← すべての記事2026年8月25日

再現可能なビルド：検査したソフトウェアが実行されているソフトウェアであることを証明する

スイスが投票ソフトウェアのソースコードを公開し、誰もが検査できるようにしました。しかし研究者たちは直ちに、完璧に見える証明を作成する一方で投票を静かに改ざんできる隠された裏口を発見しました。

2019年3月、ベルンでスイス郵便が民主主義の透明性の理想を体現するようなことを行っています。スペインのベンダーScytlが構築し、スイスの拘束力のある連邦投票での使用を予定していたインターネット投票システムの完全なソースコードが、世界中の誰もが読むためにオンラインで公開されようとしていたのです。

これは民主主義擁護者たちが何年もの間求めてきたことです。ブラックボックスを開く。専門家に見てもらう。検査を通じた信頼。

数週間以内に、3人の独立した暗号学者——サラ・ジェイミー・ルイス、オリヴィエ・ペレイラ、ヴァネッサ・ティーグ——が検査しました。そして彼らが発見したのは心強いものではありませんでした。

誰かが見るまで誰も気づかなかった裏口

このシステムの中核は数学的証明でした。すべての投票が混合・シャッフルされて匿名性が保たれた後、ソフトウェアは暗号化された「シャッフル証明」——シャッフルが正しく実行され、投票が改ざんされていないことを、検証する者が確認できるはずの数学的断片——を生成するはずでした。

これはユニバーサル検証可能性と呼ばれていました。考え方はこうです。サーバーを信頼する必要はない。証明を自分で確認する。

研究者たちが発見したのは、この証明が「トラップドア・コミットメント・スキーム」と呼ばれるものに基づいていたということです。平たく言うと：シャッフル証明は、投票が静かに改ざんされていても、トラップドア値を知っていれば検証に「合格」することができたのです。そしてトラップドア値はシステムの運用者が保有していました。

言い換えれば、その値を知っている当局者は、シャッフル証明トランスクリプトを生成して検証に合格させながら、すべてのバロットを並べ替えることができました。「ユニバーサル検証可能性」という主張は外部からは反証不可能だったのです。

彼らは論文に*「Ceci n'est pas une preuve」*（これは証明ではない）と名付けました。

スイス郵便とScytlはこの発見を認めました。スイス当局はシステムを中断しました。

その教訓は技術的に聞こえます。しかし、そうではありません。 この欠陥はコードがクローズされている限り見えませんでした。コードが公開された瞬間に発見可能になりました。しかし、それでも発見には世界トップクラスの暗号学者が数週間かかりました。より広い疑問——この投稿が実際に扱っている疑問——は、「誰かがコードを読むことができる」から「読んだコードがマシンで実行されているコードであることを確実にできる」までの間に何が起こるのか、ということです。

スイスのケースはコードの扉を開きました。しかし、オープンソースであっても自動的には閉じられない、さらに深い隙間を露呈させました。

レシピを読むことは料理を食べることと同じではない

レストランがレシピを公開していると想像してください。すべての材料、すべてのテクニック、すべてのステップ——すべてオンラインで、常に公開されています。

それでは、厨房は鍵がかかっていると想像してください。何が起こるはずかは読むことができます。何が実際に起こるかは見ることができません。

これがまさに、ほとんどの投票ソフトウェア、オープンソースの投票ソフトウェアであってさえも、直面している状況です。ソースコードを公開することは独立検証の必要条件です。しかし十分条件ではありません。

理由はこうです。リポジトリで読むソフトウェアは、マシンで実行されるソフトウェアではありません。「ソースコード」と「実行中のプログラム」の間には、一連のステップがあります：

コンパイラがソースコードを取得し、機械が読める二進コードに変換します。
その二進ファイルはパッケージ化され、投票ハードウェアやサーバーにインストールされ、暗号化されて封印されます——されないかもしれません。
選挙の時点で、マシンはそこにあるものをブートして実行します。

これらのステップのそれぞれが、実行中のコードが検査したソースコードから逸脱でき、目に見える証拠なしに行われる場所です。コンパイラは操作されて、ソースに表示されないコードを挿入することができます。二進ファイルはビルド後にスワップされることができます。マシンは、あなたがロードされていると思っていたバージョンとは異なるバージョンをブートすることができます。

