システム・セキュリティ:中世史からのモデル

あるセキュリティ専門家が述べたように、システム・セキュリティはモノではなくプロセスです。ネットワークとの接続、しかも敵対的な接続がますます増える環境ではセキュリティに新しい攻撃が行われ、新しい対抗策が生まれ、続いてより革新的な新しい攻撃が生まれるという連続的なケースが起きています。冷戦の軍拡競争が交戦国のリソースを疲弊させたのと同じように、この新しい課題が脆弱なシステムに要求するリソースは増え続ける一方です。

代替可能なコンピューティング・リソースを大量に整備したデータセンターでも、このリソースの枯渇は大きな問題となりますが、専用リソースが厳密に制限されることが多いエンベデッド・システムでは、セキュリティが克服できない障害になることがあります。また、モノのインターネット (IoT) が先進国世界の重要なインフラストラクチャ全体に広がる中で、これらのシステムでのセキュリティの必要性が文字どおり生死にかかわる問題になってきています。したがって、エンベデッド・システムの設計者は、データセンターのアーキテクトと同じように、この進化し続ける対立を理解することが不可欠です。

セキュリティの 3 段階

システム・セキュリティは 3 つの異なる段階に分けて追求できます。この区分は、システムのさまざまな領域に焦点を当てる物理的な機能を果たすとともに、設計者は問題の複雑さを理解するにつれて段階を順番に進める傾向があるので時間的にも機能します。また、段階を軍事的な話に例えるのがわかりやすいでしょう (図 1)。

1. 11 世紀のバンバラ城が、現代のシステム・セキュリティの背後にある原理を明確に説明します。

Eleventh-century Bamburgh Castle presents a clear illustration of the principles behind modern system security.

段階は、境界の保全、内部セキュリティ、および能動的なセキュリティからなります。手短に言えば、境界の保全技法は、城を囲む環状の壁と同じように攻撃がシステムに侵入しないようにするものです。内部セキュリティ対策は、城壁に設けられた塔、迷路、最終的には城壁を突破した攻撃者を打ち破るための天守閣と同じように、攻撃がシステムに侵入した場合に被害を最小限に抑えようとします。能動的なセキュリティは、城の護衛隊による城壁内外の巡回、待ち伏せ、敵の軍勢に対する襲撃、対敵坑道と同じように、システムのあらゆる場所で攻撃を特定して無力化します。

城壁には警備隊が必要であり、城壁がなければはるかに大きな警備隊が必要になるように、現実世界でのシステム・セキュリティの段階はすべてが連動し、相互依存しています。しかし、ここでは明確化のため、および不運なシステム設計者は前の段階が役に立たないことがわかるまで次の段階を実装しない傾向があるため、各段階を別々に調査します。これは、将軍が無防備な壁を築き、壁を乗り越えられたら塔と天守閣を造ってこん棒や熊手を手にした市民を配置し、2回負けて初めて兵士や将校を雇い、武装して訓練するようなものです。

境界の守り

財宝を保護する最も直感的で分かりやすい方法は、その周りに壁を築くことです。この方法は軍事史でもシステム・セキュリティでもほとんど成功した例がありませんが、政治家やシステム設計者はこの方法になぜか惹かれ続けています。したがって、対象とする攻撃、守るための技法、および守るのに必要なリソースといった境界の保全から検討し始める必要があります。

システム攻撃の基本形は別人になりすますことです。攻撃者は、データの読み書き、コードの実行、またはシステム更新の権限を持つユーザーのふりをします。そのような攻撃を阻止するには、認証 (通常はパスワードや証明書による身元の証明) を相手に求める必要があります。

しかし、トランザクションをモニタしていれば、誰でも簡単にパスワードをコピーできます。したがって、多くの場合、システムはパターンを変えてパスワードを暗号化し、暗号化されたパスワードさえ盗んで再利用するようないわゆる介入者攻撃を防止します。

