Um serviço que assina evidências sobre seus dados tem uma tentação óbvia: colocar os dados na evidência. Isso facilitaria a busca e o suporte e permitiria um dashboard mais rico. Decidimos cedo que os recibos da Trustvice não fariam isso: um recibo traz o hash do que descreve, não o conteúdo.
Este post explica por quê, e onde o design deixa de proteger você sem a sua ajuda.
Evidência que precisa viajar#
Um recibo só é útil se você pode entregá-lo a alguém: um auditor, uma contraparte, um mediador. Tudo o que está nele pode ser lido por quem o recebe. Se os recibos trouxessem conteúdo, cada recibo compartilhado vazaria algo, e você teria de pensar em ocultar dados toda vez.
Um hash SHA-256 evita isso. São 64 caracteres hexadecimais que identificam os bytes exatos do seu conteúdo sem revelá-los. O recibo diz, na prática: neste momento, estes bytes foram apresentados sob este label. Você guarda os bytes. Quando importa, você os apresenta, qualquer um calcula o hash, e ele confere com o recibo ou não.
Onde o hash não basta#
Estaríamos enganando você se parássemos aqui. Hashes protegem bem o conteúdo sob uma condição, e alguns campos de um recibo nem são hashes.
Um hash esconde o conteúdo só na medida em que ele é imprevisível#
O SHA-256 não pode ser revertido, mas pode ser adivinhado. Se a entrada tem poucas possibilidades, como um sim ou não, um endereço de e-mail, um código curto ou um modelo conhecido, quem tem o recibo pode calcular o hash dos candidatos e comparar. Para conteúdo assim, inclua um valor aleatório, um nonce, no que você passa pelo hash, e guarde o nonce com o original. O recibo então prova a existência sem deixar quem o lê adivinhar.
Alguns campos ficam em texto claro#
Labels e outros campos de texto livre que você escolhe são gravados em texto claro e, uma vez assinados em um recibo, ficam lá. Use identificadores opacos, como um número de pedido ou um id interno, e mantenha a tabela de correspondência do seu lado.
Faça o hash dos bytes exatos#
Um hash identifica bytes, não sentido. Uma quebra de linha no fim, \r\n em vez de \n ou outra normalização Unicode dão outro hash. Em texto, defina a codificação e as quebras de linha uma vez e mantenha. Em registros estruturados, guarde os bytes exatos que passaram pelo hash, não uma reserialização: um JSON.stringify posterior com outra ordem de chaves tem outro hash. Para vários arquivos, calcule o hash de um manifesto que lista o hash de cada arquivo, e ateste o manifesto.
Guarde seus originais#
Planeje uma consequência: um recibo não reproduz o conteúdo. Se você perder o original, o recibo continua verificando, mas não prova mais nada útil sobre um documento que você possa mostrar. Guarde os originais em armazenamento write-once, ao lado dos recibos.
Exclusão e a natureza da evidência#
Há um limite que nenhum design remove. Um recibo que você já entregou a alguém segue verificável por essa pessoa, faça o que fizermos, porque a verificação só exige o recibo e uma chave pública. É essa propriedade que o torna evidência. É também por isso que o conselho acima importa: mantenha dados pessoais fora dos campos em texto claro, e apagar um recibo raramente vira problema. Apagar o original no seu próprio armazenamento costuma bastar, porque o recibo guarda só o hash.
Em resumo#
Assinamos fatos sobre seus dados, não os dados. Hash primeiro significa que os recibos podem circular e que a verificação nunca exige confiar no nosso armazenamento. Isso não torna privado um valor adivinhável nem protege o que você escreve em campos de texto claro. Use nonces para entradas pequenas, ids opacos para labels e guarde seus originais.
Leia mais em O que um recibo prova, e o que não prova e na nossa página de segurança.
Trustvice 360