Encrypt + Dati di firma: PKCS # 7 / CMS o fai-da-te?

Naviga le tue risposte
2

Attualmente sto salvando un array di chiavi AES in un portachiavi come JSON, salvato come un file di testo / una colonna di testo SQL: 

{    
    [
       {
          encryptedAesKey:RsaEncryptedBytesBase64Encoded==,
          signature:RsaSignatureBytesBase64==,
          keyId:0,
       },
       {
          encryptedAesKey:RsaEncryptedBytesBase64Encoded==,
          signature:RsaSignatureBytesBase64==,
          keyId:1,
       }
    ]
    signature:HashAboveKeychainThenRsaSignatureBytesBase64==
}

Solo il titolare della chiave privata (ad esempio Alice) può decodificare le chiavi AES. Alice ha anche la sua chiave pubblica, quindi può verificare la firma prima dell'uso. Questo la protegge da Chuck che potrebbe interrompere la decrittazione AES di dati già crittografati creando una chiave AES casuale, crittografandola con la chiave pubblica di Alice e scrivendo dove viene salvato il JSON. Ma Chuck non può firmare così Alice non utilizzerà accidentalmente dati errati.

Quanto sopra ha funzionato per molti mesi, ma CMS / PKCS # 7 sembra interessante dal momento che è già stato progettato per la sicurezza e l'integrità dei dati definendo data envelope (encrypt) e data signature (signing).

Domanda: Oltre all'interoperabilità, quali ulteriori vantaggi si otterrebbero andando sulla rotta CMS / PKCS # 7?

    
posta DeepSpace101 04.02.2013 - 23:35
fonte

2 risposte

5

Non caricare la tua crittografia . Se decidi di inventare il tuo formato, allora sei da solo. La storia della crittografia è piena di persone che hanno inventato il proprio formato e hanno fallito in modo orribile; e, più precisamente, la storia della crittografia è non piena o persone che hanno inventato il loro formato e se la sono cavata. Queste cose sono difficili da eseguire correttamente e non puoi testare se ci sei riuscito o meno (puoi testare per funzionalità, non per sicurezza).

CMS (il nuovo nome per PKCS # 7) ha i doppi vantaggi di:

  1. essendo stato standardizzato e schierato sul campo per un lungo periodo di tempo, quindi le sue potenziali insidie avrebbero dovuto essere ben comprese ormai;
  2. già implementato in un numero di framework e librerie. Come al solito, il software che è più facile da implementare correttamente è il software che è già implementato correttamente.

Quindi, fai un favore a te stesso, usa CMS.

    
risposta data 05.02.2013 - 00:21
fonte
0

L'interoperabilità non sembra essere in cima alla tua lista dei requisiti. A meno che tu non abbia una libreria che supporta CMS con una qualità che corrisponda alle tue aspettative, CMS / PKCS # 7 potrebbe facilmente risultare eccessivo dato la sua complessità.

Se la tua applicazione ha un modo sicuro per archiviare i segreti di root accanto al database SQL, probabilmente stai meglio codificando tutte le tue chiavi in un blob, e usa una modalità di crittografia autenticata come AES GCM ( NIST 800-38D ) o AES CCM (NIST 800-38C ). L'unica chiave radice AES viene salvata nell'archivio protetto. Non utilizzerai alcuna chiave pubblica, ma dalla tua descrizione non sembra che tu ne abbia realmente bisogno (un'applicazione che accede ai propri dati).

    
risposta data 10.02.2013 - 21:17
fonte

Leggi altre domande sui tag

come bypassare "header" in php C'è un valore nella memorizzazione delle password nella propria tabella con chiavi crittografate o con hash?