Construções de cifras e MACs (21 min)

Neste segmento, nós vamos construir sistemas de criptografia autenticados. Uma vez que nós

já tem garantido de criptografia CPA, e temos MACs seguras, a pergunta natural

é se podemos combinar os dois de alguma forma, a fim de obter criptografia autenticado.

E se, que é exatamente o que vamos fazer neste segmento. Criptografia autenticado

foi introduzido no ano de 2000, em dois artigos independentes que apontam para a

final deste módulo. Mas antes disso, muitos crytpolibraries desde uma API que

separadamente suporte a criptografia CPA seguro, amd MAC-ing. Então, houve uma

função para implementar criptografia segura CPA. Por exemplo, a CVC com um aleatória

IV. E outra função para a implementação de um MAC. E então todos os desenvolvedores que

queria implementar a criptografia, teve que, ele próprio, chamar separadamente o seguro CPA

esquema de criptografia eo sistema MAC. Em particular, todos os desenvolvedores tiveram que inventar

maneira própria de combinar criptografia e MAC-ing para fornecer algum tipo de

criptografia autenticado. Mas desde que os objetivos da criptografia combinando e MAC-ing

não foi bem compreendida desde criptografia autenticado ainda não foi definida. Ele

realmente não estava claro quais combinações de criptografia e MAC-ing estão corretas e

que não são. E assim, cada projeto, como eu disse tinha de inventar sua própria combinação.

E, de fato, nem todas as combinações eram corretas. E eu posso te dizer que o mais

erro comum em projetos de software foram basicamente incorretamente combinando o

criptografia e mecanismos de integridade. Portanto, esperamos que, até o final deste módulo, você

saberá como combiná-los corretamente, e você não estará fazendo estes erros

si mesmo. Então, vamos olhar para algumas combinações de criptografia segura e CPA

MAC, que foram introduzidas por diferentes projetos. Então, aqui estão três exemplos. Assim,

, antes de tudo, em todos os três exemplos, há uma chave separada para a criptografia, e

uma chave separada para MACing. Estas duas chaves são independentes um do outro, e

ambos são gerados em tempo de configuração da sessão. E nós vamos ver como gerar estes

duas teclas mais tarde no curso. Assim, o primeiro exemplo é o protocolo SSL. Assim, o

maneira SSL combina criptografia e MAC, na esperança de alcançar a criptografia autenticado

é o seguinte. Basicamente, você toma o texto simples, m, e então você calcular um MAC

no texto simples, m. Então você usar sua chave MAC, KI para calcular tag para esta mensagem

m. E então você pode captionate a marca para a mensagem e então você criptografar o

captionation da mensagem ea marca eo que sai é o texto cifrado final.

Então essa é a opção número um. A segunda opção é o que faz seg IP. Assim

aqui, você leva a mensagem. A primeira coisa que você faz é criptografar a mensagem.

E então, você calcular um tag no texto cifrado resultante. Então você percebe o

tag si mesmo é calculado sobre o texto cifrado resultante. Uma terceira opção é o que o

protocolo SSH faz. Então, aqui, o SSH leva a mensagem e criptografa-lo usando um CPA

esquema de criptografia segura. E então, para ele, concatenadas uma marca da mensagem. O

diferença entre IPsec e SSH, é que em IPsec, a marca é calculado sobre o

texto cifrado, que, em SSH, o tag no computadorizada sobre a mensagem. E assim estes

são três maneiras completamente diferentes de combinar a criptografia e MAC. Eo

pergunta é, qual destes é segura. Então, eu vou deixar você pensar sobre isso por um

segundo, e então quando nós vamos continuar a fazer a análise em conjunto. Okay. Então, vamos

início com o método SSH. Assim, o método SSH você notar que a marca é calculado

na mensagem e então concatenado em claro para o texto cifrado. Agora, esta é

realmente um grande problema porque MAC em si não são projetados para fornecer

confidencialidade. Macs são projetados somente para integridade. E, de fato, não há

nada de errado com um MAC que, como parte da marca gera alguns pedaços da planície

texto. Saídas de alguns pedaços da mensagem M. Isso seria uma marca perfeitamente bem. E ainda se

fizemos isso, que seria completamente quebrar a segurança CPA aqui, porque alguns pedaços de

mensagem são divulgados no texto cifrado. E assim, a abordagem SSH, mesmo que o

especificidades da SSH estão bem e do protocolo em si não é comprometida pela

esta combinação específica, geralmente é aconselhável não usar essa abordagem. Simplesmente

porque a saída do algoritmo de assinatura MAC pode vazar bits da mensagem. Assim