これでもまだ不十分です。介入者は、価値が高いデータを閲覧するだけで盗んだり、システムに送信されるコードやデータを破壊させたりできます。そのため、多くのアプリケーションでパスワードだけでなくトランザクション全体を暗号化することが重要です。多くの場合、このレベルのセキュリティは TLS (SSL (Secure Socket Layer) の後継機能である Transport Layer Security) や IPsec によりインターネット上で提供されます。原理的には、鍵が盗まれない限り、これらのプロトコルによってトランザクションの内容の読み取りや改ざんが防止されます。しかし、この 2 つには大きな違いがあります。

よく使用される https のセキュア・ウェブ接続の基本である TLS は、TCP (Transmission Control Protocol) 上のレイヤ 4 で動作します。したがって、ブラウザなどのアプリケーションに実装できます。レイヤ 3 で動作する IPsec はオペレーティング・システムのカーネルでサポートする必要があるため、TLS ほど普及していません。IPsec が TLS よりセキュアであることはほぼ間違いありませんが、今日では主に企業の仮想プライベート・ネットワーク (VPN) に使用されているだけです。さらに強力なイーサネット・トラフィックの 3 つ目の暗号化手段である MACsec は、パケット全体を暗号化して介入者に送信元、送信先、フォーマット、または内容を知られないようにします。しかし、MACsec はイーサネット・インタフェースのハードウェアを大幅に変更する必要があるため、まだ普及していません。

認証と暗号化のいずれにも、そもそも誰にも盗まれずに相手に暗号鍵をどのように渡すかという論理的な問題があります。この一般的な答えは公開鍵暗号です。残念ながら計算量の多いこのプロセスは、いずれも大きな乱数から導き出した鍵のペアを使用します。1 つは誰とでも共有できる公開鍵であり、もう 1 つは所有者が秘密にしなければならない秘密鍵です。

認証する場合、サーバーは秘密鍵を使用して証明書 (またはそのハッシュ) を暗号化し、暗号化したメッセージをクライアントに送信できます。その後、どのクライアントも対応する公開鍵でメッセージを復号化し、サーバーが秘密鍵の実際の所有者であることを確認できます。復号化で有効な証明書またはハッシュが生成されたら、対応する秘密鍵でデータが暗号化されていたことになります。信頼性を高める証明書の所有権を記録したレジストリに関する、さらなる詳細があります。残念ながら、証明書の登録維持に注意を払うサーバー・オペレータはあまりいないため、クライアントはメッセージを復号化できるだけで満足することがほとんどです。

トラフィック自体のセキュリティのプロセスはちょうど逆です。メッセージを公開鍵で暗号化するのは誰でもできますが、復号化できるのは対応する秘密鍵の持ち主だけです。

この非対称のアプローチにより、サーバーとクライアントの間で暗号化されていない秘密鍵を何らかの方法で最初に渡すことなく、情報を渡すことができます。しかし、暗号化/復号化は困難なタスクです。Barco Silex 社の Gregory Baudet 氏によれば、暗号化ソフトウェアで 1 つの短いデジタル署名をチェックするには、Cortex®-M3 マイクロコントローラで約 2.7 秒かかります。これは、Xeon コアで問題に対処できるデータセンターでは大きな問題ではありません。しかし、1 秒間に数百個の署名を受け取る可能性がある、ネットワークに接続されたエンベデッド・システムではハードウェア・アクセラレーションを行わない限り対処できません。クライアント/サーバー環境でも、TLS は公開鍵暗号のみ使用して秘密鍵の別のセットのやりとりを保護し、次にそれをはるかに効率的な対称鍵アルゴリズムに使用して実際のメッセージを保護します。

