Condividi tramite

Raccomandazioni per la crittografia Microsoft SDL

  • Articolo

Usare queste informazioni come riferimento quando si progettano prodotti per usare le stesse API, algoritmi, protocolli e lunghezze di chiave richieste da Microsoft per i propri prodotti e servizi. Gran parte del contenuto si basa sugli standard di sicurezza interni di Microsoft usati per creare il ciclo di vita dello sviluppo della sicurezza.

Gli sviluppatori su piattaforme non Windows possono trarre vantaggio da queste raccomandazioni. Anche se i nomi delle API e delle librerie potrebbero essere diversi, le procedure consigliate che coinvolgono la scelta dell'algoritmo, la lunghezza delle chiavi e la protezione dei dati sono simili in tutte le piattaforme.

Raccomandazioni relative al protocollo di sicurezza, all'algoritmo e alla lunghezza delle chiavi

Versioni di TLS/SSL

I prodotti e i servizi devono usare versioni protette crittograficamente di TLS/SSL:

  • TLS 1.3 deve essere abilitato.
  • TLS 1.2 può essere abilitato per migliorare la compatibilità con i client meno recenti.
  • TLS 1.1, TLS 1.0, SSL 3 e SSL 2 devono essere disabilitati

Crittografie a blocchi simmetrici, modalità di crittografia e vettori di inizializzazione

Crittografie a blocchi

Per i prodotti che usano le crittografie a blocchi simmetriche:

  • È consigliabile usare Advanced Encryption Standard (AES).
  • Tutte le altre crittografie a blocchi, tra cui 3DES (Triple DES/TDEA) e RC4 devono essere sostituite se usate per la crittografia.

Per gli algoritmi di crittografia a blocchi simmetrici, è necessaria una lunghezza minima di chiave di 128 bit, ma è consigliabile supportare chiavi a 256 bit. L'unico algoritmo di crittografia a blocchi consigliato per il nuovo codice è AES (AES-128, AES-192 e AES-256 sono tutti accettabili, notando che AES-192 non dispone dell'ottimizzazione su alcuni processori).

Modalità di crittografia

Gli algoritmi simmetrici possono operare in varie modalità, la maggior parte dei quali collega le operazioni di crittografia su blocchi successivi di testo non crittografato e testo crittografato.

Le crittografie a blocchi simmetrici devono essere usate con una delle modalità di crittografia seguenti:

Alcune altre modalità di crittografia come quelle che seguono presentano insidie di implementazione che ne rendono più probabile l'uso errato. In particolare, è necessario evitare la modalità di funzionamento dell'Electronic Code Book (BCE). Il riutilizzo dello stesso vettore di inizializzazione (IV) con crittografie a blocchi in "modalità di crittografia di streaming", ad esempio CTR, potrebbe causare la rivelazione dei dati crittografati. È consigliabile verificare la sicurezza aggiuntiva se si usa una delle modalità seguenti:

  • Feedback di output (OFB)
  • Commenti e suggerimenti sulla crittografia ():Cipher Feedback ():Cipher Feedback ():Cipher
  • Contatore (CTR)
  • Altro elemento non presente nell'elenco "consigliato" precedente

Vettori di inizializzazione (IV)

Tutte le crittografie a blocchi simmetrici devono essere usate anche con un numero casuale crittograficamente sicuro come vettore di inizializzazione. I vettori di inizializzazione non devono mai essere un valore costante o predicabile. Vedere Generatori di numeri casuali per consigli sulla generazione di numeri casuali crittograficamente sicuri.

I vettori di inizializzazione non devono mai essere riutilizzati durante l'esecuzione di più operazioni di crittografia. Il riutilizzo può rivelare informazioni sui dati crittografati, in particolare quando si usano modalità di crittografia di streaming, ad esempio OUTPUT Feedback (OFB) o Counter (CTR).

Raccomandazioni di AES-GCM e AES-CCM

AES-GCM (Galois/Counter Mode) e AES-CCM (Counter with CBC-MAC) sono ampiamente usate modalità di crittografia autenticate. Combinano la riservatezza e la protezione dell'integrità, rendendoli utili per la comunicazione sicura. Tuttavia, la loro fragilità risiede nel riutilizzo nonce. Quando lo stesso nonce (vettore di inizializzazione) viene usato due volte, può causare conseguenze irreversibili.

