Projeto Preservando Conteúdos Oficiais

No Brasil existem ~4 milhões normas publicadas em diários oficiais de 1998 para cá, somando leis, decretos, portarias, etc. de todas as esferas, federal, estadual e municipal. Se acrescentarmos a esse conjunto as outras matérias publicadas nos diários oficiais, tais como contratos, licitações, etc. Multiplicamos o volume por 10 (~40 milhões de documentos acumulados).

Volume de normas produzido de 1998 a 2008, conforme estudo do IBPT.
Nota: o acervo de legislação federal do LexML em 2015 já chegava aos ~260mil documentos, quase o dobro da projeção ilustrada.

Além disso, no Brasil atualmente estamos caminhando para o zero-papel nos diários oficiais: não haverá mais provas do que foi publicado nas bibliotecas tradicionais (de papel). A comprovação, o documento que se presta como evidência, agora é um arquivo digital.

Esse enorme volume de documentos oficiais requer auditoria e preservação, mas no Brasil ainda não foram instituídos mecanismos oficiais obrigatórios para esse fim. O presente projeto apresenta uma metodologia simples e suas justificativas.

Problema e suas facetas

Para entender as questões da integridade física dos documentos oficiais digitais, imaginemos os cidadãos Alice, Roberto, Victor e Carol, atuando como auditores independentes.

Existem 3 problemas, ou facetas do mesmo problema, para garantir a integridade de arquivos digitais:

1. Garantir que o arquivo fornecido por um link (URL) está sendo recebido corretamente.
   Exemplo: Alice precisa fazer um backup do PDF dessa URL, ou seja, precisa fazer o download e conferir (auditar) se nenhuma adulteração ocorreu no caminho.
2. Garantir que outra pessoa, em outro lugar, mas no mesmo dia ou mesmo ano, obteve exatamente o mesmo arquivo ao acessar a mesma URL.
   Exemplo: Roberto espera acessa o mesmo PDF dessa mesma URL, e quer conferir (auditar) com Alice se é exatamente a mesma coisa.
3. Garantir que outras pessoas, num futuro distante, obtenham exatamente o mesmo arquivo ao acessar a mesma URL... Ou ao menos possam conferir se a nova URL oficial oferece o mesmo arquivo dos itens 1 e 2 obtidos num passado distante.
   Exemplo: Victor e Carol, 20 anos depois, precisam conferir se o arquivo oficial ainda bate com aquele auditado 20 anos antes por Alice e Roberto.

Nos exemplos

Soluções gerais

Sem entrar em detalhes, podemos classificar as soluções conhecidas em dois grandes grupos:

• comparação sistemática "byte a byte" dos arquivos;
• comparação de "impressões digitais" dos arquivos, obtidas por algoritmos de hashing.

O segundo grupo (hashing) será dividido em dois, para ajudar a apresentar a solução utilizada no projeto.

Comparação byte-a-byte

A solução mais óbvia para esse problema é fazer com que todos copiem os arquivos e confiram byte-a-byte se são exatamente os mesmos arquivos... Mas essa "solução de bruta força" tem alguns impedimentos graves, quando pensamos em milhões de documentos:

• O custo dos backups e de sua preservação.
  Além do custo de gravar tudo em DVDs e enviar para um "banco central" (hoje é a Fundação Biblioteca Nacional), há o custo de se manter o DVD por muitos anos guardado. Pode-se somar o custo/inconveniente de acesso (que não pode ser livre para qualquer um manipular os DVDs), e ainda o custo manter seguro (guardas, segurança armada por anos, etc.).

• Inconveniente da centralização.
  Persiste o problema do poder central, que se diz "o oficial". Eventualmente se forem dois, o custo será dobrado.

• Custo da verificação descentralizada.
  Não tem como qualquer um auditar, precisa ser sempre o responsável pela cópia oficial, e comparando-se byte-a-byte.

• Perda da prova em papel.
  Na tradição do papel e dos cartórios, haviam ao menos procedimentos consensuais e com uma legislação baseada em séculos de confiança em procedimentos similares. O Brasil ainda vive uma transição desses procedimentos clássicos para os procedimentos digitais. Seria interessante que a solução pudesse incorporar, mesmo que opcionalmente, procedimentos tradicionais.

Checksum simples

