PKCS#7, CMS, PAdES e CAdES: Entenda os Padrões de Assinatura Digital

Quando uma empresa decide integrar assinatura digital ao seu fluxo de trabalho via API, uma das primeiras decisões técnicas é escolher o padrão criptográfico adequado. PKCS#7, CMS, PAdES, CAdES — são siglas que aparecem constantemente em documentações técnicas, regulamentações da ICP-Brasil e requisitos de compliance. No entanto, para muitos desenvolvedores e arquitetos de software, a relação entre esses padrões permanece nebulosa.

Este artigo é um mergulho profundo na anatomia dos padrões de assinatura digital. Vamos dissecar a estrutura interna de uma assinatura CMS, comparar sistematicamente os níveis de CAdES e PAdES, e mostrar como uma API moderna de assinatura abstrai toda essa complexidade sem sacrificar a conformidade. Se você é responsável por integrações que exigem validade jurídica no Brasil, este guia técnico vai esclarecer exatamente o que acontece "debaixo do capô" quando um documento é assinado digitalmente.

Compreender esses padrões não é mero exercício acadêmico. A escolha incorreta pode resultar em assinaturas que perdem validade com o tempo, documentos rejeitados em processos judiciais ou incompatibilidade com sistemas governamentais. Ao final deste artigo, você terá o conhecimento técnico para tomar decisões informadas sobre qual padrão adotar e como implementá-lo corretamente.

Fundamentos: Criptografia Assimétrica e Pares de Chaves

Antes de mergulhar nos padrões, é essencial revisitar os fundamentos criptográficos que sustentam todas as assinaturas digitais. Se você já domina RSA e ECDSA, sinta-se à vontade para avançar para a próxima seção. Para os demais, esta base conceitual é indispensável.

Par de Chaves: Pública e Privada

A assinatura digital fundamenta-se na criptografia assimétrica, que utiliza um par de chaves matematicamente relacionadas. A chave privada é mantida em sigilo absoluto pelo signatário (armazenada em token, smartcard ou HSM) e é utilizada para gerar a assinatura. A chave pública, distribuída livremente por meio de certificados digitais, permite que qualquer pessoa verifique a autenticidade da assinatura sem jamais ter acesso à chave privada.

RSA vs. ECDSA

Os dois algoritmos mais utilizados em assinaturas digitais são:

• RSA (Rivest-Shamir-Adleman): O algoritmo mais estabelecido, baseado na dificuldade de fatoração de números primos grandes. Chaves de 2048 ou 4096 bits são o padrão atual. A ICP-Brasil exige no mínimo RSA 2048 bits para certificados emitidos a partir de 2012.
• ECDSA (Elliptic Curve Digital Signature Algorithm): Baseado em curvas elípticas, oferece segurança equivalente ao RSA com chaves significativamente menores. Uma chave ECDSA de 256 bits proporciona segurança comparável a uma chave RSA de 3072 bits, resultando em assinaturas menores e processamento mais rápido.

O Processo de Assinatura em Alto Nível

Independentemente do algoritmo, o fluxo básico de assinatura segue três etapas: (1) um hash criptográfico (SHA-256 ou SHA-512) é calculado sobre o conteúdo a ser assinado; (2) esse hash é cifrado com a chave privada do signatário, gerando a assinatura digital; (3) a assinatura, junto com o certificado do signatário e metadados, é empacotada em uma estrutura padronizada. É exatamente essa "estrutura padronizada" que os padrões PKCS#7, CMS, CAdES e PAdES definem.

PKCS#7/CMS: A Base de Tudo

O PKCS#7 (Public-Key Cryptography Standards #7) foi originalmente definido pela RSA Laboratories em 1993 e formalizado na RFC 2315. Em 1999, a IETF evoluiu essa especificação para o CMS (Cryptographic Message Syntax), atualmente definido na RFC 5652. Embora os termos sejam frequentemente usados como sinônimos, CMS é tecnicamente o padrão vigente e inclui extensões que o PKCS#7 original não possuía.

