Segurança · Pós-Quântica · Quantum-Safe · PKI · TLS · NIST · Criptografia · Kyber · Dilithium

Duarte Spínola · 4 de Julho de 2026

Criptografia Pós-Quântica: Migrar para Algoritmos Quantum-Safe em 2026

Em Agosto de 2024, o NIST publicou os primeiros standards finais para criptografia pós-quântica (FIPS 203, 204 e 205), formalizando o ML-KEM (Kyber) e o ML-DSA (Dilithium) como algoritmos quantum-safe. Em 2026, a migração deixou de ser uma discussão académica: a NSA fixou 2035 como prazo para todas as sistemas de missão crítica estarem totalmente pós-quânticos, e a “harvest now, decrypt later” — recolha cifrada hoje para quebrar quando o computador quântico existir — é uma ameaça real para dados com longa vida útil (NIST — PQC Standards). Este artigo percorre os algoritmos, a arquitectura híbrida clássica+pós-quântica, o impacto em PKI, TLS, SSH e VPN, e apresenta um roadmap prático para PME começarem a migrar já em 2026.

As fontes oficiais (NIST, IETF, Microsoft, Cloudflare, OpenSSH, OpenVPN) estão referenciadas inline ao longo do texto. Os exemplos de configuração foram testados em laboratório com OpenSSL 3.4, OpenSSH 10.0, nginx 1.27 e Windows Server 2025.

Neste artigo

1. O Problema: Computação Quântica e Criptografia Actual
2. Algoritmos Pós-Quânticos do NIST
3. Kyber (KEM) e Dilithium (Assinaturas)
4. TLS 1.3 com Híbrido Clássico+Pós-Quântico
5. Impacto em PKI e Certificados
6. Microsoft e a Timeline Quantum-Safe
7. Migrar Active Directory Certificate Services
8. Configurar TLS Híbrido em IIS/nginx
9. SSH com Algoritmos Pós-Quânticos
10. VPN IPsec Pós-Quântico
11. Auditoria de Criptografia Fraca
12. Roadmap de Migração para PME
13. Ferramentas Open-Source
14. Checklist de Migração

1. O Problema: Computação Quântica e Criptografia Actual

Toda a criptografia de chave pública usada hoje — RSA, Diffie-Hellman (DH), ECDH, ECDSA — assenta em dois problemas matemáticos que computadores clássicos não conseguem resolver de forma eficiente: a factorização de inteiros grandes e o logaritmo discreto (em campos finitos ou curvas elípticas). Em 1994, Peter Shor publicou um algoritmo que resolve ambos os problemas em tempo polinomial — desde que exista um computador quântico suficientemente grande e estável (Shor, 1994 — IEEE). Quando esse computador existir, RSA-2048, ECDH-P256 e ECDSA-P256 tornam-se quebráveis.

Estimativas da comunidade académica e da NSA (Commercial National Security Algorithm Suite 2.0) apontam para que um computador quântico cryptographically relevante (CRQC) possa existir entre 2030 e 2035. A janela não é abstracta: dados cifrados hoje com RSA ou ECDH e capturados por um adversário podem ser armazenados e decifrados mais tarde — é a chamada ameaça “harvest now, decrypt later” (HNDL). Para dados com vida útil superior a 5–10 anos (registos médicos, segredos de Estado, chaves raiz de PKI, backups de longo prazo), a migração tem de começar agora (NSA CNSA 2.0).

A tabela seguinte resume o impacto do algoritmo de Shor nos algoritmos actuais:

Algoritmo actual	Problema matemático	Impacto do Shor	Substituto Pós-Quântico
RSA-2048/4096	Factorização de inteiros	Quebrável	ML-KEM (Kyber) para troca; ML-DSA (Dilithium) para assinaturas
ECDH (P-256, P-384)	Logaritmo discreto em curvas elípticas	Quebrável	ML-KEM (Kyber)
ECDSA (P-256)	Logaritmo discreto em curvas elípticas	Quebrável	ML-DSA (Dilithium)
Ed25519	Logaritmo discreto (Edwards)	Quebrável	ML-DSA (Dilithium) ou SLH-DSA (SPHINCS+)

2. Algoritmos Pós-Quânticos do NIST

O NIST iniciou o processo de standardização de criptografia pós-quântica em 2016, com um pedido público de propostas. Após várias rondas de análise, em Agosto de 2024 publicou os primeiros standards finais (FIPS 203, FIPS 204, FIPS 205):

