Script - Trusted Computing Group IoT WG 共同議長 Steve Hanna Session:
期待が高まる IoT セキュリティ：標準化がもたらすもの
00:00:06.000 --> 00:00:11.000
みなさん、こんにちは！ (今回は)直接お会いできなくて残念です。
00:00:11.000 --> 00:00:25.000
来年は東京(JRF ワークショップ)に実際に参加したいと思います。(皆さんの前で直接講演したいと考えています。)
そこで、今回は(その前振りとして)IoT セキュリティの進展について(リモートにて)少しお話したいと思います。

00:00:25.000 --> 00:00:35.000
例えば、この 4 年間だけでも、IoT のセキュリティは進歩しています。

00:00:35.000 --> 00:00:49.000
私たち、TCG と標準化活動はは、このエリアをリードしてきました。(さて、)簡単に自己紹介から始めます。私は、Infineon の DE (Distinguished Engineer) Steve Hanna です。
Trusted Competing Group(TCG)では IoT ワークグループの共同議長を務めています。。
00:00:49.000 --> 00:01:00.000
本日は、いつくかの話題をお話したいと思います。まずは、現在私たちが実際に直面している IoT への脅威から始めたいと思います。
00:01:00.000 --> 00:01:10.000
私たちが常に目にしている攻撃と、その脅威に対抗するために提案されている新しい規制についてです。
00:01:10.000 --> 00:01:24.000
次に、IoT でで使われている"Trusted Embedded System"(信頼性の高い組み込みシステム)を構築するための基本的なテクニックや技術についてお話したいと思います。
00:01:24.000 --> 00:01:30.000
三番目に、サイバーレジリエンス(Cyber Resiliency)と堅牢性(ロバスト性、Robust)の最先端についてお話します。これらは、今までよりより安全な IoT を構築を可能にしています。

00:01:30.000 --> 00:01:37.000
00:01:37.000 --> 00:01:51.000
最後に、私たち Trusted Computing Group の標準(技術仕様)が、IoT の世界の多くの場所で採用され、その影響力の拡大についてお話しします。
00:01:51.000 --> 00:01:59.000
この TCG 標準とその使用方法についての詳細をご理解いただけると思います。
00:01:59.000 --> 00:02:12.000(これは録画されたビデオプレゼンテーションですが)私は今リモートで参加していて、最後に、質疑応答の時間を設けております。皆さんからの、(日本語・英語での)質問をお待ちしております。(皆様からの質問に、直に回答させていただきます。)
00:02:12.000 --> 00:02:26.000では、この数年かなり深刻になってきている IoT デバイスへの脅威と、その脅威に対抗するために提案されている規制の話から始めましょう。
00:02:26.000 --> 00:02:31.000(深刻さレベルは、)たとえば、冷蔵庫がスパムを送りつけるような状況にまでに進んでいます。
00:02:31.000 --> 00:02:50.000
さらに悪化している状況として、、医療機器への攻撃や、自宅のドアロックやセキュリティ
システム、そして今回のワシントン州で起きたような産業用 IoT デバイスへの攻撃もあります。
この、20 年以上前にワシントン州で起こったガスパイプラインの漏えい事件、そして、その後に起こった製鉄所などへの攻撃がありました。
また、自動車への攻撃もありました。たとえば、ミラーとバラセックはジープのハンドル操作やガソリンの停止をすることができました。これらは、全てリモートでのアタックです。
00:03:19.000 --> 00:03:28.000
高速道路を走行中へのこの車へのアタックもできました。
00:03:28.000 --> 00:03:32.000
幸いにも、これは、悪意のないジャーナリストによってなされた実験でした。

00:03:32.000 --> 00:03:37.000 しかし、悪人による重要インフラへのアタックもありました。
00:03:37.000 --> 00:03:44.000
00:03:44.000 --> 00:03:59.000
6 年前に行われたウクライナの電力網への攻撃や、その後攻撃により、真冬に電力網の一部を停止させ、人々を厳しい環境に追いやりました。
00:03:59.000 --> 00:04:06.000
そして、そのような事態を招いたのは IoT の脆弱性です。
00:04:06.000 --> 00:04:19.000
私が最も懸念しているのは、中東のガスパイプラインの安全システムを停止させた「Triton」というマルウェアです。
00:04:19.000 --> 00:04:28.000
実は、この安全システムへの攻撃は、あらゆる種類の安全装置に対しての汎用的な攻撃だったのです。
00:04:28.000 --> 00:04:34.000
この安全システムは、過圧や爆発などによる人命に人の命に関わるような事態を防ぐための最後のゲートなのです。
00:04:42.000 --> 00:04:55.000
そして、もし攻撃者がその安全システムを停止させることができるようであれば(実際に、そのようなことは可能だったようですが)、深刻な影響を与え、死や破壊を引き起こす可能性もあるのです。
00:04:55.000 --> 00:05:03.000
つまり、重要なインフラに次第に IoT が採用されるようになると
00:05:03.000 --> 00:05:09.000
セキュリティ対策をより高いレベルに引き上げるようにしなければなりません。
00:05:09.000 --> 00:05:16.000
このような危険な攻撃を防ぐのは、直接被害を受ける IoT システムだけではありません。

