Como verificar um PDF assinado — e ler o veredito

Um PDF PAdES traz consigo o certificado do signatário, o resumo dos bytes assinados e — a partir do B-T — um token temporal RFC 3161. Qualquer validador que entenda PAdES refaz esses factos a partir do próprio ficheiro: o painel de assinaturas do Adobe Reader, o validador de código aberto DSS da Comissão Europeia, ou uma simples chamada OpenSSL. A verificação pública dos nossos pacotes de evidência não exige conta.

O validador não acredita em ninguém por palavra. Volta a verificar os bytes, confere a cadeia de certificados e confere o imprint do token temporal — operações aritméticas, não uma opinião.

Conteúdo primeiro: o resumo corresponde aos bytes desta cópia? Qualquer edição depois da assinatura parte esta verificação — o hash recalculado e o hash assinado discordam. É, na prática, a propriedade do artigo 26.º, alínea d), do eIDAS: qualquer alteração posterior aos dados é detetável.

Identidade depois: o certificado dentro da assinatura identifica o signatário e encadeia numa infraestrutura de certificação em que já confia. Uma cadeia que não valida não significa que a assinatura tenha sido forjada — significa que o validador não encontrou caminho de confiança do certificado até uma raiz que conheça.

Hora por último: o genTime do token vem do relógio da autoridade, em UTC — não do portátil do signatário. O PDF também traz uma hora de assinatura declarada, do relógio do próprio signatário; se as duas divergirem de forma relevante, a fonte credível é a da autoridade.

Um veredito positivo afirma os três factos acima: estes bytes são os bytes assinados, o signatário é uma identidade certificada, e a assinatura existia no mais tardar na hora indicada. Não afirma nada do contexto humano — o validador não sabe se o signatário leu ou aceitou os termos. Por isso a evidência da cerimónia (o registo de auditoria) é sempre apresentada ao lado da criptografia, e não no lugar dela.

Certificados expiram, e as respostas de revogação (OCSP/CRL) que permitem conferir o estado da cadeia são servidas por sistemas que não respondem para sempre. Um ficheiro B-T prova muito no dia em que é assinado; anos mais tarde, a ferramenta pode não conseguir reconstituir a cadeia completa — não porque a prova enfraqueceu, mas porque parte dos dados de apoio deixa de estar acessível.

A resposta conhecida ao problema conhecido é esta: o B-LT embute no próprio PDF o material de validação — a cadeia e a informação de revogação —, de modo que a prova de que se precisa no momento da verificação viaja com o documento. Se a prova tem de sobreviver ao prazo dos certificados que a produziram, peça a B-LT à plataforma do signatário antes de ser necessária; o nosso guia sobre B-T, B-LT e B-LTA tem os pormenores.

O lado das verificações temporais está definido na RFC 3161 — o imprint da resposta tem de coincidir com o do pedido, o token tem de trazer um número de série único junto dessa autoridade e a hora tem de estar em UTC. Os algoritmos e o perfil de validação estão na ETSI EN 319 102-1 e na EN 319 142-1 — citadas por nome, não reproduzidas, por serem normas ETSI pagas.

Uma última verificação que qualquer pessoa faz a olho nu: a assinatura cobre o documento inteiro. Uma página, um carimbo ou uma caixa de texto acrescentados depois da assinatura desalinharam a faixa de bytes cobertos — todas as ferramentas acima dirão isso.