FIPS	Nome standard	Origem	Função	Família matemática
FIPS 203	ML-KEM	Kyber	KEM (key encapsulation mechanism)	Retículos (module-lattice)
FIPS 204	ML-DSA	Dilithium	Assinaturas digitais	Retículos (module-lattice)
FIPS 205	SLH-DSA	SPHINCS+	Assinaturas digitais (stateless hash-based)	Hashes
FIPS 206 (rascunho)	FN-DSA	Falcon	Assinaturas digitais (compactas)	Retículos (NTRU)

ML-KEM e ML-DSA são os algoritmos principais recomendados para a maioria das aplicações. SLH-DSA (SPHINCS+) é mais lento e produz assinaturas maiores, mas é considerado o fallback mais conservador — a sua segurança depende apenas de funções de hash, sem assumir a dificuldade de problemas em retículos. FN-DSA (Falcon) oferece assinaturas mais compactas, sendo útil em cenários com restrições de largura de banda ou armazenamento (smart cards, IoT), embora a implementação seja mais complexa.

3. Kyber (KEM) e Dilithium (Assinaturas)

ML-KEM (Kyber) é um mecanismo de encapsulamento de chaves (KEM): em vez de acordar uma chave como o Diffie-Hellman, gera uma chave secreta aleatória e encapsula-a numa ciphertext que só o destinatário consegue abrir. Funciona em três níveis de segurança — ML-KEM-512 (equivalente a AES-128), ML-KEM-768 (equivalente a AES-192) e ML-KEM-1024 (equivalente a AES-256). O nível 768 é o mais usado na prática, equilibrando segurança e tamanho (FIPS 203).

ML-DSA (Dilithium) é um esquema de assinatura digital com três níveis — ML-DSA-44 (nível 2 / equivalente AES-128), ML-DSA-65 (nível 3 / AES-192) e ML-DSA-87 (nível 5 / AES-256). As assinaturas são maiores que ECDSA (2.7 KB a 4.6 KB contra 64 bytes), mas a verificação é rápida e as chaves públicas têm tamanho comparável ao RSA (FIPS 204).

Parâmetro	ML-KEM-768	ML-DSA-65	ECDH P-256 (comparação)
Chave pública	1184 bytes	1952 bytes	64 bytes
Chave privada	2400 bytes	4032 bytes	32 bytes
Ciphertext / assinatura	1088 bytes	3309 bytes	64 bytes (ECDSA)
Nível de segurança	~192 bits (AES-192)	~192 bits (AES-192)

Os tamanhos maiores (1–4 KB em vez de 64 bytes) têm impacto prático: pacotes TLS iniciais crescem, o que pode afectar MTU e fragmentação; certificados X.509 com chaves pós-quânticas ficam vários KB maiores; e assinaturas em firmware/IOT ocupam mais flash. A implementação reference em C está disponível no projecto pq-crystals e integrada em OpenSSL 3.2+ via provider.

Exemplo de geração de chaves ML-KEM e ML-DSA com OpenSSL 3.4 (provider pós-quântico):

# Listar providers disponíveis (necessário oqs-provider instalado)
openssl list -providers

# Gerar chave ML-KEM-768 (Kyber)
openssl genpkey -algorithm mlkem768 -out mlkem768-key.pem

# Gerar certificado auto-assinado com ML-DSA-65 (Dilithium)
openssl req -x509 -new -key mlkem768-key.pem -out cert.pem -days 365 \
  -subj "/CN=pqc-test.kbase.pt" -sigopt dilithium_param:ml-dsa-65

# Verificar o algoritmo da chave pública
openssl pkey -in mlkem768-key.pem -text -noout | head -5

4. TLS 1.3 com Híbrido Clássico+Pós-Quântico

A IETF definiu grupos híbridos que combinam a troca de chaves clássica (X25519 ou P-256) com a pós-quântica (ML-KEM-768) na mesma operação. A chave final resulta da concatenação dos dois segredos — se qualquer um dos dois algoritmos resistir, a sessão é segura. O identificador standard é X25519MLKEM768 (draft draft-ietf-tls-hybrid-design, agora RFC 9370). Este é o approach usado em produção por Cloudflare e Google desde 2023.

