Lacuna TSA

O Lacuna TSA é um servidor de carimbo de tempo (Time Stamping Authority, TSA). Você envia o hash de um dado e recebe um carimbo de tempo (time-stamp token): uma estrutura assinada pela TSA que prova que o dado existia em uma data e hora. É o carimbo de tempo que permite validar uma assinatura digital depois que o certificado do signatário expira.

A Lacuna Software oferece o Lacuna TSA como serviço em nuvem (SaaS), e você também pode ter uma instância na sua própria infraestrutura (on-premises).

Padrões suportados

Padrões internacionais

Padrão	Como o Lacuna TSA o utiliza
RFC 3161, Time-Stamp Protocol (TSP)	Formatos da requisição (TimeStampReq) e da resposta (TimeStampResp), enviadas por HTTP com os content types application/timestamp-query e application/timestamp-response
RFC 5652, Cryptographic Message Syntax (CMS)	O carimbo é um SignedData CMS cujo conteúdo é a estrutura TSTInfo (tipo de conteúdo id-ct-TSTInfo)
RFC 5816, ESSCertIDv2 para a RFC 3161	O carimbo identifica o certificado da TSA com o atributo signing-certificate-v2 (RFC 5035), com hash SHA-256
RFC 5755, certificados de atributo	Formato do certificado de atributo opcional incluído em todo carimbo, como o alvará da ICP-Brasil (veja abaixo)

Os carimbos são emitidos sob a política de TSA da Lacuna Software, OID 1.3.6.1.4.1.46332.4.1 (OIDs da Lacuna Software), a menos que você configure outra política na sua instância, como a atribuída à sua autoridade de carimbo de tempo.

ICP-Brasil

Na ICP-Brasil, os carimbos de tempo — "carimbos do tempo", no vocabulário da ICP-Brasil — são emitidos por Autoridades de Carimbo do Tempo (ACTs) credenciadas, em Servidores de Carimbo do Tempo (SCTs) conectados à Rede de Carimbo do Tempo da ICP-Brasil. Só são aceitos na ICP-Brasil carimbos emitidos por SCT com alvará fornecido por um Sistema de Auditoria e Sincronismo (SAS). As regras estão nestes documentos:

Documento	O que define	No Lacuna TSA
DOC-ICP-11, visão geral do sistema de carimbo do tempo	Os participantes: ACT, SCT, a Entidade de Auditoria do Tempo (EAT), seus SASs e a Fonte Confiável do Tempo (FCT). Requisições e respostas seguem a RFC 3161	RFC 3161 via HTTP
DOC-ICP-12, requisitos mínimos para as declarações de práticas das ACTs	O perfil do carimbo (item 7.2): ordering falso ou ausente, uma precisão declarada, tratamento de nonce e reqPolicy e o alvará vigente. O certificado do SCT tem o uso estendido de chave id-kp-timeStamping	ordering falso, precisão (accuracy) de 1 segundo, nonce copiado da requisição, reqPolicy comparado com Tsa:PolicyId, alvará lido de Tsa:Tac
DOC-ICP-12.01, perfil do alvará do carimbo do tempo	O alvará é um certificado de atributo (RFC 5755) assinado pelo SAS	O alvará configurado em Tsa:Tac vai em todo carimbo, no atributo assinado signer-attributes
DOC-ICP-13, requisitos mínimos para as políticas de carimbo do tempo	Cada política de carimbo do tempo (PCT) da ACT recebe um OID 2.16.76.1.6.n no credenciamento	Configure o OID da PCT em Tsa:PolicyId

O formato do carimbo é só uma parte. Para emitir carimbos do tempo ICP-Brasil, a ACT que opera o servidor precisa ser credenciada pela AC Raiz, o certificado do SCT precisa ser um certificado ICP-Brasil, a chave do SCT precisa ser gerada e guardada em um módulo de segurança criptográfico (MSC), e o relógio do SCT precisa ser sincronizado e auditado por um SAS, que só emite o alvará enquanto o relógio estiver dentro da precisão declarada na política. No Lacuna TSA, a chave pode ficar no Amplia, que suporta HSMs (configure KeyStore:Type como Amplia).

Como um carimbo do tempo ICP-Brasil é emitido

O diagrama abaixo mostra o Lacuna TSA operando como SCT de uma ACT credenciada: a sincronização com a Rede de Carimbo do Tempo, que acontece continuamente, e a emissão de um carimbo, do pedido à verificação.

0. Continuamente, a EAT mantém a escala de tempo da FCT rastreável à UTC e, pelos SASs, sincroniza e audita o relógio do SCT. Enquanto o relógio estiver dentro da precisão, o SAS emite o alvará do SCT, que a ACT informa ao Lacuna TSA na configuração Tsa:Tac.
1. Sua aplicação calcula o hash do documento, por exemplo com SHA-256. Só o hash é enviado: a TSA nunca vê o documento.
2. Sua aplicação envia uma requisição de carimbo do tempo (TSQ, um TimeStampReq) em um POST HTTP para a raiz do servidor (/), com o header Content-Type: application/timestamp-query. A requisição pode indicar, em reqPolicy, o OID da PCT. Se houver autenticação configurada, a requisição também leva o header Authorization (Basic ou Bearer). As rotas antigas /timestamp e /timestamper aceitam a mesma requisição.
3. O Lacuna TSA valida a requisição: o content type, as credenciais, a codificação, a política pedida e o hash. Se algo falhar, responde sem carimbo (veja as falhas).
4. Monta o TSTInfo, com os campos abaixo: o OID da PCT, o hash, um número de série, o genTime em UTC, a precisão, ordering falso e o nonce.
5. Assina o TSTInfo com a chave do SCT, cujo certificado ICP-Brasil tem o uso estendido de chave id-kp-timeStamping.
6. Inclui o alvará nos atributos assinados do carimbo.
7. Devolve a resposta (TSR, um TimeStampResp) com o status granted e o carimbo, com o header Content-Type: application/timestamp-response.
8. Sua aplicação verifica o carimbo: o hash e o nonce são os que ela enviou, a assinatura é válida, a cadeia do certificado do SCT chega à AC Raiz da ICP-Brasil e o alvará era válido no genTime. Depois guarda o carimbo, ou o inclui na assinatura que ele carimba.

