[cryptolib] Algorithms for considered for hardening review

[moidx]

Hardened implementations

• RSA encrypt/decrypt with the following padding schemes: OAEP, PKCS#1 v1.5
• RSA signature with the following padding schemes: PSS, PKCS#1 v1.5.
• ECC keygen suitable for ECDSA and ECDH. Supported curves: NIST P-256, NIST P-384 and X25519.
• ECDSA sign/verify operations. Supported curves: NIST P-256 and NIST P-384
• ECDH key exchange functionality as described in the security target. Supported curves: NIST P-256, NIST P-384 and X25519.
• EdDSA sign/verify operations. Supported curve: Ed25519.
• AES encrypt/decrypt/MAC operations. Modes of operation: CBC, ECB, GCM, and CTR. Key sizes: 128, 192 and 256 bits
• SHA3, cSHAKE, KMAC Modes of operation: Hash, extendable-hash, KMAC. Key sizes: as supported by hardware.

Hardening level to be discussed

The level of hardening for the following algorithms needs to be discussed. Otherwise the algorithms are also expected to be part of the release.

• SHA2 Modes of operation: SHA2-256, SHA2-384, SHA2-512.
• HMAC Key sizes: 256, 384.

Other software implementations

The following algorithms are not supported by the OpenTitan community, but are presented for consideration as a cryptolib extension to fulfill mobile integration requirements (i.e. Android Strongbox). Hardening guarantees will be defined as part of the development process if the algorithms proceed to the implementation stage.

• SHA1 Hash and as building block in HMAC.
• TDES encrypt/decrypt operations. Padding: PKCS#7, CBC, ECB. Key sizes: 192, 168.

[nasahlpa]

Note on development goals and status for cryptolib development and hardening

Development goals / scope

For the algorithms listed in #27051, the development goals are:

• Complete their implementation.
• Functionally verify them using test vectors.
• Harden the cryptographic implementations to withstand the published OpenTitan threat model (see Lightweight Threat Model - OpenTitan Documentation). A similar threat model must be satisfied by evaluation targets in Common Criteria certifications when targeting AVA_VAN.5 as part of compliance to e.g. protection profiles PP-0084 or PP-0117. Such targets withstand attacks from attackers with ‘attack potential high’ as described in Application of Attack Potential to Smartcards and Similar Devices.
• Support FIPS compliance, i.e. passing CAVP testing for the algorithms. KAT for CMVP can be added on top of the cryptolib.
• Avoid changes to the cryptolib API (API Documentation - OpenTitan Documentation) unless required to achieve the above goals.
• Minimize penalty on code size and execution time to achieve the above goals. Generally, it can be expected that hardened implementations have higher runtimes and code size than unhardened implementations. Estimate or measure impacts where possible.

Current state of hardening

The following algorithms are hardened against side-channel and fault injection attacks:

• AES encrypt/decrypt/MAC operations. Modes of operation: CBC, ECB, and CTR. Key sizes: 128, 192 and 256 bits.
• ECC keygen suitable for ECDSA and ECDH. Supported curves: NIST P-256 and NIST P-384.
• ECDSA sign/verify operations. Supported curves: NIST P-256 and NIST P-384.
• ECDH key exchange functionality as described in the security target. Supported curves: NIST P-256 and NIST P-384.
• HMAC Key sizes: 256, 384.
• RSA encrypt/decrypt. Padding schemes: OAEP. Key sizes: 2048, 3072, 4096 bits.
• RSA signature. Padding schemes: PSS, PKCS#1 v1.5. Key sizes: 2048, 3072, 4096 bits.
• RSA keygen. Key sizes: 2048, 3072, 4096 bits.

The used hardening techniques are detailed in the documentation.

Current state of functional verification

The OpenTitan Cryptotest framework currently conducts the following tests, which are kept passing:

• Aes
• Aes-GCM
• Cshake
• Drbg
• Ecdh
• Ecdsa
• Hmac_sha256
• Hmac_sha384
• Hmac_sha512
• Kmac
• Sha256
• Sha384
• Sha3_224
• Sha3_256
• Sha3_384
• Sha3_512
• Sha512
• Shake128
• Shake256
• Sphincsplus

Currently identified opens in functional development

• RSA testing via the cryptotest framework
• ECDSA requires additional API function for FIPS compliance
  • As described in #27690.
• Complete ECC keygen for curves X25519 and Ed25519
• Complete EdDSA sign/verify operations for curve Ed25519
• Complete ECDH key exchange functionality for curve X25519
• Unify ROM and user space drivers for cryptographic operations

Currently identified opens for hardening

• AES-GCM encrypt/decrypt operations. Key sizes: 128, 192 and 256 bits.
  • Completed once #28485 and #28135 has been merged.
• Hardening for X25519 and Ed25519 ECC implementations
• Hardening for SHA3, cSHAKE, and KMAC.

Contributions to address these opens are welcome. The opens are/will be registered as issues and assigned to cryptolib milestones.