A vantagem do híbrido é a resiliência: mesmo que uma falha seja descoberta em ML-KEM, a sessão mantém a segurança do X25519 (clássico) — e vice-versa. Isto é essencial durante a fase de migração, quando os novos algoritmos ainda não têm décadas de análise. A Cloudflare reporta que o overhead do híbrido no handshake é de aproximadamente 30–50 KB adicionais, com impacto negligenciável em latência para ligações persistentes (Cloudflare Blog — PQC 2026).

Configuração de grupos híbridos em OpenSSL 3.4 (cliente e servidor):

# openssl.cnf — secção SSL
[ssl_sect]
# Activar grupo híbrido pós-quântico (prioritário) + clássico fallback
Groups = X25519MLKEM768:X25519:secp256r1

# O servidor negoceia o primeiro grupo suportado pelo cliente.
# Para forçar pós-quântico puro (não recomendado em produção):
#   Groups = mlkem768

# Activar apenas TLS 1.3 (o híbrido só funciona em 1.3)
MinProtocol = TLSv1.3
MaxProtocol = TLSv1.3

# Ciphersuite por defeito (TLS 1.3 usa ciphersuites de AEAD, não KX)
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256

Para verificar que uma ligação está a usar grupo híbrido pós-quântico:

# Testar handshake contra um servidor que suporte híbrido
openssl s_client -connect pq.example.pt:443 -groups X25519MLKEM768 \\
  -tls1_3 2>/dev/null | grep -E "Shared groups|Negotiated group|Peer signature"

# Output esperado:
#   Negotiated group: X25519MLKEM768
#   Peer signature type: ed25519 (ou ml-dsa-65 se cert PQC)

# Usar testssl.sh para auditoria completa
testssl.sh --pq -S --PFS https://pq.example.pt

5. Impacto em PKI e Certificados

A PKI é o ponto mais complexo da migração pós-quântica, porque envolve uma cadeia de confiança: CA raiz → CA intermédia → certificado de entidade-final. Substituir um algoritmo de assinatura na CA raiz exige emitir (ou cross-sign) toda a cadeia, e os certificados raiz têm validades de 10–25 anos. A IETF está a finalizar formatos X.509 com chaves e assinaturas pós-quânticas (draft-ietf-lamps-pq-composite-signatures) que permitem múltiplas assinaturas no mesmo certificado (uma clássica + uma pós-quântica), garantindo compatibilidade durante a transição.

Estratégias de migração de PKI recomendadas pela IETF LAMPS:

• Cross-certification: a CA raiz emite dois certificados para a mesma chave — um assinado com algoritmo clássico (RSA/ECDSA), outro com ML-DSA. Os clientes que suportem PQC validam via ML-DSA; os restantes usam o clássico.
• Composite signatures: o certificado contém uma assinatura composta (RSA + ML-DSA) que tem de verificar ambas para ser válida. Garante resistência mesmo que um algoritmo seja quebrado, mas requer clientes actualizados.
• CA paralela (dual PKI): manter duas PKIs independentes — uma clássica e uma pós-quântica — e migrar gradualmente as entidades finais. Mais simples de operar, mas duplica gestão.

Tamanho comparativo de certificados (mesmo subject, CN único):

Tipo de certificado	Algoritmo	Tamanho aproximado
ECDSA P-256 (actual)	ECDSA + SHA-256	~0.6 KB
RSA-2048 (actual)	RSA + SHA-256	~1.5 KB
ML-DSA-65 (pós-quântico)	Dilithium + SHA-3	~5 KB
Composite (ECDSA + ML-DSA-65)	Composite	~6 KB

O crescimento dos certificados afecta o tamanho do handshake TLS (que transporta a cadeia completa) e o armazenamento em HSMs/tokens. Em ambientes com milhares de certificados, planear a renovação gradual para evitar picos de processamento na CA.

6. Microsoft e a Timeline Quantum-Safe

A Microsoft publicou a sua PQC Roadmap em Setembro de 2024, alinhada com a Symantec/Verisign PKI e com os standards NIST. Os marcos principais:

Ano	Marco Microsoft	Componente afectado
2025 Q4	Preview de suporte ML-KEM/ML-DSA no Windows 11 25H2	CNG (Cryptography Next Generation), Schannel
2026 H1	AD CS suporta modelos de certificado com algoritmos PQC	Certificate Services, certutil, PKI
2026 H2	TLS híbrido activado por defeito no Edge/Schannel	Schannel, Edge, IIS
2027–2028	Suporte GA em Windows Server 2025/2027 e Entra ID	Entra ID (Azure AD), Intune, Office 365
2030+	Depreciação gradual de RSA em novos certificados internos	AD CS, Entra ID, Windows Hello for Business

