Documentos técnicos

Este whitepaper descreve a arquitetura do sistema Transferência Segura do PDF Pro, um mecanismo de transferência de ficheiros encriptado de ponta a ponta no qual os ficheiros são encriptados do lado do cliente com AES-256-GCM antes do envio. O servidor armazena apenas texto cifrado opaco e não tem capacidade para desencriptar, inspecionar ou ler o conteúdo dos ficheiros em qualquer momento. O sistema suporta dois modos de chave: uma chave aleatória gerada automaticamente (transportada no fragmento do URL, que nunca é enviado ao servidor) ou uma chave derivada de uma frase-passe usando PBKDF2. Em ambos os modos, a chave de encriptação existe apenas no navegador do remetente e do destinatário. Este documento detalha as primitivas criptográficas, o fluxo de dados, o modelo de ameaças e as limitações honestas do sistema. Nota sobre a terminologia: este sistema não utiliza provas de conhecimento zero (ZKPs). Quando dizemos que o servidor tem "conhecimento zero" dos seus ficheiros, queremos dizer que — como consequência da encriptação do lado do cliente — o servidor apenas detém texto cifrado que não consegue desencriptar.

O sistema Transferência Segura segue uma separação rigorosa entre cliente e servidor, na qual todas as operações criptográficas ocorrem exclusivamente no navegador:

• Cliente (Navegador): Derivação de chave, encriptação, desencriptação, leitura de ficheiros, reconstrução de ficheiros.
• Servidor (Supabase Storage + Funções Serverless): Armazena blobs encriptados, gere metadados (expiração, contagem de transferências), aplica políticas de acesso.

O servidor é intencionalmente concebido como um "tubo opaco" para dados encriptados. Não tem conhecimento da chave de encriptação, da frase-passe ou do conteúdo dos ficheiros. Isto é imposto arquitetonicamente, não meramente por política.

Toda a encriptação de ficheiros utiliza o algoritmo de encriptação autenticada AES-256-GCM, acedido através da Web Crypto API nativa do navegador. Isto fornece tanto confidencialidade (os dados não podem ser lidos) como integridade (os dados não podem ser modificados sem deteção).

1.3.1 Parâmetros do Algoritmo

1.3.2 Implementação da Encriptação

// Fluxo de encriptação simplificado (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Derivar chave a partir da frase-passe (ver Secção 1.4)
const key = await deriveKey(passphrase, salt);

