Posso usare un KEK anche per proteggere i dati?

Naviga le tue risposte
1

Il mio cliente desidera che la mia organizzazione sviluppi il proprio sistema in modo tale che le chiavi attualmente utilizzate per proteggere la riservatezza delle altre chiavi durante il trasporto vengano utilizzate anche per proteggere la riservatezza dei dati nello stesso messaggio. Sospetto che questa potrebbe essere una cattiva idea, ma è generalmente valida in tutti i casi, e in tal caso perché?

Ulteriori dettagli

I KEK stanno proteggendo le chiavi inviate al destinatario nel messaggio presente. È un modello chiave stratificato; non importa per cosa sono usate le chiavi trasmesse. Lo stesso messaggio viene inviato a più destinatari, ma solo un sottoinsieme può accedere alle chiavi che contiene. Alla mia organizzazione viene richiesto di utilizzare lo stesso KEK per proteggere anche alcuni dati nel messaggio. Per quanto riguarda le chiavi, solo un sottoinsieme di destinatari può accedere a tali dati. Il punto della questione è se la protezione dei dati debba essere un problema separato dalla protezione delle chiavi.

Più formalmente (come richiesto):

  • Un messaggio messaggio M in un luogo pubblico in cui può essere richiamato dai destinatari B, C e D.
  • Il messaggio M contiene sotto-messaggi Mb, Mc e Md destinati esclusivamente al destinatario corrispondente, B, C o D rispettivamente.
  • Chiavi di crittografia chiave Kb, Kc e Kd sono state precedentemente rilasciate a B, C e D tramite un mezzo offline.
  • Ogni sottomessaggio Mn contiene una chiave crittografata destinata al destinatario N, K'n, protetta dal KEK precedentemente emesso: E (K'n, Kn).
  • Ogni sottomessaggio Mn contiene anche dati di testo semplice, Di, destinati al destinatario I ma attualmente leggibili agli altri destinatari. Sotto questa evoluzione, questo sarà sostituito con E (Dn, Kn).

Quindi: A - > B, C, D: M

dove (oggi):

M = E (K'b, Kb) + E (K'c, Kc) + E (K'd, Kd) + Db + Dc + Dd

e dopo l'evoluzione:

M = E (K'b, Kb) + E (K'c, Kc) + E (K'd, Kd) + E (Db, Kb) + E (Dc, Kc) + E (Dd, Kd)

    
posta D.H. 17.04.2016 - 10:07
fonte

1 risposta

2

Sembra OK.

Key Encrypting Key (KEK) è un nome abbastanza confuso. Mette l'accento sul fatto che una chiave particolare viene utilizzata per crittografare un'altra chiave (che a sua volta crittografa i dati), come se questo fatto nudo aumentasse in qualche modo la sicurezza. Non è così. La sicurezza aggiuntiva viene da qualcos'altro e (da me) il nome di questo schema dovrebbe essere Chiave crittografata separatamente per riflettere ciò che è veramente importante qui.

La sicurezza aggiunta deriva dal fatto che è possibile dividere moduli software o persone o dispositivi in grado di visualizzare chiavi o dati (crittografati o semplici). Tu separa un ambiente interno e lascia il resto nel perimetro di sicurezza esterno. L'esterno:

  • non conosce il segreto più importante (ovvero KEK)
  • ma è più accessibile agli estranei, in quanto fornisce molte funzioni e deve accettare vari input di dati

L'interno deve essere separato da questo; ha bisogno di avere caratteristiche esattamente opposte. L'interno è in genere solo la chiave di crittografia (un modulo software), la chiave decryptor (idem), l'archivio che contiene il KEK (un modulo software o un dispositivo hardware) e le persone che possono accedervi.

Nella tua situazione, capisco le richieste dei clienti di aggiungere alcuni NewData (per essere crittografati con KEK). Penso che sia sicuro se e solo se non esponga l'Inside a nessun rischio aggiuntivo che sia:

  • ottenere i dati NewData non comporta alcun rischio aggiuntivo; ovvero NewData non proviene dal perimetro esterno dell'app, quindi è gratuito / esente da overflow
  • consegnare i nuovi dati a destinazione non comporta alcun rischio aggiuntivo; non richiede di contattare alcuna parte dal perimetro esterno
  • (ovviamente) la crittografia e la decrittografia di NewData vengono eseguite dagli stessi componenti che già conoscono KEK - il KEK non viene messo a rischio aggiuntivo perdendolo in altri componenti,
  • (ovviamente) usi un normale cifrario, come AES, che è immune agli attacchi in chiaro. Le chiavi che hai usato per crittografare erano pseudo-casuali, ma NewData poteva essere noto per l'aggressore,
  • (ovviamente) il NewData non richiede che altre persone abbiano accesso a Inside.

Se tutto ciò non è vero, hai già alcuni punti di partenza per analizzare e comunicare i rischi coinvolti.

    
risposta data 17.04.2016 - 19:30
fonte

Leggi altre domande sui tag

Il wifi pubblico pone un rischio per la sicurezza degli accessi esistenti? Funzioni nei linguaggi comuni lato server che vengono utilizzati per eseguire il codice [chiuso]