Could someone kindly explain why the private key is included (by default) in the JWT-Token generated by "all" the cpp-based JWT libraries found on github & how to remove it?
The only thing that comes close is the signature of the JWT (the last part in blue at the example in https://jwt.io/).
You need the private key to calculate the signature, but it is definitely not included in the JWT!
Related
We're verifying a Google ID Token on ColdFusion servers. We have everything working but one thing puzzles me:
In the instructions here Google says to use their public keys to verify the token. When we retrieve the keys, in the JSON object there are 2 of them. Whether we grab the PEM or the JWT there are 2 keys.
Example JWT:
Example PEM:
How do we know which key to use? Through testing we find that one works and we're able to decode the JWT to validate while the other doesn't. Right now we're having to try both of them to see which one works. Is there something we're missing that indicates which of these keys is the one to use?
The keys are identified by the key Id "kid":
The "kid" (key ID) parameter is used to match a specific key.
In case of the JWK, you see the kid value in the JSON and you can see the same kid values in the first column of the PEM example. Your token has a "kid" claim in the header part. Decode the header to extract the kid.
e.g.:
{
"typ":"JWT",
"alg":"RS256",
"kid":"3dd6ca2a81dc2fea8c3642431e7e296d2d75b446"
}
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'm trying to read out a tachograph company smart card. I can read all data just fine except the identification part. Which is the part I actually need. When I select that DF the security environment is reset and I have to re-authenticate. This process is described in sub appendix-11 of ECE/TRANS/SC.1/2006/2/Add.1. Although this document is a bit hard to understand for me.
In this picture you see the data structure of a tachograph company card. The "AUT" behind the ID part tells you that you need to authenticate.
After asking another question on SO and doing a lot of research on how public/private keys are used I think I have some basic understanding on how I should do the authentication. In the documentation, there is also a pretty detailed flow chart on how to get the authentication done. It's to big unfortunately to place here. But I have a question about this part:
Now, I'm counting from the top, downwards. So the first top left square is step one, the last bottom left is step 7. The middle section arrows are APDU commands that need to be send to the card, and the right section is the smart card. PK means public key. CA means certificate authority.
If you do not know the public keys, you see you need to get both the card and the CA certificate. I've done that and I can read them from the card. The part I don't understand are step 6 and 7. You see I need to verify the Card CA.C (which is some part of the certificate) with the European Public key. Where do I get the European public key and what algorithm is used to decrypt it?
EDIT:
Is this the Verification process? And if so, it says to open the sign with the CA public key, How do I get this?
EDIT 2:
I've found the European public key from this link. The CAR part of the CA certificate on the card matches the first 8 bytes from the public key. Meaning it is the correct public key. Now If I understand correctly, I need to Open the sign following step three from CSM_019 from the picture above. To open the sign, I need the correct algorithm using the public key I quess? Does anyone know what algorithm is used?
Step 6: Nothing to decrypt here: You verify the signature, also part of the certificate (Card.CA.C), and if it is correct the contained key (public key of card CA) may be extracted and used for the next step.
Step 7: You verify the signature of card certificate (made with the card.ca key just retrieved) and if it is correct you now have the public key of the card (with the certainty, that it is correct, otherwise signature would have mismatched).
The scheme uses this two-step approach, so that only the Eur.PK public key is needed instead of the keys of all card CAs.
i am using
SignedCms.CheckSignature(certColl, true)
(with only one cert in certColl) to verify the signature of a pkcs-7 message. My problem is that i dont want to change the (public part of the) signers certificate on my server after the signer has renewed his certificate :-( The public key, issuer and subject are remaining unchanged after signer has renewed his certificate! So this has to work - at least in my opinion, even if i´m not a crypto-geek :-)
..but, unfortunately the .NET-Framework throws a Cryptographic Exception "Cannot find the original signer" like the stacktrace says exactly at:
SignerInfo.CheckSignature(X509Certificate2Collection extraStore, Boolean verifySignatureOnly)
This must be because the serial number of the signers certificate has changed and the SignerIdentifier property is readonly and set to IssuerAndSerialNumber.
Does anyone know how workaround this?
Or do i have to implement a "handmade" signature verifying with sth like: signedMessage.ComputeSignature(signer, false)?
Thanks in advance and happy programming,
Krile
For all interested on this issue:
Someone told me that this is due to the PKCS #7 specification, which states that the SubjectKeyIdentifier is always set to IssuerAndSerialNumber.
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.