FIPS-Approved Cryptography#
In FIPS mode, the Curity Identity Server permits only FIPS-approved algorithms. Non-approved algorithms are rejected when configuration is applied. This page summarizes what is approved in each area.
Keystores and trust#
The default keystore format is the FIPS keystore format (BCFKS) in place of PKCS#12, and the JVM trust store is a BCFKS conversion of the standard CA certificates. PKCS#12 keystores are not permitted. See Importing FIPS-compliant keystores for the supported formats and how to convert an existing keystore.
Password hashing#
The Curity Identity Server supports the Password-Based Key Derivation Function 2 (PBKDF2) and SHA-2 based SHA-crypt algorithms for hashing credentials in FIPS mode. The bcrypt and phpass algorithms are not FIPS-approved and are rejected — both when a credential manager is configured and, as a safeguard, if such a hash is ever computed at runtime.
Because bcrypt and phpass are unavailable, credentials hashed with those algorithms in a non-FIPS deployment cannot be verified in FIPS mode. Provision credentials using an approved algorithm such as PBKDF2. See Credential Managers .
Keys and signatures#
Keys used for active operations — signing, encryption, and TLS — must be approved: RSA keys of at least 2048 bits, elliptic-curve keys on the NIST P-256, P-384, or P-521 curves, and EdDSA keys using Ed25519 or Ed448. DSA keys and RSA keys smaller than 2048 bits are not permitted.
Keys used only to verify existing signatures, and certificates used as trust anchors, are validated more leniently, in line with the FIPS treatment of signature verification as a legacy operation. This allows the server to continue verifying signatures produced elsewhere with older keys.
In FIPS mode, the same RSA key cannot be used for both signing and encryption. The validated module enforces a single purpose per key, so configure separate RSA keys where a key is needed for each purpose — for example, one key for token signing and a different key for token encryption.
Transport Layer Security#
Only TLS 1.2 and TLS 1.3 are permitted, and configured cipher suites must all be FIPS-approved. TLS 1.0 and TLS 1.1 are rejected. See Transport Layer Security for the general TLS configuration model.
Token encryption#
For JSON Web Encryption (JWE), the RSA-OAEP and RSA-OAEP-256 key-management algorithms are approved. The legacy RSA1_5 algorithm is not permitted.
Certificate thumbprints#
Where a certificate thumbprint is used as a claim, the SHA-256 thumbprint (x5t#S256) must be used. The SHA-1 thumbprint (x5t) is not permitted.
Summary#
| Area | Approved | Not approved |
|---|---|---|
| Keystores | BCFKS | PKCS#12 |
| Password hashing | PBKDF2, SHA-2 based SHA-crypt | bcrypt, phpass |
| Signing and encryption keys | RSA ≥ 2048, EC P-256/P-384/P-521, EdDSA (Ed25519, Ed448) | DSA, RSA < 2048 |
| Transport Layer Security | TLS 1.2, TLS 1.3, approved cipher suites | TLS 1.0, TLS 1.1 |
| Token encryption (JWE) | RSA-OAEP, RSA-OAEP-256 | RSA1_5 |
| Certificate thumbprint claims | x5t#S256 (SHA-256) | x5t (SHA-1) |