Reference Guide

36 Secure Operation of Crypto-C ME
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1
with Level 2 Roles, Services and Authentication
• The KDF is performed in the context of the TLS protocol
• HMAC is as specified in FIPS 198-1
• P_HASH uses either SHA-256, SHA-384 or SHA-512.
For more information, see SP 800-135 Rev. 1.
The TLS protocols have not been tested by the CAVP and CMVP.
• MAC:
– The key length for an HMAC generation or verification must be equal to or
greater than 112 bits.
– For HMAC verification, a key length greater than or equal to 80 and less than
112 is allowed for legacy-use.
• Random Bit Generator:
– Only FIPS 140-2 Approved DRBGs may be used for generation of keys,
asymmetric and symmetric.
– When using an approved DRBG, the number of bits of entropy input must be
equivalent to or greater than the security strength of the keys the caller wishes
to generate. For example, a 256-bit or higher entropy input when generating
256-bit AES keys.
– When using an Approved DRBG to generate keys or FFC domain parameters,
the requested security strength of the DRBG must be at least as great as the
security strength of the key or domain parameters being generated. That
means that an Approved DRBG with an appropriate strength must be used.
For more information about requesting the DRBG security strength, see the
API Reference Information > Pseudo-random Number Generation
section in the RSA BSAFE Crypto-C Micro Edition Developers Guide.
For further information, see Table 3: Hash functions that can be used to
provide the targeted security strengths in SP 800-57 Part 1 Rev. 4.
– As the module does not modify the output of an Approved DRBG, any
generated symmetric keys or seed values are created directly from the output
of the Approved DRBG.
• Symmetric Cipher:
– When using GCM feedback mode for symmetric encryption, the
authentication tag length and authenticated data length may be specified as
input parameters, but the IV must not be specified. It must be generated
internally. IV generation operates in one of two ways:
• In regular use, the generated IV is fully random, generated by an
approved PRNG, with a default length of 96 bits. No special
considerations are required provided the system has sufficient entropy.
• When used for TLS 1.2 protocol GCM cipher suites, as in RFC 5288, the
four-byte salt derived from the TLS handshake process must be input
using the identifier
R_CR_INFO_ID_CIPHER_PARTIAL_IV during
cipher initialization. This is used as the first four bytes of IV. The
remaining eight bytes of IV, referred to as
nonce_explicit in