Reproducible Firmware Build

O fabricante pode publicar código que um programador consegue ler. Contudo, o que normalmente se instala na carteira é um ficheiro terminado em formato de máquina, chamado binário. A compilação liga estas duas formas. Uma pessoa independente pode repeti-la e comparar o resultado com a publicação. Procura bytes idênticos, ou seja, as mesmas unidades de dados, frequentemente através de um hash criptográfico: uma impressão calculada a partir do conteúdo. A verificação abrange resultados definidos, como o ficheiro de firmware, e não automaticamente todos os ficheiros de trabalho e registos. [1] [4]

Imagine dois programadores a verificar uma atualização. O nome do projeto não chega: precisam do mesmo commit, isto é, uma revisão exata do código. Também precisam das versões das bibliotecas usadas e do compilador, a ferramenta que converte o código para formato de máquina. As suas opções, as definições relevantes do ambiente e o modelo da carteira fazem igualmente parte do procedimento. Estes dados devem ser definidos antecipadamente ou registados durante a compilação. Caso contrário, ambos podem trabalhar corretamente e obter resultados diferentes. [1] [2]

Uma diferença não significa necessariamente que alguém alterou o funcionamento do programa. O compilador pode incluir o caminho da pasta de trabalho na informação usada para investigar erros. Se cada programador guardar o projeto num local diferente, os ficheiros podem diferir. Um caminho prescrito ou uma forma suportada de uniformizar os caminhos pode resolver o problema. Essa regra tem de ser uma parte conhecida do procedimento. Apagar diferenças inexplicadas depois de uma verificação falhada, apenas para obter uma correspondência, retira sentido à verificação. [3]

Uma assinatura digital permite verificar se um ficheiro corresponde a uma assinatura criada com a chave relevante. Associar essa chave ao fabricante é outra parte da confiança envolvida. A compilação reproduzível responde a uma pergunta diferente: corresponde o ficheiro ao código-fonte definido? As duas verificações complementam-se. Porém, a atualização oficial pode conter dados de assinatura ausentes da compilação local. Comparar os ficheiros completos sem conhecer o formato pode, por isso, revelar uma diferença mesmo quando o programa foi compilado corretamente. [5]

A documentação Trezor descreve a seleção da versão e do modelo, a compilação do firmware e a comparação com o ficheiro oficial. Como o resultado local não está assinado da mesma forma que a publicação do fabricante, o procedimento começa por colocar a zero campos de assinatura rigorosamente definidos. Os formatos antigos também diferem nos cabeçalhos, as partes iniciais dos ficheiros com informações sobre eles. A estrutura depende do modelo e da versão: não se pode aplicar a outro dispositivo uma instrução sem primeiro verificar a sua adequação. A assinatura original verifica-se separadamente; comparar cópias ajustadas não substitui esse controlo. [5]

Primeiro é necessário confirmar que foram comparados a mesma revisão, o mesmo modelo e a mesma variante de firmware. Seguem-se as ferramentas, bibliotecas e transformações prescritas para o ficheiro. Os originais e o registo das diferenças devem ser preservados. A causa pode ser um erro do ambiente ou das instruções, mas também uma alteração do programa distribuído. A divergência, por si só, não identifica responsáveis nem causas. Até ser explicada e a verificação repetida, não se deve declarar a compilação verificada. [1] [4]

Se o código publicado já tiver um erro, cada nova compilação pode reproduzi-lo fielmente. Um compilador comum não fiável também pode inserir a mesma alteração maliciosa em todos os resultados; voltar a usá-lo não equivale a verificá-lo de forma independente. Componentes binários fechados limitam o que pode ser reconstruído a partir do código disponível. E um ficheiro coincidente no computador não prova que uma carteira concreta é autêntica ou executa aquele firmware. Verificar a origem do ficheiro é uma parte importante da segurança, não uma prova completa. [6] [1]

Um relatório que diz «verificado» torna-se útil quando identifica quem fez a verificação, que revisão compilou, para que modelo e segundo que procedimento. Deve indicar os ficheiros comparados, a função de hash, os resultados e o tratamento exato dos dados de assinatura. Outras pessoas podem então examinar ou repetir o trabalho. Mais compilações independentes reduzem a dependência de um único distribuidor. Continua a ser necessário analisar o código, o processo de atualização e o próprio dispositivo. [2] [4]