È consigliabile seguire le linee guida nonce descritte in NIST SP 800-38D, Raccomandazione per le modalità di crittografia a blocchi: Galois/Counter Mode (GCM) e GMAC, prestando particolare attenzione alla sezione 8.3 relativa al numero massimo di chiamate.

Un'altra opzione verrebbe generata da chiavi AES-GCM/CCM univoche per ogni messaggio crittografato, limitando in modo efficace il numero massimo di chiamate a 1. Questo approccio è consigliato per crittografare i dati inattivi, in cui l'uso di un contatore o la verifica che sia possibile tenere traccia del numero massimo di chiamate per una determinata chiave sarebbe poco pratico.

Per crittografare i dati inattivi, è anche possibile prendere in considerazione l'uso di AES-CBC con un codice di autenticazione dei messaggi (MAC) come alternativa usando uno schema Encrypt-then-MAC, assicurandosi di usare chiavi separate per la crittografia e per il MAC.

Verifica dell'integrità

È un malinteso comune che la crittografia per impostazione predefinita fornisce sia la riservatezza che la garanzia di integrità. Molti algoritmi di crittografia non forniscono alcun controllo dell'integrità e potrebbero essere vulnerabili ad attacchi di manomissione. È necessario eseguire passaggi aggiuntivi per garantire l'integrità dei dati prima dell'invio e dopo la ricezione.

Se non è possibile usare un algoritmo di crittografia autenticato con dati associati (AEAD), ad esempio AES-GCM, un'alternativa consiste nel convalidare l'integrità con un codice mac (Message Authentication Code) usando uno schema Encrypt-then-MAC, assicurandosi di usare chiavi separate per la crittografia e per il MAC.

L'uso di una chiave separata per la crittografia e per mac è essenziale. Se non è possibile archiviare le due chiavi, un'alternativa valida consiste nel derivare due chiavi dalla chiave principale usando una funzione di derivazione della chiave appropriata (KDF), una per scopi di crittografia e una per MAC. Per altre informazioni, vedere SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions | CSRC (nist.gov).

Algoritmi asimmetrici, lunghezze delle chiavi e modalità di riempimento

RSA

  • RSA può essere usato per la crittografia, lo scambio di chiavi e le firme.
  • La crittografia RSA deve usare le modalità di riempimento OAEP o RSA-PSS.
  • Il codice esistente deve usare la modalità di riempimento PKCS #1 v1.5 solo per la compatibilità.
  • L'uso della spaziatura interna Null non è consigliato.
  • È consigliabile una lunghezza minima della chiave a 2048 bit, ma è consigliabile supportare una lunghezza della chiave a 3072 bit.

ECDSA ed ECDH

  • Gli scambi di chiavi basati su ECDH e le firme basate su ECDSA devono usare una delle tre curve approvate da NIST (P-256, P-384 o P521).
  • Il supporto per P-256 deve essere considerato il minimo, ma è consigliabile supportare P-384.

Integer Diffie-Hellman

  • >Lunghezza chiave = 2048 bit consigliato0
  • I parametri del gruppo devono essere un gruppo denominato noto (ad esempio, RFC 7919) o generato da una parte attendibile e autenticato prima dell'uso.

Durate chiave

  • Definire un cryptoperiod per tutte le chiavi.
    • Ad esempio: una chiave simmetrica per la crittografia dei dati, spesso definita chiave di crittografia dei dati o DEK, potrebbe avere un periodo di utilizzo massimo di due anni per la crittografia dei dati, noto anche come periodo di utilizzo dell'origine. È possibile definire che ha un periodo di utilizzo valido per la decrittografia per altri tre anni, noto anche come periodo di utilizzo del destinatario.
  • È necessario fornire un meccanismo o un processo per sostituire le chiavi per ottenere la durata attiva limitata. Dopo la fine della durata attiva, una chiave non deve essere usata per produrre nuovi dati (ad esempio, per la crittografia o la firma), ma potrebbe comunque essere usata per leggere i dati, ad esempio per la decrittografia o la verifica.

