10. Security Considerations (Considerazioni sulla sicurezza)

Tutte le considerazioni sulla sicurezza che si applicano agli algoritmi crittografici in generale e quelle che si applicano specificamente agli algoritmi utilizzati in questa specifica si applicano a questa specifica.

Tutte le considerazioni sulla sicurezza in [JWA] (JSON Web Algorithms) si applicano anche a questa specifica. Gli implementatori dovrebbero prestare particolare attenzione alle considerazioni sulla sicurezza della crittografia, in particolare agli avvertimenti riguardanti le lunghezze minime delle chiavi nella sezione 3.5 di [JWA].

Le seguenti considerazioni sulla sicurezza si applicano agli oggetti JSON Web Signature (JWS):

10.1 Key Entropy and Random Values (Entropia delle chiavi e valori casuali)

Vedere la sezione 10.1 di [JWA] per considerazioni sull'entropia delle chiavi e sui valori casuali.

La forza di qualsiasi firma o MAC dipende criticamente dall'entropia della chiave crittografica utilizzata. Pertanto, è della massima importanza che le chiavi siano generate con entropia sufficiente. RFC 4086 [RFC4086] fornisce linee guida sulla generazione di valori casuali con entropia sufficiente.

10.2 Key Protection (Protezione delle chiavi)

Le chiavi devono essere protette dalla divulgazione e dall'uso non autorizzato. In particolare, le chiavi private utilizzate per le firme digitali devono essere protette dalla divulgazione e dall'uso non autorizzato. Le chiavi segrete utilizzate per i MAC devono essere protette dalla divulgazione e dall'uso non autorizzato.

I metodi per proteggere le chiavi includono:

• Memorizzazione delle chiavi in Hardware Security Module (HSM)
• Crittografia delle chiavi durante la memorizzazione
• Limitazione dell'accesso alle chiavi utilizzando meccanismi di controllo degli accessi
• Utilizzo di processi appropriati di gestione del ciclo di vita delle chiavi

10.3 Key Origin Authentication (Autenticazione dell'origine della chiave)

Quando una chiave viene utilizzata per verificare una firma o un MAC, il destinatario deve avere fiducia che la chiave provenga effettivamente dall'emittente previsto. I meccanismi per stabilire la fiducia nell'origine della chiave includono:

• Utilizzo di certificati X.509
• Utilizzo di protocolli di stabilimento delle chiavi con autenticazione
• Utilizzo di chiavi precondivise con autenticazione della fonte
• Recupero delle chiavi da un set di chiavi affidabile (JWK Set)

10.4 Cryptographic Agility (Agilità crittografica)

Vedere la sezione 10.4 di [JWA] per considerazioni sull'agilità crittografica.

Le implementazioni dovrebbero essere progettate per consentire la migrazione a nuovi algoritmi crittografici secondo necessità. Ciò può essere realizzato:

• Supportando più algoritmi
• Consentendo la facile configurazione degli algoritmi supportati
• Fornendo meccanismi di aggiornamento chiari

10.5 Differences between Digital Signatures and MACs (Differenze tra firme digitali e MAC)

Le firme digitali forniscono autenticazione e non ripudio; utilizzano la crittografia a chiave pubblica. I MAC forniscono autenticazione ma non il non ripudio; utilizzano chiavi segrete condivise.

Nelle applicazioni in cui è richiesto il non ripudio, devono (MUST) essere utilizzate firme digitali. Nelle applicazioni in cui il non ripudio non è richiesto, può essere utilizzato uno dei due, ma i MAC sono spesso più efficienti.

10.6 Algorithm Validation (Validazione dell'algoritmo)

Il valore del parametro header "alg" (algorithm, algoritmo) deve (MUST) essere verificato per assicurarsi che corrisponda all'algoritmo atteso dall'applicazione. Ciò previene attacchi in cui un attaccante modifica il valore "alg" per indurre il destinatario a utilizzare un algoritmo più debole o un algoritmo che l'attaccante può sfruttare.

Le implementazioni dovrebbero:

• Rifiutare i valori "alg" inattesi
• Mantenere una whitelist di algoritmi accettabili
• Non fidarsi mai ciecamente del valore "alg" ricevuto

10.7 Algorithm Protection (Protezione dell'algoritmo)

Nelle applicazioni in cui l'algoritmo utilizzato per proteggere il JWS è critico per la sicurezza, l'algoritmo dovrebbe (SHOULD) essere incluso nel JWS Protected Header anziché nel JWS Unprotected Header. In questo modo, l'algoritmo è protetto in integrità.

Vedere anche la sezione 10.6 di [JWA] e RFC 6211 [RFC6211] per ulteriori informazioni sulla protezione dell'algoritmo.

10.8 Chosen Plaintext Attacks (Attacchi con testo in chiaro scelto)

Le implementazioni JWS possono essere vulnerabili ad attacchi con testo in chiaro scelto se un attaccante può indurre il sistema a firmare o generare un MAC per payload arbitrari. Le implementazioni dovrebbero:

• Limitare quali payload possono essere firmati o protetti da MAC
• Validare i payload prima di firmarli o proteggerli con MAC
• Implementare controlli di accesso appropriati

10.9 Timing Attacks (Attacchi temporali)

Le implementazioni devono essere progettate per essere resistenti agli attacchi temporali. In particolare, le operazioni di verifica della firma e del MAC dovrebbero richiedere tempo costante, indipendentemente dal fatto che la verifica abbia successo o fallisca.

Le tecniche per mitigare gli attacchi temporali includono:

• Utilizzo di algoritmi a tempo costante per il confronto di firme/MAC
• Evitare uscite anticipate sui fallimenti di verifica
• Evitare variazioni di comportamento in base ai valori delle chiavi

10.10 Replay Protection (Protezione dalla ripetizione)

JWS non fornisce intrinsecamente protezione dalla ripetizione. Le applicazioni che richiedono protezione dalla ripetizione devono implementarla a livello di applicazione. I meccanismi per prevenire la ripetizione includono:

• Inclusione di un numero unico (nonce) nel payload
• Inclusione di un timestamp e verifica della freschezza
• Utilizzo di meccanismi a finestra scorrevole
• Mantenimento di una cache dei JWS visti di recente

10.11 SHA-1 Certificate Thumbprints (Impronte di certificati SHA-1)

Il parametro header "x5t" (X.509 certificate SHA-1 thumbprint, impronta SHA-1 del certificato X.509) è incluso solo per compatibilità retroattiva e non è raccomandato per nuovi utilizzi. Le implementazioni dovrebbero invece utilizzare il parametro header "x5t#S256" (X.509 certificate SHA-256 thumbprint, impronta SHA-256 del certificato X.509).

10.12 JSON Security Considerations (Considerazioni sulla sicurezza JSON)

Le implementazioni devono essere consapevoli dei problemi di sicurezza relativi all'elaborazione JSON, tra cui:

• Attacchi di injection JSON
• Problemi di normalizzazione Unicode
• Problemi di duplicazione delle chiavi JSON
• Problemi di analisi JSON (ad es. numeri molto grandi)

Vedere RFC 7159 [RFC7159] per ulteriori informazioni sulla sicurezza JSON.

10.13 Unicode Comparison Security Issues (Problemi di sicurezza del confronto Unicode)

I nomi dei parametri header e i valori delle stringhe devono essere confrontati utilizzando il confronto esatto dei valori delle stringhe Unicode. Le implementazioni non devono eseguire la normalizzazione Unicode o altre trasformazioni prima del confronto, poiché ciò potrebbe portare a vulnerabilità di sicurezza.