Modos de cifra e protocolos

AES transforma blocos de 16 bytes. A lista de preços da loja ocupa mais do que isso: é preciso proteger vários blocos com a mesma chave. Uma cifra de bloco define a transformação de um bloco; não define sozinha como proteger uma mensagem inteira. Para proteger uma mensagem maior, dividimos a mensagem em blocos e precisamos de uma regra, o modo de operação, que define a relação entre blocos e os valores adicionais usados na cifragem. O XOR compara bits e dá 1 quando são diferentes e 0 quando são iguais: $x\oplus x=0$ e $x\oplus0=x$; por exemplo, 1010 XOR 1100 = 0110.

ECB, CBC e CTR

Modo	Relação entre blocos	Valor adicional	Limite importante
ECB	Cada bloco cifra independentemente	Nenhum	Blocos iguais com a mesma chave dão cifras iguais
CBC	Cada bloco combina-se com a cifra anterior	IV inicial imprevisível	Exige blocos completos; sozinho não autentica
CTR	XOR da mensagem com blocos de uma sequência cifrada de contadores	Contadores que não se repetem sob a mesma chave	Reutilização revela relações entre mensagens; sozinho não autentica

Em ECB, cada bloco cifra de forma independente. Uma mensagem de blocos A A B A dá um padrão X X Y X. Um observador não precisa de descobrir A para reconhecer repetições, por isso “usar AES” sem dizer o modo não responde a este problema.

Em CBC, $C_i=E_K(P_i\oplus C_{i-1})$, com $C_0=IV$. Aqui $P_i$ é um bloco de texto em claro, $C_i$ um bloco cifrado e $K$ a chave. Com dois blocos: primeiro calcula-se $X_1=P_1\oplus IV$ e $C_1=E_K(X_1)$; depois $X_2=P_2\oplus C_1$ e $C_2=E_K(X_2)$. Para decifrar, inverte-se cada passo: $P_1=D_K(C_1)\oplus IV$ e $P_2=D_K(C_2)\oplus C_1$, como mostra o diagrama seguinte com estes dois blocos.

Em CTR, $C_i=P_i\oplus E_K(\text{contador}_i)$. O IV de CBC e os contadores de CTR têm requisitos distintos. Em CTR, evita repetir qualquer bloco de contador, inclusive entre mensagens: inícios diferentes ainda podem gerar sequências sobrepostas.

CBC convencional recebe blocos completos. Com preenchimento PKCS#7 e blocos de 16 bytes, uma mensagem de 14 bytes recebe dois bytes 02 02. Uma de 16 bytes recebe um bloco completo de dezasseis bytes de valor 16, para distinguir preenchimento de dados. Ao remover, o recetor lê o último byte $k$, exige $1\le k\le16$ e pelo menos $k$ bytes disponíveis, e verifica que os últimos $k$ bytes valem todos $k$. Se alguma condição falha, rejeita em vez de remover. O preenchimento não autentica a mensagem. CTR pode usar apenas os bytes necessários do último bloco e não precisa deste preenchimento.

Alterar bits sem conhecer a chave

Em CTR sem autenticação, alterar um bit de $C_i$ altera exatamente o bit correspondente de $P_i$. O contador e a sequência cifrada mantêm-se. Se o atacante aplica uma máscara $\Delta$, o recetor obtém:

$$C'_i=C_i\oplus\Delta.$$

Ao retirar a mesma sequência $S_i$, fica:

$$P'_i=P_i\oplus\Delta.$$

Com $P_i=01000001$ e máscara 00000011, os dois bits finais mudam e o resultado é 01000010. Não há propagação automática aos restantes blocos. Confidencialidade não impede esta alteração; uma etiqueta de autenticação válida é uma condição adicional. AES real tem blocos de 128 bits, ou 16 bytes; um bloco menor num exercício representa apenas um modelo para seguir o XOR.

Reutilizar uma sequência de XOR

Se duas mensagens usam a mesma sequência $S$, temos $C_1=P_1\oplus S$ e $C_2=P_2\oplus S$. Ao combinar as cifras:

$$C_1\oplus C_2=P_1\oplus P_2,$$

porque $S\oplus S=0$. Se uma mensagem é conhecida, a outra fica recuperável. Este problema aparece no one-time pad reutilizado e no CTR com contadores repetidos.

Para ver um byte, toma $P_1=01000001$ (A), $P_2=01000010$ (B) e $S=00110000$:

Estado	Bits
$C_1=P_1\oplus S$	01110001
$C_2=P_2\oplus S$	01110010
$C_1\oplus C_2$	00000011
$(C_1\oplus C_2)\oplus P_1$	01000010, o B original

O atacante conhece a primeira mensagem e as duas cifras. A última linha recupera a segunda mensagem sem conhecer previamente $S$.

Os bytes deste exemplo só mostram a identidade algébrica; não implementam uma cifra segura. O one-time pad só tem confidencialidade perfeita com chave uniformemente aleatória, tão longa como a mensagem, secreta e usada uma única vez.

Cifragem autenticada

