サイバートラストは、ミラクル・リナックスとの合併を経て同社の認証事業とミラクル・リナックスの組み込み Linux 事業を組み合わせ、IoTセキュリティ分野での新しい活動を始動させた。また、米Rambus Inc. （本社：カリフォルニア州サニーベール）と、さまざまな IoT 機器のセキュリティを強化する「IoT 機器の統合管理基盤」の提供を目的とした連携もスタートしている。これらの事業の概要を同社IoT事業部担当部長・豊島大朗氏に聞いた。

キーワードは「統合管理基盤」

サイバートラストのIoT事業部は、サイバートラストの中でもまだ歴史の浅い部署だが、すでに多くの技術コンポーネントを用意し（図1）、「水や電気のように使えるセキュリティのインフラを作ろう」という目標を設定している。ユーザーが意識しなくても使えるものになっていないと安心して生活できない。セキュリティに存在感は不要だ。であれば、そのためのインフラを作ろうということが我々の目指すところである。

▼（図1）Secure IoT Platformを構成するコンポーネント群

ただし、ご承知のようにセキュリティ分野には最先端の技術が日進月歩で出現する。無論、それらを集めればそれなりのセキュリティを実現できるだろうけれど、技術的にできるという話と、それが使える、という話は全く別の話だ。私たちとしては、どのようにしたら「意識せずに使える」ようになるかが重要だと捉えている。それが優れたインフラになるかどうかの境目ではないかと考えている。したがって、IoT事業部にとって重要なキーワードは「無意識に使える優れた統合管理基盤か？」ということに尽きる。

統合管理基盤で重要なのは、それ自体の機能を主張することではない。そうではなく、アプリケーションやサービスを考えることを仕事にしている方々に、その業務に専念していただくために必要な安全性自体は、極めて簡単にご提供できるものでなければならない。。基盤とアプリケーションの接続を簡便なものにすることに向けて、様々な技術開発を進めている。

様々な企業とのコラボレーションでインフラを作る

よく私たちが説明しているものが図2で、それを実現するためにどういうステップが必要なんだろう、どういうところに障壁があるのだろう、ということを説明している図である。全て弊社が一気通貫で実施するわけではなく、いろいろなパートナー企業と共同研究・開発を実施している。

▼（図2）製品ライフサイクルにおけるセキュリティ管理

一番左端にデバイスを特定するレイヤーがある。何といっても強力なインフラ基盤をつくるには、まずデバイスを特定する必要がある。それがPCであれ、スマホであれ、一つひとつにユニークな番号を付与する。それを半導体の製造段階で埋め込んでいただくという話もすでに現実にスタートしている。

それができることが前提になって、その後のプロセスが進む。当然、そのユニークネスにふさわしい証明書が必要になってくる。具体的にはどのようなメタデータを持たせるか、になる。鍵自体はユニークなものだが、証明書はこれにリッチなメタデータを付与する。我々はこれを「機器の固有化」と称している。

誰のもの？ 誰が承認した？ 誰かが前に使ってない？ 初期化されている？ この証明書自体いつまで有効なの？ など数多くのメタデータをインプリメントし、これが具体的にサービスと接続するわけだ。クラウドサービス側は、もう間もなくサービスをリリースできるはずだが、少し遅れてデバイス側の実装時期も見え始めてきた。ともあれ、クラウド側と生産ラインで同じ仕掛けを保持して同期が取れれば、サービスとして完成する。実はこれは、具体的には自動車に組み込まれることを想定しているものだ。

図3の一番左にHSM（Hardware Security Module）という鍵を生成する機械がある。これを（メーカーさんに）設置させていただくわけだが、HSMを利用してチップの中に“あるロジック”を埋め込んでしまう。それに対して、もう一つの元ネタ帳のようなものがあり、それらがマージされると鍵を生成できる、という仕組みだとご理解いただければ良い。

▼（図3）鍵管理のプロセス

実は、これは弊社と提携しているRambus社の持っている技術だ。鍵をユニークに生成するという技術をIP（知的財産）として彼らが所有していた。それを製品化して、箱の中に閉じ込めているのがHSMの中身だと考えていただければよい。当然ながら、HSMが発行した鍵を外に漏らさないように自動的に書き込む、というところまでやらないと本当のセキュリティは保てない。

次に、製品メーカー固有化に進む。製品シリアル番号とロジックを使って自分で鍵を生成できる、というのが彼ら（Rambus社）の持っている技術だ。例えば、お客さんが持っている製品シリアル番号をもらえば、同じ鍵を生成できるので、リモートだろうが、ネットワーク上にいなかろうが、同じ鍵を埋め込んだかのようにすることが可能だ。

右側に書いてあるのは、サイバートラストの中の仕組みだが、下のところがもともと同じHSMを持っている。ここで共通解といわれるものを自分で生成できるので、リモートにあるけれど同じことができる。もう一つは、それをベースに同じCA（Certification Authority）局の中に秘密鍵の生成、いわゆる鍵発行の仕掛けを持っているので、その鍵で暗号化して自分の証明書をデバイスに対して割り当てることができる。従って、それを紐解けるのもそのデバイスしかいない、というサイクルが生成されることになる。

廃棄時の安全性も重視する。そもそも証明書には有効期限がある。エクスパイア（expire
）させるか、もう一つはリボケーション（Revocation）といって、この証明書だめだよ、というのをサーバー側（認証許可側）が逆証明できる機能がある。エクスパイアにしてもリボケーションにしても、とりあえずそこから先にメーカーには責任はない、ということが実現できる。

▼（図4）バリデーションサービス

当然、有効期限は任意に設定できるので、1日しか寿命がない、あるいはある1日のこの時間帯だけ有効にしてくれ、などという要求にも対応できる。さらに応用編として、緯度経度情報にも対応しようとしている。証明書を確認しに来るタイミングにGPSデータも一緒に管理しようという企画を進めている。ただし、それをCA局がやるのか、サービスレイヤーではないか、といった議論がまだ残っている。公共性に関する議論が浮上して来るのだ。これを我々はバリデーションサービス（図4）と呼んでいるが、これを使えるからアプリケーションがこのSecurity service API for validationを使って、自分のサービスの有効・無効のようなことをやれば、IDやパスワードは不要になる。この辺りは実に多くの企業から問い合わせをいただいている。