Modalità FIPS

sgcCrypto dispone di un'opzione di compilazione facoltativa, SGC_CRYPTO_FIPS, che lascia nella libreria solo gli algoritmi approvati FIPS. È pensata per i progetti che non devono utilizzare algoritmi al di fuori delle pubblicazioni FIPS e NIST SP. Questa pagina spiega cosa fa l'opzione, come attivarla, cosa mantiene, cosa rimuove e cosa non copre.

Cosa significa FIPS in questo contesto

FIPS 140-3 è una certificazione di un modulo crittografico, non di un algoritmo. Un laboratorio accreditato testa una specifica build di un prodotto nell'ambito del Cryptographic Module Validation Program (CMVP) di NIST, e NIST pubblica un certificato per quella build. Utilizzare un algoritmo approvato come AES non rende validato un programma.

sgcCrypto non è un modulo validato FIPS 140-3, e attivare l'opzione non costituisce una dichiarazione di validazione. Ciò che l'opzione fa è più limitato:

Rimuove ogni algoritmo non approvato FIPS, in modo che nessuno di essi possa essere compilato nella propria applicazione.
Impone alcune regole sui parametri in fase di esecuzione, ad esempio una dimensione minima della chiave RSA per la firma.

Gli algoritmi che restano seguono le pubblicazioni FIPS e NIST SP elencate nella tabella seguente.

Se il progetto ha un requisito formale FIPS 140-3, la sua crittografia deve passare attraverso un modulo validato, ad esempio Windows CNG con il sistema in esecuzione in modalità FIPS. L'opzione aiuta a tenere fuori dal codice gli algoritmi non approvati. Non sostituisce un modulo validato.

Attivazione dell'opzione

L'opzione è disattivata per impostazione predefinita. Senza di essa non cambia nulla, e ogni algoritmo elencato nella pagina Crittografia è disponibile. Per attivarla, eseguire una delle seguenti operazioni:

Aprire sgcVer.inc e cambiare {.$DEFINE SGC_CRYPTO_FIPS} in {$DEFINE SGC_CRYPTO_FIPS}.
Aggiungere SGC_CRYPTO_FIPS alle direttive condizionali del progetto quando si compilano i sorgenti di sgcWebSockets.


  {.$DEFINE SGC_CRYPTO_FIPS}   { off, the default }
  {$DEFINE SGC_CRYPTO_FIPS}    { on }

Quindi ricompilare. L'opzione influisce solo sul codice compilato con la direttiva, quindi i pacchetti precompilati generati senza di essa non ne sono interessati.

Con l'opzione attivata, le funzioni rimosse non esistono più. Il codice che ne chiama ancora una non viene compilato e produce l'errore "Undeclared identifier". È una scelta voluta: nulla di non approvato può finire per errore nel binario, e il compilatore indica ogni punto che richiede un algoritmo diverso.

Cosa resta

Restano disponibili anche i certificati, le password monouso e le funzioni di codifica, perché sono costruiti unicamente con gli algoritmi approvati oppure non sono affatto algoritmi crittografici.

Famiglia	Algoritmi mantenuti	Standard
AES	AES-128/192/256 in modalità ECB, CBC, CFB, OFB, CTR, CTS, GCM e CCM, AES Key Wrap (KW e KWP), AES-CMAC e AES-GMAC	FIPS 197, SP 800-38A/B/C/D/F
Hashing	SHA-1 (solo dove è ancora consentito, mai per nuove firme), SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224/256/384/512, SHAKE128, SHAKE256, cSHAKE e KMAC	FIPS 180-4, FIPS 202, SP 800-185
Autenticazione dei messaggi	HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512	FIPS 198-1
Derivazione delle chiavi	PBKDF2, HKDF e la KDF ANSI X9.63	SP 800-132 (PBKDF2), SP 800-56C (HKDF), SP 800-135 (ANSI X9.63 KDF)
RSA	Generazione delle chiavi RSA, firme PKCS#1 v1.5 e PSS, cifratura RSA-OAEP	FIPS 186-5, SP 800-56B
ECDSA ed ECDH	Firme e key agreement su NIST P-256, P-384 e P-521 (P-224 non è implementata da sgcCrypto)	FIPS 186-5, SP 800-56A
EdDSA	Firme Ed25519 ed Ed448	FIPS 186-5
Crittografia post-quantistica	ML-KEM, ML-DSA e SLH-DSA	FIPS 203, FIPS 204, FIPS 205
Certificati e PKI	Parsing dei certificati X.509, verifica della catena e controlli CRL, e generazione di certificati o CSR firmati con gli algoritmi sopra elencati	RFC 5280, RFC 2986
Password monouso	HOTP e TOTP, basati su HMAC	RFC 4226, RFC 6238
Codifica e utilità	Codifica Hex, Base32 e Base64, confronto a tempo costante, azzeramento sicuro	RFC 4648