このいずれも、相手方、または TLS を使用している場合は経路上のインターネットのホップの 1 つが感染していれば、ユーザーを保護できません。そのため、境界の保全には、復号化された着信メッセージをスキャンして脅威がないことをチェックする最終防衛線が含まれる場合があります。これは、データセンターでは既知のウイルスに関連付けられたパターンの網羅的な検索である場合があります。また、メッセージの種類に限りがあるエンベデッド・システムでは、このタスクは単純なルール・チェックであることもあります。複雑さと速度に応じて、慎重に保護されたソフトウェア・タスクから専用ハードウェアの正規表現エンジンまで、あらゆるものがこのファイアウォールになる可能性があります。

内部セキュリティ

軍事史には、突破された壁や破壊された要塞の残がいが散らばっています。今日、セキュリティ侵害の恐ろしい事例が積み重なる中で、データセンターのアーキテクトは境界防衛では不十分であることを認めるようになってきました。データセンターのシステムは、境界内部にすでに侵入した攻撃に対してセキュアでなければなりません。エンベデッド・システムでもますます同じことが言えるようになっています。

内部にある脅威は、システムの外部防衛を何らかの方法で突破した攻撃と考えるのが自然です。しかし、Edward Snowden による告発以降、内部関係者による脅威という別のシナリオが注目されるようになりました。多くの産業、インフラストラクチャ、交通システムなど、価値が高いターゲットを攻撃する最も簡単で確実な方法は権限を持つ内部ユーザーを動かすことかもしれません。システムに自由に入れるようになるパスワードや証明書を持つ内部関係者はすでに最初の防衛線をすり抜けているため、すぐにマルウェアの挿入やデータの盗み出しに取り掛かることができます。内部セキュリティの焦点は、このような内部関係者の脅威にますます移っています。

内部セキュリティの中心的なタスクは、おそらく不正なコードの実行を防ぐことでしょう。同様にして、このタスクは、セキュアなブート・プロセスから始まります。最終的にシステムは、何かが実行される前に改ざん防止ハードウェアでブート・コードを認証しなければなりません。同様にして、ブート・コードは、オペレーティング・システムに制御を渡す前にそのコードを認証しなければなりません (図 2)。多くの場合、このプロセスにはキー・ストアへのアクセス、アドレス空間へのアクセス、およびアプリケーション・コードの認証を管理する、認証された特権コードを実行する信頼されたモードの作成などが含まれます。

2. セキュアなシステムのブートには一連のセキュア・イベントが必要です。

A chain of secure events is necessary to boot a secure system.

この中で最も慎重に扱うべきタスクは鍵の保護です。多くの場合、データセンターのキー・ストレージ、鍵管理、および暗号化アクセラレーションは、いずれもサーバーから切り離された 1 つの専用ハードウェア・セキュリティ・モジュールに置かれます。そのようなモジュールが、アクセス制御、暗号化、および不正操作防止機能を提供します。エンベデッド・システムではキー・ストレージ問題がはるかに困難になります。ハードウェア・セキュリティ・モジュールは、通常、コスト、サイズ、および消費電力に制約があるために実現できないことが多い一方で、財産や生命までもが危険にさらされる可能性があります。また、エンベデッド・システムは攻撃者に物理的に制御される可能性があるため、不正な読み出し要求だけでなくサイドチャネル攻撃と物理的な改ざんからキー・ストアを保護しなければなりません。

エンベデッド・システムの開発者は、制約によりシステム・プロセッサのアドレス空間内のどこかに鍵と暗号コードを保存せざるを得ない場合があります。その場合は、セキュアなブート・プロセス、およびシステム内のすべてのメモリ管理ユニットに独占的にアクセスする信頼された動作モードが極めて重要となります。当然ですが、信頼されないモードではデバイスから物理メモリに直接アクセスできないようにすることも同じように重要です。

これらの対策により鍵を保護できるだけではなく、内部セキュリティに関するその他のメリットもあります。信頼されるコードでのみタスクを初期化してメモリ・アクセスを許可できるシステムでは、ほとんどの種類のマルウェア攻撃を回避できる可能性が高まります。しかし、何者かがどこかで防御を突破する可能性は常にあります。

