Microsoft SDL Cryptographic Consigli

Articolo
02/07/2024

Introduzione

Questo documento contiene raccomandazioni e procedure consigliate per l'uso della crittografia nelle piattaforme Microsoft. Gran parte del contenuto qui è parafrasato o aggregato dagli standard di sicurezza interni di Microsoft usati per creare il ciclo di vita dello sviluppo della sicurezza. È progettato per essere usato come riferimento quando si progettano prodotti per usare le stesse API, algoritmi, protocolli e lunghezze di chiave richiesti da Microsoft per i propri prodotti e servizi.

Gli sviluppatori su piattaforme non Windows possono anche trarre vantaggio da queste raccomandazioni. Anche se i nomi delle API e delle librerie possono 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.

Protocollo di sicurezza, algoritmo e lunghezza della chiave Consigli

Versioni DI SSL/TLS

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

Tls 1.2 deve essere abilitato
Tls 1.1 e TLS 1.0 devono essere abilitati solo per la compatibilità con le versioni precedenti
SSL 3 e SSL 2 devono essere disabilitati per impostazione predefinita

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

Crittografie a blocchi

Per i prodotti che usano le crittografie a blocchi simmetriche:

Advanced Encryption Standard (AES) è consigliato per il nuovo codice.
Tre chiavi triple data encryption Standard (3DES) sono consentiti nel codice esistente per la compatibilità con le versioni precedenti.
Tutte le altre crittografie a blocchi, tra cui RC2, DES, 2-Key 3DES, DESX e Skipjack, devono essere usate solo per decrittografare i dati obsoleti e devono essere sostituite se usate per la crittografia.

Per gli algoritmi di crittografia a blocchi simmetrici, è consigliabile una lunghezza minima di chiave di 128 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). 3DES a tre chiavi è attualmente accettabile se è già in uso nel codice esistente. È consigliata la transizione ad AES. DES, DESX, RC2 e Skipjack non sono più considerati sicuri. Questi algoritmi devono essere usati solo per decrittografare i dati esistenti per motivi di compatibilità con le versioni precedenti e i dati devono essere crittografati nuovamente usando una crittografia a blocchi consigliata.

Modalità di crittografia

Gli algoritmi simmetrici possono operare in diverse 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:

Concatenamento blocchi crittografati (CBC)
Ciphertext Stealing (CTS)
Codicebook ottimizzato basato su XEX con furto di testo crittografato (XTS)

Alcune altre modalità di crittografia, come quelle incluse di seguito, presentano problemi di implementazione che ne rendono più probabile l'uso non corretto. In particolare, è consigliabile 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 il CTR, può causare la rivelazione dei dati crittografati. È consigliabile verificare la sicurezza aggiuntiva se vengono usate una delle modalità seguenti:

Feedback di output (OFB)
Commenti e suggerimenti sulla crittografia ():Cipher Feedback ():Cipher Feedback ():Cipher
Contatore (CTR)
Contatore con CBC-MAC (CCM)
Galois/Counter Mode (GCM)
Qualsiasi altro elemento non presente nell'elenco "consigliato" sopra

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. 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, in quanto ciò può rivelare informazioni sui dati crittografati, in particolare quando si usano modalità di crittografia di streaming come OUTPUT Feedback (OFB) o Counter (CTR).

Algoritmi asimmetrici, lunghezze delle chiavi e modalità di riempimento

RSA

È consigliabile usare RSA 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à.
Non è consigliabile usare spaziatura interna Null.
Chiavi >= 2048 bit consigliati

ECDSA

È consigliabile usare ECDSA con >= chiavi a 256 bit
Le firme basate su ECDSA devono usare una delle tre curve approvate da NIST (P-256, P-384 o P521).

ECDH

È consigliabile usare ECDH con >= chiavi a 256 bit
Lo scambio di chiavi basato su ECDH deve usare una delle tre curve approvate da NIST (P-256, P-384 o P521).