O CMS define seis tipos de conteúdo criptográfico, mas para assinaturas digitais o mais relevante é o SignedData. Esta estrutura é a base sobre a qual tanto CAdES quanto PAdES são construídos. Entender sua anatomia ASN.1 é fundamental para compreender os padrões derivados.

Estrutura ASN.1 do SignedData

A estrutura SignedData é codificada em ASN.1 (Abstract Syntax Notation One) usando as regras DER (Distinguished Encoding Rules). Abaixo está a definição simplificada:

Componentes-chave do SignedData

Cada campo da estrutura SignedData desempenha um papel específico:

• digestAlgorithms: Lista os algoritmos de hash utilizados por todos os signatários. Permite ao verificador saber quais algoritmos precisará suportar antes de processar cada SignerInfo.
• encapContentInfo: Contém o documento original (assinatura attached/envelopada) ou apenas o OID do tipo de conteúdo (assinatura detached/destacada). Em assinaturas destacadas, o documento viaja separadamente.
• certificates: Campo opcional, mas na prática sempre presente. Inclui o certificado do signatário e, idealmente, toda a cadeia até a AC Raiz da ICP-Brasil. Isso permite verificação offline sem depender de downloads de certificados intermediários.
• signerInfos: O coração da assinatura. Cada SignerInfo representa uma assinatura individual, permitindo múltiplos signatários em um único contêiner CMS.

Signed Attributes vs. Unsigned Attributes

A distinção entre atributos assinados e não assinados é crucial e frequentemente mal compreendida:

• Signed Attributes (signedAttrs): São incluídos no cálculo do hash que será assinado. Qualquer modificação nestes atributos invalida a assinatura. Incluem o message-digest (hash do documento), o content-type e o signing-time.
• Unsigned Attributes (unsignedAttrs): Podem ser adicionados após a assinatura sem invalidá-la. O exemplo mais importante é o carimbo do tempo (signature-time-stamp), que é emitido por uma Autoridade de Carimbo do Tempo (ACT) e adicionado como atributo não assinado. Isso faz sentido porque o carimbo precisa ser gerado sobre a assinatura já pronta.

CAdES: Níveis de Assinatura Explicados

O CAdES (CMS Advanced Electronic Signatures), definido pela ETSI na norma EN 319 122, estende o CMS com atributos adicionais que aumentam progressivamente a confiabilidade e longevidade da assinatura. É o padrão utilizado para assinar qualquer tipo de arquivo — não apenas PDFs — e gera arquivos com extensão .p7s (assinatura destacada) ou .p7m (assinatura envelopada).

Os níveis CAdES formam uma hierarquia cumulativa: cada nível superior incorpora todos os requisitos do nível anterior, adicionando novas garantias.

CAdES-BES (Basic Electronic Signature)

O nível básico. Inclui a assinatura CMS com o certificado do signatário e os atributos assinados obrigatórios. Equivale ao perfil AD-RB (Assinatura Digital com Referência Básica) da ICP-Brasil. Garante autenticidade e integridade, mas não comprova quando a assinatura foi realizada de forma confiável.

CAdES-T (Timestamp)

Adiciona um carimbo do tempo emitido por uma Autoridade de Carimbo do Tempo (ACT) confiável. O carimbo é incluído como unsigned attribute no SignerInfo. Equivale ao perfil AD-RT (Assinatura Digital com Referência de Tempo) da ICP-Brasil. Comprova criptograficamente o momento da assinatura, essencial para contratos com prazos e documentos regulatórios.

CAdES-C (Complete)

Incorpora referências completas a todos os certificados da cadeia de certificação e dados de revogação (CRLs ou respostas OCSP) necessários para validar a assinatura. Não inclui os dados em si, apenas as referências (hashes e URIs). Equivale ao perfil AD-RV (Assinatura Digital com Referências para Validação).

CAdES-X (Extended)

