Secure Boot 解説！ 署名への道のり

x86_64 向けにUEFI Secure Boot 環境下でブートできる shim を署名してもらうための苦労話

Transcript

1. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Linux を安全にブートする Secure Boot 解説！ 署名への道のり 2022/12/21 サイバートラスト株式会社 弦本 春樹
2. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. 2 Secure Boot とはどんな機能なのか？
3. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 3 • Windows 8 がリリースされた、2012年ごろから仕様に追加された UEFI の一機能 – UEFI 2.3.1 からSecure Boot について定義された[1] • 信頼された認証局によって署名されていないコードの起動をブロックする – この機能で保護される範囲は？ • ブートローダー • カーネル、カーネルモジュール • UEFI アプリケーション 等... – 信頼された認証局とは？ • マザーボードのベンダーが組み込む証明書によって決まる – どんなメリットがあるの？ • 低レイヤーで動作するマルウェアの起動をブロックできる – 例えば 攻撃者によって悪意を持って改変されたブートローダーを導入された場合、 OSから上のレイヤーでは悪意 ある動作をブロックしようがない、起動時点でマルウェアはすでに動作しているから。 Secure Boot とは？ [1]: https://uefi.org/press-release/UEFI_Forum_Releases_UEFI_2.3.1_Specification_Update_and_Schedules_July_3_2012 = Only “trusted” code executes
4. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 4 • 2012年〜2013年頃にこの機能が導入されるに当たって、Windows 以外のOSの界 隈では大論争が起こった • なぜなら – ほぼすべての市場に出回るマザーボード に搭載される共通キーは事実上 Microsoft の証明書の みである • “Microsoft Windows UEFI Driver Publisher” という名義 – Microsoft は Windows Certificate をハードウェアに対して認証するにあたって、デフォルトで Secure Boot が enable であることを求めている Secure Boot の厄介な点[1]
5. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 5 • このことによって、Linux・*BSD・その他Windows 以外のOS はデフォルトではブート 不可能な状態になりかけていた。 • ハードウェアベンダーに証明書を組み込んでもらう、ユーザーに自身で MOK(Machine Owner Key) に証明書を登録してもらう などの回避策はあるが前者 はOSベンダーが自身でハードウェアベンダーでもある場合を除いて非現実的、後者 はユーザーがOSを導入する敷居を引き上げることになる。 Secure Boot の厄介な点[2]
6. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 6 • 経緯や議論を省くと Secure Boot に対応したいOSベンダーは Microsoft(以下MS) から First-stage ブートローダーである shim に署名を貰う。 • MSの署名を貰った shim から ベンダー自身の証明書を使って署名したgrubを起動 →カーネルを起動と複数のステージを経てブートする。 その後
7. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 7 • Linux のブートローダーって grub じゃないの？ – これは今でも正しいですが、UEFI 環境では 前段に shim が挟まります。 shim が挟まった場合、grub は Second-stage bootloader という位置づけになります。 • shim は何をするの？ – grub のデジタル署名を検証することで、ベンダー(Linux ディストリビューションの場合は、ディストリビュー ター) によってビルドされており、改変がされていないことを確認します。 – 最近は SBAT という仕組みで UEFI側とは独立して revocation(失効) をしたりします。 – 改変されていたり、署名が無かったり、脆弱性があるブートローダーを弾く機能以外はほとんど何もしません、 検証が終了すると 直ちに初期化処理を grub に引き渡します。 • kubernetes 周りにも似た名前のソフトウェア(Dockershim)があるけど関係ある？ – 関係ありません。 • 自分でビルドしたカーネル/ブートローダーを対応させたいけど、いい方法ある？ – 自身で所有するマシンなら MOK を使う方法があります。 • Archlinux とか Linux Mint とか *BSD で Secure Boot が使えないのは何故？ – Secure Boot 対応がスコープ外か、リソース不足で追従できていないのだと思います。 shim Q&A ※ revocation: 一般に署名された対象の有効性を失わせる作業 (失効) Secure Boot においては、対象バイナリに脆弱性が発見されたり・発行元の秘密鍵が漏洩した場合、 対象バイナリのハッシュ値を dbx リストなどに追加して、失効できる。
8. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 8 ⑤ ベンダー署名(自前)を 確認 ⑥ 初期化処理 ⑦ カーネルを起動 grub2 shim UEFI ③ ベンダー署名(自 前)を確認 ④ grub2を起動 Vendor’s CA Vendor’s CA Microsoft’s UEFI CA それぞれのコンポーネントの関係 init UEFI ブートローダー Linux カーネル ① MSの署名を確認 ② shim を起動 First-stage bootloader Second-stage bootloader OS Signature Signature Signature /boot/efi/EFI/[VENDOR]/shimx64. efi /boot/efi/EFI/[VENDOR]/grubx64. efi /boot/vmlinuz-*
9. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 9 • Linux カーネルやSecond-stage ブートローダーの grub2 をベンダー(要は自分)の証 明書で署名する。 – pesign というユーティリティを使って署名できます。証明書は openssl コマンドから生成できます。 – 例えば 署名されたカーネルはこのように署名を確認できます 実際のもうちょっと細かい手順は？[1]
10. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 10 • 自分でビルドした shim をコミュニティのレビューに提出する • Microsoft の Hardware Developer Center に shim を提出する。 • 前者のレビューが accepted になったら、後者に コミュニティでOK貰ったむねをMSに 伝える。 • MS が OKすれば署名されたブートローダー(shim) が取得可能になる。 実際のもうちょっと細かい手順は？[2]
11. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 11 ピアレビューを行う場所がGitHub上に存在する rhboot/shim-review https://github.com/rhboot/shim-review/
12. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. 12 現実の課題の話をします
13. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 13 • ともかく shim-review というコミュニティから 自分でビルドした shim をレビューして貰 う必要がある • 課題 – Accept を貰うための要件が明確ではない – レビューがどう見てもスタックしている 道のり
14. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 14 ⑤ ベンダー署名(自前)を 確認 ⑥ 初期化処理 ⑦ カーネルを起動 grub2 shim UEFI ③ ベンダー署名(自 前)を確認 ④ grub2を起動 Vendor’s CA Vendor’s CA Microsoft’s UEFI CA それぞれのコンポーネントの関係 init UEFI ブートローダー Linux カーネル ① MSの署名を確認 ② shim を起動 First-stage bootloader Second-stage bootloader OS Signature Signature Signature 一番難しい部分
15. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 15 • レビューを通過するには一定の基準を満たす必要がある • レビュー提出時に多数の質問項目があるが、実際にどう整えていればいいのかについて はあまり明確なことは書かれていない – 例: 秘密鍵の管理について • 明確に HSM(Hardware Security Module) を使って署名されているべきとは書かれていない – が、Microsoft 側のドキュメントには HSMを使うべきといったことが書かれている – こういったことは自分で探すか、先達が提出している内容を真似る必要がある (真似る場合はそれが正しいとは限らない ) » 他の方法でセキュリティを確保できるなら、 OKな場合もあるようで悩ましい (Ubuntu は複数台のコンピューターに秘密鍵 を分散保存しているらしい ) – 例: 脆弱性の対応について • あなたの使う(起動させる)カーネル/ブートローダーではこの脆弱性は修正していますか？このパッチは適用しています か？ というような項目がいっぱいある – 大量にあるため、レビュイーもレビュアーもこの確認はかなり手間 – バージョンや カーネルコンフィグ によっては、N/A, Not applied が正しい回答のこともある – 裏取りが大変 • そのためレビュアー(ボランティア)も手探りでやっている 課題1: Accept を貰うための要件が明確ではない
16. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 16 • Accept されるためには権限のあるレビュワーからのOKを貰う必要がある • ただし、権限のあるレビュアーの数は少ない – 観察している限り 3人しかいない(内訳: Red Hat・Debian・Canonical) • レビュー待ちの状態にあるレビュー依頼は常に レビュワーのリソースより多い – SUSE(openSUSE/SUSE Linux Enterprise Server) ですら月単位で待たされている状態 • shim/grub2 に重大な脆弱性が発見されると、一斉に新しいレビュー依頼がオープンされ る → 結果、ますますスタックする • (Accept する権限は無いが) ピアレビュー(要は露払い)の一環としてレビューを行いコメントをしたこと がありますが、一件見るのに2〜3時間くらいはかかる。 • レビュー依頼の中には、明らかに駄目だろこれ……(質問の回答と提出されたバイナリの データが違っていたりなど)というのもあり、ノイズになる • 年単位で見ると徐々に改善しているが、基準を満たせば 誰がも簡単にサインを貰えると はいい難い状態が続いている 課題2: レビューがどう見てもスタックしている
17. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 17 レビュー依頼の実例(1) https://github.com/rhboot/shim-review/issues/196
18. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 18 レビュー依頼の実例(2) July 12 → August 16 最初の質問まで およそ 1ヶ月待ち 最終的なリードタイムはもっと長くなる https://github.com/rhboot/shim-review/issues/263
19. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. Copyright© Cybertrust Japan Co., Ltd. All rights reserved. 19 • 現在の Linux ディストリビューションは Secure Boot 対応していると、低レイヤーのマ ルウェアからブートローダーを保護できるため望ましい • ただし、正しく署名された shim を入手するのは結構(かなり？)難しく、待たされること もある – もともと、shim を前段にはさむのは 特定のディストリビューションだけが不公平な特権を持たない ようにする仕組みだった。 – 基準を満たしていれば みんな、簡単にSecure Boot 対応できるようになっていると嬉しいが 理想 と現実が離れている まとめ
20. 公開 Copyright Cybertrust Japan Co., Ltd. All rights reserved. 信頼とともに ソフトバンク・テクノロジー グループ ソフトバンク・テクノロジー エムソリューションズ フォントワークス 環 サイバートラスト モードツー アソラテック リデン