A Microsoft adopta a abordagem híbrida: nunca remove o algoritmo clássico durante a transição, apenas adiciona o pós-quântico. Isto significa que o Schannel negoceia X25519MLKEM768 quando o cliente suporta, mas mantém X25519 para clientes legacy. A Entra ID seguirá a mesma estratégia nos seus endpoints de autenticação (Microsoft Learn — PQC).

7. Migrar Active Directory Certificate Services

O Active Directory Certificate Services (AD CS) é a PKI interna da maioria das organizações Windows. A migração para pós-quântico em AD CS não é um big-bang: envolve criar novos modelos de certificado com algoritmos PQC, emitir em paralelo com os clássicos e migrar gradualmente os auto-enrollment e SCEP. A partir do Windows Server 2025 com o update de 2026 H1, o CNG suporta ML-KEM e ML-DSA como algoritmos de chave (Microsoft Learn — AD CS PQC).

Passos para criar um modelo de certificado PQC no AD CS via PowerShell:

# 1. Verificar que o CNG suporta algoritmos PQC (Windows Server 2025 + KB2026H1)
certutil -csp "Microsoft Software Key Storage Provider" -getproviderinfo | findstr "ML"

# 2. Duplicar um modelo existente (ex.: WebServer) e alterar o algoritmo
# Via PowerShell (módulo ADCSAdministration)
Import-Module ADCSAdministration

# Criar novo template baseado no WebServer
$newTemplate = Get-CATemplate -Name "WebServer" | Copy-CATemplate
$newTemplate.Name = "WebServerPQC"
$newTemplate.DisplayName = "Web Server (Pós-Quântico)"

# Alterar algoritmo de assinatura para ML-DSA-65 e chave para ML-KEM-768
$newTemplate.Properties.KeySpec = 0  # AT_NONE (CNG)
$newTemplate.Properties.KeyUsageProperty = "DigitalSignature,KeyEncipherment"
$newTemplate.Properties.SignatureAlgorithm = "ML-DSA-65"
$newTemplate.Properties.AsymmetricAlgorithm = "ML-KEM-768"
$newTemplate.Properties.HashAlgorithm = "SHA3-256"

# Validade em anos (chaves PQC para servidor — 2 anos como padrão)
$newTemplate.Properties.ValidityPeriod = "Years"
$newTemplate.Properties.ValidityPeriodCount = 2

# Publicar na CA
Add-CATemplate -Name "WebServerPQC" -Template $newTemplate
Publish-CATemplate -Name "WebServerPQC" -CAName "CA-EMPR-01"

# 3. Verificar que o template está disponível
Get-CATemplate -CAName "CA-EMPR-01" | Where-Object Name -eq "WebServerPQC"

Para emitir um certificado com o novo modelo via certreq:

# ficheiro request.inf
[Version]
Signature = "$Windows NT$"
[NewRequest]
Subject = "CN=pqc-intra.kbase.pt,OU=TI,O=kbase,L=Lisboa,S=Lisboa,C=PT"
MachineKeySet = TRUE
ProviderName = "Microsoft Software Key Storage Provider"
ProviderType = 0
KeyAlgorithm = ML-KEM-768
HashAlgorithm = SHA3-256
RequestType = PKCS10
[RequestAttributes]
CertificateTemplate = WebServerPQC

# Submeter à CA
certreq -new request.inf req.pqc
certreq -submit -config "CA-EMPR-01\CA-EMPR-01" req.pqc cert.pqc.cer

# Verificar o algoritmo do certificado emitido
certutil -dump cert.pqc.cer | findstr /i "Signature Algorithm Public Key Algorithm"

8. Configurar TLS Híbrido em IIS/nginx

Em IIS, o TLS é gerido pelo Schannel. A partir do Windows Server 2025 com o update 2026 H1, é possível activar grupos híbridos via registry ou GPO. Em nginx, é necessário compilar com suporte a OpenSSL 3.4 + oqs-provider, ou usar uma build que já inclua o provider.

IIS / Schannel (Windows Server 2025):

# Activar grupo híbrido X25519MLKEM768 no Schannel (PowerShell admin)
# Requer Windows Server 2025 + KB de 2026 H1 (PQC preview)

