Crittografia simmetrica o asimmetrica per Token Web JSON?

Question

Crittografia simmetrica o asimmetrica per Token Web JSON?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

8

Stiamo pianificando di utilizzare JSON Web Tokens (JWT) per il nostro server di autenticazione e sto valutando l'approccio di crittografia da adottare per il token JWE.

Sembra che ci siano due opzioni per la gestione della chiave di crittografia simmetrica:

L'emittente / destinatario pre-condivide una chiave simmetrica e crittografa tutti i token che lo utilizzano; la chiave simmetrica non è inclusa nel messaggio.
L'emittente genera una chiave simmetrica per token, quindi crittografa il token utilizzando la chiave pubblica del destinatario e lo include nel messaggio.

Non mi sembra che ci siano vantaggi intrinseci per la sicurezza di entrambi, a patto che vengano utilizzati algoritmi sufficientemente potenti e dimensioni chiave abbastanza grandi.

Sembra che la differenza principale sia che nel primo caso il destinatario deve fidarsi dell'emittente per non perdere la chiave pre-condivisa, mentre nel secondo caso solo il destinatario ha la chiave di decrittazione necessaria. Tuttavia, dato che il payload di questo token JWE sarà un token JWS firmato, il destinatario deve anche avere una strong relazione di fiducia con l'emittente e deve fidarsi di loro per non far trapelare la propria chiave privata di firma, quindi questo non sembra un grande problema.

Dato che l'opzione 1 produce un token molto più piccolo (non avendo una chiave simmetrica crittografata in esso incorporata) c'è una buona ragione per preferire l'opzione 2?

cryptography json encryption

posta Greg Beech 26.03.2013 - 16:10

fonte

3 risposte

Leggi altre domande sui tag cryptography json encryption

BitLocker su una macchina virtuale è ancora compatibile con FIPS 140-2? Qual è la migliore pratica per archiviare un segreto sul cloud?

score 3 · Answer 1

Direi che il vantaggio principale dell'opzione 2 è che non è necessario distribuire (o aggiornare nel caso in cui venga compromesso) una chiave pre condivisa. Se puoi in qualche modo assicurarti di avere un meccanismo sicuro per trasferire la chiave pre condivisa, (cioè c'è solo una persona con cui devi farlo, e sei sicuro di parlare con loro al telefono e di pronunciare la chiave - - Ovviamente questo ha dei rischi per la sicurezza (tocchi telefonici, chiavi scritte su carta all'altra estremità, ecc.) che dovrei valutare) Vorrei andare per l'opzione 1. Tuttavia se vuoi creare qualche interfaccia API dove i client possono connettersi e iniziare connessioni sicure senza uno scambio di chiavi fuori banda, vai per l'opzione 2.

score 1 · Answer 2

Per l'opzione 1 sia l'emittente che il destinatario devono mantenere segreta la chiave simmetrica. Se il destinatario è un servizio cloud multi-tenant prodotto e gestito da una parte diversa, potrebbe essere troppo rischioso, se qualcuno accede ai file di configurazione o al database consentirà loro di creare token per impersonare chiunque nel sistema.

L'opzione 2 attribuisce la responsabilità di mantenere la chiave segreta sull'emittente. Se sei il destinatario, questo allevia molti problemi di responsabilità e sicurezza poiché stai solo tenendo la chiave pubblica. In qualità di emittente acquisisci maggiore fiducia in quanto sei l'unico responsabile della sicurezza della tua chiave di crittografia privata.

Quindi in realtà dipende da quanto ti fidi del destinatario per mantenere la chiave simmetrica al sicuro, e se sei il destinatario sei disposto a scommettere il tuo prodotto e la tua reputazione puoi tenerlo al sicuro.

score 1 · Answer 3

Voglio solo mettere questo qui per le persone che lo trovano tramite Google (attualmente 2 ° risultato per cercare jwt public private vs symmetric )

L'opzione 2 qui è una perdita di sicurezza - se l'emittente crittografa un messaggio utilizzando la chiave pubblica del ricevitore, allora sì il ricevente è l'unica persona che può decodificare le informazioni, ma con JWT la sicurezza necessaria è che JWT è completamente intatto e non è stato modificato. La crittografia con una chiave pubblica non lo fa: chiunque potrebbe fare la stessa cosa e impersonare l'emittente .

La vera soluzione è FIRMARE il token utilizzando la chiave PRIVATE dell'emittente, quindi chiunque può confermare utilizzando la chiave PUBLIC dell'emittente che l'emittente ha effettivamente confermato tale autorizzazione nel JWT.