Key Usage Limits for OSCORE

AEAD Key Usage Limits in OSCORE This section details how key usage limits for AEAD algorithms can be considered when using OSCORE. In particular, it discusses specific limits for common AEAD algorithms used with OSCORE; parameters to track associated with an OSCORE Security Context; and additions to the OSCORE message processing.

Problem Overview The OSCORE security protocol uses AEAD algorithms to provide integrity and confidentiality of messages, as exchanged between two peers sharing an OSCORE Security Context. When processing messages with OSCORE, each peer should follow specific limits as to the number of times it uses a specific key. This applies separately to the Sender Key used to encrypt outgoing messages, and to the Recipient Key used to decrypt and verify incoming protected messages. Exceeding these limits may allow an adversary to break the security properties of the AEAD algorithm, such as message confidentiality and integrity, e.g., by performing a message forgery attack. The following refers to the two parameters 'q' and 'v' introduced in , to use when deploying an AEAD algorithm.

'q': this parameter has as value the number of messages protected with a specific key, i.e., the number of times the AEAD algorithm has been invoked to encrypt data with that key.
'v': this parameter has as value the number of alleged forgery attempts that have been made against a specific key, i.e., the number of failed decryptions that have occurred with the AEAD algorithm for that key.

When a peer uses OSCORE:

The key used to protect outgoing messages is its Sender Key from its Sender Context.
The key used to decrypt and verify incoming messages is its Recipient Key from its Recipient Context.

Both keys are derived as part of the establishment of the OSCORE Security Context, as defined in . As mentioned above, exceeding specific limits for the 'q' or 'v' value can weaken the security properties of the AEAD algorithm used, thus compromising secure communication requirements. Therefore, in order to preserve the security of the used AEAD algorithm, OSCORE has to observe limits for the 'q' and 'v' values, throughout the lifetime of the used AEAD keys.

Limits for 'q' and 'v' Formulas for calculating the security levels, as Integrity Advantage (IA) and Confidentiality Advantage (CA) probabilities, are presented in . These formulas take as input specific values for 'q' and 'v' (see ) and for 'l', i.e., the maximum length of each message (in cipher blocks). For the algorithms shown in that can be used as AEAD Algorithm for OSCORE, the main property to achieve is having IA and CA values which are no larger than p = 2^-64, which will ensure a safe security level for the AEAD Algorithm. This can be achieved by using the values q = 2^20, v = 2^20, and l = 2^10, that this document recommends using for these algorithms. also shows the resulting IA and CA probabilities enjoyed by the considered algorithms, when taking the value of 'q', 'v' and 'l' above as input to the formulas defined in .

Probabilities for algorithms based on chosen q, v and l values. When AEAD_AES_128_CCM_8 is used as AEAD Algorithm for OSCORE, the triplet (q, v, l) considered above yields larger values of IA and CA. Hence, specifically for AEAD_AES_128_CCM_8, this document recommends using the triplet (q, v, l) = (2^20, 2^14, 2^8). This is appropriate, since the resulting CA and IA values are not greater than the threshold value of 2^-50 defined in , and thus yields an acceptable security level. Achieving smaller values of CA and IA would require inconveniently reducing 'q', 'v' or 'l', with no additional security benefit since the threshold is already met, as further elaborated in .

Maximum length of each message (in bytes) With regards to the limit for 'l', the recommended 'l' value for the algorithms shown in , and for AEAD_AES_128_CCM_8, is 2^10 (16384 bytes) and 2^8 (4096 bytes) respectively. Considering a typical MTU size of 1500 bytes, and the fact that the maximum block size when using block-wise transfers with CoAP is 1024 bytes (see ), it is unlikely that a larger size of 'l' than what is recommended makes sense to use in typical network setups. However, although under typical circumstances an 'l' limit of 2^8 (4096 bytes) is acceptable, exceptional cases can warrant a higher value of 'l'. For instance, Block-wise Extension for Reliable Transport (BERT) extends the CoAP Block-Wise transfer functionality, enabling use of larger messages over reliable transports such as TCP or WebSockets (see ). In case the OSCORE peers wish to take full advantage of BERT functionality and the large message sizes it allows for, the OSCORE peers must use higher values of 'l'. The maximum length of each message in bytes for different values of 'l' and different AEAD algorithms is shown in . An alternative means of allowing for larger values of 'l', while still maintaining the security properties of the used AEAD algorithm, is to adjust the 'q' and 'v' values to compensate. In practice, this means reducing the value of 'q' and 'v' considering the new value of 'l', to ensure an acceptably low value of the IA and CA probabilities. A reasonable target for the IA and CA probability values is the threshold value of 2^-50 defined in .