// Encriptar o ficheiro
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Pacote: [salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

O blob encriptado final é uma concatenação de três componentes: o salt de 16 bytes (utilizado para derivação de chave), o IV de 12 bytes (utilizado para AES-GCM) e o texto cifrado com o tag de autenticação GCM de 16 bytes anexado. Este blob é o que o servidor recebe e armazena.

A Transferência Segura suporta dois modos de chave mutuamente exclusivos. O modo é selecionado pelo remetente no momento da criação da transferência.

1.4.1 Modo A — Chave Gerada Automaticamente (Predefinição)

No modo predefinido, não é envolvida qualquer frase-passe. O navegador gera diretamente uma chave AES de 256 bits criptograficamente aleatória:

• O navegador gera uma chave AES-GCM de 256 bits aleatória através de crypto.getRandomValues() e crypto.subtle.generateKey().
• A chave é exportada como bytes em bruto e colocada no fragmento do URL (#).
• De acordo com a especificação HTTP, o fragmento do URL nunca é enviado ao servidor — é processado exclusivamente pelo navegador.
• O remetente partilha o URL completo (incluindo o fragmento) com o destinatário através do canal preferido (por exemplo, aplicação de mensagens, e-mail).
• O navegador do destinatário extrai a chave do fragmento do URL e utiliza-a para desencriptar o ficheiro.

1.4.2 Modo B — Transferência Protegida por Frase-Passe

Quando o remetente opta por definir uma frase-passe, a chave é derivada dessa frase-passe utilizando PBKDF2:

• O utilizador fornece uma frase-passe.
• A frase-passe é utilizada para derivar uma chave AES-256 através de PBKDF2-SHA256.
• Parâmetros: 600 000 iterações, salt aleatório de 16 bytes.
• A chave derivada encripta o ficheiro.
• O salt é armazenado juntamente com o texto cifrado (anteposto ao blob encriptado).
• A frase-passe é partilhada fora da banda (separadamente do link).
• Não é possível recuperar a frase-passe — nem o servidor nem o PDF Pro conseguem recuperar uma frase-passe esquecida.

1.4.3 Parâmetros PBKDF2 (Modo B)

1.4.4 Implementação da Derivação de Chave (Modo B)

async function deriveKey(passphrase, salt) {
  // Importar frase-passe como material de chave em bruto
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Derivar chave AES-256-GCM
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

O ciclo de vida completo de uma transferência segura segue este percurso:

1.5.1 Envio (Upload) — Modo A (Chave Gerada Automaticamente)

1. O remetente seleciona um ficheiro no navegador.
2. O navegador gera uma chave AES-GCM de 256 bits aleatória e um IV de 12 bytes aleatório utilizando crypto.getRandomValues().
3. O navegador encripta o ficheiro utilizando AES-256-GCM, produzindo texto cifrado + tag de autenticação.
4. O navegador concatena [IV | ciphertext+tag] num único blob.
5. O navegador envia o blob encriptado para o servidor através de HTTPS.
6. O servidor armazena o blob no Supabase Storage e cria um registo de metadados (ID da transferência, expiração, limite de transferências, nome do ficheiro, tamanho do ficheiro).
7. O servidor devolve um URL de transferência. O navegador anexa a chave exportada ao fragmento do URL (#).
8. O remetente partilha o URL completo (com fragmento) com o destinatário.

1.5.2 Envio (Upload) — Modo B (Frase-Passe)

1. O remetente seleciona um ficheiro e introduz uma frase-passe no navegador.
2. O navegador gera um salt aleatório de 16 bytes e um IV de 12 bytes utilizando crypto.getRandomValues().
3. O navegador deriva uma chave AES-256 a partir da frase-passe utilizando PBKDF2 (600 mil iterações).
4. O navegador encripta o ficheiro utilizando AES-256-GCM, produzindo texto cifrado + tag de autenticação.
5. O navegador concatena [salt | IV | ciphertext+tag] num único blob.
6. O navegador envia o blob encriptado para o servidor através de HTTPS.
7. O servidor armazena o blob no Supabase Storage e cria um registo de metadados (ID da transferência, expiração, limite de transferências, nome do ficheiro, tamanho do ficheiro).
8. O servidor devolve um URL de transferência contendo o ID da transferência.
9. O remetente partilha o URL de transferência e a frase-passe com o destinatário através de canais separados.

1.5.3 Receção (Download) — Modo A

1. O destinatário abre o URL de transferência completo (com a chave no fragmento).
2. O navegador extrai a chave AES do fragmento do URL (nunca enviado ao servidor).
3. O navegador descarrega o blob encriptado do servidor através de HTTPS.
4. O navegador extrai o IV (primeiros 12 bytes) do blob.
5. O navegador desencripta o texto cifrado utilizando AES-256-GCM com a chave e o IV extraídos.
6. Se a desencriptação for bem-sucedida (o tag GCM valida), o ficheiro em texto simples é apresentado ao utilizador.
7. O servidor atualiza o contador de transferências e, se a opção "queimar após leitura" estiver ativa, elimina o blob.

1.5.4 Receção (Download) — Modo B

1. O destinatário abre o URL de transferência e introduz a frase-passe no navegador.
2. O navegador descarrega o blob encriptado do servidor através de HTTPS.
3. O navegador extrai o salt (primeiros 16 bytes) e o IV (12 bytes seguintes) do blob.
4. O navegador deriva a chave AES-256 a partir da frase-passe + salt utilizando PBKDF2 (600 mil iterações).
5. O navegador desencripta o texto cifrado utilizando AES-256-GCM com a chave derivada e o IV.
6. Se a desencriptação for bem-sucedida (o tag GCM valida), o ficheiro em texto simples é apresentado ao utilizador.
7. Se a desencriptação falhar (frase-passe errada = chave errada = tag GCM inválido), é apresentado um erro.
8. O servidor atualiza o contador de transferências e, se a opção "queimar após leitura" estiver ativa, elimina o blob.

Todas as transferências seguras são efémeras por design. Não existe opção de armazenamento permanente.

1.7.1 Opções de Expiração

1.7.2 Garantia de Eliminação

Quando uma transferência expira ou é queimada após leitura, o blob encriptado é eliminado permanentemente do Supabase Storage. O registo de metadados é mantido durante 30 dias num estado de eliminação suave (para investigação de abuso) antes de ser purgado permanentemente. O registo de metadados não contém a chave de encriptação, a frase-passe ou qualquer informação que possa ser utilizada para reconstruir o ficheiro.

1.8.1 Pressupostos

• Tempo de execução do navegador é fiável (sem extensões maliciosas)
• Canal seguro para partilha de link/frase-passe
• A terminação HTTPS é fiável
• O dispositivo do destinatário não está comprometido
• Sem prevenção de captura de ecrã

1.8.2 Fora do Âmbito

• Malware em dispositivos de extremidade
• Ataques de engenharia social / phishing
• Captura de ecrã pelos destinatários
• Extensões de navegador comprometidas
• Ataques de computação quântica (consideração futura)

• A robustez da frase-passe é controlada pelo utilizador. Podemos aplicar um comprimento mínimo na interface, mas não conseguimos impedir os utilizadores de escolherem frases-passe fracas. A segurança da encriptação é diretamente proporcional à entropia da frase-passe.
• A transmissão da frase-passe é fora da banda. Não fornecemos um canal seguro para partilhar a frase-passe. Se a frase-passe for partilhada por um canal inseguro (por exemplo, e-mail não encriptado juntamente com o URL de transferência), o modelo de segurança fica enfraquecido.
• Os metadados do ficheiro não são encriptados. O nome de ficheiro original e o tamanho do ficheiro são armazenados em texto simples no servidor. Isto revela o tipo e a natureza aproximada do ficheiro transferido, mesmo que o seu conteúdo permaneça encriptado.
• Confiança no código do lado do cliente. Os utilizadores devem confiar que o JavaScript servido pelo nosso CDN é o código correto e não modificado. Um CDN comprometido ou um sequestro de DNS poderia servir JavaScript malicioso. Esta é uma limitação fundamental de toda a criptografia baseada na Web.
• Sem confidencialidade futura. Se a frase-passe for comprometida em qualquer ponto antes da eliminação do blob encriptado, uma cópia armazenada do blob pode ser desencriptada. As opções "queimar após leitura" e tempos de expiração curtos mitigam isto.
• Dependência do modelo de segurança do navegador. A segurança do sistema depende da implementação da Web Crypto API pelo navegador e do seu isolamento de memória. Um navegador comprometido ou uma extensão maliciosa pode subverter todas as proteções do lado do cliente.
• Computação quântica. O AES-256 é considerado resistente a ataques quânticos (o algoritmo de Grover reduz a segurança efetiva para 128 bits, o que continua a ser inviável). No entanto, o PBKDF2 com SHA-256 não é especificamente projetado para resistência pós-quântica. Esta não é uma preocupação a curto prazo, mas é referida por uma questão de completude.

Este whitepaper descreve a arquitetura do sistema Assinatura Privada do PDF Pro, um mecanismo criptográfico de assinatura de documentos no qual o documento PDF nunca sai do navegador do signatário. O sistema utiliza ECDSA com a curva P-256 e hash SHA-256 para produzir assinaturas digitais separadas. Apenas o hash do documento, a assinatura criptográfica e a chave pública são transmitidos ao servidor. As chaves privadas são geradas, encriptadas e armazenadas exclusivamente no navegador do utilizador através de IndexedDB, protegidas por derivação de chave PBKDF2 (600 000 iterações) e encriptação AES-256-GCM. Este documento detalha a arquitetura completa de assinatura e verificação, o modelo de gestão de chaves, o esquema do payload assinado, o design do registo de auditoria, o modelo de ameaças e as limitações honestas.

O sistema Assinatura Privada foi concebido em torno de uma restrição fundamental: o documento PDF nunca pode ser transmitido ao servidor. Isto é imposto arquitetonicamente através de um modelo de assinatura separada.

• Cliente (Navegador): Geração de chaves, armazenamento de chaves (encriptadas em IndexedDB), hash de documentos (SHA-256), geração de assinaturas (ECDSA P-256), verificação de assinaturas.
• Servidor (Supabase): Armazena chaves públicas, registos de assinaturas (hash + assinatura + metadados), eventos do registo de auditoria. Nunca recebe o documento PDF, chaves privadas ou frases-passe das chaves.

2.3.1 Parâmetros do Algoritmo

2.3.2 Fluxo de Assinatura

// 1. Calcular hash do documento PDF (do lado do cliente)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. Assinar o hash com a chave privada (do lado do cliente)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey de IndexedDB (desencriptada)
  hashBuffer
);

// 3. Enviar ao servidor: hash + assinatura + chave pública (NÃO o PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Geração de Chaves

// Gerar par de chaves ECDSA P-256 (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extraível (necessário para encriptação + armazenamento)
  ["sign", "verify"]
);

// Exportar chave pública como JWK para registo no servidor
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Exportar chave privada como JWK para armazenamento encriptado
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

As chaves privadas persistentes nunca são armazenadas em texto simples. Antes de serem escritas em IndexedDB, a chave privada (exportada como JWK JSON) é encriptada utilizando o mesmo padrão da Transferência Segura:

2.5.1 Parâmetros de Proteção

2.5.2 Esquema de Armazenamento

// Estrutura do registo IndexedDB para uma chave de assinatura encriptada
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* formato JWK, não encriptado */ },
  "encryptedPrivateKey": {
    "salt":       "base64-encoded-16-bytes",
    "iv":         "base64-encoded-12-bytes",
    "ciphertext": "base64-encoded-aes-gcm-ciphertext"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "supabase-auth-user-id"
}

O PDF Pro utiliza um modelo de assinatura separada, o que significa que a assinatura é armazenada separadamente do documento. Este é o mecanismo crítico de privacidade: o documento nunca sai do dispositivo do signatário.

2.6.1 O Que É Enviado ao Servidor

• Hash SHA-256 do PDF (32 bytes, codificado em hexadecimal para 64 caracteres).
• Assinatura ECDSA sobre o hash (64 bytes, codificada em base64).
• Chave pública do signatário (formato JWK).
• Metadados: nome a apresentar do signatário, e-mail do signatário (se autenticado), carimbo temporal, ID da assinatura.

2.6.2 O Que NÃO É Enviado ao Servidor

• O próprio documento PDF — nunca transmitido.
• A chave privada — nunca sai do navegador.
• A frase-passe de assinatura — nunca sai do navegador.
• Qualquer conteúdo de página, texto ou imagens do PDF.

O esquema JSON seguinte define o registo de assinatura completo armazenado no servidor:

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-chars",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-encoded-ecdsa-signature",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-encoded-x-coordinate",
    "y":   "base64url-encoded-y-coordinate"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "string or null",
    "email":         "string or null",
    "userId":        "supabase-uid or null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "original-file-name.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "browser-user-agent-string"
  },
  "auditChain": {
    "previousEventHash": "sha256-of-previous-audit-event or null",
    "eventHash":         "sha256-of-this-record"
  }
}

