DDSセキュリティハード（ウェア）ウェイ-SGX：パート1（概要）

マルチパートのパート1シリーズ

ミッションクリティカルな産業用IoT環境を保護するには、システムやサプライヤー全体で、エッジからクラウドまで拡張できるセキュリティが必要です。 RTIは、OMG DDSセキュリティ標準の筆頭著者として、分散環境を保護するために必要な要件（および環境）を定義する上で主導的な役割を果たしてきました。 DDSセキュリティプラグインは、ネットワーク上のデータに対して堅牢でデータ中心のセキュリティメカニズムを提供します。 RTI Connext DDS Secureは、デバイスからクラウドまで、最適なパフォーマンスと効率を実現するための柔軟できめ細かいセキュリティを通じてシステムを保護する、実績のある信頼できる接続フレームワークです。

ただし、セキュリティは複雑な問題であると認識しています。 RTIはConnextDDSソフトウェアフレームワークで高品質のセキュリティを作成しましたが、私たちの研究チームは、IIoTにさらに堅牢なセキュリティを導入するために他の分野を検討しています。このことを念頭に置いて、セキュリティへの新しく革新的なアプローチを模索しているRTIResearchの作業の一部を皆さんと共有できることをうれしく思います。

このブログシリーズでは、セキュリティの専門家であるJason Upchurchが、ソフトウェアだけでなく、重要なアプリケーションがデータを処理する信頼できないシステムにセキュリティを提供するハードウェアメカニズムについても説明します。彼はセキュリティの限界を押し上げる精神で、RTIConnext®DDSMicroおよびSecurityPluginsのコンテキスト内でIntelSGX®を調査しています。

それでは始めましょう。

SGXとは何ですか、なぜそれが重要なのですか？

SGX（Software Guard Extensions）は、機密データを含むアプリケーションを実行するためのTEE（信頼できる実行環境）を提供するIntel ISA（命令セットアーキテクチャ）の拡張機能です。 IntelISAがIndustrialIoT（IIoT）を支配していないことは事実ですが、サーバールームで市場シェアを持っており、サーバールームはさまざまなIIoTアーキテクチャに組み込まれていることがよくあります。さらに重要なことに、これらのサーバールームデータ処理アプリケーションは、従来のIIoTエンドポイントよりも保護されたデータにアクセスできる可能性があるため、悪意のあるユーザーの価値の高いターゲットになる可能性が高くなります。したがって、SGXは、IIoTまたはその少なくとも一部を保護するのに非常に役立ちます。高セキュリティ環境を必要とするDDSユーザーやその他のアプリケーション開発者にとってSGXが重要である理由を探りましょう。

図1：Connext DDS Secure Inside SGX Space

有線のセキュリティでは不十分な場合があります

まず、秘密を共有する古典的なアリスとボブの学術的な例を見てみましょう。物語は、アリスとボブが直接会うことから始まり、悪意のあるイブがネットワーク上のメッセージを傍受することで進行し、秘密を共有するための実証済みの方法で終わります。これは、イブがすべてのメッセージを傍受した場合でも、安全な通信の基盤です。世界最大の侵入調査をいくつか実行したことで、「イブ」がネットワーク上の暗号化されたメッセージを傍受して秘密を収集するのを見たことがないと言っても過言ではありません。また、「イブ」はほとんどの場合、彼女が求めている秘密を手に入れていると確信を持って言えます。ネットワーク暗号化は堅牢であり、したがって攻撃の標的になることはめったにないため、これらの一見矛盾するステートメントは両方とも当てはまる可能性があります。

この問題を調べるために、イブがアリスとボブの間に座って、メッセージを自由に聞いたり操作したりできるシナリオを見てみましょう。このシナリオでは、アリスとボブが共有している秘密でお互いを信頼していると想定しています。ただし、この仮定は実際にはひどく欠陥があることがわかります。図2の教科書の図は、アリスがテクノロジーなしで離れた場所でボブと通信しているように見えるため、実際に問題を示しています。

図2：教科書のアリスとボブのコミュニケーション

状況の現実は、アリスとボブが通信できるようにするために何らかの形式のデバイスが使用されているということです。これは、私たちの仮定が私たちをより良くする場所です。コンピュータセキュリティには、トラステッドコンピューティングベース（TCB）と呼ばれる概念があります。簡単に言うと、TCBは、ソフトウェアを含むすべてのコンポーネント（個別およびシステムの両方）であり、ある種の処理を保護するために信頼する必要があります。私たちの古典的なアリスとボブのシナリオでは、距離を置いて秘密の共有を確保しようとしています。アリスがボブと秘密を共有することを信頼していると仮定しているのは事実ですが、彼女は彼のコンピューティング環境（および彼女）も信頼しています。実際のシナリオでは、これはさまざまなメーカーの数百のコンポーネントの集合であり、（a）数百万行のコードでオペレーティングシステムを実行している可能性があります。 （b）知らない人によってコード化されたアプリケーションでいっぱいです。 （c）攻撃者と自動伝播マルウェアの無料アクセスがシステムを自由に攻撃できるようにする、公開されているネットワークに接続されている可能性があります。これらのシステムは、控えめに言っても、信頼できるものとはほど遠いものです。