agora vamos olhar para SSL e IPsec. Como se vê, o método recomendado, na verdade

é o método de IPsec. Porque acontece que não importa o CPA sistema seguro e MAC

chave que você use a combinação é sempre vai fornecer criptografia autenticado.

Agora deixe-me muito, muito brevemente explicar o porquê. Basicamente o que acontece é que, uma vez que criptografar

mensagem bem o conteúdo da mensagem agora está escondido no interior do texto cifrado e agora

quando calculamos uma marca do texto cifrado, basicamente, estamos travando, esta tag bloqueios

texto a cifra e garante que ninguém pode produzir um texto cifrado diferente que

olhar válido. E como resultado desta abordagem garante que quaisquer modificações na

texto cifrado será detectado pelo decrypter simplesmente porque o MAC não é

vai verificar. Como se vê, para a abordagem SSL, há na verdade são uma espécie de

exemplos patológicos, onde combinam CPA sistema de criptografia seguro com um seguro

MAC. E o resultado é vulnerável a um ataque escolhido cifra texto, de modo que ele faz

na verdade não fornece criptografia autenticado. E, basicamente, a razão que

poderia acontecer, é que há algum tipo de interação ruim entre a criptografia

esquema eo algoritmo MAC. De tal modo que, de fato, haverá uma cifra escolhida

ataque texto. Então, se você está projetando um novo projeto a recomendação agora é

sempre usar criptografar então MAC porque isso é seguro, não importa qual CPA seguro

algoritmo de criptografia e MAC seguro você está combinando. Agora, só para definir o

terminologia, o método SSL é às vezes chamado MAC-then-encrypt. Eo

método IPsec é chamado encrypt-then-MAC. O método SSH mesmo que seu

não deveria usá-lo, é chamado de criptografar e-MAC. Ok, então eu vou muitas vezes referem-se a

encrypt-then-MAC e MAC-then-criptografar para diferenciar SSL e IPsec. Ok, então

apenas para repetir o que acabei de dizer. O método de IPsec encrypt-e-mac sempre

nos fornecer uma criptografia autenticado. Se você começar do CPA cifra segura e um MAC seguro

Você sempre terá criptografia autenticado. Como eu disse, MAC-depois-criptografar em

fato, há casos patológicos, onde o resultado é vulnerável a fatos CCA e

, portanto, não fornece criptografia autenticado. No entanto, a história é um pouco

pouco mais interessante do que isso, na medida em que, ao que parece, se você está realmente usando

modo aleatório contador ou CBC randomizado, em seguida, ao que parece, para aqueles que especial

CPA esquemas de criptografia seguras, MAC-then-criptografar realmente dá autenticado

criptografia e por isso é seguro. De fato, há mesmo uma mais interessante

torcer aqui em que se você estiver usando o modo de contador ao acaso. Então, é suficiente

que o seu algoritmo de MAC apenas ser um tempo seguro. Ele não tem que ser um totalmente

MAC seguro. Ele só tem que ser seguro quando uma tecla é usada para criptografar uma mensagem única,

ok? E quando falamos sobre a integridade da mensagem, vimos que há realmente

6:56.08
MACs muito mais rápido que são um tempo seguro de MACs que são totalmente seguras. Como

resultado, se você estiver usando o modo aleatório contra-MAC, em seguida, criptografar-pudesse realmente

resultado em um mecanismo de criptografia mais eficiente. No entanto, eu vou repetir

isso de novo. A recomendação é usar encrypt-then-MAC e estamos indo para ver um

número de ataques a sistemas que não usam encrypt-then-MAC. E assim o fazem apenas

que as coisas são seguras sem você ter que pensar muito sobre isso. Novamente, eu sou

vai recomendar que você use sempre encrypt-then-MAC. Agora, uma vez que o conceito de

criptografia autenticada tornou-se mais popular, um número de padronizada

abordagens para a combinação de criptografia e MAC apareceu. E eram mesmo

padronizado pelo Instituto Nacional de Padrões. Então eu só vou mencionar três

destas normas. Dois deles foram padronizados pelo NIST. E estes são

chamado Galois modo de contador e contador de modo CBC. E então deixe-me explicar o que fazem.

modo Galois contador basicamente usa criptografia de modo contador, para um contador randomizado

modo com um MAC Carter-Wegman, portanto, um fato muito Carter-Wagmon MAC. E a forma como o

Carter-Wegman MAC trabalha em GCM é que é basicamente uma função hash da mensagem

que está sendo MACed. E então o resultado é criptografada usando um PRF. Agora esse hash

função em MGC é já bastante rápido até o ponto onde a maior parte do executando

