Suporte à criptografia pós-quântica no control plane do Red Hat OpenShift 4.20

A era da computação quântica está chegando e, com seu imenso poder de processamento, surge uma ameaça significativa às bases criptográficas do nosso mundo digital. Neste artigo, vamos explorar o novo suporte à criptografia pós-quântica (PQC) no Red Hat OpenShift 4.20, com foco em como ele aprimora os principais componentes do control plane do Kubernetes: apiserver, kubelet, scheduler e controller-manager. O etcd está ausente, usando uma versão mais antiga do Go.

A ameaça quântica

Os sistemas criptográficos de chave pública amplamente usados atualmente, como o RSA e a criptografia de curva elíptica (ECC), formam a base da comunicação online com segurança aprimorada. No entanto, esses sistemas são vulneráveis a ataques de computadores quânticos em larga escala, que podem resolver os problemas matemáticos subjacentes a esses algoritmos com uma velocidade alarmante. Isso deu origem a ataques nos quais os adversários registram o tráfego criptografado hoje para descriptografá-lo no futuro, assim que tiverem acesso a um computador quântico poderoso. O mesmo desafio se aplica aos dados em repouso se um adversário conseguir fazer uma cópia agora para descriptografá-los mais tarde.

Para combater essa ameaça, o campo de PQC surgiu, desenvolvendo novos algoritmos criptográficos resistentes a ataques de computadores clássicos e quânticos.

PQC no Kubernetes e no OpenShift

O Red Hat OpenShift é uma distribuição do Kubernetes certificada pela Cloud Native Computing Foundation (CNCF), e o Kubernetes usa a linguagem de programação Go. Portanto, a jornada para o suporte a PQC no OpenShift começa com o Go.

A versão Go 1.24 representou um marco significativo ao introduzir o suporte para o mecanismo de troca de chaves híbridas X25519MLKEM768. O X25519MLKEM768 é uma troca de chave híbrida que combina o X25519 clássico (curva elíptica de Diffie-Hellman) com o ML-KEM-768 (o algoritmo pós-quântico). Ambos os mecanismos combinados geram o segredo compartilhado final. O ML-KEM puro depende inteiramente da criptografia baseada em treliça para resistência quântica. O X25519MLKEM768 oferece a resistência quântica do ML-KEM e a segurança clássica do X25519 simultaneamente.

A abordagem híbrida é genuinamente mais robusta no momento. Só padronizaram o ML-KEM em agosto de 2024, o que significa que ele é considerado "jovem" em termos criptográficos. Se alguém descobrir um ataque clássico inesperado contra as premissas da estrutura reticular do ML-KEM (não quântico, apenas criptoanálise convencional), as implementações puras do ML-KEM seriam comprometidas. Com a versão híbrida, você ainda tem o X25519 na linha.

O segredo compartilhado resultante para uma sessão de segurança da camada de transporte (TLS) fornece o nível de segurança esperado, contanto que pelo menos um dos algoritmos do componente permaneça intacto. Isso oferece uma maneira robusta e compatível com o futuro de introduzir a PQC no ecossistema.

Aplique a PQC ao plano de controle do OpenShift

O suporte para PQC no OpenShift 4.20 não se trata da configuração de sinalizadores de PQC específicos em cada componente do Kubernetes. Na verdade, trata-se da força da comunicação TLS entre esses componentes, que a versão subjacente do Go e suas bibliotecas criptográficas habilitam.

Veja como o suporte a PQC melhora a segurança da comunicação entre os principais componentes do OpenShift (discutimos o status do etcd separadamente abaixo):

• Servidor de API: como o hub central do control plane do Kubernetes, todas as comunicações de e para o servidor de API são um ponto crítico de segurança. Com o TLS habilitado para ML-KEM, a comunicação do control plane protege-se contra ataques que registram o tráfego criptografado hoje com planos de descriptografá-lo no futuro.
• Kubelet: o kubelet, executado em cada nó, comunica-se com o servidor da API para fornecer atualizações de status do nó e receber especificações do pod. Essa comunicação agora incorpora uma troca de chave PQC híbrida para aumentar a segurança, ajudando a verificar a integridade e a confidencialidade desse link.
• Scheduler e controller-manager: o scheduler e o controller-manager interagem continuamente com o servidor da API para tomar decisões de programação e gerenciar o estado do cluster. O TLS habilitado para ML-KEM também protege essas interações para fortalecer a segurança da lógica e das operações que mantêm suas aplicações em execução.

A perspectiva da Red Hat

Embora muitos regulamentos do setor não exijam a PQC até 2035, estamos trabalhando ativamente na transição para a PQC. Em um artigo recente, ”Prepare sua organização para o futuro quântico” enfatizamos a importância de começar agora a jornada da PQC. Além disso, o trabalho de integração da PQC ao Red Hat Enterprise Linux (RHEL) indica fortemente o rumo do OpenShift. A inclusão de recursos de PQC no OpenShift 4.20 é um avanço significativo.

A incompatibilidade de versões do Go

Uma consideração crucial para os administradores é o potencial de uma incompatibilidade de versão Go entre diferentes componentes em um cluster. Por exemplo, se um cliente kubectl criado com uma versão Go compatível com ML-KEM se comunicar com um servidor de API mais antigo, o handshake TLS poderá fazer o downgrade silenciosamente para um algoritmo criptográfico clássico. Isso resultaria na perda da proteção da PQC sem nenhum aviso explícito. Portanto, é essencial confirmar que todos os componentes no seu ambiente do OpenShift estão executando versões compatíveis com PQC.

E o etcd?

Embora os principais componentes do plano de controle se beneficiem do TLS habilitado para ML-KEM, a história do etcd é diferente, baseada em sua filosofia de desenvolvimento e função distintas. Como fonte de verdade definitiva para todo o cluster, as prioridades absolutas do etcd são estabilidade, integridade dos dados e desempenho. O projeto etcd intencionalmente mantém um cronograma de controle de versão Go mais conservador em comparação com o Kubernetes. Embora o projeto Kubernetes adote geralmente a versão mais recente do Go para usar novos recursos e melhorias de desempenho rapidamente, a equipe do etcd prioriza a estabilidade, aderindo a versões Go mais antigas e testadas em seus lançamentos estáveis. Esse atraso deliberado auxilia a comunidade em geral a examinar minuciosamente possíveis problemas em um novo runtime Go antes de introduzi-lo em um componente tão crítico quanto o etcd.

A falta de suporte imediato à PQC não é um descuido, mas uma consequência direta dessa abordagem que prioriza a estabilidade. Antes que se possa oferecer suporte oficial aos algoritmos de PQC, introduzidos no Go 1.24, no etcd, é preciso primeiro adotar essa versão do Go nos branches de versão estável do etcd, que atualmente ainda usam o Go 1.23. Esse processo envolve uma extensa validação para confirmar que não há impacto negativo no protocolo de consenso do Raft, na latência de E/S ou nas operações de recuperação. Fique atento ao suporte de segurança quântica no etcd em uma versão futura.

O caminho a seguir

A integração da PQC ao OpenShift 4.20 é uma prova da abordagem proativa que a Red Hat está adotando para desenvolver um futuro quântico para a computação nativa em nuvem. Embora a PQC para certificados e assinaturas digitais ainda esteja em seus estágios iniciais, implementar a troca de chave híbrida no TLS é um primeiro passo essencial.