How does JWE secure the Content Encryption Key

Question

I apologise in advance if this is a dumb question. But this seems like one of those straight forward things that are so straight forward that its not even mentioned and I am not getting it.

Perhaps I am too used to the simplistic client / server model where the client is like a web browser or a native mobile client which can't be trusted.

As far as i know with JWE's there is a symmetric content encryption key that encrypts the payload. The same key will be used to decrypt the payload. This key is securely transferred through asymmetric key encryption. For this I assume the public key is used to encrypt the secret key ? I assume this because from what i know in public key encryption, the public key is used to encrypt and the private key to decrypt (opposite of digital signatures)

But this is what I see from the JWT handbook:

So if the above statements and assumptions are correct, I can't make sense of:

1. Is it possible for the private key to both encrypt and decrypt ?

If yes, it would answer the rest of my questions because if a private key can both encrypt and decrypt then it makes sense a server can encrypt it and sent it out in the public. But if only one key can be used for encryption and the other for decryption then I struggle to understand how the CEK can ever be secure?

2. Who generates the symmetric CEK ? Surely it can't be a public client, If it is a server with a private key, how is this encrypted and sent for the first time ?
3. How can the symmetric CEK ever be secure when the public key is encrypting it ?
4. Even if a secure server nests the JWE inside a JWS and the public key verifies that the token comes from a verified source, can't anyone just use the secret key and encrypt anything ?

Answer 1

A public key can only be used to encrypt data and verify signatures. Decryption of data and signature generation requires the private key. So when a sender encrypts the CEK with the receiver's public key, then only the receiver can read it and decrypt the CEK-encrypted content (assuming the private key hasn't been shared or stolen).

How the CEK is generated and encrypted depends on the Key Management Mode. There are 5 different options.

• Key Encryption: The sender randomly generates the CEK and then encrypts it with the receiver's public key, so that the receiver (and only the receiver) can decrypt the CEK and, subsequently, the content. This doesn't require the parties to exchange any secrets beforehand. It's just necessary to provide the correct public key when setting up the sender.
• Key Wrapping: The sender randomly generates the CEK and encrypts it with a symmetric key shared between sender and receiver. Of course this means that both parties must be provided with the initial key beforehand, and they have to be able to securely store this key. If at least one of this cannot be implemented, then Key Wrapping isn't an option.
• Direct Key Agreement: Sender and receiver use a key agreement algorithm like (Elliptic Curve) Diffie-Hellman to generate a shared CEK ad hoc. No secret data has to be exchanged beforehand.
• Key Agreement with Key Wrapping: Similar to Direct Key Agreement, but both parties agree on a key which is used for CEK encryption. The sender generates the CEK randomly.
• Direct Encryption: Both parties have a shared symmetric key (like in Key Wrapping mode) which is used as the CEK.

More details are explained in RFC 7516.

Note that JWE is a generic protocol which isn't tied to any particular use case. You seem to use JWE in the context of OAuth, but this is just one possible application.