ウォレットのダウンロードを検証する:チェックサム、署名、再現可能なビルド

·4 分で読める·SSP Editorial Team 著
SSP Academy カバー:ウォレットのダウンロードを検証する

ウォレットのダウンロードを検証する:チェックサム、署名、再現可能なビルド

ウォレットをインストールするとき、あなたはコンピューター上のファイルが開発者のリリースしたソフトウェアそのものであり、侵害されたウェブサイトや偽のダウンロードページから入手した改ざん版や、改ざんされたビルドではないと信頼しています。ほとんどの人にとっては、公式ストアからインストールすれば十分です。しかし、信頼するよりも自分で確認したい人のために、オープンソースのウォレットは段階的に強力になる三つの手段を提供できます。チェックサム、署名、そして再現可能なビルドです。

それぞれが何を証明するのか、そして SSP Wallet でどう使うのかを説明します。

チェックサム:同じファイルか?

チェックサムとは、SHA-256 などのハッシュ関数によって生成されるファイルの指紋です。たった1バイト変えるだけで、指紋はまったく別のものになります。ダウンロードしたファイルのチェックサムが開発者の公開したものと一致すれば、同じファイルを持っていることになります。

macOS や Linux では、ターミナルで計算できます。

shasum -a 256 ssp-wallet-chrome-v2.1.3.zip

チェックサムだけでは弱点があります。攻撃者がダウンロードページを支配していれば、ファイルと公開されたチェックサムの両方を差し替えられるのです。だからこそ次のステップが重要になります。

署名:開発者が公開したものか?

署名は、誰がチェックサムを公開したかを証明します。開発者はチェックサムファイルに秘密鍵で署名し、対応する公開鍵を持つ人なら誰でもその署名を検証できます。ファイルやチェックサムを改ざんした攻撃者は、その秘密鍵がなければ有効な署名を作れません。

唯一確実に正しくしなければならないのは、公開鍵そのものです。プロジェクトの公式な入手元から取得し、その指紋を複数の公式チャネルで照合し、以後はすべてのリリースで同じ鍵を使ってください。

再現可能なビルド:このファイルは本当に公開コードからビルドされたのか?

署名が証明するのは誰がファイルをリリースしたかであって、中身が何かではありません。開発者のビルドマシンが侵害されていれば、悪意ある成果物に善意で署名してしまう可能性があります。

再現可能なビルド(決定論的ビルドとも呼ばれます)は、その隙間を埋めます。ビルド工程が固定されているため、同じソースコードからはどのマシンでも常にバイト単位で同一のファイルが生成されます。誰でも公開コードからリリースを再ビルドし、チェックサムを比較できます。一致すれば、リリースされたファイルにはソースコードに書かれている内容だけが含まれ、それ以外は何も含まれていないことになります。サプライチェーン攻撃と決定論的ビルドでは、これがウォレットにとってなぜそれほど重要なのかを解説しています。

SSP Wallet を検証する

GitHub(RunOnFlux/ssp-wallet)上の SSP Wallet のリリースは、Chrome 用と Firefox 用が決定論的にビルドされており、追加で二つのファイルが含まれています。各パッケージのチェックサムを一覧にした SHA256SUMS と、その一覧に対する GPG 署名である SHA256SUMS.asc です。

1. リリースファイルをダウンロードする。 リリースページから、お使いのブラウザー用のパッケージ(ssp-wallet-chrome-v2.1.3.zip や ssp-wallet-firefox-v2.1.3.zip のような名前)を、SHA256SUMS および SHA256SUMS.asc と一緒に一つのフォルダーへダウンロードします。

2. 署名を確認する。 SSP のリリース署名用公開鍵を GPG にインポートした状態で、次を実行します。

gpg --verify SHA256SUMS.asc SHA256SUMS

GPG が想定どおりの鍵による正しい署名だと報告するはずです。不正な署名や不明な鍵と報告された場合は、そこで中止してください。

3. 一覧と照合してファイルを確認する。

sha256sum -c SHA256SUMS

macOS では shasum -a 256 -c SHA256SUMS で同じことができます。ダウンロードした各ファイルについて OK と表示されるはずです。一覧には Chrome 用と Firefox 用の両方のパッケージが含まれています。片方だけをダウンロードした場合は、もう片方が欠落と報告されないよう --ignore-missing を追加してください。

4. 必要に応じて、自分でビルドする。 リリースタグの時点でリポジトリをクローンし、決定論的ビルドを実行します。

git clone https://github.com/RunOnFlux/ssp-wallet.git
cd ssp-wallet
git checkout <release-tag>
yarn build:deterministic

ビルドは固定された Docker 環境で実行され、独自の SHA256SUMS を書き出します。あなたのチェックサムが公開されたものと一致すれば、そのリリースがそのソースコードからビルドされたことを独自に確認できたことになります。

ブラウザーのストアはどうか?

ほとんどの人は SSP Wallet を Chrome Web Store や Firefox Add-ons からインストールしており、それは妥当な選択です。ストアからのインストールは自動で更新され、ストアには独自の審査プロセスもあります。上記のチェックサムは、GitHub 上のリリースパッケージを対象としたものです。ストアからインストールする場合、最も重要な確認はもっと簡単です。公式ウェブサイトからストアのページにたどり着いたこと、そして公開元が一致していることです。偽のウォレットアプリを見抜くではその手順を、ブラウザー拡張機能の衛生管理ではその後ブラウザーを安全に保つ方法を解説しています。

率直なまとめ

チェックサムは同じファイルを持っていることを、署名は誰がそれを公開したかを、再現可能なビルドはファイルが公開コードから生まれたことを証明します。各ステップは、それぞれ異なる種類の信頼を不要にします。

ほとんどの人は公式ストアからインストールするでしょうし、それで問題ありません。自分で検証したい場合、SSP Wallet のリリースには三つの手段がすべてそろっています。署名付きのチェックサム一覧、1行で済む確認、そしてバイト単位で再現できるビルドです。

この記事をシェアする

関連記事