tmygt
2024年3月4日 13時34分
お世話になっております。
SD bootを無効化するかどうか検討しています。
下記を読むと、SD bootによってセキュアブート鍵への攻撃が考えられるとあります。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
> その反面、 SD メディアの盗難や流出によってシステムへの侵入、SD boot を利用した セキュアブート鍵に対する攻撃が考えられます。
この攻撃について、下記を教えていただけないでしょうか。
1. 「セキュアブート鍵に対する攻撃」の難易度。SD boot以外に攻撃成立のための条件があるのかどうか
2. SDカード自体もセキュアブートを有効にすることは可能でしょうか? 公開情報をもとに作成したSDカードではブートできず、弊社で署名したSDカードでのみブートできる、といった機能です
3. セキュアブート鍵が攻撃された場合、そのデバイスのeMMCは暗号化していたとしても復号されてしまうのでしょうか
よろしくお願いいたします。
コメント
tmygt
マルティネさん
コメントありがとうございます。
不明点が明確になってきました。
何を要件とするかによって必要な対策が変わると思うので、まず前提を共有します。
前提として、下記を考えています。
- eMMCに書き込まれている弊社アプリケーション/設定ファイルが、eMMCを取り外すなどのHW的な解析によっても読みだされないこと
- eMMCを初期化されること、完全初期化してから別のアプリケーションを書き込まれることは許容する
- 弊社にて厳重に管理したSDカードを使うことで、eMMC領域の初期化ができること
- SDカードは厳重に管理する。SDカード流出のリスクは受け入れる
- ソフトウェア起因の不具合があった場合に、顧客のデバイスが文鎮化することは回避したい。回収+再書き込みで復旧できるようにする。
それを踏まえて、追加で質問させてください。
> 1/ 今の initrd (build-rootfs の initrd/init スクリプト）が rootfs を暗号化あり/無しの両方を対応してしまっていますし、パーティションを何も確認してませんので、rootfs パーティションを暗号化無しに入れ替えることはできます。
入れ替えですので、もともと書いてあるアプリケーション/設定ファイルを読むことはできないということですよね? それであれば、問題ありません。
> また、eMMC の imxboot/linux を使って SD カードにコピーして SD ブートが無効化されてなかった場合に SD ブートもできてしまいます。
ブートできても任意の処理の実行ができるわけではないので、eMMCの内容の確認はできないと考えているのですが、正しいですか?
(eMMCをクローン出来るだけで、書き換えができない。読んでも中身はわからない)
> 2/ uboot の環境変数領域の変更ができます。
このことで暗号化されたeMMCの中身を読むことができたり、鍵を抜けたりすると問題だと思うのですが、それは不可能ですよね?
まだ理解が追い付いていない点があり恐縮ですが、ご確認よろしくお願い致します。
tmygt
> > また、eMMC の imxboot/linux を使って SD カードにコピーして SD ブートが無効化されてなかった場合に SD ブートもできてしまいます。
>
> ブートできても任意の処理の実行ができるわけではないので、eMMCの内容の確認はできないと考えているのですが、正しいですか?
> (eMMCをクローン出来るだけで、書き換えができない。読んでも中身はわからない)
投稿してから再確認して気づいたのですが、質問1の回答の下記箇所はeMMCをクローンしたSDカードでも同様ですかね。
そうであれば、eMMCのデータから作ったSDカードのuserlandを書き換えれば、eMMCが読めるということですね。
> なので、SD カードの場合は証明された SD カードを取得できれば、userland の部分を入れ替えることで簡単に何でも起動できます。
> 暗号化もそこから複合できますので、そこから eMMC の確認や変更はできてしまいます。
at_dominique.m…
> 前提として、下記を考えています。
説明ありがとうございます。
先ほどの返事で大体同じ前提で考えていましたが、開発時点では eMMC の直接な変更の配慮が足りてませんでした。
改めて考え直してセキュリティガイドに追加の説明を追加しようと思います。
> > 1/ 今の initrd (build-rootfs の initrd/init スクリプト）が rootfs を暗号化あり/無しの両方を対応してしまっていますし、パーティションを何も確認してませんので、rootfs パーティションを暗号化無しに入れ替えることはできます。
>
> 入れ替えですので、もともと書いてあるアプリケーション/設定ファイルを読むことはできないということですよね? それであれば、問題ありません。
"rootfs" のパーティションの内容はなくなりますが、appfs の内容は読めてしまいますのでそれだけでもダメだと思っています。
> > また、eMMC の imxboot/linux を使って SD カードにコピーして SD ブートが無効化されてなかった場合に SD ブートもできてしまいます。
>
> ブートできても任意の処理の実行ができるわけではないので、eMMCの内容の確認はできないと考えているのですが、正しいですか?
> (eMMCをクローン出来るだけで、書き換えができない。読んでも中身はわからない)
>
> 投稿してから再確認して気づいたのですが、質問1の回答の下記箇所はeMMCをクローンしたSDカードでも同様ですかね。
> そうであれば、eMMCのデータから作ったSDカードのuserlandを書き換えれば、eMMCが読めるということですね。
そのとおりです、説明は下手ですみません。
eMMC のクローンではなく、eMMC からブートローダーとカーネルだけをコピーして任意のシステムを起動できますので、eMMC の内容の確認や変更はできてしまいます。
この点は、initrd を固めたら簡単に sd ブート不可能にできますので、回避方法は大丈夫です。
お手数をおかけしていますが、スクリプトの変更はお願いします。
build-rootfs の initrd/init を編集して、build_initrd.sh を再実行して、カーネルを再び署名すれば更新されます。
具体的に、先の返事で説明しようとした内容は if [ "$(head -c 4 "$root" 2>/dev/null)" = LUKS ] のチェックを必要とされることです（LUKS 以外の場合に起動させない）
そうすると、暗号化のおかげでクローンできても問題にならないはずです。
> > 2/ uboot の環境変数領域の変更ができます。
>
> このことで暗号化されたeMMCの中身を読むことができたり、鍵を抜けたりすると問題だと思うのですが、それは不可能ですよね?
いいえ、例えば optargs=/bin/sh に変更するとシリアルコンソールでシェルを取得できますので、eMMC の内容を直接に変更できる攻撃者の想定でしたらここもダメです。
ここは前の返事のとおりに対応が複雑になりそうですので、もう少し考えさせてください。
先ほどの返事はある程度の回避はできるかもしれませんが、解決だと思ってません。
今提供している u-boot にはないオプションですが、アップストリーム u-boot では ENV_WRITEABLE_LIST のオプションがあって、それを使えば綺麗に解決できますのでこのパッチをバックポートしてセキュリティマニュアルにそのオプションを有効にさせた方がいいかと考えはじめましたが、その機能は 2020-2023 のスパンでパッチが重なってますのでどこまでが本当に必要かなどに少し時間がかかります。
今週末か来週にまた返事します。
よろしくお願いします。
at_ohsawa
横から失礼します。
アットマークテクノの大澤です。
誤った鍵を書いた場合に対しての復旧手段を残すと、それ自体が脆弱性になるので
SDブートを不可にするのは良いと思います。(当然ミスすると何もできないのですが…)
あとは、故障等での解析も制約が大きくなるので、基板に触れることのできないような
鍵や溶接・接着による筐体の封止等も手段としてあると思います。
また、デバイス上の情報の守秘を目的にするのか、装置自体の挙動変更・改ざん防止を
するのかによると思いますが、前者であればブートプロセスと全般的な暗号化をした
としてもランタイムでのDRAMのプローピングが出来る状況であれば（かなり面倒ですが)、
解析できなくも無いです。
後者であれば先のマルティネの説明の通りブート手段を限定をするのは有効なので、
SDブート・JTAGの無効化は効果的ですね。
tmygt
大澤さん
> 誤った鍵を書いた場合に対しての復旧手段を残すと、それ自体が脆弱性になるので
> SDブートを不可にするのは良いと思います。(当然ミスすると何もできないのですが…)
何らかのミスでデバイス全交換になるのは避けたく、保険としてSDカードブートは残しておきたいです。
> また、デバイス上の情報の守秘を目的にするのか、装置自体の挙動変更・改ざん防止を
するのかによると思いますが、前者であればブートプロセスと全般的な暗号化をした
としてもランタイムでのDRAMのプローピングが出来る状況であれば（かなり面倒ですが)、
解析できなくも無いです。
中途半端ではあるのですが、前者を部分的に達成したいと考えております。
実行中のメモリ解析のような攻撃のリスクは受け入れますが、eMMCの解析による攻撃は防ぎたいです。(実行中のメモリ解析に比べてeMMCへの攻撃は難易度が低いという理解です。)
tmygt
マルティネさん
> 具体的に、先の返事で説明しようとした内容は if [ "$(head -c 4 "$root" 2>/dev/null)" = LUKS ] のチェックを必要とされることです（LUKS 以外の場合に起動させない）
このチェックで下記2つの対策ができるということで正しいでしょうか? (念のため)
1. rootfsパーティションの置き換え(暗号化無のデータに置き換えられないので)
2. eMMC領域をクローンしたSDカードによるブート(ブートできるが変更できないので)
> ここは前の返事のとおりに対応が複雑になりそうですので、もう少し考えさせてください。
お手数をおかけしますが検討よろしくお願いいたします。
at_dominique.m…
tmygtさん
お待たせしました、
マルティネです。
> > 具体的に、先の返事で説明しようとした内容は if [ "$(head -c 4 "$root" 2>/dev/null)" = LUKS ] のチェックを必要とされることです（LUKS 以外の場合に起動させない）
> このチェックで下記2つの対策ができるということで正しいでしょうか? (念のため)
はい、その確認だけで両方の問題を回避できます。
暗号化の仕組みとして他デバイスで暗号化の鍵を生成できないので、SD カードの場合は「オープン」できるパーティションを生成できないためそれだけで足りるはずです。
気になる場合は case "$root" のチェックに明確に /dev/mmcblk2p[12] もチェックできます。
この点については build_initrd.sh スクリプトのオプションでの対応を考えています（rootfs を暗号化しないと不要なので、デフォルトを厳しくして、オプションとしてSD ブートにも使えるモードも生成可能にします。セキュリティガイドの説明に注意を追加します。）
> > ここは前の返事のとおりに対応が複雑になりそうですので、もう少し考えさせてください。
>
> お手数をおかけしますが検討よろしくお願いいたします。
手元で ENV_WRITEABLE_LIST にパッチをバックポートできましたので、この方向で進みたいと思います：
* 今後（おそらく今月末）の imx-boot のリリースで設定可能になります（デフォルトは無効のままになる想定）
* G4 のセキュリティガイドに有効方法を説明します（defconfig ファイルにオプションの追加、書込み可能な変数リストの確認）
お手数ですが、その際の確認などをお願いします。
at_dominique.m…
2024年3月4日 15時28分
tmygtさん
お世話になっています、
マルティネです。
違う順番で回答します。
> 2. SDカード自体もセキュアブートを有効にすることは可能でしょうか? 公開情報をもとに作成したSDカードではブートできず、弊社で署名したSDカードでのみブートできる、といった機能です
セキュアーブートを有効した時点で SD ブートでも署名が必要です。armadilloサイトにあるイメージなどは起動できません。
> 3. セキュアブート鍵が攻撃された場合、そのデバイスのeMMCは暗号化していたとしても復号されてしまうのでしょうか
はい、SD ブートでもセキュアーブート有効状態で起動できた場合に暗号化を復号できてしまいます。
（暗号化自体の仕組みはどこにも説明されてないと思いますが、initrd スクリプトをみれば簡単に再現できると思います。
具体的に、eMMCの頭に暗号化されている鍵があって、セキュアブートが成功した状態でしたら「caam-decrypt」と言うプログラムでその鍵を復号できます。その複合された鍵で luks のディスク暗号化を操作できます）
> 1. 「セキュアブート鍵に対する攻撃」の難易度。SD boot以外に攻撃成立のための条件があるのかどうか
セキュアーブートで確認しているのは imxboot (u-bootなど）と linux (kernel, dtb, 暗号化の場合に initrd)だけです。
なので、SD カードの場合は証明された SD カードを取得できれば、userland の部分を入れ替えることで簡単に何でも起動できます。
暗号化もそこから複合できますので、そこから eMMC の確認や変更はできてしまいます。
SD boot 以外の場合でも eMMC を取り外して内容変更を防ぐ仕組みはありませんが、その難易度はかなり上がりますね…
改めて考えて、eMMC を外せる場合はいくつかの問題があります：
1/ 今の initrd (build-rootfs の initrd/init スクリプト）が rootfs を暗号化あり/無しの両方を対応してしまっていますし、パーティションを何も確認してませんので、
rootfs パーティションを暗号化無しに入れ替えることはできます。
また、eMMC の imxboot/linux を使って SD カードにコピーして SD ブートが無効化されてなかった場合に SD ブートもできてしまいます。
この点はスクリプトの修正で対応できると思いますので、時間ある時に対応しますが、手元のスクリプトを編集しても構いませんのでそういう心配がある場合にスクリプト内容を確認してください。
2/ uboot の環境変数領域の変更ができます。
普段の使い方であればその領域を直接に変更することは不可能なので問題ありませんが、eMMC を直接に変更できる場合に例えば Linux のコマンドライン（optargs) を編集できてしまいますので、何でもできます。
そこの対応はもう少し難しいいです：
* 変数の変更機能自体は rollback と uboot が暗号化されている場合に使いますので、簡単に無効化できません。
uboot の暗号化までされてなかった場合は uboot の環境変数を無効化して(CONFIG_ENV_IS_NOWHERE) rollback できなくなる以外に問題はないと思いますが、試したことないので確認が必要です。
* optargs 以外のオプションは initrd で確認できますが、init=/bin/sh などで init スクリプトを実行させなければ意味がありませんので:
* optargs の場合は一般的に linux の CONFIG_CMDLINE + CONFIG_CMDLINE_FORCE で強制できますが、そのコマンドラインに a/b の選択肢も含まれてますのでそのオプションを使えません。linux の init/main.c の init_setup/rdinit_setup を無理やりに削除するぐらいしか思いつきません…
この点についてはもう少し考えてセキュリティマニュアルに何かの説明を追加しようと考えています。
eMMC を外して、読み取りや変更はそう簡単にできませんが、もう少し考えるべきでした申し訳ございません。
意見をいただけるとすごくありがたいので、何か追加の質問やコメントがあればまたよろしくお願いします。