Existem duas variantes: CAdES-X Type 1 (carimbo do tempo sobre as referências) e CAdES-X Type 2 (carimbo do tempo sobre os certificados e dados de revogação completos). Ambas adicionam proteção temporal às referências de validação, impedindo que um comprometimento futuro de algoritmos afete a verificabilidade. Equivale ao perfil AD-RC (Assinatura Digital com Referências Completas).

CAdES-A (Archival)

O nível máximo de longevidade. Inclui todos os dados de validação efetivos (não apenas referências) e aplica um carimbo do tempo de arquivamento sobre toda a estrutura. O carimbo de arquivamento pode ser renovado periodicamente, permitindo que a assinatura sobreviva à obsolescência de algoritmos criptográficos. Equivale ao perfil AD-RA (Assinatura Digital com Referências para Arquivamento) da ICP-Brasil.

Tabela Comparativa: Níveis CAdES

PAdES: Assinatura Digital Nativa em PDF

O PAdES (PDF Advanced Electronic Signatures), definido pela ETSI na norma EN 319 142, é o padrão específico para assinaturas digitais embutidas em documentos PDF. Diferentemente do CAdES, que gera um arquivo de assinatura separado, o PAdES integra a assinatura diretamente na estrutura do PDF, utilizando o mecanismo de incremental update do formato.

Essa integração nativa significa que o PDF assinado com PAdES pode ser aberto e verificado diretamente no Adobe Acrobat Reader, sem necessidade de ferramentas externas. A assinatura aparece no painel de assinaturas do leitor, com indicação visual de validade — um diferencial significativo para a experiência do usuário final.

PAdES-BES (Basic Electronic Signature)

O nível básico de PAdES. A assinatura CMS é embutida em um campo de assinatura (signature field) do PDF, dentro de um dicionário /ByteRange e /Contents. Inclui o certificado do signatário e os atributos assinados obrigatórios. Corresponde ao perfil AD-RB da ICP-Brasil quando aplicado a PDFs.

PAdES-T (Timestamp)

Adiciona um carimbo do tempo de assinatura embutido no PDF. O carimbo pode ser incluído como um atributo não assinado dentro do CMS embutido, ou como um document timestamp separado. Corresponde ao perfil AD-RT.

PAdES-LTV (Long-Term Validation)

O nível mais robusto de PAdES. Incorpora no próprio PDF todos os dados necessários para validação de longo prazo: a cadeia completa de certificados, respostas OCSP atuais, CRLs e um document security store (DSS). Um carimbo do tempo de documento adicional sela todos esses dados. O resultado é um PDF autocontido que pode ser verificado décadas após a assinatura, mesmo que os servidores OCSP originais já não existam. Corresponde aos perfis AD-RA da ICP-Brasil.

Tabela Comparativa: Níveis PAdES

PAdES vs. CAdES: Matriz de Decisão

A escolha entre PAdES e CAdES depende do contexto técnico e dos requisitos do seu projeto. Ambos os padrões são igualmente válidos do ponto de vista jurídico sob a ICP-Brasil, mas cada um tem vantagens específicas.

Recomendações Práticas

Escolha PAdES quando:

• Seus documentos são predominantemente PDF (contratos, propostas, laudos).
• Os destinatários finais precisam verificar a assinatura sem ferramentas técnicas.
• Você precisa de representação visual da assinatura no documento.
• O documento será armazenado e transmitido como um único arquivo.

Escolha CAdES quando:

• Você precisa assinar formatos variados (XML, JSON, binários, lotes de arquivos).
• O documento original não deve ser modificado (requisito de integridade estrita).
• A assinatura precisa viajar separadamente do documento (arquitetura de microserviços).
• Integração com sistemas governamentais que exigem especificamente CAdES (ex.: NF-e).

Evidence Packs (.p7m): CMS Além da Assinatura

Os Evidence Packs representam uma evolução do conceito de assinatura CMS para o domínio da prova jurídica digital. Enquanto um arquivo .p7s tradicional contém apenas a assinatura criptográfica, um Evidence Pack no formato .p7m encapsula um conjunto completo de evidências em um único contêiner CMS verificável.

