What are JWE Key Management Modes?

Question

The JWE standard defines a concept called Key Management Mode. According to the RFC, there are five: Direct Encryption, Key Encryption, Direct Key Agreement, Key Wrapping, Key Agreement with Key Wrapping.

What's the difference between them and what's the point of having so many?

Answer 1

JWE always encrypts plaintext using a symmetric encryption key called CEK (Content Encryption Key). An issuer and recipient don't always have a pre-shared key they can use as the CEK, so they must use some form of public-key cryptography in order to securely share or agree on a CEK to use. Key Management Modes specify how the CEK is determined.

JWE always provides confidentiality (ensure only recipient can decrypt data), and integrity (ensure data was not altered by a third-party during transit). Depending on the Key Management Mode, it can also provide authentication (ensure data comes from issuer it claims to be).

JWE also supports tokens intended for multiple recipients where each recipient may use a different Key Management Mode. In this scenario, the JWE cannot use compact serialization and must use JSON serialization. Additionally, regardless of the number of recipients, JWE uses a single CEK to encrypt the plaintext. Thus, there is no need to include a different copy of the ciphertext for each intended recipient.

The following are the supported Key Management Modes by JWE:

1. Direct Encryption:

• Used when:
  • Issuer and recipient have a pre-shared symmetric key.
• How it works:
  • Let the pre-shared symmetric key be the CEK.
  • Issuer encrypts plaintext with CEK.
  • Recipient decrypts ciphertext with CEK.
• Properties:
  • Confidentiality.
  • Integrity.
  • Authentication (assuming only issuer and recipient have knowledge of CEK).
• Supported by multi-recipient JWE: No.
• Example JOSE header: { "alg": "dir", "enc": "A256GCM" }

2. Key Encryption:

• Used when:
  • Scenario A:
    • Issuer and recipient do not have a pre-shared symmetric key.
    • Issuer has knowledge of a recipient's public RSA key.
  • Scenario B:
    • Issuer wants to send a single JWE to multiple recipients.
    • Issuer and at least one of the recipients do not have a pre-shared symmetric key. Instead, the issuer has knowledge of a public RSA key for that recipient.
• How it works:
  • Issuer randomly-generates a CEK.
  • Issuer encrypts plaintext with CEK.
  • For each intended recipient:
    • Issuer encrypts CEK with recipient's public key.
    • Issuer includes encrypted CEK + ciphertext in JWE.
    • Recipient decrypts encrypted CEK with its private key.
    • Recipient decrypts ciphertext with CEK.
• Properties:
  • Confidentiality.
  • Integrity.
• Supported by multi-recipient JWE: Yes.
• Example JOSE header: { "alg": "RSA-OAEP", "enc": "A256GCM" }

3. Direct Key Agreement

• Used when:
  • The issuer and recipient do not have a pre-shared symmetric key.
  • Issuer has knowledge of a recipient's public EC key (EC key pairs cannot be used directly to encrypt/decrypt data).
• How it works:
  • Issuer randomly-generates an ephemeral EC public/private key pair.
  • Issuer derives CEK using ephemeral private key and recipient's public key.
  • Issuer encrypts plaintext with CEK.
  • Issuer includes ephemeral public key + ciphertext in JWE.
  • Recipient derives CEK using ephemeral public key and its private key.
  • Recipient decrypts ciphertext with CEK.
• Properties:
  • Confidentiality.
  • Integrity.
• Supported by multi-recipient JWE: No.
• Example JOSE header: { "alg": "ECDH-ES", "enc": "A256GCM", "epk": { ephemeral public key }, "apu": "(issuer)", "apv": "(recipient)" }

4. Key Wrapping

• Used when:
  • The issuer wants to send a single JWE to multiple recipients.
  • The issuer and at least one of the recipients have a pre-shared secret.
• How it works:
  • Issuer randomly-generates a CEK.
  • Issuer encrypts plaintext with CEK.
  • For each intended recipient:
    • Let the pre-shared secret be the wrapping key or a password used to derive a wrapping key.
    • Issuer encrypts CEK with the wrapping key.
    • Issuer includes encrypted CEK + ciphertext in JWE.
    • Recipient finds its corresponding encrypted CEK and decrypts it with the wrapping key.
    • Recipient decrypts ciphertext with CEK.
• Properties:
  • Confidentiality.
  • Integrity.
  • Authentication (assuming only issuer and recipient have knowledge of shared secret).
• Supported by multi-recipient JWE: Yes.
• Example JOSE header: { "alg": "A256KW", "enc": "A256GCM" }

5. Key Agreement with Key Wrapping

• Used when:
  • The issuer wants to send a single JWE to multiple recipients.
  • The issuer and at least one of the recipients do not have a pre-shared symmetric key. Instead, the issuer has knowledge of a public EC key for that recipient (EC key pairs cannot be used directly to encrypt/decrypt data).
• How it works:
  • Issuer randomly-generates a CEK.
  • Issuer encrypts plaintext with CEK.
  • For each intended recipient:
    • Issuer randomly-generates an ephemeral EC public/private key pair.
    • Issuer derives a wrapping key using ephemeral private key and recipient's public key.
    • Issuer encrypts CEK using wrapping key.
    • Issuer includes encrypted CEK + ephemeral public key + ciphertext in JWE.
    • Recipient finds its corresponding ephemeral public key and derives wrapping key using it and its private key.
    • Recipient finds its corresponding encrypted CEK and decrypts it using the derived wrapping key.
    • Recipient decrypts ciphertext with CEK.
• Properties:
  • Confidentiality.
  • Integrity.
• Supported by multi-recipient JWE: Yes.
• Example JOSE header: { "alg": "ECDH-ES+A256KW", "enc": "A256GCM", "epk": { ephemeral public key }, "apu": "(issuer)", "apv": "(recipient)" }