O conceito de checksum é bem conhecido... Em português é "soma de verificação", e ficou mais conhecido em códigos como o CPF, onde o os últimos dois dígitos, redundantes, são ditos "dígitos de verificação", obtidos da soma rotativa dos dígitos não-redundantes. Por exemplo no CPF 007.687.828-72, 72 é o resultado da soma de verificação aplicada a 007687828.

Podemos imaginar que todos os bytes de um arquivo podem ser somados através de um algoritmo de checksum, resultando em uma espécie de impressão digital do arquivo, dita digest, que é um código com bem mais do que dois dígitos. Os algoritmos mais comuns retornam digests com comprimento entre 120 e 512 bits.

Como o digest resultante da checksum é (em geral) único para cada documento, o digest também pode ser utilizado como identificador do documento. Além disso, como os bons algoritmos de checksums também são sensíveis a pequenas modificações no arquivo (por exemplo mudança de um virgula no texto da Constituição), eles se prestam à garantia de integridade.

Como são pequenos (mesmo 512 bits requerem menos que 100 caracteres para sua representação), podem ser impressos sem maior custo, assim como registrados aos milhões em bancos de dados.

Exemplificando o uso de checksums nas três facetas do problema da integridade comentado acima:

1. Garantindo que o arquivo da URL está sendo recebido corretamente.
   Alice apenas calcula o checksum do PDF da URL, e compara (audita) com o checksum esperado, divulgado no mesmo portal que o PDF. Suponhamos que o algortimo oficial fosse SHA1, então teremos sha1sum(PDF)=bdc3831478ef9d00f62afa7c28cd379e42904f5f. Se os digests resultarem ser iguais, nenhuma adulteração ocorreu no caminho.
2. Garantir que outra pessoa obteve exatamente o mesmo arquivo ao acessar a mesma URL.
   Roberto acessando e conferindo a mesma URL, obtém bdc3831478ef9d00f62afa7c28cd379e42904f5f, o mesmo digest que Alice.
3. Garantir que outras pessoas, num futuro distante, obtenham exatamente o mesmo arquivo ao acessar a mesma URL.
   Victor e Carol, 20 anos depois, obtém novamente bdc3831478ef9d00f62afa7c28cd379e42904f5f.

Se ao invés de SHA1 o padrão oficial do exemplo fosse SHA3-256: aplicado ao mesmo PDF, obtemos em representação hexadecimal f269212ad72b600542072ae125c9c4835cb00ebfeed65539c5004c5d1f84645c; em base58 é mais compacto, HKGe7sby674GnmnzNDLLXb1hf8Amwcx682gX4QtPrJSf. A base da representação é o seu alfabeto, base10 é decimal, base16 hexa, base58 é um alfabeto de 58 caracteres. A base de referência, com dígitos contabilizados em bits, é a base2. O SHA1 tem 120 bits, o SHA3-256 tem 256 bits.

Checksum dupla

Como ao longo de anos (ou décadas) o "fator de proteção" do checksum decresce, é importante que o fator seja grande o suficiente.

Para reforçar essa garantia do fator, pode-se utilizar um checksum mais longo, ou usar dois algoritmos distintos para aumentar a dificuldade. Exemplos:

• Mais longo: SHA3-512 ao invés de SHA3-256.
  A teoria garante as duas coisas com o mais longo, que será mais difícil de aparecer outro documento com mesma digest (probabilidade de colisão) e portanto menos suceptivel a "ataques"; e que amostrará melhor o documento, sendo uma "impressão digital" mais fiel.

• Dois dois algorimos: SHA3-256 + SHA1 ou SHA3-256 + SHA2-256, ao invés de só um deles.
  A teoria diz que os fatores de proteção das duas checksums serão multiplicados, resultando em um fator muito maior do que qualquer delas sozinha. Quanto mais distintos os algoritmos maiores as chances também de serem amostragens distintas.

Ambos os métodos portanto resultam nas mesmas garantias, a principal diferença no uso de dois algoritmos distintos, é que em caso de um dos algoritmos ser corrompido (exposição a "ataques"), o outro pode garantir.

Alguns protocolos concatenam os dois digests resultantes, outros registram digests em separado.

Mix de métodos

Os métodos acima podem ser utilizados de forma concomitante. Por exemplo uma autoridade central independente preserva os backups e seus checksums, e autoridades descentralizadas monitoram os checksums e auditam amostras dos backups.

O principal exemplo de preservação digital hoje, usando esse mix de métodos, é o wikipedia:LOCKSS.

Propostas

...

Git com reforço de SHA3

...