Qual è lo scopo del parametro entropy per DPAPI.Protect?

Dalla navigazione: link

L'entropia fornisce un vettore di inizializzazione a 16 byte (128 bit), non un sale crittografico.

In genere non è necessario mantenere il tuo IV segreto [1] , devi solo fare attenzione a non riutilizzare lo stesso IV (che non accadrà se è stato generato casualmente in quanto ci sono 2 ¹²⁸ valori possibili).

Lo scopo del vettore di inizializzazione è di randomizzare inizialmente il messaggio prima della crittografia (in genere solo il primo blocco).

Confronta Electronic CodeBook (ECB) che non ha bisogno di IV e Cifratura a blocchi di codice che ne ha bisogno.

Supponiamo che tu abbia una funzione di crittografia encrypted_block = Encrypt(block, key) che prende un blocco di dati di dimensione fissa (ad esempio 128 bit), una chiave di crittografia segreta e restituisce un blocco crittografato di dati, che può essere decodificato con block = Decrypt(encrypted_block, key) . Quindi se crittografate un file da 10 kB con una dimensione di blocco di 128 bit, allora avete 640 blocchi da crittografare. Se due blocchi sono identici nell'originale (diciamo che è un'immagine con poca entropia), i blocchi crittografati alla fine finiranno per essere identici e spesso i pattern possono essere individuati. Quindi ECB fondamentalmente divide solo un file in blocchi e applica la funzione di crittografia a ciascun blocco singolarmente (senza fare affidamento sull'output dei blocchi precedenti).

Ora vediamo uno schema come CBC che usa un vettore di inizializzazione (IV). Il primo blocco è crittografato da encrypted_block_0 = Encrypt(block_0 ^ IV, key) , dove ^ è lo XOR (bitwise exclusive o operator). Il prossimo blocco è crittografato con encrypted_block_1 = Encrypt(block_1 ^ encrypted_block_0, key) ; in questo modo si utilizza il risultato della crittografia del blocco precedente per "randomizzare" il blocco corrente prima di passare alla funzione di crittografia. Ora se non hanno usato un vettore di inizializzazione per il primo blocco, si potrebbero dedurre le cose osservando i primi blocchi di coppia. Ad esempio, se hai due file crittografati entrambi con lo stesso vettore di inizializzazione e hai visto che i primi 10 blocchi erano identici, imparerai che i primi 10 blocchi dei file di testo in chiaro sono identici e ottieni informazioni extra. Non che semplicemente conoscere l'IV nel testo in chiaro non ti aiuti affatto, poiché si trova all'interno di una complicata funzione% non lineare dellaEncrypt che non puoi invertire senza conoscere il segreto key .

EDIT: In realtà, penso di aver sbagliato a pensare che i 16 byte siano usati come vettore di inizializzazione in DPAPI; ecco un reverse engineering del DPAPI segreto di Microsoft: link

La documentazione MSDN fa un buon lavoro di spiegarlo:

A small drawback to using the logon password is that all applications running under the same user can access any protected data that they know about. Of course, because applications must store their own protected data, gaining access to the data could be somewhat difficult for other applications, but certainly not impossible.

In sostanza, se qualcuno scopre alcuni dati protetti (ad esempio una stringa di connessione crittografata memorizzata nel registro), un'applicazione semplice eseguita nel contesto dell'utente potrebbe banalmente utilizzare DPAPI per decrittografare i dati protetti.

To counteract this, DPAPI allows an application to use an additional secret when protecting data. This additional secret is then required to unprotect the data.

Technically, this "secret" should be called secondary entropy. It is secondary because, while it doesn't strengthen the key used to encrypt the data, it does increase the difficulty of one application, running under the same user, to compromise another application's encryption key. Applications should be careful about how they use and store this entropy. If it is simply saved to a file unprotected, then adversaries could access the entropy and use it to unprotect an application's data.

Memorizzare chiaramente l'entropia in testo semplice nella stessa posizione dei dati protetti sconfigge completamente lo scopo.

Il parametro viene ulteriormente spiegato come segue:

Funzione di protezione interna

pOptionalEntropy
Pointer to a DATA_BLOB containing additional entropy used to protect the data. The cbData member holds the length of the pbData member's byte string that contains the optional entropy. The DATA_BLOB used in the protection call must also be used in the unprotection call. This is the application specific "secret" mentioned earlier.
This parameter is optional and can be NULL.

Funzione di non protezione interna

pOptionalEntropy
Pointer to a DATA_BLOB containing additional entropy used when the data was protected. The cbData member holds the length of the pbData member's byte string that contains the optional entropy. This is the application specific "secret" mentioned earlier.
This parameter is optional and can be NULL. However, if the optional entropy was used in the protection call, that same entropy must be used in the unprotection call.

Quindi potresti aumentare la protezione contro altre applicazioni (o anche l'utente) usando il parametro entropy e rendendo un po 'difficile scoprire il valore di entropia.

Quindi, è OK memorizzare l'entropia come testo semplice (forse hardcode)?

Probabilmente il testo normale va bene, a condizione che la posizione sia difficile da trovare o accedere. Metterlo nella stessa posizione dei dati protetti è in qualche modo inutile.

Non sarai in grado di ottenere una "perfetta sicurezza" contro un attacco che ha già accesso all'utente e tempo e risorse sufficienti. Ma ci sono alcune piccole cose che puoi fare per rallentarle:

• Se si codifica il valore di entropia nell'applicazione, è possibile trovarlo nel file binario. Ma questo è più difficile da fare.
• Se si applica una trasformazione semplice (come XOR) al valore di entropia prima di utilizzarla, l'applicazione dovrebbe essere decompilata o il codice sorgente altrimenti compromesso in modo che un utente malintenzionato possa sapere cosa fare.
• È possibile memorizzare il valore di entropia da remoto. Ciò significa che un utente malintenzionato dovrebbe sapere dove trovarlo. E hanno bisogno di altre credenziali appropriate per accedervi. (Naturalmente, anche altre credenziali dovrebbero essere accessibili per l'applicazione, motivo per cui "la perfetta sicurezza" in questo scenario non è possibile.)