CAdES na Prática: Assinar Qualquer Arquivo com Certificado ICP-Brasil

Nem todo documento é PDF. Planilha de fechamento, arquivo XML de integração, imagem digitalizada, pacote de dados que alimenta outro sistema — tudo isso pode precisar de assinatura com certificado ICP-Brasil, e nada disso cabe no PAdES. O padrão para esses casos é o CAdES, e o arquivo que sai dele costuma ter a extensão .p7s.

CAdES é a sigla de CMS Advanced Electronic Signatures. É uma extensão do CMS — o padrão de contêiner criptográfico que descende do PKCS#7 — criada, nas palavras do DOC-ICP-15 do ITI, "com vistas a prover as assinaturas digitais de informações que permitam sua validação por longo prazo". Na prática, é o formato mais genérico e mais universal dos três padrões adotados pela ICP-Brasil.

Este guia percorre a estrutura do contêiner, a diferença entre assinatura anexada e destacada, os atributos que separam um CMS qualquer de um CAdES, o que só o CAdES consegue fazer e o PDF não, e como o SignDocs Brasil usa esse padrão em dois lugares distintos do produto. Para o panorama comparativo, veja PKCS#7, CMS, PAdES e CAdES; para o PDF, o guia de PAdES.

A base: o que o CMS carrega

Um contêiner CMS do tipo SignedData transporta, em uma estrutura ASN.1 codificada em DER, quatro coisas que interessam:

• Os algoritmos de resumo usados, declarados no topo.
• O conteúdo assinado — opcionalmente, e é aqui que nasce a escolha mais importante do formato.
• Os certificados necessários para montar a cadeia até a raiz.
• Um ou mais blocos de signatário, cada um com seus atributos, o algoritmo usado e a assinatura propriamente dita.

O ITI resume a característica que define o uso: o CMS "não permite assinar partes de um documento, somente o documento como um todo". É granularidade de arquivo inteiro — diferente do XML, que permite assinar apenas uma parte do documento.

Anexada ou destacada: a escolha que define a operação

A inclusão do conteúdo dentro da estrutura CMS é opcional, e o DOC-ICP-15 nomeia as duas representações:

Sobre extensões, o ITI recomenda que os arquivos com assinaturas digitais ICP-Brasil sejam gerados com as extensões p7s, xml e pdf. Na prática do mercado, .p7s designa a assinatura e .p7m costuma designar a mensagem assinada com o conteúdo dentro — uma convenção herdada do S/MIME, não uma imposição do padrão.

O que transforma um CMS em CAdES: os atributos assinados

Atributos assinados entram no cálculo do resumo criptográfico — alterar qualquer um deles invalida a assinatura. Atributos não assinados ficam fora, o que é exatamente o que permite acrescentar informação depois sem quebrar nada. Os que aparecem no dia a dia:

O signingCertificateV2 merece destaque porque resolve um ataque real: sem ele, um contêiner pode ser manipulado para apontar para outro certificado com a mesma chave pública. Com ele, a assinatura declara, de dentro do próprio cálculo, qual certificado a produziu.

Coassinatura e contra-assinatura: o que o PDF não faz

Esta é a vantagem estrutural do CAdES, e o DOC-ICP-15 a descreve com precisão. Para CAdES e XAdES existem três arranjos; para PAdES, apenas dois.

• Assinatura simples — uma assinatura sobre um conteúdo. Existe nos três padrões.
• Coassinatura, também chamada de assinatura paralela — "duas ou mais assinaturas digitais são geradas de forma paralela e independente pelos signatários, utilizando conteúdos digitais idênticos", cada uma com seus próprios atributos. Só CAdES e XAdES.
• Contra-assinatura — a assinatura é feita sobre a sequência de bytes que representa uma assinatura já existente. É o que expressa hierarquia: testemunha, endosso, aprovação de quem assinou. Só CAdES e XAdES.

Em PDF, como vimos no guia de PAdES, os arranjos são assinatura simples e assinatura serial: cada signatário assina o documento inteiro, com as assinaturas anteriores dentro. Não há como dizer, no formato, que a assinatura B é sobre a assinatura A, e não sobre o documento.

Quando o requisito de negócio é literalmente "o gerente referenda a assinatura do analista", a expressão nativa disso é contra-assinatura em CAdES. Em PDF, isso vira convenção de ordem e registro na trilha de auditoria — o que funciona, mas não é a mesma coisa no nível do formato.

CAdES-ICP-Brasil e as políticas de assinatura