明白ではあっても、性能や経済性の点から無視されることが多い静的な最終防衛線は、ストレージ上のデータの暗号化です。格納データを暗号化していれば、それを読み書きしようとするタスクは有効な鍵を示さなければなりません。したがって、攻撃者はマルウェア・タスクを起動できても、許可されたタスクのストレージ暗号鍵へのアクセス権を手に入れる必要があります。ストレージを暗号化すると、フラッシュ・メモリ、ディスク、テープといった媒体を物理的に盗まれてもデータを保護できるという追加的な効果があります。

一方で課題もあります。復号化は、特にソフトウェアで行う場合にストレージ・アクセスのレイテンシを増加させます。さらに悪いことに、ソフトウェアによる復号化タスクは攻撃者にとって明らかに魅力的な標的です。これら両方の理由から、ハードウェア・ベースの暗号化が不可欠です。

また、暗号化の壁を配置する場所も問題になります。当然考えられる場所はディスクと DRAM の間です。しかし、ディスク・キャッシュ、さらにはメイン・メモリとして使用されるフラッシュ・メモリが増える中、不揮発性の共有メモリに平文のファイルを保存したいと本当に思うでしょうか。最もセキュアなシステムではプロセッサの SoC 自体が暗号化サイトになるケースがあるため、DRAM 内のデータでさえ暗号化されます。唯一の平文バージョンはオンチップ・キャッシュにしかありません。このアプローチは、SoC のデザインとシステムの性能に大きな影響を与えます。

最後に抑止力があります。内部関係者の脅威からシステムを完全に保護するのは不可能であっても、危険すぎて内部関係者が攻撃を仕掛けられないシステムにすることはできるでしょう。そのために、新しいタスクの起動やシステムへの/からのデータ転送などのマイルストーンに特に注目して、ユーザーまたはタスクごとに活動を追跡するシステムにします。その後、これらのログをアルゴリズムまたは人間による検査のいずれかで監査して疑わしい活動を特定できます。監査だけで攻撃を失敗させることはできません。しかし、内部関係者が脅威を及ぼすには、多くの場合、試行を繰り返してシステム防衛上の弱点を見つける必要があります。監査することによって、短期間では成功しにくい攻撃のリスクを高めることができるため、攻撃者はそのリスクを取らないようになります。

システム動作を事後にオフラインで精査する必要はありません。システム自体の動作をモニタして疑わしい活動への対抗策を講じることも可能なシステムを設計できます。この考え方から、セキュリティの第 3 レイヤである能動的な手法が導かれます。

能動的なセキュリティ

これまで説明してきた対策は基本的に受動的なもの、つまりシステム・リソースへのアクセスを阻止するか、または侵入者がリソースを使用できないようにするものでした。一方、セキュリティ違反が発生した前提で対抗策を講じる、というまったく異なる戦術を利用した 3 つ目の防衛カテゴリがあります。そのような対抗策であるスクラビング、モニタリング、および機械学習という 3 種類を取り上げます。この 3 つの本質は、いずれもセキュリティではなく信頼性とランダム故障検出の領域にあります。また、侵入はハードウェアの故障のように追跡されます。

スクラビングの考え方は単純です。セキュリティ上重要な状態がシステムに発生したらそれを頻繁に読み取り、ハッシュと照らし合わせて正当性を検証し、必要に応じてアラームを発したり状態を修正したりします。スクラビングの候補には、ブート ROM、CPU のセキュア・モードで実行されるすべてのコード、認証鍵、MMU とキャッシュ TLB のエントリ、FPGA の機能を決定する制御 RAM などがあります。改ざんを目的としたマルウェアから隔離された別のハードウェアでスクラビングを行わない限り、問題の無限ループを避けることは極めて困難です。