スイスの裏口はソースコードにありました。しかし、別の裏口はその鎖のどこにでもあり得ます——そしてコードにはまったく表示されないかもしれません。

再現可能なビルドの問題を平易に言うと

ソフトウェア工学には再現可能なビルドと呼ばれる分野があります。その目的は簡単です：同じソースコード、同じコンパイラ、同じビルド命令を使って、ビルドプロセスを実行する誰もが、毎回——バイト対バイト、ビット対ビット——同じ二進ファイルを得る必要があります。

これが重要なのは、確認する方法を与えるからです。選挙当局がバイナリハッシュ——マシンのソフトウェアの一意なデジタルフィンガープリント——を公開し、公開されたソースから正確に同じ二進ファイルを独立して再現できれば、マシン上のコードが読んだコードであるという暗号学的保証が得られます。

二進ファイルが一致しなければ、ソースとマシンの間で何かが変わったことがわかります。何が変わったのかはわかりません。しかし、質問をすべき理由を知っています。

再現可能なビルドがなければ、「検査されたソース」と「実行中のソフトウェア」の間の隙間は見えません。それを確認するツールがありません。ビルドを行った当局を信頼する立場に戻ります。

Reproducible Buildsプロジェクト——ソフトウェアエンジニアリングコミュニティにおける横断的な取り組み——は、これがいかに達成しにくいか、また同じソースから異なる出力を生成できるビルドチェーンがいかに多くの方法を持つかを体系的に文書化しています。コンパイラはタイムスタンプを埋め込みます。リンカーは環境変数を挿入します。ファイルの順序は異なります。それぞれが、2つの「同一の」ビルドが誰も詐欺を意図しないまま異なるバイナリを生成するメカニズムです。

認証：問題の第2部分

ビルドが再現可能であっても、第2の問題が残ります。再現可能性は、誰かがソースから同じ二進ファイルを再構築できることを証明します。投票マシンで実行されている二進ファイルがその二進ファイルであることは証明しません。

ここで認証が登場します。

認証は、暗号化された請求に署名するプロセスです：「このデバイスはバイナリXを実行しており、時刻Tにビルドされ、ハッシュHです。」署名は、ブート後にソフトウェアで上書きできない、理想的にはトラステッドプラットフォームモジュール（TPM）またはハードウェアセキュリティモジュールなどのハードウェアから来る、改ざん明白なものから来なければなりません。署名された請求は、公開鍵を持つ誰もが確認できます。

それはメモリカードの改ざん明白なシール——開くと破れる物理的なシールの代わりに、カードを手渡した人を信頼することなく検証できる数学的署名——のようなものと考えてください。

一緒に、再現可能なビルドと認証は鎖を形成します：ソースを読む→それをビルドしてバイナリHを取得する→実行デバイスがバイナリHに認証されていることを検証する→マシンが読んだコードを実行していることに確信が持てる。

その鎖がなければ、2つの接続されていない事実があります：ここにソースコードがあるそしてここに何かを実行しているマシンがある。これら2つのものが対応しているかどうかは、検証ではなく信頼の問題です。

「認定されたオープンソースソフトウェアを実行している」は主張です。再現可能なビルドと認証は、それを確認可能にするものです。

スイスのケースがより深い問題について教えてくれること

スイスに戻ってください。研究者たちはソースコードを読んだので裏口を発見しました。スイス郵便は欠陥を認めてシステムを中断しました。ここまで：システムは意図通りに機能しています。

しかし、その話の報告されているバージョンで検査されなかったものに注目してください。裏口がソースコードに存在していなかったとしても、独立した当事者はスイス郵便サーバー上で実行されている二進ファイルが正確にそのソースからコンパイルされた——公開されたコードに決して表示されない欠陥を持つ、わずかに修正されたバージョンではなく——ことを確認するメカニズムを持っていませんでした。

これは仮説上のものではありません。2003年、コンピュータ科学者ケン・トンプソンは、チューリング賞受賞講演で、コンパイラがどのように修正されてプログラムに自動的にバックドアを挿入できるか——そしてさらに修正されてバックドアを自分自身に挿入できるか——について説明しました。クリーンなソースからコンパイラをコンパイルしても、妥協したバイナリが生成されます。ソースは無垢に見えます。コンパイラは無垢に見えます。出力はトロイ木馬化されています。