A verificação de assinaturas é um processo em duas fases: verificação criptográfica do lado do cliente seguida de verificação cruzada do lado do servidor.

2.8.1 Fase 1: Verificação Criptográfica do Lado do Cliente

1. O utilizador carrega um PDF no navegador.
2. O navegador calcula o hash SHA-256 do PDF carregado.
3. O navegador consulta o servidor por quaisquer registos de assinatura que correspondam a este hash.
4. Para cada registo de assinatura devolvido, o navegador efetua a verificação ECDSA:

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. Se isValid === true, a assinatura é criptograficamente válida: o documento não foi modificado desde a assinatura e a assinatura foi produzida pelo detentor da chave privada correspondente.

2.8.2 Fase 2: Verificação Cruzada do Lado do Servidor

1. O servidor confirma que a chave pública no registo de assinatura está registada num utilizador conhecido (para assinaturas autenticadas).
2. O servidor confirma que o registo de assinatura não foi revogado.
3. O servidor confirma a integridade do registo de auditoria (validação da cadeia de hashes).
4. O servidor devolve o nível de identidade do signatário e o estado de registo.

2.8.3 Resultados da Verificação

Cada evento de assinatura e verificação é registado num registo de auditoria à prova de adulteração. Os eventos são encadeados por hash: cada evento inclui o hash SHA-256 do evento anterior, formando uma cadeia apenas de adição semelhante a uma blockchain.

