token de autenticação é criptografado, mas não assinado - fraqueza?

Question

Ao longo dos anos eu me deparei com este cenário mais do que uma vez. Você tem um monte de dados relacionados ao usuário que deseja enviar a partir de uma aplicação para outra. A segunda aplicação é esperado para "confiança" isto "token" e utilizar os dados dentro dele. Um carimbo está incluído no token para evitar um ataque de roubo / re-utilização. Por alguma razão (não vamos nos preocupar sobre isso aqui) uma solução personalizada foi escolhido em vez de um padrão da indústria como SAML.

Para mim parece que assinar digitalmente os dados são o que você quer aqui. Se as necessidades de dados para ser secreta, então você também pode criptografá-lo.

Mas o que eu vejo um monte é que os desenvolvedores usarão criptografia simétrica, por exemplo, AES. Eles estão assumindo que além de tornar os dados "segredo", a criptografia também fornece 1) a integridade da mensagem e 2) confiança (autenticação de origem).

Am I direito de suspeitar que há uma fraqueza inerente aqui? No valor de face que parece funcionar, se a chave simétrica é gerida de forma adequada. Falta essa chave, eu certamente não saberia como modificar um criptografados forma, ou lançar algum tipo de ataque criptográfico depois de interceptar vários tokens. Mas seria um atacante mais sofisticado ser capaz de explorar alguma coisa aqui?

Answer 1

Parte disso depende do Modo de criptografia. Se você usa o BCE ( que vergonha! ) Eu poderia trocar blocos ao redor, alterando a mensagem. Stackoverflow foi atingido por este bug muito .

Menos ameaçador -, sem qualquer verificação de integridade, eu poderia executar um ataque man-in-the-middle, e trocar todos os tipos de pedaços ao redor, e você recebê-lo e tentar decifrá-lo. Você iria falhar, é claro, mas a tentativa pode ser revelador. Existem ataques de canal lateral por "Bernstein (exploração de uma combinação de características de cache e microarquiteturais) e Osvik, Shamir, e Tromer (explorando as colisões de cache) dependem de ganhar dados estatísticos baseados em um grande número de testes aleatórios." 1 O artigo da nota de rodapé é por um criptógrafo de maior nota do que eu, e ele aconselha a reduzir a superfície de ataque com um MAC:

Se você pode ter certeza que um atacante que não tem acesso ao seu MAC chave não pode jamais alimentar entrada mal a um bloco de código, no entanto, você reduzir drasticamente a chance de que ele será capaz de explorar todos os erros

Answer 2

Sim. Criptografia por si só não fornece autenticação. Se você quiser autenticação, então você deve usar um código de autenticação de mensagens, tais como HMAC ou assinaturas digitais (dependendo de suas necessidades).

Há um grande número de ataques que são possíveis se as mensagens são apenas criptografados, mas não autenticado. Aqui é apenas um exemplo muito simples. Suponha que as mensagens são criptografadas usando CBC . Este modo usa um IV para embaralhar o texto cifrado para que criptografar a mesma mensagem duas vezes não resulta no mesmo texto cifrado. Agora veja o que acontece durante descriptografia se o atacante apenas modifica a IV, mas deixa o restante do texto cifrado como é. Apenas o primeiro bloco da mensagem decifrada vai mudar. Além disso exatamente esses bits mudou na mudança IV na mensagem. Daí o atacante sabe exatamente o que vai mudar quando o receptor descodifica a mensagem. Se esse primeiro bloco Foi, por exemplo, um timestamp um atacante sabe quando a mensagem original foi enviada, então ele pode facilmente corrigir o timestamp para qualquer outro momento, apenas invertendo os bits corretos.

Outros blocos da mensagem pode também ser manipulado, mas isso é um pouco mais complicado. Note também que esta não é apenas uma fraqueza da CBC. Outros modos como OFB, CFB têm fraquezas similiar. Assim, esperando que a criptografia só fornece autenticação é apenas uma hipótese muito perigosa

Answer 3

A abordagem de criptografia simétrica é tão segura como a chave. Se ambos os sistemas pode ser dada a chave e segure a tecla de forma segura, isso é bom. criptografia de chave pública é certamente um ajuste mais natural.