これは珍しい理論的な攻撃ではありません。これはよく理解されている脅威のクラスです。そして防御は再現可能なビルドです：出力が決定論的で公開されていれば、独立した当事者はソースからリビルドして矛盾を検出できます。されていなければ——無害な技術的理由で毎回ビルドが異なるバイナリを生成していれば——比較を行うことができません。

スイスのケースはオープンソースがクローズドソースより優れていることを証明しました。また、オープンソース単独では十分ではないことも証明しました。

ギャップ追跡ツールが監視しているギャップ

TrustVotingでは、具体的なギャップを追跡しています：ほとんどの配備投票システムに見られる、公開検証された再現可能なビルドとデバイス認証の不在です。このギャップがどのくらいの頻度で、どこに表示されるかを世界中で確認できます。

スイスのシステムはオープンソースを持っていました。これは民主的世界で最も透明性に配慮したインターネット投票プログラムの1つです。研究者たちはそれでも暗号化に欠陥を見つけました——クローズドシステムでは検出不可能だったでしょう。そしてその欠陥が見つかって修正された後でさえ、独立した観測者は、サーバー上のパッチされたバイナリがパッチされたソースから派生したことを確認するメカニズムを持っていません。

これがギャップです。それは読むことができるコードと実際に投票を処理するソフトウェアの継ぎ目に正確に位置しています。

それを閉じるでしょう何かのいくつか：

公開されたビルド命令は、当局が実行されていると主張する正確なバイナリハッシュを生成します——十分な技術を持つ観測者が独立して検証できるように。
改ざん明白なハードウェアからの署名付き認証各投票デバイス上で、各結果バッチとともに実行中バイナリのハッシュを公開します。
展開後の継続的で継続的な監視公開されたハッシュに対する——ソフトウェアスワップが認証後だが選挙前に行われた場合、それが検出可能になるように。

これらのどれもが異国的ではありません。それらは高セキュリティソフトウェア配備の標準的な実践です。それらは投票システム認証要件から大部分が不在です。

あなたが今日検証できないこと——そしてそれを修正するでしょう何か

2019年のスイスの後、私たちが残されている不快な位置はここにあります。

オープンソースが優れていることを知っています。裏口はコードが読める正確だったので見つかりました。クローズドシステムは欠陥を検出されないまま出荷していたでしょう。

暗号化検証可能性が紙の証跡だけより優れていることを知っています。スイスのシステムの設計哲学全体——ユニバーサル検証可能性、数学的にチェック可能な証明——は、有権者が当局を信頼することなく、自分の投票がカウントされたことを確認できるようにしようとする試みです。

そして、ソースと実行バイナリの間の架け橋がなければ、両方が不十分であることを知っています。

現在、世界中に配備されているほぼすべての投票システムについて、「そのマシンのソフトウェアが検査されたソフトウェアであることをどうやって知るのか」という正直な答えは：わかりません。デプロイした当局を信頼します。

その信頼は正当かもしれません。しかし信頼は検証ではありません。ドイツの連邦憲法裁判所は2009年の判決で、電子投票は投票から結果まで本質的な各ステップを一般市民——専門家だけでなく——が独立して検証できる場合にのみ合法であることを理解していました。裁判所の論理は投票カウントと同じくらい鋭く、ソフトウェア配備に適用されます：正しいコードが実行されていることを確認することが、それを実行する人々を信頼することを必要とする場合、本質的な検証ステップは欠けています。

修正は、オープンソース投票の取り組みを取り壊すことではありません。それらを完成させることです。オープンソースプラス再現可能なビルドプラス署名付き認証プラス公開されたバイナリハッシュは、「検査したソフトウェアが実行されたソフトウェアである」がノートパソコンと好奇心を持つ誰もが確認可能である——それをデプロイした当局だけではなく——システムに等しいです。

その鎖が閉じられるまで、すべての「私たちはオープンで認定されたソフトウェアを使用しています」という主張は信頼への招待です。そしてあなたにそれを信頼するよう求め、証明を見せる代わりに選挙システムは、問題の解決を完了していません。

投票システム追跡における再現可能なビルドギャップがどのように表示されるかを確認する

この議論の2分バージョンを読む

選挙技術検証ギャップの世界的マップを探索する

ソース

すべての記事を表示ギャップを探索