Cartórios da Internet

Onde o grande público da Internet pode registrar e conferir “registros de existência” relativos aos conteúdos a que todos temos acesso?

Podemos resumir o problema através do seguinte cenário:

Os conteúdos da Web mudam a todo momento, mas fazemos transações bancárias, consultamos diários oficiais e baixamos arquivos, uma infinidade de dados abertos com origem (dono) e licença rastreáveis, e muitos deles supostamente oficiais
Será que serão rastreáveis daqui 1 ano? E sua origem, quem baixou hoje pode comprovar daqui 1 ano que não era fake ou que não foi um hacker que vazou o dado, sem a devida licença?

O que a Internet precisa para resolver esse problema?

Seria um tipo de escritório online de uma organização que tenha a custódia de “documentos da Internet”, e que lhes dá fé pública, com valor de prova dentro do Sistema Jurídico do Brasil.

Mais especificamente, os “documentos da Internet” são conteúdos digitais ofertados na grande rede numa certa data, tais como páginas web e demais arquivos de extensão MIME válida… Tudo ou boa parte daquilo que o nosso Marco Civil da Internet também entende por “dados” e “conteúdos”.
Nesse contexto o “cartório da Internet” seria um análogo ao que nossa Lei dos Cartórios designou, em seu art. 5º, como

registradores de títulos e documentos e civis das pessoas jurídicas

onde o termo registrador seria reservado aos “oficiais de registro”, mas aqui tem um sentido mais amplo.


Notas

Deixando o Brasil de lado e procurando pela Internet, logo notamos que existe o conceito de web archiving. Consagrada pelos seus conteúdos e seu sistema de comprovação das fontes, a Wikipedia é um bom exemplo de instituição que já aderiu ao uso do web archiving: quando desejamos registrar um link (ou seja URL) na grande enciclopédia, usamos dois endereços, o url original e o archive-url, que é a URL de um serviço confiável de web archiving apontando para o registro da URL original numa certa data.

Exemplos populares desse “serviço de registro no cartório da Internet”: Web.Archive.org/save  e  Archive.Today.

3 curtidas

Confiabilidade dos serviços de web archiving

O Sistema de Direito requer que as evidências sejam guardadas em segurança, com todo um ritual que inicia pela coleta até o seu arquivamento em local seguro, dentro da assim-chamada cadeia de custória. Os sistemas de web archiving parecem respeitar esse ritual e seus cuidados, mas será que fazem tudo certinho, sem risco de contestações?

Quanto à confiabilidade e reprodutibilidade do serviço: qualquer um de nós pode conferir a checksum do conteúdo arquivado. Sendo um bom algoritmo de hash criptográfica, tal como SHA256 (hoje adotado em nossos cartórios), podemos confiar.

Quanto à confiabilidade de datação: há quem questione os serviços de web archiving. quanto à garantia de “data de fotografia” de uma página web por exemplo. Existem sugestões de registro em blockchain, por exemplo essa discussão de 2017 (“Bitcoin Carbon Dated”) ou esse artigo sobre registro em blockchain.

Alternativas juridicamente válidas

Voltando o Brasil, o eCPF (exemplo) já foi integrado ao nosso Sistema Jurídico, inclusive para dispensar o uso de papel, e para autenticar as páginas de um Diário Oficial. Ainda assim o nosso Sistema de Chaves não é registro público, mas apenas um mecanismo que garante a autenticidade de assinaturas (e sua data) em operações digitais, hoje restritas ao (horrível) formato PDF.

Uma gambiarra interessante seria assinar digitalmente com eCPF (exemplo) um documento PDF de declaração do tipo
“eu Fulano declaro que os arquivos abaixo listados com respectivos checksums do tipo SHA256 foram registrado no dia 2022-03-04”.

No caso da Capital do Estado de São Paulo, em observância à Lei Municipal nº 16.838 de 2018, que confere fé pública aos advogados (portadores de token da Autoridade Certificadora OAB), isso é válido.

Dentro da ideia de cadeia de custódia fica aqui minha sugestão publica de uma demanda necessidades de ferramentas mais práticas para implementar isso estratégias. No link a seguir tem uso mais especializado:

  • Berkeley Protocol - on Digital Open Source Investigations: A Practical Guide on the Effective Use of Digital Open Source Information in Investigating Violations of International Criminal, Human Rights and Humanitarian Law
    • Na Página 59 (VI - Investigating process / C. Collection) tem alguns pontos mais relevantes. Mas eles não falam de ferramenta específicas (compreensível considerando que isso evitaria vendor lock-in)
    • O documento como um todo envolve a ideia de arquivistas digitais

Enquanto o Istanbul protocol e o Minnesota Protocol são mais focados em procedimentos para coleção de evidências que requerem acesso físico, o Berkeley Protocol é totalmente focado em como lidar com coleção de evidências. Usam “open source” numa analogica para evidências que estavam abertas, sem necessidade de coletar de depoimentos de vítimas ou, o que é um problema em tribunais, uso de dados vazados ou que foram obtidos por invasão de computador da pessoa.

