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.