2.9.1 Tipos de Eventos de Auditoria

2.9.2 Estrutura da Cadeia de Hashes

// Cada evento de auditoria inclui:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* payload específico do evento */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// Deteção de adulteração: para verificar a cadeia, calcular:
// SHA-256(JSON.stringify(evento sem o campo eventHash))
// e confirmar que corresponde ao eventHash.
// Depois confirmar que previousEventHash corresponde ao eventHash do evento anterior.

Se algum evento na cadeia for modificado, todas as ligações de hash subsequentes serão quebradas, tornando a adulteração imediatamente detetável. Isto fornece uma forte garantia da integridade do registo de auditoria.

Nota: Na interface do produto, "self_asserted" pode ser apresentado como "Identidade Auto-Declarada" ou "Assinatura de Convidado". "authenticated" pode ser apresentado como "Conta Autenticada". Estas são etiquetas de apresentação para os mesmos níveis de identidade subjacentes.

2.11.1 Pressupostos

• Tempo de execução do navegador é fiável
• A implementação da Web Crypto API está correta
• O IndexedDB não é acessível a outras origens
• O utilizador protege a sua frase-passe
• O código do servidor corresponde ao comportamento publicado

2.11.2 Fora do Âmbito

• Malware em dispositivos de extremidade
• Ataques de engenharia social / phishing
• Captura de ecrã pelos destinatários
• Extensões de navegador comprometidas
• Ataques de computação quântica (consideração futura)