Anatomia de um Evidence Pack

Um Evidence Pack típico gerado por uma plataforma moderna de assinatura contém:

• Documento original: O arquivo que foi assinado, embutido no encapContentInfo do SignedData.
• Assinatura(s) digital(is): Uma ou mais estruturas SignerInfo com os certificados dos signatários.
• Carimbo de hora do servidor: Registro de tempo ISO-8601 gerado pelos próprios servidores da SignDocs (início e conclusão da assinatura), vinculado à trilha de auditoria. Não se trata de um carimbo de tempo de uma ACT (RFC 3161) — esse recurso não é gerado atualmente pela API.
• Trilha de auditoria: Metadados de auditoria — endereço IP, geolocalização, user-agent do navegador, método de autenticação utilizado.
• Cadeia de certificados: Para assinaturas com certificado ICP-Brasil, a cadeia de certificados do signatário é incluída no momento da assinatura.
• Hash de integridade: Resumo criptográfico SHA-256 do documento que vincula a evidência ao contêiner.

Esta abordagem é particularmente valiosa em cenários judiciais. Enquanto uma assinatura CAdES-BES simples prova apenas quem assinou e que o documento não foi alterado, um Evidence Pack prova também quando, onde, como e em que contexto a assinatura foi realizada. Para saber mais sobre a força probatória desse formato, consulte nosso artigo sobre Evidence Packs como prova jurídica.

Implementando Padrões via API: Complexidade Zero

A implementação direta de CAdES ou PAdES exige bibliotecas criptográficas robustas (como Bouncy Castle, OpenSSL ou iText), conhecimento profundo de ASN.1 e gerenciamento cuidadoso de certificados e timestamps. Para a maioria das empresas, esse investimento em engenharia é desnecessário e arriscado — um único byte errado na codificação DER invalida toda a assinatura.

Uma API moderna de assinatura digital resolve isso ao expor operações de alto nível que encapsulam toda a complexidade dos padrões. Após autenticar-se via OAuth 2.0, uma única chamada REST produz uma assinatura em conformidade total com o padrão escolhido.

Exemplo: Gerando uma Assinatura via API

O exemplo abaixo demonstra como solicitar uma assinatura no nível baseline (assinatura CMS + certificado + carimbo de hora do servidor + trilha de auditoria) usando a API REST da SignDocs. Os níveis com carimbo de tempo de uma ACT (B-T em diante) e LTV não são gerados atualmente pela API:

Observe que em nenhum momento o desenvolvedor precisou manipular estruturas ASN.1 ou gerar hashes manualmente. A API realiza automaticamente, no nível baseline:

1. Construção da estrutura CMS SignedData com os atributos assinados obrigatórios.
2. Embutimento da assinatura CMS no campo de assinatura do PDF.
3. Registro do carimbo de hora do servidor (ISO-8601) de início e conclusão da assinatura.
4. Inclusão da cadeia de certificados ICP-Brasil para assinaturas com certificado.
5. Geração do Evidence Pack em formato CMS (.p7m) com trilha de auditoria completa (IP, geolocalização, user-agent, método de autenticação) e o hash SHA-256 do documento.

Os níveis com carimbo de tempo de uma ACT (PAdES-B-T/CAdES-T em diante) e LTV — que exigem a coleta de respostas OCSP/CRL e a construção de um Document Security Store (DSS) selado por um carimbo de documento — não são gerados atualmente pela API.

Verificação Programática

A API também expõe um endpoint de detecção de assinaturas embutidas: você envia um PDF e recebe de volta se ele carrega assinaturas digitais (PAdES/CMS) e quais os seus tipos. Para verificar o conjunto completo de evidências de uma assinatura feita na plataforma, use a verificação pública por evidenceId:

Perguntas Frequentes (FAQ)

1. Qual a diferença entre PKCS#7 e CMS?

