Spring's default OAuth JWT flow (using client_credentials grant) is as follows:
Launch the Auth Server (AS)
Launch the Resource Server (RS)
At startup the RS requests the tokenKey by calling GET /oauth/token_key using Basic Auth
The AS returns a PUBLIC KEY using RS256 (SHA256withRSA)
Some time later, the Client requests an accessToken by calling GET /oauth/token using the client_credentials grant
The AS returns a JWT accessToken containing a JWS signature
The Client sends the JWT as a Bearer token to the RS
The RS uses the tokenKey that it received from the AS at startup to verify that the JWT accessToken came from the AS. This is where I get confused...
Is this secure? Why would a public cert be used rather than a shared secret key? Couldn't a hacker easily obtain the public key and sign their own valid JWT accessToken? How does the usage of the public key cert and the JWT signature work together to verify that the sender was actually the Auth Server and not an attacker?
Any insight would help.
Some research into the nature of public key cryptography and digital signatures gleans this:
Digital signatures implement asymmetric cryptography. A digital signature gives the receiver reason to believe the message was sent by the claimed sender. Similar to a handwritten signature they are difficult to forge. The signer, in this case, the AS, uses a secret PrivateKey to create the signature. Some non-repudiation schemes offer a time stamp for the digital signature, so that even when the PrivateKey is exposed, the signature is valid.
A digital signature scheme typically consists of 3 algorithms
1) A key generation algorithm that selects a PrivateKey uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key.
2) A signing algorithm that creates a signature using the message and the private key
3) A signature verifying algorithm that, given the message, PublicKey and signature, either accepts or rejects the message's claim to authenticity.
In this case (RS256), the signature was created using SHA256withRSA which is not used as an encryption algorithm, rather it is used to verify the origin or the authenticity of the data. The signature was generated using a private key. The public key is passed to the Resource server to be used to verify the signature. In this scenario, even if an attacker has the PublicKey, they cannot create a spoof message with the signature or alter the contents.
Related
I've generated a key-pair using keytool -genkeypair command. I presume this create a pair of private key and public key.
I've also generated a CSR out of this key-pair using the keytool -certreg command. I got it signed by our CA (or whatever they call it) and I got another certificate in return along with it is its thumbprint.
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
A key is a set of mathematical parameters describing how to initialize certain algorithms for cryptographic operations, e.g. for signing/verification or for encryption/decryption.
A key pair merely is a pair of such keys where each key can verify what the other one has signed or where each key can decrypt what the other one has encrypted.
One key in such a pair is declared the public key and the other one the private key. (This choice is not completely arbitrary, there can be different extra requirements to a private key than to a public one.)
There is nothing in these keys declaring that they are bound to a specific person, to a specific issuer, to a specific purpose, to a specific accountability, etc.
This is where X.509 certificates come into the picture: A X.509 certificate is a structure that bundles the public key of a key pair with extra information like the name of the holder of the key pair, the name of an issuer of the certificate, validity time spans, and much more.
This structure furthermore contains a signature of all those other data in the structure. This signature is generated using the private key of the issuer of the certificate.
The information in the certificate in particular allows you to determine the issuer of it. If you trust organization of the issuer to only issue certificates to persons whose identity they checked, and if you successfully validated that the certificate signature is valid and created by the issuer, you can trust the identity of the holder of the key pair of a given certificate.
Thus,
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
you provide your certificate publicly to allow people to be sure of your identity when they use the contained public key to validate your signatures or encrypt information they send to you. Without a mechanism like the certificates you'd have to give people your public key in person for them to be sure of that.
I am confused about the execution order of ECDSA and ECDH, which one runs first ?
Since ECDH can not avoid MITM attach, therefore ECDSA is used to verify the entity. So ECDSA should run before ECDH ?
Or it doens't matter at all?
Since ECDH can not avoid MITM attack
First, here is one of the many ways you could solve this difficulty using RSA instead of DSA (or ECDSA): the client, before sending its ECDH (or DH) public key on the wire, could encrypt this ECDH (or DH) public key with the public RSA key of the server. And this way, the server is the only peer that knows the client ECDH key. Therefore, both sides are protected against man in the middle attacks. Of course, using RSA to encrypt another key may need OAEP.
Or it doens't matter at all?
In your case, using ECDSA instead of RSA, you can not encrypt anything. So you need to have mutual authentication in the protocol you will design: your server and your client must have previously exchanged their public ECDSA keys or must have some kind of PKI with some kind of root certificate to authenticate the remote public ECDSA key. Finally, the client and the server just need to follow those steps, in this order:
sign their ECDH public key with their ECDSA private key,
send this information to the other host,
receive this information from the other host,
check the signature,
if the check failed, stop talking,
if the signature is correctly checked, perform the end of the DH algorithm.
i want to know performance wise which is better to provide message authenticity, ECDSA signatures or hash based signatures, although i have read the comparisons of ECDSA with RSA, but not found with hash based signatures. Can ECDSA signatures replaced with Hash based signatures improves the message authenticity or not.
ECDSA is a hash based signature, in that the data gets hashed, then ECDSA is performed on the hash (not the whole data)
When it comes to data verification there are three main approaches:
Straight hash (e.g. SHA-2-256)
The fastest option to verify
If you are only protecting against line corruption this is a valid choice.
Otherwise, requires that the hash/digest value be sent over a secure (from tamper) channel, because the tampered can easily transmit the digest along with the tampered document
Provides no proof of origin
HMAC (e.g. HMACSHA256)
Requires that both the sender and receiver share the secret key
Either the sender or receiver having the key stolen puts both sides at risk
Secret key needs to come from key agreement algorithms (ECDH) or be transmitted in secret (encrypted)
Proves the document came from someone with the shared secret.
Digital Signature (e.g. ECDSA, RSA signature)
The sender is the only entity with the private key, receiver needs public key (non-secret)
Public key can be embedded in an X.509 certificate to provide a notarized association of public key to the signer
Or the public key can be transmitted raw over a secure (from tamper) channel.
Provides strong assurances about the document origin, since they shouldn't share their private key.
All three options use a hash algorithm to reduce the original data, the rest of the algorithms are what do you do with that data. There's not really a standard definition of "secure", you have to say "secure against (something)". ECDSA provides more assurances than HMAC as long as the private key isn't shared. But if HMAC provides enough assurance it is probably faster on average (specialty hardware aside).
I am trying to create a JWT for the authentication of Googles app engine
The main issue is that I need to create a signer with RSA using SHA-256 hashing algorithm.
The only library I found which supports this is Nimbus but their signing always uses the already created private key which is of type RSAPrivateKey, I need to be able to sign with the private key String I obtained from google.
How can I transform the String representation of my private key into a RSAPrivateKey object?
In case of claim based authentication which uses SSO, an application receives a token from the issuer for a particular user and that token contains the claims as well as some sort of digital signature in order to be traced by the application that an issuer is a trusted one.
I want to know, if there are some sort of algorithms involved by which this application recognizes an issuer?
I had read that issuer has a public key and all the other applications have their own private key, is it true?
There are many protocols, formats and methods of doing Single Sign On such as Security Assertion Markup Language (SAML), OpenID and OAuth. The goal is for one entity, such as a website, to identity and authenticate the user (such as through a user name and password) and other entities, such as other websties, trust the evidence of that authentication through a token. This means users need not remember yet another password and each website maintain their own list of passwords.
This trust is usually enforced through cryptography using a digital signature. Digital signatures are used because it allows the trusting entity to verify token was (1) issued by the authenticating entity only and (2) not tampered with without being able to impersonate (pretend to be) the authenticating entity.
As you say above, this is performed using asymmetric or public key cryptography. Symmetric cryptography, such as the AES or DES algorithms, use a single key to encrypt and decrypt data. Asymmetric cryptography, such as the RSA algorithm, uses two related keys. Data encrypted using one can only be decrypted by the other and vice versa.
One key is usually kept secret, called the private key, and the other is distributed widely, called the public key. In the example above, the authenticating entity has the private key that allows it to encrypt data that anyone with the public key can decrypt.
It would seem to follow that the authenticating entity would just encrypt the user details and use that as the token. However, commonly used asymmetric algorithms like RSA are very slow and encrypting even small amounts of data can take too long.
Therefore, instead of encrypting the user details, the authenticating entity generates a "hash" or "digest" and encrypts that. A hash algorithm converts a piece of data into a small number (the hash) in a very difficult to reverse way. Difference pieces of data also create different hashes. Common hash algorithms include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) and its derivatives like SHA1, SHA256 and SHA512.
The hash encrypted with the authenticating entity's private key is called a digital signature. When it receives the token, the trusting entity decrypts the token using the authenticating entity's public key and compares it to a hash it calculates itself. If the hashes are the same, the trusting entity knows it has not been modified (because the hashes match) and it must have come from the authenticating entity (because only it knows its private key).
If you want more information about SAML and claims-based authentication, I found this video very helpful. It does get complicated rather quickly and you may need to watch it multiple times but Vittorio covers most of these concepts in great detail.