Additional Information in the Security Context In addition to what is defined in , the following parameters associated with an OSCORE Security Context can be used for keeping track of the expiration of that OSCORE Security Context and maintaining key usage below safe limits.

Common Context The Common Context has the following associated parameter.

'exp': with value the expiration time of the OSCORE Security Context, as a non-negative integer. The parameter contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in . At the time indicated by this parameter, a peer must stop using this Security Context to process any incoming or outgoing messages, and is required to establish a new Security Context to continue OSCORE-protected communications with the other peer. That is, the expiration of an OSCORE Security Context means that the current Sender Key must no longer be used for protecting outgoing messages, and the Recipient Key must no longer to decrypt and verify incoming messages. The value of 'exp' must be set upon installing the OSCORE Security Context, namely at time t_1, considering a lifetime value t_l. In particular, t_l can be a default value (potentially differing between the two peers sharing the OSCORE Security Context), or can be agreed by the two peers during the establishment of the OSCORE Security Context. For instance, this value may be stored and/or transported in the OSCORE LwM2M object , or specified as part of an EDHOC Application Profile used when executing EDHOC to establish the OSCORE Security Context. Regardless of how the lifetime value is determined, the 'exp' parameter is set to indicate the point in time corresponding to t_1 offset by t_l.

Sender Context The Sender Context has the following associated parameters.

'count_q': a non-negative integer counter, keeping track of the current 'q' value for the Sender Key. At any time, 'count_q' has as value the number of messages that have been encrypted using the Sender Key. The value of 'count_q' is set to 0 when establishing the Sender Context.
'limit_q': a non-negative integer, which specifies the highest value that 'count_q' is allowed to reach, before stopping using the Sender Key to process outgoing messages. The value of 'limit_q' depends on the AEAD algorithm specified in the Common Context, considering the properties of that algorithm. The value of 'limit_q' is determined according to .

Note for implementers: it is possible to avoid storing and maintaining the counter 'count_q'. Rather, an estimated value to be compared against 'limit_q' can be computed, by leveraging the Sender Sequence Number (SSN) of the peer and (an estimate of) the other peer's SSN. A possible method to achieve this is described in . While this relieves peers from storing and maintaining the precise 'count_q' value, it results in overestimating the number of encryptions performed with a Sender Key. This in turn results in approaching 'limit_q' sooner and thus in performing a key update procedure more frequently.

Recipient Context The Recipient Context has the following associated parameters.

'count_v': a non-negative integer counter, keeping track of the current 'v' value for the Recipient Key. At any time, 'count_v' has as value the number of failed decryptions that have occurred for incoming messages using the Recipient Key. The value of 'count_v' is set to 0 when establishing the Recipient Context.
'limit_v': a non-negative integer, which specifies the highest value that 'count_v' is allowed to reach, before stopping using the Recipient Key to process incoming messages. The value of 'limit_v' depends on the AEAD algorithm specified in the Common Context, considering the properties of that algorithm. The value of 'limit_v' is determined according to .

OSCORE Message Processing To keep track of the 'q' and 'v' values and ensure that AEAD keys are not used beyond reaching their limits, OSCORE peers protect messages with OSCORE as defined in this section. A limitation that is introduced is that, in order to not exceed the selected value for 'l', the total size of the COSE plaintext , authentication tag, and possible ciphertext padding for a message must not exceed the block size for the selected algorithm multiplied by 'l'. The size of the COSE plaintext is calculated as described in . If OSCORE peers need to transmit messages exceeding the maximum recommended size calculated from 'l', CoAP Block-Wise transfers may be used to split content into smaller segments. The following steps can be adopted by a client or server to determine whether the usage of block-wise transfer is necessary for the transmission of a specific OSCORE protected message.

The CoAP message to transmit is first produced.
The sum of the total size of the COSE plaintext, the length of the authentication tag, and the length of any potential ciphertext padding should be computed to produce a value T. It should be noted that the size of the padding and the length of the authentication tag depend on the used AEAD algorithm.
If the value of T exceeds the 'l' value for the used AEAD algorithm, block-wise transfer is to be used with the CoAP message before protecting it with OSCORE.

The processing of CoAP messages with OSCORE follows the steps outlined in , with the additions defined below.

Protecting a Request or a Response Before encrypting the COSE object using the Sender Key, the 'count_q' counter is incremented. If 'count_q' exceeds the 'limit_q' limit, the message processing is aborted. From then on, the Sender Key must not be used to encrypt further messages.

Verifying a Request or a Response If an incoming message is detected to be a replay (see ), the 'count_v' counter is not incremented. If the decryption and verification of the COSE object using the Recipient Key fails, the 'count_v' counter is incremented. After 'count_v' has exceeded the 'limit_v' limit, incoming messages must not be decrypted and verified using the Recipient Key, and their processing must be aborted.