2 つ目のカテゴリは、システムを監視して悪さをしていないことを確認する動作モニタリングです。実際のところこのアプローチは、ホストがお客様のコードから予想される動作をまったく把握できない可能性があるデータセンターより、正しくない動作を明確に定義できるエンベデッド・システムにおいて、より利用価値が高くなります。

いくつかの高信頼性システムで使用される極端な例は、図 3 に示す三重化モジュールによる冗長性 (TMR) です。TMR では、動作が同じ (ただし、理想的には実装が異なる) 3 つのモジュールがロックステップで動作し、各ステップの結果を多数決で決定します。攻撃者がシステム動作に影響を及ぼすには、2 つの異なるモジュールが同じステップで同じように誤った結果を得るようにしなければなりません。

3. 三重化モジュールの冗長性により、モジュールの 3 つの独立した実装の結果を比較して正しい状態を多数決で決定します。

Triple module redundancy compares the results of three independent implementations of a module and takes a majority vote on the correct state

 

TMR には、3 つの完全なモジュールの他に比較、投票、およびエラー回復ハードウェアが必要です。これらがセキュアなハードウェアでなければ、冗長化による保護は投票または回復プロセスへの攻撃によって帳消しになります。モジュールを 2 つにすればコストの節約にはなりますが、システムはエラーを検出するだけで、オンザフライで訂正することはできなくなります。

コストを節約できる、ほかのアプローチもあります。冗長モジュールの代わりに、システムの状態と、許容可能な動作を完全に定義する一連のルールを重要なステップごとに比較するステート・マシンを作成するのです。このアプローチによって、許容可能な動作を簡潔に定義できるエンベデッド・システムの多くのコストと消費電力を節約できます。このアプローチはまた、不安全な行動を定義できる機能的に安全なシステムでも使用されます。しかし、適切なルール・セットを見つけ出すことは実際には極めて困難です。

ここで、現時点ではまだ実験段階にある 3 つ目の代替策であるディープ・ラーニングが登場します。システムの重要な状態変数をディープ・ラーニングのニューラル・ネットワークに接続します。このネットワークを、正常動作、既知の攻撃、およびランダムに挿入されるフォルトの組み合わせで訓練します。その結果得られたネットワークがどのように動作するかを知ることはできず、ネットワークが十分であるか、正しいかどうかさえ証明できません。しかし、複雑なシステムは人間が考え出したルール・リストより優れた性能を発揮するでしょう。言うまでもありませんが、訓練したネットワーク自体を攻撃から保護しなければなりません。

このような能動的な対策はどのレベルに適用すべきかという重要な問題が提起されます。チェックするモジュールは、個々のレジスタ、プロセッサ内部の機能ブロック、SoC 内部のプロセッサ全体、それともエンベデッド・システム全体という場合もあるでしょう。モジュールがきめ細かくなるほどコストは増加し、皮肉なことに攻撃によっては検出が困難になるものもあります。完璧に機能する CPU はマルウェアも完璧に実行してしまいます。全システムレベルでチェックするのは経済的かもしれませんが、許容できる動作の範囲を定義し、システム内部に損害を与える前に攻撃を発見するのがはるかに難しくなる可能性があります。

まとめ

境界の保全、極めて重要な資産の確保、および能動的なモニタリングという 3 種類の防衛方法を提起しました。外壁から城の砦、機動力のある護衛兵といった、中世の武将には珍しくない防衛方法ですが、ハードウェア機能の仮想化によって実現されたクラウド・データセンターが引き受けるセキュリティ上重要なタスクが増える中、これらの考え方はサーバー、ネットワーク、およびストレージ・ハードウェアでのイノベーションに見えます。エンベデッド・システムがますますミッションクリティカルになり、ネットワークに接続されるにつれて、これらの考え方はエンベデッド・システムにも導入されるでしょう。

城を守るために、準備しましょう。


CATEGORIES : All, Embedded system, System Security/ AUTHOR : Ron Wilson

Write a Reply or Comment

Your email address will not be published.