I dati autenticati aggiuntivi (AAD) sono qualsiasi stringa passata a Cloud Key Management Service nell'ambito di una richiesta di crittografia o decrittografia. AAD viene utilizzato come controllo dell'integrità e può contribuire a proteggere i tuoi dati da un attacco di amministratore confuso. La stringa AAD non deve superare i 64 KiB.
Cloud KMS non decripta il testo cifrato, a meno che lo stesso valore AAD non venga utilizzato sia per la crittografia sia per la decrittografia.
L'AAD è associato ai dati criptati, perché non puoi decriptare il testo criptato se non conosci l'AAD, ma non viene memorizzato all'interno del testo criptato. Inoltre, AAD non aumenta la sicurezza crittografica del testo cifrato. Si tratta invece di un controllo aggiuntivo di Cloud KMS per autenticare una richiesta di decrittografia.
In Cloud KMS, AAD è sempre presente quando effettui una chiamata per criptare o decriptare. Se non fornisci un valore per AAD, viene utilizzata una stringa vuota. Se viene utilizzata una stringa vuota come AAD per la crittografia del testo non criptato, solo una stringa vuota consentirà la decrittografia del testo criptato.
AAD non viene registrato da Cloud Audit Logs.
Quando utilizzare AAD
Un esempio di utilizzo di AAD è quando l'applicazione funge da proxy di wrapping/unwrapping con una singola chiave e un numero illimitato di client, ciascuno in confini di sicurezza distinti. Ad esempio, l'applicazione potrebbe essere un diario che consente agli utenti di tenere un diario privato. Quando un utente deve visualizzare una voce del diario privata, l'applicazione può utilizzare il nome utente univoco come AAD nella richiesta di sblocco (decrittografia) per autenticare esplicitamente l'utente. In questo scenario puoi utilizzare una singola chiave per servire più utenti (senza limiti). Uno dei vantaggi principali è che non è necessario mantenere lo stato per i singoli utenti.
Un altro esempio è se la tua applicazione deve utilizzare token di accesso che contengono alcune informazioni private, ad esempio un indirizzo email. Gli input al token di accesso sono i dati autenticati utilizzati per un token di accesso più l'indirizzo email in testo normale. Questi input vengono quindi criptati in modo che il token di accesso scambiato sia sotto forma di Additional Encrypted Authenticated Data (AEAD).
Esempio di attacco di tipo confuso
Questo esempio mostra come un'applicazione potrebbe essere indotta a decriptare il testo cifrato per conto di un utente malintenzionato. In questo esempio, l'applicazione è il deputato confuso perché non è a conoscenza del fatto che l'aggressore l'ha indotta a usare impropriamente la sua autorità. Di conseguenza, l'utente malintenzionato è in grado di visualizzare i dati decriptati che in origine erano criptati per un altro utente. Tieni presente che in questo attacco l'aggressore non ha bisogno di conoscere la chiave di crittografia, perché si basa sul delegato confuso per eseguire la decrittografia.
Un'applicazione di diario consente agli utenti di tenere un diario privato. Ogni entry del diario è criptata e deve essere decriptata solo dall'utente che l'ha creata.
Alice crea una nota del diario. L'applicazione cripta la voce del diario e poi la archivia in una posizione riservata alle voci del diario di Alice.
Alice invia una richiesta per visualizzare la sua voce del diario. Poiché la voce del diario criptata si trova in una posizione riservata ad Alice, l'applicazione decripta i dati e li restituisce come risposta alla richiesta di Alice. Questo è il comportamento previsto dell'applicazione.
Mallory copia la voce del diario di Alice dalla posizione riservata ad Alice alla posizione riservata a Mallory.
Mallory invia una richiesta per visualizzare la copia della voce del diario di Alice. Poiché la copia della voce del diario di Alice si trova in una posizione riservata a Mallory, l'applicazione decripta la voce del diario e restituisce il testo non cifrato come risposta alla richiesta di Mallory. Mallory può quindi visualizzare la voce del diario di Alice, che non è il comportamento previsto dell'applicazione.
Per difendersi da questo tipo di attacco, l'applicazione può utilizzare una stringa non vuota come AAD per la crittografia e la decrittografia. L'AAD fornisce un controllo aggiuntivo per le richieste di decrittografia. Quando Mallory invia la richiesta di decrittografia per visualizzare la sua copia della voce del diario di Alice, la richiesta non andrà a buon fine a meno che Mallory non riesca anche a ingannare l'applicazione affinché utilizzi l'AAD corretto.
Archiviazione o riproduzione di AAD
Prima di criptare con AAD, decidi se memorizzare l'AAD affiancato con i dati criptati o riprodurlo per la decriptazione successiva.
Un motivo per archiviare l'AAD è semplificarne l'utilizzo quando devi decriptare il testo cifrato. Ad esempio, una riga di database potrebbe contenere sia il testo cifrato sia l'AAD utilizzato per la crittografia del testo in chiaro. Quando viene ricevuta una richiesta di decrittografia, l'applicazione può recuperare sia l'AAD sia il testo cifrato dal database. L'applicazione può quindi utilizzare l'AAD per il processo di decrittografia del testo criptato.
Un motivo per riprodurre l'AAD è verificare eventuali dati non privati, evitando al contempo lo stoccaggio dell'AAD. Ad esempio, se vuoi assicurarti che il percorso del file e il nome del file di un file criptato non siano stati modificati, puoi includerli come AAD durante la crittografia del file. Poi, quando viene inviata una richiesta di decrittografia per il file, puoi riprodurre l'AAD esaminando il percorso del file e il nome del file.
Archiviazione di AAD
Se memorizzi l'AAD, questo viene salvato e sarà subito disponibile per la tua applicazione per un uso futuro. Ad esempio, una tabella di database potrebbe contenere una colonna per il testo cifrato e una colonna per l'AAD utilizzato durante la creazione del testo cifrato. Quando è il momento di decriptare il testo criptato, l'applicazione recupera l'AAD e lo utilizza per la decriptazione.
Prendiamo ad esempio un'applicazione di diario progettata per mostrare una voce del diario solo all'utente che l'ha creata. Quando viene creata una voce del diario, viene criptata e poi salvata in un database, nella colonna ENCRYPTED_DIARY_ENTRY. Per ogni richiesta di visualizzazione
di una voce del diario, l'applicazione autentica l'utente e poi gli fornisce la
voce del diario.
Supponiamo che non venga utilizzato alcun AAD (diverso dalla stringa vuota predefinita) e che ipotetica
Mallory sia riuscita a copiare i dati di ENCRYPTED_DIARY_ENTRY di Alice nei suoi datiENCRYPTED_DIARY_ENTRY. Quando Mallory invia una richiesta di decrittografia per i suoi dati ENCRYPTED_DIARY_ENTRY (che sono stati copiati dai dati di Alice), l'applicazione esegue la decrittografia senza rendersi conto di essere stata ingannata.
Mallory riesce a vedere la voce del diario di Alice in testo non criptato.
Supponiamo ora che l'indirizzo email dell'utente venga utilizzato come AAD quando una voce del diario viene criptata. Quando Alice crea una voce del diario, l'applicazione memorizza il suo
EMAILENCRYPTED_DIARY_ENTRYEMAILENCRYPTED_DIARY_ENTRYEMAILENCRYPTED_DIARY_ENTRYEMAIL Supponiamo di nuovo che Mallory sia riuscita a copiare i dati ENCRYPTED_DIARY_ENTRY di Alice nei suoi dati ENCRYPTED_DIARY_ENTRY.
Quando Mallory invia una richiesta di decrittografia, l'applicazione recupera il suo indirizzo email dalla colonna EMAIL da utilizzare come AAD per la richiesta di decrittografia.
L'indirizzo email di Mallory non andrà a buon fine come AAD per la decrittografia, pertanto l'applicazione non consente a Mallory di vedere la voce del diario di Alice in testo normale.
Riproduzione di AAD
La riproduzione dell'AAD significa che non viene memorizzato da nessuna parte, ma puoi riprodurlo quando è il momento di decriptarlo.
Ad esempio, puoi utilizzare un percorso file e un nome file come AAD. Durante il processo di crittografia, supponiamo che il file criptato sia stato salvato in MY_PATH\MY_FILE1.enc, quindi MY_PATH\MY_FILE1.enc è stato utilizzato come AAD."MY_PATH\MY_FILE1.enc" Questo account AAD non viene archiviato. Quando viene ricevuta una richiesta di decrittografia, l'applicazione riproduce l'AAD esaminando il percorso e il nome del file da decriptare. Se il file criptato non è stato spostato in un'altra posizione, durante la decrittografia verrà utilizzato "MY_PATH\MY_FILE1.enc" come AAD, che corrisponde all'AAD utilizzato durante la crittografia, quindi la decrittografia può procedere.
Se il file criptato è stato spostato, ad esempio in SOME_OTHER_PATH\MY_FILE1.enc, "SOME_OTHER_PATH\MY_FILE1.enc" verrà utilizzato come AAD per la decrittografia. Questo valore AAD non corrisponde al valore AAD utilizzato per la crittografia, pertanto la decrittografia non andrà a buon fine.