Fora da ICP-Brasil o fluxo é o mesmo, sem o SAS e sem o alvará: o Lacuna TSA obtém a hora dos servidores NTP da seção Ntp ou do relógio do sistema (veja Configuração de sincronização com NTP), e o carimbo segue a política padrão ou a configurada em Tsa:PolicyId.

O que o carimbo contém

Campo do TSTInfo	Valor
version	1
policy	Tsa:PolicyId; por padrão, 1.3.6.1.4.1.46332.4.1
messageImprint	Copiado da requisição: o algoritmo de hash e o hash. Vale qualquer algoritmo que o cliente escolher, como SHA-256 ou SHA-512
serialNumber	Um número aleatório de 128 bits, único para cada carimbo
genTime	A hora da emissão, em UTC, com frações de segundo
accuracy	1 segundo
ordering	false
nonce	Copiado da requisição, quando presente
tsa	O nome do titular (subject) do certificado da TSA
extensions	Nenhuma

O TSTInfo é assinado como um SignedData CMS, com SHA-256. Os atributos assinados são content-type, message-digest e signing-certificate-v2, além de signer-attributes quando há um certificado de atributo em Tsa:Tac. Não há o atributo signing-time: a hora é o genTime. O SignedData sempre inclui o certificado da TSA, mas não o restante da cadeia.

Como solicitar um carimbo de tempo

As bibliotecas de assinatura em geral montam a requisição e leem a resposta por você: basta informar o endereço da TSA. Para testar um servidor manualmente, use o OpenSSL e o curl:

openssl ts -query -data documento.pdf -sha256 -cert -out requisicao.tsq

curl -H "Content-Type: application/timestamp-query" --data-binary @requisicao.tsq -o resposta.tsr https://endereco-da-sua-tsa/

openssl ts -reply -in resposta.tsr -text

Se a instância exigir autenticação, acrescente -u USUARIO:SENHA (Basic) ou -H "Authorization: Bearer SEU_TOKEN" ao comando do curl.

Falhas

Situação	Resposta
O content type não é application/timestamp-query	HTTP 400. Para aceitar outros content types, defina Tsa:CheckRequestType como False
Credenciais ausentes ou erradas, ou usuário desativado	TimeStampResp com status rejection e failInfo notAuthorized
A requisição não pode ser decodificada	TimeStampResp sem carimbo, com failInfo badRequest
reqPolicy diferente de Tsa:PolicyId	TimeStampResp sem carimbo, com failInfo unacceptedPolicy
A requisição não traz o hash (messageImprint)	TimeStampResp sem carimbo, com failInfo badMessageCheck
O carimbo não pôde ser assinado	TimeStampResp sem carimbo, com failInfo systemFailure

Desde a versão 1.2.1, uma requisição cujo reqPolicy não seja o valor de Tsa:PolicyId é recusada. Se os seus clientes enviam reqPolicy, configure Tsa:PolicyId, mesmo que com o OID padrão 1.3.6.1.4.1.46332.4.1, para que as requisições correspondam.

Configurações

Estas configurações definem os carimbos emitidos. O formato é o mesmo das configurações de autenticação e de NTP: seções no arquivo .conf ou variáveis de ambiente como Tsa__PolicyId.

Configuração	Descrição
Tsa:PolicyId	OID da política dos carimbos. Padrão: 1.3.6.1.4.1.46332.4.1
Tsa:Tac	Certificado de atributo incluído em todo carimbo, em Base64, como o alvará da ICP-Brasil. Padrão: nenhum
Tsa:CheckRequestType	Defina como False para aceitar requisições sem o content type application/timestamp-query. Padrão: True
KeyStore:Type	Onde fica a chave da TSA: Pkcs12 ou Amplia
KeyStore:Pkcs12Content, KeyStore:Pkcs12Password	Com Pkcs12: o arquivo PKCS #12, em Base64, e a senha dele
KeyStore:KeyId, KeyStore:CertificateId	Com Amplia: o ID da chave e o do certificado da TSA no Amplia
KeyStore:Certificate	Com Amplia, quando o certificado da TSA não foi emitido pela mesma assinatura do Amplia que guarda a chave: o certificado, em Base64
Amplia:Endpoint, Amplia:ApiKey	Com Amplia: o endereço da instância do Amplia e a chave de API de uma aplicação com o papel Gerente (Manager)

Exemplo (arquivo .conf) para um SCT da ICP-Brasil com a chave no Amplia:

[Tsa]
PolicyId=2.16.76.1.6.n
Tac=BASE64_DO_ALVARA

[KeyStore]
Type=Amplia
KeyId=00000000-0000-0000-0000-000000000000
CertificateId=00000000-0000-0000-0000-000000000000

[Amplia]
Endpoint=https://endereco-do-seu-amplia/
ApiKey=SUA_CHAVE_DE_API

Veja também

• Lacuna TSA on premises
• Configuração de sincronização com NTP
• Configuração de autenticação
• OIDs da Lacuna Software
• Histórico de versões