Cloudflare lança beta do GeoKey pós-quântico

Segurança Digital

Nova solução da Cloudflare oferece proteção avançada para chaves de descriptografia com tecnologia pós-quântica.

Leia também: AWS Security Agent code review: Continuum corrige 89% das falhas

A Cloudflare colocou em beta fechado uma versão pós-quântica do GeoKey Manager para clientes da Data Localization Suite, redesenhando o serviço que protege chaves de descriptografia geograficamente restritas e trocando a criptografia baseada em atributos por um esquema híbrido com ML-KEM-768 e X25519 para reforçar soberania de dados e defesa contra ataques com computadores quânticos.

Cloudflare abandona criptografia por atributos

O GeoKey Manager é o serviço que garante que chaves privadas usadas para descriptografar tráfego só sejam acessadas em data centers autorizados, dentro de regiões específicas. Desde 2022, essa proteção se baseava em criptografia por atributos, um modelo flexível que permite expressar políticas finas de localização. Agora, a Cloudflare aposenta esse desenho em favor de uma arquitetura considerada mais simples para os clientes e compatível com criptografia resistente à computação quântica.

Os engenheiros Chetan Agrawal, Arka Nayan e Erik Engstrom explicam que a mudança responde a duas pressões simultâneas: regras de soberania de dados, que proíbem o processamento de texto simples fora de determinadas jurisdições, e o risco dos ataques chamados de “harvest-now, decrypt-later”, em que invasores capturam hoje dados cifrados para tentar quebrá-los no futuro com máquinas quânticas.

O problema central é que não existe, hoje, uma variante pós-quântica pronta para produção do esquema de criptografia baseada em atributos usado no serviço. Ao mesmo tempo, boa parte dos clientes não utiliza a complexidade de múltiplas regiões e combinações que esse modelo permite. A solução foi reconstruir o GeoKey Manager sobre um padrão diferente de criptografia pública, com componentes já avaliados para um cenário pós-quântico.

Entenda o contexto

A Cloudflare vem ampliando o uso de criptografia híbrida que combina algoritmos clássicos e pós-quânticos. Em março, a empresa passou a usar ML-KEM em modo híbrido no serviço de IPsec, e afirma que mais de 60% do tráfego TLS humano em sua rede já roda com esse tipo de proteção. O novo GeoKey segue a mesma linha, ao unir ML-KEM-768, candidato de criptografia de chave resistente a quântica, com X25519, amplamente usado hoje em trocas de chaves.

No plano estratégico, o GeoKey pós-quântico é uma peça da agenda de “segurança futura” da Cloudflare, que inclui também planos para uma autoridade certificadora (CA) resistente a ataques de computadores quânticos. Para setores como finanças, saúde e governo, essas mudanças são apresentadas como um caminho para manter conformidade com legislações locais de dados e, ao mesmo tempo, antecipar ameaças que ainda não são práticas, mas já preocupam reguladores e equipes de segurança.

Como funciona o GeoKey Manager pós-quântico

No novo desenho, a proteção das chaves usa HPKE (Hybrid Public Key Encryption), conforme o padrão RFC 9180. O mecanismo de encapsulamento de chaves (KEM) é híbrido, combinando ML-KEM-768 e X25519, com derivação de chaves via HKDF-SHA-256 e criptografia de dados com AES-256-GCM.

Em vez de políticas expressas em atributos, o sistema passa a trabalhar com dois tipos de segredo. Primeiro, chaves raiz regionais simétricas de 256 bits, mantidas uma por região. Depois, pares de chaves específicos para aplicações, derivados dessas raízes. Cada par é vinculado a um serviço (como Tunnel ou Gateway) e a uma “época”, termo usado pela Cloudflare para cada geração de chave nas rotações.

Na prática, o serviço de gerenciamento de chaves deriva o par de chaves de aplicação a partir da raiz regional e da época corrente. Em seguida, envolve as chaves privadas dos clientes sob o componente público desse par. Com isso, a chave efetiva do cliente fica “embrulhada” de forma que só servidores autorizados, na região correta e na época correta, consigam acessá-la.

Distribuição via Quicksilver e serviço de provisionamento

As chaves seguem caminhos diferentes dentro da infraestrutura da Cloudflare. O Quicksilver, armazenamento global de chave-valor replicado, carrega chaves já protegidas e metadados para todos os pontos da rede. As chaves raiz regionais, mais sensíveis, trafegam por um caminho separado, controlado pelo serviço de provisionamento, que as mantém em um cofre de segredos (Vault).

Antes que um servidor de borda receba uma chave raiz regional, ele precisa passar por três verificações. A primeira é a autenticação de hardware via TPM, que comprova a identidade física da máquina. A segunda é uma consulta ao Zinc, inventário interno de servidores, que associa aquela identidade ao data center e à localização geográfica. A terceira é a decisão do serviço de provisionamento, que determina quais chaves raiz aquele servidor está autorizado a armazenar.

Somente depois de aprovado nesse triplo filtro o servidor carrega a chave raiz na memória volátil do kernel, por meio do mecanismo de keyring. Nada é gravado em disco. “A máquina reinicia e remove as chaves, e o servidor precisa se autenticar novamente”, destacam os engenheiros da Cloudflare. Esse comportamento limita o tempo de exposição em caso de comprometimento de um host específico.

Como funciona a rotação das chaves geo-restritas?

