Invio di messaggi crittografati con RSA ibrido, AES e HMAC SHA-256

Question

Invio di messaggi crittografati con RSA ibrido, AES e HMAC SHA-256

#1 da (1 voti)

5

È una strategia sicura per inviare un messaggio crittografato di grandi dimensioni utilizzando Hybrid RSA 2048, AES 256 e autenticato con HMAC SHA-256:

Dato che Alice ha già la chiave pubblica RSA di Bob, Alice:

Genera un nuovo 128bit IV (strong PRNG)
Genera una nuova chiave di crittografia AES 256bit / CBC / PKCS7 (Kc)
Genera una nuova chiave di autenticazione AES 256bit / CBC / PKCS7 (Ka)
Crittografa il suo messaggio + Timestamp con (Kc) e IV = > (M) e
Autentica IV + (M) e con (Ka) utilizzando HMAC SHA-256 = > IV + (M) e + tag
Crittografa (Ka) + (Kc) con la chiave pubblica RSA di Bob con OAEP = > (Kc + Ka + P) e
Autentica (Kc + Ka + P) e con (Ka) utilizzando HMAC SHA-256 = > IV + (Kc + Ka + P) e + tag
Invia Bob RSA Encrypted IV + (Kc + Ka + P) e + Tag e AES HMAC-256 Messaggio IV + (M) e + Tag

Bob procede quindi a:

Estrai IV da IV + (Kc + Ka + P) e + Tag
verifica IV contro cache nonce, rifiutando messaggi con IV ripetuti
Estrai e decodifica (Kc + Ka + P) e con la sua chiave privata RSA = > (Ka) + (Kc)
Verifica IV + (Kc + Ka + P) e + Tag con (Ka) , rifiutando i messaggi non validi
Verifica IV + (M) e + Tag con (Ka) , rifiutando i messaggi non validi
Decodifica IV + (M) e + tag con (Kc)
Estrae Timestamp e Messaggio
Verifica che Timestamp non è più vecchio di Max Request Age, rifiutando i messaggi scaduti

Fondamentalmente vorrei sapere se ci sono evidenti punti deboli con l'approccio ibrido RSA / AES / HMAC SHA-256 sopra o qualcosa che chiunque farebbe diversamente?

La strategia di cui sopra è stata rivista per includere feedback di @ puzzlepalace di creazione di chiavi AES separate per la crittografia e l'autenticazione invece di derivarli dall'hash SHA-512 della chiave principale.

Qualsiasi altro feedback o suggerimento per miglioramenti sono ben accetti!

encryption hmac hash aes rsa

posta mythz 18.07.2015 - 02:00

fonte

1 risposta

Leggi altre domande sui tag encryption hmac hash aes rsa

server proxy e computer di lavoro con restrizioni Protocollo di sicurezza per adesivi / tessere NFC

score 1 · Accepted Answer

Passo dopo passo e poi nel sistema crittografico generale, mi sembra più logico.

Generate a new AES 256bit/CBC/PKCS7 Master Key (Km)

Generate a new 128bit IV (strong PRNG)

CBC va bene in quanto non c'è alcun tipo di oracle a cui l'hacker possa accedere e gli attacchi di bit-flipping sono esclusi dal tag. Random IV è corretto, 256 bit sono più che sufficienti per le dimensioni della chiave.

Generate the SHA-512 Hash of (Km) => (Hm)

Splits (Hm) into Crypt Key => (Kc) and Auth Key => (Ka)

Questo dovrebbe andare bene. Un commento, in realtà non ho familiarità con il master secret che viene espanso tramite un hash (quindi se questo è considerato best practice per favore correggimi), c'è qualche ragione per cui non si generano solo due chiavi a 256 bit? Direi che se non hai davvero bisogno di conservare le dimensioni dei pacchetti sulla rete, perché non generare solo due chiavi da 256 bit, una per AES e una per l'HMAC? È solo 256 bit in più sulla rete.

Encrypts her Message + Timestamp with (Kc) and IV => (M)e

Signs (IV)+(M)e with (Ka) using HMAC SHA-256 => (IV+(M)e+Tag)

Questo è buono, Encrypt-then-MAC è IND-CCA (cioè la migliore costruzione generica). Una nota nit-picky: un HMAC non è una firma, ma piuttosto un tag. (un tag fornisce integrità e autenticità, una firma fornisce anche non ripudio).

Encrypts (IV+Km) with Bob's RSA Public Key padded with OAEP => (IV+Km+P)e

Sends Bob RSA encrypted AES key (IV+Km+P)e and Signed AES Message (IV+(M)e+Tag)

OAEP è una buona scelta per il padding RSA, ed è IND-CCA, non vedo problemi qui.

Mi sembra che entrambi i tuoi schemi simmetrici e asimmetrici non siano suscettibili a un attacco di testo cifrato scelto, che è molto sicuro. In quanto tale, non penso che avere lo stesso IV crittografato in entrambi i cipherti di RSA e AES sia un problema. Soprattutto perché la IV non deve nemmeno essere segreta in modalità CBC (non dovrebbe essere prevedibile o riutilizzata!), E quindi potrebbe essere inviata in chiaro (magari aggiungendo il testo in chiaro IV al testo cifrato AES e calcolando il MAC di quello). Inoltre, non dovrebbe essere crittografato con la chiave pubblica dei destinatari.

Spero di esserti utile, felice di chiarire o espandere qualsiasi cosa tu abbia domande!