Altri dati autenticati

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

I dati autenticati aggiuntivi (AAD) sono qualsiasi stringa trasferita a 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 decapitato confuso. La stringa AAD non deve essere più grande 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 che per la decriptazione.

AAD è associato ai dati criptati, perché non puoi decriptare il testo di crittografia a meno che tu non conosca l'AAD, ma non viene archiviato come parte del testo di crittografia. AAD non aumenta la forza della crittografia del testo di crittografia. Si tratta invece di un controllo aggiuntivo da parte di Cloud KMS per autenticare una richiesta di decriptazione.

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 criptato.

AAD non viene registrato da Cloud Audit Logs.

Quando utilizzare AAD

Un esempio di utilizzo di AAD è quando la tua applicazione funge da proxy wrap/unwrap con una singola chiave e un numero illimitato di client, con ciascun client in confini 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 (illimitati). 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. I dati inseriti nel token di connessione sono i dati autenticati utilizzati per un token di connessione oltre all'indirizzo email in testo non crittografato. Questi input vengono quindi criptati, di conseguenza il token di connessione che viene scambiato è nel formato Additional Encrypted Authenticated Data (AEAD).

Esempio di attacco di con ovunque

Questo esempio mostra in che modo un'applicazione potrebbe essere ingannata per decriptare il testo criptato per conto di un utente malintenzionato. In questo esempio l'applicazione è il vice confuso perché non è a conoscenza del fatto che l'utente malintenzionato abbia ingannato l'applicazione in modo da usarne in modo improprio l'autorità. Il risultato è che l'utente malintenzionato può visualizzare i dati decriptati che erano stati originariamente criptati per un altro utente. Nota che in questo attacco l'utente malintenzionato non ha bisogno di conoscere la chiave di crittografia, perché si basa sul viceconfuso per eseguire la decriptazione.

  1. Un'applicazione diario consente agli utenti di mantenere un diario privato. Ogni voce del diario è criptata e deve essere decriptata solo dall'utente che ha creato la voce del diario.

  2. Alice crea un diario. L'applicazione cripta la voce del diario, quindi archivia la voce del diario criptato in una posizione riservata alle voci del diario che appartengono ad Alice.

  3. Alice invia una richiesta per visualizzare il diario. Poiché la voce di 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. Maria copia il diario di Alice dalla posizione riservata ad Alice nella località riservata a Maria.

  5. Maria invia una richiesta per visualizzare la copia del diario di Maria. Poiché la copia del diario di Alice si trova in una posizione riservata a Maria, l'applicazione decripta la voce del diario e restituisce il testo normale come risposta alla richiesta di Maria. Mallory può quindi visualizzare il diario di Alice, che non è il comportamento previsto della domanda.

Per difenderti da questo tipo di attacco, l'applicazione può utilizzare una stringa non vuota come AAD per la crittografia e la decriptazione. L'AAD offre un controllo aggiuntivo per le richieste di decriptazione. Quando Maria invia la richiesta di decriptazione per visualizzare la copia di Diario della voce del diario di Alice, la richiesta di Maria non avrà esito positivo a meno che non sia anche in grado di ingannare l'applicazione utilizzando AAD corretto.

Memorizzazione o riproduzione di AAD

Prima di eseguire la crittografia con AAD, decidi se memorizzare AAD con i dati criptati o riprodurre l'AAD per una successiva decriptazione.

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

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 cripti il 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 in corso...

L'archiviazione di AAD comporta l'archiviazione di AAD e l'applicazione sarà facilmente disponibile per l'utilizzo futuro. Ad esempio, una tabella di database potrebbe contenere una colonna per il testo di crittografia e una colonna per l'AAD utilizzato al momento della creazione del testo di crittografia. Quando è il momento di decriptare il testo di crittografia, l'applicazione recupera l'AAD e lo utilizza per la decriptazione.

Valuta un'applicazione diario progettata per mostrare una voce del diario solo all'utente che l'ha creata. Quando viene creata una voce del diario, questa viene criptata e quindi salvata in un database, nella colonna ENCRYPTED_DIARY_ENTRY. Per ogni richiesta di visualizzazione di una voce di diario, l'applicazione autentica l'utente e quindi fornisce la voce al diario all'utente.

Supponiamo che non venga utilizzato alcun AAD (diversa dalla stringa vuota predefinita) e che in teoria Mallory sia riuscito a copiare i dati ENCRYPTED_DIARY_ENTRY di Alice nei dati ENCRYPTED_DIARY_ENTRY di Mallory. Quando Maria invia una richiesta di decriptazione per i dati ENCRYPTED_DIARY_ENTRY di Maria (copiati dai dati di Alice), l'applicazione esegue la decriptazione senza accorgersi di essere stata ingannata. Maria è in grado di vedere il diario di Alice come testo non crittografato.

Supponiamo ora che l'indirizzo email dell'utente venga utilizzato come AAD quando una voce del diario è criptata. Quando Alice crea una voce del diario, l'applicazione archivia il suo indirizzo email non criptato nella colonna EMAIL, affiancato dai dati di ENCRYPTED_DIARY_ENTRY. Supponiamo ancora che Maria abbia copiato i dati di ENCRYPTED_DIARY_ENTRY di Alice nei dati di ENCRYPTED_DIARY_ENTRY di Maria. Quando Mallory invia una richiesta di decriptazione, l'applicazione recupera l'indirizzo email di Mallory dalla colonna EMAIL da utilizzare come AAD per la richiesta di decriptazione. L'indirizzo email di Mallory non avrà esito positivo come AAD per la decriptazione, pertanto l'applicazione non consente a Mallory di visualizzare la voce del diario di Alice come testo non crittografato.

Riproduzione di AAD

La riproduzione di AAD significa che non è archiviata ovunque, 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. 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, "MY_PATH\MY_FILE1.enc" verrà utilizzato come AAD durante la decriptazione, che corrisponde all'AAD utilizzato durante la crittografia, in modo che la decriptazione possa 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 utilizzato per la crittografia, quindi la decriptazione avrà esito negativo.