Implementation Guidance for the PKCS #1 RSA Cryptography Specification
draftkariorsaguidance00
This document is an InternetDraft (ID).
Anyone may submit an ID to the IETF.
This ID is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document  Type 
This is an older version of an InternetDraft whose latest revision state is "Replaced".



Author  Alicja Kario  
Last updated  20231010  
Replaced by  draftirtfcfrgrsaguidance  
RFC stream  (None)  
Formats  
Stream  Stream state  (No stream defined)  
Consensus boilerplate  Unknown  
RFC Editor Note  (None)  
IESG  IESG state  ID Exists  
Telechat date  (None)  
Responsible AD  (None)  
Send notices to  (None) 
draftkariorsaguidance00
Internet Engineering Task Force H. Kario, Ed. InternetDraft Red Hat, Inc. Updates: 8017 (if approved) 9 October 2023 Intended status: Informational Expires: 11 April 2024 Implementation Guidance for the PKCS #1 RSA Cryptography Specification draftkariorsaguidance00 Abstract This document specifies additions and amendments to RFC 8017. Specifically, it provides guidence to implementers of the standard to protect against sidechannel attacks. It also deprecates the PKCS #1 v1.5 encryption padding, but provides an alternative depadding algorithm that protects against sidechannel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. Status of This Memo This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79. InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current Internet Drafts is at https://datatracker.ietf.org/drafts/current/. InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as "work in progress." This InternetDraft will expire on 11 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Kario Expires 11 April 2024 [Page 1] InternetDraft RSA Implementation Guidance October 2023 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 4. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Side channel attacks . . . . . . . . . . . . . . . . . . . . 3 6. General recommendations . . . . . . . . . . . . . . . . . . . 4 7. Sidechannel free modular exponentiation . . . . . . . . . . 4 7.1. General recommendations . . . . . . . . . . . . . . . . . 5 7.2. Montgomery ladder . . . . . . . . . . . . . . . . . . . . 5 7.3. Montgomery reduction in multiplication . . . . . . . . . 5 8. Base blinding . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Exponent blinding . . . . . . . . . . . . . . . . . . . . . . 6 10. Depadding . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. IRPRF . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.2. Implicit rejection . . . . . . . . . . . . . . . . . . . 7 11. Deprecated Algorithms . . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 13. Security Considerations . . . . . . . . . . . . . . . . . . . 10 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 14.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 A.1. 2048 bit key . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The PKCS #1 [RFC8017] specification describes the RSA cryptosystem, providing guidance on implementing encryption schemes and signature schemes. Unfortunately, typical uses of RSA encryption schemes leave it vulnerable to sidechannel attacks. Protections against them are not documented there, and attacks are mentioned only in passing. Kario Expires 11 April 2024 [Page 2] InternetDraft RSA Implementation Guidance October 2023 2. Rationale The PKCS #1 v1.5 padding is known to be problematic since 1998, when Daniel Bleichenbacher published his attack. Sidechannel attacks against public key implementations, including RSA, are known to be possible since 1996 thanks to work by Paul Kocher. Despite those results, sidechannel attacks against RSA implementations have proliferated for the next 25 years. We thus provide guidance how to implement those algorithms in a way that should be secure against at least the simple timing side channel attacks. 3. Requirements Language 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 RFC 2119 [RFC2119]. 4. Notation In this document we reuse the notation from RFC 8017, in addition, we define the following: AL alternative message length, nonnegative integer, 0 <= AL <= k  11 AM alternative encoded message, an octet string D octet string representation of d DH an octet string of a SHA256 hash of D KDK an octet string containg a Key Derivation Key for a specific ciphertext C l length in octets of the message M 5. Side channel attacks Cryptographic implementations may provide a lot of indirect signals to the attacker that includes information about the secret processed data. Depending on type of information, those leaks can be used to decrypt data or retrieve private keys. Most common sidechannels that leak information about secret data are: 1. Different errors returned Kario Expires 11 April 2024 [Page 3] InternetDraft RSA Implementation Guidance October 2023 2. Different processing times of operations 3. Different patterns of jump instructions and memory accesses 4. Use of hardware instructions that take different amount time to execute depending on operands or result Some of those leaks may be detectable over the network, while others may require closer access to the attacked system. With closer access, the attacker may be able to measure power usage, electromagnetic emanations, or sounds and correlate them with specific bits of secret information. Recent research into network based side channel detection has shown that even very small side channels (of just few clock cycles) can be reliably detected over the network. The detectability depends on the sample size the attacker is able to collect, not on size of the side channel. 6. General recommendations As a general rule, all operations that process secret information (be it parts of the private key or parts of encrypted message) MUST be performed with code that doesn't have secret data dependent branch instructions, secret data dependent memory accesses, or uses non constant time machine instructions (which ones are those if architecture dependant, but division is commonly nonconstant time). Special care should be placed around the code that handles the conversion of the numerical representation to the octet string representation in RSA decryption operations. All operations that use private keys SHOULD additionally employ both base blinding and exponent blinding as protections against leaks inside modular exponentiation code. 7. Sidechannel free modular exponentiation The underlying modular exponentiation algorithm MUST be constant time with regards to the exponent in all uses of the private key. For private key decryption the modular exponentiation algorithm MUST be constant time with regards to the output of the exponentiation. In case the Chinese remainder theorem optimisation is used the modular exponentiation algorithm must also be constant time with regards to the used moduli. Kario Expires 11 April 2024 [Page 4] InternetDraft RSA Implementation Guidance October 2023 7.1. General recommendations It's especially important to make sure that all values that are secret to the attacker are stored in memory buffers that have sizes determined by the public modulus. For example, the private exponenents should be stored in memory buffers that have sizes determined by the public modulus value, not the numerical values of the exponents themselves. Similarly, the size of the output buffer for multiplication should always be equal to the sum of buffer sizes of multiplicands. The output size of the modular reduction operation should similarly be equal to the size of the modulus and not depend on bit size of the output. 7.2. Montgomery ladder For the modular exponentiation algorithm to be sidechannel free every step of the calculation MUST NOT depend on the bits of the exponent. In particular, use of simple square and multiply algorithm will leak information about bits of the exponent through lack of multiplication operation in individual exponentiation steps. The recommended workaround against it, is the use of the Montgomery ladder construction. While that approach ensures that both the square and multiply operations are performed, the fact that the results of them are placed in different memory locations based on bits of the secret exponent will provide enough information for an attacker to recover the bits of the exponent. To counteract it, the implementation should ensure that both memory locations are accessed and updated on every step. 7.3. Montgomery reduction in multiplication As multiplication operations quickly make the intermediate values in modular exponentiation large, performing a modular reduction after every multiplication or squaring operation is a common optimisation. To further optimise the modular reduction, the Montgomery modular multiplication is used for performing the combined multiplyand reduce operation. The last step of that operation is conditional on the value of the output. A sidechannel free implementation should perfom the subtraction in all cases and then copy the result or the first operand of the subtraction based on sign of the result of the subtraction. Kario Expires 11 April 2024 [Page 5] InternetDraft RSA Implementation Guidance October 2023 8. Base blinding As protection against multiple attacks, it's RECOMMENDED to perform all operations involving the private key with the use of blinding. It should be noted that for decryption operations the unblinding operation MUST be performed using sidechannel free code that does not leak information about the result of this multiplication and reduction modulo operation. «describe the base blinding use» Unless the multiplication and reduction modulo operations are verified to be sidechannel free, it's RECOMMENDED to generate a completely new blinding parameters every few hundred private key operations. 9. Exponent blinding To further protect against private key leaks, it's RECOMMENDED to perform the blinding of the used exponents. «describe the exponent blinding algorithm here» 10. Depadding In case of RSAOAEP, the padding is selfverifying, thus the depadding operation needs to follow the standard algorithm to provide a safe API to users. It MUST ignore the value of the very fist octet of padding and process the remaining bytes as if it was equal zero. The PKCS #1 v1.5 padding is considered deprecated, and should be used only to process legacy data. It MUST NOT be used as part of online protocols or API endpoints. 10.1. IRPRF For the calculation of the random message for implicit rejection we define a PseudoRandom Function (PRF) as follows: IRPRF( KDK, label, length ) Input: KDK the key derivation key Kario Expires 11 April 2024 [Page 6] InternetDraft RSA Implementation Guidance October 2023 label a label making the output unique for a given KDK length requested length of output in octets Output: derived key, an octet string Steps: 1. If KDK is not 32 octets long, or if length is larger than 8192 return error and stop. 2. The returned value is created by concatenation of subsequent calls to a SHA256 HMAC function with the KDK as the HMAC key and following octet string as the message: P_i = I  label  bitLength 3. Where the I is an iterator value encoded as two octet long big endian integer, label is the passed in label, and bitLength is the length times 8 (to represent number of bits of output) encoded as two octet big endian integer. The iterator is initialised to 0 on first call, and then incremented by 1 for every subsequent HMAC call. 4. The HMAC is iterated until the concatenated output is shorter than length 5. The output is the length leftmost octets of the concatenated HMAC output 10.2. Implicit rejection For implementations that cannot remove support for the PKCS #1 v1.5 padding nor provide a usagespecific API, it's possible to implement an implicit rejection algorithm as a protection measure. It should be noted that implementing it is hard, thus it's RECOMMENDED instead to disable support for PKCS #1 v1.5 padding instead. To implement implicit rejection, the RSAESPKCS1V1_5DECRYPT from section 7.2.2 of RFC 8017 needs to be implemented as follows: 1. Length checking: If the length of the ciphertext C is not k octets (or if k < 11), output "decryption error" and stop. 2. RSA decryption: a. Convert the ciphertext C to an integer ciphertext representative c: Kario Expires 11 April 2024 [Page 7] InternetDraft RSA Implementation Guidance October 2023 c = OS2IP (C). b. Apply the RSADP decryption primitive to the RSA private key (n, d) and the ciphertext representative c to produce an integer message representative m: m = RSADP ((n, d), c). Note: the RSADP MUST be constanttime with respect of message m. If RSADP outputs "ciphertext representative out of range" (meaning that c >= n), output "decryption error" and stop. c. Convert the message representative m to an encoded message EM of length k octets: EM = I2OSP (m, k). Note: I2OSP MUST be constanttime with respect of m. 3. Derivation of alternative message 1. Derive the Key Derivation Key (KDK) a. Convert the private expoent d to a string of length k octets: D = I2OSP (d, k). b. Hash the private exponent using the SHA256 algorithm: DH = SHA256 (D). Note: This value MAY be cached between the decryption operations, but MUST be considered privatekey equivalent. c. Use the DH as the SHA256 HMAC key and the provided ciphertext C as the message. If the ciphertext C is not k octets long, it MUST be left padded with octets of value zero. KDK = HMAC (DH, C, SHA256). 2. Create the candidate lengths and the random message Kario Expires 11 April 2024 [Page 8] InternetDraft RSA Implementation Guidance October 2023 a. Use the IRPRF with key KDK, "length" as six octet label encoded with UTF8, to generate 256 octet output. Interpret this output as 128 two octet long bigendian numbers. CL = IRPRF (KDK, "length", 256). b. Use the IRPRF with key KDK, "message" as a seven octet label encoded with UTF8 to generate k octet long output to be used as the alternative message: AM = IRPRF (KDK, "message", k). 3. Select the alternative length for the alternative message. Note: this must be performed in sidechannel free way. a. Iterate over the 128 candidate CL lengths. For each zero out high order bits so that they have the same bit length as the maximum valid message size (k  11). b. Select the last length that's not larger than k  11, use 0 if none are. Save it as AL. 4. EMEPKCS1v1_5 decoding: Separate the encoded message EM into an octet string PS consisting of nonzero octets and a message M as EM = 0x00  0x02  PS  0x00  M. If the first octet of EM does not have hexadecimal value 0x00, if the second octet of EM does not have hexadecimal value 0x02, if there is no octet with hexadecimal value 0x00 to separate PS from M, or if the length of PS is less than 8 octets, the check variable must remember if any of those checks failed. Irrespective of the check variable value, the code should also return length of message M: L. If there is no octet with hexadecimal value 0x00 to separate PS from M, then L should equal 0. Note: All those checks MUST be performed irrespective if previous checks failed or not. A common technique for that is to have a check variable that is ORed with the results of subsequent checks. 5. Decision which message to return: in case the check variable is set, the code should return the last AL octets of AM, in case the check variable is unset the code should return the last L octets of EM. Kario Expires 11 April 2024 [Page 9] InternetDraft RSA Implementation Guidance October 2023 Note: The decision which length to use MUST be performed in side channel free manner. While the length of the returned message is not considered sensitive, the read memory location is. As such, when returning message M both EM and AM memory locations MUST be read. 11. Deprecated Algorithms Current protocols deployments MUST NOT use encryption with RSA PKCS #1 v1.5 padding. Support for RSA PKCS #1 v1.5 SHOULD be disabled in default configuration of any implementation of RSA cryptosystem. All new protocols MUST NOT specify PKCS #1 v1.5 as a valid encryption padding for RSA keys. 12. IANA Considerations This memo includes no request to IANA. 13. Security Considerations This whole document specifies security considerations for RSA implementations. 14. References 14.1. Normative References [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfceditor.org/info/rfc8017>. 14.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfceditor.org/info/rfc2119>. Appendix A. Test Vectors A.1. 2048 bit key «provide test vectors here» Author's Address Kario Expires 11 April 2024 [Page 10] InternetDraft RSA Implementation Guidance October 2023 Hubert Kario (editor) Red Hat, Inc. Purkynova 115 61200 Brno Czech Republic Email: hkario@redhat.com Kario Expires 11 April 2024 [Page 11]