hora do GCM é dominada pelo modo de contador de criptografia e está ainda fez mais,

em que a Intel introduz um PCLMULQDQ instrução especial especificamente

projetado para a finalidade de fazer a função hash na GCM correr tão rápido quanto possível.

Agora modo contador CCM é um outro padrão NIST ele usa um MAC CBC. E

então criptografia modo de contador. Portanto, este mecanismo, você sabe, este usa MAC, então

encrypt, como SSL faz. Portanto, este não é realmente a maneira recomendada de se fazer

coisas, mas porque a criptografia modo contador é usado. Esta é realmente uma

mecanismo de criptografia perfeitamente bem. Uma coisa que eu gostaria de ressaltar sobre

CCM, é que tudo é baseado em AES. Você percebe, ele está usando AES para a CBC

MAC, e ele está usando a criptografia AES de modo contador. E, como resultado, o CCM pode

ser implementada com o código de relativamente pouco. Porque tudo que você precisa é um motor AES

e nada mais. E por isso, CCM, na verdade foi adoptada pelo Wi-Fi

aliança e, na verdade, provavelmente você está usando CCM em uma base diária, se você estiver usando

criptografado Wi-Fi 802.11i então você está usando basicamente o tráfego do CCM encrypt

entre o laptop eo ponto de acesso. Há um outro modo chamado EAX que

usa criptografia de modo contador, e depois CMAC. Então, novamente você notar encrypt-de-mac

e isso é um outro modo bem usar. Nós vamos fazer uma comparação de todos estes

modos em apenas um minuto. Agora eu queria mencionar que, antes de tudo, todos estes são

nonce-based. Em outras palavras, eles não usam qualquer aleatoriedade, mas eles tomam como

entrada um nonce e nonce deve ser único por chave. Em outras palavras, como você

lembre-se, a par nonce chave comum não deve nunca, nunca repetir. Mas o

nonce si não precisa ser aleatória, por isso é perfeitamente possível usar um contador, para

exemplo, como um uso único. E o outro ponto importante é que, na verdade, todos

estes modos são o que se chama de criptografia autenticado com associados

dados. Esta é uma extensão de criptografia autenticado, mas que vem

-se muitas vezes em protocolos de rede. Portanto, a ideia entre AEAD é que, na verdade,

a mensagem que é fornecido para o modo de criptografia não se destina a ser totalmente

encriptado. Apenas uma parte da mensagem se destina a ser criptografada, mas todo o

mensagem se destina a ser autenticado. Um bom exemplo disto é um pacote de rede.

Pense como um pacote IP, onde há um cabeçalho. E depois há uma carga e

normalmente o cabeçalho não vai ser criptografados. Por exemplo, o cabeçalho pode

conter o destino do pacote, mas, em seguida, o cabeçalho é melhor que não seja

criptografados de outra forma os roteadores ao longo do caminho não saberia por onde rotear o pacote.

E assim, tipicamente o cabeçalho é enviado em claro, que a carga, é claro, é

sempre criptografados, mas o que você gostaria de fazer é ter o cabeçalho ser autenticado.

não criptografado, mas autenticado. Portanto, este é exatamente o que estes modos AEAD, fazer. Eles

irá autenticar o cabeçalho e, em seguida, criptografar a carga. Mas o cabeçalho e

carga a estão unidos na autenticação para a autenticação não pode

realmente ser separados. Então isso não é difícil de fazer. O que acontece nestes

três modos GCM, CCM, EAX e, basicamente, o MAC é aplicado para a totalidade dos dados. Mas

criptografia é aplicada somente a parte dos dados que precisam ser criptografados.

Então, eu queria mostrar o que uma API para criptografia autenticado com

dados associados esquemas de criptografia semelhante. Então aqui está o que parece no OpenSSL

Por exemplo, isto é, uma API para GCM. Então o que você faz é chamar a

função de inicialização para inicializar o modo de criptografia, e você percebe que você dê a ele uma chave

o nonce. O uso único de novo, não tem de ser aleatória, mas tem que

ser único. E após a inicialização, você poderia chamar essa função encrypt, onde

você vê que você dê a ele a dados associado que vai ser autenticadas, mas

não criptografado. Você dá os dados, e vai ser autenticada e

encriptado. E dá-lhe de volta o texto cifrado completo, que é uma criptografia da

dados, mas é claro que não inclui o AAD, porque o DAA vai ser enviado em

claro. Portanto, agora que entendemos esse modo de criptografar-then-MAC, que pode ir

volta para a definição de MAC segurança e posso explicar-lhe algo que poderia

ter sido um pouco obscura, quando olhamos para essa definição. Então, se você se lembra,