O padrão internacional define o que é possível. A ICP-Brasil define o que é aceito. O DOC-ICP-15 é direto: é CAdES-ICP-Brasil toda assinatura no formato CAdES que, além de seguir os requisitos de assinatura digital ICP-Brasil, possui um identificador de política de assinatura pertencente ao conjunto de políticas divulgadas e aprovadas conforme o DOC-ICP-15.03. E a validação, diz o mesmo documento, deve exigir que a assinatura esteja de acordo com uma das políticas aprovadas.

As cinco políticas publicadas pelo ITI, aplicáveis ao CAdES:

• AD-RB — Assinatura digital com Referência Básica.
• AD-RT — Assinatura digital com Referência de Tempo.
• AD-RV — Assinatura digital com Referências para Validação.
• AD-RC — Assinatura digital com Referências Completas.
• AD-RA — Assinatura digital com Referências para Arquivamento.

O ITI descreve ainda a lógica de evolução: uma assinatura pode receber atributos que a levem de um nível ao seguinte, porque a informação acrescentada entra como atributo não assinado e, por definição, não quebra a assinatura original.

Se um edital, contrato ou norma setorial cita uma dessas siglas nominalmente, trate como requisito técnico explícito, confirme o entendimento com o jurídico e leve ao time comercial antes de fechar o desenho da integração.

Onde o SignDocs Brasil usa CAdES

Em dois lugares distintos, com propósitos diferentes — e confundi-los é fonte garantida de mal-entendido.

1. Assinatura de documentos que não são PDF

A API aceita bem mais que PDF: .docx, .doc, .xlsx, .xls, .pptx, .ppt, .odt, .ods, .odp, .rtf, .txt, .csv, .jpg, .jpeg, .png, .tiff, .tif, .bmp, .svg, .xml, .json e .html, com limite de 10 MB. Quando o arquivo enviado não é PDF, o fluxo de assinatura com certificado é o genérico, e o resultado é um .p7s:

1. O SHA-256 é calculado sobre o arquivo inteiro — sem manipulação do documento, sem ByteRange, sem inserir nada dentro dele.
2. Os atributos autenticados são montados com o mesmo conjunto do fluxo PAdES, incluindo o signingCertificateV2.
3. A chave privada do signatário assina o resumo desses atributos — no navegador, com A1, ou no token, com A3, pelo SignDocsBrasil Assinador via PKCS#11.
4. O servidor monta o contêiner CMS com o conteúdo anexado: o arquivo original vai dentro do .p7s.

Em envelope com vários signatários, cada novo signatário tem seu bloco acrescentado ao mesmo contêiner, que ao final carrega todos os blocos sobre o mesmo conteúdo — a estrutura de coassinatura descrita pelo ITI. Concluído o último, uma cópia consolidada é promovida para o escopo do envelope, e é essa que a verificação expõe como download único. Vale registrar: sempre que algum signatário usa certificado digital, o envelope passa a ser sequencial, e os convites saem um a um.

2. O pacote de evidências .p7m

O segundo uso não tem relação com o certificado do signatário. Toda transação gera uma trilha de auditoria, e essa trilha é empacotada em um CMS assinado com o certificado ICP-Brasil A1 da própria SignDocs Brasil — um e-CNPJ. O que isso prova é diferente: não que fulano assinou, mas que o registro do que aconteceu não foi adulterado depois. As duas provas se somam e não se substituem. Detalhes em o pacote de evidências .p7m.

PAdES ou CAdES: como decidir

Validar um .p7s, e o que costuma falhar

Para uma inspeção rápida de estrutura, o OpenSSL resolve:

Para conformidade com o perfil brasileiro, o caminho é o Validador do ITI, que confere a aderência à política e não apenas a matemática. O verificador público abre a trilha de auditoria pelo identificador da evidência, e a verificação programática cobre o caso de PDF.

As falhas mais comuns:

1. Assinatura destacada sem o original. Um .p7s destacado sozinho não verifica nada. Quem gerou precisa entregar o par.
2. O original foi tocado. Reabrir e salvar uma planilha muda bytes. O resumo deixa de bater, mesmo que o conteúdo visível pareça idêntico.
3. Cadeia incompleta. Faltando os certificados intermediários, o validador não chega à raiz. Um contêiner bem montado leva a cadeia dentro.
4. Reserialização do DER. Decodificar, modificar e recodificar os atributos autenticados pode produzir bytes diferentes dos que foram assinados. O sintoma clássico no Validador do ITI é a reprovação da cifra assimétrica em uma assinatura que, do ponto de vista da chave, está correta. É por isso que, no SignDocs Brasil, esses atributos são construídos em DER byte a byte, sem rodada de reserialização.
5. Algoritmo legado. Contêineres antigos com SHA-1 devem ser tratados como obsoletos.

A visão de conjunto dos formatos, dos certificados e dos níveis de assinatura está na Central de Assinatura Digital.

Perguntas Frequentes