00:05:16.000 --> 00:05:34.000
実際、史上最大の分散型サービス拒否攻撃は数年前、Mirai ボットネットという殺人蜂のよ
うに襲ってくるたくさんの IoT デバイスからの攻撃によって、00:05:34.000 --> 00:05:44.000
銀行サーバーや DNS サーバーのようなインターネットインフラの重要な要素をダウンさせることができるのです。
00:05:44.000 --> 00:05:49.000
また、数年前、米国ではガソリンパイプラインの会社が攻撃され00:05:49.000 --> 00:05:59.000
東部でガソリン不足になったことがありましたね。
00:05:59.000 --> 00:06:09.000
このような攻撃は非常に多く、また深刻であるため、各国政府から注目されています。
00:06:09.000 --> 00:06:14.000
政府はこれらの IoT 攻撃が冗談ではないことを認識しています。
00:06:14.000 --> 00:06:32.000
このようなことは、一部の人に迷惑をかけるだけではありません。これらは、私たちの経済活動を支えている重要インフラへの脅威なのです。そのため、世界各国の政府は IoT のセキュリティに関する規制を導入しています。
00:06:32.000 --> 00:06:50.000
すでに施行されているものもありますが、まだ草案中のものもあります。これは本当に世界的な現象で、
00:06:50.000 --> 00:06:56.000
数年後には、世界中のほとんどの国が、少なくともいくつかの分野では、最低レベルの IT
サイバーセキュリティを確保するための要件を採用するようになると思います。
00:06:56.000 --> 00:07:13.000
実際、ここアメリカでは昨年、政府が購入するすべての IoT 機器に最低レベルのサイバー
セキュリティの機能を持つことを義務付ける法律が可決され、大統領令や国家安全保障に関する法律が制定されました。
00:07:13.000 --> 00:07:21.000

重要なインフラにも同様の規定を設けるよう求める覚書があります。
00:07:21.000 --> 00:07:28.000
そして、消費者向け IoT サイバーセキュリティのパイロットプログラムも開始しました。
00:07:28.000 --> 00:07:36.000
つまり、スマートホームからスマートファクトリー、スマートシティに至るまで、IotIoT の対象領域が広がっています。
00:07:36.000 --> 00:07:44.000(したがって)IoT のサイバーセキュリティに対する要求がますます強くなってきています。
00:07:44.000 --> 00:08:02.000
このような要求に応えるにはどうすればいいのでしょうか？トラステッド・コンピューティング・グループが開発した信頼性の高い組み込みシステムを構築するための技術は最適なアプローチであり、その技術は後ほどご紹介する通りです。
00:08:02.000 --> 00:08:20.000
00:08:02.000 --> 00:08:20.000 「信頼できるシステムの構築」とは、予測可能で、攻撃などのストレスがかかっても信頼できるシステム、経験に基づいて信頼できるシステム、つまり、「信頼できるシステム」を構築することです。
00:08:20.000 --> 00:08:37.000
あなたが使っているシステムが比較的安全で、あなたの知らないうちに危険にさらされていないことを知りたいと思うでしょうし、このセキュリティは基本的なサイバーセキュリ
ティに基づいている必要があります。
00:08:37.000 --> 00:08:46.000
このセキュリティは、アイデンティティやインテグリティといった基本的なサイバーセキ
ュリティの特性に基づいている必要があります。もし私たちが信頼できるシステムを構築するのなら、
00:08:46.000 --> 00:08:53.000
信頼できるコンポーネントの上に構築することで、それが実現できるのです
00:08:53.000 --> 00:09:06.000
そのため、私たちは"Root of Trust" ルート・オブ・トラスト (「信頼の基点」)、理想的にはハードウェアのルート・オブ・トラスト,強固に守られたセキュリティ機能です。
00:09:06.000 --> 00:09:13.000

また、十分なセキュリティレベルを担保しつつ、最小化されています。00:09:13.000 -->00:09:21.000
何百万行ものコードがある巨大な OS を考えた場合、少なくとも何千もの脆弱性が存在するはずです。
00:09:21.000 --> 00:09:34.000
セキュリティ機能を最小化し、強力に保護すれば、ほとんどの攻撃から守ることができます。
私たちはこのルート・オブ・トラストを使って、最も安全性の高いセキュリティに取り組んでいます。
00:09:34.000 --> 00:09:48.000
機密機能とは、乱数の生成や長期的な鍵の保管、さらには使用中の鍵の保管やシステムの検証、完全性などを指します。
00:09:48.000 --> 00:10:03.000
ルート・オブ・トラストの利点は、より大きく、より複雑なシステムに伴うリスクを軽減することができることです。
00:10:03.000 --> 00:10:11.000
複雑さはセキュリティの敵です。もし安全なシステムを作りたいのであれば、シンプルでなければならないのです。
00:10:11.000 --> 00:10:25.000
そして、その唯一の方法は、必要最低限で、攻撃に対して強化された、シンプルなルート・オブ・トラストから始めることなのです。
00:10:25.000 --> 00:10:32.000
そうすることで、長期的な鍵の漏洩や、システムが危険にさらされるリスクを減らすことができるのです。それも、おそらく検知されることはなく。
00:10:32.000 --> 00:10:41.000
なぜ私たちはこの信頼性の根源にハードウェアを使うのでしょうか、少なくともハードウェアを推奨するのでしょうか？
00:10:41.000 --> 00:10:49.000
それは、ソフトウェアのセキュリティが十分でないからです。数年前のハートブリード・アタックを覚えていますか？

