現在の規制環境において、安全なブートローダの実装はもはや「ベストプラクティス」にとどまらず、コンプライアンスの必須要件となりつつあります。EUや米国をはじめとする各国で最近導入されたサイバーセキュリティ規制では、セキュアブートやファームウェアの正当性検証といった対策が、接続デバイスに求められる要件として明記されています。
本記事では、従来のブートローダへのwolfBootの導入に関する以前の議論を踏まえつつ、今後導入される各種フレームワークがセキュアブートをコンプライアンス上不可欠なものとして位置づけていること、そしてwolfBootの機能がこうした新たな規制要件にどのように対応しているかを紹介します。
目次
- はじめに – コンプライアンス要件としてのセキュアブート
- EUサイバーレジリエンス法：”Secure by Design” とセキュアブート
- 米国大統領令14028と連邦イニシアチブ
- UN R155（自動車）：サイバーセキュリティとブート整合性
- 産業制御 – IEC 62443要件
- 医療機器 – FDAサイバーセキュリティガイダンス
- 消費者向けIoTデバイス – ETSI EN 303 645およびその他の標準
- コンプライアンスニーズに対応するwolfBoot機能
- まとめ – 組み込みシステムにセキュアな将来性を
はじめに – コンプライアンス要件としてのセキュアブート
数年前の時点では、システムにセキュアブートローダーを導入することはあくまで予防的措置の一環に過ぎませんでした。しかし現在では、各種規制に対応するために必須のアクションとなりつつあります。いくらかの場合において、各種デバイスに対し「認証されたファームウェア以外では起動できない仕組み」及び「信頼できる更新プロセスを維持すること」を求められるようになってきています。
先日施行されたEUのサイバーレジリエンス法では、コネクティッドデバイスが「実行前にソフトウェアの整合性を検証するセキュアブートプロセスを実装する」ことを義務付けています。米国でも同様に、大統領令14028や連邦IoTセキュリティガイドラインなどにより、デジタル署名やセキュアブートなどの対策を通じてデバイスの整合性を保つべきであると示されています。要するに、システムでセキュアブートローダーを使用することはもはや必須要件となりつつあるのです。
wolfBootなどの製品を使用して既存のブートローダーを改良することは、次の2つの利点をもたらします。1つはセキュリティの向上、もう1つはコンプライアンス要件の達成です。ここからは、あらゆる業界における主要なサイバーセキュリティフレームワークについて、セキュアブートやファームウェア検証がどのように取り扱われているのかを紹介します。併せて、wolfBootが規制適合に向けてどのような支援を行えるのかについてもご案内します。
EUサイバーレジリエンス法：”Secure by Design” とセキュアブート
今日、業界に激震をもたらした規制は、やはりEUのサイバーレジリエンス法(CRA)です。これはEUで販売される「デジタル要素を有する製品」に対し、厳格なサイバーセキュリティ基準を満たすことを要求するものです。
この法律では、セキュアブートは “Secure by Design” の一部として明示されており、製品のメーカーが「実行前にソフトウェアの整合性を検証するセキュアブートプロセスを実装すること」を義務付けています。これはすなわち、デバイス上で「改ざんされていない信頼できるファームウェア」のみが実行可能であることを意味します。実際には、デバイスの起動時にファームウェアを暗号学的に認証することでこの要件をクリアできます。これはまさに、wolfBootのようなセキュアブートローダーが提供する機能です。
CRAは他にも、デフォルトでセキュアな設定が施されることや、脆弱性開示プロセスの制定、製品のライフサイクル全体を通じてセキュアに更新/パッチを適用できることを強制します。セキュアブートはこれらの対策の基盤として動作します。起動プロセスが安全でなければ、他のいかなる対策も回避されてしまう恐れがあるためです。これらの制御を実装しない場合、EUのCRAに準拠していないことになります。これはつまり、コンプライアンス要件に違反していることを意味します。
wolfBootによる対応
wolfBootは認証されたファームウェアのみが実行されることを保証するように設計されており、CRAのセキュアブート要件を完全にカバーできます。wolfBootは起動時に暗号エンジンを使用してファームウェアのデジタル署名を検証し、整合性と真正性を確認します。チェックに失敗した場合、デバイスはその時点で起動プロセスを中止し、アプリケーションが動作することはありません。これはまさに、ガイドラインが要求している通りの動作です。
さらに、wolfBootの署名検証&バージョン指定機能を有するセキュアOver-The-Air(OTA)ファームウェア更新機能は、CRAのセキュア更新メカニズムの要件を満たしています。すでに生産中・生産済みのデバイスであっても、wolfBootを用いて改修することで、ハードウェアの再設計なしにEU CRAセキュアブート規定へ準拠させることができます。
米国大統領令14028と連邦イニシアチブ
米国では、IoTセキュリティのための包括的な法律はまだありませんが、大統領令14028（2021年）- 「Improving the Nation’s Cybersecurity ― 国家のサイバーセキュリティの改善」によって、ソフトウェアとデバイスにおいてより高いセキュリティ標準を充足することを求めています。この大統領令は、連邦機関と重要なインフラストラクチャーの提供者にゼロトラストアーキテクチャやセキュアソフトウェア開発などを取り入れるよう促しました。
これによってもたらされた結果の1つが、ソフトウェアサプライチェーンにおける整合性担保の推進です。承認されたコードのみがデバイス上で実行されることを検証することで、これを実現できます。実際に、2020年のIoTサイバーセキュリティ改善法とNIST勧告によって推進されている連邦IoTセキュリティガイドラインにおいて、ファームウェアの整合性と真正性を保証するためのセキュアブート機能を推奨しています。これにより、米国政府やその他の重要セクターに製品を販売する場合、セキュアブートやファームウェア署名などの機能を有していることはすでに必須要件となりました。
大統領令14028自体は政府のITネットワークに焦点を当てたものですが、IoTや組み込みデバイスの要件にも波及して効果を及ぼしました。米国政府はIoTセキュリティラベリングプログラム（Cyber Trust Mark）と新たな連邦調達規制(FAR)を策定中であり、これらはデバイスの整合性保護を含むことになると予想されています。これにより、多くの米国デバイスメーカーは現在「どのパートにおいてセキュアブート、ファームウェア署名、相互認証の実装が求められるのか」と問いかけている状況です。これはまさに、急速に成長するコンプライアンスの複雑さを印象付けます。
米国でのファームウェア検証規制は主に政策主導で進められていますが、これらに広く共通しているのは「信頼できないコードはデバイスから遠ざけなければならない」ということです。
訳注：日本においても2024年8月に経済産業省より「IoT製品に対するセキュリティ適合性評価制度構築方針」が公表され、これに基づいて2025年3月よりIPAによる「セキュリティ要件適合評価及びラベリング制度（JC-STAR）」がスタートしました。米国と同様に、セキュアブートに関する要件が定められています。
wolfBootによる対応
wolfBootを用いることで、セキュアブートに関する新たな米国基準を満たすことができます。例えば、wolfBootではリセットベクターから信頼チェーンを確立します。これは、米国ガイドラインがサプライチェーン攻撃とファームウェア改ざんに対応するために求めている防御手法の1つです。
またwolfBootは非常に小さなフットプリントしか必要としない一方で、内部ではFIPS 140-3認証取得実績のある堅牢なアルゴリズム実装が動作しています。これはまさに、米国政府や関連組織に販売する製品に最適であることを意味します。
今後、使用するデバイスが何らかの規則によって「信頼できるソフトウェアのみをブートする」ことを証明しなければならなくなった場合、wolfBootは明確にこれに応えることができます。
UN R155（自動車）：サイバーセキュリティとブート整合性
自動車業界では、2021年に国連欧州経済委員会(UNECE)においてUN R155としてサイバーセキュリティ要件が明示されました。これは車両型式承認の際、適切なサイバーセキュリティ管理システムが機能していることを義務付ける規制であり、EU・日本などで2024年半ばからすでに発効しています。
UN R155はプロセス指向の規則ですが、UN R156（ソフトウェア更新管理用）によってISO/SAE 21434標準と組み合わされ、内容が大きく拡充しています。これらのフレームワークは共に、自動車メーカーがソフトウェア改ざんから車両を保護することを要求します。つまりこれは、認証されたソフトウェアのみがECU上で実行できることを保証しなければならないことを意味しています。
UN R155において、自動車メーカーはソフトウェアの改ざんへの対策を実装し、暗号処理を用いて正式なソフトウェア更新であるかを検証しなければならないと示されています。つまり、自動車を構成する各電子制御ユニットが、適切に署名/検証されていないプログラムコードを拒否しなければならないということです。
この要件を満たすにあたって、セキュアブートはまさに根幹をなす技術です。ハードウェアベースのRoot of Trustを確立し、ブートチェーンの各段階で署名を検証することで、車両を構成する各制御システムがきちんと整合性を確保できていると保証できます。
また、UN R155で言及されているISO 21434では、「初期ブートソフトウェアの整合性を保証するための信頼アンカー(＝セキュアブートの確立)」を、OTA更新と車載ネットワークを保護するためのベストプラクティスとして強調し、明示しています。このことからも、自動車業界においてセキュアブートとランタイムの整合性保持がすでにベーシックなコンプライアンスと見なされていることは明らかです。
訳注：日本でもこのUN R155が道路運送車両法に組み込まれ、すでに施行されています。これにより2024年1月以降、基準に準拠していない車両は型式認証を得ることができなくなっています。さらに2026年5月からは、すでに型式認証を受けて販売している車両にも同法が適用され、新たに型式認証を取り直さなければならないと定められました。
wolfBootによる対応
wolfBootは、検証されたブートチェーンとハードウェアベースの信頼統合が非常に重要である自動車ニーズに適しています。TPM 2.0やHSMをハードウェアRoot of Trustとして活用し、単なるデバイス識別のためのチップではなくブートプロセスを構成する重要なパーツとして使用できます。
具体的には、wolfBootはTPMのセキュアキーストレージとPCR(Platform Configuration Registers)測定を使用して、自動車に搭載されたマイコン上でMeasured Bootを実装できます。これは、UNECEが提示する「運用ライフサイクル全体を通したソフトウェアの整合性保持」を実現するために利用できる機能の1つです。
wolfBootがブートプロセスの各段階で実行する署名検証やロールバック保護などの機能は、自動車の脅威シナリオに対してまさに直接アプローチできます。例えば、UN R155において「攻撃者がファームウェアをダウングレードしたり悪意のあるコードを注入しようとした場合、システムがこれを検知できること」という要件が示されています。これについてwolfBootでは、ブード時のバージョンチェックを強制し、不正なファームウェアやダウングレードされたファームウェアのロードを拒否することで対応できます。
さらに、wolfBootは様々な実行環境において各種認証を取得しやすくなるよう開発されています。具体的には、MISRA-Cコンプライアンスへの準拠を念頭に設計され、航空宇宙・アビオニクス用のDO-178C認証可能フォーマットに対応し、自動車メーカーがISO 21434コンプライアンスに使用できる堅牢性を有しています。
総括すると、旧式のECUであってもwolfBootを用いて改修することにより、次世代機の開発を待つことなく厳格なUN R155規則に準拠したセキュアブートを実現できます。
産業制御 – IEC 62443要件
産業・OT（Operational Technology）システム向けには、IECによって定められた独自のサイバーセキュリティ標準IEC 62443があります。
このうち、産業向け制御システムで使用される組み込みデバイスのセキュリティ機能について定めるIEC 62443-4-2に、「組み込みデバイスは、使用前にコンポーネントのブートとランタイムプロセスに必要なファームウェア、ソフトウェア、構成データの整合性を検証する」という記述があります。
これはブート時のファームウェアとソフトウェアの整合性を保証するメカニズムの実装を求めるものであり、産業向け製品におけるセキュアブートや安全なファームウェア更新の重要性を示しています。
他のセクションでは、「許可されていないソフトウェアがデバイス上で実行されることを防ぐ」ことなども記されています。プログラムに対する署名及びその検証を実施することにより、不正なプログラムをハードウェア上で実行させないことは非常に重要です。
これらの記述から、発電所や工場といった重要インフラ設備の制御に用いるPLC、RTU、コントローラーでセキュリティレベル2以上を満たすためには、暗号技術に基づくセキュアブートの実装が必要不可欠とされていることが分かります。
実際、業界のガイダンスではこの基準を満たすために、産業ゲートウェイとPLCにおいてセキュアブートを使用することが促されています。しかし本質的にこの要件を充足するためには、電源投入時からアプリケーション起動まで、一貫した信頼チェーンの実装が求められているという見方もできます。
wolfBootによる対応
wolfBootのコア機能である「信頼できるファームウェアイメージのみの実行許可」は、IEC 62443-4-2の整合性検証要件を直接満たします。
旧式のPLCのブートシーケンスにwolfBootを統合することで、「ブート中にファームウェア整合性を検証し、チェックが失敗した場合は実行をブロックする」処理を追加できます。wolfBootは幅広い暗号化アルゴリズム（ECC、RSA、Ed25519など）に対応しており、様々な環境のアルゴリズムポリシーに十分対応できます。
さらに、wolfBootはOSに依存しないよう設計されており、非常に小さなフットプリントで動作します。これはつまり、リソース制約の厳しいベアメタルコントローラーにおいても、最小限のオーバーヘッドで動作することを意味します。リアルタイムな動作を要求される産業デバイスにおいて、特に重要な観点ではないでしょうか。
このほか、フェイルセーフロールバック機能を備えたデュアルバンクファームウェア更新も特筆すべき項目の1つです。何らかの要因で更新処理に失敗した場合にも、それ以前に動作していた状態のファームウェアに自動的にロールバックすることで、システムの可用性を維持します。
wolfBootが有するこれらすべての機能により、旧式の産業システムをベースとして、1からの再設計なしにIEC 62443で求められるセキュアブートを実装することが容易になります。
医療機器 – FDAサイバーセキュリティガイダンス
米国の規制当局が要件を厳格化しているもう1つの分野として、医療機器が挙げられます。
2023年9月、FDA(米国食品医薬品局)がデバイスメーカーに求めるサイバーセキュリティ対策を概説するガイダンス「医療機器におけるサイバーセキュリティ：品質システム考慮事項と市販前提出の内容」の最新版を発行しました。
このガイダンスではデバイスにおける真正性・整合性保護の必要性などが指摘されており、医療機器メーカーに対して「信頼できるソフトウェアのみがハードウェア上で実行できるような対策を実装すること」が期待されています。
特にセキュアブートメカニズムについては明示して推奨されており、「デバイスは信頼され認証されたファームウェア/ソフトウェアのみがデバイス上でロードされ実行されることを保証するために、セキュアブートメカニズムを使用するべきです。ブートプロセス中にファームウェアの整合性を検証し、チェックが失敗した場合はブートを拒否すべきです。」と述べられています。これは医療機器におけるサイバーセキュリティ基準として、セキュアブートの重要性を明確に著しています。
さらに、新しい米国立法（2023年包括法のPATCH法規定）により、医療機器の市販前提出にサイバーセキュリティ計画を含めることが要求されるようになりました。これには、デバイスのライフサイクル全体を通じて「セキュアで信頼できる更新とパッチ」を保証する能力を持つことが含まれます。
FDAはこのほかに強固なアクセス制御、ログ記録、データ暗号化、安全なアップデート配信を求めていますが、これらをアプリケーションレイヤでどれほど堅実に実装したとしても、デバイスのブートプロセスが安全でないとこれらすべてが損なわれる可能性があります。したがって、セキュアブートとハードウェアベースの信頼チェーンは、患者の安全に影響を与える可能性のあるデバイスを保護するための基盤となります。
訳注：日本では厚生労働省が2023年3月に医療機器の基本要件基準を改正し、サイバーセキュリティに関する要求事項が第12条第3項として規定されたほか、関連する通知文書が多数発行されています。また同省は、国際医療機器規制当局フォーラム(IMDRF)により公布されているガイダンス(通称：IMDRFガイダンス)についても言及しています。詳細は厚生労働省「医療機器におけるサイバーセキュリティについて」をご確認ください。
wolfBootによる対応
多数の従来型のプラットフォームを更新しなければならない医療機器メーカーにとって、wolfBootはFDA勧告で示されたブート整合性をすぐに満たせる有用なツールとなります。
wolfBootはデバイスのブートローダーとして動作し、デバイスが起動する度にファームウェアイメージのデジタル署名を検証します。これにより、悪意のある / 偶発的な改ざんを検知でき、デバイスが未検証のコードを実行しないことを保証できます。これはまさに、FDAのガイドラインで求められている機能です。
wolfBootは、暗号化されたファームウェアイメージにも対応しています。ファームウェアイメージを予め暗号化して配布することで、攻撃者に傍受されたとしても、これを元にファームウェアを改造することを事実上不可能にできます。
そしてもう1つ、wolfBootが有する大きな利点があります。それはOSや重いランタイムに依存せずに動作することです。これは非常に小さなフットプリントで動作することのみならず、脆弱性が生じる恐れのある領域を極限までコンパクトにできるという点で、まさに理想的です。
wolfBootのセキュアブートと安全なアップデート機能を用いることで、医療機器メーカーはFDAが市販前提出で求めるサイバーセキュリティ要件の大部分を満たすことができます。デバイスがハードウェアからアプリケーションに至るまで、暗号に基づいて検証されたセキュアなブートチェーンを有することを文書に記すことができるようになります。
消費者向けIoTデバイス – ETSI EN 303 645およびその他の標準
スマートホーム、ウェアラブルデバイスといったIoT製品でよく用いられる標準規格は、ETSI EN 303 645です。なお、ETSIが2020年6月に公開したv2.1.1についてIPAが和訳を提供していますが、2024年9月に新しくv3.1.3が公開されているため注意が必要です。そしてこの標準はヨーロッパ発のものですが、英国・オーストラリアなどのIoTラベリング制度にも影響します。
この標準では「コンシューマーIoTデバイスは、セキュアブートメカニズムを使用してソフトウェアを検証すべきである」と示されており、さらに「無許可の変更が検出された場合、デバイスはユーザーに警告し、通常の動作を控えるべきである」とも述べています。これによりセキュアブートは基準としての推奨事項となり、万一マルウェアがデバイスに何らかの方法で侵入したとしても、適切に署名されていないことを検知し、再起動後にはマルウェアが動作できないことを保証します。
ETSI 303 645はこれらをベストプラクティスとして「すべき」と表現していますが、英国の規制当局では製品セキュリティおよび電気通信インフラ法を通じ、これらの項目に従うよう整備する方向に動いています。つまり、消費者向けIoTデバイスは起動時と更新時の両方で、ファームウェアを暗号学的に検証する機構を持つことが期待されています。
これはIoT業界に限ったものではなく、他の業界固有の標準においても共通したテーマとなっています。例えば、前述の自動車業界向けISO/SAE21434や、いくつかのIEEE UL IoT標準においてもセキュアブートが強調されています。このほか、米国のNISTIR 8259やGSA IoTセキュリティフレームワークなどのガイドラインにおいて、概ね共通した記述が見られます。
デバイスはコードの整合性を保証しなければなりません。セキュアブートを実装するメーカーは、多くの場合複数の標準を一度に満たすことができます。セキュアブートとロールバック保護は、悪意のあるファームウェアのインストールやファームウェアの改ざんを防ぐために、一部の規制/標準で要求される機能です。
まとめると、IoTセキュリティラベリングのために認証されるスマートヒーターも、コンプライアンス要件への準拠が必要である新たなドローンも、セキュアブートが共通の要件となっているということです。
wolfBootによる対応
wolfBootは多様な環境に移植できます。コンパクトなIoT向けSoCでも使用でき、小さなオーバーヘッドで消費者向けIoTセキュリティ要件を充足できる実用的な選択肢です。
例えば、ETSI 303 645のセキュアブート勧告に準拠させるケースを想定します。wolfBootはブート時にファームウェアイメージに施されたデジタル署名を検証し、これに失敗した場合には動作を停止するか、安全なフォールバックイメージをロードするように構成できます。
そして、wolfBootはバージョン番号に基づくアンチロールバック機構も備えています。これにより、デバイスが古い脆弱なファームウェアを実行できないよう保証することができます。これはCRAが定める”Secure by Default”のロールバック要件に適応するほか、復元力を求めるその他いくつかのIoT標準にも対応できます。
さらに、wolfBootは耐量子署名も含む強力な暗号技術を使用します。よって、各規制/標準で要求される「最先端暗号実装」への準拠を明確に主張できます。
ETSIガイドラインに従う必要のあるスマートカメラも、IoT Security Foundation勧告に準拠する家庭用ルーターも、wolfBootを組み合わせることで容易にセキュアブート要件を満たすことができます。そして、将来的に公開される新たなセキュリティ標準への適応性を確保できます。
コンプライアンスニーズに対応するwolfBoot機能
エンタープライズ、自動車、産業、医療、IoT。これらすべてのドメインにおいて、セキュアブートを構成するいくつかの機能の実装が要件として求められています。
wolfBootがこれらをどのように充足しているのかについて、以下に示します。
検証されたブートチェーンとファームウェア認証
wolfBootは各回起動時にファームウェアのデジタル署名を検証し、「信頼できるファームウェアイメージのみがターゲットデバイス上で実行できる」ことを保証します。これは、CRA、IEC 62443、FDAなどのファームウェア整合性検証を要求する規制をそのまま満たすものです。
そして信頼チェーンは、書き換えできない領域やTPMなどに保存した鍵を起点とし、wolfBootを通じてアプリケーションレイヤにまで拡張します。これにより、信頼チェーンがEnd-to-Endで構築できていることを保証できます。
現代のアルゴリズムに基づくデジタル署名
wolfBootはwolfCryptエンジンを活用し、デジタル署名用の幅広いアルゴリズムをサポートします。具体的には、ECDSA（secp256r1）やRSA-4096、ed25519/ed448、そしてLMS/XMSSやML-DSAなどのポスト量子スキームも含みます。
これは、業界標準が要求するアルゴリズムポリシーや証明書スキーム（例：政府向けFIPS承認アルゴリズム、長寿命産業デバイス向け量子耐性鍵）に準拠できることを意味します。
すべてのファームウェアイメージは、起動時と更新時の両方でこれらの強力な暗号処理を用いて検証されます。
アンチロールバック保護
CRAやUN R156をはじめとする多くの規制では、デバイスが許可なしに脆弱なファームウェアにロールバックできないことを要求します。
wolfBootは、バージョン番号に基づくロールバック保護を実装しています。つまり、現在インストールされているものより古いバージョン番号を持つファームウェアイメージを拒否できます。これにより、攻撃者がデバイスを以前の安全でない状態に戻せないことを保証できます。
そして、wolfBootは何らかの要因で更新に失敗した場合にも、最後に動作していた良好なファームウェアにロールバックさせることができます。
wolBootはダウングレード攻撃への耐性と、正当な回復を実現する復元力の両方を提供します。
セキュア更新メカニズム（OTAサポート）
事実上、すべてのフレームワークがセキュアなファームウェア更新プロセスを求めています。
wolfBootはトランスポートレイヤーとは独立した、高い信頼性を有する更新メカニズムを有しています。これにより、UARTやSPI、CAN、Ethernetなどを用いて動作できるほか、転送中・保存時のファームウェアの暗号化に対応します。
要件として暗号化を含む無線での更新(OTA)が含まれていようと、更新パッケージへのデジタル署名の付帯が含まれていようと、wolfBootはそれらを達成するための手段を有しています。
これらの技術は、アップデートがセキュアに配信・適用されることを求めているCRA、FDAガイダンス、UN R156の要件に適合します。
ハードウェアベースのRoot of Trust（TPM/HSM統合）
多くの規制と標準において、信頼をより強固にするためのトラストアンカーとして、ハードウェアセキュリティ技術の使用を推奨または要求しています。
wolfBootは、各ハードウェアが有するセキュアチップ、TPM 2.0チップ、Arm TrustZone-MなどのMCUのセキュリティ機能との統合に対応しています。TPMに格納した鍵とPCR(Platform Configuration Registers)を使用してブートプロセスを検証し、暗号処理のハードウェアアクセラレータへのオフロードをサポートします。これは、wolfBootが認証要件である「ハードウェアベースのRoot of Trust」を満たし、より高い保証品質を提示できることを意味します。
例えば、IoTデバイスでは鍵データをOTP(One-Time Programmable Memory)やTPMに保存でき、wolfBootはそれを使用してファームウェアの検証を行います。
万一メインのフラッシュメモリが侵害されても、デバイスは信頼できないコードをブートしません。
最小限の攻撃面と高品質実装
wolfBootは、シンプル、コンパクト、そして安全になるように設計されています。そのコードベースはブートローディングと暗号のみに焦点を当てた最小限のもので、脆弱性が潜在するリスクを減らします。これは、CRAの”Secure by Design”を満たすために重要です。具体的には、wolfBootはOSに依存しておらず、そして小さなハードウェア抽象化レイヤーを有しています。この設計は、正式な認証プロセスと監査を行う際に役立ちます。
特に安全性が重視される産業向けに、wolfBootをDO-178Cレベル認証可能キット（航空電子工学用）で提供することも可能です。これは、wolfBootの開発プロセスの厳密さを示しています。
産業と自動車業界に対しては、MISRAコンプライアンスと静的解析実績を有しています。また、必要に応じてISO 26262やIEC 61508などの標準に対して検証することを容易にしています。
要するに、wolfBootは「認証可能な」セキュアブートローダーソリューションと示すことができます。航空電子工学パートナーシップで言及されたように、これは移植が容易で、各種認証に対応できるブートローダー&ファームウェア更新ソリューションです。これにより、規制当局にソフトウェア品質と信頼性の根拠を示す必要がある場合に、一定の信憑性を伴わせることができます。
製造する製品が各種サイバーセキュリティ要件を満たすことを示すには、通常かなりの工数を要します。しかし、wolfBootを組み込むことにより、それらの多くの要件に適合することを容易に提示できます。
そして、各方面のベストプラクティスに基づいて設計・開発され、各種認証取得実績のあるセキュアブートローダーwolfBootを用いることで、多様な新しい標準に適合するブートローダーを都度開発することに要す非常に多くの工数を削減できます。
まとめ – 組み込みシステムにセキュアな将来性を
セキュアブートと安全なファームウェア更新は、自動車の型式認証や医療機器の承認、そしてEU CRAに基づくその他のあらゆるコネクティッドデバイスに必須の要件となりつつあります。
かつてはハイエンドのセキュリティ機構と見なされていましたが、まもなく各国の法律に基づいた規制・基準として機能します。これは、これまでのアーキテクチャで設計されたデバイスを多く保有する組織にとって大きな壁となり得ます。しかし、既存のブートローダーやハードウェアを廃棄する必要はありません。wolfBootなどのセキュアブートソリューションを用いることで、これらの規制に準拠できるよう改修することが可能です。
これまでに、既存のブートローダーに署名検証機能を付加するため、wolfBootをライブラリやドロップインのコンポーネントとして使用できることを実証済みです。独自の更新ロジックやハードウェアチューニングを維持したまま、セキュリティレイヤーを挿入しています。
このような既存のブートローダーを改修するアプローチがもたらす恩恵は、デバイス寿命を延長するだけでなく、今後数年間でより厳格な規制が設けられたとしても、デバイスの使用・販売を継続できることの保証にも繋がります。
wolfBootはOS非依存・マルチプラットフォームで動作することにより、過去の様々なアーキテクチャに適用でき、1から設計し直すのとほぼ同等のコンプライアンスレベルに到達させることができます。
まとめると、セキュアブートは単なる高度なセキュリティ技術ではなく、確実に実装しなければならないコンプライアンス要件となってきています。デバイスにwolfBootを統合することで、検証されたブートチェーン、堅牢性、そして規制当局や監査担当者に提供できるテスト証跡などのドキュメントをもたらし、各種要件への準拠をスムーズに実現できます。
wolfBootのような高度なセキュアブートソリューションを選択することで、デバイスに日々進化を続けるサイバーセキュリティ法への対応力を持たせ、そして顧客をファームウェア攻撃へのリスクから保護することが可能になります。
セキュリティ、コンプライアンス、そしてイノベーションの3者は両立させることができます。wolfBootを用いて旧式のブートローダをアップデートすることは、まさにこの3つをすべて達成するために有効な戦略です。
wolfBootの機能（TPM/HSM統合、耐量子署名、セキュア認証など）とそれらが各規制にどう適合するかについてご質問がございましたら、ぜひ info@wolfssl.jp までお問い合わせください。
原文：https://www.wolfssl.com/meeting-secure-boot-compliance-requirements
(本稿では、原文の翻訳に日本における状況を追記しました)