Crittografia multipiattaforma in .NET

Le operazioni di crittografia in .NET vengono eseguite dalle librerie del sistema operativo (OS). Questa dipendenza presenta vari vantaggi:

• Le app .NET beneficiano dell’affidabilità del sistema operativo. Mantenere le librerie di crittografia al sicuro dalle vulnerabilità è una priorità elevata per i fornitori di sistemi operativi. A tale scopo, forniscono aggiornamenti che devono essere applicati dagli amministratori di sistema.
• Le app .NET hanno accesso agli algoritmi convalidati FIPS se le librerie del sistema operativo sono convalidate da FIPS.

La dipendenza dalle librerie del sistema operativo significa anche che le app .NET possono usare solo funzionalità di crittografia supportate dal sistema operativo. Sebbene tutte le piattaforme supportino determinate funzionalità di base, alcune funzionalità supportate da .NET non possono essere usate in alcune piattaforme. Questo articolo illustra le funzionalità supportate in ogni piattaforma.

Questo articolo presuppone che si abbia familiarità con la crittografia in .NET. Per ulteriori informazioni, consultare Modello di crittografia .NET e Servizi di crittografia .NET.

Algoritmi di autenticazione hash e messaggi

Tutte le classi HMAC (Hash Algorithm and Hash-Based Message Authentication), incluse le classi *Managed, rimandano alle librerie del sistema operativo, ad eccezione di .NET in Browser WASM. Nel browser WASM, SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 e gli equivalenti HMAC vengono implementati utilizzando codice gestito.

¹Disponibile a partire da .NET 8.

²Disponibile a partire da .NET 9.

³La funzione di output estendibile di streaming (XOF) è disponibile a partire da .NET 9. In Linux è necessario OpenSSL 3.3.

Crittografia simmetrica

Le crittografie e il concatenamento sottostanti vengono eseguite dalle librerie di sistema.

Crittografia autenticata

Il supporto della crittografia autenticata (AE) viene fornito rispettivamente per AES-CCM, AES-GCM e ChaCha20Poly1305 tramite le classi System.Security.Cryptography.AesCcm, System.Security.Cryptography.AesGcm e System.Security.Cryptography.ChaCha20Poly1305.

Poiché la crittografia dell'autenticazione richiede API della piattaforma più recenti per supportare l'algoritmo, il supporto potrebbe non essere presente in tutte le piattaforme. La proprietà statica IsSupported delle classi per l'algoritmo può essere usata per rilevare durante il runtime se la piattaforma corrente supporta o meno l'algoritmo.

AES-CCM in macOS

In macOS, le librerie di sistema non supportano AES-CCM per codice di terzi, quindi la classe AesCcm usa OpenSSL per supporto. Gli utenti di macOS devono ottenere una copia adatta di OpenSSL (libcrypto) perché questo possa funzionare, e deve trovarsi in un percorso da cui il sistema caricherebbe una libreria per impostazione predefinita. È consigliabile installare OpenSSL da una gestione pacchetti, come Homebrew.

Le librerie libcrypto.0.9.7.dylib e libcrypto.0.9.8.dylib incluse in macOS provengono da versioni precedenti di OpenSSL e non saranno usate. Le librerie libcrypto.35.dylib, libcrypto.41.dylib e libcrypto.42.dylib provengono da LibreSSL e non saranno usate.

AES-GCM e ChaCha20Poly1305 in macOS

macOS non supporta AES-GCM o ChaCha20Poly1305 fino a macOS 10.15 per codice di terzi. In versioni precedenti a .NET 8, AesGcm e ChaCha20Poly1305 hanno lo stesso requisito di AES-CCM e gli utenti devono installare OpenSSL perché questi tipi possano funzionare.

A partire da .NET 8, .NET in macOS userà il framework CryptoKit di Apple per AES-GCM e ChaCha20Poly1305. Gli utenti non dovranno installare o configurare dipendenze aggiuntive per AES-GCM o ChaCha20Poly1305 in macOS.

AES-GCM e ChaCha20Poly1305 in iOS, tvOS e MacCatalyst

Il supporto per AES-GCM e ChaCha20Poly1305 è disponibile a partire da .NET 9 in iOS e tvOS 13.0 e versioni successive e tutte le versioni di MacCatalyst.

Chiavi, nonce e tag AES-CCM

• Dimensioni chiave

  AES-CCM funziona con chiavi a 128, 192 e a 256 bit.

• Dimensioni nonce

  La classe AesCcm supporta 56, 64, 72, 80, 88, 96 e 104 bit (7, 8, 9, 10, 11, 12 e 13 byte).

• Dimensioni tag

  La classe AesCcm supporta la creazione o l'elaborazione di tag 32, 48, 64, 80, 96, 112 e 128 bit (4, 8, 10, 12, 14 e 16 byte).