Um MAC autentica dados, mas não os esconde. Cifrar sem autenticar pode permitir alterações controladas ou ataques através das respostas a dados inválidos. AEAD protege a confidencialidade do conteúdo e a integridade do conteúdo e dos dados associados, como um número de sequência. Estes dados associados não ficam cifrados.

Usa construções estudadas, como AES-GCM ou ChaCha20-Poly1305, com os requisitos de nonce da construção. Para GCM, reutilizar um nonce com a mesma chave compromete a segurança. A aplicação deve rejeitar dados cuja etiqueta não verifica, antes de lhes dar significado. Usa uma construção analisada, em vez de combinar por conta própria uma cifra e um hash.

AEAD não elimina automaticamente a repetição. Uma mensagem válida antiga continua a ter uma etiqueta válida, porque a etiqueta prova que alguém com a chave protegeu aquele conteúdo e dados associados. Não prova que a mensagem é nova. A frescura precisa de mecanismo próprio, conforme o protocolo: por exemplo incluir um número de sequência nos dados associados e manter estado de receção com janela que tolera reordenação legítima, ou usar um desafio fresco por operação e rejeitar respostas fora do desafio pendente.

No esquema, o identificador 7 está autenticado com a mensagem. O atacante só copia os bytes; a segunda receção é recusada pelo estado da aplicação, não por uma falha da etiqueta.

A verificação de unicidade e o efeito têm de ficar ligados atomicamente. Caso contrário, dois pedidos concorrentes podem observar o identificador como novo antes de qualquer um o registar. Este exemplo não define um protocolo completo.

Ordem entre cifragem e MAC

Os nomes indicam que dados se autenticam e quando. Escrevemos $E$ para cifragem, $M$ para MAC e $\Vert$ para concatenação; $K_E$ e $K_M$ têm funções separadas.

• Encrypt-then-MAC: calcula $c=E_{K_E}(m)$, depois $t=M_{K_M}(c)$, e envia $(c,t)$.
• MAC-then-Encrypt: calcula $t=M_{K_M}(m)$, depois $c=E_{K_E}(m\Vert t)$, e envia $c$.
• Encrypt-and-MAC: calcula separadamente $c=E_{K_E}(m)$ e $t=M_{K_M}(m)$, e envia $(c,t)$.

No primeiro caso, o recetor pode verificar a etiqueta antes de decifrar. No segundo, precisa de decifrar para chegar à etiqueta. Se diferenças de resposta revelarem erros de preenchimento antes da autenticação, essa ordem pode criar um oráculo: o atacante aprende algo pelas respostas a cifras alteradas. No terceiro, um MAC sobre o texto em claro pode revelar relações que a cifra pretendia esconder.

Estes esquemas distinguem composições, não provam segurança de qualquer implementação. É preciso proteger também IV/nonce e contexto conforme a construção, separar chaves e cumprir os requisitos das primitivas. Usar AEAD analisada evita inventar esse protocolo. Enviar só uma etiqueta MAC não envia a mensagem; enviar a chave MAC em claro permite ao observador criar etiquetas para mensagens alteradas.

Diffie-Hellman em números pequenos

A conta usa a aritmética modular, com números pequenos para permitir refazer as contas; não são parâmetros seguros.

Ana e Bruno publicam $p=23$ e $g=5$. Ana escolhe $a=6$ e envia $A=g^a\bmod p=8$. Bruno escolhe $b=15$ e envia $B=g^b\bmod p=19$. Ana calcula $B^a\bmod p=2$ e Bruno calcula $A^b\bmod p=2$.

A igualdade vem de aplicar os dois expoentes à mesma base:

$$B^a=(g^b)^a=g^{ab}=(g^a)^b=A^b\pmod p.$$

Ana não precisa de conhecer $b$: usa o valor público $B$ e o seu $a$. Bruno faz a operação correspondente com $A$ e $b$.

Num protocolo real, os parâmetros e a validação dos valores recebidos têm requisitos de segurança, e uma função de derivação transforma o segredo em chaves adequadas. A igualdade anterior explica a coincidência dos resultados no grupo usado, não a autenticação dos participantes.

Sem autenticação, um intermediário pode substituir A e B pelos seus valores e estabelecer um segredo com cada lado. O acordo não prova com quem falamos. No diagrama seguinte, o intermediário combina um segredo com Ana e outro segredo com Bruno; Ana e Bruno veem trocas aparentemente normais, mas partilham segredos diferentes com o intermediário.

Certificados e assinaturas sobre o contexto da troca, ou uma chave previamente partilhada, podem autenticar o acordo.

Chaves efémeras corretamente usadas e apagadas podem dar sigilo futuro: comprometer mais tarde a chave de autenticação de longo prazo não permite recuperar sessões antigas gravadas. Isso não protege uma sessão cujo próprio segredo efémero foi comprometido.

O vídeo acompanha a troca de valores públicos. Compara-a com os dois diagramas: obter um segredo comum e verificar a identidade do interlocutor continuam a ser problemas diferentes.

Abrir no YouTube