O National Cyber Security Centre do Reino Unido publicou recomendações para configurar criptografia pós-quântica no TLS, e sua mensagem aos operadores é direta: o momento de migrar é agora. A atualização foi anunciada em uma postagem de blog, Post-quantum updates to our TLS guidance, sinalizando que as orientações de TLS da agência passam a cobrir como implantar algoritmos pós-quânticos, e não apenas se pensar neles algum dia.

Essa mudança é relevante para qualquer pessoa que opera infraestrutura de identidade no Reino Unido, ou seja, para todos que têm uma página de login. O TLS é o transporte por trás de toda asserção SAML, de toda troca de token OIDC, de toda chamada de provisionamento SCIM e de toda API que distribui bearer tokens. Se a troca de chaves que protege essas sessões puder ser quebrada por um computador quântico no futuro, a camada de identidade quebra junto. O NCSC está orientando os operadores a pararem de tratar isso como tema de pesquisa e começarem a tratá-lo como trabalho de configuração.

O comunicado em si é conciso. Ele afirma que o NCSC publicou suas recomendações para configurar criptografia pós-quântica no TLS e que a migração deve ser iniciada. No material analisado aqui, não há prazo definido, algoritmo obrigatório indicado nem qualquer mecanismo de enforcement. Os leitores devem consultar a orientação completa do NCSC para as recomendações de configuração específicas, em vez de se apoiar em resumos, incluindo este.

Algum contexto geral ajuda a explicar por que o TLS é o primeiro alvo. O risco quântico de curto prazo para o TLS não é que atacantes quebrem sessões atuais em tempo real. O risco é o "harvest now, decrypt later": um adversário registra o tráfego cifrado hoje e o decifra quando um computador quântico suficientemente capaz existir. Isso torna a troca de chaves a parte urgente, pois ela protege a confidencialidade de tudo que vem a seguir. Assinaturas e certificados também importam, mas um certificado forjado só é útil no momento do ataque, enquanto uma sessão gravada permanece gravada para sempre. É por isso que os trabalhos da indústria sobre TLS pós-quântico, incluindo rascunhos no grupo de trabalho TLS do IETF sobre troca de chaves híbrida, têm se concentrado em combinar um acordo de chaves clássico com um mecanismo de encapsulamento de chaves pós-quântico, de modo que a sessão seja segura se qualquer um dos dois resistir. O NIST publicou padrões finais para algoritmos pós-quânticos, incluindo o mecanismo de encapsulamento de chaves ML-KEM no FIPS 203, que é o bloco construtivo utilizado pela maioria dessas implantações híbridas. Se e como as orientações do NCSC se alinham a esses detalhes cabe à própria orientação explicar.

Para as equipes de IAM, a verdade incômoda é que a configuração de TLS costuma ser problema de outra pessoa, até que deixa de ser. Provedores de identidade, reverse proxies, API gateways, load balancers e aquele keystore Java esquecido em algum canto todos encerram TLS, e raramente têm um único responsável. A troca de chaves pós-quântica tende a chegar como um recurso de negociação entre cliente e servidor, de modo que um navegador moderno conversando com uma CDN moderna pode já estar usando enquanto a conexão LDAP-over-TLS com o diretório on-premises negocia cipher suites que eram modernos na era dos celulares com teclado físico. A boa notícia é que a maior parte do trabalho é inventário e atualizações, não invenção criptográfica. Ninguém está sendo solicitado a implementar um esquema de reticulados em um final de semana. Está sendo pedido que as pessoas saibam o que operam, atualizem e ativem as opções corretas.

Há também um precedente encorajador. A migração do TLS 1.0 e 1.1, assim como a aposentadoria anterior dos certificados SHA-1, pareciam intermináveis na época e ambas foram concluídas, em grande parte porque navegadores e bibliotecas se moveram primeiro e o restante do ecossistema seguiu. O TLS pós-quântico está se moldando da mesma forma. As organizações que tratarem as orientações do NCSC como uma checklist agora passarão os próximos anos aplicando patches discretamente. As que esperarem terão a oportunidade de redescobrir cada endpoint TLS não documentado em seu ambiente durante um incidente, o que é uma péssima forma de construir um inventário de ativos, mas, reconhecidamente, uma forma bastante completa.

O que verificar: comece com um inventário de cada ponto de encerramento de TLS no caminho de identidade, incluindo endpoints do IdP, APIs de token e introspecção, conectores SCIM, LDAPS e quaisquer sidecars de service mesh, e registre a versão da biblioteca ou do appliance por trás de cada um. Leia as orientações do NCSC na íntegra e compare suas recomendações de configuração com o que esses endpoints conseguem negociar hoje, prestando atenção especial à troca de chaves. Em seguida, abra chamados com os fornecedores que ainda não suportam isso, porque um caminho de atualização suportado é a única coisa que uma mudança de configuração não consegue simular.