Chiavi, nonce e tag AES-GCM

• Dimensioni chiave

  AES-GCM funziona con chiavi a 128, 192 e a 256 bit.

• Dimensioni nonce

  La classe AesGcm supporta solo nonce a 96 bit (12 byte).

• Dimensioni tag in Windows e Linux, la classe AesGcm supporta la creazione o l'elaborazione di tag 96, 104, 112, 120 e 128 bit (12, 13, 14, 15 e 16 byte). Sulle piattaforme Apple, la dimensione del tag è limitata a 128 bit (16 byte) a causa delle limitazioni del framework CryptoKit.

Chiavi ChaCha20Poly1305, nonce e tag.

ChaCha20Poly1305 ha una dimensione fissa per il tag di autenticazione, nonce e chiave. ChaCha20Poly1305 usa sempre un tag a 256 bit, un nonce a 96 bit (12 byte) e un tag a 128 bit (16 byte).

Crittografia asimmetrica

Questa sezione include le seguenti sottosezioni:

• RSA
• ECDSA
• ECDH
• DSA

RSA

La generazione di chiavi RSA (Rivest–Shamir-Adleman) viene eseguita dalle librerie del sistema operativo ed è soggetta alle relative limitazioni di dimensioni e caratteristiche delle prestazioni.

Le operazioni chiave RSA vengono eseguite dalle librerie del sistema operativo e i tipi di chiave che possono essere caricati sono soggetti ai requisiti del sistema operativo.

.NET non espone operazioni RSA "raw" (senza spaziatura interna).

Il supporto di spaziatura interna e di digest varia in base alla piattaforma:

¹ Windows CryptoAPI (CAPI) è in grado di effettuare una firma PKCS1 con un algoritmo SHA-2. Tuttavia, il singolo oggetto RSA potrebbe essere caricato in un provider di servizi di crittografia (CSP) nel quale non è supportato.

² Richiede .NET 8.

RSA in Windows

• Windows CryptoAPI (CAPI) viene usato ogni volta che new RSACryptoServiceProvider() è in uso.
• Windows Cryptography API Next Generation (CNG) viene usato ogni volta che new RSACng() è in uso.
• L'oggetto restituito da RSA.Create è alimentato internamente da Windows CNG. Questo uso di Windows CNG è un dettaglio di implementazione ed è soggetto a modifiche.
• Il metodo di estensione GetRSAPublicKey per X509Certificate2 restituisce un'istanza di RSACng. Questo uso di RSACng è un dettaglio di implementazione ed è soggetto a modifiche.
• Attualmente, il metodo di estensione GetRSAPrivateKey per X509Certificate2 preferisce un'istanza RSACng, ma se RSACng non può aprire la chiave, verrà eseguito un tentativo di RSACryptoServiceProvider. Il provider preferito è un dettaglio di implementazione ed è soggetto a modifiche.

Interoperabilità nativa RSA

.NET espone tipi per consentire ai programmi di interagire con le librerie del sistema operativo usate dal codice di crittografia .NET. I tipi coinvolti non si traducono tra piattaforme e devono essere usati direttamente solo quando necessario.

¹ In sistemi diversi da Windows, RSACryptoServiceProvider può essere usato per la compatibilità con programmi esistenti. In tal caso, qualsiasi metodo che richieda l'interoperabilità del sistema operativo (ad esempio, l'apertura di una chiave denominata) genera un'eccezione PlatformNotSupportedException.

² In macOS, RSAOpenSsl sarà funzionante se OpenSSL è installato e un dylib libcrypto adatto può essere trovato tramite il caricamento della libreria dinamica. Se non è possibile trovare una libreria adatta, verranno generate eccezioni.

ECDSA

La generazione di chiavi ECDSA (Elliptic Curve Digital Signature Algorithm) viene eseguita dalle librerie del sistema operativo ed è soggetta alle relative limitazioni di dimensioni e caratteristiche delle prestazioni.

Le curve chiave ECDSA sono definite dalle librerie del sistema operativo e sono soggette alle relative limitazioni.

¹ Non tutte le distribuzioni di Linux supportano le stesse curve denominate.

² Il supporto per le curve denominate è stato aggiunto a Windows CNG in Windows 10. Per ulteriori informazioni, consultare Curva ellittica denominata CNG. Le curve denominate non sono disponibili nelle versioni precedenti di Windows, ad eccezione di tre curve in Windows 7.

³ L'esportazione con parametri di curva espliciti richiede il supporto della libreria del sistema operativo, che non è disponibile nelle piattaforme Apple o nelle versioni precedenti di Windows.