A rotação das chaves geo-restritas é feita por um modelo de épocas, com múltiplas gerações ativas ao mesmo tempo para permitir trocas sem interrupção do serviço. Cada época corresponde a um conjunto de chaves derivadas de uma raiz regional para um serviço específico.

Na discussão pública sobre o novo desenho, Dabeer Shaikh, engenheiro de soluções sênior da HashiCorp, perguntou “como uma chave geo-restrita pode ser rotacionada sem downtime?”. A resposta da Cloudflare está justamente no uso das épocas: durante uma rotação suave, o sistema cria uma nova época, mas mantém um número limitado de épocas anteriores ainda válidas. Assim, requisições que chegam cifradas sob chaves antigas continuam atendidas enquanto os clientes migram para a nova geração.

Quando é necessário um corte mais drástico, a empresa fala em rotação “dura”. Nesse caso, as chaves afetadas são reempacotadas sob a nova época, e o acesso às gerações anteriores é encerrado. Esse tipo de operação pode ser disparado, por exemplo, diante da suspeita de comprometimento de uma raiz regional ou quando políticas internas exigem renovação imediata.

Segundo a Cloudflare, a rotação de épocas e a atualização do mapa de quais servidores pertencem a cada região são processos separados. A associação de máquinas a regiões é atualizada várias vezes por dia, para acompanhar mudanças na rede, e isso ocorre sem intervenção dos clientes. A intenção é manter a capacidade de reagir rápido a incidentes e mudanças de infraestrutura, sem expor dados a data centers errados.

Falha fechada aumenta segurança, mas pode derrubar região?

O novo GeoKey adota explicitamente um desenho de “falha fechada”: se algo der errado em qualquer verificação de contexto, região ou época, o sistema simplesmente recusa o pedido e o serviço não sobe. “Uma falha em qualquer verificação rejeita a requisição e impede o serviço de iniciar, um design intencional”, dizem os engenheiros da Cloudflare.

Na prática, isso significa que problemas em componentes de controle podem resultar em indisponibilidade, e não em uma degradação silenciosa da segurança. Se o Zinc registrar um servidor como pertencente à região errada, se o serviço de provisionamento se recusar a entregar uma chave raiz, ou se houver inconsistência entre as épocas configuradas, o resultado é o bloqueio do acesso às chaves georrestritas naquele ponto.

Mark Tehrani, fundador da consultoria CyberSeQ e professor de cibersegurança, resumiu a principal preocupação em uma pergunta direta: “se provisionamento, sincronização ou rotação falharem, o design pode causar indisponibilidade regional?”. O questionamento atinge o coração do trade-off feito pela Cloudflare, que prefere correr o risco de uma região sair do ar a permitir que chaves sejam entregues a servidores não autorizados ou em localizações erradas.

A empresa responde que o Quicksilver, responsável por distribuir chaves já protegidas e metadados, permanece fora da fronteira de confiança, justamente porque nunca carrega segredos em texto simples. O perímetro crítico se limita ao serviço de gerenciamento de chaves, ao provisionamento e aos serviços de borda autorizados. Se qualquer elo dessa cadeia falhar ou suspeitar de irregularidade, a ordem é bloquear o acesso.

Impacto para clientes e risco operacional

Para clientes da Data Localization Suite, sobretudo em setores regulados, o novo GeoKey promete reforçar garantias de que dados sensíveis ficam confinados às regiões exigidas por lei e que as chaves associadas a esse tráfego já nascem protegidas contra ataques com computadores quânticos. A adoção de ML-KEM-768 em modo híbrido com X25519 busca preservar compatibilidade com o cenário atual e, ao mesmo tempo, blindar contra avanços futuros na quebra de criptografia.

O outro lado dessa moeda é a complexidade operacional. O fluxo que envolve TPM, Zinc, serviço de provisionamento, Vault, kernel keyring e múltiplas épocas de rotação amplia a superfície para falhas de coordenação interna. A opção por falhar fechado significa que erros nesses componentes podem escalar para indisponibilidade regional de serviços que dependem do GeoKey.

Especialistas apontam que ambientes que exigem alta disponibilidade podem sentir com mais força esse tipo de escolha, em especial se dependem de janelas mínimas de outage. A Cloudflare, por sua vez, argumenta que expor temporariamente chaves ou violar soberania de dados seria pior que uma interrupção, mesmo que localizada e temporária.

Beta fechado testa equilíbrio entre segurança e disponibilidade

O beta fechado, aberto em 23 de outubro para clientes existentes da Data Localization Suite em regiões já cobertas pelo serviço, é o campo de provas desse novo equilíbrio. Durante o período de testes, a Cloudflare pretende medir como o desenho de falha fechada se comporta em escala regional e quais ajustes são necessários para reduzir o risco de indisponibilidade sem afrouxar as garantias de segurança.

A empresa projeta disponibilizar o novo GeoKey Manager pós-quântico de forma geral no primeiro trimestre de 2027, com cobertura da maior parte das regiões em que já opera, mas com ressalvas específicas por produto. Até lá, também deve avançar em outras iniciativas pós-quânticas, como a maturação da autoridade certificadora resistente a quântica e a expansão do uso de ML-KEM híbrido em mais pontos da rede.

O desempenho desse beta, em particular a aceitação pelos clientes da ideia de que qualquer verificação falha leva à recusa do serviço, deve influenciar não só o futuro do GeoKey Manager, mas também o padrão de como o mercado trata chaves georrestritas e ameaças quânticas em projetos de soberania digital.