セキュアな組み込みシステムを求めて「信頼」を掘り下げる：SYSTEM DESIGN JOURNAL（3/5 ページ）

[Ron Wilson，Altera Corporation. MONOist]

OSの問題

　OSとファームウェアには、アプリケーションコードと共通の問題が多くありますが、一方で大きな違いも幾つかあります。最初の違いは、多くのデザインが独自のOSを作成するのではなく、OSや開発プラットフォーム全体のライセンスを受けていることです。SEooCに近い程度の品質であっても、小さなリアルタイムカーネルを超えるレベルのものを見つけることは困難です。

　2つ目の違いは、稼働中のソフトウェアとファームウェアのいずれもフィールドアップデートが多いという事実です。Windowsがどれほど頻繁にアップデートされているかを考えてみてください。3つ目の違いは、システム開発者がOSを一般にブラックボックスとして扱っており、つまり実際にどのようなコードが含まれているか、どのように機能するか、どのようなリスクが隠れているかを知らないということです。

　システムソフトウェアの1つの大きなトレンドによって、セキュリティが積極的に弱体化されています。エンベデッドコンピューティングの領域で著名な、ジョージア工科大学のMarilyn Wolf（マリリン・ウルフ）氏は、DACの聴衆に「オープン・ソースは信頼できる方式ではありません」と警告しました。

　Mentor Graphicsのエンベデッド部門最高セーフティ責任者であるRobert Bates（ロバート・ベイツ）氏は、ISO 26262 SEooCに関する別のオンラインセミナーで、「今日のオープンソースソフトウェアはSEooCになる経路を持っていません。基本的にLinux は忘れてください。ヨーロッパではLinuxをASIL（Automotive Safety Integrity Level）B［ISO 26262評価で下から2番目のレベル］にする取り組みが進んでいますが、達成には2〜3年はかかるでしょう」と述べています。

　専門家は、顧客と交渉してシステムのASILを下げるか、またはOSを隔離してその影響が重要でない機能にしか物理的に及ばないようにすることを提案しています。Linuxが制御ループに影響を及ぼすことができない状態である限り、LinuxをインフォメーションUIだけに使用することは許容できるかもしれません。そのようにしない場合、フィールド実績があるカーネルを使用すること、SEooCまたは同等にセキュアなコンポーネントからOSを構築すること、ISO 26262規格に準拠したカスタムカーネルを記述すること、またはベアメタルハードウェアでアプリケーションコードを実行することになるでしょう。

　マルチコアシステムでは、2つまたは3つのコアで別々のOSを実行して照合するか、または多数決を取ることが可能ですが、それでも複数のOSが攻撃されるケースを試験する必要はあります。

　アップデートによって一連の新しい問題が発生します。アップデートするにはSEooCの品質レベルが必要です。つまり、アップデートの作成チームがその適用先システムのことを知らなくても、アップデートとシステムの相互作用によって脆弱性が生じないことをアップデート作業者が確信している必要があります。

　アップデート作業者は、システムのコードを置き換える前に、新しいコードが正当なソースから受信したものであること、受信したものとソースが送信したものが完全に同じであることを確認したいと考えます。それには、一般にアップデートに強力なハッシュコードの透かしがあり、認可された発行当事者の署名があり、暗号化されている必要があります。アップデートを受信したシステムは、インストールする前に復号し、署名とハッシュコードを検証しなければなりません。

　しかし、この復号と検査のプロセスは信頼できるものでしょうか。

　信頼するには、それを実行するソフトウェアと、コードを実行するハードウェア（ハードウェア暗号アクセラレータ、チップ内蔵バスなど）をいずれも信頼しなければなりません。このような問題は、セキュアハードウェア領域に入り込むものです。

　この世界でも信頼のソースという概念は同じですが、危険度は高くなります。ハードウェア設計とアップデートは困難であり時間を要します。ツールチェーンはさらに複雑化し、関与する当事者が増えます。物理的な攻撃の他に論理的な攻撃もあります。ハードウェアの攻撃は困難で高いコストを要するため、ハードウェアを守るということは、最も高いスキルを持ったしつこい敵に立ち向かうことになります。