10. Considerazioni sulla sicurezza

Gli agenti JWS/JWE/JWK DEVONO affrontare tutte le problematiche di sicurezza pertinenti a qualsiasi applicazione crittografica. Tra queste rientrano la protezione delle chiavi private asimmetriche e delle chiavi segrete simmetriche dell'utente e l'impiego di contromisure contro vari attacchi.

Tutte le considerazioni sulla sicurezza in "XML Signature Syntax and Processing Version 2.0" [W3C.NOTE-xmldsig-core2-20130411] si applicano anche a questa specifica, eccetto quelle specifiche di XML. Analogamente, molte delle pratiche consigliate documentate in "XML Signature Best Practices" [W3C.NOTE-xmldsig-bestpractices-20130411] si applicano a questa specifica, eccetto quelle specifiche di XML.

10.1 Entropia delle chiavi e valori casuali

La robustezza delle chiavi dipende dalla quantità di entropia usata per generarle. Per tutte le chiavi DOVREBBERO essere usati almeno 128 bit di entropia e, a seconda del contesto applicativo, potrebbero esserne necessari di più.

Le implementazioni DEVONO generare casualmente coppie di chiavi pubblica/privata, chiavi MAC e valori di padding. L'uso di generatori di numeri pseudocasuali (PRNG) inadeguati per generare chiavi crittografiche può comportare una sicurezza scarsa o nulla. Un attaccante può trovare molto più semplice riprodurre l'ambiente PRNG che ha prodotto le chiavi, esplorando il piccolo insieme di possibilità risultante invece di cercare per forza bruta nell'intero spazio delle chiavi. Generare numeri casuali di qualità è difficile. RFC 4086 [RFC4086] fornisce indicazioni importanti in questo ambito.

10.2 Protezione delle chiavi

Le implementazioni DEVONO proteggere la chiave privata del firmatario. La compromissione della chiave privata del firmatario consente a un attaccante di spacciarsi per il firmatario.

Le implementazioni DEVONO proteggere la chiave MAC. La compromissione della chiave MAC può consentire modifiche non rilevabili al contenuto autenticato.

10.3 Autenticazione dell'origine delle chiavi

La tecnica di gestione delle chiavi usata per ottenere chiavi pubbliche DEVE autenticare l'origine della chiave; in caso contrario non è noto quale parte abbia firmato il messaggio.

Analogamente, la tecnica di gestione delle chiavi usata per distribuire chiavi MAC DEVE fornire l'autenticazione dell'origine dei dati; altrimenti l'integrità del contenuto è attestata da una fonte sconosciuta.

10.4 Agilità crittografica

Per le considerazioni di sicurezza sull'agilità crittografica, vedere la Sezione 8.1 di [JWA].

10.5 Differenze tra firme digitali e MAC

Sebbene sia i MAC sia le firme digitali possano essere usati per verificare l'integrità, le proprietà di sicurezza offerte da ciascuno presentano differenze significative. Tali differenze DEVONO essere considerate nella progettazione dei protocolli e nella selezione degli algoritmi da impiegare nei protocolli.

Sia le firme sia i MAC consentono di verificare l'integrità, ossia che il messaggio non sia stato modificato dopo il calcolo del valore di integrità. Tuttavia, i MAC consentono l'identificazione dell'origine solo in circostanze specifiche. Normalmente si può presumere che una chiave privata usata per una firma sia nelle mani di una sola entità, sebbene possa essere un'entità distribuita nel caso di server replicati; una chiave MAC, invece, deve essere nelle mani di tutte le entità che la usano per calcolare e verificare l'integrità. La convalida di un MAC conferma soltanto che il messaggio è stato generato da una delle parti che conoscono la chiave MAC simmetrica. Ne consegue che l'origine può essere determinata soltanto se una chiave MAC è nota a due sole entità e il destinatario sa di non avere creato il messaggio. La convalida di un MAC non può essere usata per dimostrare l'origine a una terza parte.

10.6 Convalida degli algoritmi

Le rappresentazioni delle firme digitali di alcuni algoritmi includono nel valore di firma informazioni sull'algoritmo usato. Ad esempio, le firme prodotte con RSASSA-PKCS1-v1_5 [RFC3447] codificano la funzione hash usata e molte librerie usano effettivamente, per convalidare la firma, l'algoritmo hash specificato al suo interno. Quando si usano tali librerie, nell'ambito della convalida dell'algoritmo, le implementazioni DEVONO assicurare che le informazioni sull'algoritmo codificate nella firma corrispondano a quelle specificate dal parametro di intestazione "alg". In caso contrario, un attaccante potrebbe dichiarare di avere usato un algoritmo hash robusto mentre ha in realtà usato quello debole rappresentato nel valore della firma.

10.7 Protezione degli algoritmi

In alcuni usi di JWS esiste il rischio di attacchi di sostituzione dell'algoritmo, nei quali un attaccante può usare un valore di firma digitale esistente con un diverso algoritmo di firma per far apparire che un firmatario abbia firmato qualcosa che non ha firmato. Questi attacchi sono discussi dettagliatamente nel contesto di Cryptographic Message Syntax (CMS) [RFC6211]. Il rischio si presenta quando sono vere tutte le seguenti condizioni:

I verificatori di una firma supportano più algoritmi.
Data una firma esistente, un attaccante può trovare un altro payload che produce lo stesso valore di firma con un algoritmo diverso.
Il payload creato dall'attaccante è valido nel contesto applicativo.

Un'applicazione può mitigare gli attacchi di sostituzione dell'algoritmo in vari modi:

