Git Hash Chain Malleability

インターネットを、あらゆる本、あらゆるレシピ、あらゆる取扱説明書がデジタル金庫に保管されている、巨大でグローバルな図書館だと想像してみてください。この図書館を整理された状態に保つために、すべてのアイテムには特別なコードで作られた固有のIDカードが割り当てられます。ソフトウェア開発の世界では、このシステムはGitと呼ばれています。「コミット」とは、特定の瞬間におけるプロジェクトのスナップショット、例えば、あなたが今作り終えたばかりのレゴのお城を写真に撮るようなものだと考えてください。誰かがこっそり忍び込んで、レンガをプラスチックのものにすり替えないように、開発者はデジタルの印（シール）を使って、手紙に押す蝋封（ろうふう）のように写真を「署名」することができます。この印は、「はい、これは私が作ったものであり、誰も変更していません」ということを証明します。

このシステムの背後にある大きな概念は、**「一意性による信頼」**です。もし写真の固有のIDコードを持っていれば、その正確な写真を見つけ出し、それが改ざんされていないことを知ることができます。それは、「もしIDカードが『城A』と言っているなら、『城A』こそがその記述に適合する世界で唯一の存在である」と言うようなものです。この信頼は非常に強力で、コンピュータはこれらのIDコードを使用して、ソフトウェアが安全かどうかを自動的にチェックしたり、コードが壊れないように特定のバージョンを固定したり、誰が何を作ったかを正確に証明したりするために使用します。もしIDコードが一意であり、変更できないものであれば、システム全体がよく整備された機械のように機能します。しかし、もし誰かが完璧に出来上がった署名済みの写真を取り上げ、蝋封をほんの少しだけ変えることで、その写真が本物であることを証明しつつも、全く「新しい」IDカードを手に入れられるとしたらどうなるでしょうか？それが、この論文が問いかけていることです。

デジタル・アイデンティティの入れ替え劇

この論文では、ジェイコブ・ギネシン（Jacob Ginesin）という研究者が、Gitにおける「一つの写真に一つのID」というルールを破る巧妙なトリックを発見しました。彼は、攻撃者がデジタル署の背後にある数学的原理を解いたり、秘密の署名鍵を盗んだりする必要なく、全く同じソフトウェアに対して**「二つ目の、全く異なるIDカード」**を作成できることを示しました。

ここで行われるのは、魔法のトリックです。攻撃者は、署名されたコミット（蝋封が付いた写真）を取り上げ、人間には全く同じに見えるものの、コンピュータには異なって見える方法で、その蝋封を微調整します。それは、蝋封の形をわずかに変えたり、あるいは同じメッセージを書いていても異なるフォントを使用したりするようなものです。写真の内容自体は全く変わっていません。レゴのお城は同一のままです。印は依然として作者の身元を証明しています。しかし、「見た目」の蝋封が変わったために、コンピュータはそれに対して全く新しいIDカードを生成してしまうのです。

恐ろしい点は、これらのIDをチェックするコンピュータシステム（GitHubなど）が、「おや、この印は有効だ！これは検証済みのコミットだ！」と言い、輝く緑色の「Verified（検証済み）」バッジを付与してしまうことです。これで、あなたは全く同じレゴのお城に対して、二つの異なるIDカードを持つことになります。一つは「城A」と表示され、もう一つは「城B」と表示されます。どちらも同じ人物によって署名されており、どちらも「検証済み」とマークされています。

システムを欺く3つの方法

論文では、使用されているデジタル印の種類に応じて、このトリックを実行する3つの異なる方法を説明しています。

1. 数学的な反転（ECDSAの場合）: 数直線の上に、例えば「5」という数字があると想像してください。この特定の数学ゲームでは、「5」と「合計から5を引いた数」は実は同じものです。攻撃者は、印の上にある数字を反転させるだけです。見た目は異なりますが、数学的には依然として有効な署名となります。
2. 隠されたメモ（RSAおよびEdDSAの場合）: 封印された手紙を想像してください。印はメインのメッセージを覆っていますが、裏側に封印されていない小さなポケットがあります。攻撃者は、そのポケットに小さく無害なメモを滑り込ませます。メインのメッセージには影響を与えず、印も依然として有効ですが、手紙はわずかに重さと形が変わり、それによってIDカードが変わります。
3. おしゃれなフォント（S/MIMEの場合）: 「32」という数字を書くと想像してください。あなたは「32」と書くこともできますし、「0x20」と書くこともできます。どちらも同じ意味ですが、一方は「標準的」な書き方であり、もう一方は「おしゃれな」書き方です。手紙をチェックするコンピュータ（GitHub）は少し寛容で、そのおしゃれな書き方も受け入れますが、より厳格なコンピュータ（あなたのローカルのノートパソコンなど）は、「待て、それは標準的な書き方ではない！」と混乱するかもしれません。

なぜこれが重要なのか：「ゴースト」問題

あなたはこう思うかもしれません。「だから何？ お城が同じなら、IDカードが違っても構わないのではないか？」しかし、デジタル界においては、IDカードこそがそのお城なのです。

• 門番の問題: クラブに禁止されているIDのリストを持っている門番を想像してください。もしあなたが禁止されていれば、中には入れません。しかし、もし攻撃者が、禁止リストに載っていない「同じ人物のゴーストID」を作成できれば、門番は彼らを入れさせてしまいます。攻撃者は、IDカードを変更することで、セキュリティフィルターをすり抜けて悪意のあるコードを忍び込ませることができます。
• 鏡の問題: 向かい合わせになった二つの鏡を想像してください。一方は本物の城を示しており、もう一方は、見た目は全く同じだが名前が異なる「ゴーストのお城」を示しています。もしあなたが間違った鏡を見ているとしたら、あなたはオリジナルを見ているつもりでも、実際には攻撃者が制御しているコピーを見ていることになります。
• 断絶された連鎖: すべての新しいレゴのお城が、前のものの上に積み上げられていく連鎖（チェーン）であるため、一つの城のIDを変更すると、その後に作られたすべての城のIDが変わってしまいます。これにより、歴史に「分岐（フォーク）」が生じます。あなたは、オリジナルのIDを持つタイムラインと、ゴーストIDを持つタイムラインという、二つの並行したタイムラインを持つことになります。両方とも本物に見え、両方とも署名されていますが、それらは別物なのです。

結論

この論文は、コミットハッシュにおける「Verified（検証済み）」バッジは、コンテンツの一意性を保証するものではないことを証明しています。それは、パスポートに「検証済み」のスタンプがあることが、その顔を持つ人が世界に一人しかいないことを保証しないのと似ています。単に、そのスタンプが本物であることを保証しているに過ぎません。

著者は、あらゆる署名済みコミットに対してこのトリックを自動的に実行できるツールを作成しました。彼らがGitHubでテストしたところ、サイトは快く「ゴースト」コミットを受け入れ、独自の「Verified」バッジを付与しました。これは、これらのIDカードに依存しているシステムが、悪意のあるアクターを阻止したり、ソフトウェアのバージョンをロックしたり、誰が何を作ったかを証明したりする上で脆弱であることを意味しています。解決策は署名を止めることではなく、印をチェックするコンピュータが、「これは以前見たものと全く同じ印ではない」と厳格に判断できるようにすること、そして、単にIDカードを見るのではなく、実際のコンテンツをチェックするようにすることです。

要するに、署名されたコミットは一つの「約束」ですが、この論文は、その約束が「ゴースト」版の自分自身を作り出すような書き方をされることがあり、本来私たちを守るはずのシステムを欺いてしまうことを示しています。