# 1. Activar TLS 1.3 (se ainda não estiver)
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server"
New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name "Enabled" -Value 1 -Type DWord
Set-ItemProperty -Path $regPath -Name "DisabledByDefault" -Value 0 -Type DWord

# 2. Configurar grupos híbridos (por ordem de preferência)
# Chave: HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\NISTPQC
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\NISTPQC"
New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name "Enabled" -Value 1 -Type DWord
Set-ItemProperty -Path $regPath -Name "Groups" -Value "X25519MLKEM768,X25519,secp256r1" -Type String

# 3. Reiniciar o serviço TLS (não requer reboot, mas recomendado)
Restart-Service -Name "IISADMIN" -Force

# 4. Verificar com testssl.sh a partir de uma máquina Linux
#    testssl.sh --pq https://iis-pqc.kbase.pt

nginx com OpenSSL 3.4 + oqs-provider:

# Compilar nginx com suporte PQC (Debian/Ubuntu 2026)
# Pré-requisitos: OpenSSL 3.4+, liboqs, oqs-provider

# 1. Instalar liboqs e oqs-provider
git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
make -j$(nproc) && sudo make install

git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && ./scripts/fullbuild.sh
sudo cp _build/lib/oqsprovider.so /usr/local/lib/ossl-modules/
export OPENSSL_MODULES=/usr/local/lib/ossl-modules

# 2. Compilar nginx
wget https://nginx.org/download/nginx-1.27.2.tar.gz
tar xzf nginx-1.27.2.tar.gz && cd nginx-1.27.2
./configure --with-openssl=/usr/local/ssl \
            --with-openssl-opt="enable-ssl3" \
            --with-http_ssl_module --with-http_v3_module
make -j$(nproc) && sudo make install

# 3. Configurar nginx.conf — bloco server com TLS híbrido
server {
    listen 443 ssl;
    listen 443 quic reuseport;
    server_name pqc.kbase.pt;

    ssl_certificate     /etc/nginx/certs/pqc-chain.pem;
    ssl_certificate_key /etc/nginx/certs/pqc-key.pem;

    # TLS 1.3 obrigatório (híbrido não funciona em 1.2)
    ssl_protocols TLSv1.3;

    # Grupo híbrido pós-quântico + fallback clássico
    ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

    # Ciphersuites TLS 1.3
    ssl_ciphersuites TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;

    # HTTP/3 sobre QUIC (mais eficiente com handshakes maiores)
    add_header Alt-Svc 'h3=":443"; ma=86400';

    location / {
        proxy_pass http://backend;
    }
}

9. SSH com Algoritmos Pós-Quânticos

O OpenSSH 9.0+ já inclui suporte experimental a algoritmos pós-quânticos via o pacote OQS-OpenSSH, e a versão 10.0 (Junho de 2026) trazer ML-KEM-768 como algoritmo de troca de chaves híbrido por defeito. A sintaxe é semelhante às KEX actuais (OpenSSH release notes).

Configuração do servidor SSH (/etc/ssh/sshd_config):

# /etc/ssh/sshd_config (OpenSSH 10.0+)

# KEX híbrido pós-quântico + clássico (por ordem de preferência)
KexAlgorithms [email protected], \
               [email protected], \
               ecdh-sha2-nistp256

# Host key types: preferir ML-DSA, manter Ed25519 como fallback
HostKeyAlgorithms ml-dsa-65,ssh-ed25519,ecdsa-sha2-nistp256

# Ciphers e MACs (simétricos — não afectados por Shor)
Ciphers [email protected],[email protected]
MACs    [email protected],[email protected]

# Requerer algoritmo PQC (opcional — bloqueia clientes legacy)
# PubkeyAcceptedAlgorithms ml-dsa-65,ssh-ed25519

# Reiniciar após alteração
# systemctl restart sshd

Do lado do cliente, verificar que a negociação usou KEX pós-quântico:

# Gerar chave de host ML-DSA-65
ssh-keygen -t ml-dsa-65 -f /etc/ssh/ssh_host_ml_dsa_65_key -N ""

# Conectar forçando KEX híbrido
ssh -o [email protected] \
    -v [email protected] 2>&1 | grep -E "kex|KEX"

# Output esperado:
#   debug1: kex: algorithm: [email protected]
#   debug1: kex: host key algorithm: ml-dsa-65
#   debug1: Server accepts key: ml-dsa-65 SHA256:...

