👨🏿‍🚀 👩🏻‍🏭 👩🏾‍🎨 A longa jornada do RFC 4357 ao RFC 8645 ou como gerenciar chaves de criptografia ⏸️ 🦊 ⏺️

Como você sabe, o gerenciamento de chaves é uma das tarefas mais difíceis da criptografia. Outro dia, o documento “Mecanismos de re-digitação para chaves simétricas” foi publicado como RFC 8645 . É o resultado de dois anos e meio de trabalho do grupo de pesquisa do CFRG, que determina o desenvolvimento e o uso de criptografia na IETF, e foi baseado em muitos anos de pesquisa e na experiência de especialistas russos. A seguir, explicamos brevemente qual é a essência deste RFC e por que acabou sendo apenas isso.

Um pouco de susto ...

Em 2016, dois pesquisadores franceses do Instituto Inria publicaram uma descrição do ataque Sweet32 . A ideia que eles usaram é obscenamente simples e baseada no chamado "problema do aniversário" : se calcularmos os valores de um mapeamento aleatório

f : V_{n} r i g h t a r r o w V_{n}

$f: V_n \ rightarrow V_n$ então em cerca de

2^{n / 2}

$2 ^ {n / 2}$ testes na sequência resultante, pelo menos dois valores coincidem. Do ponto de vista da criptografia, isso significa que uma cifra de bloco com um comprimento de bloco

n

$n$ bit não pode mais ser criptografado em uma chave

2^{n / 2}

$2 ^ {n / 2}$ blocos de texto simples.

Esse ataque já foi considerado em detalhes em Habré ; aqui, observamos apenas que os autores aproveitaram o fato de que algumas bibliotecas criptográficas amplamente usadas não alteraram a chave da sessão a tempo. Isso nos permitiu acumular muitos dados e simplesmente usar a propriedade probabilística especificada se a conexão usasse uma cifra de bloco com um comprimento de 64 bits. Isso imediatamente causou uma grave histeria no ambiente quase criptográfico, com relação à necessidade de uma rejeição urgente de tais cifras.

Mas é o comprimento do bloco?

De fato, vale a pena ostracizar uma cifra apenas porque ela tem um tamanho de bloco curto: e se você mudar a chave periodicamente? Isso pode ser feito usando a chamada função de derivação de chave ( KDF ). Essas funções permitem obter novas chaves com base nas antigas, preservando a propriedade aleatória das chaves (consulte, por exemplo, este artigo ). Tais funções, por exemplo, são determinadas pelas recomendações de padronização russas P 1323565.1.022-2018 e P 50.1.113-2016 . No entanto, existe um "mas": essas conversões são bastante complexas e não muito rápidas, baseadas nas funções de hash, o que reduzirá significativamente a velocidade de criptografia.

É possível fazer algo mais rápido?

Essa tentativa foi feita em 2006 na RFC 4357 , onde foi proposto o mecanismo CryptoPro Key Meshing, que produz uma chave derivada criptografando uma constante fixa com uma cifra de bloco em um modo de substituição simples.

Era um algoritmo muito rápido, praticamente sem efeito na velocidade de criptografia e protegido contra situações ridículas como as usadas no Sweet32, e também, por exemplo, contra ataques a canais laterais. No entanto, na conferência Ruscrypto de 2015, foi demonstrado que essa transformação reduz o poder do conjunto de chaves, ou seja, a cada nova alteração de chave, o número de opções possíveis de seleção de chave diminui. O autor observou que isso não teve nenhum impacto significativo na segurança, mas, no entanto, tornou-se interessante se poderia ser feito ainda melhor.

Descobriu-se não é tão simples

Infelizmente, milagres não existem, e não é possível oferecer um mecanismo rápido comparável aos KDFs convencionais; no entanto, podemos provar a segurança de vários esquemas modificados, como a Malha de Chaves especificada para cada modo de criptografia específico. São esses mecanismos que foram propostos e justificados para o modo gama CTR amplamente usado (CTR-ACPKM, Prolongamento Criptográfico Avançado de Material Chave) e o desenvolvimento de um inserto de simulação OMAC (OMAC-ACPKM) a partir do padrão doméstico GOST R 34.13-2015.

As classificações de segurança para esses modos são obtidas usando o chamado aparelho "Durabilidade comprovada . "

Esses modos foram adotados na Rússia como recomendações para padronização do R 1323565.1.017-2018 .

É essa maneira de trabalhar com chaves que permite que ferramentas de criptografia que implementam conjuntos de criptografia TLS 1.2 russos (definidos nas recomendações de padronização R 1323565.1.020-2018 ) atendam aos requisitos de proteção criptográfica russa para classes altas.

Trabalho na IETF

Os mecanismos desenvolvidos se encaixam perfeitamente como resposta à discussão mencionada no início do artigo sobre se deve haver cifras com comprimento de bloco curto ou não.

O desenvolvimento do documento correspondente, que mais tarde se tornou a RFC 8645, foi encomendado pelos presidentes do CFRG Kenny Paterson e Alexei Melnikov por um grupo internacional de especialistas liderado por Stanislav Smyshlyaev. A contribuição para o desenvolvimento do documento final foi feita por Evgeny Alekseev, Ekaterina Smyshlyaeva e Lilia Akhmetzyanova (CryptoPro), Shay Gueron (Universidade de Haifa), Daniel Fox Franke (Akamai Technologies), além do ex-chefe da IETF Russ House (Vigil Security); em vários estágios, especialistas importantes como Mihir Bellare (Universidade da Califórnia), Scott Fleurer (Cisco), Yoav Nir (ponto de verificação), Dmitry Belyavsky (Cryptocom) e Paul Hoffman (ICANN) participaram do trabalho.

Comparado com as recomendações russas, foram adicionados a este RFC mecanismos ACPKM para modos como CBC, CFB e GCM, que, como você provavelmente já entendeu, exigiam evidências separadas .

Sumário

Como já observado, apesar de a abordagem proposta não ser, de certa forma, universal e exigir justificativas de segurança separadas para cada modo individual, recompensamos a alta velocidade, segurança contra ataques como Sweet32 e, pelo menos, ataques de canais laterais.