00:10:49.000 --> 00:10:57.000
それは高度に信頼されたソフトウェアシステム・OpenSSL のいい例です。
00:10:57.000 --> 00:11:01.000
どこでも使われている、ごく基本的な脆弱性があることが判明しました。
00:11:01.000 --> 00:11:05.000
あるパケットに送るだけで、メモリのダンプを送信してくるのです。
00:11:05.000 --> 00:11:13.000
これは大規模なソフトウェアシステムで起こることの一例です。
00:11:13.000 --> 00:11:19.000
これだけの量のコードから脆弱性を見つけるのは簡単なことです。
00:11:19.000 --> 00:11:36.000
実際、このグラフは数十年にわたる研究に基づいて、平均的な欠陥、密度、1000 行のコードやファンクションポイントあたりのバグや欠陥の数を示しており、
00:11:36.000 --> 00:11:46.000
アメリカでの平均なので、これは世界的な平均値だと考えてよいと思いますが、1,000 行あたりのバグの数はだいたい 5 個くらいです。
00:11:46.000 --> 00:11:50.000
もし、ソフトウェアがだらだらと開発されたら、もしかしたらもっと多いかもしれません。
00:11:50.000 --> 00:11:57.000
でも、最高クラスのものだと、1000 行に 1～2 個くらいのバグに抑えられるんですよ。
00:11:57.000 --> 00:12:04.000
これは世界トップクラスのアビオニクスコード、宇宙船コードです。
00:12:04.000 --> 00:12:17.000
このレベルの投資と品質、そしてバグの数を減らすことで、0 にすることができると思うんです。
00:12:17.000 --> 00:12:24.000
しかし、それは不可能です。だから、私たちはそこに到達できないことを知っているのです。

00:12:24.000 --> 00:12:34.000
できる限り少なくして、ルート・オブ・トラストを最小化・単純化し、攻撃に対して強固にすることです。
00:12:34.000 --> 00:12:43.000
この図は、右に行くほど様々な攻撃に対する防御が強化されていることを示しています。
00:12:43.000 --> 00:12:53.000
ソフトウェア的なルート・オブ・トラストから、ファームウェア的な信頼ルート、ハードウ
ェア的な信頼ルート、そして安全なハードウェアをベースとした信頼ルートへと移行しています。
00:12:53.000 --> 00:13:08.000ですから、リスクが高まるにつれて、より安全な信頼の根、より安全な保護形態へと移行していくことをお勧めします。
00:13:08.000 --> 00:13:18.000
IoT に対してなぜこのようなことをするのでしょうか？なぜこれが必要なのでしょうか？
それは、IoT の世界では、まさにいろんな状況・種類が存在するからです。
00:13:18.000 --> 00:13:26.000
小さなものから大きなものまで、何千、何万、あるいはもっと多くのものがあります。
00:13:26.000 --> 00:13:36.000
そしてこれらのものは......修正するにも、そこに入るにも非常に困難なのです。
00:13:36.000 --> 00:13:41.000
そして、手動でパッチを当てたり、リセットしたりと言う。
00:13:41.000 --> 00:13:48.000
我々は本質的に安全なものを用意する必要があるのです。
00:13:48.000 --> 00:13:58.000
あの街灯を見てください。その街路灯を一つ一つ修正していたら、どれだけの費用がかかるでしょうか？
00:13:58.000 --> 00:14:02.000

修理のために、あの風車の上に乗るのにも、多額の費用が必要です。00:14:02.000 -->00:14:10.000
全ての風車に出向いてソフトウエアのアップデートや修理をしています。
00:14:10.000 --> 00:14:16.000
そして家庭でも。でも、あなたは、自宅では、それはあまり重要なことではないと考えるかもしれません。
00:14:16.000 --> 00:14:23.000
家庭の中で今、電子化されているもので、明日にはスマート化されるものを考えてみてくだ
さい。
00:14:23.000 --> 00:14:39.000
電源スイッチ、プラグ、電球、電化製品、それらすべてを保護する必要があります。
00:14:39.000 --> 00:14:44.000
パッチや修正プログラム、ウィルス対策などです。
00:14:44.000 --> 00:14:48.000
全ては本質的に安全で、しっかりと保護されている必要があるのです。
00:14:48.000 --> 00:15:03.000
消費者が心配する必要がないように、今日、すべてのものが電気的安全性の評価を受け、安全でないものの販売を許可しないのと同じように
00:15:03.000 --> 00:15:12.000
安全でないものを売ることは許されないのです。
00:15:12.000 --> 00:15:30.000
同じことが IoT にも当てはまります。つまり、様々な異なるアプリケーションにおいて、組み込みシステムのセキュリティはより高いレベルに引き上げられる必要があることがわかります。
00:15:30.000 --> 00:15:33.000
我々はコネクテッドカーを導入する予定です。
00:15:33.000 --> 00:15:37.000(このコネクテッドカーは)セキュリティの確保が必要です。銀行もセキュリティが必要です。