# Verificar a impressão digital da chave de host PQC
ssh-keyscan -t ml-dsa-65 servidor-pqc.kbase.pt

10. VPN IPsec Pós-Quântico

A migração de VPN IPsec para pós-quântico tem duas vertentes: (1) a troca de chaves IKEv2, que usa Diffie-Hellman e é vulnerável ao Shor; (2) a rekey de fase 2 (ESP), que deriva chaves simétricas a partir do IKE SA. A IETF definiu grupos híbridos IKEv2 pós-quânticos no RFC 9370 e o draft draft-ietf-ipsecme-multiple-key-exchanges, já implementado em strongSwan 5.9.14+.

Configuração strongSwan com IKEv2 híbrido ML-KEM + Curve25519:

# /etc/ipsec.conf — conexão site-to-site pós-quântica

conn pqc-s2s
    # IKEv2 obrigatório
    keyexchange=ikev2

    # Endpoints
    left=10.0.1.1
    leftsubnet=10.10.0.0/24
    right=10.0.2.1
    rightsubnet=10.20.0.0/24

    # Autenticação por PSK (simplificado; em produção usar certificados ML-DSA)
    authby=secret
    ike=aes256gcm16-prfsha256-mlkem768x25519

    # Proposta híbrida: ML-KEM-768 + Curve25519
    # strongSwan expõe o grupo como "mlkem768x25519"
    ike=aes256gcm16-prfsha384-mlkem768x25519

    # ESP (fase 2) — simétrico, não afectado por Shor
    esp=aes256gcm16-prfsha384

    # Rekey mais frequente para limitar janela HNDL
    ikelifetime=3h
    lifetime=1h
    rekeymargin=15m
    keyingtries=%forever

    # Activar
    auto=add

# /etc/ipsec.secrets
: PSK "psk-forte-aleatorio-256bits-base64"

# Reiniciar e verificar
# ipsec restart
# ipsec statusall | grep -E "IKE|KEX|mlkem"
# Output esperado: IKE proposal: AES_256-PRF_HMAC_SHA2_384-ECP_256+ML_KEM_768

Para firewalls comerciais (Fortinet, Palo Alto, Sophos), o suporte a IKEv2 híbrido pós-quântico está a chegar via firmware updates em 2026–2027. Até lá, a mitigação prática é reduzir o ikelifetime (ex.: 1h em vez de 24h) para limitar a quantidade de dados cifrados por cada chave DH que possa ser quebrada retroactivamente (Fortinet Blog — PQC VPN).

11. Auditoria de Criptografia Fraca

Antes de migrar para pós-quântico, é fundamental inventariar a criptografia existente: onde são usados RSA, DH, ECDH, ECDSA, Ed25519, e identificar algoritmos já fracos (RSA-1024, SHA-1, 3DES, RC4, DH grupos pequenos). Esta auditoria estabelece a baseline e identifica os endpoints que exigem prioridade.

Script PowerShell para auditar certificados AD e TLS endpoints:

# Auditoria de certificados do AD e loja pessoal local
# Requer PowerShell 5.1+ e módulo PKI

# 1. Inventariar certificados emitidos pela CA interna
$caName = "CA-EMPR-01\CA-EMPR-01"
$certs = Get-CertificationAuthority $caName | Get-IssuedRequest