Integer Diffie-Hellman

>Lunghezza chiave = 2048 bit consigliato
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

Durata delle chiavi

Tutte le chiavi asimmetriche devono avere una durata massima di cinque anni, durata consigliata di un anno.
Tutte le chiavi simmetriche devono avere una durata massima di tre anni; durata consigliata di un anno.
È 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 può 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_Uedizione Standard_SYSTEM_PREFERRED_RNG

CAPI

Usare CryptGenRandom per generare valori casuali.

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 qualsiasi applicazione crittografica, ma è ok solo per i test interni.
La funzione SystemPrng è consigliata per il codice in modalità kernel.

.NET

Usare RNGCryptoServiceProvider

App di Windows Store

Le app dello Store possono usare CryptographicBuffer.GenerateRandom o CryptographicBuffer.GenerateRandomNumber.

Non consigliato

Le funzioni non sicure correlate alla generazione di numeri casuali includono rand,System.Random (.NET), GetTickCount e GetTickCount64
Non è consigliabile usare l'algoritmo dual elliptic curve random number generator ("DUAL_EC_DRBG").

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 possono scegliere di valutare librerie di crittografia non piattaforma da usare. In generale, le librerie di crittografia della piattaforma verranno 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 non piattaforma deve essere guidata dai requisiti seguenti:

La libreria deve essere una versione attualmente supportata senza vulnerabilità di sicurezza note
È consigliabile 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 la compatibilità con le versioni precedenti

Codice nativo

Primitive di crittografia: se la versione è in Windows o Windows Telefono, usare CNG, se possibile. In caso contrario, usare CryptoAPI (detto anche CAPI, supportato come componente legacy in Windows da Windows Vista in poi).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 o IXMLHTTPRequest3.
- Le app WinHTTP devono essere compilate con WinHttpSetOptionper supportare TLS 1.2
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

Primitive di crittografia: usare l'API definita nello spazio dei nomi System.Security.Cryptography--- le classi CNG sono preferite.
Usare la versione più recente di .Net Framework disponibile. Almeno questa deve essere .Net Framework versione 4.6. Se è necessaria una versione precedente, verificare che la chiave di regkey "SchUseStrongCrypto" sia impostata per abilitare TLS 1.2 per l'applicazione in questione.
Convalida del certificato: usare le API definite nello spazio dei nomi System.Security.Cryptography.X509Certificates.
SSL/TLS/DTLS: usare le API definite nello spazio dei nomi System.Net ,ad esempio HttpWebRequest.

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: raccomandazione per la derivazione chiave tramite funzioni pseudorandome. In particolare, KDF in modalità contatore, con HMAC come funzione pseudorandoma
NIST SP 800-56A (revisione 2): raccomandazione per gli schemi di definizione delle chiavi pair-wise che usano la crittografia logaritmica discreta. In particolare, è consigliabile usare la funzione di derivazione con chiave a passaggio singolo nella sezione 5.8.1.

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 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 SSL, TLS o DTLS devono verificare completamente i certificati X.509 delle entità a cui si connettono. Ciò include la verifica dei certificati':

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 (CA) considerata attendibile dalla piattaforma o configurata in modo esplicito dall'amministratore.

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

I client che considerano attendibili i certificati "autofirmati", ad esempio un client di posta elettronica che si connette a un server Exchange in una configurazione predefinita, possono ignorare i controlli di verifica del certificato. Tuttavia, i certificati autofirmati non trasmettono intrinsecamente attendibilità, supportano la revoca o supportano il rinnovo della chiave. È consigliabile considerare attendibili solo i certificati autofirmati se sono stati ottenuti da un'altra origine attendibile, ad esempio un'entità attendibile che fornisce il certificato su un trasporto autenticato e protetto dall'integrità.

Funzioni hash crittografiche