00:15:37.000 --> 00:15:46.000
産業用制御システム、などなど。あらゆる接続機器にセキュリティが必要です。
00:15:46.000 --> 00:15:57.000
このルート・オブ・トラストをどうするのか？いろいろと実装方法はあるのですが、ここでは一般的なものを紹介します。
00:15:57.000 --> 00:16:08.000
ただし、最後にリンクを貼っておきますので、信頼できるルートが提供するもっと曖昧なセキュリティ機能についても読んでみてください。
00:16:08.000 --> 00:16:20.000
デバイス・アイデンティティは最も基本的なもので、組み込みデバイスの多くは遠隔地にあります。
00:16:20.000 --> 00:16:30.000
そしてそこにはアクセスできないので、接続と認証が必要なのです。
00:16:30.000 --> 00:16:38.000
ネットワーク上の他の機器と安全に通信を行うためには、信頼性が必要です。
00:16:38.000 --> 00:16:44.000
そのためには、暗号化された ID を提供することが最適です。
00:16:44.000 --> 00:16:59.000
00:16:44.000 --> 00:16:59.000
典型的には、秘密鍵と一つ以上の証明書がそれです。
これらの秘密鍵や証明書は、ハードウェアベースの、ルート・オブ・トラストに格納しておく必要があります。たとえば、Trausted Platform Module (TPM)です。

00:16:59.000 --> 00:17:16.000。このようなデバイスにインストールされた ID は、様々な用途で使用することができ、デバイスが他のデバイスと認証する必要のある通信に使用することができます。
00:17:16.000 --> 00:17:26.000
00:17:16.000 --> 00:17:26.000 コマンドを送信できるようにするため アクセスコントロー

ルはその ID を使ってコマンドに従うかどうかを決めることができます。
00:17:26.000 --> 00:17:42.000
あるデバイスが別のデバイスにコマンドを送る場合、どのデバイスを管理しているのかを知ることは非常に重要です。
00:17:42.000 --> 00:17:58.000
また、適切なリモート管理端末からコマンドを受信していることを確認することも重要です。偽造デバイスの検出も、デバイス・アイデンティティの重要な利用法のひとつです。偽装デバイスは、攻撃的な物より、脆弱だったり低い品質であったりしますが。
00:17:58.000 --> 00:18:02.000
00:17:58.000 --> 00:18:02.000
00:18:02.000 --> 00:18:10.000
消費者、つまりデバイスを購入する人は、支払った金額に見合ったものが得られるかどうかを確認したいものです。
00:18:10.000 --> 00:18:22.000
そして、適切なライセンスを持っているデバイスだけが特定のサービスを利用できるようにしたいと思うかもしれません。
00:18:22.000 --> 00:18:28.000
00:18:22.000 --> 00:18:28.000
今、セキュアな通信と言いましたが、それはどういう意味でしょうか？
00:18:28.000 --> 00:18:35.000
2 つのデバイスが信頼できないネットワーク上で通信を行う場合、その通信は常に安全でなければなりません。
00:18:35.000 --> 00:18:40.000
00:18:35.000 --> 00:18:40.000
昨今のネットワークは無線であるため、信頼できない可能性があります。
00:18:40.000 --> 00:18:46.000
そこで認証が必要な通信の機密性を保護する必要があります。
00:18:46.000 --> 00:19:03.000

通信においては、その間に第 3 者が存在しないことを確認し、そして特定のコマンドを送信する、また、特定のセンサーデータを送信することが承認されていることを確認するために、通信の承認状況を確認する必要があります
00:19:03.000 --> 00:19:10.000
さらに通信が改竄されていないことを確認するために通信の完全性を保護する必要があります。
00:19:10.000 --> 00:19:23.000
リプレイプロテクションは、玄関の鍵を開けるコマンドを記録し、後でそれを再生することができないようにするためのものですが、その手段を提供する必要もあります
00:19:23.000 --> 00:19:32.000
そうなると完全な前方秘匿が必要になってきます。
00:19:32.000 --> 00:19:45.000
それは、たとえ誰かが通信を記録し、その後に LTK（Long Terms KEY）を入手したとしてもその通信を解読することができないようにする機能です。
00:19:45.000 --> 00:19:50.000
つまり、これが長期的な機密保護というわけですね。
00:19:50.000 --> 00:20:08.000
組み込みシステム環境では、クラウドやピアツーピアであっても、TLS や DTLS といったプロトコルで T ベースの ID を使用し、安全な通信を行うことをお勧めします。
00:20:08.000 --> 00:20:13.000
基本的には、TPM ベースの ID を使用した認証を実行することができます。
00:20:13.000 --> 00:20:20.000
また、セキュアな通信を行うのであれば、今 TPM に格納されている ID を信頼のルートとして利用し、他のデバイスを認証することも可能です。
00:20:20.000 --> 00:20:25.000
00:20:25.000 --> 00:20:35.000
強力な乱数生成が必要です。TLS のような暗号化プロトコルは、基本的に高い品質が要求されます。

