Onde está o checksum? Plataformas como CKAN não parecem oferecer

Apenas conferindo aqui com a comunidade, eu sempre entendi que é uma boa prática de incluir checksum nas páginas de download, principalmente em plataformas de dados abertos como o CKAN .

Achei que era só no Brasil que vinham negligenciando, mas não, parece que é geral, não oferecem checksum… Exemplos aleatórios:

Parece que internamente o CKAN confere hashes MD5 e SHA1, mas para o usuário final não é nada evidente.


Notas

Sempre bom lembrar que somente através do checksum podemos assegurar a autenticidade do documento… No Brasil SHA256 é o hash criptográfico mais comumente utilizado, por exemplo nos cartórios.

Descrevendo o problema através de um cenário típico:
um ano depois de ter feito o download, descubro que o site de sua origem não existe mais (ou que adulteraram o arquivo), e quero incluir meu download como prova num julgamento. Sem o checksum o meu arquivo não tem valor de prova.
Até posso conseguir comprovar que a página do download existiu, e que meu arquivo tem mesmo nome e formato… Mas como garantir que o arquivo que foi anunciado naquela página é de fato o meu arquivo?

2 curtidas

Em datasets que usamos o padrão Frictionless Data Package incluímos o checksum. Por exemplo, este tem o hash 3e844d3c2f5a96e9525de8ec4aad28892862505c0ba65ca1af0b613a12f49e73 com o algoritmo SHA256, como pode ser visto nos metadados em formato JSON. Ele é atualizado mensalmente por um processo automatizado que sempre gera o Data Package.

Mas concordo que são raros os conjuntos de dados que oferecem isso.

1 curtida

Alguns argumentos que vou usar no post


Tem uma clarificação terminológica importante aqui: o que se entende por /checksum/@eng-Latn obrigatoriamente deve ser útil para detectar erros (não intencionais) durante transmissão e armazenamento de dados, porém _não é obrigatório garantir autenticidade. No artigo de 2017 do Peter ele aborda isso. Mas vou ser chatinho aqui com terminologia, pois isso afeta quais algorítimos o CKAN usa, e o que o Peter quer com o artigo

… “incluir meu download como prova num julgamento” …

Se o interesse é judicial, estamos falando de /Data authenticity/(at)eng-Latn e não de /Checksum/(at)eng-Latn.

Usando como base o Berkeley Protocol - on Digital Open Source Investigations que comentei aqui Cartórios da Internet - #3 por rocha, além de “foto de tela” que pode ser anexada em processos (e isso sei que é usado também no Brasil, mas dependeria de portais de dados exibirem assinatura criptograficamente segura) eles também aceitam armazenar o HTML inteiro de páginas (que poderia ter informações adicionais). Ambos os casos têm algo em comum: conjuntos de dados poderiam ser considerados uma prova como qualquer outra informação (como uma foto, ou um vídeo) mas assume-se que é inviável anexá-los em processos (questão de tamanho), então a forma de autenticar a informação é extremamente importante, e essa prova é que deve ser armazenada, enquanto a evidência pode permanecer em outros lugares.

Vou dar um resumo da minha opinião no momento sobre isso.

Como autenticar dados? Qual estratégia usar?

Modo tradicional

O modo mais tradicional é ter uma cadeia de custódia clara, e quem armazena as provas é considerado confiável. O equivalente aqui seria deixar um cartório, força policial e afins guardarem as evidências, mesmo que digitais. Nada impede de ter alternativas, como bibliotecas de um país, ou arquivadores de outras regiões do mundo, mas todos têm em comum que a confiança em quem armazena dados pode ser suficiente.

Isso inclusive pode servir para informações de 5 décadas atrás (e, por inferência, daqui 50 anos), e sobreviver a todas as estratégias existentes de tecnologia que visam garantir autenticidade de dados. Para ter ideia, potencialmente a maioria do que seria considerado estado da arte (como blockchain) a não ser que houvesse re-hashing com novos algoritmos antes dos antigos se tornarem obsoletos, potencialmente não seriam mais aceitáveis em 5 décadas.

Modo autenticar algo equivalente à assinatura de uma evidência, mas armazenar a tal prova (que pode ter dados sensíveis) em outro lugar sem fé pública

A resposta para isso vai evoluir com os anos e avanço da tecnologia. Assumindo que quem armazena não tem fé pública (ou tem, mas quer proteger de invasões e/ou ataques focados) a ideia pode parecer com rotacionar backups onde ao longo das décadas as assinaturas devem antecipar a fragilidade de algoritmos.

