Quão inseguro é o AES-128-CTR para criptografar qualquer tipo de dados usando o formato de arquivo de armazenamento de chave Ethereum?
On Novembro 18, 2020 by adminEstou usando o formato de arquivo de armazenamento de chaves Ethereum para criptografar quaisquer outros dados, como texto simples ou JSON.
Aqui está um exemplo de pseudocódigo da implementação:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Com este código, posso gerar o arquivo keystore parecido com este:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Este é o arquivo padrão que armazena milhões de dólares de pessoas no Ethers.
Perguntas:
- Isso é seguro?
- Em caso negativo, por quê?
- Em caso afirmativo, também é seguro criptografar texto simples ou JSON (sem formato hexadecimal)?
- É seguro definir um
kdfparams.n
?
Editar: para esclarecer por que estou perguntando isso, é porque outra pessoa disse o seguinte:
Isso não é seguro de todo. Esta implementação contém muitos erros básicos. Um exemplo é usar um gerador de número aleatório inseguro, que destrói totalmente a segurança da criptografia. Outro é usar AES- 128-CTR sem autenticação.
Comentários
- Primeiro, defina ” secure ” . Mas por qualquer definição razoável disso, com uma senha da mesma categoria que ‘ 1234 ‘, e texto simples tão grande e redundante, nada utilizável é seguro.
- Seguro em termos de muito, muito difícil de quebrar, mesmo se for um bom criptógrafo. L edite-me para esclarecer que seria uma senha muito forte.
- Agora, defina ” break ” . Isso é encontrar a senha original? Adivinhando o texto simples de um texto cifrado? Adivinhando parte do texto simples de muitos textos cifrados que compartilham algum? Adivinhando um texto simples de muitos textos cifrados e todos os outros textos simples? Podemos obter ajuda de um executável rodando na mesma máquina (e se sim, exatamente qual CPU com qual patch de microcódigo? O AES-NI é usado?). Podemos usar EMI como canal lateral? Um keylogger, hardware ou software sotfare? Na verdade, o que ‘ é a implementação de randomBytes, que tem uma influência?
- Você não pode responder a essa pergunta olhando para o psuedocode. A implementação real pode conter todos os tipos de vulnerabilidades e canais secundários . A segurança também não é um binário, ‘ é uma questão de quão longe você ‘ está disposto a ir para se proteger contra cada vez mais ataques exóticos .
- @ fgrieu desculpe, a única pergunta que posso responder é: nodejs.org / api / … @EllaRose Presumo que as bibliotecas que estou usando não tenham vulnerabilidades. Portanto, meu pseudocódigo acima é apenas uma implementação dessas funções de bibliotecas, como randomBytes.
Resposta
O pior A fraqueza puramente criptográfica é a senha (1). As piores (e muito piores) fraquezas práticas provavelmente estão na implementação (6) (7), e aquelas (4) (5) que os criptógrafos descartam como fora do escopo da criptografia (o único objetivo declarado da questão).
Candidatos a pontos fracos, da criptografia (mas ainda a considerar) à implementação:
- A senha: é difícil lembrar uma senha com mais de 48 bits de entropia ( isso é quase equivalente a um número de 16 dígitos, como 3141592653589793 ou 2718281828459045, e mais do que o previsto pelo XKCD obrigatório). Usando N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , compra no mínimo 18 + 3 + 1 = 22 bits (consulte this ) em comparação com um hash SHA-256 seguido por AES-128, acho que cerca de 32 bits mais forte, portanto, a chave pode ser cerca de 80 bits boa, o que é não totalmente inquebrável por força bruta, mas ainda bastante seguro.
- AES-128: tem uma chave de 128 bits, nenhum conhecido puramente criptanalítico ataque melhor do que força bruta e, portanto, é muito melhor do que a senha.
- Modo CTR: com o bloco de 128 bits do AES, a única maneira de a reutilização do fluxo de chave entrar em ação seria um número aleatório ruim gerador para o IV (ver 6)
- O tamanho do texto simples pode ser deduzido sem esforço do tamanho do texto cifrado. Isso explicitamente não é uma fraqueza teórica da criptografia, uma vez que o comprimento é excluído do que uma cifra deve ocultar sobre o texto simples. No entanto, isso pode ser um ponto fraco prático. Digamos que a análise do texto cifrado conclua que é 17267095423 octetos; e existe, em algum lugar da promotoria exibe um arquivo exatamente desse tamanho, comprovadamente anterior à busca e apreensão do texto cifrado, e cuja mera detenção é ilegal.
- Ausência de detecção de alterações (intencionais ou acidentais) no texto cifrado, correspondendo à alteração previsível no texto simples: novamente, isso é explicitamente não uma fraqueza teórica da criptografia, mas pode permitir alguns ataques se o adversário pode alterar o texto cifrado (exemplo: se o texto simples é um executável ou PDF com uma fração conhecida, isso pode permitir alterar o que o executável faz para sobre qualquer coisa, ou fazer o PDF exibir como sobre qualquer coisa). Criptografia autenticada ( AES-GCM ..) resolve isso.
- Gerador de números aleatórios: se isso for ruim ou pior, fica mais ou menos preso (obrigatório XKCD e Dilbert que se transformam em realidade com muita frequência), que permitiria a recuperação de texto simples em muitos cenários, incluindo a codificação repetida de diferentes textos em inglês ou endereços de e-mail com a mesma senha.
- Um canal lateral, que é amplamente falando de vazamento imprevisto ou absoluto de informações no contexto de implementação ou uso. Existem tantos:
- Recuperação de senha do detentor da senha explorando uma burla de procedimento (senha em uma nota post-it, lista de senha mestra), criptoanálise de mangueira de borracha (obrigatória XKCD ), variantes legais (envolvendo o uso de expressões como desacato ao tribunal ), suborno, impregnação química.
- Recuperação de senha por navegação no ombro , key logger (software ou hardware), câmera, microfone (uma boa captura de áudio de o som das teclas ao inserir uma senha vaza muitas informações sobre a senha, especialmente quando correlacionada com uma entrada de teclado conhecida pelo mesmo operador nas mesmas condições).
- Comprometimento direto do texto simples conforme mostrado na tela (com TEMPEST variantes desse), impresso, enquanto transmitido para uma impressora ou acessado remotamente por uma rede, ou apenas armazenado “temporariamente” ..
- Compromisso direto do sistema operacional do mach fazer criptografia ou descriptografia (obter acesso root temporário é o suficiente, significa que em 7.7 o atacante não está jogando).
- Canal lateral criptanalítico à distância, incluindo DPA e DEMA variante eletromagnética e, hipoteticamente, tempo se a máquina que faz a criptografia / descriptografia for acessada por uma rede e não usar Instruções AES .
- Canal lateral criptanalítico de um processo em execução no mesmo hardware (incluindo outra VM), incluindo segmentação baseada em cache para AES quando não estiver usando AES instruções, ou mais gerais (Meltdown, Spectre) que estão na moda atualmente.
- Exploração de vários bugs de software; isso “é enorme.
Comentários
- Seria mais útil se eu hash a senha antes da criptografia? Como usar sha ou md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Hashing senha antes de entrar em scrypt não muda muito a dificuldade de ataque da senha ( ponto 1). Para melhorar isso, é necessária uma senha melhor, uma melhor parametrização para criptografar ou um melhor esquema de derivação de chave baseado em senha (Argônio? Balão?)
Resposta
O principal elemento de segurança que pode ser atacado no esquema acima é – é claro – a frase secreta. Agora, o salt é importante para evitar ataques de rainbow table, mas caso contrário, não adiciona tanta segurança. Se o salt e a senha forem razoavelmente únicos, a chave também será. Nesse caso, o IV não é tão importante.
Portanto, embora usar um gerador de números aleatórios inseguro seja ruim, provavelmente não terá tanta influência na segurança prática. , isso indica que práticas inadequadas foram implementadas. E se a senha longa foi gerada usando o mesmo gerador aleatório inseguro? E se outros erros de implementação surgirem?
Usar texto criptografado não autenticado é mais problemático, pois permitiria ao adversário alterar o texto simples de cada bit. O adversário pode simplesmente inverter qualquer bit de texto cifrado e o bit de texto simples na mesma posição também inverterá. Isso significaria que você obteria um erro ou um problema ao usar a carteira. A confidencialidade do conteúdo da carteira provavelmente não foi perdida, mas usar criptografia autenticada é certamente a melhor prática.
Comentários
- Obrigado! Você poderia explicar mal como obter texto criptografado autenticado com este modo? Vou editar o e exemplos acima porque acho que está relacionado com a propriedade original do mac que removi do arquivo de armazenamento de chaves original.
- O modo CTR é o modo subjacente de CCM, GCM, EAX, SIV e um monte de outros autenticados cifras. No entanto, uma combinação do modo CTR com um (H) MAC também pode ser segura.Ambos produzem uma etiqueta de autenticação com aproximadamente o mesmo tamanho / segurança. CCM e EAX são pouco mais do que combinações específicas de CTR e MAC onde a mesma chave pode ser usada para a cifra e MAC.
- Observe que eu ‘ ve respondi a esta pergunta o melhor que pude, usando conhecimento genérico de cifras (não tanto Ethereum). Ella Rose está correta ao afirmar que não podemos concluir a segurança do sistema a partir das informações fornecidas na pergunta. Portanto, ‘ foquei exclusivamente no uso de CTR.
- Bem, o aleatório parece depender – no final – do aleatório do sistema. Freqüentemente, as fontes aleatórias do sistema são relativamente seguras e o termo CSPRNG é realmente mencionado pela fonte. Portanto, a afirmação de que não é aleatório está errada, a menos que o sistema aleatório não seja bem implementado ou propagado.
- Criar um MAC a partir de SHA-3 diretamente não é recomendado, KMAC deveria ter sido usado em seu lugar (provavelmente simplesmente não foi ‘ especificado ainda no momento). Mas não consigo pensar em nenhuma situação em que o uso sobre a concatenação da chave e do texto cifrado possa representar um problema.
Deixe uma resposta