00:20:35.000 --> 00:20:42.000
セッションキー、ノンス、初期化ベクター、その他必要不可欠な要素を生成するための乱数です。
00:20:42.000 --> 00:20:51.000
このような高品質な乱数を目的別に生成するのがベストです。
00:20:51.000 --> 00:20:58.000
そのために必要とされているのは、TPM に搭載されている真正乱数発生器です。
00:20:58.000 --> 00:21:02.000
この乱数はパスワードのようなものだと覚えておいてください。
00:21:02.000 --> 00:21:05.000
乱数を推測することができれば、プロトコルを破ることができるのです。
00:21:05.000 --> 00:21:11.000
まあ、実際、LTK（Long Terms KEY）を見つけることはできるでしょうけど。
00:21:11.000 --> 00:21:20.000
残念ながら、乱数は組み込みシステムで簡単に得られるものではありません。組み込みシス
テムには乱数の多様性を組み込むことは難しいのです。
00:21:20.000 --> 00:21:29.000
キーボードをクリックしたり、マウスを動かしたりするユーザがいないので、ＰＣのように
ランダム性を持たせることができません。
00:21:29.000 --> 00:21:41.000
そこでシステム自身が内部でランダム性を生成する必要がありますが、ソフトウェアだけ
では真の乱数を発生させるという役割を果たせません。

00:21:41.000 --> 00:21:49.000
ハードウェアが必要なのです。TPM は典型的に、また良質な、乱数性を発生させる強力なハードウェアを備えています。
00:21:49.000 --> 00:21:56.000

エントロピーとも呼ばれるもので、ソフトウェアの更新を安全に行うには良い方法なのです。
00:21:56.000 --> 00:22:05.000
私たちはこのことについてよく話題にしています。ソフトウェアや組み込みシステムのアップデートことを考えると不安になりますよね。
00:22:05.000 --> 00:22:10.000
ああ、それ！？もし、それが間違っていたら？その時は問題が起こるでしょうね。
00:22:10.000 --> 00:22:15.000だから、強力で安全な更新メカニズムが必要なんです。
00:22:15.000 --> 00:22:22.000だから、携帯電話のアップデートが必要なように、パソコンのアップデートが必要なように、そのアップデート機構を持たなければなりません。
00:22:22.000 --> 00:22:34.000
組み込みシステムも、うまく動いているものに単に機能を追加するだけでなく、バグを修正するため、あるいはセキュリティの脆弱性を修復するためにソフトウェアをアップデート
しなければなりません。
00:22:34.000 --> 00:22:51.000
もし、あるデバイスにセキュリティ上の脆弱性が発見された場合、あるいはそのデバイスに組み込まれているソフトウェア・ライブラリに脆弱性が発見された場合、デバイス自体にパッチが適用されていなければ、非常に脆弱な状態になる可能性があるからです。
00:22:51.000 --> 00:23:03.000
攻撃者はパッチが利用可能になると、すぐにリバースエンジニアリングを行い、何が問題だ
ったのかを突き止め、その問題に対する悪用方法を開発します。
00:23:03.000 --> 00:23:11.000
このようなオープンソースのライブラリが使われる組み込みシステムが増えてきて、昔対処したような事例が多くなってきたと思うのです。
00:23:11.000 --> 00:23:27.000
つまり、攻撃者がオープンソースライブラリの脆弱性を知り、見つけ、そしてそのライブラ
リが何千もの異なる製品で使われていることを知り、すべての製品でそれを悪用しようとし始めるというような攻撃の可能性を残しているのです。
00:23:27.000 --> 00:23:37.000
そして、そのライブラリが何千もの製品で使われていることを突き止め、それを利用して製品に感染させようとするのです。ですから、強力で安全なアップデート機構が必要なのです。
00:23:37.000 --> 00:23:50.000
幸いなことに、TCG は安全なアップデート機構を構築する方法、ソフトウェアやファーム
ウェアの組み込み方法を説明する素晴らしいドキュメントを書いています。
00:23:50.000 --> 00:24:05.000
この文書はかなり徹底的でかつ包括的なもので、安全なアップデートを作成し、それをインストールするためのすべての段階をカバーしており、ソフトウェア開発からアップデート
への署名、配布、インストール、更新プログラムの署名、配布、インストール、そしてリモート・アテステーションなどを用いて正しくインストールされたかどうかの検証についてまでが書かれています。
00:24:05.000 --> 00:24:13.000
00:24:05.000 --> 00:24:13.000
00:24:13.000 --> 00:24:17.000
皆さんも多段階で行われるこのプロセスをよくご存じでしょう。
00:24:17.000 --> 00:24:28.000
最近ソフトウェア開発をしたことがあるが、おそらくリモート・アテステーションはあまりしたことがないという方のために、リモート・アテステーションについて少しお話しします。
00:24:28.000 --> 00:24:35.000
これは TPM 独自のものですし TCG 独自のものでもあります。
00:24:35.000 --> 00:24:54.000
20 年以上前に開発されたものです。そのコンセプトは、もしあなたが組込みシステム、あるいは他のシステムのうち、特にネットワークに接続された組込みシステム、例えば IoT デ
バイスのようなもの扱っているのであれば、そのシステムあるいはそのデバイスが最新のパッチ、最新のソフトウェア・アップデート、ファームウェア・アップデートをすべて持っていることを確認するための検証を行えるようにしたいということです。
00:24:54.000 --> 00:25:04.000