Creio que acaba sendo relevante no tópico aqui essa referência pois toda documentação de como cadeia de custódia, como gerenciamento dos dados, é relevante. Não obstante, comparado a um cartório tradicional (que tem custos elevados, e pode ter limite de tamanho) o tipo de coleção de evidência potencial do Berkeley Protocol é muito alto e as vezes pode ter dados pessoais (o que de certa forma complica ideia de deixar completamente publico, mas ao mesmo tempo precisar provar o contexto em que foi coletada).

Era isso para meu segundo post aqui!

Produzir documentos assinados usando um certificado ICP Brasil é muito mais complicado do que deveria ser. Eu mesmo já tentei, sem sucesso, fazer uso disso quando ganhei um certificado em 2019:

E olha que eu posso dizer que tenho mais habilidades em lidar com recursos computacionais que o usuário médio. Quem dirá quem é leigo no assunto.

O bug na libgcr, reportado à época, continua sem solução, mais de 2 anos depois. Os drivers do token continuam sendo proprietários. Enquanto não houver investimento em drivers livres para hardware criptográfico, bem como em ferramentas livres e com usabilidade para fazer e verificar assinaturas digitais, essa utopia continuará sendo uma fantasia.

1 curtida

Minha recomendação para quem estiver passando problemas como o do @herrmann: um dos melhores provedores de smartcards que tem mais suporte em software é a Yubico. (Não tenho relação com empresa, mas vou dizer aqui, pois é relevante).

Minha experiencia com Yubico

Eu tenho uma YubiKey 5 NFC (importei direto do fabricante, nem fui cobrado imposto) e o processo de instalar coisas ainda continua sendo meio infernal, mas pelo menos é menos infernal do que concorrentes. No caso de celular sem NFC, com adaptador da para usar via porta USB e as coisas funcionam como esperado até mesmo em aplicativos Android. Minhas assinaturas de Commit no GitHub são usados ele.

O guia publico mais importante para quem quer usar é esse aqui

  • GitHub - drduh/YubiKey-Guide: Guide to using YubiKey for GPG and SSH
    • Meu ambiente de testes é primariamente Ubuntu 20.04 LTS
      • mas os pacotes que realmente importam, são padrões de sistema. Não precisa de driver proprietário para ações chaves!
      • A Yubico tem pacotes extras (inclusive uma GUI) mas quase tudo da para fazer usando interfaces padrões do GNUGPG. Prefiro elas pois da para documentar menor quando tem que resetar as coisas.
      • A GUI deles tem pacote que funciona standalone (ou seja, um executável que não precisa ser instalado)
    • O meu setup foi o mais hardcore possível, assumindo inclusive hardware comprometido no caso de gerar as chaves. Recomendo quem for querer fazer setup bacana, já compre de antemão alguns pen drives (pode ser pequenos) e deixar num Tails (ou Debian live) tanto backups como qualquer operação que envolve gerenciar as chaves.

Tem outras coisas que eu poderia falar, mas da um trabalho enorme fazer as coisas. Mas na época eu configurei tanto scripts que permitem fazer backup da minha máquina de trabalho mas que tinham compatibilidade para funcionar com Live Installs:

Sobre encritação automatizada (uso de agentes sem interação humana)

Smartcards fazem mais sentido quando tem um humano por trás, mas não é o ideal se você precisa deixar um agende (por exemplo, uma VPS) que encripta ou autentica coisas.

Tem como usar smartcards para isso? Tem, mas é uma situação overkill. Se até mesmo smartcads com acesso físico tem motivos conhecidos de segurança para ter botão físico, deixar um agente totalmente automático (numa VPS externa, localmente por algum período de tempo até pode ser tolerável) não é vantajoso.

O que geralmente faço para casos simples (quer segurança, mas não nível militar)

No caso de clientes que só precisam de backup simples (e ja é muito difícil explicar que backup tem senha, então seria impossível explicar chave assimétrica) geralmente os backups são com chave simétrica (isto é, password estático, mesmo que esteja usando ferramentas do GNU) antes de enviar para alguma cloud remota.

O que geralmente faço para casos simples (quer segurança, mas tem recupera acesso tem mais conhecimento)

Se fosse algo governamental (em que quem recuperaria os backups tem condições de saber como usar chave assimétrica) em vez de password estático, a máquina que ficaria fazendo backups de outras máquinas sem interferência humana teria alguma chave assimétrica com mais de um destinatário (por exemplo, ela mesma, e chaves em smartcads de outros).

Note que se a máquina (um agente automatizado, sem interferência humana) for comprometida, seja nesse contexto ou no de password estático, o dano seria semelhante. Porém o uso de chaves assimétricas (e poder “permitir vários destinatários”) é extremamente conveniente para evitar ter passwords de muitos departamentos. Se uma pessoa for demitida, é complicado rotacionar backups antigos (mas pode-se impedir acesso dela a tais backups), e nada impede de ter alguma chave antiga, do tipo que guarda em um cofre ou algo assim, que todos assinam e somente seria usada em caso tudo der errado.