Quanto è sicura la libreria Ciphersweet per la crittografia ricercabile e perché una fuga di voci duplicate non è un problema?

Important Disclaimer: I wrote CipherSweet for my employer. Everything that follows should be taken with a grain of salt unless otherwise verified by third party security experts. Even if this answer gets a lot of votes, it must never be accepted. I'm merely attempting to answer some of the basic questions about CipherSweet's design, not answer whether or not it's secure. Trust others instead.

Il modello di sicurezza di CipherSweet è essenzialmente un compromesso di memoria temporale, che introduce il rischio di attacchi più simili a un cruciverba rispetto alle tecniche di crittanalisi tradizionali (quindi, li chiamiamo semplicemente "attacchi di cruciverba", anche se il termine più formale "attacchi di testo in chiaro parzialmente noti" ha più probabilità di trovare risultati rilevanti nella letteratura accademica).

Da questo punto di vista, il design complessivo di può di CipherSweet essere sicuro, ma solo se si presta attenzione nella progettazione degli indici ciechi nella propria applicazione. Ci sono alcune considerazioni:

1. Quanti bit di ciascun indice cieco conserverai?
   • Meno bit aumentano le probabilità di collisioni su una determinata query SELECT, il che significa più falsi positivi da filtrare dopo la decrittografia.
   • Tuttavia, meno bit diminuiscono anche l'utilità di un indice cieco.
2. Quanti indici ciechi creerai per una determinata colonna crittografata?
   • Maggiore è il numero di indici che crei, più metadati rischiano di filtrare agli autori di attacchi.

Certamente, la sicurezza di questo design vale la pena di parlare solo se alcune altre ipotesi sono vere:

1. Ogni indice cieco ha una chiave distinta.
2. La funzione di hash (o KDF) utilizzata per trasformare il testo in chiaro in un indice cieco è adeguatamente sicura (ad esempio nel modello di oracolo casuale).
3. La crittografia stessa è sicura (ad esempio, AEAD con un livello di sicurezza superiore a 127 bit rispetto a tutti gli attacchi pratici noti).

Per comprendere in che modo vengono soddisfatte queste ipotesi, consulta la documentazione interna di CipherSweet . Ma in breve, le risposte sono:

1. CipherSweet utilizza chiavi distinte per campo e per indice, derivato da una chiave master .
2. A novembre 2018, HMAC-SHA384 e BLAKE2b rimani integro.
3. A novembre 2018, AES-CTR + HMAC-SHA2 e XChaCha20- Poly1305 rimane integro.

Detto questo, la domanda senza risposta è: Come determiniamo un livello di perdita di informazioni non sicuro?

• Ovviamente, creando un indice cieco distinto $plaintext[0] , $plaintext[1] , ... si perderebbero interi indici in chiaro dagli indici.
  • Non è necessario interrompere la crittografia in questo caso. Basta studiare modelli e commettere voci fittizie e trattarlo come una cifratura di sostituzione molto inefficiente.
• Al contrario, un singolo indice cieco letterale dell'intero testo in chiaro, troncato a 16 bit, quasi certamente non perde nulla di utile per gli aggressori.
  • Dato un set di dati sufficientemente ampio, le collisioni sarebbero molto comuni.
  • Ovviamente, questo sfugge quasi allo scopo di creare persino un indice cieco.

Inoltre, CipherSweet ti consente di creare indici ciechi composti . Ad esempio, potresti eseguire l'hash insieme:

1. La prima iniziale del nome della persona (se applicabile)
2. La prima iniziale del cognome della persona (se applicabile)
3. Le ultime 4 cifre del numero di previdenza sociale della persona
4. Una singola lettera che identifica il loro sesso / sesso (se applicabile)

Ciò aumenta notevolmente lo spazio delle chiavi di possibili testi in chiaro per un dato indice cieco, anche se lo spazio delle chiavi di ogni singolo ingresso è limitato. Ciò è particolarmente utile per crittografia / ricerca con campi booleani .

Considerato tutto quanto sopra, non so se riuscirai a ottenere una risposta sufficiente sull'opportunità o meno di fidarti di CipherSweet su questo sito web. Le domande senza risposta non sono esattamente semplici da rispondere e richiedono un'analisi approfondita.

Detto questo: è certamente possibile usare impropriamente CipherSweet in un modo che mina i suoi obiettivi di sicurezza. È uno strumento.

Credo che, a meno che qualche difetto profondo non venga scoperto nella progettazione del protocollo, è DOVREBBE essere possibile utilizzare CipherSweet in modo sicuro. E anche se è sicuro, quasi sicuramente vorrai un esperto di sicurezza per ricontrollare come lo usi.