um dos requisitos que se seguiram a nossa definição de MACs seguras significava que

dada uma mensagem par MAC em uma mensagem M, o atacante não pode produzir outra tag na

a mesma mensagem M. Em outras palavras, mesmo que o invasor já tem uma marca para

M a mensagem, ele não deve ser capaz de produzir uma marca de novo para a mesma mensagem de M.

E não é muito claro, por que isso importa? Quem se importa se o adversário já

tem uma etiqueta na mensagem M? Quem se importa se ele pode produzir outra marca? Bem, acontece

que o MAC não tem essa propriedade. Em outras palavras, dada uma mensagem

par MAC, você pode produzir um outro MAC na mesma mensagem, então, que o MAC seria

resultado em um modo de criptografar-then-MAC inseguro. E por isso, se queremos que o nosso MAC criptografado para

ter auto-ajuste integridade, é crucial que a nossa Segurança MAC implicaria uma forte

noção de segurança, o que, evidentemente, não faz porque definido-lo correctamente.

Então vamos ver o que iria dar errado, se, de fato, era fácil de produzir este tipo de

falsificação. Então o que vou fazer é que eu vou mostrar-lhe um ataque de texto cifrado escolhido no

sistema encrypt-then-MAC resultante. E já que o sistema tem um texto cifrado escolhido

ataque sobre ela, significa necessariamente que ele não fornece uma autenticado

criptografia. Então vamos ver. Então começo do adversário gonnna enviando dois

mensagens, M0 e M1. E ele vai receber, como de costume, a criptografia de um

deles, a criptografia de M0 ou a criptografia de M1. E já que estamos

usando encrypt-then-MAC, o adversário recebe um texto cifrado, vamos chamar um C0

e MAC no texto cifrado C0. Bem, agora temos dito que, dada a MAC

uma mensagem o adversário pode produzir um outro MAC na mesma mensagem. Então, o que

ele vai fazer é que ele vai produzir um outro MAC na mensagem C0. Agora, ele tem