Generatori di numeri casuali

Tutti i prodotti e i servizi devono usare generatori di numeri casuali sicuri in modo crittografico quando è necessaria la casualità.

CNG

  • Usare BCryptGenRandom con il flag BCRYPT_U edizione Standard_SYSTEM_PREFERRED_RNG.

Win32/64

  • Il codice legacy può usare RtlGenRandom in modalità kernel.
  • Il nuovo codice deve usare BCryptGenRandom o CryptGenRandom.
  • La funzione C Rand_s() è consigliata anche (che in Windows chiama CryptGenRandom).
  • Rand_s() è una sostituzione sicura ed efficiente per Rand().
  • Rand() non deve essere usato per le applicazioni crittografiche.

.NET

PowerShell

App di Windows Store

Linux/macOS

  • Il /dev/urandom dispositivo fornisce una fonte crittograficamente avanzata di dati casuali, così come la chiamata di getrandom(2) sistema.

Librerie di crittografia supportate dalla piattaforma Windows

Nella piattaforma Windows, Microsoft consiglia di usare le API di crittografia integrate nel sistema operativo. In altre piattaforme, gli sviluppatori potrebbero scegliere di valutare librerie di crittografia nonpiattaforma da usare. In generale, le librerie di crittografia della piattaforma vengono aggiornate più frequentemente perché vengono fornite come parte di un sistema operativo anziché essere raggruppate con un'applicazione.

Qualsiasi decisione di utilizzo relativa alla piattaforma e alla crittografia nonpiattaforma deve essere guidata dai requisiti seguenti:

  • La libreria deve essere una versione attualmente supportata senza vulnerabilità di sicurezza note.
  • È necessario supportare i protocolli di sicurezza, gli algoritmi e le lunghezze delle chiavi più recenti.
  • (Facoltativo) La libreria deve essere in grado di supportare solo protocolli/algoritmi di sicurezza meno recenti per garantire la compatibilità con le versioni precedenti.

Codice nativo

  • Crypto Primitives: se la versione è in Windows, usare CNG, se possibile.
  • Verifica della firma del codice: WinVerifyTrust è l'API supportata per la verifica delle firme di codice nelle piattaforme Windows.
  • Convalida dei certificati (usata nella convalida dei certificati con restrizioni per la firma del codice o SSL/TLS/DTLS): API CAPI2; ad esempio CertGetCertificateChain e CertVerifyCertificateChainPolicy.

Codice gestito (.NET)

Funzioni di derivazione chiave

La derivazione della chiave è il processo di derivazione del materiale della chiave crittografica da un segreto condiviso o da una chiave crittografica esistente. I prodotti devono usare le funzioni di derivazione chiave consigliate. La derivazione di chiavi da password scelte dall'utente o l'hashing delle password per l'archiviazione in un sistema di autenticazione è un caso speciale non coperto da queste linee guida; gli sviluppatori devono consultare un esperto.

Gli standard seguenti specificano le funzioni KDF consigliate per l'uso:

  • NIST SP 800-108 (revisione 1): raccomandazione per la derivazione chiave tramite funzioni pseudorandome. In particolare, KDF in modalità contatore, con HMAC come funzione pseudorandoma
  • NIST SP 800-56A (revisione 3): raccomandazione per schemi di definizione delle chiavi pair-wise che usano la crittografia logaritmica discreta.

