I am reading about application code signing in iOS and I don't understand why both private and public key is together? What is the public key and certificate used for when you are signing the application with the private?
Xcode uses your digital identity to sign your application during the
build process. This digital identity consists of a public-private key
pair and a certificate. The private key is used by cryptographic
functions to generate the signature. The certificate is issued by
Apple; it contains the public key and identifies you as the owner of
the key pair.
Let's sum up the process:
You encrypt an hashed digest (like md5 or sha-1) of the executable of application with your private key. That's "signing".
Your users decrypt it with your public key (they have it because it's public) and check it against the executable. As long as your private key stays private, it's you who "signed" it. That's called "verifying".
What about the digital identity then:
You public key isn't public by itself, it must be somehow shared, "made public", and signed by the Certification Autority (hereby CA) too, (that's the CA encrypting it —or an hash of it— with their, one of their, magical mysterious private keys) this guarantees the sharing process hasn't been tampered with by a man in the middle.
So, public key and certificate (CA signature — CA encrypting your public key) identify you (as such are considered part of your "digital identity") and must reach the end user somehow (via a third party, embedded into the executable, you name the way)
The public key is needed so anyone can decrypt the application, and is hence included in the build.
Related
I have private key (not RSA) and i want to generate JWT using <jwt.io> using RS256. How can I generate a token?
Whenever I enter my private key it says invalid signature. If I need to pass RSA private key then how to convert my private key to RSA private key? I am totally new to this.
RS256 is an asymmetric signature algorithm, that means you need a keypair consisting of private and public key. You can generate such a pair with various online tools or with openssl.
To generate (i.e sign) a token, you need the private key.
But for verification, you need the public key. As long as you only paste the private key into the field in the right column, JWT.io can sign a token, but can't verify it. Therefore paste both keys of the pair into the key fields to get your token signed and verified.
I quite understand the part that after creating a CSR it is sent to the CA where it is signed with its private key. Now I want to create an algorithm that would do a backward check of authenticity from "pubcert>issuing ca>to subroot ca> to root ca" by verifying the signatures in its certificates and the public key of the CA that signed it. The problem is I don't know what is the input needed to do verification. See to initiate verification i have to do like "C_Verify(session handle, public key, input, inputLength, signature, signature length)". In my case, signature and signature length is from the pubcert while the public key would be from the issuing CA but I do not know what the input part would be?
A CSR is mainly created to create a certificate having trusted public key.
Before creating a CSR,
we create a private key
openssl genrsa -out key.pem 1024
and then use that private key(key.pem) to create a CSR(req.pem) request.
openssl req -new -key key.pem -out req.pem
Edit:
I see that a docker engine is installed with root certificate, server certificate & private used with CSR
What is the exact purpose of providing private key(key.pem as input) amidst submitting CSR? Because certificate is supposed to be signed with parent private key
Is private key(key.pem) required to generate corresponding public key amidst CSR creation?
or
Is private key(key.pem) used to encrypt the CSR and the resulting signature is appended to CSR?
The structure of a PKCS#10 certification request (RFC 2986) is, loosely described:
Request:
Info:
Version
Name
PublicKey
Attributes
SignatureAlgorithmIdentifier
Signature
The attributes are attributes for the request, where one if them could be attributes you are requesting for the resulting certificate.
The CA can respect as much, or as little, from the CSR as it chooses. StartSSL, for example, only read out the public key information, and discarded the remainder of the CSR -- everything else they needed was based on your request from their web UI and your account status.
In general, the CA isn't going to ignore the public key value, because if they asserted a new keypair for you they'd need to figure out how you were supposed to get the private key. So, the public key part needs to be present and correct. OpenSSL's command can get the public key value by reading the private key, then it can embed it in the CSR.
The second reason you need the private key is to sign the request. I'll assert that the main reason the request is signed is to force/strongly-suggest you save the private key at this stage, so you don't come back in a few minutes with a "please revoke this new certificate, I already lost the private key" request. The RFC (also) has this to say:
Note 2 - The signature on the certification request prevents an
entity from requesting a certificate with another party's public key.
Such an attack would give the entity the minor ability to pretend to
be the originator of any message signed by the other party. This
attack is significant only if the entity does not know the message
being signed and the signed part of the message does not identify the
signer. The entity would still not be able to decrypt messages
intended for the other party, of course.
I was wondering whether RSA can be cracked given:
The public key
A plaintext of a known cipher text.
In other words the decrypted message from an encrypted one (but without knowing the private key)
I.E.: you have managed to find the plaintext of an already encrypted message using the public key, however, you DO NOT know the private key.
No. That's called a known-plaintext attack, and there is no such attack known against RSA.
If we make the private key exportable (using -pe option in makecert), then in theory we have both an exportable private key and the public key (public key in certificate) -- which can be transferred or imported to another machine.
So, my question is, why do we still need to create the .pfx file (key exchange file, which contains private and public keys) -- making the private key exportable in certificate could do anything we want? Any scenarios pfx file could cover which making private key exportable in certificate could not achieve?
thanks in advance,
George
Is there a makecert command line you have found that will generate a certificate file that includes a private key? I never have. I have seen someone allude to the fact that there is a version of makecert that can produce .pfx files but also have never seen that.
That means at the very best you can create TWO files with makecert if you want a private key file. One for the certificate and one for the private key. You can copy both those files to another computer and import them using makecert.
The advantage of the .pfx certificate format is that you can combine the two files with the certificate and private key into one. This is more convenient and also means you can use the file with the .Net X509Certificate2 class for use with an SslStream.
Your pfx file can be password protected, that would add a layer of protection
The problem is, the X509 Certificate standard (the certificate) does not include the private key. The certificate contains the subject public key info (aka, the public key) and information about the holder of the private key, but the standard does not support including the private key. This is the basic idea of PKI - the certificate is the public info you share with the world, the private key is something you hold very securely.
Making a private key exportable in any mechanism (for example, makecert), means you are telling that product that the key can be exported. It doesn't specify the file format that you would use to store it. A pfx file is one way of storing the private key - it uses the PKCS 12 standard. Java Key Stores (*.jks) are another way to do the same thing. Most commerically supported standards have similar common features - they protect the private key by encrypting it. The encryption can be unlocked using a password. They couple the private key with the certificate that decribes it.
If you want to build a PFX file, you should have both x509 cert public key and private key file which you can generate using makecert command. PFX can be generated using PVk2PFX command which you can find Microsoft SDK installation directiory.