Cosa viene rimosso

Rimossi	Motivo
ChaCha20, XChaCha20, Salsa20, XSalsa20, Poly1305, ChaCha20-Poly1305 e XChaCha20-Poly1305	Non sono algoritmi NIST.
Scambio di chiavi X25519 e X448	Non sono approvati per il key agreement nella SP 800-56A.
L'ibrido X25519 + ML-KEM-768, ed ECIES	Entrambi sono costruiti su X25519.
secp256k1 e le curve Brainpool, e le firme Schnorr BIP-340	Non sono curve raccomandate da NIST, e BIP-340 non è uno schema di firma FIPS 186-5. La modalità FIPS mantiene solo le curve NIST P.
Argon2 e scrypt	Non sono funzioni NIST di derivazione delle chiavi da password.
BLAKE2b, BLAKE2s, SipHash e TLSH	Non sono algoritmi NIST.
MD4, MD5, HMAC-MD5, RIPEMD-160 e DES (l'unit sgcCrypto_Legacy)	Obsoleti, oppure mai approvati da NIST.
KDF1 e KDF2	Definite nella ISO 18033-2, non in una pubblicazione NIST. La KDF ANSI X9.63 resta disponibile.
Cifratura RSA PKCS#1 v1.5	Non consentita dalla SP 800-131A. Le firme PKCS#1 v1.5 restano disponibili.
WinZip AES (AE-1 e AE-2)	Non è un formato NIST.

Per la maggior parte degli algoritmi rimossi, un sostituto approvato si trova nella prima tabella: AES-GCM al posto di ChaCha20-Poly1305, ECDH su P-256 o P-384 al posto di X25519, PBKDF2 al posto di Argon2 o scrypt, SHA-256 o SHA-3 al posto di BLAKE2, e RSA-OAEP al posto della cifratura PKCS#1 v1.5.

Regole verificate in fase di esecuzione

Alcune regole dipendono dai valori passati a una funzione, quindi il compilatore non può imporle. Con l'opzione attivata, sgcCrypto le verifica durante l'esecuzione della funzione, e ciascuna solleva un'eccezione il cui messaggio inizia con sgcCrypto FIPS:

Creare una firma con SHA-1, con RSA o ECDSA, inclusa la firma di un certificato o di una CSR. La verifica di una firma SHA-1 esistente è ancora consentita.
Firmare con una chiave RSA di meno di 2048 bit.
La generazione delle chiavi RSA esegue i controlli aggiuntivi sulle chiavi previsti da FIPS 186-5 e un test di coerenza della coppia (pairwise consistency test) sulla nuova coppia di chiavi.
La generazione di una chiave EC da un seed richiede un seed più lungo di almeno 64 bit rispetto all'ordine della curva, ad esempio almeno 320 bit per P-256.
PBKDF2 con un salt più corto di 16 byte, oppure con una chiave derivata più corta di 14 byte.
AES-GCM con un IV vuoto.

Da dove provengono i byte casuali

Chiavi, nonce e salt richiedono byte casuali. sgcRandomBytes li legge sempre dal sistema operativo, in entrambe le modalità, e non vi sovrappone mai un proprio generatore. L'opzione cambia soltanto la sorgente di sistema utilizzata:

Piattaforma	Con SGC_CRYPTO_FIPS	Senza SGC_CRYPTO_FIPS
Windows	BCryptGenRandom (CNG, RNG preferito dal sistema), senza fallback	BCryptGenRandom, con fallback su RtlGenRandom e poi su CryptGenRandom quando BCryptGenRandom non è disponibile
Linux e Android	La chiamata di sistema getrandom	/dev/urandom
macOS e iOS	SecRandomCopyBytes del framework Security	/dev/urandom

In entrambe le modalità, se nessuna sorgente può essere letta, viene sollevata un'eccezione anziché restituire byte deboli. Il fatto che il generatore del sistema operativo sia considerato FIPS dipende dal sistema operativo e dalla sua configurazione, non da sgcCrypto.

Cosa non copre l'opzione

L'opzione si applica solo alle unit sgcCrypto. Altre parti di sgcWebSockets possono comunque utilizzare algoritmi non approvati:

MD5 nelle credenziali long-term di TURN, nella firma dell'API Pusher e nel vecchio handshake WebSocket hixie-76.
MD4 e DES nell'autenticazione NTLM.
Le cipher suite e lo scambio di chiavi che OpenSSL negozia per le connessioni TLS e QUIC, come ChaCha20-Poly1305 o X25519. Questi sono controllati dalla configurazione di OpenSSL, non da questa opzione.
Gli URL firmati di Amazon CloudFront, che per progettazione richiedono RSA con SHA-1. Sollevano un'eccezione quando l'opzione è attivata.

Se l'intera applicazione deve limitarsi agli algoritmi approvati, verificare anche queste aree.

Vedere anche