]>
Synthetic IV (SIV) encryption modes for JWE
ForgeRockBroad Quay HousePrince StreetBristolBS1 4DJUnited Kingdomneil.madden@forgerock.com
Security
RFCRequest for CommentsI-DInternet-DraftJavaScript Object NotationJSONJSON Object Signing and EncryptionJOSEJSON Web EncryptionJWEJSON Web AlgorithmsJWASynthetic Initialization VectorSynthetic IVSIV
This document defines how to use Synthetic Initialization Vector (SIV)
encryption and key-wrapping modes with JSON Web Encryption (JWE), and registers
identifiers for SIV-based key-wrapping and content encryption algorithms.
SIV provides either deterministic authenticated encryption and key-wrapping,
or nonce-based misuse-resistant authenticated encryption depending on usage.This specification registers cryptographic algorithms and identifiers to be used
with JSON Web Encryption (JWE) for key-wrapping, deterministic
authenticated encryption and nonce-based misuse-resistant authenticated
content encryption based on Synthetic Initialization Vectors (SIV, or "Synthetic IV")
.
SIV mode takes as input a key, the JWE Protected Header, an optional nonce (IV), and
the plaintext payload, and produces a ciphertext having the same length as the
plaintext and an authentication tag that also serves as the synthetic initialization
vector.
This extends .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .The motivations from apply here.Compared to the existing JWE AES Key Wrap algorithm (Section 4.4), SIV
provides a provable security bound, and a more efficient construction. To wrap a 128-bit key,
AES Key Wrap requires 12 calls to the AES block cipher, while SIV (with CMAC and as described
in this specification) requires just 3.For Content Encryption with a nonce, SIV is typically slightly faster than AES_CBC_HMAC_SHA2 for
short messages and typically
slower than AES GCM. However, while the security of AES GCM
collapses catastrophically if a key-nonce pair is reused (Appendix A), in
SIV an attacker would only learn whether the same plaintext (and the same associated data) has been
encrypted with the same key and
nonce. This property, known as nonce misuse resistance (NMR), provides a measure of safety in the
face of programming errors or poor quality nonce generation, such as misconfigured or compromised
random data generators, or accidental reuse due to logic errors in deterministic nonce
generation algorithms (for instance, reusing nonces after a restart).For randomly-generated IVs, AES-GCM can only safely encrypt less than 2^32 messages with the same
key, before the risk of an accidental repetition becomes too high (Section 8.3). This
limit can be easily reached in practice. For instance, an application producing JWE-encrypted tokens
at a rate of 1000 per second will need to rotate the key at most every 49 days. For SIV (and CBC)
this limit is around 2^48 (for short messages), which would allow the same application to keep using
one key for almost 9000 years.Where the content or associated data of a JWE is known to contain a non-repeating value or
key (such as a unique JWT ID ), then the nonce can be omitted, resulting in
a more compact serialisation. The nonce can also be omitted if deterministic authenticated
encryption is desired.For constrained devices, the abstract SIV scheme can be instantiated with AES in CTR
mode for confidentiality, and CMAC for authentication. In this
instantiation the mode requires only an AES encryption circuit, providing similar benefits
(and comparable performance) to AES CCM mode , but with the added robustness
of nonce misuse resistance. The NMR property is particularly attractive for devices that have
limited access to high-quality sources of entropy.Finally, SIV allows a single construction to be used for both authenticated content encryption
and key wrapping, and the construction itself is simple to describe and implement correctly
from standard building blocks.The main drawback of SIV is that it cannot be performed online as data is produced. The full data
must be processed to produce an authentication tag (and synthetic IV) before any part can be
encrypted. It is therefore most suitable for relatively short content such as JWTs .
Once the authentication tag has been produced, CTR mode encryption is fast and can be
parallelised easily. Decryption can be performed online and in parallel.BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 2 of .UTF8(STRING) denotes the octets of the UTF-8 representation
of STRING, where STRING is a sequence of zero or more Unicode
characters.ASCII(STRING) denotes the octets of the ASCII representation
of STRING, where STRING is a sequence of zero or more ASCII
characters.The concatenation of two values A and B is denoted as A || B.
These terms defined by the
JSON Web Signature (JWS)
specification are incorporated into this specification:
"Base64url Encoding"
These terms defined by the
JSON Web Encryption (JWE)
specification are incorporated into this specification:
"JSON Web Encryption (JWE)",
"Additional Authenticated Data (AAD)",
"Authentication Tag",
"Content Encryption Key (CEK)",
"JWE Authentication Tag",
"JWE Ciphertext",
"JWE Encrypted Key",
"JWE Initialization Vector",
"JWE Protected Header",
and "Key Wrapping".
These terms defined by the
Internet Security Glossary, Version 2
are incorporated into this specification:
"Ciphertext",
"Message Authentication Code (MAC)",
and "Plaintext".
This section defines a family of authenticated encryption algorithms built using a
combination of AES in Counter (CTR) mode and either CMAC or HMAC-SHA2 operations. The
presentation here is based on the abstract SIV scheme in Section 4 of .
The generic construction is parameterised by the size of the key and the instantiation of the MAC
algorithm. We use MAC(K, M) to denote the application of the MAC algorithm to the given message M
using the given key K. We use AES-CTR(K, IV, M) to denote the application of AES in CTR mode to the
message M, using the key K and Initialization Vector IV.
Rather than adopting the S2V construction of for providing multiple Additional
Authentication Data (AAD) blocks to the MAC, we instead adopt a simpler method
based on the base64url-encoded compact serialisation of the JWE Protected Header and IV separated by
dots, and the unencoded plaintext octets. This encoding uniquely determines the components of the AAD
while being simpler, and uses encoded components that are already produced if the Compact Serialization
is being used. As stated in Section 5 of , the motivation for the S2V construction is
efficiency rather than security, and any unambiguous encoding will suffice. It is expected that
a simpler construction will aid adoption of these safer encryption modes in situations where performance
is not of paramount importance.
There is an I-D defining an AES-GCM-SIV mode currently in progress
(https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05). This is a much more high-performance SIV mode
than the ones defined in this document. I have left it out of this specification because it is more
complex to implement and still in draft form. A further I-D/RFC could be proposed to also add that mode
for in this same framework, but I believe the modes defined in the present I-D will be useful for
many years to come, especially on constrained devices.For the CMAC-based algorithms, we only define modes for an overall 128-bit security level. That is, the
expected effort for an attacker to either produce an authentication tag forgery, recover either
the encryption or MAC keys, or to compromise the privacy of a any SIV-encrypted JWE, is on the order of 2^128
operations. For the HMAC-based algorithms we define modes at overall 128-bit, 192-bit and 256-bit
security levels. The reason for this is that AES-CMAC is only capable of producing a maximum authentication
tag of 128 bits and so cannot provide more than 128 bits of protection against authentication tag forgery.
The authenticated encryption algorithm takes as input for octet strings: a secret key K, a plaintext P,
additional authenticated data AAD (computed as per Steps 13-14 of Section 5.1 of ),
and an optional initialization vector IV. It produces the
ciphertext value E and an authentication tag T as outputs. The data in the plaintext are encrypted, and
the additional authenticated data are authenticated, but not encrypted.Encryption is performed using the following steps:
The secondary keys MAC_KEY and ENC_KEY are generated from the
input key K as follows. Each of these two keys is an octet string.
MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in order.ENC_KEY consists of the final ENC_KEY_LEN octets of K, in order.
The number of octets in the input key K MUST be the sum of MAC_KEY_LEN and ENC_KEY_LEN.If a nonce is to be used, then the IV SHOULD be a 128-bit value generated randomly
or pseudorandomly.A message Authentication Tag T is computed as:
T = MAC(MAC_KEY, ASCII(AAD || '.' || BASE64URL(IV) || '.') || plaintext).
If no IV (nonce) is being used, then an empty octet sequence MUST be used instead.The Synthetic IV, SIV, is set to the first 16 octets of T, in order.The plaintext is encrypted using AES-CTR with ENC_KEY as the key and SIV as the IV. We denote the ciphertext
output of this step as E.The ciphertext E and the Authentication Tag T are returned as the outputs of the authenticated encryption.The encryption process can be illustrated as follows. Here K, P, AAD, IV, SIV, T, and E denote the key,
plaintext, Additional Authenticated Data, Initialization Vector, Synthetic IV, Authentication Tag, and ciphertext, respectively.
MAC_KEY = initial MAC_KEY_LEN octets of K,ENC_KEY = final ENC_KEY_LEN octets of K,T = MAC(MAC_KEY, ASCII(AAD || '.' || BASE64URL(IV) || '.') || P),SIV = initial 16 octets of T,E = AES-CTR(ENC_KEY, SIV, P).Decryption is performed using the following steps:The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as in Step 1 of .The Synthetic IV is set to the first 16 octets of the Authentication Tag T. If the Authentication Tag is missing or
not of the expected length for the algorithm (which is always at least 16 octets) then decryption MUST halt
with an indication of failure.The plaintext P is decrypted using AES-CTR with ENC_KEY as the key, SIV as the IV, and the ciphertext, E.The Authentication Tag T is checked by recomputing the tag T' as in Step 3 of . If T and T' are
identical then H and P are considered valid and processing is continued. Otherwise, all of the data used
in the MAC computation MUST be discarded and the decryption operation MUST halt with an indication of failure.
Tag comparison MUST use a constant-time octet string comparison operation using the known length of the
Authentication Tag as specified by the algorithm in use.The plaintext P is returned.The following JWE algorithms are defined here (to be applied as values of "alg" parameter):"alg" Param ValueKey Management AlgorithmA128SIVKWAES SIV Key Wrap using CMAC and 256 bit key.A128SIVKW-HS256AES SIV Key Wrap using HMAC-SHA-256-128 and 256 bit key.A192SIVKW-HS384AES SIV Key Wrap using HMAC-SHA-384-192 and 384 bit key.A256SIVKW-HS512AES SIV Key Wrap using HMAC-SHA-512-256 and 512 bit key.All of the key wrapping modes use the generic construction from ,
with the following inputs:
The plaintext P is the octets of the Content Encryption Key (CEK) to be wrapped.The input key K is the Key Encryption Key (KEK).The IV is an empty octet sequence.The AAD is the UTF8 octets of the value of the "alg" parameter (e.g., "A128SIVKW").In all cases the output ciphertext length will be the same as the input plaintext CEK, in octets. The authentication
tag will either be 16, 24 or 32 octets long depending on the algorithm.
The JWE Encrypted Key value is the Ciphertext output.The Authentication Tag output is represented in base64url encoded form
as the tag (authentication tag) Header
Parameter value, as in Section 4.7.1.2 of . This
specification extends that header value to allow authentication tags of 192
or 256 bits. NB: this has the added advantage of binding the wrapped key
into the JWE authenticated data, which would otherwise not happen.This algorithm uses the CMAC message authentication
code to provide message authentication and
the synthetic IV.The parameters are as follows:
The input key K is 32 octets long.MAC_KEY_LEN is 16 octets.ENC_KEY_LEN is 16 octets.MAC is CMAC.The output tag length is 16 octets.This algorithm uses the HMAC-SHA-256-128 message authentication code as defined
in to provide message authentication and the synthetic IV.The parameters are as follows:
The input key K is 32 octets long.MAC_KEY_LEN is 16 octets.ENC_KEY_LEN is 16 octets.MAC is HMAC-SHA-256-128.The output tag length is 16 octets.This algorithm uses the HMAC-SHA-384-192 message authentication code as defined
in to provide message authentication and the synthetic IV.The parameters are as follows:
The input key K is 48 octets long.MAC_KEY_LEN is 24 octets.ENC_KEY_LEN is 24 octets.MAC is HMAC-SHA-384-192.The output tag length is 24 octets.This algorithm uses the HMAC-SHA-512-256 message authentication code as defined
in to provide message authentication and the synthetic IV.The parameters are as follows:
The input key K is 64 octets long.MAC_KEY_LEN is 32 octets.ENC_KEY_LEN is 32 octets.MAC is HMAC-SHA-512-256.The output tag length is 32 octets.The following content encryption methods are defined here (to be applied as values of
the "enc" parameter):"enc" Param ValueContent Encryption MethodA128SIVAES SIV using CMAC and 256 bit key.A128SIV-HS256AES SIV using HMAC-SHA-256-128 and 256 bit key.A192SIV-HS384AES SIV using HMAC-SHA-384-192 and 384 bit key.A256SIV-HS512AES SIV using HMAC-SHA-512-256 and 512 bit key.All of the SIV content encryption methods use the generic construction from ,
with the following inputs:
The plaintext P is the octets of JWE plaintext.The input key K is the Content Encryption Key (CEK).The IV is either a randomly or pseudorandomly generated 16 octet value, or an empty octet string.The AAD is the UTF8 octets of the JWE Protected Header.In all cases the output ciphertext length will be the same as the input plaintext, in octets. The authentication
tag will either be 16, 24 or 32 octets long depending on the algorithm. The Ciphertext and Authentication Tag
outputs become the JWE Ciphertext and JWE Authentication Tag values respectively.
This algorithm uses the CMAC message authentication
code to provide message authentication and
the synthetic IV.The parameters are as follows:
The input key K is 32 octets long.MAC_KEY_LEN is 16 octets.ENC_KEY_LEN is 16 octets.MAC is CMAC.The output tag length is 16 octets.This algorithm uses the HMAC-SHA-256-128 message authentication code as defined
in to provide message authentication and the synthetic IV.The parameters are as follows:
The input key K is 32 octets long.MAC_KEY_LEN is 16 octets.ENC_KEY_LEN is 16 octets.MAC is HMAC-SHA-256-128.The output tag length is 16 octets.This algorithm uses the HMAC-SHA-384-192 message authentication code as defined
in to provide message authentication and the synthetic IV.The parameters are as follows:
The input key K is 48 octets long.MAC_KEY_LEN is 24 octets.ENC_KEY_LEN is 24 octets.MAC is HMAC-SHA-384-192.The output tag length is 24 octets.This algorithm uses the HMAC-SHA-512-256 message authentication code as defined
in to provide message authentication and the synthetic IV.The parameters are as follows:
The input key K is 64 octets long.MAC_KEY_LEN is 32 octets.ENC_KEY_LEN is 32 octets.MAC is HMAC-SHA-512-256.The output tag length is 32 octets.The following are added to JSON Web Signature and Encryption Algorithms registry:Algorithm Name: "A128SIVKW"Algorithm Description: AES SIV Key Wrap with CMAC using 256 bit keyAlgorithm Usage Location(s): "alg"JOSE Implementation Requirements: RecommendedChange Controller: IESGSpecification Document(s): Algorithm Name: "A128SIVKW-HS256"Algorithm Description: AES SIV Key Wrap with HMAC-SHA-256-128 using 256 bit keyAlgorithm Usage Location(s): "alg"JOSE Implementation Requirements: RecommendedChange Controller: IESGSpecification Document(s): Algorithm Name: "A192SIVKW-HS384"Algorithm Description: AES SIV Key Wrap with HMAC-SHA-384-192 using 384 bit keyAlgorithm Usage Location(s): "alg"JOSE Implementation Requirements: OptionalChange Controller: IESGSpecification Document(s): Algorithm Name: "A256SIVKW-HS512"Algorithm Description: AES SIV Key Wrap with HMAC-SHA-512-256 using 512 bit keyAlgorithm Usage Location(s): "alg"JOSE Implementation Requirements: OptionalChange Controller: IESGSpecification Document(s): Algorithm Name: "A128SIV"Algorithm Description: AES SIV with CMAC using 256 bit keyAlgorithm Usage Location(s): "enc"JOSE Implementation Requirements: RecommendedChange Controller: IESGSpecification Document(s): Algorithm Name: "A128SIV-HS256"Algorithm Description: AES SIV with HMAC-SHA-256-128 using 256 bit keyAlgorithm Usage Location(s): "enc"JOSE Implementation Requirements: RecommendedChange Controller: IESGSpecification Document(s): Algorithm Name: "A192SIV-HS284"Algorithm Description: AES SIV with HMAC-SHA-384-192 using 384 bit keyAlgorithm Usage Location(s): "enc"JOSE Implementation Requirements: OptionalChange Controller: IESGSpecification Document(s): Algorithm Name: "A256SIV-HS512"Algorithm Description: AES SIV with HMAC-SHA-512-256 using 512 bit keyAlgorithm Usage Location(s): "enc"JOSE Implementation Requirements: OptionalChange Controller: IESGSpecification Document(s): The security considerations of apply here.
In total, no more than 16 * 2^48 octets of data (approx. 4 exabytes) should be encrypted with the same key
in any SIV mode. For example, when using SIV128KW to wrap 128-bit keys, then no more than 2^48 messages should
be encrypted with the same key encryption key (KEK). This is over 281 trillion messages, so is expected
to provide sufficient capacity for extremely long-lived or high-usage keys.
SIV uses AES in CTR mode for encryption, which produces ciphertexts that are exactly the same length as the
plaintext. If the length of the plaintext is sensitive (for instance, when encrypting a password that may be
short) then the application should pad such values to some minimum/fixed size before encryption. If such
padding is performed, then it MUST be applied before calling the AES-SIV encryption modes defined in this
specification, so that the padding is included in the authentication tag. When decrypting, authentication
tag validation in Step 4 of MUST be performed before any validation or processing
of the padding is performed.
Care should be taken when combining JWE plaintext compression with SIV encryption for a related reason: compression
varies the size of the plaintext based on the (confidential) content of that plaintext. In SIV mode (and other
cipher modes, such as GCM and, to a lesser extent, CBC), this will vary the size of the ciphertext by
the same amount. If an attacker is able to control any part of the content of the plaintext then they
may be able to infer confidential parts of the same plaintext according to variations in the size of the
compressed and encrypted ciphertext. It is therefore recommended not to use compression with SIV mode
encryption (or any encryption) unless the expected information leakage is acceptable.
&RFC2119;
&RFC3629;
&RFC4868;
&RFC7515;
&RFC7516;
&RFC7518;
ASCII format for Network InterchangeUniversity California Los Angeles (UCLA)For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.
&RFC3610;
&RFC4493;
&RFC4949;
&RFC5297;
&RFC7519;
Deterministic Authenticated-Encryption. A Provable-Security Treatment of the Key-Wrap Problem.University of California at DavisPortland State UniversityThe Unicode StandardThe Unicode ConsortiumRecommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.NIST
The following test cases can be used to validate implementations of
the AES SIV algorithms defined in this specification.
The variable names are those defined in .
All values are hexadecimal.
NB: K here is the KEK, and P is the CEK to be wrapped, T is the output "tag" value, and E is the wrapped CEK.NB: K here is the KEK, and P is the CEK to be wrapped, T is the output "tag" value, and E is the wrapped CEK.