...この状況は、紙の壁のある家に精巧な錠をかけた鉄製のドアを建てるのと似ています。

有線での通信を暗号化するためにいくつかの新しくより良い暗号化スキームが推奨される場合、それはコンピュータセキュリティコミュニティの多くの人にとって冷笑的なユーモアの源です。結局のところ、暗号化についてまったく心配することなく、ソースまたは宛先からわずかな労力で完全にクリアに秘密を取得することができます。私はいつも、この状況は紙の壁のある家に精巧な錠をかけた鋼鉄のドアを建てるのと似ていると思っていました。

では、何をすべきでしょうか？業界における現在のアプローチは、重要なタスクを達成し、各コンポーネントを認証および/または測定し、システム内の他のコンポーネントからそれらを分離するために必要な最小限の実行可能なコンポーネント（ハードウェアおよびソフトウェア）を見つけることに主に集中しています。非常に基本的なレベルでは、このアプローチはTCBを縮小し、TCB内のコンポーネントが追加または変更されていないことを確認します。

エンドポイント（およびその間のすべてのポイント）でのセキュリティ

些細なことではありませんが、安全なコンピューティング環境を構築することが可能であるというコンピューティングの段階に到達したことに注意してください。問題は、現在の市場の需要は、安全な環境とは相容れない豊富なコンピューティング環境に対するものであるということです。 IIoTでも、豊富なコンピューティング環境の需要は、それらが提供する膨大な機能に対するものであるとは限りませんが、人気があり、十分にサポートされているため、開発と保守がはるかに安価です。したがって、大きなTCBの問題は、別のアプローチで保護できるデバイスに侵入します。この問題への回答として、業界は、豊富なオペレーティングシステムと（何らかの形で）分離されたTrusted Execution Environment（TEE）の両方を単一のデバイスで提供するシステムの設計に取り組んでいます。

ほとんどのTEE設計では、基本的に2つのオペレーティングシステムが1つのデバイスで並行して実行されています。リッチオペレーティングシステムは一般的なタスクを処理し、セキュアオペレーティングシステムは機密性の高いタスクを処理します。 TEE設計では、2つを切り替えることができます。多くの場合、スイッチはハードウェアでサポートされ、実施されています。信頼チェーンロードのルートなどの一般的な信頼メカニズムは、不正なコードが導入されていないことを確認するために安全な側で使用されます。

SGXはまったく異なります。安全な側のTCBでさえ、かなり大きくなる可能性があります。信頼のルートは、プログラムがロード時に変更されないことを保証するだけです。そのため、そのセキュリティは、信頼できる起動プロセスだけでなく、ロードされたすべてのプログラム（最小のOSを含む）のソフトウェア検証手法に依存します。 Intelは、TCBを根本的に最小化することに着手しました。 SGX対応プロセッサの攻撃対象領域は、CPUとアプリケーションです。 SGX環境で信頼する必要のあるOS、ファームウェア、ハイパーバイザー、その他のハードウェアまたはBIOSはありません。信頼できる必要がある唯一のソフトウェアは、アプリケーション自体です。 SGXは、通常の信頼できるブートとほぼ同じ方法で、そのアプリケーションの信頼できるロードを保証する方法を提供します。ただし、信頼チェーンの長さは、従来のセキュアなかなり長いチェーンではなく、3リンク（ルート認証、CPU、アプリケーション）のみです。ブートシステム。

図3：SGX環境での攻撃対象領域

私はIntelSGXとDDS + Securityを試してきました。私の目的は、SGXが有効になっているバニラUbuntu16.04の保護された領域でDDSアプリケーションを実行することです。アイデアは、DDSで保護された有線通信がUbuntu OSに到着し、SGXで保護されたスペースに渡されるというものです。 DDS保護は、保護されたスペース内で削除されます。次に、その保護された領域内のアプリケーションによってデータが操作される可能性があります。この保護領域は、OSおよびシステム上に存在する悪意のあるユーザー/ソフトウェアに対して不透明です。この操作はOSに対して不透明であるため（CPU保護/暗号化の組み合わせ）、結果はSGXスペース内のConnext DDS Secureで保護され、ネットワークに渡されます。したがって、CPUとアプリケーション以外のOSまたはシステムのどの部分にもデータが公開されることはありません。システムへのルート（またはルート+）アクセス権を持つシステム管理者または攻撃者は、横方向としてアプリケーションデータにアクセスできず、特権攻撃はSGXスペースにアクセスできません。

これは、このトピックについて深く掘り下げたマルチパートシリーズのパート1です。このトピックの詳細については、直接私に連絡してください。