Altri dati autenticati

I dati autenticati aggiuntivi (AAD) sono stringhe precedute dal servizio Cloud Key Management Service nell'ambito di una richiesta di crittografia o decriptazione. AAD viene utilizzato come controllo di integrità e può aiutarti a proteggere i tuoi dati da un attacco decaffeinato. La stringa AAD non deve essere maggiore di 64 KiB.

Cloud KMS non decripta il testo di crittografia, a meno che non venga utilizzato lo stesso valore AAD sia per la crittografia sia per la decriptazione.

Il formato AAD è associato ai dati criptati, perché non puoi decriptare il testo criptato a meno che tu non lo conosca, ma non è memorizzato come parte del testo criptato. Inoltre, AAD non aumenta la sicurezza crittografica del testo di crittografia. È invece un controllo aggiuntivo di Cloud KMS per autenticare una richiesta di decriptazione.

In Cloud KMS, AAD è sempre presente quando esegui 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 decriptazione 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 wrap/unwrap con una singola chiave e un numero illimitato di client, dove ogni client ha limiti di sicurezza distinti. Ad esempio, potrebbe essere un'applicazione diario che consente agli utenti di gestire un diario privato. Quando un utente deve visualizzare una voce di diario privato, l'applicazione può utilizzare il nome utente univoco come AAD nella richiesta di decriptazione (decriptazione) per autenticare esplicitamente l'utente. In questo scenario, puoi utilizzare una singola chiave per gestire più utenti (senza limiti). Uno dei vantaggi principali è che non è necessario mantenere lo stato per singoli utenti.

Un altro esempio è se la tua applicazione deve utilizzare token di connessione che contengono alcune informazioni private, come un indirizzo email. Gli input per il token di connessione potrebbero essere i dati autenticati utilizzati per un token di connessione più l'indirizzo email in testo non crittografato. Questi input vengono poi criptati, in modo che il token di connessione venga scambiato sotto forma di dati criptati aggiuntivi (AEAD).

Esempio di attacco per confuso confuso

Questo esempio mostra come un'applicazione potrebbe essere ingannata con la decriptazione del testo criptato per conto di un utente malintenzionato. In questo esempio, l'applicazione è il quercia confuso perché non è a conoscenza del fatto che l'utente malintenzionato abbia ingannato l'applicazione con l'uso improprio dell'autorità. Il risultato è che l'utente malintenzionato può visualizzare i dati decriptati originariamente criptati per un altro utente. Tieni presente che, in questo attacco, l'utente malintenzionato non ha bisogno di conoscere la chiave di crittografia, perché si basa sul confondente confuso che esegue la decriptazione.

  1. Un'applicazione diario consente agli utenti di tenere un diario privato. Ogni diario è criptato e deve essere decriptato solo dall'utente che lo ha creato.

  2. Alice crea un diario. L'applicazione cripta la voce del diario, quindi la archivia in un percorso riservato al diario di Alice.

  3. Alice invia una richiesta di visualizzazione 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.

  4. Mallory copia il diario di Alice dal luogo riservato ad Alice nel luogo riservato a Mallory.

  5. Mallory invia una richiesta per visualizzare la copia del diario di Mallory. Poiché la copia del diario di Alice si trova in un percorso riservato a Mallory, l'applicazione decripta il diario e restituisce il testo non crittografato come risposta alla richiesta di Mallory. Mallory può quindi visualizzare il diario di Alice, che non è il comportamento previsto dell'applicazione.

Per difenderti da questo tipo di attacco, l'applicazione può utilizzare una stringa non vuota come AAD per crittografia e decriptazione. AAD fornisce un controllo aggiuntivo per le richieste di decriptazione. Quando Mallory invia la richiesta di decriptazione per visualizzare la copia di Diario di Alice, Marco non riesce a meno che non sia possibile ingannare l'applicazione utilizzando l'AAD corretto.

Archiviazione o riproduzione di AAD

Prima di criptare con AAD, decidi se memorizzare l'AAD affiancato ai dati criptati o riproducilo per la decriptazione successiva.

Un motivo per archiviare AAD è semplificare l'utilizzo di AAD quando devi decriptare il testo di crittografia. Ad esempio, una riga di database potrebbe contenere sia il testo criptato sia l'AAD utilizzato quando il testo normale era criptato. Quando viene ricevuta una richiesta di decriptazione, l'applicazione può recuperare sia il testo criptato AAD sia il testo di crittografia dal database. L'applicazione può quindi utilizzare AAD per il processo di decriptazione del codice di crittografia.

Un motivo per riprodurre AAD è verificare eventuali dati non privati evitando allo stesso tempo l'archiviazione dell'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 esegui la crittografia del file. Quindi, quando viene inviata una richiesta di decriptazione per il file, puoi riprodurre l'AAD esaminando il percorso e il nome del file.

Archiviazione AAD

L'archiviazione di AAD significa che la funzione AAD viene salvata e quindi rapidamente disponibile dalla tua applicazione per l'uso futuro. Ad esempio, una tabella di database potrebbe contenere una colonna per il testo criptato e una colonna per AAD utilizzata al momento della creazione del testo criptato. Quando è il momento di decriptare il testo criptato, l'applicazione recupera l'AAD e lo utilizza per la decriptazione.

Considera un'applicazione diario progettata per mostrare una voce dell'agenda solo per l'utente che l'ha creata. Alla creazione, il diario viene criptato e salvato in un database, nella colonna ENCRYPTED_DIARY_ENTRY. Per ogni richiesta di visualizzazione di una voce di diario, l'applicazione autentica l'utente e fornisce la voce al diario.

Supponiamo che non venga utilizzato AAD (ad eccezione della stringa vuota predefinita) e ipoteticamente Mallory è riuscito a copiare i dati ENCRYPTED_DIARY_ENTRY di Alice in ENCRYPTED_DIARY_ENTRY dati di Mallory. Quando Mallory invia una richiesta di decriptazione dei dati di ENCRYPTED_DIARY_ENTRY di Mallory's (che è stata copiata dai dati di Alice), l'applicazione esegue la decriptazione senza accorgersi di essere stata ingannata. Mallory è in grado di visualizzare il diario di Alice come testo non crittografato.

Ora supponiamo che l'indirizzo email dell'utente venga utilizzato come AAD quando una voce del diario è criptata. Quando Alice crea un diario, l'applicazione archivia il suo indirizzo email non criptato nella colonna EMAIL, affiancato con i dati ENCRYPTED_DIARY_ENTRY. Immaginiamo ancora che Mallory abbia potuto copiare i dati ENCRYPTED_DIARY_ENTRY di Alice nei dati ENCRYPTED_DIARY_ENTRY di Mallory. Quando Mallory invia una richiesta di decriptazione, l'applicazione recupera l'indirizzo email di Mallory dalla colonna EMAIL per utilizzarla come AAD per la richiesta di decriptazione. L'indirizzo email di Mallory non avrà esito positivo come AAD per la decriptazione, quindi l'applicazione non consente a Mallory di visualizzare il diario di Alice come testo non crittografato.

Riproduzione AAD

La riproduzione di AAD significa che non viene archiviata ovunque, ma puoi riprodurla quando è il momento di decriptarla.

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 sia stato utilizzato "MY_PATH\MY_FILE1.enc" come AAD. Questo AAD non è memorizzato. 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 altro percorso, "MY_PATH\MY_FILE1.enc" verrà utilizzato come AAD durante la decriptazione, che è lo stesso di AAD usato durante la crittografia, quindi la decriptazione 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 decriptazione. Questo valore AAD non corrisponde al valore AAD usato per la crittografia, quindi la decriptazione avrà esito negativo.