um texto cifrado de novo (C0, T '), que é um texto cifrado perfeitamente válido. T 'é um

MAC válido de C0. Portanto, o adversário agora pode enviar uma consulta de texto da cifra escolhida

em C 'e esta é uma consulta de texto válido cifra escolhida porque é diferente

de C. É um texto cifrado de novo. O desafiante pobre agora é obrigado a decifrar este

texto cifrado C 'para que ele vai mandar de volta a descriptografia de C'. É uma

texto cifrado válido, portanto, a decodificação de C é o principal Mb mensagem, mas agora o

atacante acabou de aprender o valor de B, porque ele pode testar se Mb é igual a

M0 ou MB é igual a M1. Como resultado, ele pode apenas output B e ele fica vantagem

um. Na alimentação do sistema. E assim, novamente, se a nossa segurança MAC não implicava

essa propriedade aqui. Em seguida, haverá um ataque de texto escolhido cifra para criptografar-then-MAC. E

portanto, não seria seguro. Assim, o fato de que nós definir a segurança MAC corretamente

significa que criptografam-then-MAC realmente fornecer criptografia autenticado. E

durante todos os MACs que discutimos realmente satisfazer essa noção forte de

unforgeability. Assim, curiosamente, este não é o fim da história. Então, como dissemos

antes do conceito de criptografia autenticado foi introduzido todos estavam

apenas combinando MACs e criptografia de várias maneiras, na esperança de alcançar

alguns, alguns criptografia autenticado. Após a noção de criptografia autenticado

tornou-se formalizado e rigorosa, as pessoas começaram a coçar a cabeça e disse:

ei, espere um minuto. Talvez possamos alcançar a criptografia autenticada de forma mais eficiente

do que pela combinação de um MAC e um esquema de criptografia. Na verdade, se você pensar em como

esta combinação de MAC e criptografia funciona, vamos dizer que combinar o modo de contador

com CMAC, em seguida, para cada bloco de texto simples, você primeiro de tudo tem que usar

cifra de bloco para o seu modo de contador, e então você tem que usar a sua cifra de bloco

novamente, para o CBC-MAC. Isto significa que se você combinar CPA criptografia segura com um

MAC, para cada bloco de texto simples, você tem que avaliar o seu bloco cifrado duas vezes,

uma vez para o MAC e uma vez para o esquema de criptografia. Então, a pergunta natural

era, podemos construir um sistema de criptografia autenticado diretamente de um PRP,

tal que teríamos que apenas avaliar o PRP, uma vez por bloco. E acontece

, a resposta é sim, e há estes bela construção denominada OCB, que

praticamente faz tudo que você quer, e é muito mais rápido do que construções que são

separadamente construído a partir de uma criptografia e MAC. Então eu escrevi para baixo, tipo de um esquema

da OCB. Eu não quero explicar em detalhes. Vou explicá-lo meio a uma

de alto nível. Então aqui nós temos, de entrada de texto simples, aqui no topo. E você

aviso de que, em primeiro lugar, OCB é paralelizável, completamente paralelizável.

Assim, cada bloco pode ser criptografado separadamente de cada outro bloco. A outra coisa a

aviso é que, como eu prometi, você só avaliar a sua cifra do bloco uma vez por simples

bloco de texto. E então você avaliá-lo mais uma vez no fim de construir o seu

tag autenticação e, em seguida, a sobrecarga de OCB além de apenas um bloco cifra é

mínima. Tudo que você tem a fazer é avaliar uma determinada função P muito simples que o

nonce vai para o P você notar, a chave vai para este P e, em seguida, há uma

contra bloco que vai para este P. Então você só avaliar essa função P, duas vezes

para cada bloco e você XOR o resultado antes e depois de criptografia usando o

cifra de bloco e é isso. Isso é tudo que você tem que fazer e então você começa um muito rápido

esquema de criptografia e de autenticação eficiente construído a partir de uma cifra de bloco. Então OCB

realmente tem um teorema de segurança agradável associado com ele e eu vou apontar

para um trabalho sobre OCB quando chegarmos ao final deste módulo onde eu vou listar algumas mais

papéis de leitura que você pode dar uma olhada. Então você deve estar se perguntando se é tão OCB

muito melhor do que tudo o que tenho visto até agora todas essas três padrões CCM, GCM e

EAX porque não é OCB sendo usado ou porque não é OCB o padrão? E a resposta é um

pouco triste. A resposta primária em que CBC não está sendo utilizado é porque na verdade

de várias patentes. E eu vou deixar por isso mesmo. Portanto, para concluir esta seção I

queria mostrar-lhe alguns números de desempenho. Então, aqui à direita listei

números de desempenho para os modos que você não deve usar. Então isto é para

modo casualizado contador, e isto é para CBC casualizado. E você pode ver também o

desempenho de CBC MAC é basicamente o mesmo que o desempenho de criptografia CBC.

Ok. E aqui são os modos de criptografia autenticados, por isso estes são os

que você deveria usar, estes que você não deveria estar usando em sua

próprio, direito. Estes dois, você nunca deve usar esses dois, porque eles só

fornecer CPA segurança, eles realmente não oferecer segurança contra ativa

ataques. Você só deve usar criptografia autenticado para criptografia.

E por isso este é os seus números de desempenho para os três padrões. E deixe-me lembrá

você que GCM basicamente usa um hash muito rápido. E então ele usa o modo de contador para

criptografia real. E você pode ver que a sobrecarga de GCM sobre o modo de contador é

relativamente pequeno. CCM e EAX tanto usar uma criptografia Sipher bloco base e um

cifra de bloco para a base da MAC. E como resultado a sua duas vezes mais lento que o contador

modos. Você vê que é realmente mais rápido OCB destes, principalmente porque

só usar a cifra de bloco uma vez por bloco de mensagem. Assim, com base no desempenho desses

números, você poderia pensar que GCM é exatamente o modo correto de usar sempre. Mas

acontece se você está no hardware espaço restrito, GCM não é o ideal.

Principalmente porque a sua aplicação requer um código maior que os outros dois

modos. No entanto, como eu disse, a Intel especificamente acrescentou instruções para acelerar

modo GCM para cima. E, como resultado, a implementação de GCM na arquitetura Intel leva

muito pouco código. Mas em outras plataformas de hardware, visto em cartões inteligentes ou outros

ambientes restritos, os sites de código para a implementação GCM seria consideravelmente

maior do que para os outros dois modos. Mas se o tamanho do código não é uma restrição, então GCM

é o modo correto de usar. Então, para resumir esse segmento que eu quero dizer mais uma

tempo que, quando você quiser criptografar mensagens que você tem que usar uma autenticação

modo de criptografia e a maneira recomendada para fazer isso é usar um dos padrões,

principalmente um destes três modos para fornecer criptografia de autenticação. Não implementar o esquema de criptografia si mesmo.

Em outras palavras, não implementar criptografar e-MAC-se.

Basta usar um desses três padrões. Muitas bibliotecas criptografar

agora fornecer API padrão para estes três modos e estes são os do que você deve

estar usando e nada mais. No próximo segmento nós vamos ver o que mais pode

dar errado quando você tentar implementar uma criptografia sonicado por si mesmo.