• Não são uma Assinatura Eletrónica Qualificada (QES). As assinaturas do PDF Pro não cumprem os requisitos do Regulamento UE 910/2014 (eIDAS) para Assinaturas Eletrónicas Qualificadas. Não somos um Prestador Qualificado de Serviços de Confiança (QTSP) e as nossas chaves de assinatura não são geradas num Dispositivo Qualificado de Criação de Assinaturas (QSCD).
• Não são qualificadas pelo eIDAS. Ao abrigo do eIDAS, apenas as Assinaturas Eletrónicas Qualificadas têm o equivalente legal das assinaturas manuscritas em todos os Estados-Membros da UE. As assinaturas do PDF Pro são, no máximo, assinaturas eletrónicas avançadas e a sua validade legal depende da jurisdição específica e do caso de uso.
• Não são confiáveis pela Adobe. As assinaturas do PDF Pro não constam da Adobe Approved Trust List (AATL). Ao abrir um documento assinado pelo PDF Pro no Adobe Acrobat, a assinatura não aparecerá como "fiável" na interface da Adobe. A verificação deve ser efetuada através do sistema de verificação do PDF Pro.
• Não são uma autoridade de certificação. Não emitimos certificados X.509. A nossa infraestrutura de chave pública é proprietária do PDF Pro e não é interoperável com sistemas PKI como os utilizados por agências governamentais ou autoridades de certificação.
• Não são notarização. As assinaturas do PDF Pro não constituem notarização, apostilha ou qualquer forma de autenticação documental certificada pelo governo.
• Sem verificação de identidade real. Verificamos endereços de e-mail através do Supabase Auth, mas não realizamos verificação de documento de identidade governamental, verificação biométrica ou prova de identidade presencial.

2.12.1 Para Que São Adequadas as Assinaturas do PDF Pro

• Fluxos de trabalho empresariais — Aprovações internas de documentos, validações por equipas, autorizações de aquisição em que as partes confiam no modelo de identidade do PDF Pro.
• Verificação de integridade — Demonstrar que um documento não foi modificado desde um ponto específico no tempo.
• Não-repúdio (limitado) — Demonstrar que o detentor de uma chave privada específica assinou um documento específico num momento específico. A força do não-repúdio depende de quão bem a chave privada está protegida e de como a chave pública está vinculada a uma identidade.
• Conformidade de auditoria — Fornecer um registo de auditoria à prova de adulteração de eventos de assinatura de documentos para requisitos de conformidade interna.
• Assinatura de contratos — Em muitas jurisdições, as assinaturas eletrónicas (incluindo as não qualificadas) são legalmente válidas para a maioria dos contratos comerciais ao abrigo de leis como a ESIGN (EUA), UETA (EUA) e o artigo 25.º, n.º 1, do eIDAS (UE).