Vamos assumir um cenário otimista de apenas 20 anos:

  • Nenhuma assinatura de smartcard prevê esse prazo.
    • Entendo que alguns podem argumentar que cartórios digitais ganham mais dinheiro ao renovar, mas quem ler a fundo que RSA 4096 (que é o mais suportado hoje) já está sendo substituído por ECCs como curve25519 (e é uma merda querer ir direto pois muitas ferramentas ainda não aceitam ECCs)
    • Mesmo que smartcards possam ser usados, isso ainda dependerá da confiança da pessoa que fez a assinatura (e que ao longo dos anos não houve comprometimento).
  • Hash que forem considerados cartograficamente seguros (para uma determinada época) sempre serão mais práticos de automatizar (para criar arquiva, para quem certifica que evidência arquivada é válida, e para explicar para juízes)
    • O que é seguro em 2022? Tem que ir atrás para ver.
      • Mas MD5 e SHA1 nem fodendo.
      • Na dúvida, autenticar com mais de uma estratégia é uma proteção para caso um algoritmo for considerado invalidado
        • SHA-384 (SHA-2), e SHA-512 (SHA-2) (mesma família, apenas força maior) pode ser útil por questão de compatibilidade, mas faria sentido ter mais de uma família de algoritmos, não apenas variações de maior força de uma mesma família
  • Mas… tem como garantir que em 20 anos o que você arquivaria hoje permaneceria incontestável sem precisar intervenção de outros humanos?
    • Quanto às assinaturas (ainda mais com redundância, assumindo falhas), talvez
      • Isto é, existe chance de não precisar ter uma cadeia de custódia muito bem documentada para antes dos algoritmos serem considerados inseguros, re-assinar com novos algoritmos que cada evidência agora tem assinaturas mais fortes
    • Quanto à integridade dos arquivos, não.
      • Aqui é o motivo de /checksum/(at)eng-Latn serem tão populares: armazenamento deteriora com o tempo. Fabricantes de mídias offline alertam do risco de bit rot (que pode ser mitigado com mais de uma cópia, provavelmente mais de um tipo de arquivo e redundância para corrigir bits errados). Pode não afetar o arquivo que você precisa, mas algums arquivos são afetados, mesmo que a mídia de armazenamento esteja funcionando.
    • Notem que, para fins legais, mesmo que algoritmos ainda estejam seguros, até mesmo um mero bit rot vai alterar todas as assinaturas!
      • Vamos assumir que isso acontecem daqui 19 anos:
        • Se quem armazena arquivos tem fé publica (mas os acesso aos arquivos eram restritos e controlados):
          • embora argumentação enfraqueça a prova, juízes podem aceitar erro acidental da forma como foi feito armazenamento e não ignorar completamente
        • Se o arquivamento é externo:
          • Degradação natural de um mero bit (se não puder fazer força bruta para descobrir qual foi) invalida a prova.
            • O padrão é sempre guardar arquivos originais, e, segundo Berkeley Protocol - on Digital Open Source Investigations qualquer alteração nos arquivos for cuidadosamente anotada.
              • Por inferência (isso não é dito no Berkeley, é chute meu) se for muito caro armazenar arquivos grandes (imaginemos: 10GB de um vídeo), também gerar uma cópia menor (que tem hash adicional) que pode ter mais cópias poderia ser uma alternativa para um humano ver que o arquivo grande perdeu o hash, mas ainda é equivalente.
              • Notem que é muito, muito complicado esse tipo de manipulação de arquivos se o processo e quem o faz não tem fé publica ou pode ser alegado interesse

CKAN como meio de armazenar informações como provas

Em teoria, CKAN, desde que adote hasheamento considerado critograficamente confiável, até poderia ser usado como para “fotos de tela” com o que se tinha em uma época. Em geral com passar do tempo os arquivos que não tem interesse ao publico são deletados e isso pode ser um processo natural (não ser ma fé).

Mas se há interesse de propor alterar o comportamento padrão de futuras versões do CKAN:

  1. primeiro tem que ficar claro se a finalidade é /checksum/(at)eng-Latn ou /data authenticity/(at)eng-Latn. Checksum, ate CRC32 serve. Sem saber aonde quer chegar, qualquer opção é válida.
  2. Se é /data authenticity/(at)eng-Latn, quantos anos? 20 anos pode ser uma boa linha base? Se sim, usando SHA-1, publicado em 1995, já em 2010 (15 anos depois) já haviam ataques teóricos. Trivia: a forma como falhas são descobertas explora implementação de algorítimos, não mera força-bruta com mais máquinas e hardware.
    1. Se não há como prever quais hashs vão deixar de ser fortes, uma alternativa é usar pelo menos duas opções, de famílias completamente diferentes (não apenas mesma família, só que mais bits).
    2. Não apenas para facilitar quem tira foto de tela no Brasil, mas outros locais no mundo em que advogados podem não entender HTML, todas as opções de assinaturas devem ser visíveis no mesmo local onde outros metadados são exibidos.

Acho que o ponto 2 da lista acima provavelmente atende a sugestão do autor do tópico. E, embora estejamos discutindo pensando sobre dados abertos (instâncias publicas do CKAN) isso pode ser útil também em instâncias privadas, onde pessoas leigas não sabem como gerar o hashes. Ou então como algum tipo de guia de boas práticas de arquivamento.

1 curtida