00:25:04.000 --> 00:25:09.000
どうやってそれを確認しましょうか？そうですね...... インストールされているソフトウェ
アのバージョンを教えてくださいというコマンドを送ればいいんです。
00:25:09.000 --> 00:25:26.000
問題は、もしソフトウェアがマルウェアに感染していた場合、実際は最新パッチが適用されておらず、改ざんされているにもかかわらず、バージョン番号を偽って、最新のパッチが適用され、インストールされていると主張する可能性が高いということです。
00:25:26.000 --> 00:25:34.000
00:25:34.000 --> 00:25:34.000
00:25:34.000 --> 00:25:49.000
つまり、デバイスのソフトウェアがバージョン番号を教えてくれというのは、道にいる誰かに対し「あなたは犯罪を犯していますか」と尋ねるようなものです。
00:25:49.000 --> 00:26:02.000
犯罪者でなければもちろん違うと言いますし、もし犯罪者でも、「違うよ」とウソをつくかもしれない。
00:26:02.000 --> 00:26:21.000
00:26:02.000 --> 00:26:21.000
安全を確保するために行う、本当に正しい方法は。インテグリティを実行し、そのインテグ
リティを測定し、ロードされた各モジュールのバージョンを測定し、どのバージョンのファームウェアとソフトウェアがロードされたかを安全に検証する方法を持つことです。
00:26:21.000 --> 00:26:28.000
そこでこのようにＭＡＣが存在し、それは Trusted Computing に不可欠なのです。
00:26:28.000 --> 00:26:32.000
メジャーブートという方法で、画面の左側にあるリモートアテストレーションという方法です。
00:26:32.000 --> 00:26:51.000
計測されたブートプロセスが見えますね。ここでブート ROM を用いて測定とロードを実行し、値を測定して、測定した BIOS の HASH 値を TPM に保存しています。その後 BIOS
が起動します00:26:51.000 --> 00:26:55.000
BIOS がしばらく実行されのちに OS をロードします。
00:26:55.000 --> 00:26:59.000
BIOS は OS を測定し、TPM にハッシュ値を入力します。
00:26:59.000 --> 00:27:05.000
そして、OS の実行を続けます。そして、同じことがスタックまで続きます。
00:27:05.000 --> 00:27:08.000
これは単純化したものです。ここには何層ものレイヤーが存在する可能性があります。
00:27:08.000 --> 00:27:14.000
しかし、これらは全て TPM に格納されるのです。
00:27:14.000 --> 00:27:20.000
あるいはハッシュ化されて保護されるログに開始され、TＰＭに格納します
00:27:20.000 --> 00:27:32.000
時間がたつと TPM.はチャレンジを送信するリモートのベリファイアと安全に通信することができるようになり、TPM.はそのチャレンジに対する署名されたレスポンスを送り、リモートのベリファイアは TPM は本物でリプレイされていないという内容の証明を検証することができます。
00:27:32.000 --> 00:27:46.000
00:27:46.000 --> 00:27:52.000
00:27:46000 --> 00:27:52000
なぜなら最新の nonce を持っていることを確認し、TPM による計測結果であることを検証できるからです。
00:27:52.000 --> 00:27:59.000
00:27:52000 --> 00:27:59000
また TPM による署名は、ソフトウェアまたはファームウェアの有効性、または最新であることを表しています。
00:27:59.000 --> 00:28:16.000

これが、測定ブートとリモート認証がどのように稼働するか、また、IoT クラウドなどのリモート検証者に、デバイスの健全性を常時監視することを可能にするかを表したものになります。
00:28:16.000 --> 00:28:21.000
これはセキュアードブートと計測（メジャー）ブートと連動して動作します。
00:28:21.000 --> 00:28:25.000
計測ブートかセキュアブートか、どちらか一方だけではありません。
00:28:25.000 --> 00:28:35.000
両方です。セキュアブートはブートの初期段階には有効です。
00:28:35.000 --> 00:28:55.000
しかし、どのバージョンのソフトウェアがそのデバイスにロードされたかを正確に知るための証拠がありません。計測ブートを実行しデバイスにロードされたソフトウェアのバー
ジョンを正確に証明できることによって、デバイスの動作の信用を確立ことができるのです。
00:28:55.000 --> 00:29:02.000
00:29:02.000 --> 00:29:14.000
これらすべては計測ブートやリモート・アテステーションのできる TPM や DICE、あるいは MARS といった何かを持つことに依存します。
00:29:14.000 --> 00:29:19.000
既に説明した全てのことに加えて......
00:29:19.000 --> 00:29:26.000
あなたの TPM は、パスワードや認証キーのような秘密を保護するために用いることができます。
00:29:26.000 --> 00:29:28.000
ちょうど、産業用制御システムにあるようなものです。
、
00:29:28.000 --> 00:29:41.000
コカ・コーラのレシピのような秘密の公式や設定のように特殊な処理のために最適化されたコードです。

