Pesquisa de texto completo nos dados encriptados
suponha que tenho um servidor a guardar o texto encriptado (extremo-a-extremo: o servidor nunca vê texto simples).
quero ser capaz de fazer uma pesquisa de texto completo nesse texto.
Eu sei que isto é complicado, mas a minha ideia é usar o tradicional desenho de texto completo ("lista" e "correspondência" tabelas onde as palavras são armazenadas e correspondidas com ids da tabela de conteúdo). Quando os usuários enviam o texto criptografado, eles também enviam um MD5 salgado das palavras e respectivas correspondências. O sal utilizado é único para cada utilizador e é recuperado da sua senha.
(em resumo: a única diferença é que a tabela "lista" conterá palavras hashed)
Note que eu disse "quão vulnerável" em vez de "quão seguro", porque eu reconheço que não pode ser totalmente seguro.
Eu entendo o tradeoff entre recursos (busca de texto completo) e segurança (divulgando algumas informações do Índice de palavra). Por exemplo, eu entendo que um atacante capaz de obter a lista e as tabelas de correspondência pode obter informações sobre o original, o texto encriptado e , possivelmente, ser capaz de decifrar algumas palavras com a análise estatística (no entanto, sendo o sal exclusivo para cada usuário, isso precisa ser repetido para cada usuário). Quão grave seria esta ameaça? E haveria outras ameaças sérias?
declaração de exoneração de responsabilidade
O que estou tentando construir (e com a ajuda de um criptógrafo para a implementação real; neste momento estou apenas tentando para entender se isso será possível) é um produto de qualidade de consumidor que lidará com dados confidenciais, mas não totalmente secretos.
Meu objetivo é apenas fornecer algo segura o suficiente, de modo que seria mais fácil para um atacante para tentar roubar as senhas dos usuários (e.g. violação clientes - eles são os consumidores que, eventualmente), ao invés de gastar uma enorme quantidade de tempo e potência de computação tentando força-bruta-índice ou executar complicado análise estatística.
(pode ser relevante para qualquer outra pessoa que responda)
como referiu, outras soluções não são viáveis. Armazenar todos os dados dentro do cliente significa que os usuários não podem acessar seus dados de outros clientes. A encriptação do lado do servidor funcionaria, mas não conseguiremos dar aos utilizadores a segurança adicional da encriptação do lado do cliente.
a única "verdadeira alternativa" é apenas não implementar a pesquisa: embora esta não seja uma característica necessária, é muito importante a mim / a nós.o sal será protegido exactamente da mesma forma que a chave de descodificação dos utilizadores (a usada para descodificar textos armazenados). Assim, se alguém fosse capaz de capturar o sal, ele ou ela provavelmente seria capaz de capturar também a chave, criando um problema muito maior.Para ser preciso, a chave e o sal serão armazenados encriptados no servidor. Eles serão descriptografados pelo cliente localmente com a senha do Usuário e mantidos em memória; o servidor nunca vê a chave descriptografada e sal. Os usuários podem mudar senhas, então, e eles só precisam re-criptografar a chave e o sal, e não todos os textos armazenados. Esta é uma abordagem bastante padrão na indústria, tanto quanto sei.
-
Na verdade, a concepção da base de dados será a seguinte (apenas para comunicar as entradas relevantes). Este design é como você propôs em seu comentário. Não permite pesquisas de proximidade (não muito relevantes para nós) e torna a frequência menos precisa.
- tabela
content, contendo Todos textos codificados. As colunas sãocontent.idecontent.text. - Tabela
words, contendo a lista de todas as erupções cutâneas. As colunas sãowords.idewords.hash. - Tabela
match, que combina textos com traços/palavras (numa relação de um para muitos). As colunas sãomatch.content_idematch.word_id.
- tabela
teríamos que implementar recursos como remover stopwords etc. Certo. Isso não é uma grande questão (será, naturalmente, feito sobre o cliente). Eventualmente, essas listas sempre foram de utilidade limitada para utilizadores internacionais (isto é, não de língua inglesa).
Esperamos que a relação procurar / inserir seja bastante elevada (isto é, muitas pesquisas, mas inserções raras e principalmente em massa).decifrar toda a base de dados de hash é certamente possível, mas requer um ataque de Força bruta.
Suponha que o sal é mantido seguro (conforme o ponto 2 acima). Se o sal for suficientemente longo (citou 32 bits... mas porque não 320? - isso levaria muito tempo.
De facto, em primeiro lugar, o sal seria único por cada utilizador. Isso significa que um usuário deve ser atacado no momento.
Em segundo lugar, reportando palavras apenas uma vez por texto (não importa quantas vezes apareçam), a análise de frequência torna-se menos confiável.
Terceira... A análise de frequência em palavras hashed não soa tão bem como análise de frequência de uma mudança de César, por exemplo. Há de 250.000 palavras em inglês (e, novamente, nem todos os nossos usuários serão de língua inglesa), e mesmo que algumas palavras são mais comuns do que outras, creio que não seria difícil fazer este ataque de qualquer maneira. PS: os dados que vamos armazenar são mensagens, como mensagens instantâneas. Estes são curtos, contêm um monte de abreviaturas, gírias, etc. E cada pessoa tem um estilo diferente na escrita de textos, reduzindo ainda mais o risco (na minha opinião) de ataques de frequência.
3 answers
TL; DR: se isto precisar de ser seguro o suficiente para que exija encriptação de extremo a extremo por Utilizador: não o faça.
Muito tempo para um comentário, por isso aqui vai-se bem entendi:- você tem dados criptografados enviados pelo Usuário (lado cliente criptografado, então não usando o DB para lidar).
- você quer que isso seja pesquisável para o usuário (sem você saber nada sobre isso - então um bloco criptografado de texto é inútil).
- a tua proposta solução para isso é também armazenar uma lista (ou talvez parágrafo) de palavras hashed enviadas do cliente também.
Então o registo de dados pareceria como:
- coluna 1: bloco de dados cifrado
- coluna 2: (espaço) delimitada, ordenada, palavras individuais do texto encriptado acima
Então, para pesquisar, basta analisar os Termos de pesquisa e tratar os Termos tracejados como palavras para procurar o(s) parágrafo (s) de "texto" na coluna 2. Isto vai definitivamente funcionar. - basta considerar procurar texto absurdo com termos de busca sem sentido. Você ainda seria capaz de fazer algum ranking de proximidade de termos com esta abordagem.
Preocupações:
- a coluna com as palavras individualmente tracejadas como texto será incrivelmente fraca em comparação com o texto encriptado. Você está enfraquecendo muito a sua solução, pois não só há palavras limitadas para trabalhar, o texto resultante será suscetível à análise de frequência de palavras, etc.
- Se fizeres isto: armazenar separadamente um sal não relacionado com a senha. Dado que uma mesa arco-íris será fácil de criar se o seu sal é capturado (apenas palavras do dicionário) armazená-lo criptografado em algum lugar.
- Você irá perder muitos benefícios de FTS como ignorar palavras como 'a' - você vai precisar re-implementar esta funcionalidade no seu próprio, se você quer que ele (i.e. remover estes termos no lado do cliente antes de enviar os dados / termos de pesquisa).
Outras abordagens que implica não são aceitável/exequível:
- Implemente procurar do lado do cliente (todos os dados têm de existir no cliente para procurar)
- encriptação centralizada, alavancando as bases de dados construídas com funcionalidade
Entendo o argumento de que a sua abordagem fornece ao utilizador o único acesso aos seus dados (ou seja, não o consegue ver/descodificar). Eu argumentaria que esta abordagem hashed enfraquece os dados suficientemente que você poderia razoavelmente trabalhar para fora de dados de Usuários (isto é, você tem reduziu o esforço necessário ao ponto de ser muito plausível que você possa decifrar as informações de um usuário sem qualquer conhecimento de suas chaves/sais). Eu não baixaria a fasquia para descrever isto como apenas ofuscação, mas devias pensar no quão significativo isto é.
Se TEM a certeza de que enfraquecer o seu sistema para implementar uma pesquisa como esta faz sentido, e a outra abordagem não é suficiente, uma coisa que pode ajudar é armazenar os traços de palavras no texto como um lista de palavras de ocorrência única apenas (ou seja, nenhuma informação de frequência ou proximidade estaria disponível). Isso reduziria a área de superfície de ataque de sua implementação um pouco, mas também perderia os benefícios que você está insinuando que você quer, descrevendo a abordagem como FTS. Você pode obter resultados muito rápidos como este, embora como as palavras hashed essencialmente se tornam tags anexados a todos os registros que os incluem. A pesquisa, em seguida, poderia tornar-se muito rápido (à custa de seu insercao).
*só para que fique claro - gostaria de ter a certeza de que as minhas necessidades empresariais exigiram algo como isto antes de o Implementar...
Editar:
Um exemplo rápido dos problemas - diz-me que sei que estás a usar sais de 32 bits e estás a usar palavras comuns como "o". 2^32 sais possíveis = 4 bilhões de sais possíveis (isto é, não tantos se você só precisa de hash um punhado de palavras para o ataque inicial). Assumir que o sal é adicionado ou pré-adicionado, isto ainda é apenas 8 bilhões de entradas para pré-calcular. Mesmo que sejam palavras menos comuns, você não precisa criar muitas listas para garantir que você vai receber hits (se este não for o caso, seus dados não valeriam a pena pesquisar).
Em seguida, procure os sais de maior frequência para um dado bloco de texto em cada uma das nossas tabelas Salinas pré-calculadas e use a correspondência para ver se ela descriptografa corretamente outras palavras no texto. Uma vez que você tem um candidato plausível gerar a 250.000 palavra Inglês language rainbow table for that salt and decrypt the text.
Acho que podes descodificar os dados escondidos no sistema em horas a dias com acesso à base de dados.Assumo que a chave de encriptação de texto completo é derivada da senha, ou é encriptada por uma chave derivada da senha. Assim, um atacante pode testar suposições contra uma seleção de chaves de índice hashed, e assim que ela encontrar a senha, decifra todos os documentos.
Mas, mesmo que um utilizador escolha uma senha de alta entropia, a análise de frequência no índice pode revelar muito sobre o texto simples. Embora a ordem de palavras seja perdida na indexação (se você não suporta pesquisas de proximidade), você está essencialmente criando um livro de código eletrônico para cada usuário. Este índice seria vulnerável a séculos de técnicas criptanalíticas bem desenvolvidas. Os protocolos de encriptação modernos evitam o BCE e fornecem "indistinguibilidade do cifrotexto" -o mesmo texto simples produz um texto cifrado diferente cada vez que é criptografado. Mas isso não funciona com índices.
Uma abordagem menos vulnerável seria indexar e procurar no cliente. As tabelas necessárias seriam agrupadas como uma única mensagem e criptografadas no cliente, em seguida, transportado para o servidor para armazenamento. O tradeoff óbvio é o custo de transmissão desse pacote em cada sessão. O caching do lado do cliente de fragmentos de índice pode mitigar isto. custou um pouco. No final, só você pode pesar o custo de segurança de uma violação contra os custos de desempenho da indexação do lado do cliente. Mas a análise estatística possibilitada por um índice é uma vulnerabilidade significativa.O MSSQL Enterprise TDE encripta o índice de texto completo, assim como outros índices, quando definir a encriptação completa da base de dados (desde 2008). na prática, funciona muito bem, sem uma grande penalidade de desempenho. Não posso comentar como, b/C, é uma manga proprietária, mas são os médicos.
Não cobre nenhuma das suas aplicações além do seu db, mas o seu FTS. os índices funcionarão como o normal e não existirão em texto simples como fazem em MySQL ou PostGres. A MariaDB e, claro, a Oracle também têm a sua própria implementação, pelo que me lembro. MySQL e PGSQL não.Quanto às senhas, o TDE em todas as implementações usa chaves AES, que podem ser rodadas (embora nem sempre com facilidade) - de modo que a vulnerabilidade da senha cai no DBA.
O problema é que você precisa pagar pela licença total da empresa para o TDE MSSQL (ou seja, recursos não disponíveis em "standard "ou" basic " cloud and on premise editions), and you do probably for TDE in Oracle as well. Mas se o que você precisa é de uma solução rápida e tem o dinheiro para o licenciamento da empresa (provavelmente mais barato do que o desenvolvimento de sua própria implementação), implementações estão lá fora.