crittografia busta (utilizzando KMS) vs ECDH

2

al lavoro ho implementato la crittografia di buste di base quando invio messaggi a un client. Sto usando AWS KMS e ho una chiave master lì. Ricevo una chiave dati, crittografare il messaggio con AES-GCM e inviare il messaggio con la chiave dati crittografata, IV, tag, ecc. Il client chiama quindi AWS KMS per decrittografare la chiave dati per decodificare il messaggio. L'ho implementato guardando i documenti di AWS. Sto memorizzando la chiave dati per un po 'di tempo prima di riutilizzarla prima di crearne una nuova.

Un collega, che è meglio della crittografia di me, pensa che questo non sia sicuro a causa dell'invio della chiave con il messaggio, che questo potrebbe portare a capire la chiave principale? Raccomanda ECDH che ha una migliore distribuzione delle chiavi, utilizzando un segreto condiviso con chiavi private / pubbliche per generare la chiave AES. Il problema con questo credo è che ho bisogno di memorizzare una coppia di chiavi pubblica / privata da qualche parte, ed entrambi questi metodi hanno bisogno di accedere ad un segreto (chiave KMS o chiave privata).

Sto cercando altre opinioni su quanto siano sicuri questi diversi metodi. Quali sono le differenze nella vulnerabilità?

Modifica: Chiarimento: la chiave master è una chiave specifica creata solo per crittografare le chiavi dati per questi messaggi su un client specifico, nient'altro. Documenti di AWS che ho utilizzato: link

    
posta KTrum 18.11.2018 - 12:59
fonte

1 risposta

1

Matematicamente, sei corretto sul fatto che se la tua chiave dati viene generata correttamente utilizzando un generatore di numeri pseudocasuali crittograficamente sicuro, la chiave master non può essere invertita da un messaggio (supponendo che AES sia integro). Ma dal punto di vista operativo, questo schema fornisce un "Presepe" a un utente malintenzionato che cerca di indovinare la chiave principale. Abilita un attacco "testo in chiaro noto".

Considera il caso in cui un avversario crede di avere parte della tua chiave principale. Può usare qualsiasi messaggio intercettato da questo sistema come test per vedere se le sue ipotesi sono corrette. Oppure può srotolare l'algoritmo, nel caso in cui tale attacco contro AES dovesse mai essere conosciuto.

Questo schema non sta seguendo il principio di "una chiave dovrebbe essere usata per un singolo scopo". Poiché la chiave principale risiede ancora in ogni messaggio, ogni chiave dati ora condivide la chiave principale con tutte le altre chiavi.

Detto questo, non conosco abbastanza bene il KMS di AWS per sapere come è configurato il tuo sistema, ma tutti i sistemi KMS con cui lavoro gestiscono le chiavi concedendo ai singoli utenti l'accesso alle sole chiavi dell'applicazione. Nessun utente potrebbe mai avere accesso all'utilizzo della chiave master effettiva del sistema per crittografare direttamente una chiave dati. Quindi è possibile che la tua descrizione non sia completa, e ciò a cui ti sei riferito come una chiave master potrebbe semplicemente riferirsi a una chiave specifica dell'applicazione. In tal caso, la perdita della tua chiave non porterà alla perdita delle altre chiavi nel tuo KMS. Le altre chiavi della tua organizzazione non sarebbero state compromesse anche se la tua chiave fosse.

Anche in quel caso, continuerei a prendere in considerazione l'idea di prendere il consiglio del collega e di passare a utilizzare una soluzione chiave asimmetrica come quella che ha descritto per lo scambio di chiavi, invece di crittografare le chiavi dati direttamente con la chiave principale. È ancora possibile avere il mittente e il destinatario utilizzare il KMS per decrittografare le chiavi private, poiché le chiavi private non vengono mai inviate con i messaggi. Rimuove l'attacco del testo in chiaro noto contro la chiave master.

    
risposta data 18.11.2018 - 14:02
fonte

Leggi altre domande sui tag