PKCS#7 foi a especificação original criada pela RSA Laboratories (RFC 2315). O CMS (Cryptographic Message Syntax) é a evolução padronizada pela IETF (RFC 5652). Na prática, CMS é um superconjunto do PKCS#7 com melhorias como suporte a algoritmos mais modernos e extensões de atributos. Os termos são frequentemente usados de forma intercambiável, mas tecnicamente CMS é o padrão atual e deve ser referenciado em implementações novas.

2. PAdES ou CAdES: qual padrão devo usar na minha aplicação?

Se seus documentos são exclusivamente PDF e precisam de verificação visual integrada ao documento, escolha PAdES. Se você precisa assinar qualquer tipo de arquivo (XML, binários, imagens), ou se precisa de assinaturas destacadas (detached), escolha CAdES. Para conformidade com ICP-Brasil em documentos PDF, ambos são aceitos, mas PAdES oferece melhor experiência de verificação no Adobe Reader. A SignDocs aplica os dois padrões automaticamente conforme o tipo de arquivo: PAdES para PDFs e CAdES para os demais formatos.

3. O que é o nível LTV em PAdES e por que é importante?

LTV (Long-Term Validation) é o nível mais alto de PAdES. Ele embute no PDF todas as informações necessárias para validação futura: certificados completos da cadeia, respostas OCSP, CRLs e carimbos do tempo. Isso garante que a assinatura possa ser verificada mesmo décadas depois, independentemente da disponibilidade dos servidores de validação originais. Para documentos que precisam manter validade jurídica por longos períodos — como escrituras, contratos de longo prazo e documentos fiscais — PAdES-LTV é essencial.

4. Como a ICP-Brasil se relaciona com CAdES e PAdES?

A ICP-Brasil define perfis próprios baseados nos padrões europeus da ETSI. O mapeamento é: AD-RB equivale a CAdES-BES/PAdES-BES, AD-RT a CAdES-T/PAdES-T, AD-RV a CAdES-C, AD-RC a CAdES-X, e AD-RA a CAdES-A/PAdES-LTV. O documento normativo DOC-ICP-15 regulamenta essas políticas de assinatura digital, e implementações que seguem esses perfis possuem validade jurídica plena no Brasil, conforme a Medida Provisória 2.200-2/2001.

5. Posso implementar PAdES-LTV sem conhecer a estrutura ASN.1 interna?

Sim. APIs modernas de assinatura digital, como a da SignDocs, abstraem a complexidade criptográfica. Você envia o documento e os parâmetros desejados via REST API, e a plataforma cuida da construção da estrutura CMS, do empacotamento da assinatura e da geração do Evidence Pack. A SignDocs emite atualmente o nível baseline (equivalente a PAdES-B/CAdES-B: assinatura + certificado + carimbo de hora do servidor + trilha de auditoria); os níveis com carimbo de tempo de uma ACT (B-T em diante) e LTV não são gerados atualmente pela API. Não é necessário manipular ASN.1, DER ou certificados X.509 diretamente na sua aplicação.

6. O que é um Evidence Pack (.p7m) e como se relaciona com CMS?

Um Evidence Pack é um contêiner no formato CMS SignedData (.p7m) que encapsula não apenas a assinatura criptográfica, mas também metadados de auditoria: endereço IP do signatário, geolocalização, user-agent, e logs de autenticação. É a evolução do simples .p7s, reunindo provas jurídicas completas em um único arquivo verificável. A estrutura interna segue rigorosamente o padrão CMS, garantindo interoperabilidade com qualquer ferramenta de verificação compatível.

7. CAdES-A e PAdES-LTV garantem validade por quanto tempo?

Teoricamente, por tempo indefinido. CAdES-A (Archival) e PAdES-LTV incorporam mecanismos de re-carimbo do tempo (archive timestamp) que permitem renovar a proteção criptográfica antes que os algoritmos utilizados se tornem obsoletos. Na prática, a ICP-Brasil recomenda que assinaturas de longo prazo (AD-RA) sejam re-carimbadas periodicamente — por exemplo, quando um algoritmo de hash é deprecado — garantindo validade contínua por décadas.