Canonicalの開発者Gianpiero Carpinelli氏が、DebianやUbuntuのパッケージ管理に使われるAPT（Advanced Package Tool）へ、SHA3-256とSHA3-512の対応を追加するマージリクエストを提出した。狙いは、長期間運用されるUbuntuの端末に、将来別のハッシュ関数へ移行するための選択肢をあらかじめ持たせることだ。
9月29日に提出され、10月2日に更新された提案は、10月4日時点ではまだ統合されていない。端末側がSHA-3を検証できるようになっていれば、将来配布側がハッシュ方式を変更する必要が生じたとき、既存端末への対応が移行の障害になりにくい。今回の変更を理解するには、端末がSHA-3を扱えるようになることと、DebianやUbuntuの配布サーバーが実際にSHA-3へ切り替えることを分けて考える必要がある。
SHA-3を扱えるようにすることと、実際に採用することは別
今回の提案では、APTのライブラリlibapt-pkgに、SHA3-256とSHA3-512を読み取り、検証する機能を追加する。対象は、パッケージ配布の索引となるRelease、Packages、Sourcesだ。
配布用の索引を生成するapt-ftparchiveにも、SHA3-256とSHA3-512のハッシュ値を出力する機能を追加する。ただし、SHA-3の生成は既定では無効になっており、--sha3-256や--sha3-512、または対応する設定項目で明示的に有効にする設計だ。
今回のAPTへのSHA-3対応では、端末側の検証機能、配布用メタデータの生成、配布サーバーでの実際の採用、OpenPGP署名をそれぞれ別の問題として扱っている。
Carpinelli氏が10月2日に更新した提案と、9月29日の開発者向け説明を、役割ごとに整理すると次のようになる。
| 担当する部分 | 今回の提案で加えるもの | 利用が始まる条件・対象外の範囲 |
|---|---|---|
| 端末側のAPT | 索引内のSHA3-256・SHA3-512を読み取り、検証する機能 | SHA-3対応版APTが導入され、配布側がSHA-3のハッシュ値を掲載した場合に利用される |
apt-ftparchive |
SHA-3のハッシュ値を索引へ出力する機能 | 管理者が生成オプションや設定で有効にする。既定では出力しない |
| パッケージ配布サーバー | SHA-3を掲載するために必要な生成機能 | 実際にどの方式を掲載するかは配布側が決める。公式サーバーでの採用を決めたものではない |
| OpenPGP署名 | 今回の変更対象には含まれない | 署名に利用するダイジェスト方式の変更は今回の提案の範囲外 |
この表は、同じマージリクエストに含まれる機能と、今後必要になる運用上の判断を分けたものであり、すでに提供されているAPTの機能一覧ではない。
9月29日のメールではSHA-3生成を既定で有効にするかどうかも検討されていたが、10月2日に更新された現在の提案では、明示的に指定した場合だけ生成する方式になっている。議論の途中で示された案と、現在レビューされている実装を混同しないことが重要だ。
一方、端末側では、配布サーバーが複数のハッシュを掲載している場合、新しいSHA-3を優先して利用する。現在のコードで定義されている優先順位は、SHA3-512、SHA3-256、SHA512、SHA256の順だ。
ファイルのハッシュ値をURLの一部に含めて索引を取得するby-hashにもSHA-3対応が加わる。SHA-3のby-hash経路を利用できる場合はそちらを使い、必要に応じて通常のファイルパスへフォールバックする。索引をどの経路から取得するかと、その内容をどのハッシュ値で検証するかの両方をSHA-3へ対応させる変更である。
開発者の説明によると、ダウンロード時に端末が計算するのは、配布側が実際に掲載している方式のハッシュ値だけだ。つまり、端末側のAPTにSHA-3対応コードが入っただけでは、現在の配布サーバーがSHA-3を使わない限り、SHA-3の計算処理は増えない。
ただし、これはSHA-3を実際に併記した場合の処理負荷や、APT全体の性能への影響を測定した結果ではない。
APTは署名された索引からパッケージまで順番に検証する
Ubuntuの公式パッケージでは、それぞれの.debファイルだけを単独で確認して信頼性を判断しているわけではない。Canonicalのセキュリティ文書では、署名された索引から実際のパッケージまでつながる検証の仕組みを説明している。
まずAPTは、OpenPGP署名を含むInReleaseを検証する。そこには、アーキテクチャや配布区分ごとのPackages索引について、正しいファイルを確認するためのハッシュ値が記録されている。
次に、取得したPackagesファイルのハッシュ値がInReleaseに記録された値と一致するかを確認する。さらにPackagesには、それぞれの.debファイルの名前やハッシュ値が掲載されており、ダウンロードしたパッケージの内容を照合できる。ソースコードの配布でも、Sourcesを介して同様の検証が行われる。
途中のファイルだけを改ざんすれば、一つ上の段階に記録されたハッシュ値と一致しなくなる。攻撃者が索引内のハッシュ値まで変更すれば、その索引を参照する上位のファイルも変更しなければならず、最終的にはOpenPGP署名の検証に行き着く。
今回のSHA-3追加は、この検証の連鎖でファイル内容を照合するために利用できるハッシュ関数を増やすものだ。OpenPGP署名そのものに使うダイジェスト方式を変更する作業とは別になる。
ここで重要になる性質も、単に「暗号として強い」という説明だけでは十分ではない。Canonicalは、この検証方式がハッシュ関数の**第二原像耐性（second-preimage resistance）**に依存すると説明している。
第二原像耐性とは、あるファイルがすでに与えられているとき、それと同じハッシュ値になる別のファイルを見つけることが困難である性質を指す。任意の異なる二つのデータについて同じハッシュ値を見つける「衝突耐性」とは、攻撃者に与えられる条件が異なる。NISTの定義でも両者は区別されている。
また、APTの暗号学的な検証に成功することと、配布されているソフトウェア自体が安全であることも同じではない。
例えば、第三者の配布元が自分の鍵で署名したパッケージは、その鍵を利用者が信頼する設定にすればAPTで検証できる。Canonicalも第三者のパッケージ配布元について、運営者を信頼できるかどうかを利用者自身が判断する必要があるとしている。ハッシュ関数を増やしたからといって、配布元そのものへの信頼まで自動的に得られるわけではない。
長期サポートに備え、異なる設計のハッシュを先に実装する
Carpinelli氏は、Debian開発者から今回の目的を問われ、ハッシュ関数の「多様性」を確保するためだと説明している。
Ubuntu 24.04を長期間支援する間に、仮にSHA-2を安全に使い続けられない状況が生じた場合、すでに配備されている端末が別系統のハッシュ方式を理解できなければ、配布側だけを新方式へ切り替えることはできない、という考え方だ。
これはSHA-2が近く破られると予測したものではない。将来ハッシュ関数を切り替える必要が生じたとき、既存端末が新方式に対応していないこと自体が移行の障害になるため、対応機能を先に配布しておくという発想である。
配布サーバーだけを新しい方式に変更しても、古い端末がそのハッシュ値を理解できなければパッケージを検証できない。そこで通常のソフトウェア更新によって、端末側へ新しい方式への対応をあらかじめ届けておく。
問題が判明してから新方式を実装し、長期間利用されているすべての端末へ配布するところから始めるより、必要になった時点ですぐに移行できる選択肢を用意しておける。
SHA-3は、SHA-2の出力を単純に長くした方式ではない。NISTがKeccakを基に標準化した、SHA-2とは設計の異なるハッシュ関数群だ。例えばSHA-256とSHA3-256はどちらも256ビットのハッシュ値を出力するが、内部の仕組みは異なる。
同じ用途に対して異なる設計のハッシュ関数を選べることが、今回Carpinelli氏が挙げる「多様性」の意味になる。NISTの標準には現在もSHA-2とSHA-3の双方が含まれており、今回の提案を「SHA-2からSHA-3への移行開始」と受け取るのは早い。
Ubuntu LTSのサポート期間についても条件を分ける必要がある。Ubuntuの公式サポート表では、Ubuntu 24.04 LTSの標準セキュリティ保守は2029年5月まで、Ubuntu Proによる拡張セキュリティ保守は2034年5月までとなっている。Legacy add-onを利用すれば、2039年5月までセキュリティ保守とサポートを延長できる。
そのため、提案に記された「10〜12年」という開発上の動機を、すべてのUbuntu 24.04利用者に共通するサポート期間と考えるべきではない。
長期間サポートする環境ほど、同じ暗号方式を使い続ける期間も長くなる。今回準備しているのは、その期間中にハッシュ方式を変更する必要が生じた場合の選択肢だ。OpenPGP署名に使うダイジェストは今回の対象外なので、APTで使われる暗号方式全体の移行が、この変更だけで完了するわけでもない。
SHA-2とSHA-3を併記すれば段階的に移行できる
古いAPTが未知のSHA-3欄を無視できることは、段階的な移行に役立つ。
配布側がSHA-2とSHA-3を併記すれば、今回の変更に対応した新しいAPTはSHA-3を優先し、SHA-3を理解しない古いAPTは従来のSHA-2を利用できる。
ただし、その後SHA-2を削除し、SHA-3だけを掲載する段階は別の問題だ。新しい欄を無視できることは、古いAPTがSHA-3だけで構成された配布元を検証できることを意味しない。
つまり、
- まず端末側へSHA-3対応を広げる
- 配布側でSHA-2とSHA-3を併記する
- 十分な端末が対応した後、必要なら古い方式を外す
という段階を踏む余地が生まれる。
一方、ハッシュ方式を増やせば、索引ファイルに掲載する値も増える。dpkg開発者のGuillem Jover氏は9月29日の議論で、特に512ビットの方式まで追加するとメタデータの容量が増えることを指摘している。
Carpinelli氏は、仮にDebianやUbuntuがSHA-3を追加するとしても、実際にはSHA3-256だけを採用する可能性があるとの見方を示している。ただし、これは開発者個人の見通しであり、DebianやUbuntuの公式配布サーバーが採用する方式を決めたものではない。
パッケージ生成側にも課題は残る。Jover氏によると、dpkg自体でSHA-3へ対応する場合、Perlの標準構成に含まれていないDigest::SHA3への依存をどう扱うかが問題になる。
一方、今回のAPT提案では、ソースパッケージの情報ファイル.dscに必要なハッシュ値が存在しない場合でも、apt-ftparchive側でSHA-3を計算して補えるようにする。配布に関係するすべてのツールが同時にSHA-3対応することを前提にせず、索引を生成する段階で不足している値を補う設計である。
今回は「SHA-3への移行」ではなく、将来切り替えるための準備
実装上の細かな変更もある。
今回の提案ではOpenSSL 1.1.1以降をビルド要件とし、apt-ftparchiveが使うキャッシュ形式もSHA-3に対応するよう拡張する。
新しい版のapt-ftparchiveが書き込んだキャッシュは古い版では読み込めず、「Cache record size mismatch」というエラーになる。そのため、新しい版から古い版へ戻す場合はキャッシュを削除する必要がある。これはSHA-3のハッシュ値を保存する領域がキャッシュへ追加されるためだ。
また、SHA-3だけを掲載する配布元をテストする過程で、以前から存在していたapt-ftparchiveのチェックサム生成に関する二つの不具合も見つかり、今回のマージリクエストに修正が含まれている。
一つは、MD5を無効にした状態で.dscファイルに必要なチェックサムがなかった場合、Sourcesへチェックサムが生成されない問題。もう一つは、一度キャッシュされたハッシュ方式を後から無効にしても、その値が出力され続ける問題だ。
いずれもSHA-3そのものによって生じた不具合ではなく、SHA-3だけを使う構成をテストしたことで既存の問題が表面化したものになる。
現時点で確認できるのは、APT本体にSHA3-256とSHA3-512への対応を追加するマージリクエストと、その設計までだ。
どのAPTバージョンに採用されるのか、Ubuntu 24.04 LTSへバックポートされるのか、DebianやUbuntuの公式配布サーバーが実際にSHA-3を掲載するのかは、今後の判断になる。
今回の変更で直ちにSHA-2が使われなくなるわけではない。意味があるのは、必要になってから新しい暗号方式への対応を始めるのではなく、既存端末へあらかじめ対応機能を届けておくことだ。
長期間運用される端末側の準備を先に済ませておけば、将来ハッシュ方式を変更する必要が生じたとき、古い端末が対応するのを待たずに移行できる可能性が高まる。