Usare solo algoritmi di firma digitale che non siano vulnerabili agli attacchi di sostituzione. Gli attacchi di sostituzione sono praticabili solo se un attaccante può calcolare preimmagini per una funzione hash accettata dal destinatario. Tutti gli algoritmi di firma definiti da JWA usano hash SHA-2, per i quali, al momento della stesura di questo documento, non sono noti attacchi di preimmagine.
Richiedere che il parametro di intestazione "alg" sia contenuto nell'intestazione protetta JWS. (Questo avviene sempre quando si usa la serializzazione compatta JWS ed è l'approccio adottato da CMS [RFC6211].)
Includere nel payload applicativo un campo contenente l'algoritmo e richiedere che, durante la verifica, corrisponda al parametro di intestazione "alg". (Questo è l'approccio adottato da PKIX [RFC5280].)

10.8 Attacchi a testo in chiaro scelto

I creatori di JWS non DOVREBBERO consentire a terzi di inserire contenuto arbitrario nel messaggio senza aggiungere entropia non controllata da tali terzi.

10.9 Attacchi temporali

Quando gli algoritmi crittografici sono implementati in modo che le operazioni riuscite richiedano un tempo diverso da quelle non riuscite, gli attaccanti potrebbero sfruttare la differenza temporale per ottenere informazioni sulle chiavi usate. Tali differenze temporali DEVONO pertanto essere evitate.

10.10 Protezione contro il replay

Benché non rientri direttamente nell'ambito di questa specifica, le applicazioni che usano oggetti JWS (o JWE) possono contrastare gli attacchi di replay includendo nel messaggio JWS (o JWE) un identificatore univoco del messaggio come contenuto protetto dall'integrità e facendo verificare al destinatario che il messaggio non sia stato ricevuto o elaborato in precedenza.

10.11 Impronte digitali dei certificati SHA-1

Per ragioni di compatibilità, per calcolare i valori "x5t" (impronta digitale SHA-1 del certificato X.509) viene usato un hash SHA-1. Qualora fosse sviluppato un metodo efficace per produrre collisioni hash SHA-1 e un attaccante volesse interferire con l'uso di un certificato noto su un dato sistema, potrebbe farlo creando un altro certificato con lo stesso valore hash SHA-1 e aggiungendolo all'archivio certificati della vittima designata. Perché l'attacco riesca, l'attaccante deve poter scrivere nell'archivio certificati della vittima designata.

In alternativa al parametro di intestazione "x5t" potrebbe essere usato "x5t#S256" (impronta digitale SHA-256 del certificato X.509). Tuttavia, al momento della stesura di questo documento non è nota alcuna piattaforma di sviluppo che supporti impronte digitali dei certificati SHA-256.

10.12 Considerazioni sulla sicurezza di JSON

La convalida rigorosa di JSON [RFC7159] è un requisito di sicurezza. Se si riceve JSON malformato, è impossibile determinare in modo affidabile l'intento del produttore. Se il parser JSON usato non rifiuta una sintassi JSON malformata, possono insorgere situazioni ambigue e potenzialmente sfruttabili. In particolare, i parser JSON DEVONO rifiutare integralmente qualsiasi input JSON che non sia conforme alla sintassi JSON-text definita in RFC 7159.

La Sezione 4 di "The JavaScript Object Notation (JSON) Data Interchange Format" [RFC7159] afferma che "i nomi all'interno di un oggetto DOVREBBERO essere univoci", mentre questa specifica stabilisce quanto segue:

I nomi dei parametri di intestazione nell'intestazione JOSE DEVONO essere univoci; i parser JWS DEVONO rifiutare i JWS con nomi di parametri di intestazione duplicati oppure usare un parser JSON che restituisca soltanto il nome dell'ultimo membro duplicato in ordine lessicale, come specificato nella Sezione 15.12 ("The JSON Object") di ECMAScript 5.1 [ECMAScript].

Pertanto, questa specifica richiede che i produttori trattino il "DOVREBBE" della Sezione 4 di [RFC7159] come un "DEVE" e che i consumatori lo trattino come un "DEVE" oppure nel modo specificato da ECMAScript 5.1. Se il parser JSON usato non impone l'unicità dei nomi dei membri o restituisce un valore imprevedibile per nomi di membri duplicati, possono insorgere situazioni ambigue e potenzialmente sfruttabili.

Alcuni parser JSON potrebbero non rifiutare un input che contiene caratteri significativi aggiuntivi dopo un input valido. Ad esempio, l'input "{"tag":"value"}ABCD" contiene un oggetto JSON-text valido seguito dai caratteri aggiuntivi "ABCD". Le implementazioni DEVONO considerare non validi i JWS che contengono tale input.

10.13 Considerazioni sulla sicurezza del confronto Unicode

I nomi dei parametri di intestazione e degli algoritmi sono stringhe Unicode. Per ragioni di sicurezza, le rappresentazioni di tali nomi DEVONO essere confrontate letteralmente dopo l'elaborazione delle sequenze di escape (come nella Sezione 8.3 di RFC 7159 [RFC7159]). Ciò significa, ad esempio, che queste stringhe JSON DEVONO risultare uguali ("sig", "\u0073ig"), mentre tutte queste DEVONO risultare diverse dal primo insieme e tra loro ("SIG", "Sig", "si\u0047").

Le stringhe JSON possono contenere caratteri esterni al Piano multilingue di base Unicode. Ad esempio, il carattere chiave di violino (U+1D11E) può essere rappresentato in una stringa JSON come "\uD834\uDD1E". Idealmente, le implementazioni JWS DOVREBBERO assicurare che i caratteri esterni al Piano multilingue di base siano conservati e confrontati correttamente; in alternativa, se ciò non è possibile perché tali caratteri espongono limiti dell'implementazione JSON sottostante, gli input che li contengono DEVONO essere rifiutati.