tkhrosm
2024年9月5日 9時00分
お世話になっております。
emmcを暗号化するためにセキュアブートの利用を検討しています。
セキュアブートの利用には、セキュアブートセットアップ用のSDカードでSDブートを行った後にubootでSRKハッシュの書き込みやclose処理等の作業が必要という認識です。
emmcを暗号化したデバイスをリリースしたい場合、BTOサービスでそのような作業もサポートされていますでしょうか？
また、もしサポートされていない場合、emmcを暗号化したデバイスをリリースするにはどのような手段がありますでしょうか？
よろしくお願いいたします。
コメント
tkhrosm
マルティネさん
ご回答ありがとうございます。
> 申し訳ございません、ただいまセキュリティまわりの設定を BTO でサポートできるように作業の真っ最中で、まだサポートできません。
> 暗号化のためにカーネルを二つ用意しないといけない等、セキュアブート＋暗号化を実際に使えるまでに少し時間かかってしまうと思いますので、おそらく今年の最後か来年の頭ぐらいになってしまいます。
> 量産がまだ先でしたら待っていただければと思いますが、すぐに必要な場合は大変お手数ですが頑張っていただく必要があります。
> （途中まででも必要なツールは少しずつ揃いますので、10月ぐらいにある程度楽になると思いますが、最終的にはもう少し時間かかる見込みです）
>
> > また、もしサポートされていない場合、emmcを暗号化したデバイスをリリースするにはどのような手段がありますでしょうか？
>
> こちらについても大変申し訳ないですが、技術的にはできていても分かりやすいまとめ等がない状態です。（サポートする際に色々自動化したいと考えていますので、最終的には不要になる想定です）。
>
> 足りないステップはそんなに多くないですが、OTP fuse (SRKのハッシュ情報やクロース処理など）の書込みを間違うと後戻りのできないことになりますので、下手に案内したくない気持ちも強いです。
> （暗号化の書込み自体はすでにサポートしていますので、fuse の書込みと少し特集なインストーラーの作り方だけが課題です）
>
> それでも待たずに進みたい場合は「ベストエフォート」と「自己責任」の形になりますが、それでよろしければ一つのやり方を書いてみますので聞いてください。
今年最後 ～ 来年頭を目安にサポート開始の見込みとのことで承知しました。
こちらで作業するにはリスクが高く、また直ちに量産する予定ではないため、ひとまずサポート開始を待ちたいと思います。
追加で質問させてください。
先の話にはなりますが、セキュアブート対応のBTOを受け付ける際にこちらからお渡しするべきイメージの形式は決まっていますでしょうか。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
上記のセキュアブートビルドフローでは最終的にSDブートイメージであるbaseos-installer.imgが生成されますが、このイメージに対して開発物を組み込んだイメージファイルをBTOの際に送付するのでしょうか。
こちらで何を準備しておくべきかを知っておきたいため、もし決まっていましたら教えていただけますと幸いです。
よろしくお願いいたします。
at_dominique.m…
tkhrosmさん
> 今年最後 ～ 来年頭を目安にサポート開始の見込みとのことで承知しました。
> こちらで作業するにはリスクが高く、また直ちに量産する予定ではないため、ひとまずサポート開始を待ちたいと思います。
了解しました。
最終的な物じゃなくても間違いにくい形にできたら案内させていただきます。
> 追加で質問させてください。
> 先の話にはなりますが、セキュアブート対応のBTOを受け付ける際にこちらからお渡しするべきイメージの形式は決まっていますでしょうか。
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
> 上記のセキュアブートビルドフローでは最終的にSDブートイメージであるbaseos-installer.imgが生成されますが、このイメージに対して開発物を組み込んだイメージファイルをBTOの際に送付するのでしょうか。
> こちらで何を準備しておくべきかを知っておきたいため、もし決まっていましたら教えていただけますと幸いです。
形としては同じになります。
baseos-installer.img に SRK のハッシュ等の必要な情報を組み込む予定で、インストールする際に SRK ハッシュなどを設定して一度再起動して通常のインストールにつながります。
SRK ハッシュ以外の差としては、暗号化の復号を対応するカーネルイメージとインストーラー用の SD ブートのカーネルが違う物にしないといけないと考えていますので、そこの扱いはまだ完全に決まっていません。
暗号化用のカーネルは build_initrd.sh --lock で暗号化されたパーティションしか起動できないようにできますので eMMC のタンパリング防止になりますが、インストーラー用のカーネルに「この内容しかインストールできない」の様な機能はまだ開発していないので、準備はまだできません。
（暗号化はデバイスに固定されている鍵を利用しているためインストーラーイメージには利用できません…さらに遠い未来ではセキュアエレメントを使って仕組みを考えれないことはないですが、もの凄くややっこしいことになりそうですのでひとまずは完全性を保証したいです）
なので、今はインストーラーの準備というより、アプリケーションの開発などに集中してください。
セキュリティの面では、まだ行ってない場合に u-boot の設定の制限も推奨しています：
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
(u-boot の prompt が有効でしたら何でもできてしまいますので）
よろしくお願いします
tkhrosm
マルティネさん
> > こちらで作業するにはリスクが高く、また直ちに量産する予定ではないため、ひとまずサポート開始を待ちたいと思います。
> 最終的な物じゃなくても間違いにくい形にできたら案内させていただきます。
はい、ありがとうございます。
> 形としては同じになります。
> baseos-installer.img に SRK のハッシュ等の必要な情報を組み込む予定で、インストールする際に SRK ハッシュなどを設定して一度再起動して通常のインストールにつながります。
>
> SRK ハッシュ以外の差としては、暗号化の復号を対応するカーネルイメージとインストーラー用の SD ブートのカーネルが違う物にしないといけないと考えていますので、そこの扱いはまだ完全に決まっていません。
> 暗号化用のカーネルは build_initrd.sh --lock で暗号化されたパーティションしか起動できないようにできますので eMMC のタンパリング防止になりますが、インストーラー用のカーネルに「この内容しかインストールできない」の様な機能はまだ開発していないので、準備はまだできません。
> （暗号化はデバイスに固定されている鍵を利用しているためインストーラーイメージには利用できません…さらに遠い未来ではセキュアエレメントを使って仕組みを考えれないことはないですが、もの凄くややっこしいことになりそうですのでひとまずは完全性を保証したいです）
>
> なので、今はインストーラーの準備というより、アプリケーションの開発などに集中してください。
> セキュリティの面では、まだ行ってない場合に u-boot の設定の制限も推奨しています：
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
> (u-boot の prompt が有効でしたら何でもできてしまいますので）
ご回答ありがとうございます。
送付するイメージファイルの生成を実機から吸い出して作成する方法が現在の形式だと思いますが、そうではなくATDEのみで作成できないかを検討していることが質問の背景でした。その際にbaseos-installer.imgの扱いが不明でした。
baseos-installer.imgの仕様も含めて検討段階とのことで、ご提案頂いた通りアプリ側の開発を進めたいと思います。
u-bootの使用制限のご提案ありがとうございます。検討いたします。
at_dominique.m…
tkhrosmさん
> 送付するイメージファイルの生成を実機から吸い出して作成する方法が現在の形式だと思いますが、そうではなくATDEのみで作成できないかを検討していることが質問の背景でした。その際にbaseos-installer.imgの扱いが不明でした。
なるほど、ATDE のみでインストーラーも生成したいですね。
それでしたら確かに準備できる物があります。
ATDE でイメージを生成すること自体は可能ですが、コンテナの吸出しの例・説明はありませんので、その部分の動作確認は今からできます。
基本的には「初期化インストールディスク」と同じ手順になります：
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
セキュアブートの SRK 等をすでに書き込んだ機器に試す場合はディスク暗号化のガイドも参考にでいます：
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
そこでお気づきだと思いますが、そのイメージは初期化用の物で、カスタム内容やアプリを入れないといけないですね。
build-rootfs ディレクトリに common/image_installer/installer_swus ディレクトリを追加して、そちらに swu を設置してくださればコンテナを追加できます。
swu は alpha順で（再起動無しで）インストールされますので、00_initial_setup.swu 10_container.swu の用な名前で設置すると管理しやすいかと思います。
rootfs の内容はマニュアルに書いてあるとおりに common か ax2 の resources ディレクトリにファイルを追加できますが、改善ができた際に build-rootfs のアーカイブを更新していただく必要がありますので、できるだけのことを swu で管理すると後々楽になると思います。
よろしくお願いします。
tkhrosm
> ATDE でイメージを生成すること自体は可能ですが、コンテナの吸出しの例・説明はありませんので、その部分の動作確認は今からできます。
>
> 基本的には「初期化インストールディスク」と同じ手順になります：
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
> セキュアブートの SRK 等をすでに書き込んだ機器に試す場合はディスク暗号化のガイドも参考にでいます：
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…
>
> そこでお気づきだと思いますが、そのイメージは初期化用の物で、カスタム内容やアプリを入れないといけないですね。
> build-rootfs ディレクトリに common/image_installer/installer_swus ディレクトリを追加して、そちらに swu を設置してくださればコンテナを追加できます。
> swu は alpha順で（再起動無しで）インストールされますので、00_initial_setup.swu 10_container.swu の用な名前で設置すると管理しやすいかと思います。
>
> rootfs の内容はマニュアルに書いてあるとおりに common か ax2 の resources ディレクトリにファイルを追加できますが、改善ができた際に build-rootfs のアーカイブを更新していただく必要がありますので、できるだけのことを swu で管理すると後々楽になると思います。
>
>
> よろしくお願いします。
返答に間が空いてしまい申し訳ございません。
swuの配置の案内、ありがとうございます。早速開発物のswuを配置して書き込みを試しています。
元の質問とは逸れた質問になってしまうのですが、セキュアブートに関してもう一点お聞きしたいです。
セキュリティガイドの5.11.6. SRK の無効化と切り替え(https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…)について、手順を確認させてください。
SRK1からSRK2に切り替えるには、当然SRK1とSRK2が書き込まれている必要があると思います。
現在使用しているデバイスはSRK1が書き込まれている状態ですので、そこにSRK2を追加したいと考えています。
SRK1と同様にSRK2を作成し、それとsecureboot.confを以下のように編集してインストーライメージを作成しました。
# 省略 CST_UNLOCK_SRK=y CST_SOURCE_INDEX=1
このイメージを使用してSDbootしてSRK2をwFuseに書き込むことが次の手順と認識しています。その際にfuse prog -yによる書き込み先はどこになるのでしょうか？SRK1の場合はbank=6, 7になっているので、SRK2の場合はまた異なるbankを指定すると考えているのですが合っていますでしょうか？
よろしくお願いします。
at_dominique.m…
tkhrosmさん
マルティネです。
> 元の質問とは逸れた質問になってしまうのですが、セキュアブートに関してもう一点お聞きしたいです。
（ここで回答しますが、またこういう関係ない質問があれば新しいスレッドで聞いていただければ嬉しいです。別のスレッドだと検索しやすくなりますので、他に似たような疑問を持っているお客さんがいれば情報を見つかるかもしれません…質問があるということはそもそもマニュアルの説明が不足していてそちらも改善したいと思いますが、そこは少し時間かかりそうです）
> セキュリティガイドの5.11.6. SRK の無効化と切り替え(https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-sec…)について、手順を確認させてください。
> SRK1からSRK2に切り替えるには、当然SRK1とSRK2が書き込まれている必要があると思います。
> 現在使用しているデバイスはSRK1が書き込まれている状態ですので、そこにSRK2を追加したいと考えています。
SRK fuse の変更・追加は不要です。
「print_srk_fuse」コマンドで表示した fuse の設定は一つの SRK スロットではなく、共有のハッシュです。
細かいところまで確認していませんが、fuse を計算する時に４つの証明書（SRK[1-4]_..._crt.pem) を渡して、全部の情報がすでに入っています。
ハッシュ自体は共通ですが、bank=9 slot=3 のfuse で最初の４ビットでどの証明書を使えるかの許可になります。
> このイメージを使用してSDbootしてSRK2をwFuseに書き込むことが次の手順と認識しています。その際にfuse prog -yによる書き込み先はどこになるのでしょうか？SRK1の場合はbank=6, 7になっているので、SRK2の場合はまた異なるbankを指定すると考えているのですが合っていますでしょうか？
なので、手順賭してはマニュアルに書いてある通り：
- CST_UNLOCK_SRK=y で生成した u-boot で起動します。
マニュアルに CST_SOURCE_INDEX の変更の説明は後に来ますが、その際はすでに CST_SOURCE_INDEX を変更した方がいいですね；revoke した後に再起動できなくなりますので…
- その UNLOCK 状態で fuse prog 9 3 1 で index=0 の証明書を無効化します。
- fuse を焼いた後に別の CST_UNLOCK_SRK=n で証明した u-boot に切り替えて、他の証明書を revoke できないようにすることを推奨しています（攻撃か間違いで 0xf を焼いたらもう何も起動できなくなりますので、通常はできない状態が好ましいです）
使用可能な証明書は最初に生成した４つの証明書だけで、同時になくしたりした場合はもうどうしようもないですね…運用としては別に保存するか、ネットワークにつながってないところがいいかもしれません。
弊社ではセキュアブートの鍵を運用してませんが、SWU 用の予備の署名鍵を qr code として印刷して金庫に保存しています。（qrencodeというコマンドでできます）
話をまた逸らして BTO に戻しますが、 https://armadillo.atmark-techno.com/forum/armadillo/21898 での imx-boot の暗号化についての質問もtkhrosmさんからの質問だったと今更気づきました。
imx-boot の暗号化の手順の一部で暗号化されたイメージをデバイスに固定しないといけないですが、そのステップは u-boot からしかできなくて、技術的には対応可能ではありますがこれもまだ実装してません。
imx-boot には基本的に秘密情報が少ないと考えてその対応の優先度はかなり低くて、手間のかかる実装になりますので、結果的に実装しない可能性が高いです。
その点については、ひとまず、今回の書き込み依頼の予定でどれぐらい imx-boot の暗号化を重要しているかを教えていただけますか。
よろしくお願いします
tkhrosm
> （ここで回答しますが、またこういう関係ない質問があれば新しいスレッドで聞いていただければ嬉しいです。別のスレッドだと検索しやすくなりますので、他に似たような疑問を持っているお客さんがいれば情報を見つかるかもしれません…質問があるということはそもそもマニュアルの説明が不足していてそちらも改善したいと思いますが、そこは少し時間かかりそうです）
失礼しました。作業の延長上だったためついこの場を使用してしまいましたが、不適切でした。
> SRK fuse の変更・追加は不要です。
> 「print_srk_fuse」コマンドで表示した fuse の設定は一つの SRK スロットではなく、共有のハッシュです。
> 細かいところまで確認していませんが、fuse を計算する時に４つの証明書（SRK[1-4]_..._crt.pem) を渡して、全部の情報がすでに入っています。
>
> ハッシュ自体は共通ですが、bank=9 slot=3 のfuse で最初の４ビットでどの証明書を使えるかの許可になります。
> なので、手順賭してはマニュアルに書いてある通り：
> - CST_UNLOCK_SRK=y で生成した u-boot で起動します。
> マニュアルに CST_SOURCE_INDEX の変更の説明は後に来ますが、その際はすでに CST_SOURCE_INDEX を変更した方がいいですね；revoke した後に再起動できなくなりますので…
> - その UNLOCK 状態で fuse prog 9 3 1 で index=0 の証明書を無効化します。
> - fuse を焼いた後に別の CST_UNLOCK_SRK=n で証明した u-boot に切り替えて、他の証明書を revoke できないようにすることを推奨しています（攻撃か間違いで 0xf を焼いたらもう何も起動できなくなりますので、通常はできない状態が好ましいです）
>
> 使用可能な証明書は最初に生成した４つの証明書だけで、同時になくしたりした場合はもうどうしようもないですね…運用としては別に保存するか、ネットワークにつながってないところがいいかもしれません。
> 弊社ではセキュアブートの鍵を運用してませんが、SWU 用の予備の署名鍵を qr code として印刷して金庫に保存しています。（qrencodeというコマンドでできます）
ご回答ありがとうございます。追加するのではなく既に作成済みだったものなのですね。勘違いしていました。
※作業中に管理ミスで証明書を失ってしまったのが背景です。該当デバイスの復旧は不可と理解しましたのでこちらの件はクローズで大丈夫です。脱線してしまい失礼しました。
> 話をまた逸らして BTO に戻しますが、 https://armadillo.atmark-techno.com/forum/armadillo/21898 での imx-boot の暗号化についての質問もtkhrosmさんからの質問だったと今更気づきました。
もう一方のフォーラムのご確認ありがとうございます。
> imx-boot の暗号化の手順の一部で暗号化されたイメージをデバイスに固定しないといけないですが、そのステップは u-boot からしかできなくて、技術的には対応可能ではありますがこれもまだ実装してません。
> imx-boot には基本的に秘密情報が少ないと考えてその対応の優先度はかなり低くて、手間のかかる実装になりますので、結果的に実装しない可能性が高いです。
> その点については、ひとまず、今回の書き込み依頼の予定でどれぐらい imx-boot の暗号化を重要しているかを教えていただけますか。
>
> よろしくお願いします
そちらのフォーラムの初めに記載ある通り、主目的としてはemmc領域の暗号化です。それに向けてセキュリティガイドに則って進めていた際にimx-bootの暗号化を行っていました。
こちらとしてもimx-bootの暗号化の重要度は低いと認識しております。
セキュアブート対応のBTOサポートを依頼させていただく際に、imx-bootの暗号化は対象外になる可能性があるということでしたら承知しました。
imx-boot暗号化非対応は許容内です。
手元でもimx-bootを非暗号化のままセキュアブートを試したい場合、./secureboot.sh imxboot_encによるimx-boot_armadillo_x2.encの作成が不要という認識で良いでしょうか？
at_dominique.m…
tkhrosmさん
> そちらのフォーラムの初めに記載ある通り、主目的としてはemmc領域の暗号化です。それに向けてセキュリティガイドに則って進めていた際にimx-bootの暗号化を行っていました。
> こちらとしてもimx-bootの暗号化の重要度は低いと認識しております。
> セキュアブート対応のBTOサポートを依頼させていただく際に、imx-bootの暗号化は対象外になる可能性があるということでしたら承知しました。
> imx-boot暗号化非対応は許容内です。
ご配慮ありがとうございます。
> 手元でもimx-bootを非暗号化のままセキュアブートを試したい場合、./secureboot.sh imxboot_encによるimx-boot_armadillo_x2.encの作成が不要という認識で良いでしょうか？
はい、インストーラーでは imx-boot_armadillo_x2.signed を使いますので、 .enc の方は不要になります。
カーネルに関しては、現在のバージョンで「--lock」を指定しなかった initrd で証明された Image.signed を使ってください。secureboot.sh の成果物はこの二つのファイルのみです。
BTO の手順を見直した際に最終システム（eMMC用）の --lock されるカーネルとインストーラー用の別のカーネルを準備していただきますが、手順できたらちゃんと説明させていただきます
tkhrosm
> > 手元でもimx-bootを非暗号化のままセキュアブートを試したい場合、./secureboot.sh imxboot_encによるimx-boot_armadillo_x2.encの作成が不要という認識で良いでしょうか？
>
> はい、インストーラーでは imx-boot_armadillo_x2.signed を使いますので、 .enc の方は不要になります。
> カーネルに関しては、現在のバージョンで「--lock」を指定しなかった initrd で証明された Image.signed を使ってください。secureboot.sh の成果物はこの二つのファイルのみです。
ありがとうございます。参考にして進めさせていただきます。
> BTO の手順を見直した際に最終システム（eMMC用）の --lock されるカーネルとインストーラー用の別のカーネルを準備していただきますが、手順できたらちゃんと説明させていただきます
はい、よろしくお願いします。
まだ準備段階の中ご回答いただきありがとうございました。
at_dominique.m…
2024年9月5日 10時07分
tkhrosmさん
お世話になっています、
マルティネです。
> emmcを暗号化するためにセキュアブートの利用を検討しています。
> セキュアブートの利用には、セキュアブートセットアップ用のSDカードでSDブートを行った後にubootでSRKハッシュの書き込みやclose処理等の作業が必要という認識です。
はい、クロース処理を行う際に暗号化に使う SoC内の鍵が変更されますので、暗号化する前にクロース処理を行わないといけません。
> emmcを暗号化したデバイスをリリースしたい場合、BTOサービスでそのような作業もサポートされていますでしょうか？
申し訳ございません、ただいまセキュリティまわりの設定を BTO でサポートできるように作業の真っ最中で、まだサポートできません。
暗号化のためにカーネルを二つ用意しないといけない等、セキュアブート＋暗号化を実際に使えるまでに少し時間かかってしまうと思いますので、おそらく今年の最後か来年の頭ぐらいになってしまいます。
量産がまだ先でしたら待っていただければと思いますが、すぐに必要な場合は大変お手数ですが頑張っていただく必要があります。
（途中まででも必要なツールは少しずつ揃いますので、10月ぐらいにある程度楽になると思いますが、最終的にはもう少し時間かかる見込みです）
> また、もしサポートされていない場合、emmcを暗号化したデバイスをリリースするにはどのような手段がありますでしょうか？
こちらについても大変申し訳ないですが、技術的にはできていても分かりやすいまとめ等がない状態です。（サポートする際に色々自動化したいと考えていますので、最終的には不要になる想定です）。
足りないステップはそんなに多くないですが、OTP fuse (SRKのハッシュ情報やクロース処理など）の書込みを間違うと後戻りのできないことになりますので、下手に案内したくない気持ちも強いです。
（暗号化の書込み自体はすでにサポートしていますので、fuse の書込みと少し特集なインストーラーの作り方だけが課題です）
それでも待たずに進みたい場合は「ベストエフォート」と「自己責任」の形になりますが、それでよろしければ一つのやり方を書いてみますので聞いてください。
よろしくお願いします。