Reproducible Firmware Build

メーカーは、プログラマーが読めるソースコードを公開できます。しかし、ウォレットに通常インストールするのは、機械が処理する形になった完成済みのファイル、いわゆるバイナリです。両者をつなぐ工程がビルドです。独立した人がその工程を繰り返し、配布されたファイルと比較します。調べるのは、データの単位であるバイトが一致するかどうかです。内容から計算される指紋のような値、暗号学的ハッシュを使うこともあります。検証の対象はファームウェアなど指定された出力であり、作業ファイルやログまで自動的に含むわけではありません。 [1] [4]

二人の開発者が一つの更新を検証すると考えてみましょう。プロジェクト名だけでは不十分で、コードの正確な版を指定する同じ commit が必要です。利用するライブラリと、コードを機械向けの形に変換するコンパイラのバージョンも必要になります。コンパイラのオプション、関係する環境設定、ウォレットの機種も手順の一部です。こうした情報は事前に決めるか、ビルド時に記録しなければなりません。そうしないと、二人とも誠実に作業していても結果が異なることがあります。 [1] [2]

違いがあるからといって、必ずプログラムの動作が改変されたとは限りません。コンパイラは、不具合を調べるための情報に作業フォルダのパスを書き込むことがあります。二人が別の場所にプロジェクトを置けば、それだけでファイルが変わり得ます。指定のパスを使う、または対応した方法でパスを統一することが解決策になります。その処理は、あらかじめ分かっている手順の一部である必要があります。検証に失敗した後で、説明できない違いを消して一致させるのでは意味がありません。 [3]

デジタル署名では、そのファイルが対応する鍵で作られた署名と一致するかを確認できます。その鍵をメーカーのものだと判断することも、信頼の別の要素です。再現可能なビルドが調べるのは、ファイルが指定のソースコードに対応するかという別の問題です。二つの確認は補い合います。ただし、公式の更新にはローカルのビルドにない署名データが入っていることがあります。形式を理解せずファイル全体を比較すると、プログラム自体は正しくビルドされていても不一致になります。 [5]

Trezor の文書は、バージョンと機種の選択、ファームウェアのビルド、公式ファイルとの比較を説明しています。ローカルの結果にはメーカーの配布物と同じ署名がないため、比較前に厳密に指定された署名フィールドをゼロにします。古い形式では、ファイルの情報を収める先頭部分であるヘッダーにも違いがあります。構造は機種とバージョンによって変わるので、ある機器の手順を別の機器にそのまま適用することはできません。元の署名は別途検証します。調整したコピーの比較は、署名の検証を置き換えません。 [5]

まず、同じコードの版、機種、ファームウェアの種類を比較していたかを確認します。その後で、道具、ライブラリ、指定されたファイル変換を調べます。元のファイルと、見つかった違いの記録は残す必要があります。原因は環境や手順の誤りかもしれず、配布プログラムへの変更かもしれません。不一致だけで原因や責任者を特定することはできません。違いが説明され、検証をやり直すまでは、確認済みのビルドと呼ぶべきではありません。 [1] [4]

公開コードにすでに欠陥があれば、何度ビルドしてもその欠陥が忠実に再現され得ます。共通の信頼できないコンパイラが、すべての結果に同じ悪意ある変更を加える場合もあります。そのコンパイラをもう一度使うことは、道具そのものを独立して検証することではありません。非公開のバイナリ部品があれば、公開コードから再構築できる範囲も限られます。さらに、コンピューター上のファイルが一致しても、手元のウォレットが本物か、そのファームウェアを実際に実行しているかは分かりません。ファイルの由来の確認は安全性の重要な一部ですが、完全な証明ではありません。 [6] [1]

「検証済み」という報告は、誰が、どのコードの版を、どの機種向けに、どの手順でビルドしたかが分かってこそ役立ちます。比較したファイル、ハッシュ関数、結果、署名データの正確な扱いも必要です。その記録があれば、ほかの人が調べたり作業を繰り返したりできます。独立した検証者が増えるほど、一つの配布元への依存は小さくなります。それでも、コード、更新方法、機器自体の確認は必要です。 [2] [4]