Hello,
最近、ファイルシステムの整合性を維持する方法と、iMX93 EVKでファイルシステムを更新した後にこの問題を管理する方法について考えています。
明確にするために、次のeMMCパーティションを想定しましょう。
/dev/mmbclk1boot0 -> ブートローダ
/dev/mmbclk1p1 -> FIT image
/dev/mmcblk1p2 -> rootFS_one
/dev/mmcblk1p3 -> rootFS_two
/dev/mmcblk1p4 -> hash_one
/dev/mmcblk1p5 -> hash_two
事柄は次のとおりです。これで、bootaloaderとFITイメージ(initramfsを使用)が固定されました。だから今、私はファイルシステムを保護しようとします。私の考えは、2つのパーティションを使用して2つのファイルシステム(/ dev / mmcblk1p2と/ dev / mmcblk1p3)を格納し、通常の操作ではそのうちの1つがマウントされ、更新がアサートされる必要があるときに新しいコンテンツが他のパーティションに格納されます。更新が完了すると、システムがリセットされ、更新されたファイルシステムがマウントされます(そして、両方のパーティションが次の更新のために役割を交換します)。
現在、両方のファイルシステムの整合性が問題になっています。これは、initramfs中にマウントされるファイルシステムの整合性をチェックするという考え方です。
私の考えは、 /dev/mmcblk1p2 のファイルシステムが実行されているとき (initramfs が以前にこのパーティションをマウントしているとき) 、 /dev/mmcblk1p3 が更新されるというものです。次に、coreutils の sha256sum ユーティリティを使用して、/dev/mmcblk1p3 からハッシュが計算されます。このハッシュは秘密鍵で署名され、結果は /dev/mmcblk1p5 に保存されます。リセット後、initramfs は /dev/mmcblk1p5 に格納されたハッシュを読み取り、公開鍵 (FIT イメージはブートローダーによって保護されているため不変) で復号化し、計算されたハッシュ /dev/mmcblk1p3 と比較します。すべてが正常であれば、システムは /dev/mmcblk1p3 からブートします。
このプロセスは、2番目のファイルシステムから最初のファイルシステムまで発生します(再度説明することはしませんが、明確だと思います)。
私の考えについて2つの質問があります。
sha256sumユーティリティは、このアプリケーション(ファイルシステムの保護)に適していますか?(実装がはるかに簡単なので、dm-verityまたはimaよりもsha256を使用する予定です)。
ファイルシステムがハッシュの署名に使用する秘密鍵をどのように保護できますか?iMX93は、キーを安全に保存するためのユーティリティを提供しますか?(この質問は、ELEについては知っていますが、使い方がわからないため、少し修辞的です)。
よろしくお願いします。
Gorka.
こんにちは
あなたのユースケースは実行可能に思えるので、私はそれがうまく見えると言うでしょう
セキュアなELEについては、以下のドキュメントへのアクセスをリクエストできます。
https://www.nxp.com/webapp/Download?colCode=IMX93ELEAPI&appType=moderatedWithoutFAE
よろしくお願いします/サルドス、
アルド。