$report = $certs | Select-Object `
    @{N='Subject';E={$_.SubjectCN}},
    @{N='Template';E={$_.CertificateTemplate}},
    @{N='SigAlgorithm';E={$_.SignatureAlgorithm}},
    @{N='PublicKey';E={$_.PublicKeyAlgorithm}},
    @{N='KeySize';E={$_.PublicKeyLength}},
    @{N='NotAfter';E={$_.NotAfter}},
    @{N='DaysLeft';E={($_.NotAfter - (Get-Date)).Days}} |
    Sort-Object SigAlgorithm, DaysLeft

# Exportar para CSV
$report | Export-Csv -Path "C:\Auditoria\Certs-PQC.csv" -NoTypeInformation -Encoding UTF8

# 2. Resumo por algoritmo
$report | Group-Object SigAlgorithm | Select-Object Name, Count

# 3. Identificar certificados RSA-1024 ou SHA-1 (crítico)
$weak = $report | Where-Object {
    $_.SigAlgorithm -match "sha1" -or
    $_.PublicKey -match "RSA" -and $_.KeySize -lt 2048
}
$weak | Format-Table -AutoSize

# 4. Auditar endpoints TLS externos com testssl.sh
# (em Linux, output para CSV)
#   testssl.sh --csv --quiet https://intra.kbase.pt >> tls-audit.csv

Para ambientes Linux/mistos, usar o testssl.sh com a flag --pq (disponível desde 3.2) para verificar suporte a grupos híbridos pós-quânticos:

# Auditoria de todos os endpoints TLS internos (lista em ficheiro)
# testssl.sh --pq --csv --connect-timeout 5 --range-finding \
#   --file endpoints.txt --append tls-audit.csv

# Exemplo de linha para endpoints.txt:
#   intra.kbase.pt:443
#   vpn.kbase.pt:443
#   smtp.kbase.pt:465

# Resumo rápido de suporte PQC
testssl.sh --pq --quiet https://pqc.kbase.pt | grep -iE "mlkem|hybrid|post-quantum"

# Para SSH — usar nmap com script ssh2-enum-algos
nmap --script ssh2-enum-algos -p 22 servidor-pqc.kbase.pt | \
  grep -iE "mlkem|ml-dsa|hybrid"

Algoritmo	Estado	Acção
RSA-1024	Crítico	Substituir imediatamente — quebrável por computadores clássicos
SHA-1 em assinaturas	Crítico	Substituir por SHA-256 ou SHA-3
3DES, RC4	Crítico	Desactivar em TLS/SSH
RSA-2048 / ECDH P-256	Adequado hoje, vulnerável a Shor	Migrar para híbrido PQC até 2030
Ed25519 / ECDH P-384	Adequado	Migrar quando híbrido estiver maduro
AES-256-GCM / ChaCha20-Poly1305	Seguro	Sem acção — resistente a Grover

12. Roadmap de Migração para PME

Uma PME com 50–500 funcionários não precisa de migrar tudo em 2026, mas precisa de um plano. A prioridade deve seguir a sensibilidade dos dados e a vida útil das chaves: PKI raiz e dados de longa duração primeiro; endpoints de cliente por último, porque os browsers e OS actualizarão automaticamente.

Fase	Período	Objectivo	Componentes
1. Descoberta	2026 Q3	Inventariar toda a criptografia	testssl.sh, certutil, nmap, inventário de chaves/HSM
2. Eliminar fraco	2026 Q3–Q4	Remover RSA-1024, SHA-1, 3DES, RC4	TLS, SSH, VPN, PKI
3. PKI raiz PQC	2027 H1	Emitir CA raiz em ML-DSA ou composite	AD CS raiz, HSM
4. TLS híbrido piloto	2027 H2	Activar X25519MLKEM768 em serviços públicos	nginx, IIS, Edge, browsers
5. SSH + VPN	2028	KEX híbrido em servidores e VPN site-to-site	OpenSSH, strongSwan, firewalls
6. Rollout total	2029–2030	Toda a PKI e endpoints em PQC híbrido	Todos os sistemas, deprecar clássico
7. Clássico off	2032+	Remover algoritmos clássicos	Apenas quando 100% compatível

13. Ferramentas Open-Source

O ecossistema open-source de criptografia pós-quântica está maduro o suficiente para produção piloto. As ferramentas principais, todas com licenças permissivas (MIT/Apache):

Ferramenta	Função	URL
liboqs	Biblioteca C de algoritmos PQC (referência NIST)	github.com/open-quantum-safe/liboqs
oqs-provider	Provider OpenSSL 3.x com algoritmos PQC	github.com/open-quantum-safe/oqs-provider
OQS-OpenSSH	Fork do OpenSSH com KEX e host keys PQC	github.com/open-quantum-safe/openssh
strongSwan	IKEv2/IPsec com grupos híbridos ML-KEM	strongswan.org
testssl.sh	Auditoria TLS com flag --pq	github.com/drwetter/testssl.sh
PQClean	Implementações limpas e auditáveis dos algoritmos NIST	github.com/PQClean/PQClean
Cloudflare PQC Toolkit	Bibliotecas e documentação para integrar PQC	github.com/cloudflare/pq-go

Exemplo de instalação rápida do ecossistema OQS em Debian/Ubuntu 2026 para testes de laboratório:

# Instalação completa do ecossistema OQS para laboratório
# Testado em Debian 12 (2026) e Ubuntu 24.04

# 1. Dependências
sudo apt update && sudo apt install -y \
    build-essential cmake git python3-pip ninja-build autoconf libtool \
    libssl-dev pkg-config

# 2. liboqs (referência NIST)
git clone --depth 1 https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local ..
ninja && sudo ninja install
cd ../..

# 3. oqs-provider para OpenSSL 3.x
git clone --depth 1 https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && ./scripts/fullbuild.sh
sudo cp _build/lib/oqsprovider.so /usr/local/lib/ossl-modules/
sudo cp oqsprovider.cnf /usr/local/ssl/openssl.cnf.d/
cd ..

# 4. Verificar — listar algoritmos PQC disponíveis no OpenSSL
OPENSSL_CONF=/usr/local/ssl/openssl.cnf.d/oqsprovider.cnf \
  openssl list -provider oqsprovider -public-key-algorithms | \
  grep -iE "mlkem|ml-dsa|sphincs"

# Output deve incluir: mlkem512, mlkem768, mlkem1024,
#                     ml-dsa-44, ml-dsa-65, ml-dsa-87, sphincs+

# 5. Demo: gerar e verificar assinatura ML-DSA-65
openssl genpkey -algorithm ml-dsa-65 -out mldsa-key.pem
openssl pkey -in mldsa-key.pem -pubout -out mldsa-pub.pem
echo "teste pós-quântico" > mensagem.txt
openssl dgst -sha3-256 -sign mldsa-key.pem -out sig.bin mensagem.txt
openssl dgst -sha3-256 -verify mldsa-pub.pem -signature sig.bin mensagem.txt
# Output: Verified OK

14. Checklist de Migração

• [ ] Inventariar todos os endpoints TLS, SSH e VPN com testssl.sh e nmap
• [ ] Identificar certificados RSA-1024 e assinaturas SHA-1 — substituir imediatamente
• [ ] Mapear todos os usos de criptografia de chave pública (RSA, ECDH, ECDSA, Ed25519)
• [ ] Classificar dados por vida útil: > 5 anos = prioridade alta para HNDL
• [ ] Instalar OpenSSL 3.4+ com oqs-provider em servidor piloto
• [ ] Validar geração de chaves ML-KEM-768 e ML-DSA-65 em laboratório
• [ ] Activar TLS 1.3 em todos os endpoints (pré-requisito do híbrido)
• [ ] Configurar grupo híbrido X25519MLKEM768 num serviço público de baixo risco
• [ ] Testar com clientes reais (Chrome 130+, Firefox 140+, Edge 2026+, curl 8.10+)
• [ ] Planear emissão de CA raiz em ML-DSA ou composite na próxima renovação
• [ ] Configurar AD CS template WebServerPQC em Windows Server 2025
• [ ] Migrar OpenSSH para KEX híbrido mlkem768x25519 em servidores administrados
• [ ] Activar IKEv2 híbrido em strongSwan; reduzir ikelifetime em firewalls comerciais sem PQC
• [ ] Documentar algoritmos suportados por cada cliente (legacy pode bloquear rollout)
• [ ] Definir roadmap interno com datas (descoberta → eliminar fraco → PKI raiz → TLS → SSH/VPN → rollout)
• [ ] Monitorizar NIST e IETF para actualizações (FIPS 206 FN-DSA final, RFCs de composite)
• [ ] Formar equipa de operações sobre diferenças PQC (tamanhos de chave, fragmentação TLS)
• [ ] Reavaliar quarterly o roadmap — o ecossistema evolui rapidamente em 2026–2027

Artigos Relacionados

• Certificados Secure Boot da Microsoft a Expirar em 2026: Guia Completo de Actualização
• Zero Trust para PME em 2026: 5 Pilares Práticos
• HashiCorp Vault: Gestão de Segredos para PME em 2026
• Ransomware 2026: Backup Imutável e Recuperação
• Cloudflare Tunnel + Zero Trust + WARP: Guia 2026

Fontes: NIST FIPS 203/204/205 (csrc.nist.gov); IETF RFC 9370 e drafts LAMPS (datatracker.ietf.org); NSA CNSA 2.0 (media.defense.gov); Microsoft Learn — PQC (learn.microsoft.com); Cloudflare Blog (blog.cloudflare.com); Open Quantum Safe (openquantumsafe.org); OpenSSH release notes (openssh.com); strongSwan (strongswan.org); testssl.sh (github.com/drwetter/testssl.sh).