Armadilhas de código criptográfico

Question

Eu estou modificando o código de segurança existente. As especificações são bastante claras, não há exemplo de código, mas eu não sou nenhum perito criptográfica. Na verdade, o código de exemplo tem um aviso dizendo, com efeito, "Não use este código na íntegra."

Enquanto auditar o código que eu sou para modificar (que é supostamente apresentam completa) eu corri em toda esta pequena jóia que é usado na geração do desafio:

static uint16 randomSeed;

...

uint16 GetRandomValue(void)
{
  return randomSeed++;/* This is not a good example of very random generation :o) */
}

Claro, a primeira coisa que imediatamente fez foi passá-lo ao redor do escritório para que pudéssemos todos fazer rir.

O programador que produziu este código sabia que não era um bom algoritmo (como indicado pelo comentário), mas eu não acho que eles entenderam as implicações de segurança. Eles nem sequer se preocuparam em chamá-lo no circuito principal, de modo que seria, pelo menos, transformar-se em um contador de corrida livre -. Ainda não é o ideal, mas mundos além deste

No entanto, eu sei que o produto código que vai semelhante causa um guru de segurança real para rir ou terremoto.

• Quais são os problemas mais comuns de segurança, específico para criptografia, que eu preciso entender?
• Quais são alguns bons recursos que vai me dar conhecimento adequado sobre o que eu deveria saber sem erros comuns?

-Adam

Answer 1

Applied Cryptography é um excelente livro para ajudá-lo entender a criptografia e código. Ele passa por cima um monte de fundamentos, como a forma como bloco de cifras de trabalho, e por isso a escolha de um modo de codificação pobres fará seu código inútil, mesmo se você estiver usando uma versão perfeitamente implementado de AES.

Algumas coisas que atente para:

• pobres Fontes da aleatoriedade
• Tentando projetar seu próprio algoritmo ou protocolo -. Não faça isso, nunca
• Não começá-lo código revisto. De preferência por publicá-lo online.
• Não usar uma biblioteca bem estabelecida e tentar escrevê-lo sozinho.
• Crypto como uma panacéia - criptografia de dados não magicamente torná-la segura
• Gerenciamento de Chaves. Nestes dias, é muitas vezes mais fácil para roubar a chave com um ataque pelo lado do canal do que para atacar o cripto.

Answer 2

Não tente rolar o seu próprio - usar uma biblioteca padrão, se possível. mudanças sutis código de segurança pode ter um enorme impacto que não são fáceis de detectar, mas pode abrir brechas de segurança. Por exemplo, duas linhas modificadas para uma biblioteca abriu um orifício que não era' t facilmente perceptível por algum tempo.

Answer 3

A sua questão mostra uma das mais comuns: fontes pobres de aleatoriedade. Não importa se você usar uma chave de 256 bits se os bits não são suficientes aleatória.

Número 2 é provavelmente supondo que você pode projetar um sistema melhor do que os especialistas. Esta é uma área onde a implementação de um padrão de qualidade é quase certo que vai ser melhor do que inovação. Lembre-se, levou 3 versões principais antes de SSL estava realmente seguro. Nós pensamos.

Answer 4

IMHO, existem quatro níveis de ataques que você deve estar ciente de:

1. ataques de engenharia social. Você deve treinar seus usuários a não fazer coisas estúpidas e escrever o seu software de tal forma que é difícil para os usuários a fazer coisas estúpidas. Eu não sei de qualquer boa referência sobre essas coisas.

2. não executar código arbitrário (buffer overflows, exploits de XSS, injeção de SQL são todos agrupados aqui). A coisa mínima para fazer a fim de aprender sobre isso é ler Escrevendo código seguro de alguém da MS e observando a forma de quebrar Web Software google Tech Talk. Isso também deve ensinar-lhe um pouco sobre defesa em profundidade.

3. ataques lógicos. Se o seu código está manipulando texto simples, certificados, assinaturas, cifra-textos, chaves públicas ou quaisquer outros objetos de criptografia, você deve estar ciente de que lidar com eles de maneiras ruins podem levar a coisas ruins. coisas mínimas que você deve estar ciente sobre incluem ataques de dicionário off-line e on-line, ataques de repetição, ataques man-in-the-middle. O ponto de partida para aprender sobre isso e geralmente uma referência muito boa para você é http://www.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps

4. ataques criptográficos. vulnerabilidades criptográficas incluem:

   • coisas que você pode evitar: bad geração de números aleatórios, o uso de uma função hash quebrado, quebrado implementação da segurança primitivo (por exemplo esquece engenheiro -1 algum lugar do código, o que torna a função de encriptação reversível)
   • coisas que você não pode evitar, exceto por ser como up-to-date possível: novo ataque contra uma função hash ou uma função de criptografia (ver, por exemplo recente conversa MD5), nova técnica de ataque (ver por exemplo, os recentes ataques contra os protocolos que enviam criptografados voz através da rede)

Uma boa referência, em geral, deve ser Applied Cryptography.

Além disso, ele é muito preocupante para mim esse material que vai em um dispositivo móvel que é provavelmente bloqueada e difícil de atualização é escrito por alguém que está perguntando sobre a segurança em stackoverflow. Eu acredito que o seu caso fosse um dos poucos casos em que você precisa de um consultor externo (bom) que ajuda a obter os detalhes direito. Mesmo se você contratar um consultor de segurança, o que eu recomendo que você faça, por favor, leia também o acima referências (minimalista).

Answer 5

Quais são os problemas mais comuns de segurança, específico para criptografia, que eu preciso entender?

Fácil - você (1) não são suficientes inteligente para avançar com o seu próprio algoritmo

.

(1) e por você, quero dizer que você, eu e todo mundo lendo este site ... exceto para possivelmente Alan Kay e Jon Skeet .

Answer 6

Eu não sou um cripto cara também, mas S-boxes pode ser problemático quando mexeu com (e eles fazem a diferença). Você também precisa de uma verdadeira fonte de entropia, não apenas um PRNG (não importa o quão aleatório que parece). PRNGs são inúteis. Em seguida, você deve garantir a fonte de entropia não é determinista e que não pode ser adulterado.

Meu humilde conselho é: vara com algoritmos de criptografia conhecidos, a menos que você é um especialista e compreender os riscos. Você pode ser melhor fora de usar alguns testados, código publicamente disponíveis de fonte aberta / domínio público.