I prodotti devono usare la famiglia di algoritmi hash SHA-2 (SHA256, SHA384 e SHA512). Non è consigliabile troncare gli hash crittografici per scopi di sicurezza a meno di 128 bit.

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).

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 dopo aver raggiunto la fine della durata attiva o se 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. Deve includere l'algoritmo usato, le dimensioni delle chiavi, i vettori di inizializzazione e le modalità di riempimento.
- Per altre informazioni sull'agilità crittografica, vedere Cryptographic Agility (Agilità crittografica) su MSDN.
Se disponibile, i prodotti devono usare protocolli crittografici stabiliti e forniti dalla piattaforma anziché implementarli di nuovo. Sono inclusi i formati di firma (ad esempio, usare un formato standard, esistente).
Le crittografie del flusso simmetrico, ad esempio RC4, non devono essere usate. Invece delle crittografie di flusso simmetriche, i prodotti devono usare una crittografia a blocchi, in particolare AES con una lunghezza di chiave di almeno 128 bit.
Non segnalare errori di operazione crittografica 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 quanto segue:Additional Security Review is highly recommended for any design incorpore the following:
- Un nuovo protocollo incentrato principalmente sulla sicurezza (ad esempio un protocollo di autenticazione o autorizzazione)
- Un nuovo protocollo che usa la crittografia in un romanzo o non standard o 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 per gli ambienti di produzione. L'uso di un certificato autofirmato, ad esempio l'uso di una chiave crittografica non elaborata, non fornisce 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.

Crittografia dei dati sensibili prima di Archiviazione

DPAPI/DPAPI-NG

Per i dati che devono essere salvati in modo permanente tra i riavvii del sistema:

CryptProtectData
CryptUnprotectData
NCryptProtectSecret (DPAPI Windows 8 CNG)

Per i dati che non devono essere salvati in modo permanente tra i riavvii del sistema:

CryptProtectMemory
CryptUnprotectMemory

Per i dati che devono essere salvati in modo permanente e a cui si accede da più account di dominio e computer:

NCryptProtectSecret (in CNG DPAPI, disponibile a partire da Windows 8)
Insieme di credenziali delle chiavi di Microsoft Azure

SQL Server TDE

È possibile usare Transparent Data Encryption (TDE) di SQL Server per proteggere i dati sensibili.

È consigliabile usare una chiave DEK (TDE Database Encryption Key) che soddisfi i requisiti di complessità della chiave e dell'algoritmo di crittografia SDL. Attualmente sono consigliati solo AES_128, AES_192 e AES_256; TRIPLE_DES_3KEY non è consigliato.

Per l'uso di SQL TDE è necessario tenere presenti alcune considerazioni importanti:

SQL Server non supporta la crittografia per i dati FILESTREAM , anche quando TDE è abilitato.
TDE non fornisce automaticamente la crittografia per i dati in transito da o verso il database; è anche necessario abilitare le connessioni crittografate al database di SQL Server. Per indicazioni sull'abilitazione delle connessioni crittografate, vedere Abilitarele Connessione crittografate nel motore di database (Gestione configurazione SQL Server).
Se si sposta un database protetto da TDE in un'istanza di SQL Server diversa, è necessario spostare anche il certificato che protegge la chiave DEK (TDE Data Encryption Key) e installarlo nel database master dell'istanza di SQL Server di destinazione. Per altre informazioni, vedere l'articolo TechNet Spostare un database protetto TDEin un altro SQL Server.

Gestione delle credenziali

Usare l'API di Windows Credential Manager o Microsoft Azure KeyVault per proteggere i dati delle password e delle credenziali.

App di Windows Store

Usare le classi negli spazi dei nomi Windows.Security.Cryptography e Windows.Security.Cryptography.DataProtection per proteggere i segreti e i dati sensibili.

ProtectAsync
ProtectStreamAsync
UnprotectAsync
UnprotectStreamAsync

Usare le classi nello spazio dei nomi Windows.Security.Credentials per proteggere i dati delle credenziali e delle password.

.NET