00:29:41.000 --> 00:29:56.000
これらはすべては TPM に保存され、例えば既知のバージョンのファームウェアが実行されているなど、プラットフォームが特定の状態になった時、TPM は解読を行うように命令を受けます。
00:29:56.000 --> 00:29:58.000
00:29:56.000 --> 00:29:58.000 その際に、自由に前提条件付きのパラメータを設定することもでき、00:29:58.000 --> 00:30:04.000
そして、ＴＰＭはそれら設定された状況下でのみ、秘密を公開します。
00:30:04.000 --> 00:30:16.000
大量のデータを保存・保護するのであれば、ＯＰＡＬドライブを使えばいいでしょう。
00:30:16.000 --> 00:30:32.000
これは TCG が作成した自己暗号化ドライブ規格で、オパール・ドライブのロックを解除するのに必要な鍵を TPM を使って保護することができます。ですので、何ギガバイトのデー
タでも00:30:32.000 --> 00:30:39.000
ＯＰＡＬドライブに保存さし、TPM で保護することができます。
00:30:39.000 --> 00:30:58.000
このＴＰＭはアンロックキーしか開放しません。特定のバージョンのソフトウェアのロード、機密の提示、その他さまざまなＴＰＭに適応するだろうポリシーに応じてです。
00:30:58.000 --> 00:31:07.000
さて、ここまでＴＰＭやＤＩＣＥ、ＭＡＲＳが提供できる様々な保護機能を一通り見てきました。ＤＩＣＥとＭＡＲＳはより
00:31:07.000 --> 00:31:21.000
TCG が最近開発した、組み込みシステムに適した軽量版の TPM のです。さて、ここからは本当の意味での最先端を紹介します。
00:31:21.000 --> 00:31:27.000
これはサイバーレジリエンスとロバストネス（堅牢）です。
00:31:27.000 --> 00:31:37.000

伝統的にコンピュータ・セキュリティについては、3 つの段階で考えられてきました。つまり、プロテクト（保護）とデテクト（検知）とリカバー（回復）です。
00:31:37.000 --> 00:31:47.000
しかし、従来のコンピュータ・セキュリティで重視されてきたのは、プロテクト（保護）とデテクト（検出）でした。
00:31:47.000 --> 00:31:52.000
我々は３つすべてを重視しています。そのデータをどのように暗号化するか、それが保護です。
00:31:52.000 --> 00:31:56.000
どうやって悪者を排除するのか。......それは重要ですよね
00:31:56.000 --> 00:32:01.000
デテクト（検知）について考えてましょう。悪者が入ってきたらどうするか？

00:32:01.000 --> 00:32:06.000
恐らく悪事を働かれる前に検知できるはずです
00:32:06.000 --> 00:32:12.000
これはプラットフォームの侵入検出やシステムとなります。
（保護と）同様に、検出が必要ですね。
00:32:12.000 --> 00:32:17.000
ハニーポットやハニーネット（本物のシステムをハッカーから守るために設置するおとりサーバーやネットワーク機器）のようなものであっても、プロテクション（保護）は必要です。
00:32:17.000 --> 00:32:22.000
しかし、リカバリー（回復）についてはどうでしょうか？リカバリーは......ある意味
00:32:22.000 --> 00:32:31.000
損な役回りとでも言いましょうか。リカバリー（回復）は今、ＴＣＧにとってそして世界中の政府にとって、新たな焦点となる分野です。
00:32:31.000 --> 00:32:36.000

00:32:36.000 --> 00:32:36.000
00:32:36.000 --> 00:32:48.000
ゼロトラストアーキテクチャという言葉を聞いたことがあるかもしれません。ゼロトラス
トアーキテクチャとは、悪者が最終的に侵入してくることを想定しているということです。
00:32:48.000 --> 00:33:04.000
つまり、悪者が実際に侵入したとしても、侵入を検知し、システムを保護し、感染から回復させられるように備える必要があります。このようなことは、我々セキュリティ関係者にとって、あまり考えたくもないとことです。
00:33:04.000 --> 00:33:10.000
そのようなことが起こらないように、侵入される前に食い止めたいのです。
00:33:10.000 --> 00:33:26.000
しかし、知っての通り、それは不可能です。完璧に安全なものを作ることはできません。悪者は侵入してきますし、少なくともその可能性はあります。どうやって侵入者を追い出すか知っておく必要があるのです。
00:33:26.000 --> 00:33:40.000ですから、サイバーレジリエンスでは、人体が皮膚で感染症から身を守るように、ＩｏＴのための免疫システムを構築しているのです。
00:33:40.000 --> 00:33:45.000
つまり皮膚が人体を感染から保護し、もし皮膚が破れて感染したら、それを検出することができます。
00:33:45.000 --> 00:33:58.000
そして、検出だけでなく、人体には感染症を排除して回復する能力も備えているのです。
00:33:58.000 --> 00:34:04.000
同じ能力を IoT システムにも搭載するには、どうすればいいのでしょうか？
00:34:04.000 --> 00:34:14.000
まず、あるハードウェアをベースにしたトラステッド・コンピューティング上で動作する正常なアプリケーション・コードを始点とし、それをレジリエンスとします。

