A Privacy-by-Design Architecture for Secure Submission of Sensitive Documents to Public Agencies: Mutual Consent, Local Encryption and Forensic Hashing

🇺🇸 TECHNICAL NOTE / DESIGN SPECIFICATION Secure Interaction System with Mutual Consent, Cryptographic Integrity Hashing, and Data-Minimizing Auto-Deletion Complete Operational Flow + Proof of Concept (PoC) Architecture 1. Overview This Technical Note describes the complete architecture, operational flow, and cryptographic mechanisms of a system designed to securely submit sensitive documents to public agencies (specifically the INSS – Brazilian Social Security Institute). The solution implements: mutual informed consent (user + institution) local encryption prior to upload forensic-grade integrity verification (SHA-256) a full and auditable chain of custody privacy-by-design and data minimization automated deletion of sensitive content low-cost, lightweight, independently auditable components This document integrates the functional flowchart and the detailed PoC architecture into one unified specification. 2. System Architecture Overview The system operates through seven sequential phases, each generating cryptographically verifiable metadata: Initiation & User Consent (C1) Document Submission + Local Encryption Institutional Acceptance (C2) Document Analysis Secure Auto-Deletion Persisted Minimal Metadata Archive Completion & Notification All sensitive content is erased after analysis. The only data retained is non-sensitive, audit-relevant metadata. 3. Detailed Operational Flow 3.1. Phase 1 — Initiation of the Process The user (claimant) initiates the submission session. The interface prompts explicit informed consent:C1 – User Consent Once consent is confirmed, the system activates the secure submission workflow. 3.2. Phase 2 — Document Submission After selecting a file (e.g., FLIR thermal image, PDF report, medical documentation): The system generates a SHA-256 integrity hash (H1). The file is encrypted locally using AES-256. A technical package is created containing: session ID H1 timestamp T1 consent token C1 session encryption key (KS) encrypted file The package is transmitted to secure storage (Google Drive API or Cloud Storage). The system waits for the institution’s decision. 3.3. Phase 3 — Institutional Reception and Consent The INSS server interface displays: session ID hash H1 timestamp T1 user consent C1 The server chooses: a) Reject → Immediate auto-deletion of all content.→ Session ends. b) Accept → Generates C2 – Institutional Consent→ Registers timestamp T2→ Establishes Mutual Consent (C1 + C2)→ Forms the initial probative chain: {C1, C2, H1, T1, T2} 3.4. Phase 4 — Document Analysis Once accepted: The server receives the session key KS. The document is decrypted locally (never stored in plaintext). The server analyzes the content. The system records: timestamp T3 (document opening) minimal server identifier (non-sensitive) timestamp T4 (conclusion) decision or finding integrity validation using H1 3.5. Phase 5 — Secure Auto-Deletion After the analysis concludes, the system permanently deletes: encrypted file decrypted temporary file session key (KS) Only non-sensitive metadata remains. This satisfies LGPD’s principle of necessity, prevents retention of sensitive data, and reduces risk. 3.6. Phase 6 — Minimal Metadata Archive Persisted metadata (final, legal, audit-proof): ID of session H1 (integrity hash) T1, T2, T3, T4 (timestamps) C1 and C2 (consent chain) Decision/outcome No document content is retained. These records provide: proof of voluntary submission proof of institutional acceptance proof of integrity proof of analysis verifiable chain of custody 3.7. Phase 7 — Completion The process finishes with: complete traceability cryptographic integrity minimal data retention strong privacy guarantees institutional auditability low operational cost The user receives a secure notification confirming analysis and deletion. 4. Proof of Concept (PoC) — Full Technical Description The PoC is divided into six modular components, all auditable, independently testable, and lightweight. 4.1. Component 1 — Minimal Submission Interface (HTML + Vanilla JS) Core functions: file selection SHA-256 hash generation explicit consent request (C1) AES-256 local encryption metadata packaging upload to external storage timestamp generation Internal flow: User selects file Browser computes SHA-256 → H1 Consent request (“I confirm I want to send this document to INSS”) Local AES-256 encryption Package creation Upload via Google Drive API or GCP Storage This interface has no external dependencies, ensuring easy auditing. 4.2. Component 2 — Local Encryption (AES-256) Encryption occurs before any transmission. The session key (KS): is generated per session may derive from the session ID is only shared after the INSS accepts the session (C2) Security guarantees: prevents interception blocks unauthorized access shields sensitive content (e.g., thermal images, medical reports) 4.3. Component 3 — Integrity Hash (SHA-256) Generated using the browser's crypto.subtle.digest API. Properties: H1 remains even after deletion functions as a forensic “digital fingerprint” verifies integrity at all stages supports legal and audit requirements 4.4. Component 4 — Secure Upload (Google Drive API / GCP Storage) The storage layer accepts a structured package: { "session_id": "...", "hash": "H1", "encrypted_file": "<blob>", "user_consent": "C1", "timestamp_T1": "..." } No names, CPFs, or identifying data appear in plaintext. 4.5. Component 5 — INSS Server Panel The server interface displays: session ID H1 T1 C1 ACCEPT (C2) REJECT (auto-delete) If “ACCEPT” is selected: C2 is generated KS is released Local decryption Document review Decision recorded with T3 and T4 Creates the full probative chain and ensures LGPD compliance. 4.6. Component 6 — Auto-Deletion Engine This is the core mechanism for privacy and legal compliance. Deletes: encrypted file decrypted temporary file KS Preserves only essential, non-sensitive metadata. Guarantees: total privacy strict necessity principle reduced legal exposure minimized attack surface 5. PoC Validation Criteria The PoC is valid when it satisfies: Voluntary user submission✔ C1 Institutional acceptance✔ C2 Integrity verification✔ H1 Secure analysis without exposure✔ local encryption + controlled access Data minimization✔ auto-deletion mechanism Auditable probative chain✔ T1–T4 + H1 + C1 + C2 6. Conclusion This integrated system demonstrates a privacy-by-design architecture enabling secure submission of sensitive documents to public agencies, ensuring: mutual consent cryptographic integrity end-to-end encryption minimal retention auditability full LGPD compliance operational simplicity The system is suitable for immediate demonstration, institutional evaluation, and formal presentation in academic or governmental contexts. 🇧🇷 DOCUMENTO TÉCNICO INTEGRADO Sistema de Interação Segura com Consentimento Mútuo, Hash de Integridade e Proteção de Dados Sensíveis(Fluxo Operacional + Descrição Técnica da Prova de Conceito – PoC) 1. Objetivo Geral Este documento apresenta a arquitetura integrada e o detalhamento técnico-funcional de um sistema destinado a permitir o envio seguro de documentos sensíveis ao INSS, assegurando: consentimento mútuo (usuário + INSS) integridade criptográfica cadeia de custódia juridicamente válida privacidade e não retenção de dados pessoais sensíveis aderência plena à LGPD rastreabilidade técnica completa baixo custo operacional e simplicidade de implementação O sistema é composto por fluxo operacional (Seções 2 a 7) e descrição da PoC (Seção 8). 2. Fluxograma Técnico Geral do Sistema O sistema funciona mediante sete fases integradas, cada uma gerando metadados probatórios auditáveis: 2.1. Início do Processo O segurado inicia o envio. A interface solicita consentimento explícito:C1 – Consentimento do Segurado Ao confirmar, inicia-se a sessão técnica de envio. 2.2. Envio do Arquivo Após o usuário selecionar o arquivo: é gerado HASH H1 (sha-256) o arquivo é criptografado localmente (AES-256) é criado o pacote técnico contendo: ID único da sessão H1 timestamp T1 C1 chave da sessão (KS) O pacote é enviado a repositório seguro externo (Drive ou Cloud). O sistema aguarda o aceite do INSS. 2.3. Recebimento pelo INSS O servidor do INSS acessa a fila de documentos, visualizando: ID da sessão hash H1 T1 C1 O servidor decide: a) Recusar → O sistema executa autolimpeza imediata e encerra. b) Aceitar → gera C2 – Consentimento do INSS→ registra T2→ estabelece o “consentimento mútuo” (C1 + C2)→ cria a cadeia probatória inicial: {C1, C2, H1, T1, T2} 2.4. Análise do Documento Após o aceite: o servidor recebe a chave KS o arquivo é descriptografado localmente o servidor visualiza, analisa e emite decisão são registrados: T3 (abertura) ID mínima do servidor T4 (conclusão) decisão emitida verificação de integridade via H1 2.5. Fechamento e Autolimpeza Concluída a análise: O sistema elimina: arquivo criptografado arquivo descriptografado chave KS E mantém apenas os metadados probatórios: {H1, T1, T2, T3, T4, C1, C2, decisão} Atendendo ao princípio da necessidade da LGPD e garantindo proteção total. 2.6. Arquivo Final (Persistente e Legal) Os únicos dados armazenados sã