I dati autenticati aggiuntivi (AAD) sono qualsiasi stringa che passi a Cloud Key Management Service nell'ambito di una richiesta di crittografia o decriptazione. AAD viene utilizzato come controllo dell'integrità e può aiutare a proteggere i tuoi dati da un attacco a vicepresidente confuso. La stringa AAD non deve superare i 64 KiB.
Cloud KMS non decripta il testo crittografato, a meno che non venga utilizzato lo stesso valore AAD sia per la crittografia che per la decriptazione.
AAD è associato ai dati criptati perché non puoi decriptare il testo crittografato a meno che non conosci l'AAD, ma questo non è archiviato come parte del testo crittografato. Inoltre, l'AAD non aumenta la potenza crittografica del testo crittografato. Si tratta invece di un controllo aggiuntivo da parte 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 crittografato, solo una stringa vuota consentirà la decriptazione del testo crittografato.
L'AAD non viene registrato da Cloud Audit Logs.
Quando utilizzare AAD
Un esempio di utilizzo di AAD è quando l'applicazione funge da proxy di wrap/unwrapping con una singola chiave e un numero illimitato di client, con ciascun client in limiti di sicurezza distinti. Ad esempio, l'applicazione potrebbe essere un diario che consente agli utenti di gestire un diario privato. Quando un utente deve visualizzare la voce di un diario privato, l'applicazione può utilizzare il nome utente univoco come AAD nella richiesta di unwrapping (decrittografia) per autenticare esplicitamente l'utente. In questo scenario puoi utilizzare una singola chiave per gestire più utenti (illimitati). Uno dei vantaggi principali è che non devi mantenere lo stato per i singoli utenti.
Un altro esempio è il caso in cui la tua applicazione utilizzi token di connessione che contengono alcune informazioni private, ad esempio un indirizzo email. Gli input nel token di connessione sono i dati autenticati utilizzati per un token di connessione più l'indirizzo email in testo non crittografato. Questi input vengono quindi criptati in modo che il token di connessione che viene scambiato sia nella forma di Additional Encrypted Authenticated Data (AEAD).
Esempio di attacco confuso a un vice
Questo esempio mostra come un'applicazione potrebbe essere indotta con l'inganno a decriptare il testo crittografato per conto di un utente malintenzionato. In questo esempio, l'applicazione è confusa, perché non è consapevole che l'utente malintenzionato ha indotto l'applicazione con l'inganno a utilizzare impropriamente la propria autorità. Il risultato è che l'utente malintenzionato riesce a visualizzare i dati decriptati che in origine erano stati criptati per un altro utente. Tieni presente che in questo attacco non è necessario che l'utente malintenzionato conosca la chiave di crittografia, perché si affida all'agente confuso per eseguire la decrittografia.
Un'applicazione di diario consente agli utenti di gestire un diario privato. Ogni voce del diario è criptata e deve essere decriptata solo dall'utente che ha creato la voce del diario.
Alice crea una voce in un diario. L'applicazione cripta la voce del diario, quindi la archivia in una posizione riservata alle voci del diario che appartengono ad Alice.
Alice invia una richiesta per visualizzare la voce del suo diario. Poiché la voce del diario criptato 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 nota del diario di Alice dal luogo riservato ad Alice al luogo riservato a Mallory.
Mallory invia una richiesta per visualizzare una copia della registrazione del diario di Alice di Mallory. Poiché la copia della voce del diario di Alice si trova in un luogo riservato a Michela, l'applicazione decripta la voce del diario e restituisce il testo non crittografato come risposta alla richiesta di Michela. 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 decriptazione. L'AAD fornisce un controllo aggiuntivo per le richieste di decriptazione. Quando Mallory invia la richiesta di decrittografia per visualizzare la copia della voce del diario di Alice, la richiesta non andrà a buon fine, a meno che anche Mallory possa indurre con l'inganno l'applicazione a utilizzare l'AAD corretto.
Archiviazione o riproduzione di AAD
Prima di eseguire la crittografia con AAD, decidi se archiviare l'AAD accanto ai dati criptati oppure se riprodurre l'AAD per la successiva decriptazione.
Un motivo per archiviare AAD è semplificare l'utilizzo di AAD quando è necessario decriptare il testo crittografato. Ad esempio, una riga di database potrebbe contenere sia il testo crittografato che l'AAD utilizzati quando il testo non crittografato è stato criptato. Quando viene ricevuta una richiesta di decriptazione, l'applicazione può recuperare sia l'AAD sia il testo crittografato dal database. L'applicazione può quindi utilizzare l'AAD per la procedura di decriptazione del testo crittografato.
Un motivo per riprodurre AAD è verificare tutti i dati non privati, evitando al contempo l'archiviazione di AAD. Ad esempio, se vuoi assicurarti che il percorso e il nome file di un file criptato non siano cambiati, puoi includere il percorso e il nome file come AAD quando cripti il file. Quindi, quando viene inviata una richiesta di decriptazione per il file, puoi riprodurre l'AAD esaminando il percorso e il nome file.
Archiviazione dell'AAD
L'archiviazione di AAD significa che l'AAD viene salvato e immediatamente disponibile dalla tua applicazione per uso futuro. Ad esempio, una tabella di database potrebbe contenere una colonna per il testo crittografato e una colonna per l'AAD utilizzato al momento della creazione del testo crittografato. Quando è il momento di decriptare il testo crittografato, l'applicazione recupera l'AAD e lo utilizza per la decriptazione.
Prendiamo in considerazione un'applicazione di diario progettata per mostrare la voce del diario solo all'utente che l'ha creata. Quando viene creata una voce di diario, questa 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 fornisce la voce del diario all'utente.
Supponiamo che non venga utilizzato alcun AAD (a parte la stringa vuota predefinita) e che ipoteticamente Mallory sia riuscito a copiare i dati di ENCRYPTED_DIARY_ENTRY di Alice in quelli di ENCRYPTED_DIARY_ENTRY di Mallory. Quando Mallory invia una richiesta di decriptazione per i dati ENCRYPTED_DIARY_ENTRY di Mallory (copiati dai dati di Alice), l'applicazione esegue la decriptazione senza rendersi conto di essere stata ingannata.
Mallory riesce a vedere la voce del diario di Alice in testo non crittografato.
Ora supponiamo che l'indirizzo email dell'utente venga utilizzato come AAD quando una voce del diario viene criptata. Quando Alice crea una voce di diario, l'applicazione archivia il suo
indirizzo email non criptato nella colonna EMAIL, accanto ai
dati ENCRYPTED_DIARY_ENTRY. Supponiamo ancora che Michela sia riuscita a copiare
i dati di Alice su ENCRYPTED_DIARY_ENTRY in quelli di ENCRYPTED_DIARY_ENTRY.
Quando Mallory invia una richiesta di decriptazione, l'applicazione recupera l'indirizzo email di Mallory dalla colonna EMAIL per utilizzarlo come AAD per la richiesta di decriptazione.
L'indirizzo email di Mallory non avrà successo come AAD per la decrittografia, quindi l'applicazione non consente a Mallory di vedere la voce del diario di Alice come testo non crittografato.
Riproduzione dell'AAD in corso...
Se riproduci i file AAD, i file AAD non vengono archiviati in nessun luogo, ma puoi riprodurli al momento della decrittografia.
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 e che "MY_PATH\MY_FILE1.enc" sia stato utilizzato come AAD. Questo AAD non è archiviato. Quando viene ricevuta una richiesta di decriptazione, l'applicazione riproduce l'AAD esaminando il percorso e il nome file del file da decriptare. Se il file criptato non è stato spostato in un'altra posizione, durante la decriptazione verrà utilizzato "MY_PATH\MY_FILE1.enc" come AAD, che equivale al file AAD utilizzato durante la crittografia, quindi la decrittografia può continuare.
Se il file criptato è stato spostato, ad esempio in SOME_OTHER_PATH\MY_FILE1.enc, verrà utilizzato "SOME_OTHER_PATH\MY_FILE1.enc" come AAD per la decriptazione. Questo valore AAD non corrisponde a quello utilizzato per la crittografia, quindi la decriptazione non andrà a buon fine.