Disclaimer: while I looked into the design and implementation of ciphersweet back when it was published (or at least when I became aware of it), I didn't perform a full-blown audit & proof of security of the design, and I didn't look into the PHP implementation in depth (in large parts because I do not do much PHP work). Do not mistake this for an audit report (I only make those when I'm paid for it :P)

Ciphersweet usa un suono piuttosto noioso, un design noioso; Scott lo spiega, insieme alle affermazioni sulla sicurezza di Cyphersweet, nella sua risposta, quindi non lo ripeterò più. Il punto principale di Ciphersweet, IMO, è che è più sicuro e più difficile incasinare rispetto alle alternative.

La "fuga di voci duplicate" che menzioni non si applica ai record completi (quelli sono crittografati con crittografia standard non deterministica) ma agli indici ciechi: se indichi, per esempio, lo stato di HIV, quindi qualcuno con accesso in lettura al database può capire quali documenti hanno lo stesso stato di HIV, e da lì probabilmente recupera lo stato di HIV per tutti i record.

Questa è una fuga di informazioni fondamentale per gli indici ciechi: se hai sufficienti informazioni su SELECT su tutte le righe con una data (funzione dello) stato dell'HIV, hai abbastanza informazioni da controllare se due file hanno lo stesso stato di HIV, quindi la crittografia più elaborata non sarà di aiuto in questo caso (incluso l'uso di crittografia deterministica, crittografia che preserva l'ordine / rivelatore, ...).

La buona notizia è che, a differenza di altri design (come la crittografia che rivela gli ordini), gli hash con chiave (sotto una chiave sconosciuta) non rivelano più informazioni se i valori sono uguali.

Ovviamente, non è sufficiente (come mostrato con l'esempio di stato dell'HIV), quindi ci sono 3 mitigazioni principali che puoi usare (e Ciphersweet le supporta tutte):

1. il più ovvio è non aggiungere indici ciechi su dati molto sensibili: se non vuoi esporre i dati sullo stato dell'HIV, perché stai creando un indice per interrogarli efficientemente?

2. Usa indici composti: se i dati su cui devi indicizzare sono troppo bassa entropia per essere inseriti in un indice cieco (ad esempio, stato dell'HIV), puoi aggiungerlo insieme ad altri dati (la documentazione fornisce l'uso del SSN in quell'esempio) e supporta SELECT record con un dato stato dell'HIV e un dato SSN.

   Questa è, IMO, l'opzione meno utile, dato che puoi direttamente SELECT di SSN (supponendo che tu abbia un indice cieco su SSN) e poi controlli lo stato dell'HIV nel record decrittografato. Riservalo nei casi in cui non puoi avere un indice su uno dei campi (perché sono troppo a bassa entropia e / o alta sensibilità).

3. tronca il valore HMAC, in modo da ridurre la perdita di informazioni: diciamo che si dispone di record paziente, tutti con un nome univoco e supportano la selezione da esso [0]. Potrei verificare se esiste un determinato paziente aggiungendo un record (tramite l'applicazione) con quel nome, quindi controllando il database per un secondo record con lo stesso hash del nome, anche se l'applicazione stessa non mi concederà il permesso di cercare pazienti per nome.

   Con un hash troncato, puoi fare in modo che ogni ricerca nell'indice cieco restituisca (in media) un piccolo numero di record; dì, se vuoi avg. 3 record per query, su 1 000 000 di record, si vorrebbe un hash con dimensione log2 (10⁶ / 3) ~ 18 bit. Ciò rende impossibile lo scenario che ho descritto.

   Non credo che Ciphersweet fornisca un supporto particolare per l'evoluzione delle dimensioni degli indici ciechi man mano che la dimensione del database aumenta, sebbene dovrebbe essere fattibile. Per fortuna, l'unico problema con il non ridimensionamento di un indice cieco man mano che il database cresce, è un leggero sovraccarico di prestazioni: se il DB diventa 10 × più grande e ora contiene 10.000.000 di record, mantenendo lo stesso indice di 18 bit cieco in avg. 30 record selezionati, che l'applicazione decodifica e filtra; decifrare 30 record per trovare quello a cui sei interessato dovrebbe essere abbastanza veloce.

[0] In un caso d'uso del mondo reale, probabilmente sosterrai la selezione con una versione normalizzata (in minuscolo, spogliata di punteggiatura) del nome; Ciphersweet supporta gli indici funzionali.

TL; DR: Ciphersweet è sicuro, probabilmente molto più della maggior parte delle alternative; ci sono alcune avvertenze da tenere a mente, che esistono in tutti i database crittografati, e alcuni problemi operativi, ma sono tutti molto gestibili.