⁴ Il supporto Android per alcune curve dipende dalla versione di Android. I distributori Android possono scegliere di aggiungere o rimuovere curve anche dalla compilazione Android.

Interoperabilità nativa ECDSA

.NET espone tipi per consentire ai programmi di interagire con le librerie del sistema operativo usate dal codice di crittografia .NET. I tipi coinvolti non si traducono tra piattaforme e devono essere usati direttamente solo quando necessario.

* In macOS, ECDsaOpenSsl sarà funzionante se OpenSSL è installato nel sistema e un dylib libcrypto adatto può essere trovato tramite il caricamento della libreria dinamica. Se non è possibile trovare una libreria adatta, verranno generate eccezioni.

ECDH

La generazione di chiavi ECDH (Elliptic Curve Diffie-Hellman) viene eseguita dalle librerie del sistema operativo ed è soggetta alle relative limitazioni di dimensioni e caratteristiche delle prestazioni.

La classe ECDiffieHellman supporta il valore "raw" del calcolo ECDH, nonché tramite le seguenti funzioni di derivazione chiave:

• HASH(Z)
• HASH(prepend || Z || append)
• HMAC(key, Z)
• HMAC(key, prepend || Z || append)
• HMAC(Z, Z)
• HMAC(Z, prepend || Z || append)
• Tls11Prf(label, seed)

La derivazione della chiave "Raw" è stata introdotta in .NET 8.

Le curve chiave ECDH sono definite dalle librerie del sistema operativo e sono soggette alle relative limitazioni.

¹ Non tutte le distribuzioni di Linux supportano le stesse curve denominate.

² Il supporto per le curve denominate è stato aggiunto a Windows CNG in Windows 10. Per ulteriori informazioni, consultare Curva ellittica denominata CNG. Le curve denominate non sono disponibili nelle versioni precedenti di Windows, ad eccezione di tre curve in Windows 7.

³ L'esportazione con parametri di curva espliciti richiede il supporto della libreria del sistema operativo, che non è disponibile nelle piattaforme Apple o nelle versioni precedenti di Windows.

⁴ Il supporto Android per alcune curve dipende dalla versione di Android. I distributori Android possono scegliere di aggiungere o rimuovere curve anche dalla compilazione Android.

Interoperabilità nativa ECDH

.NET espone tipi per consentire ai programmi di interagire con le librerie del sistema operativo usate da .NET. I tipi coinvolti non si traducono tra piattaforme e devono essere usati direttamente solo quando necessario.

* In macOS, ECDiffieHellmanOpenSsl sarà funzionante se OpenSSL è installato e un dylib libcrypto adatto può essere trovato tramite il caricamento della libreria dinamica. Se non è possibile trovare una libreria adatta, verranno generate eccezioni.

DSA

La generazione di chiavi DSA (Digital Signature Algorithm) viene eseguita dalle librerie di sistema ed è soggetta alle relative limitazioni di dimensioni e caratteristiche delle prestazioni.

* macOS carica le chiavi DSA superiori a 1024 bit, ma il comportamento di tali chiavi non è definito. Non si comportano secondo FIPS 186-3.

DSA in Windows

• Windows CryptoAPI (CAPI) viene usato ogni volta che new DSACryptoServiceProvider() è in uso.
• Windows Cryptography API Next Generation (CNG) viene usato ogni volta che new DSACng() è in uso.
• L'oggetto restituito da DSA.Create è alimentato internamente da Windows CNG. Questo uso di Windows CNG è un dettaglio di implementazione ed è soggetto a modifiche.
• Il metodo di estensione GetDSAPublicKey per X509Certificate2 restituisce un'istanza DSACng. Questo uso di DSACng è un dettaglio di implementazione ed è soggetto a modifiche.
• Il metodo di estensione GetDSAPrivateKey per X509Certificate2 preferisce un'istanza DSACng, ma se DSACng non può aprire la chiave, verrà eseguito un tentativo di DSACryptoServiceProvider. Il provider preferito è un dettaglio di implementazione ed è soggetto a modifiche.

Interoperabilità nativa di DSA

.NET espone tipi per consentire ai programmi di interagire con le librerie del sistema operativo usate dal codice di crittografia .NET. I tipi coinvolti non si traducono tra piattaforme e devono essere usati direttamente solo quando necessario.

¹ In sistemi diversi da Windows, DSACryptoServiceProvider può essere usato per la compatibilità con programmi esistenti. In tal caso, qualsiasi metodo che richieda l'interoperabilità del sistema operativo (ad esempio, l'apertura di una chiave denominata) genera un'eccezione PlatformNotSupportedException.

² In macOS, DSAOpenSsl sarà funzionante se OpenSSL è installato e un dylib libcrypto adatto può essere trovato tramite il caricamento della libreria dinamica. Se non è possibile trovare una libreria adatta, verranno generate eccezioni.

