Un indice di ricerca Lucene è effettivamente una backdoor per la crittografia a livello di campo?

Question

Un indice di ricerca Lucene è effettivamente una backdoor per la crittografia a livello di campo?

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

4

Per proteggere le informazioni personali identificabili (PII) in un database SQL, abbiamo implementato la crittografia a livello di campo. Tuttavia, dobbiamo consentire la ricerca di testo completo rispetto ad alcuni di questi dati.

Un'idea che stavo considerando era la creazione di un indice di ricerca Lucene dei valori non crittografati, ma assicurando che tutti i campi contenenti PII siano indicizzati ma non memorizzati.

Il processo funzionerebbe in questo modo:

L'utente invia per esempio un numero ID nazionale parziale in un modulo di ricerca nell'applicazione.
L'applicazione invia la query a Lucene.
Lucene restituisce una raccolta di documenti. I documenti non contengono alcuna informazione personale; piuttosto ogni documento contiene il valore PK del record corrispondente nel database SQL.
L'applicazione recupera i record corrispondenti dal database e decodifica i valori da visualizzare all'utente.

Tuttavia, questo lascia aperta la domanda, se qualcuno dovesse ottenere l'accesso in lettura ai file di indice di Lucene, potrebbe ricostruire i valori non crittografati?

encryption

posta user5568265 19.01.2016 - 20:05

fonte

2 risposte

1

Siccome Lucene non pretende di essere sicuro contro un simile attacco, non puoi supporre che lo sia. Forse è sicuro contro un tale attacco questa versione, ma essendo questo non è visto come parte del suo set di funzionalità, che potrebbe cambiare in qualsiasi patch minore. Quindi devi presumere che non sia sicuro.

risposta data 20.01.2016 - 04:25

fonte

Leggi altre domande sui tag encryption

John The Ripper Nome del formato del testo cifrato sconosciuto richiesto CVSS v3 valuta l'impatto della vulnerabilità sull'host?

score 2 · Accepted Answer

Secondo un articolo del 2013 , la risposta a questa domanda sembra di essere, "Sì, a meno che non ti dispiaccia che il tuo indice di ricerca sia sostanzialmente inutile.":

Terms are stored in our classic inverted list, for each term there is a list of documents and, optionally, the position within that document. It's quite possible, though tedious, to reconstruct a document from the list of terms in the index. They may not be easily readable by a human because the terms have been through the entire analysis chain; think of stemming, synonym substitution, any of the transformations, and more, listed here. While these can be hard to glance at and read, the document so reconstructed should be considered complete; sensitive information is available.

[...]

Naturally ... the question arises "can't we encrypt [the index files]"? Sure, we can. It's just that doing so leads to some surprising results, often making the resulting index next to useless. Here's why.

A decent encrypting algorithm will not produce, say, the same first portion for two tokens that start with the same letters. So wildcard searches won't work. Consider "runs", "running", "runner". A search on "run*" would be expected to match all three, but wouldn't unless the encryption were so trivial as to be useless. Similar issues arise with sorting. "More Like This" would be unreliable. There are many other features of a robust search engine that would be impacted, and an index with encrypted terms would be useful for only exact matches, which usually results in a poor search experience.