whitepaper
Whitepaper: Segurança da Informação e Validade Jurídica
Documento técnico completo sobre a arquitetura de segurança, primitivas criptográficas, fluxo de assinatura, proteção de dados pessoais e fundamentação jurídica da plataforma Anaclara.
RSA-SHA256
Lei 14.063/2020
AES-256-GCM
Art. 4º §II
HMAC-SHA256
MP 2.200-2/2001
PAdES / ICP-Brasil
LGPD Art. 7º
SHA-256 Integrity Chain
CPC Art. 369-441
SERPRO Datavalid v4
Assinatura Avançada
RSA-SHA256
Lei 14.063/2020
AES-256-GCM
Art. 4º §II
HMAC-SHA256
MP 2.200-2/2001
PAdES / ICP-Brasil
LGPD Art. 7º
SHA-256 Integrity Chain
CPC Art. 369-441
SERPRO Datavalid v4
Assinatura Avançada
JWT HS256
Não-Repúdio
OTP 7-digit SecureRandom
Marco Civil Art. 15
RSASSA-PKCS1-v1_5
Trilha de Auditoria
PKCS#12 Certificate
Controle Exclusivo
S3 Integrity Check
Identidade Unívoca
Blind Index
Dossiê 15 Seções
JWT HS256
Não-Repúdio
OTP 7-digit SecureRandom
Marco Civil Art. 15
RSASSA-PKCS1-v1_5
Trilha de Auditoria
PKCS#12 Certificate
Controle Exclusivo
S3 Integrity Check
Identidade Unívoca
Blind Index
Dossiê 15 Seções
1. Sumário Executivo
A Anaclara é uma plataforma de assinatura eletrônica que opera via WhatsApp, classificada como assinatura avançada nos termos da Lei 14.063/2020, Art. 4º, §II. Este whitepaper detalha os mecanismos técnicos e jurídicos que sustentam essa classificação.
Principais garantias técnicas:
- Verificação de identidade em tempo real via SERPRO/Datavalid (bases federais RFB e DENATRAN)
- Controle exclusivo do signatário por OTP de 7 dígitos enviado ao WhatsApp
- Cadeia de integridade SHA-256 em cada estágio do documento
- Assinatura digital RSA-SHA256 (RSASSA-PKCS1-v1_5) com chave RSA de 2048 bits
- Assinatura PAdES com certificado ICP-Brasil (atestação de plataforma)
- Criptografia AES-256-GCM de dados pessoais em repouso
- Índices cegos HMAC-SHA256 para buscas sem exposição de dados
- Trilha de auditoria forense com timestamps duais (servidor NTP + Meta webhook)
- Portal de validação pública com re-verificação criptográfica independente
Conformidade legal: MP 2.200-2/2001, Lei 14.063/2020, Lei 13.709/2018 (LGPD), Lei 12.965/2014 (Marco Civil da Internet), Código de Processo Civil.
Principais garantias técnicas:
- Verificação de identidade em tempo real via SERPRO/Datavalid (bases federais RFB e DENATRAN)
- Controle exclusivo do signatário por OTP de 7 dígitos enviado ao WhatsApp
- Cadeia de integridade SHA-256 em cada estágio do documento
- Assinatura digital RSA-SHA256 (RSASSA-PKCS1-v1_5) com chave RSA de 2048 bits
- Assinatura PAdES com certificado ICP-Brasil (atestação de plataforma)
- Criptografia AES-256-GCM de dados pessoais em repouso
- Índices cegos HMAC-SHA256 para buscas sem exposição de dados
- Trilha de auditoria forense com timestamps duais (servidor NTP + Meta webhook)
- Portal de validação pública com re-verificação criptográfica independente
Conformidade legal: MP 2.200-2/2001, Lei 14.063/2020, Lei 13.709/2018 (LGPD), Lei 12.965/2014 (Marco Civil da Internet), Código de Processo Civil.
2. Arquitetura de Segurança
2.1 Primitivas Criptográficas
A plataforma utiliza as seguintes primitivas criptográficas, todas amplamente reconhecidas pela comunidade de segurança e conformes com padrões internacionais (NIST, IETF):
- RSA-SHA256 (RSASSA-PKCS1-v1_5): Assinatura digital do documento. Chave RSA de 2048 bits. Utilizada para vincular criptograficamente o conteúdo do documento à plataforma. A verificação pode ser feita por qualquer parte com acesso à chave pública.
- SHA-256: Função hash criptográfica (família SHA-2) utilizada para calcular digests de integridade em cada estágio do documento. Resistente a colisões e pré-imagens. Computada em streaming com blocos de 4KB para eficiência com arquivos grandes.
- AES-256-GCM: Criptografia simétrica autenticada para proteção de dados pessoais em repouso. O modo GCM (Galois/Counter Mode) fornece simultaneamente confidencialidade e autenticidade, detectando qualquer adulteração nos dados criptografados.
- HMAC-SHA256: Utilizado para gerar índices cegos (blind indexes). Permite buscas determinísticas no banco de dados sem armazenar o valor original em texto claro.
- JWT HS256: Tokens de verificação assinados com HMAC-SHA256 usando a e secret key. Vinculam criptograficamente o código OTP, CPF, nome, hash do documento e timestamp da verificação.
2.2 Cadeia de Integridade Documental
O documento passa por quatro estágios, com um hash SHA-256 calculado em cada um:
1. original_sha256: Hash do documento original no momento do upload
2. footer_sha256: Hash após inserção do rodapé de assinatura com dados do signatário
3. signed_sha256: Hash após aplicação da assinatura digital RSA-SHA256 e do certificado ICP-Brasil PAdES
4. Verificação S3: Na recuperação do documento armazenado, o hash é recalculado e comparado com o signed_sha256 registrado
Qualquer divergência em qualquer estágio invalida o documento e é reportada imediatamente.
2.3 Proteção de Dados Pessoais (PII)
A Anaclara utiliza o Active Record Encryption para criptografar campos sensíveis individualmente:
- Criptografia determinística: Aplicada a campos que precisam ser consultados via busca exata (ex: CPF, telefone). Gera o mesmo ciphertext para o mesmo plaintext, permitindo queries de igualdade. Complementada por blind indexes HMAC-SHA256.
- Criptografia não-determinística: Aplicada a campos que não precisam ser buscados (ex: nome, e-mail). Gera ciphertexts diferentes para o mesmo plaintext em cada operação, oferecendo maior proteção contra ataques de análise de frequência.
Modelos com campos criptografados incluem: Contact (nome, CPF, telefone, e-mail e outros dados sensíveis), SignatureRequest, Organization e outros modelos que armazenam PII.
2.4 Gerenciamento de Chaves
- Par RSA da plataforma: Chave privada RSA de 2048 bits armazenada como variável de ambiente no servidor. Utilizada para assinar documentos. A chave pública é utilizada para verificação no portal de validação.
- Certificado ICP-Brasil PKCS#12: Certificado digital emitido por Autoridade Certificadora credenciada pela ICP-Brasil. Armazenado em formato PKCS#12 protegido por senha. Utilizado para assinatura PAdES embutida no PDF.
- Secret key: Chave mestra do framework utilizada para derivar chaves de criptografia e assinar tokens JWT.
A plataforma utiliza as seguintes primitivas criptográficas, todas amplamente reconhecidas pela comunidade de segurança e conformes com padrões internacionais (NIST, IETF):
- RSA-SHA256 (RSASSA-PKCS1-v1_5): Assinatura digital do documento. Chave RSA de 2048 bits. Utilizada para vincular criptograficamente o conteúdo do documento à plataforma. A verificação pode ser feita por qualquer parte com acesso à chave pública.
- SHA-256: Função hash criptográfica (família SHA-2) utilizada para calcular digests de integridade em cada estágio do documento. Resistente a colisões e pré-imagens. Computada em streaming com blocos de 4KB para eficiência com arquivos grandes.
- AES-256-GCM: Criptografia simétrica autenticada para proteção de dados pessoais em repouso. O modo GCM (Galois/Counter Mode) fornece simultaneamente confidencialidade e autenticidade, detectando qualquer adulteração nos dados criptografados.
- HMAC-SHA256: Utilizado para gerar índices cegos (blind indexes). Permite buscas determinísticas no banco de dados sem armazenar o valor original em texto claro.
- JWT HS256: Tokens de verificação assinados com HMAC-SHA256 usando a e secret key. Vinculam criptograficamente o código OTP, CPF, nome, hash do documento e timestamp da verificação.
2.2 Cadeia de Integridade Documental
O documento passa por quatro estágios, com um hash SHA-256 calculado em cada um:
1. original_sha256: Hash do documento original no momento do upload
2. footer_sha256: Hash após inserção do rodapé de assinatura com dados do signatário
3. signed_sha256: Hash após aplicação da assinatura digital RSA-SHA256 e do certificado ICP-Brasil PAdES
4. Verificação S3: Na recuperação do documento armazenado, o hash é recalculado e comparado com o signed_sha256 registrado
Qualquer divergência em qualquer estágio invalida o documento e é reportada imediatamente.
2.3 Proteção de Dados Pessoais (PII)
A Anaclara utiliza o Active Record Encryption para criptografar campos sensíveis individualmente:
- Criptografia determinística: Aplicada a campos que precisam ser consultados via busca exata (ex: CPF, telefone). Gera o mesmo ciphertext para o mesmo plaintext, permitindo queries de igualdade. Complementada por blind indexes HMAC-SHA256.
- Criptografia não-determinística: Aplicada a campos que não precisam ser buscados (ex: nome, e-mail). Gera ciphertexts diferentes para o mesmo plaintext em cada operação, oferecendo maior proteção contra ataques de análise de frequência.
Modelos com campos criptografados incluem: Contact (nome, CPF, telefone, e-mail e outros dados sensíveis), SignatureRequest, Organization e outros modelos que armazenam PII.
2.4 Gerenciamento de Chaves
- Par RSA da plataforma: Chave privada RSA de 2048 bits armazenada como variável de ambiente no servidor. Utilizada para assinar documentos. A chave pública é utilizada para verificação no portal de validação.
- Certificado ICP-Brasil PKCS#12: Certificado digital emitido por Autoridade Certificadora credenciada pela ICP-Brasil. Armazenado em formato PKCS#12 protegido por senha. Utilizado para assinatura PAdES embutida no PDF.
- Secret key: Chave mestra do framework utilizada para derivar chaves de criptografia e assinar tokens JWT.
3. Fluxo Completo de Assinatura
O processo de assinatura eletrônica da Anaclara compreende 10 etapas, cada uma com registros de auditoria e verificações criptográficas:
Etapa 1 — Upload do documento
O remetente faz upload de um documento PDF. O sistema calcula o hash SHA-256 do arquivo original (original_sha256) e armazena-o como referência de integridade. O upload é registrado no SignatureRequestLog com timestamp do servidor.
Etapa 2 — Verificação de CPF via Datavalid
O CPF do destinatário é verificado em tempo real junto à API Datavalid v4 do SERPRO. A consulta verifica: existência e regularidade do CPF na base da Receita Federal, e correspondência do nome com os registros federais. O resultado é registrado na trilha de auditoria.
Etapa 3 — Criação da SignatureRequest
Um registro de SignatureRequest é criado com todos os dados relevantes: identificação do remetente, dados do destinatário (criptografados com AES-256-GCM), hash original do documento, e status inicial. O PaperTrail registra a criação.
Etapa 4 — Consentimento do remetente
Antes do envio, o remetente confirma explicitamente o consentimento para envio do documento ao destinatário para assinatura. O consentimento é registrado com timestamp, identificação do usuário e contexto, atendendo aos requisitos da LGPD para base legal.
Etapa 5 — Envio do documento ao destinatário
O documento é enviado ao destinatário via WhatsApp Business API (Meta Cloud API). O webhook do Meta confirma a entrega com um timestamp independente (timestamp do Meta), que é registrado junto ao timestamp do servidor, criando a dupla fonte temporal.
Etapa 6 — Visualização pelo destinatário
Quando o destinatário abre/visualiza o documento, o evento é registrado via webhook do Meta (status "read") com timestamp independente. O sistema registra ambos os timestamps (servidor + Meta).
Etapa 7 — Geração e envio do OTP
Quando o destinatário indica intenção de assinar, o sistema gera um código OTP de 7 dígitos usando SecureRandom (fonte criptograficamente segura). O código é enviado via template de autenticação do WhatsApp Business API, junto com a janela de expiração de 60 minutos. O código, seu hash e o timestamp de geração são armazenados no SignatureRequest.
Etapa 8 — Verificação tripla do OTP
O destinatário envia o código recebido. O sistema executa três verificações simultâneas: (1) o código informado corresponde ao código armazenado; (2) o código não expirou (dentro da janela de 60 minutos); (3) o número de telefone de origem corresponde ao número do signatário. As três condições devem ser verdadeiras simultaneamente. Em caso de falha, o sistema bloqueia tentativas adicionais para prevenir ataques de força bruta.
Etapa 9 — Finalização da assinatura
Após verificação bem-sucedida do OTP:
1. Um rodapé de assinatura é inserido no documento com dados do signatário, e o footer_sha256 é calculado
2. O documento é assinado digitalmente com RSA-SHA256 usando a chave privada da plataforma
3. Uma assinatura PAdES é embutida no PDF usando o certificado ICP-Brasil (via HexaPDF)
4. O signed_sha256 é calculado sobre o documento final
5. Um token JWT (HS256) é gerado vinculando: código OTP verificado, CPF, nome, hash do documento e timestamp
6. O documento assinado é armazenado na AWS S3
7. Toda a cadeia de hashes (original → footer → signed) é salva no registro
Etapa 10 — Entrega às partes
O documento assinado é enviado a ambas as partes (remetente e destinatário) via WhatsApp. O dossiê de auditoria é gerado e armazenado. Os webhooks do Meta confirmam a entrega com timestamps independentes.
Etapa 1 — Upload do documento
O remetente faz upload de um documento PDF. O sistema calcula o hash SHA-256 do arquivo original (original_sha256) e armazena-o como referência de integridade. O upload é registrado no SignatureRequestLog com timestamp do servidor.
Etapa 2 — Verificação de CPF via Datavalid
O CPF do destinatário é verificado em tempo real junto à API Datavalid v4 do SERPRO. A consulta verifica: existência e regularidade do CPF na base da Receita Federal, e correspondência do nome com os registros federais. O resultado é registrado na trilha de auditoria.
Etapa 3 — Criação da SignatureRequest
Um registro de SignatureRequest é criado com todos os dados relevantes: identificação do remetente, dados do destinatário (criptografados com AES-256-GCM), hash original do documento, e status inicial. O PaperTrail registra a criação.
Etapa 4 — Consentimento do remetente
Antes do envio, o remetente confirma explicitamente o consentimento para envio do documento ao destinatário para assinatura. O consentimento é registrado com timestamp, identificação do usuário e contexto, atendendo aos requisitos da LGPD para base legal.
Etapa 5 — Envio do documento ao destinatário
O documento é enviado ao destinatário via WhatsApp Business API (Meta Cloud API). O webhook do Meta confirma a entrega com um timestamp independente (timestamp do Meta), que é registrado junto ao timestamp do servidor, criando a dupla fonte temporal.
Etapa 6 — Visualização pelo destinatário
Quando o destinatário abre/visualiza o documento, o evento é registrado via webhook do Meta (status "read") com timestamp independente. O sistema registra ambos os timestamps (servidor + Meta).
Etapa 7 — Geração e envio do OTP
Quando o destinatário indica intenção de assinar, o sistema gera um código OTP de 7 dígitos usando SecureRandom (fonte criptograficamente segura). O código é enviado via template de autenticação do WhatsApp Business API, junto com a janela de expiração de 60 minutos. O código, seu hash e o timestamp de geração são armazenados no SignatureRequest.
Etapa 8 — Verificação tripla do OTP
O destinatário envia o código recebido. O sistema executa três verificações simultâneas: (1) o código informado corresponde ao código armazenado; (2) o código não expirou (dentro da janela de 60 minutos); (3) o número de telefone de origem corresponde ao número do signatário. As três condições devem ser verdadeiras simultaneamente. Em caso de falha, o sistema bloqueia tentativas adicionais para prevenir ataques de força bruta.
Etapa 9 — Finalização da assinatura
Após verificação bem-sucedida do OTP:
1. Um rodapé de assinatura é inserido no documento com dados do signatário, e o footer_sha256 é calculado
2. O documento é assinado digitalmente com RSA-SHA256 usando a chave privada da plataforma
3. Uma assinatura PAdES é embutida no PDF usando o certificado ICP-Brasil (via HexaPDF)
4. O signed_sha256 é calculado sobre o documento final
5. Um token JWT (HS256) é gerado vinculando: código OTP verificado, CPF, nome, hash do documento e timestamp
6. O documento assinado é armazenado na AWS S3
7. Toda a cadeia de hashes (original → footer → signed) é salva no registro
Etapa 10 — Entrega às partes
O documento assinado é enviado a ambas as partes (remetente e destinatário) via WhatsApp. O dossiê de auditoria é gerado e armazenado. Os webhooks do Meta confirmam a entrega com timestamps independentes.
4. Verificação de Identidade
4.1 SERPRO Datavalid API v4
A Anaclara utiliza a API Datavalid v4 do SERPRO (Serviço Federal de Processamento de Dados) para validação de identidade. O Datavalid consulta duas bases de dados federais oficiais:
- Receita Federal do Brasil (RFB): Confirma existência, regularidade e situação cadastral do CPF. Verifica se o nome informado corresponde ao registrado na base da RFB.
- DENATRAN (CNH): Base complementar que pode ser consultada para validação adicional de dados biográficos.
A validação inclui também a verificação algorítmica do CPF (módulo-11), que detecta CPFs com dígitos verificadores inválidos antes mesmo da consulta à API.
4.2 Verificação via WhatsApp (Meta Cloud API)
O número de telefone do signatário é verificado pelo próprio WhatsApp como pré-requisito de uso do serviço. Cada conta WhatsApp exige verificação por SMS ou ligação, vinculando o número a um chip SIM e, portanto, a um dispositivo físico.
A Anaclara trata a normalização de números brasileiros, considerando a transição de 8 para 9 dígitos nos números de celular, garantindo que variações de formato não comprometam a correspondência de identidade.
4.3 Força da identificação combinada
A combinação de dois fatores independentes — CPF (identidade civil federal) e WhatsApp (posse de dispositivo físico) — cria uma identificação que:
- Supera o requisito de associação unívoca da Lei 14.063, Art. 4º, §II, alínea (a)
- Oferece autenticação de dois fatores (algo que o signatário "é" via CPF + algo que o signatário "tem" via dispositivo físico)
- Utiliza bases de dados governamentais oficiais, não apenas dados auto-declarados
A Anaclara utiliza a API Datavalid v4 do SERPRO (Serviço Federal de Processamento de Dados) para validação de identidade. O Datavalid consulta duas bases de dados federais oficiais:
- Receita Federal do Brasil (RFB): Confirma existência, regularidade e situação cadastral do CPF. Verifica se o nome informado corresponde ao registrado na base da RFB.
- DENATRAN (CNH): Base complementar que pode ser consultada para validação adicional de dados biográficos.
A validação inclui também a verificação algorítmica do CPF (módulo-11), que detecta CPFs com dígitos verificadores inválidos antes mesmo da consulta à API.
4.2 Verificação via WhatsApp (Meta Cloud API)
O número de telefone do signatário é verificado pelo próprio WhatsApp como pré-requisito de uso do serviço. Cada conta WhatsApp exige verificação por SMS ou ligação, vinculando o número a um chip SIM e, portanto, a um dispositivo físico.
A Anaclara trata a normalização de números brasileiros, considerando a transição de 8 para 9 dígitos nos números de celular, garantindo que variações de formato não comprometam a correspondência de identidade.
4.3 Força da identificação combinada
A combinação de dois fatores independentes — CPF (identidade civil federal) e WhatsApp (posse de dispositivo físico) — cria uma identificação que:
- Supera o requisito de associação unívoca da Lei 14.063, Art. 4º, §II, alínea (a)
- Oferece autenticação de dois fatores (algo que o signatário "é" via CPF + algo que o signatário "tem" via dispositivo físico)
- Utiliza bases de dados governamentais oficiais, não apenas dados auto-declarados
5. Controle Exclusivo do Signatário
5.1 Geração do OTP
O código OTP (One-Time Password) é um número de 7 dígitos gerado usando
5.2 Entrega via WhatsApp
O OTP é enviado via template de autenticação do WhatsApp Business API. Este tipo de template tem características especiais:
- Entrega garantida apenas ao dispositivo vinculado ao número do destinatário
- Canal criptografado ponta-a-ponta pelo protocolo Signal
- O código é exibido com botão de cópia automática no WhatsApp
- Templates de autenticação são pré-aprovados pelo Meta e não podem ser modificados em tempo de execução
5.3 Verificação tripla
A assinatura só é aceita quando três condições são satisfeitas simultaneamente:
1. Correspondência de código: O código informado pelo signatário deve ser idêntico ao código gerado e armazenado
2. Validade temporal: O código deve estar dentro da janela de 60 minutos desde a geração. Após expiração, um novo código deve ser solicitado
3. Correspondência de telefone: O número de onde a resposta foi enviada deve corresponder ao número do signatário registrado na SignatureRequest
Esta verificação tripla garante que apenas a pessoa correta, com o dispositivo correto, em uma janela temporal limitada, pode autorizar a assinatura.
5.4 Estrutura do JWT de verificação
Após a verificação bem-sucedida, é gerado um token JWT (HS256) com o seguinte payload:
-
-
-
-
-
-
Este token constitui prova criptográfica irrefutável de que o signatário identificado pelo CPF autorizou a assinatura do documento específico naquele momento exato.
O código OTP (One-Time Password) é um número de 7 dígitos gerado usando
SecureRandom.random_number(10**7) do Ruby. O SecureRandom utiliza o gerador de números aleatórios criptográficos do sistema operacional (/dev/urandom no Linux), garantindo imprevisibilidade total. Com 10 milhões de combinações possíveis (0000000 a 9999999) e proteção contra força bruta, a probabilidade de acertar ao acaso em uma única tentativa é de 0,00001%.5.2 Entrega via WhatsApp
O OTP é enviado via template de autenticação do WhatsApp Business API. Este tipo de template tem características especiais:
- Entrega garantida apenas ao dispositivo vinculado ao número do destinatário
- Canal criptografado ponta-a-ponta pelo protocolo Signal
- O código é exibido com botão de cópia automática no WhatsApp
- Templates de autenticação são pré-aprovados pelo Meta e não podem ser modificados em tempo de execução
5.3 Verificação tripla
A assinatura só é aceita quando três condições são satisfeitas simultaneamente:
1. Correspondência de código: O código informado pelo signatário deve ser idêntico ao código gerado e armazenado
2. Validade temporal: O código deve estar dentro da janela de 60 minutos desde a geração. Após expiração, um novo código deve ser solicitado
3. Correspondência de telefone: O número de onde a resposta foi enviada deve corresponder ao número do signatário registrado na SignatureRequest
Esta verificação tripla garante que apenas a pessoa correta, com o dispositivo correto, em uma janela temporal limitada, pode autorizar a assinatura.
5.4 Estrutura do JWT de verificação
Após a verificação bem-sucedida, é gerado um token JWT (HS256) com o seguinte payload:
-
verification_sid: Identificador único da verificação-
code: O código OTP verificado-
cpf: CPF do signatário-
name: Nome do signatário-
document_hash: Hash SHA-256 do documento no momento da verificação-
timestamp: Timestamp exato da verificaçãoEste token constitui prova criptográfica irrefutável de que o signatário identificado pelo CPF autorizou a assinatura do documento específico naquele momento exato.
6. Integridade Documental
6.1 Computação de SHA-256
Os hashes SHA-256 são computados em streaming, processando o arquivo em blocos de 4KB. Isso garante:
- Eficiência de memória: arquivos grandes não são carregados inteiramente na memória
- Consistência: o mesmo algoritmo e tamanho de bloco são utilizados em todas as computações
- O resultado é um digest de 256 bits (32 bytes), representado como string hexadecimal de 64 caracteres
6.2 Assinatura Digital RSA-SHA256
O processo de assinatura digital utiliza o algoritmo RSASSA-PKCS1-v1_5 com SHA-256:
1. O hash SHA-256 do documento é calculado
2. O hash é assinado com a chave privada RSA da plataforma (2048 bits)
3. A assinatura resultante é armazenada junto ao registro da SignatureRequest
Para verificação:
1. O hash SHA-256 do documento é recalculado
2. A assinatura armazenada é verificada usando a chave pública RSA
3. Se o hash calculado corresponde ao hash assinado, a integridade é confirmada
6.3 Assinatura PAdES com ICP-Brasil
Além da assinatura RSA própria, o documento recebe uma assinatura PAdES (PDF Advanced Electronic Signatures) utilizando o certificado ICP-Brasil da Anaclara:
- O certificado é emitido por uma Autoridade Certificadora credenciada pela ICP-Brasil
- Armazenado em formato PKCS#12 (.p12) protegido por senha
- A assinatura é embutida diretamente no PDF usando a biblioteca HexaPDF
- Leitores de PDF como Adobe Acrobat podem verificar a assinatura automaticamente, exibindo os detalhes do certificado
Esta assinatura funciona como atestação de plataforma: a Anaclara, como entidade verificadora, atesta que o processo de verificação de identidade e OTP foi concluído com sucesso.
6.4 Verificação de integridade no S3
Ao recuperar um documento da AWS S3, o sistema recalcula o hash SHA-256 do arquivo e compara com o signed_sha256 armazenado no banco de dados. Se houver divergência, o documento é marcado como comprometido e o acesso é bloqueado. Essa re-verificação ocorre em cada acesso ao documento, garantindo detecção imediata de qualquer adulteração no armazenamento.
Os hashes SHA-256 são computados em streaming, processando o arquivo em blocos de 4KB. Isso garante:
- Eficiência de memória: arquivos grandes não são carregados inteiramente na memória
- Consistência: o mesmo algoritmo e tamanho de bloco são utilizados em todas as computações
- O resultado é um digest de 256 bits (32 bytes), representado como string hexadecimal de 64 caracteres
6.2 Assinatura Digital RSA-SHA256
O processo de assinatura digital utiliza o algoritmo RSASSA-PKCS1-v1_5 com SHA-256:
1. O hash SHA-256 do documento é calculado
2. O hash é assinado com a chave privada RSA da plataforma (2048 bits)
3. A assinatura resultante é armazenada junto ao registro da SignatureRequest
Para verificação:
1. O hash SHA-256 do documento é recalculado
2. A assinatura armazenada é verificada usando a chave pública RSA
3. Se o hash calculado corresponde ao hash assinado, a integridade é confirmada
6.3 Assinatura PAdES com ICP-Brasil
Além da assinatura RSA própria, o documento recebe uma assinatura PAdES (PDF Advanced Electronic Signatures) utilizando o certificado ICP-Brasil da Anaclara:
- O certificado é emitido por uma Autoridade Certificadora credenciada pela ICP-Brasil
- Armazenado em formato PKCS#12 (.p12) protegido por senha
- A assinatura é embutida diretamente no PDF usando a biblioteca HexaPDF
- Leitores de PDF como Adobe Acrobat podem verificar a assinatura automaticamente, exibindo os detalhes do certificado
Esta assinatura funciona como atestação de plataforma: a Anaclara, como entidade verificadora, atesta que o processo de verificação de identidade e OTP foi concluído com sucesso.
6.4 Verificação de integridade no S3
Ao recuperar um documento da AWS S3, o sistema recalcula o hash SHA-256 do arquivo e compara com o signed_sha256 armazenado no banco de dados. Se houver divergência, o documento é marcado como comprometido e o acesso é bloqueado. Essa re-verificação ocorre em cada acesso ao documento, garantindo detecção imediata de qualquer adulteração no armazenamento.
7. Trilha de Auditoria Forense
7.1 SignatureRequestLog
O modelo SignatureRequestLog registra cada evento do processo de assinatura com os seguintes campos:
- step: Identificador do evento (ex: "signature_request_created", "otp_sent", "otp_verified", "document_signed")
- server_timestamp: Timestamp do servidor no momento do registro (sincronizado via NTP)
- meta_timestamp: Timestamp fornecido pelo webhook do Meta/WhatsApp (quando aplicável)
- metadata: Dados adicionais relevantes ao evento (JSON estruturado)
- signature_request_id: Referência ao registro de assinatura
A dupla fonte temporal (servidor + Meta) é fundamental: mesmo que o relógio do servidor seja manipulado, os timestamps do Meta são independentes e podem ser confrontados. Isso cria uma evidência temporal que nenhuma das partes pode adulterar unilateralmente.
7.2 PaperTrail
O PaperTrail mantém um histórico completo de versões de registros críticos. Cada alteração registra:
- O estado anterior do registro (serializado em JSON)
- O usuário responsável pela alteração
- O timestamp da alteração
- O tipo de alteração (criação, atualização, exclusão)
Isso permite reconstruir o estado completo de qualquer registro em qualquer ponto no tempo, fornecendo uma trilha de auditoria imutável.
7.3 Dossiê de Auditoria
Ao final de cada processo de assinatura, é gerado um dossiê de auditoria com 15 seções:
1. Identificação do contrato
2. Dados do remetente
3. Dados do destinatário (signatário)
4. Dados do documento original (nome, tipo, tamanho, hash SHA-256)
5. Registro de consentimento do remetente
6. Cronologia de envio e entrega (com timestamps duais)
7. Cronologia de visualização
8. Registro de geração e envio do OTP
9. Registro de verificação do OTP
10. Cadeia de hashes (original → footer → signed)
11. Dados da assinatura digital RSA
12. Dados do certificado ICP-Brasil
13. Registro de armazenamento S3
14. Token JWT de verificação
15. Hash de integridade do dossiê
A seção 15 é o hash SHA-256 do próprio dossiê (calculado sobre as seções 1 a 14), garantindo que o registro de auditoria em si não foi adulterado após a geração.
O modelo SignatureRequestLog registra cada evento do processo de assinatura com os seguintes campos:
- step: Identificador do evento (ex: "signature_request_created", "otp_sent", "otp_verified", "document_signed")
- server_timestamp: Timestamp do servidor no momento do registro (sincronizado via NTP)
- meta_timestamp: Timestamp fornecido pelo webhook do Meta/WhatsApp (quando aplicável)
- metadata: Dados adicionais relevantes ao evento (JSON estruturado)
- signature_request_id: Referência ao registro de assinatura
A dupla fonte temporal (servidor + Meta) é fundamental: mesmo que o relógio do servidor seja manipulado, os timestamps do Meta são independentes e podem ser confrontados. Isso cria uma evidência temporal que nenhuma das partes pode adulterar unilateralmente.
7.2 PaperTrail
O PaperTrail mantém um histórico completo de versões de registros críticos. Cada alteração registra:
- O estado anterior do registro (serializado em JSON)
- O usuário responsável pela alteração
- O timestamp da alteração
- O tipo de alteração (criação, atualização, exclusão)
Isso permite reconstruir o estado completo de qualquer registro em qualquer ponto no tempo, fornecendo uma trilha de auditoria imutável.
7.3 Dossiê de Auditoria
Ao final de cada processo de assinatura, é gerado um dossiê de auditoria com 15 seções:
1. Identificação do contrato
2. Dados do remetente
3. Dados do destinatário (signatário)
4. Dados do documento original (nome, tipo, tamanho, hash SHA-256)
5. Registro de consentimento do remetente
6. Cronologia de envio e entrega (com timestamps duais)
7. Cronologia de visualização
8. Registro de geração e envio do OTP
9. Registro de verificação do OTP
10. Cadeia de hashes (original → footer → signed)
11. Dados da assinatura digital RSA
12. Dados do certificado ICP-Brasil
13. Registro de armazenamento S3
14. Token JWT de verificação
15. Hash de integridade do dossiê
A seção 15 é o hash SHA-256 do próprio dossiê (calculado sobre as seções 1 a 14), garantindo que o registro de auditoria em si não foi adulterado após a geração.
8. Proteção de Dados Pessoais (LGPD)
8.1 Mapeamento de criptografia por campo
A tabela abaixo detalha quais campos de PII são criptografados e em qual modalidade:
Contact:
- Nome: criptografia não-determinística (AES-256-GCM)
- CPF: criptografia determinística + blind index HMAC-SHA256
- Telefone: criptografia determinística + blind index HMAC-SHA256
- E-mail: criptografia não-determinística (AES-256-GCM)
- Outros campos sensíveis: criptografia não-determinística
SignatureRequest:
- Dados do signatário: criptografados conforme tipo de campo
- Hash do documento: armazenado em texto claro (não é PII)
Organization:
- Dados da organização: campos sensíveis criptografados
8.2 Minimização de dados no portal de validação
O portal de validação pública (validar.anaclara.app) implementa o princípio de minimização de dados da LGPD:
- CPF exibido com máscara: apenas primeiros 3 e últimos 2 dígitos visíveis (ex: 123.***.** -45)
- Telefone exibido com máscara: apenas DDD e últimos 2 dígitos visíveis
- Nome exibido parcialmente
- Nenhum dado pessoal completo é exposto
Isso permite que terceiros confirmem a autenticidade de um documento sem ter acesso a dados pessoais completos dos signatários.
8.3 Base legal para tratamento de dados
O tratamento de dados pessoais pela Anaclara tem as seguintes bases legais (LGPD, Art. 7º):
- Consentimento (Art. 7º, I): O remetente consente explicitamente antes do envio do documento, com registro de timestamp e contexto
- Execução de contrato (Art. 7º, V): O tratamento é necessário para execução do serviço de assinatura eletrônica contratado
- Exercício regular de direitos (Art. 7º, VI): A trilha de auditoria é mantida para exercício regular de direitos em processo judicial ou administrativo
A tabela abaixo detalha quais campos de PII são criptografados e em qual modalidade:
Contact:
- Nome: criptografia não-determinística (AES-256-GCM)
- CPF: criptografia determinística + blind index HMAC-SHA256
- Telefone: criptografia determinística + blind index HMAC-SHA256
- E-mail: criptografia não-determinística (AES-256-GCM)
- Outros campos sensíveis: criptografia não-determinística
SignatureRequest:
- Dados do signatário: criptografados conforme tipo de campo
- Hash do documento: armazenado em texto claro (não é PII)
Organization:
- Dados da organização: campos sensíveis criptografados
8.2 Minimização de dados no portal de validação
O portal de validação pública (validar.anaclara.app) implementa o princípio de minimização de dados da LGPD:
- CPF exibido com máscara: apenas primeiros 3 e últimos 2 dígitos visíveis (ex: 123.***.** -45)
- Telefone exibido com máscara: apenas DDD e últimos 2 dígitos visíveis
- Nome exibido parcialmente
- Nenhum dado pessoal completo é exposto
Isso permite que terceiros confirmem a autenticidade de um documento sem ter acesso a dados pessoais completos dos signatários.
8.3 Base legal para tratamento de dados
O tratamento de dados pessoais pela Anaclara tem as seguintes bases legais (LGPD, Art. 7º):
- Consentimento (Art. 7º, I): O remetente consente explicitamente antes do envio do documento, com registro de timestamp e contexto
- Execução de contrato (Art. 7º, V): O tratamento é necessário para execução do serviço de assinatura eletrônica contratado
- Exercício regular de direitos (Art. 7º, VI): A trilha de auditoria é mantida para exercício regular de direitos em processo judicial ou administrativo
9. Análise Jurídica
9.1 Lei 14.063/2020, Art. 4º, §II — Análise requisito a requisito
Requisito (a): "estar associada ao signatário de maneira unívoca"
Atendido por: verificação de CPF via SERPRO/Datavalid (base federal) + verificação de número de WhatsApp (dispositivo físico). A combinação de documento de identidade civil e posse de dispositivo cria identificação unívoca com dois fatores independentes.
Requisito (b): "utilizar dados para a criação de assinatura eletrônica cujo signatário pode, com elevado nível de confiança, operar sob o seu controle exclusivo"
Atendido por: OTP de 7 dígitos gerado criptograficamente (SecureRandom), enviado exclusivamente ao WhatsApp do signatário via canal criptografado, com verificação tripla (código + expiração + telefone). O controle é exclusivo pois apenas o portador do dispositivo físico pode receber e informar o código.
Requisito (c): "estar relacionada aos dados a ela associados de tal modo que qualquer modificação posterior seja detectável"
Atendido por: cadeia de hashes SHA-256 (original → footer → signed), assinatura digital RSA-SHA256, certificado ICP-Brasil PAdES e re-verificação via S3. Qualquer alteração em um único byte do documento é detectada imediatamente por qualquer uma das quatro camadas de verificação.
9.2 MP 2.200-2/2001
Art. 10, §1º: "As declarações constantes dos documentos em forma eletrônica produzidos com a utilização de processo de certificação disponibilizado pela ICP-Brasil presumem-se verdadeiros em relação aos signatários." A Anaclara utiliza certificado ICP-Brasil para atestação de plataforma, conferindo presunção de veracidade ao documento.
Art. 10, §2º: "O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento." O consentimento explícito registrado no fluxo da Anaclara satisfaz este requisito de aceitação entre as partes.
9.3 CPC — Documentos Eletrônicos como Prova
Art. 369: As partes podem utilizar "todos os meios legais, bem como os moralmente legítimos" para provar fatos. Assinaturas eletrônicas com trilha de auditoria completa são meio legítimo de prova.
Art. 411: O documento eletrônico faz prova quando sua autenticidade não for impugnada. Com cadeia de hashes SHA-256, assinatura RSA, certificado ICP-Brasil e trilha de auditoria forense, a Anaclara fornece elementos robustos para comprovar autenticidade mesmo em caso de impugnação.
Art. 422: Qualquer reprodução mecânica ou eletrônica faz prova dos fatos ou coisas representadas se não houver impugnação fundamentada. Os mecanismos criptográficos da Anaclara tornam extremamente difícil fundamentar uma impugnação válida.
9.4 Comparação com outras plataformas
A Anaclara se diferencia de outras plataformas de assinatura eletrônica por:
- Utilizar bases de dados governamentais oficiais (SERPRO/Datavalid) para verificação de identidade, em vez de depender apenas de dados auto-declarados
- Operar via WhatsApp, o canal de comunicação mais utilizado no Brasil (99% dos smartphones), eliminando a necessidade de instalar aplicativos adicionais ou criar novas contas
- Implementar verificação tripla de OTP (código + expiração + telefone), não apenas verificação simples de código
- Combinar assinatura RSA própria com certificado ICP-Brasil, oferecendo tanto verificação técnica independente quanto reconhecimento institucional
- Fornecer portal de validação pública gratuito para verificação por terceiros
Requisito (a): "estar associada ao signatário de maneira unívoca"
Atendido por: verificação de CPF via SERPRO/Datavalid (base federal) + verificação de número de WhatsApp (dispositivo físico). A combinação de documento de identidade civil e posse de dispositivo cria identificação unívoca com dois fatores independentes.
Requisito (b): "utilizar dados para a criação de assinatura eletrônica cujo signatário pode, com elevado nível de confiança, operar sob o seu controle exclusivo"
Atendido por: OTP de 7 dígitos gerado criptograficamente (SecureRandom), enviado exclusivamente ao WhatsApp do signatário via canal criptografado, com verificação tripla (código + expiração + telefone). O controle é exclusivo pois apenas o portador do dispositivo físico pode receber e informar o código.
Requisito (c): "estar relacionada aos dados a ela associados de tal modo que qualquer modificação posterior seja detectável"
Atendido por: cadeia de hashes SHA-256 (original → footer → signed), assinatura digital RSA-SHA256, certificado ICP-Brasil PAdES e re-verificação via S3. Qualquer alteração em um único byte do documento é detectada imediatamente por qualquer uma das quatro camadas de verificação.
9.2 MP 2.200-2/2001
Art. 10, §1º: "As declarações constantes dos documentos em forma eletrônica produzidos com a utilização de processo de certificação disponibilizado pela ICP-Brasil presumem-se verdadeiros em relação aos signatários." A Anaclara utiliza certificado ICP-Brasil para atestação de plataforma, conferindo presunção de veracidade ao documento.
Art. 10, §2º: "O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento." O consentimento explícito registrado no fluxo da Anaclara satisfaz este requisito de aceitação entre as partes.
9.3 CPC — Documentos Eletrônicos como Prova
Art. 369: As partes podem utilizar "todos os meios legais, bem como os moralmente legítimos" para provar fatos. Assinaturas eletrônicas com trilha de auditoria completa são meio legítimo de prova.
Art. 411: O documento eletrônico faz prova quando sua autenticidade não for impugnada. Com cadeia de hashes SHA-256, assinatura RSA, certificado ICP-Brasil e trilha de auditoria forense, a Anaclara fornece elementos robustos para comprovar autenticidade mesmo em caso de impugnação.
Art. 422: Qualquer reprodução mecânica ou eletrônica faz prova dos fatos ou coisas representadas se não houver impugnação fundamentada. Os mecanismos criptográficos da Anaclara tornam extremamente difícil fundamentar uma impugnação válida.
9.4 Comparação com outras plataformas
A Anaclara se diferencia de outras plataformas de assinatura eletrônica por:
- Utilizar bases de dados governamentais oficiais (SERPRO/Datavalid) para verificação de identidade, em vez de depender apenas de dados auto-declarados
- Operar via WhatsApp, o canal de comunicação mais utilizado no Brasil (99% dos smartphones), eliminando a necessidade de instalar aplicativos adicionais ou criar novas contas
- Implementar verificação tripla de OTP (código + expiração + telefone), não apenas verificação simples de código
- Combinar assinatura RSA própria com certificado ICP-Brasil, oferecendo tanto verificação técnica independente quanto reconhecimento institucional
- Fornecer portal de validação pública gratuito para verificação por terceiros
10. Portal de Validação Pública
O portal validar.anaclara.app permite a verificação independente da autenticidade de qualquer documento assinado pela Anaclara.
Fluxo técnico de verificação:
1. Lookup do contrato: O identificador informado é utilizado para localizar o registro da SignatureRequest no banco de dados
2. Verificação RSA: A assinatura digital RSA-SHA256 armazenada é verificada contra o hash SHA-256 recalculado do documento, utilizando a chave pública da plataforma. Se a verificação falhar, o documento é marcado como inválido.
3. Verificação S3: O documento é baixado da AWS S3 e seu hash SHA-256 é recalculado. O hash calculado é comparado com o signed_sha256 armazenado no banco de dados. Divergências indicam adulteração no armazenamento.
4. Resposta mascarada: Se ambas as verificações forem bem-sucedidas, o portal exibe:
- Status de verificação: "Autêntico" ou "Inválido"
- Nome do signatário (parcialmente mascarado)
- CPF (parcialmente mascarado)
- Telefone (parcialmente mascarado)
- Data e hora da assinatura
- Hash do documento
O portal é público e gratuito — não requer cadastro, login ou qualquer forma de autenticação. Isso permite que terceiros (advogados, juízes, contadores, RH) verifiquem a autenticidade de documentos de forma independente.
Fluxo técnico de verificação:
1. Lookup do contrato: O identificador informado é utilizado para localizar o registro da SignatureRequest no banco de dados
2. Verificação RSA: A assinatura digital RSA-SHA256 armazenada é verificada contra o hash SHA-256 recalculado do documento, utilizando a chave pública da plataforma. Se a verificação falhar, o documento é marcado como inválido.
3. Verificação S3: O documento é baixado da AWS S3 e seu hash SHA-256 é recalculado. O hash calculado é comparado com o signed_sha256 armazenado no banco de dados. Divergências indicam adulteração no armazenamento.
4. Resposta mascarada: Se ambas as verificações forem bem-sucedidas, o portal exibe:
- Status de verificação: "Autêntico" ou "Inválido"
- Nome do signatário (parcialmente mascarado)
- CPF (parcialmente mascarado)
- Telefone (parcialmente mascarado)
- Data e hora da assinatura
- Hash do documento
O portal é público e gratuito — não requer cadastro, login ou qualquer forma de autenticação. Isso permite que terceiros (advogados, juízes, contadores, RH) verifiquem a autenticidade de documentos de forma independente.
11. Glossário Técnico
AES-256-GCM — Advanced Encryption Standard com chave de 256 bits no modo Galois/Counter Mode. Algoritmo de criptografia simétrica autenticada que fornece confidencialidade e integridade simultaneamente.
Blind Index — Índice cego. Valor hash determinístico (HMAC-SHA256) de um dado sensível, utilizado para permitir buscas no banco de dados sem armazenar o valor original em texto claro.
Datavalid — API do SERPRO para validação de dados cadastrais de pessoas físicas e jurídicas contra bases de dados governamentais oficiais (Receita Federal, DENATRAN).
HMAC-SHA256 — Hash-based Message Authentication Code usando SHA-256. Função que combina uma chave secreta com dados para produzir um código de autenticação, garantindo integridade e autenticidade.
ICP-Brasil — Infraestrutura de Chaves Públicas Brasileira. Sistema nacional de certificação digital instituído pela MP 2.200-2/2001, que garante a autenticidade e integridade de documentos e transações eletrônicas.
JWT — JSON Web Token. Padrão aberto (RFC 7519) para criação de tokens de acesso que contêm declarações (claims) assinadas criptograficamente.
OTP — One-Time Password. Código de uso único gerado criptograficamente, válido por tempo limitado, utilizado como fator de autenticação.
PAdES — PDF Advanced Electronic Signatures. Padrão de assinatura eletrônica para documentos PDF definido pelo ETSI (European Telecommunications Standards Institute), que embute a assinatura e o certificado diretamente no arquivo PDF.
PII — Personally Identifiable Information (Informação Pessoal Identificável). Qualquer dado que possa ser utilizado para identificar uma pessoa, como nome, CPF, telefone e e-mail.
PKCS#12 — Public Key Cryptography Standards #12. Formato de arquivo que armazena um certificado digital junto com sua chave privada, protegidos por senha.
PKI — Public Key Infrastructure (Infraestrutura de Chaves Públicas). Sistema que gerencia certificados digitais e criptografia de chave pública, permitindo comunicações seguras e assinaturas digitais.
RSA — Rivest-Shamir-Adleman. Algoritmo de criptografia assimétrica (chave pública/privada) amplamente utilizado para assinaturas digitais e criptografia.
RSASSA-PKCS1-v1_5 — Esquema de assinatura digital RSA definido na RFC 8017. Combina o algoritmo RSA com uma função hash (neste caso, SHA-256) para gerar e verificar assinaturas digitais.
SERPRO — Serviço Federal de Processamento de Dados. Empresa pública vinculada ao Ministério da Fazenda, responsável por soluções de tecnologia para o governo federal brasileiro.
SHA-256 — Secure Hash Algorithm 256-bit. Função hash criptográfica da família SHA-2 que produz um digest de 256 bits (32 bytes). Resistente a colisões e pré-imagens, utilizada para verificação de integridade de dados.
TLS — Transport Layer Security. Protocolo criptográfico que fornece segurança nas comunicações pela internet, garantindo privacidade e integridade dos dados em trânsito.
Blind Index — Índice cego. Valor hash determinístico (HMAC-SHA256) de um dado sensível, utilizado para permitir buscas no banco de dados sem armazenar o valor original em texto claro.
Datavalid — API do SERPRO para validação de dados cadastrais de pessoas físicas e jurídicas contra bases de dados governamentais oficiais (Receita Federal, DENATRAN).
HMAC-SHA256 — Hash-based Message Authentication Code usando SHA-256. Função que combina uma chave secreta com dados para produzir um código de autenticação, garantindo integridade e autenticidade.
ICP-Brasil — Infraestrutura de Chaves Públicas Brasileira. Sistema nacional de certificação digital instituído pela MP 2.200-2/2001, que garante a autenticidade e integridade de documentos e transações eletrônicas.
JWT — JSON Web Token. Padrão aberto (RFC 7519) para criação de tokens de acesso que contêm declarações (claims) assinadas criptograficamente.
OTP — One-Time Password. Código de uso único gerado criptograficamente, válido por tempo limitado, utilizado como fator de autenticação.
PAdES — PDF Advanced Electronic Signatures. Padrão de assinatura eletrônica para documentos PDF definido pelo ETSI (European Telecommunications Standards Institute), que embute a assinatura e o certificado diretamente no arquivo PDF.
PII — Personally Identifiable Information (Informação Pessoal Identificável). Qualquer dado que possa ser utilizado para identificar uma pessoa, como nome, CPF, telefone e e-mail.
PKCS#12 — Public Key Cryptography Standards #12. Formato de arquivo que armazena um certificado digital junto com sua chave privada, protegidos por senha.
PKI — Public Key Infrastructure (Infraestrutura de Chaves Públicas). Sistema que gerencia certificados digitais e criptografia de chave pública, permitindo comunicações seguras e assinaturas digitais.
RSA — Rivest-Shamir-Adleman. Algoritmo de criptografia assimétrica (chave pública/privada) amplamente utilizado para assinaturas digitais e criptografia.
RSASSA-PKCS1-v1_5 — Esquema de assinatura digital RSA definido na RFC 8017. Combina o algoritmo RSA com uma função hash (neste caso, SHA-256) para gerar e verificar assinaturas digitais.
SERPRO — Serviço Federal de Processamento de Dados. Empresa pública vinculada ao Ministério da Fazenda, responsável por soluções de tecnologia para o governo federal brasileiro.
SHA-256 — Secure Hash Algorithm 256-bit. Função hash criptográfica da família SHA-2 que produz um digest de 256 bits (32 bytes). Resistente a colisões e pré-imagens, utilizada para verificação de integridade de dados.
TLS — Transport Layer Security. Protocolo criptográfico que fornece segurança nas comunicações pela internet, garantindo privacidade e integridade dos dados em trânsito.
Saiba Mais
Para uma visão geral da validade jurídica, consulte a página Validade Jurídica.
Verifique a autenticidade de qualquer documento assinado pela Anaclara no Portal de Validação.
Experimente a Anaclara gratuitamente por 7 dias: Começar agora.
Verifique a autenticidade de qualquer documento assinado pela Anaclara no Portal de Validação.
Experimente a Anaclara gratuitamente por 7 dias: Começar agora.
©2026 Anaclara Sistemas Inteligentes LTDA
Política de Privacidade
Termos de Uso
Blog
suporte@anaclara.app
CNPJ: 47.297.488/0001-24
Avenida Queiroz Filho 1560, São Paulo – SP
Avenida Queiroz Filho 1560, São Paulo – SP
