#!/intro
A utilização segura de criptografia depende não só dos algoritmos escolhidos, mas também da forma como os dados criptográficos, como chaves, certificados e assinaturas, são representados, armazenados e transferidos.
O OpenSSL suporta diversos formatos criptográficos, cada um com estrutura própria, suporte a diferentes tipos de conteúdo, mecanismos de proteção distintos e níveis variados de compatibilidade com outras ferramentas e normas. Essas diferenças afetam diretamente a segurança e a interoperabilidade dos sistemas onde são aplicados.
A escolha do formato adequado tem impacto direto em operações como autenticação, assinatura digital, troca de chaves e estabelecimento de canais cifrados. Uma decisão inadequada pode comprometer a confidencialidade dos dados, dificultar a integração entre sistemas ou inviabilizar a conformidade com requisitos legais e normativos.
Compreender os formatos criptográficos suportados pelo OpenSSL, seus contextos de utilização, limitações e vantagens é parte essencial de uma abordagem informada e segura à gestão de ativos criptográficos.
> PEM
PEM (Privacy-Enhanced Mail) não é um formato de chave no sentido estrutural, mas sim uma codificação de dados criptográficos baseada em texto.
Utiliza codificação Base64 sobre estruturas ASN.1, encapsuladas entre delimitadores específicos, como
-----BEGIN PRIVATE KEY----- ou -----BEGIN CERTIFICATE-----.
Originalmente desenvolvido para transportar mensagens seguras por email, acabou por ser amplamente adotado como representação externa para chaves, certificados e outros dados criptográficos. A sua principal vantagem reside na portabilidade: por ser texto puro, pode ser facilmente transmitido por canais que não suportam binário, como email, HTTP ou sistemas de ficheiros restritivos.
PEM pode encapsular estruturas de diversos standards, como PKCS#1, PKCS#8, X.509 ou SEC#1. O delimitador de cabeçalho identifica o tipo de conteúdo, enquanto o corpo contém a representação codificada em Base64 da estrutura binária original.
Devido à sua ubiquidade e simplicidade, o formato PEM continua a ser a escolha dominante para exportação, troca e armazenamento de dados criptográficos em ambientes baseados em OpenSSL.
> DER
DER (Distinguished Encoding Rules) é uma codificação binária de estruturas ASN.1 utilizada para representar dados criptográficos de forma compacta e inequívoca. Ao contrário do formato PEM, que é textual, o DER produz uma representação binária exata e não ambígua dos mesmos conteúdos.
O DER é frequentemente utilizado para armazenar certificados X.509, chaves públicas, chaves privadas e estruturas como PKCS#1, PKCS#8 e certificados em PKCS#7. Os ficheiros codificados em DER não contêm delimitadores ou cabeçalhos, e são tipicamente identificados por extensões como .der, .crt, .cer ou .key, dependendo do conteúdo e da convenção adotada.
Esta codificação é a preferida em ambientes onde o tamanho do ficheiro, a velocidade de leitura ou a interoperabilidade com dispositivos restritos são fatores relevantes. É também o formato utilizado internamente em muitas bibliotecas e protocolos para operações criptográficas.
Por ser binário, o conteúdo DER não pode ser lido nem editado manualmente requerendo ferramentas especializadas para visualização ou análise. O formato é particularmente adequado para distribuição de certificados ou integração com dispositivos que exigem estruturas binárias padronizadas, como smartcards, HSMs ou tokens criptográficos.
> PKCS#1
O formato PKCS#1 define a estrutura de representação de chaves RSA, tanto públicas como privadas. Desenvolvido pela RSA Laboratories, é um dos standards mais antigos da família Public-Key Cryptography Standards (PKCS), sendo aplicável exclusivamente ao algoritmo RSA.
As chaves PKCS#1 são codificadas em ASN.1 e geralmente representadas em formato PEM, com os cabeçalhos -----BEGIN RSA PRIVATE KEY----- ou -----BEGIN RSA PUBLIC KEY-----. No caso das chaves privadas, o conteúdo inclui diretamente os parâmetros fundamentais da chave RSA: módulo, expoente público, expoente privado, primos e coeficiente CRT.
Uma limitação significativa deste formato é a ausência de mecanismos internos de cifra ou verificação de integridade. A proteção por palavra-passe, quando utilizada, é feita fora da especificação, através de uma camada externa PEM com parâmetros ad-hoc. Esta abordagem é considerada frágil, especialmente quando comparada com standards mais recentes que integram essas funcionalidades de forma estruturada.
Apesar das suas limitações em termos de flexibilidade e proteção nativa, o PKCS#1 continua amplamente utilizado devido à sua simplicidade e compatibilidade com bibliotecas e sistemas que operam exclusivamente com RSA.
> SEC#1
O formato SEC#1 define a estrutura de representação de chaves baseadas em curvas elípticas (Elliptic Curve, EC). É especificado pelo Standards for Efficient Cryptography Group (SECG) e estabelece as normas para a codificação de chaves públicas e privadas EC, bem como para os parâmetros associados às curvas.
As chaves SEC#1 são codificadas em ASN.1 e frequentemente representadas em formato PEM, com o cabeçalho -----BEGIN EC PRIVATE KEY-----.
No caso das chaves privadas, a estrutura inclui o valor da chave privada, a curva utilizada e, opcionalmente, a chave pública correspondente.
Tal como o PKCS#1, o SEC#1 não define mecanismos internos de cifra ou proteção por palavra-passe. Quando aplicável, a cifra é realizada externamente, utilizando um encapsulamento PEM com parâmetros não padronizados, o que representa uma fragilidade em contextos com requisitos de segurança elevados.
Este formato é limitado ao suporte de curvas elípticas e não é adequado para outros algoritmos assimétricos. No entanto, é amplamente utilizado devido à crescente adoção da criptografia de curva elíptica em ambientes onde a eficiência e o desempenho são críticos, como sistemas móveis, aplicações embebidas ou dispositivos com restrições de recursos.
> PKCS#7
O formato PKCS#7, padronizado como RFC 2315, foi concebido para encapsular dados assinados ou cifrados, como parte de operações de assinatura digital, cifragem de mensagens e distribuição de certificados.
Ao contrário dos restantes formatos abordados, o PKCS#7 não é utilizado para armazenar chaves privadas. A sua principal função é transportar certificados e respetivas cadeias de certificação, bem como mensagens criptográficas estruturadas segundo a sintaxe CMS (Cryptographic Message Syntax), da qual é precursor.
Em OpenSSL, o PKCS#7 é frequentemente utilizado para agrupar múltiplos certificados num único ficheiro, com extensão .p7b ou .p7c, podendo ser codificado em DER ou PEM. Os cabeçalhos típicos incluem -----BEGIN PKCS7-----.
Este formato é especialmente útil em contextos de distribuição de confiança, como a entrega de cadeias de certificação por autoridades certificadoras, ou em protocolos como S/MIME e TLS, para transportar conjuntos de certificados.
Por não conter chaves privadas nem suportar cifra com proteção por palavra-passe, o PKCS#7 não deve ser utilizado para armazenamento de materiais sensíveis. A sua função é puramente transitória ou estrutural, servindo como contentor seguro e interoperável para dados criptográficos processados ou certificados públicos.
> PKCS#8
O formato PKCS#8 foi concebido para representar chaves privadas de forma padronizada, flexível e independente do algoritmo utilizado. Define uma estrutura que encapsula não apenas o valor da chave, mas também os identificadores do algoritmo e os respetivos parâmetros, permitindo a utilização com RSA, DSA, EC, entre outros.
As chaves PKCS#8 são codificadas em ASN.1 e podem ser representadas em PEM com os cabeçalhos -----BEGIN PRIVATE KEY----- para chaves não cifradas, ou -----BEGIN ENCRYPTED PRIVATE KEY----- quando protegidas por palavra-passe.
Ao contrário dos formatos mais antigos, o PKCS#8 suporta cifra nativa através de mecanismos padronizados como PBES2 e PBKDF2, com algoritmos robustos como AES para proteção dos dados e HMAC-SHA2 para verificação de integridade. Esta abordagem garante uma proteção estruturada e parametrizável, em conformidade com boas práticas de segurança.
Além da proteção integrada, o PKCS#8 facilita a interoperabilidade entre sistemas e bibliotecas, funcionando como formato intermediário para conversão entre representações específicas como PKCS#1 ou SEC#1.
A sua utilização é recomendada sempre que se pretenda armazenar ou transportar chaves privadas com mecanismos de proteção modernos, assegurando simultaneamente compatibilidade e robustez criptográfica.
> PKCS#12
O formato PKCS#12, também identificado pelas extensões .p12 ou .pfx, foi desenvolvido para agrupar num único ficheiro chaves privadas, certificados e as respetivas cadeias de certificação. É um formato binário estruturado com base em ASN.1, concebido para portabilidade e proteção criptográfica integrada.
Ao contrário de formatos como PKCS#1 ou SEC 1, o PKCS#12 inclui suporte nativo tanto para cifra como para verificação de integridade. Utiliza algoritmos como AES ou 3DES para cifrar chaves privadas, combinados com funções de derivação como PBKDF2 para proteção por palavra-passe. A integridade pode ser verificada através de HMAC-SHA1 ou SHA-2, consoante a implementação e as opções definidas aquando da criação do ficheiro.
O formato permite aplicar proteção tanto ao nível da estrutura global como de cada entrada individual, oferecendo um elevado grau de controlo e granularidade sobre os mecanismos de acesso. Esta característica torna-o particularmente adequado para exportar credenciais completas, por exemplo em operações de aprovisionamento de servidores ou em integrações que exijam a importação de chaves e certificados num único ficheiro.
Desde a versão 9 do Java, o PKCS#12 tornou-se o formato predefinido de keystore, substituindo o JKS, precisamente pela sua robustez e interoperabilidade alargada.
Apesar das suas vantagens, o PKCS#12 apresenta uma estrutura complexa, e nem todas as ferramentas suportam o mesmo conjunto de algoritmos ou parâmetros. É essencial garantir que os ambientes envolvidos são compatíveis com as opções de cifra, dispersão criptográfica e codificação utilizadas, para evitar falhas de interoperabilidade.
O PKCS#12 continua a ser uma opção sólida para ambientes que exigem proteção criptográfica estruturada, portabilidade de credenciais e compatibilidade entre plataformas heterogéneas.
> conclusão
Os diferentes formatos de chave suportados pelo OpenSSL refletem a diversidade de requisitos técnicos, históricos e operacionais que surgem na gestão de ativos criptográficos.
Formatos como PKCS#1 e SEC#1, apesar de simples e amplamente suportados, carecem de mecanismos internos de proteção, devendo ser utilizados com precaução e preferencialmente encapsulados em estruturas mais robustas. O PKCS#7, por sua vez, não serve para armazenar chaves, mas desempenha um papel importante na distribuição de certificados e no encapsulamento de dados criptográficos.
PKCS#8 representa uma evolução natural para a gestão segura de chaves privadas, permitindo proteção nativa com algoritmos modernos e interoperabilidade entre algoritmos assimétricos. Já o PKCS#12 oferece uma solução abrangente para o transporte de credenciais completas, com suporte para cifra, integridade e múltiplos objetos criptográficos num único ficheiro.
A escolha do formato adequado deve ser feita com base no tipo de chave, no contexto de utilização, nos requisitos de segurança e nas necessidades de interoperabilidade. Ignorar estas diferenças pode comprometer a proteção dos dados, dificultar a integração de sistemas ou impedir a conformidade com normas e regulamentos relevantes.
Compreender as características técnicas e as limitações de cada formato é essencial para assegurar uma gestão eficaz, segura e duradoura dos materiais criptográficos num ecossistema baseado em OpenSSL.
> status: sealed
> exit 0