00:34:14.000 --> 00:34:19.000
これが我々が保護しようとしているものです。
00:34:19.000 --> 00:34:38.000
そして、レジリエンス・エンジンを追加します。レジリエンス・エンジンとは、修復のアクションを行うためのものです。おそらく、検知も同様に行います。そして、この
00:34:38.000 --> 00:34:57.000
レジリエンス・エンジンをレジリエンス・オーソリティに接続します。これには見覚えがあるかもしれませんが、クラウドにあるように見えますし、ＩｏＴのアーキテクチャと非常によく一致しています。
00:34:57.000 --> 00:35:15.000
レジリエンス・エンジンを追加したデバイスを監視できるセントラル・オーソリティがクラウド上にあり、
レジリエンスオーソリティがデバイス上であらゆる種類の高度な機能をトリガーする機能があり、00:35:15.000 --> 00:35:24.000
00:35:15.000 --> 00:35:24.000 機器を再起動したり、工場出荷時の設定に戻したりすることができます。
00:35:24.000 --> 00:35:34.000
また、端末がマルウェアに感染していても、アップデートすることができます。
00:35:34.000 --> 00:35:39.000
さて、あなたが組み込みシステムの開発者であれば、こう思うかもしれません。
00:35:39.000 --> 00:35:45.000
どうすればいいんだ？もしマルウェアがそのデバイス上で動いていたら、どうやってコン
トロールするんだ？
00:35:45.000 --> 00:35:49.000
テンショントリガーには様々な方法があります。
00:35:49.000 --> 00:35:56.000
これはできます。ウォッチドッグタイマーが典型的な例です。

00:35:56.000 --> 00:36:00.000
特に、私たちはこの場合、認証されたウォッチドッグタイマーを使用します。
00:36:00.000 --> 00:36:07.000
そして、これはデバイスが正常に動作している限り、保証するものです。
00:36:07.000 --> 00:36:14.000
そして、消去して再設定する必要はないのです。
00:36:14.000 --> 00:36:31.000
しかし、もしレジリエンスオーソリティがデバイスの感染の兆候を検知したり、デバイスがレジリエンスオーソリティに一定期間チェックインしなかったりすると、ウォッチドッグ・
タイマーが無効になってしまいます。
00:36:31.000 --> 00:36:39.000
レジリエンス・エンジンが制御を回復し、レジリエンス・オーソリティと通信してどのような救済措置をとるかを決定します。
00:36:39.000 --> 00:36:57.000
そして必要なのは復旧です。つまり、この、あるいはサイバーレジリエンス機能は、長い間議論されてきたもので、高い可用性システムで使われているものですが、スケールダウンしたバージョンで利用するようになってきます。
00:36:57.000 --> 00:37:15.000
00:36:57.000 --> 00:37:15.000 ＩｏＴデバイスにとって非常に魅力的で、わざわざ再起動や再インストールをしなくてもシステムのセキュリティに自信を持つことができます。
00:37:15.000 --> 00:37:23.000
そして、常にマニュアルな方法でクリーンな状態を保とうとするのです。
00:37:23.000 --> 00:37:34.000
このように、私が既に述べてきた全ての魅了的な技術のおかげで、ＴＣＧの標準の影響力は広く知れ渡っているのです。
00:37:34.000 --> 00:37:41.000
例えば、産業用サイバーセキュリティの標準規格を見てみましょう。
00:37:41.000 --> 00:37:47.000

ISA/IEC62443、この標準! なんという素敵な名前でしょう
00:37:47.000 --> 00:38:00.000
国際自動化学会と国際電極技術委員会から生まれたもので、産業界を想定して設計されたものなんです。
00:38:00.000 --> 00:38:16.000
安全性を第一に、そして信頼性を第二にしています。安全性は最も重要なものです。
これは化学工場で発生するようなリアルタイムでの厳しい要求に対応できるように設計されています。
00:38:16.000 --> 00:38:20.000
化学物質の温度が上がり過ぎている場合には、対応に遅れる訳には行きません、調整が必要です。
00:38:20.000 --> 00:38:25.000
温度が上がりすぎてきたときに、リアルタイムに対応する必要があります。
00:38:25.000 --> 00:38:32.000
そして、これらの産業用制御システムは、製品寿命が 20 年以上であることが多いのです。
00:38:32.000 --> 00:38:41.000
セキュリティの観点からも非常に能力が試されるものです。特に、私たちのアルゴリズムにおけるサイバーセキュリティは、非常に速く変化しますから。
00:38:41.000 --> 00:38:52.000
暗号化のアルゴリズムです。 そのため、この規格ではよりリスクが大きい部分への高度なセキュリティのためにＴＰＭを推奨しています。
00:38:52.000 --> 00:39:08.000
そして、スマートホームのサイバーセキュリティの領域に目を向けると、コネクティビティ
規格で開発されている別の管理規格があり、400 社以上のスマートホーム企業が開発中のアライアンス規格が00:39:08.000 --> 00:39:16.000
この秋にリリースされる予定であり、相互運用性、シンプルさ、そしてセキュリティの分野でスマートホームを驚くほど改善する内容が含まれています。
00:39:16.000 --> 00:39:23.000
繰り返しになりますが、より高度なセキュリティのために TPM またはそれと同等のものが推奨されています。
00:39:23.000 --> 00:39:36.000
このように、様々なラウンドやドメインにおいて、TPM やそれと同等のものが IoT では推奨されていることがわかります。
00:39:36.000 --> 00:39:47.000
さて、今日お話した規格についてもっと詳しく知りたい方は、これらの用語のどれでも、そのほとんどが TCG のウェブサイトで検索することができます。
00:39:47.000 --> 00:40:01.000
また、TCG 開発者のサイトでは、TCG で行われているエキサイティングな取組みについて知ることができます。IoT サイバーセキュリティに関係することです。
00:40:01.000 --> 00:40:16.000
00:40:01.000 --> 00:40:16.000 では、皆様からのご質問にお答えしたいと心が躍っております。是非
ライブであなたからのご質問をお待ちします！