Per derivare chiavi da chiavi esistenti, usare l'API BCryptKeyDerivation con uno degli algoritmi:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM
  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Per derivare le chiavi da un segreto condiviso (l'output di un contratto di chiave), usare l'API BCryptDeriveKey con uno degli algoritmi seguenti:

  • BCRYPT_KDF_SP80056A_CONCAT
  • BCRYPT_KDF_HMAC

Convalida del certificato

I prodotti che usano TLS o DTLS devono verificare completamente i certificati X.509 delle entità a cui si connettono. Questo processo include la verifica delle parti seguenti del certificato:

  • Nome dominio.
  • Date di validità (date di inizio e scadenza).
  • Stato di revoca.
  • Utilizzo (ad esempio, "Autenticazione server" per i server, "Autenticazione client" per i client).
  • Catena di certificati. I certificati devono essere concatenati a un'autorità di certificazione radice attendibile dalla piattaforma o configurati in modo esplicito dall'amministratore.

Se uno di questi test di verifica ha esito negativo, il prodotto deve terminare la connessione con l'entità.

Non usare certificati autofirmato. L'autofirmato non trasmette intrinsecamente fiducia, revoca del supporto o supporto del rinnovo della chiave.

Funzioni hash crittografiche

I prodotti devono usare la famiglia di algoritmi hash SHA-2 (SHA-256, SHA-384 e SHA-512). Il troncamento degli hash crittografici per scopi di sicurezza a meno di 128 bit non è consentito. Sebbene l'utilizzo di SHA-256 sia il minimo, è consigliabile supportare SHA-384.

Algoritmi hash MAC/HMAC/con chiave

Un codice MAC è un'informazione allegata a un messaggio che consente ai destinatari di verificare sia l'autenticità del mittente che l'integrità del messaggio con una chiave privata.

È consigliabile usare mac (HMAC) basato su hash o MAC basato su blocchi, purché siano consigliati anche tutti gli algoritmi di crittografia hash o simmetrica sottostanti. Attualmente sono incluse le funzioni HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512). Sebbene l'utilizzo di HMAC-SHA256 sia il minimo, è consigliabile supportare HMAC-SHA384.

Il troncamento di HMAC a meno di 128 bit non è consigliato.

Considerazioni sulla progettazione e sull'operatività

  • È necessario fornire un meccanismo per sostituire le chiavi crittografiche in base alle esigenze. Le chiavi devono essere sostituite quando raggiungono la fine della durata attiva o la chiave crittografica viene compromessa.
    • Ogni volta che si rinnova un certificato, è necessario rinnovarlo con una nuova chiave.
  • I prodotti che usano algoritmi di crittografia per proteggere i dati devono includere metadati sufficienti insieme a tale contenuto per supportare la migrazione a algoritmi diversi in futuro. Questi metadati devono includere l'algoritmo usato, le dimensioni delle chiavi e le modalità di riempimento.
  • Se disponibile, i prodotti devono usare protocolli crittografici stabiliti e forniti dalla piattaforma anziché riapplicarli, inclusi i formati di firma (ad esempio, usare un formato standard, esistente).
  • Non segnalare errori di operazione di crittografia agli utenti finali. Quando si restituisce un errore a un chiamante remoto (ad esempio, client Web o client in uno scenario client-server), usare solo un messaggio di errore generico.
    • Evitare di fornire informazioni non necessarie, ad esempio la segnalazione diretta di errori di lunghezza insufficiente o di lunghezza non valida. Registrare gli errori dettagliato solo nel server e solo se è abilitata la registrazione dettagliata.
  • È consigliabile esaminare la sicurezza aggiuntiva per qualsiasi progettazione che incorpora gli elementi seguenti:
    • Un nuovo protocollo incentrato principalmente sulla sicurezza (ad esempio un protocollo di autenticazione o autorizzazione)
    • Nuovo protocollo che usa la crittografia in un modo nuovo o non standard. Le considerazioni di esempio includono:
      • Un prodotto che implementa il protocollo chiama qualsiasi API di crittografia o metodi come parte dell'implementazione del protocollo?
      • Il protocollo dipende da qualsiasi altro protocollo usato per l'autenticazione o l'autorizzazione?
      • Il protocollo definirà i formati di archiviazione per gli elementi crittografici, ad esempio le chiavi?
  • I certificati autofirmati non sono consigliati. L'uso di un certificato autofirmato, ad esempio l'uso di una chiave crittografica non elaborata, non fornisce intrinsecamente agli utenti o agli amministratori alcuna base per prendere una decisione di attendibilità.
    • Al contrario, l'uso di un certificato rooted in un'autorità di certificazione attendibile rende chiara la base per basarsi sulla chiave privata associata e abilita la revoca e gli aggiornamenti in caso di errore di sicurezza.