Certificati X.509

La maggior parte del supporto per i certificati X.509 in .NET proviene dalle librerie del sistema operativo. Per caricare un certificato in un'istanza X509Certificate2 o X509Certificate in .NET, il certificato deve essere caricato dalla libreria del sistema operativo sottostante.

Leggere un pkCS12/PFX

Scrivere un pkCS12/PFX

macOS non può caricare chiavi private del certificato senza un oggetto keychain, che richiede la scrittura su disco. I keychain vengono creati automaticamente per il caricamento PFX e vengono eliminati quando non più in uso. Poiché l'opzione X509KeyStorageFlags.EphemeralKeySet indica che la chiave privata non deve essere scritta su disco, l'asserzione del flag in macOS comporta la generazione di un PlatformNotSupportedException.

Scrivere una raccolta di certificati PKCS7

Sia Windows che Linux generano BLOB PKCS7 con codifica DER. macOS genera BLOB PKCS7 codificati a lunghezza indefinita.

X509Store

In Windows, la classe X509Store è una rappresentazione delle API dell'archivio certificati di Windows. Queste API funzionano in .NET Core e .NET 5 come in .NET Framework.

In sistemi operativi diversi da Windows, la classe X509Store è una proiezione di decisioni di attendibilità del sistema (sola lettura), decisioni di attendibilità utente (lettura/scrittura) e archiviazione delle chiavi utente (lettura/scrittura).

Le seguenti tabelle illustrano gli scenari supportati in ogni piattaforma. Per gli scenari non supportati (❌ nelle tabelle), viene generata un'eccezione CryptographicException.

Il mio archivio

In Linux, gli archivi vengono creati durante la prima scrittura e non esistono archivi utente predefiniti, quindi l'apertura di CurrentUser\My con ExistingOnly potrebbe non riuscire.

In macOS, l'archivio CurrentUser\My è il keychain predefinito dell'utente, che è login.keychain per impostazione predefinita. L'archivio LocalMachine\My è System.keychain.

Archivio radice

In Linux, l'archivio LocalMachine\Root è un'interpretazione del bundle CA nel percorso predefinito per OpenSSL.

In macOS, l'archivio CurrentUser\Root è un'interpretazione dei risultati SecTrustSettings per il dominio di attendibilità utente. L'archivio LocalMachine\Root è un'interpretazione dei risultati SecTrustSettings per i domini di attendibilità di sistema e amministratore.

Archivio intermedio

In Linux, l'archivio CurrentUser\Intermediate viene usato come cache quando si scaricano CA intermedie dai record di Accesso alle informazioni sull'autorità nelle build X509Chain riuscite. L'archivio LocalMachine\Intermediate è un'interpretazione del bundle CA nel percorso predefinito per OpenSSL.

In macOS, l'archivio CurrentUser\Intermediate viene considerato un archivio personalizzato. I certificati aggiunti a questo archivio non influiscono sulla compilazione della catena X.509.

Archivio non consentito

In Linux, l'archivio Disallowed non viene usato nella compilazione a catena e il tentativo di aggiungervi contenuto comporta un CryptographicException. Un‘eccezione CryptographicException viene generata quando si apre lo store Disallowed se questo ha già acquisito contenuti.

In macOS, gli archivi CurrentUser\Disallowed e LocalMachine\Disallowed sono interpretazioni dei risultati di SecTrustSettings appropriati per i certificati il cui trust è impostato su Always Deny.

Archivio inesistente

In macOS, la creazione di archivi personalizzati con l'API X509Store è supportata solo per la posizioneCurrentUser. Creerà un nuovo portachiavi senza password nella directory portachiavi dell'utente (~/Library/Keychains). Per creare un portachiavi con password, è possibile usare un P/Invoke. SecKeychainCreate Analogamente, SecKeychainOpen può essere usato per aprire keychain in diverse posizioni. L'oggetto risultante IntPtr può essere passato a new X509Store(IntPtr) per ottenere un archivio capace di lettura/scrittura, soggetto alle autorizzazioni dell'utente corrente.

X509Chain

macOS non supporta l'utilizzo di CRL offline, quindi X509RevocationMode.Offline viene considerato come X509RevocationMode.Online.

macOS non supporta un timeout avviato dall'utente in CRL (Certificate Revocation List), OCSP (Online Certificate Status Protocol), o AIA (Authority Information Access), quindi X509ChainPolicy.UrlRetrievalTimeout viene ignorato.

Risorse aggiuntive

• Modello di crittografia .NET
• Servizi di crittografia .NET
• Vulnerabilità di temporizzazione con decrittografia simmetrica modalità CBC usando il riempimento
• Protezione dati ASP.NET Core