JP2024071510A - シール及び検証によるデバイス認証 - Google Patents

Abstract

【課題】通信デバイス（１）は、生産フローへの影響を最小限に抑える。【解決手段】信頼の基点ＲｏＴ（２）であって、秘密情報を格納するのに安全な環境を提供し、安全にデータを共有するように構成された信頼の基点ＲｏＴ（２）と、前記基点ＲｏＴ（２）は、安全にデータを共有するように構成され、前記基点ＲｏＴ（２）によって制御されたメモリーであって、通信デバイス（１）の製造（１０１）の際に、通信デバイス（１）のデバイス情報を、メモリ内に保存するように構成されたメモリーと、前記ＲｏＴ（２）に関する情報をシステム（１０）に提供し、前記メモリ内に保存された装置情報をシステム（１０）に提供するように構成されたプロセッサとを備えることを特徴とする通信デバイス。【選択図】図１

Description

本発明は、一般的に認証デバイスに関連する。より具体的には、本発明は、信頼の基点（Ｒｏｏｔ－ｏｆ－Ｔｒｕｓｔ）（ＲｏＴ））を含むモノのインターネット（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ））デバイスに関連し、セキュリティ所有者のシステムによって認証出来る。

ＩｏＴは、電子機器やソフトウェアに組み込まれた物理的なデバイス、アプライアンス、又はアイテムのネットワークであり、これらのオブジェクトは、人との相互作用なしにデータを交換出来る。

ＩＴＵ－Ｔ Ｙ．２０６０は、ＩｏＴを情報社会のグローバルインフラストラクチャとして定義し、既存及び進化する相互運用可能な情報通信技術に基づいて物理的なモノと仮想的なモノとを相互接続することで、高度なサービスを可能にする。

「ＩｏＴ」という用語の「モノ（ｔｈｉｎｇ）」は、物理的な世界である物理的なモノ、又は情報の世界である仮想的なモノの対象と考えられており、通信ネットワークに識別され統合することが出来る。

この定義では、物理的なモノは物理的な世界に存在し、感知され、作動し、つながることが出来る。物理的なモノの例としては、周辺環境、産業用ロボット、物品、電気機器などが挙げられる。
この定義では、仮想的なモノは情報の世界に存在し、保存、処理、及びアクセスが可能である。仮想的なモノの例としては、マルチメディアコンテンツやアプリケーションソフトウェアなどが挙げられる。

ＩＴＵ－Ｔ Ｙ．２０６０では、ＩｏＴデバイスは、通信の必須機能と、感知、作動、データキャプチャ、データ保存、及び／又はデータ処理のオプション機能を備えた機器の一部と見なされる。

ＩｏＴデバイスは、ゲートウェイを介して通信ネットワークを通じて通信したり、ゲートウェイを使用せずに通信ネットワークを通じて通信したり、通信ネットワークを使用せずに直接通信することが出来るなど、通常、他のデバイスとの通信を行う。また、通信シナリオの組み合わせも可能であり、例えば、デバイスは、ローカルネットワーク（即ちアドホックネットワークのような、デバイス間及びデバイスとゲートウェイ間のローカル接続性を提供するネットワーク）による直接通信、及びローカルネットワークゲートウェイを介した通信ネットワークを通じた通信を用いて、他のデバイスとの通信を行うことができる。

通信ネットワークは、ＩｏＴデバイスによって取り入れられたデータをアプリケーション及び他のデバイスに転送したり、アプリケーションからデバイスへ命令を転送することもできる。
通信ネットワークは、一般に、信頼性が高く効率的なデータ転送のための機能を提供する。ＩｏＴネットワークインフラストラクチャは、従来のＴＣＰ／ＩＰベースのネットワークなどの既存のネットワーク、及び／又は次世代ネットワーク（ＮＧＮ）などの進化するネットワークを介して実現することができる。

ＩｏＴデバイスは、例えばシステムオンチップ（ｓｙｓｔｅｍ ｏｎ ａ ｃｈｉｐ（ＳｏＣ））の形態で集積回路の周辺に構築することが出来る。
このようなＳｏＣには、デバイスによって常に信頼され、デバイスの資格情報とソフトウェアを強力に保護するためにハードウェアベースで提供される一連の機能である、信頼の基点（ＲｏＴ）が含まれる場合がある。

ＲｏＴは通常、統合されたセキュア要素に実装される。ＲｏＴがデバイスのＳｏＣに埋め込まれておらず、デバイスの統合されたセキュア要素に実装されていない可能性がある。ＲｏＴは、一般的に、信頼出来る実行環境（ｔｒｕｓｔｅｄ ｅｘｅｃｕｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔ（ＴＥＥ））よりも信頼出来る。

ＲｏＴは、オンチップの他のデバイスとデータを安全に共有出来る。ＲｏＴは、ＳｏＣ内で、また異なるホストＣＰＵで実行されるクライアントアプリケーションの代わりに、秘密（ｓｅｃｒｅｔｓ）を作成、格納、使用するのに安全な環境を提供する。ＲｏＴは、セキュリティモジュール、暗号コア等で構成出来る。

ＩｏＴデバイスは、例えばある機能を起動するために、接続されているデバイスの強力な認証を必要とする特定のシステムに接続出来る。
このような認証は、通常、デバイスとシステム間の強力な暗号化認証プロトコルのセットアップで使用されるデバイスに埋め込まれたデバイス毎に一意の秘密（ｕｎｉｑｕｅ ｐｅｒ ｄｅｖｉｃｅ ｓｅｃｒｅｔ）に依存している。たとえば、システムは ＩｏＴプラットフォームであっても良い。

これらのデバイス毎に一意の秘密は、通常、ＲｏＴで保護され、通常はＳｏＣ又はセキュアエレメントの製造中にプロビジョニングされる。
システムは、デバイスに埋め込まれたＲｏＴ秘密を認証する。デバイスを認証するには、システムは、デバイスにＲｏＴ毎に一意の秘密のバインドを安全にする必要がある。

マーリンペアリング（Ｍｅｒｌｉｎ Ｐａｉｒｉｎｇ）や、ＴＶｋｅｙのデバイスシーリングセキュアメッセージ（Ｄｅｖｉｃｅ Ｓｅａｌｉｎｇ ｓｅｃｕｒｅ ｍｅｓｓａｇｅ）など、様々なソリューションが存在する。マーリンペアリングは、製造時に設定されたユニークキーを使用する。
セキュアメッセージＴＶｋｅｙは、チップ製造時に非対称のユニークキーセットを使用する。

既存のソリューションの欠点は、デバイスの製造中に特定の処理が必要な点である。
このような従来の技術を用いると、デバイスの製造はより長く、より費用がかさみ、そのようなデバイスの全体的な生産フローに大きな影響を与える。

既存のソリューションの欠点は、デバイスの製造中に特定の処理が必要な点である。このような従来の技術を用いると、デバイスの製造はより長く、より費用がかさみ、そのようなデバイスの全体的な生産フローに大きな影響を与える。

本発明は、従来技術に存在する上記の課題を解決する。

本発明の態様によれば、デバイスがシステムによってプログラムされ、認証されることが出来る方法が提案される。
デバイスの信頼の基点ＲｏＴによって管理されるメモリは、デバイスの生産中にデバイスのデバイス情報を受信出来る。

デバイスはシステムにブートストラップされることが出来、情報は、システムの暗号化プロトコルによってＲｏＴを認証するためのＲｏＴとプログラムされたデバイス情報とに提供することが出来る。
これにより、認証されたＲｏＴとシステムに知られているデバイス情報との間のバインディングが発生し、デバイスのデバイス生産を確認するために使用され、システムによってバインディングが検証されることが可能である。

このようにして、デバイスの製造中の特定の処理を回避することが出来る。
即ち、デバイスはシステムによってプログラムされ、認証されるので、製造中の時間を節約する。

実施形態では、デバイスは１つ又は複数のＳｏＣを有することが出来、ＲｏＴは、各ＳｏＣのデバイス情報のプログラミングを管理することが出来る。
デバイス情報は、ＳｏＣ（複数可）及びデバイスにも関連する場合がある。
デバイスに関連する場合、情報は、例えば、モジュール、ＣＰＵ、又はアプリケーションに関するものである。

一方のパーティがデバイスを提供でき、別のパーティがデバイスを所有することが出来るので、モジュールの製造元とモジュール／デバイスの所有者を有することが出来る。
従って、モジュールとそれが埋め込まれているモジュールの所有者という、それぞれの情報のプログラミングを管理する必要があるが、別のＳｏＣ上である必要はない。

このように、デバイスの設計はより多目的であり、認証は、デバイスのＲｏＴを使用することによってのみ異なるＳｏＣのために実行することが出来る。

実施形態では、ＲｏＴは、デバイスのＳｏＣのいずれかに埋め込まれる必要はない。
このように、デバイスの設計及び生産はより多目的になる。

実施形態では、ＲｏＴは、デバイスの生産中にデバイスの各ＳｏＣとの専用のバインディング鍵に合意することが出来、これはＲｏＴとデバイスを暗号的にバインドするために使用出来る。
このようにして、ＲｏＴとデバイスとは相互に暗号化されてバインド出来る。キーアグリーメント（Ｋｅｙ ａｇｒｅｅｍｅｎｔ）は、Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎキー交換を利用し進んだ秘密を持つ暗号化の挑戦になる可能性がある。

実施形態では、デバイス鍵は、デバイスとＲｏＴとの間の通信を暗号化するために使用することが出来る。
このようにして、デバイス及びＲｏＴは安全な方法で相互に情報を送受信することが出来る。

実施形態では、デバイス情報のプログラミングは、永続的な方法で行うことが出来る。
このようにして、デバイス情報はデバイスに永続的に格納され、簡単に失われることはない。

実施形態では、ＲｏＴはシステムに一回だけブートストラップするように構成することが出来る。
このように、システムへのブートストラップは一回だけ起こるので、特定のブートストラップは以前に実行されたブートストラップとのコンフリクトを生成しない。更に、システムとデバイス間の不要な通信の量を制限する。

実施形態では、本方法は、更に、セキュリティ所有者に対してＲｏＴのデバイス生産に関する情報を報告することから構成することが出来る。
このようにして、特定のデバイスに配置された特定のＲｏＴのデバイス生産に関する詳細情報は、セキュリティ所有者が利用出来る。

実施形態では、デバイスのデバイス生産の検証は、ブートストラップされたＲｏＴがデバイスの生産中に報告されたかどうかの検証を含むことが出来る。
このようにして、デバイスの起点（ｏｒｉｇｉｎ）をセキュリティ所有者が簡単に確認出来る。

実施形態では、検証は、システムへのデバイスのブートストラップ中に強制することが出来る。
このようにして、システムがデバイスを認証するときに、システムによるデバイス情報の検証が実行される。これにより、認証プロセスが改善される。

実施形態では、検証は、デバイス生産に関する報告された情報がシステムによって受信された後に行うことが出来る。
このようにして、検証プロセスは、デバイス生産に関する報告された情報がシステムによって受信される時間にあまり依存しない。実施形態では、ブートストラップ情報及びデバイス生産に関する報告情報をＲｏＴのセキュリティ所有者に報告することが出来る。

このようにして、セキュリティ所有者は、デバイスのブートストラップ情報に対応するデバイス生産情報を決定出来る。つまり、セキュリティ所有者は、生産されたデバイスがどの認証済みデバイスに属しているかを判断出来る。

実施形態において、ＲｏＴに関する情報は、ＲｏＴの公開ｉｄから構成することが出来る。
報告される最低限の情報は、ＲｏＴの公開識別子である。
その他の情報はオプションである。
従って、ＲｏＴのタイプが異なるデバイス生産サイトを持つ異なるデバイス所有者によって共有されている場合、異なる生産サイトを持つ各デバイス所有者は、デバイスに埋め込まれたＲｏＴの公開識別子を報告出来るため、他のデバイスのＲｏＴを要求できない。

１つのＲｏＴの種類が１つのデバイス所有者によって使用されるだけである場合、セキュリティに関するレポートは必要ない。それ以外の場合は、デバイス所有者毎のＲｏＴ公開ｉｄレポートはセキュリティのために必須である。
このようにして、特定のデバイスに配置される特定のＲｏＴを決定することが出来る。

本発明の別の態様によれば、記載された実施形態のいずれかに従って方法のステップを実行するように構成されたプロセッサを備えることが出来るデバイスが提案される。

本発明の別の態様によれば、記載された実施形態のいずれかに従って方法のステップを実行するように構成された集積回路を備えることが出来るデバイスが提案される。

実施形態では、デバイスはモノのインターネットデバイスであり得る。

本発明の別の態様によれば、コンピュータプログラム製品が提案され、コンピュータ読み取り可能な非一時的記憶媒体上に実装することが出来る、ここでコンピュータプログラム製品は、プロセッサによって実行される際に、記載された実施形態のいずれかによる方法のステップをプロセッサに実行させることが出来るコンピュータ実行可能命令を含むことが出来る。

本発明の別の態様によれば、コンピュータ読み取り可能な非一時的な記憶媒体が提案され、コンピュータ実行可能命令を含み、プロセッサによって実行される際にプロセッサが上記のいずれかの実施形態による方法のステップを実行させ得る。

本発明の別の態様によれば、信頼の基点ＲｏＴ（２）であって、秘密情報を格納するのに安全な環境を提供し、安全にデータを共有するように構成された信頼の基点ＲｏＴ（２）と、
前記基点ＲｏＴ（２）によって制御されたメモリーであって、通信デバイス（１）の製造（１０１）の際に、通信デバイス（１）のデバイス情報をメモリ内に保存するように構成されたメモリーと、
前記ＲｏＴ（２）に関する情報をシステム（１０）に提供し、前記メモリ内に保存された装置情報をシステム（１０）に提供するように構成されたプロセッサとを備えることを特徴とする通信デバイスである。

本発明の別の態様によれば、前記通信デバイス（１）が１つ又は複数のシステムオンチップＳｏＣ（３）を有し、前記ＲｏＴ（２）が各ＳｏＣ（３）に対するデバイス情報のプログラミングを管理することを特徴とする通信デバイスである。

本発明の別の態様によれば、前記ＲｏＴ（２）が前記通信デバイス（１）の前記ＳｏＣ（３）のいずれにも埋め込まれていないことを特徴とする通信デバイスである。

本発明の別の態様によれば、前記ＲｏＴ（２）と前記通信デバイス（１）とを暗号的にバインドするのに使用するために、デバイス生産中（１０１）に前記通信デバイス（１）の各ＳｏＣ（３）との専用バインディング鍵に、前記ＲｏＴ（２）が合意するように構成されていることを特徴とする通信デバイスである。

本発明の別の態様によれば、前記通信デバイス（１）と前記ＲｏＴ（２）との間の通信を暗号化するためにデバイス鍵が使用されるように構成されていることを特徴とする通信デバイスである。

本発明の別の態様によれば、前記ＲｏＴ（２）が前記システム（１０）に１回だけブートストラップするように構成されていることを特徴とする通信デバイスである。

本発明の別の態様によれば、前記ＲｏＴ（２）に関する前記情報が前記ＲｏＴ（２）の公開ｉｄから成ることを特徴とする通信デバイスである。

実施形態は、例えば、対応する参照記号が対応する部品を示す添付の概略図を参照して、次の内容について説明する。

図１は、デバイスの生産、認証及び検証プロセスの例示的な実施形態を示す図である。 図２は、ＲｏＴがＳｏＣに埋め込まれているデバイスの例示的な実施形態を示す図である。 図３は、ＲｏＴがＳｏＣに埋め込まれていないデバイスの例示的な実施形態を示す図である。 図４は、複数のＳｏＣを有するデバイスの例示的な実施形態を示す図である。 図５は、デバイス生産によってセキュリティ所有者に生産情報が送信されていないデバイスの生産、認証及び検証プロセスの例示的な実施形態を示す図である。

以下の例ではクライアントデバイスに対して参照がなされているが、開示はクライアントデバイスへの適用に限定されないことが理解される。

図１は、デバイス１の生産、認証及び検証プロセスの例示的な実施形態を示す。

セキュリティ所有者１１は、ＲｏＴの生産１００の間にＲｏＴ２にＲｏＴ公開ｉｄとＲｏＴ鍵とを提供し２００、その後それらはＲｏＴ２をプログラム出来る２０１。
ＲｏＴ公開ｉｄは、後でデバイス１が接続するシステム１０と交換することが出来るＲｏＴ２に関する情報の一例である。
これは、デバイス１に配置された特定のＲｏＴを識別するために使用することが出来る。
ＲｏＴ鍵は、例えば、ＲｏＴ２とデバイス１又はシステム１０とを暗号的にバインドするために使用される暗号鍵の例であり得る。

セキュリティ所有者１１は、ＲｏＴ２に関する情報をデバイス生産時１０１にもＲｏＴ２に提供することが出来る。
ＲｏＴ２に関する情報は、ＲｏＴ２に永久的にプログラムされるか、又はＲｏＴ２によって管理されるメモリユニットに提供される。

デバイス生産１０１の間、ＲｏＴ２が配置されている特定のデバイス１に関するデバイス情報は、ＲｏＴ２に、又はＲｏＴ２によって管理されるセキュアメモリユニット４にシールしてもよい２０２。
このセキュアメモリユニット４は、ＲｏＴ２の一部であっても良いし、別のメモリユニット４であっても良い。
シールは、ＲｏＴ２又はＲｏＴ２によって管理されるセキュアメモリユニット４にデバイス情報を永久にプログラミングすることから成り立つ。

特定のデバイス１に関するデバイス情報は、メーカー情報、モデル情報、ブランド情報、バージョン番号及びシリアル番号、一般に汎用一意識別子（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）（ＵＵＩＤ）の形式で、デバイスの抽象的な識別子を含み得るが、これに限定されない。

図２は、ＲｏＴ２がＳｏＣ３に埋め込まれたデバイス１の例示的な実施形態を示す。本実施形態においてＲｏＴ２によって管理されるセキュアメモリユニット４は、ＲｏＴ２の外側に描かれているが、ＲｏＴ２の一部であってもよい。

図３は、ＲｏＴ２がＳｏＣ３に埋め込まれていないデバイス１の例示的な実施形態を示す。
ＲｏＴ２は、デバイス１の一部であってもよいし、あるいは、デバイス１の外部に設けてもよい。

図３の実施形態では、ＲｏＴ２とＳｏＣ３との間の通信３０は、例えば通信を暗号化することによって、安全にする必要がある。
この暗号化通信３０を有効にするために、ＲｏＴ２は、通常、相互認証によって、例えば１回のシーリング処理（ｓｅａｌｉｎｇ ｐｒｏｃｅｄｕｒｅ）の間に、鍵合意暗号プロトコルを使用して、デバイス毎に一意の鍵を使用することに合意することが出来る。

このデバイス鍵はデバイス１に格納され、ＲｏＴ２及びデバイス１を暗号化してバインドするために使用される。
ＲｏＴ２とデバイス１との間の通信を暗号化する方法の例としては、ＲｏＴ２とデバイス１との相互認証を使用した、標準又は独自の公開鍵ベースのセキュアチャネルが含まれる。
相互認証は製造時に行われ、共有の交渉済み秘密は、ＲｏＴ２のメモリ及びデバイス１のメモリの両方にプログラムされても良い。

次に、デバイス１の生産設備は、セキュリティ所有者１１に、ＲｏＴ２に関する情報のリストを報告２０４してもよいし、例えばＲｏＴ公開ｉｄを、デバイス１のデバイス生産に用いる。

この情報は、後で、システム１０にブートストラップされたＲｏＴ２が、生産設備によって報告され、従って生産されたことを確認するために使用することが出来る。
この情報は、たとえば、生産ログに含めることが出来る。生産ログには、たとえば、ＲｏＴ公開ｉｄと共にデバイス情報、又はＲｏＴ公開ｉｄと共にデバイスのシリアル番号を含めることが出来る。

次に、生産されたデバイス１は、システム１０にブートストラップされてもよい。
これは、デバイス生産１０１の直後に、又はデバイス１が消費者に販売された後に行われてもよい。

このようにして、デバイス１及びデバイス１のＲｏＴ２をブートストラップ及び認証することは、生産プロセス１００、１０１とは別に行われ、従ってデバイスの生産フローに対する影響を最小限に抑える。

デバイス１がシステム１０にブートストラップされると、ＲｏＴ２に関する情報、例えばＲｏＴ公開ｉｄ、タイプ又はバージョン番号を、シーリングプロセス２０２の間にシールされたデバイス情報と共に、システム１０に提供してもよい２０５。

デバイス情報は、デバイスの製造元、例えば、ブランドや種類によって定義されてもよい。
デバイス情報は、システム１０によって定義されデバイス製造者に返される一意の識別子であり得る。

この情報の送信は、例えば事前共有秘密に基づく標準又は専有セキュアチャネルを使用して、安全な方法で実行することが出来る。
たとえば、Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎキー交換を使用して、安全なチャネルを設定出来る。これについては、以下で詳しく説明する。

デバイス１がセキュアリンクの初期化を求められた後、デバイス１は、鍵の個人部分（ｐｒｉｖａｔｅ ｐａｒｔ ｏｆ ｔｈｅ ｋｅｙ）、即ち、個人デバイス鍵、及び鍵の公開部分、即ち公開デバイス鍵からなるランダムなキーペアを生成する。

これは通常、ランダムなキーペアである。個人デバイス鍵は、暗号化の目的で１回だけ使用出来る、ノンス、数値又はビット文字列であっても良い。
公開デバイス鍵は、個人デバイス鍵に基づいて計算出来る。これは通常、デバイス１のより安全な部分で行われる。

デバイス１は、公開デバイス鍵をシステム１０に送信する。
この送信は、デバイス１の安全な部分を介して直接、又はデバイス１の別のより安全性の低い部分を介して行ってもよい。
デバイス１は、システム１０にその一意のＩＤを送信することも出来る。

システム１０は、デバイス１に属するこの一意のＩＤをチェックして、システム１０とのセキュアリンクを確立しようとしているデバイス１の同一性を確認し、その一意のＩＤが実際に生産されたチップに属していることを確認してもよい。
更に、デバイス１は、署名（ｓｉｇｎａｔｕｒｅ）を用いて送信にサインしてもよい。これは、認証、否認防止、及びメッセージが送信後に変更されていないかどうかを確認するために使用出来る。

送信を受信すると、システム１０は送信のパラメータをチェックする。これは、たとえば、デバイス１によって送信される署名又は一意のＩＤをチェックすることを意味する。

次に、システム１０は、鍵の個人部分－個人サーバ鍵－及び鍵の公開部分－公開サーバ鍵－から構成されるキーペアを生成する。これはランダムなキーペアであっても良い。個人サーバの鍵はノンスであっても良く、公開サーバの鍵は、個人サーバ鍵に基づいて計算出来る。

次に、システム１０は、公開デバイス鍵及び個人サーバ鍵に基づいて、セキュアリンクキーを計算してもよい。このセキュアリンクキーは、システム１０とデバイス１との間に形成されるセキュアリンクを安全にするために使用され得る。

システム１０は、セキュアリンクキーを計算する際に、公開サーバ鍵をデバイス１に送信する。
この送信は、デバイス１の安全性の低い部分を介して、又はデバイス１のより安全な部分に直接行うことが出来る。
システム１０はまた、そのサーバ証明書を送信し、送信を介して送られた公開サーバ鍵が実際にシステム１０によって所有されていることを証明するために使用される。
更に、システム１０は、その署名を用いて送信にサインしてもよい。

送信を受信すると、デバイス１は、署名、サーバ証明書などの送信のパラメータをチェックし、デバイス１の個人鍵及びシステム１０の公開鍵に基づいてセキュアリンクキーを算出する。
これで、デバイス１及びシステム１０の両方が、セキュアリンクキーに合意する。
このキーは、次に、デバイス１とシステム１０との間のセキュアリンクを介して送信されるデータを暗号化及び復号化するために使用され得る。

システム１０は、強力な暗号認証プロトコル及び秘密を使用してＲｏＴ２を認証することが出来る。
このようなプロトコル及び秘密の例としては、ＴＬＳ若しくはＤＴＬＳ ＰＫＩ、ＲＡＷ証明書、又は相互認証を使用したＰＫＩスキームなどがある。
このようにして、システム１０は、ＲｏＴ２がシステム１０によって信頼され得るか否かを検証してもよい。
このようにして、セキュリティシステムは、信頼されたＲｏＴ秘密とデバイス１のデバイス情報との間のバインディングを受け取ることがある。

例えば、シーリングデバイス１情報及びＲｏＴ情報が暗号で認証されたＲｏＴ２から受信されたデータであることをシステム１０が認証した場合に、ＲｏＴ２は信頼され得る。
ブートストラップ２０５をシステムに対して、例えばＲｏＴ２によって１回だけ行ってもよい。

次に、システム１０は、ブートストラップされたＲｏＴ２が生産設備によって報告された２０４か否かを確認しても良い２０６。
この検証２０６は、ブートストラップ２０５中に強制されても良いし、システム１０によって生産ログが受信された後に実行されても良い。

このようにして、システム１０は、システム１０にブートストラップされたＲｏＴ２が実際に生産設備によって生産されたことを検証することが出来る。
この検証は、デバイスのメモリの特定の測定を行い、ブートストラップされたタイプのデバイスの有効なパターンに対応することを確認することによって行うことが出来る。

ＲｏＴ秘密は、ＲｏＴ２の認証に使用出来る。
更に、システム１０は、デバイス１のデバイス情報を用いてシステム１０にブートストラップされたＲｏＴ２が、実際にその特定のデバイス１に配置されたことを確認することが出来る。
この検証２０６の間、ＲｏＴ公開ｉｄは、ＲｏＴ２が生産設備によって報告されたことを確認するために、デバイス製造情報と例えばＲｏＴ秘密との間のリンクとして使用され得る。

検証２０６の後、ＲｏＴ２とデバイス１との一意のバウンディング（ｕｎｉｑｕｅ ｂｏｕｎｄｉｎｇ）は、システム１０のデータベースに認証済みとして報告され得る。

また、デバイス２の生産に使用されたＲｏＴ公開ｉｄのリストを、生産設備が報告しないことも考えられる。

例えば、システム１０のセキュリティ所有者は、ＲｏＴ公開ｉｄをＲｏＴ２に既に提供しており、既にそれを知っている可能性がある。
更に、ＲｏＴ公開ｉｄが、例えばデバイス１のインストール中に現場で（ｉｎ ｔｈｅ ｆｉｅｌｄ）報告されることがある。
ＲｏＴ公開ｉｄは、例えばデバイスに一致するメモリフットプリントをチェックするなどして、フィールド内のリモート構成証明によって報告及び検証することも出来る。

ブートストラップ２０５からのブートストラップ情報及び生産情報２０４は、ＲｏＴ２を使用する全システム１０での一貫性を検証するために、ＲｏＴセキュリティ所有者１１に報告され得る。

従って上記の方法は、正しいデバイス情報のシーリング２０２のデバイス生産設備を信頼し、生産ログを正しく報告する２０４ことに依存する。この方法は、多くの攻撃の可能性を妨げる可能性がある。

まず、「正規のデバイスアップグレード（ｌｉｇｉｄ ｄｅｖｉｃｅ ｕｐｇｒａｄｅ）」と呼ばれる攻撃を防御することが出来る。
この攻撃では、正規のＲｏＴ２を有する正規のデバイス１は、別の正規のデバイス１のふりをすることが出来る。

通常、ローエンドデバイス１は、ハイエンドデバイス１としてブートストラップ２０５を試みる。
信頼された環境でデバイス情報がＲｏＴ２にシールされ２０２、ブートストラップ２０５中にシステムに安全に報告されるので、ローエンドデバイス１は、生産後にハイエンドデバイス１のふりをすることができない。

第二に、「偽りのデバイス（ｎｏｎ－ｌｅｇｉｔ ｄｅｖｉｃｅ）」と呼ばれる攻撃が防御される。
この攻撃では、正しいＲｏＴ２を有する偽りのデバイス１は、正規のデバイス１のふりをすることが出来る。

典型的には、偽りのデバイス１は、システム１０の有効なＲｏＴ２を用いて、正規のシステム１０内でブートストラップ２０５してもよい。
偽りのデバイス１は、システム１０が、例えばそのＲｏＴ公開ｉｄのブートストラップされたＲｏＴ２についての情報が、正規の生産設備１００，１０１によって報告２０４されていないことを検出したときに、検証ステップ２０６中に検出される。

第三に、「クローンデバイス（ｃｌｏｎｅ ｄｅｖｉｃｅ）」と呼ばれる攻撃が防御される。
この攻撃では、偽りのデバイス１は、ＲｏＴ２がデバイス１のＳｏＣ３の外部にある場合に、正規のデバイス１のＲｏＴ２を使用する可能性がある。
シーリング処理２０２の間に、デバイス１に一意のデバイス毎の鍵がインストールされ（２０３）、秘密鍵のクローンを作成することを攻撃者に強制する場合がある。

第四に、「クローンＲｏＴ（ｃｌｏｎｅ ＲｏＴ）」と呼ばれる攻撃も防御される。
この攻撃では、クローンＲｏＴ２は、正規のＲｏＴ２の秘密を使用して、システムにブートストラップしようとする２０５。
クローンＲｏＴ２は、単一のＲｏＴ２が複数のブートストラップ２０５を試みる場合、検証ステップ２０６中に検出される場合がある。

次に、システムはブートストラップ２０５を拒否し、更なる調査のためにＲｏＴ２にタグを付けるかも知れない。このようにして、セキュリティ所有者は、特定のＲｏＴ２がブートストラップを一回だけ確認するだけで、特定のＲｏＴ２のクローンを防ぐことによって、ＲｏＴ２の一貫性を検証出来る。

図４は、複数のＳｏＣ３を有するデバイス１の例示的な実施形態を示す。

本実施形態では、デバイス１のＲｏＴ２は、１つ又は複数の生産設備を有する複数のシーリング処理を管理することが出来る。上記の方法は、デバイス１毎に複数のＳｏＣ３もサポートする。

図５は、デバイス生産によってセキュリティ所有者に生産情報が送られていないデバイス１の生産、認証及び検証プロセスの例示的な実施形態を示す。

システム１０の１つの利点は、生産情報が部分的又は欠落している場合でも、システム１０が機能し、部分的に安全なままである点である。
検証後のプロセス２０７は、完全に認証されていないデバイス１を認証するために実行されてもよい。
これは、多数のデバイス１を管理するシステム１０に特に有用である。

このような事後検証処理２０７は、例えば、ＲｏＴ２によって行われるデバイスメモリ領域の安全な遠隔測定を含み得る。これは、ＲｏＴ２がＳｏＣ３に統合されている場合に特に効率的である。

１つ以上の実施形態は、コンピュータシステムで使用するためのコンピュータプログラム製品として実装され得る。
プログラム製品のプログラムは、本明細書に記載されている方法を含む実施形態の機能を定義し、様々なコンピュータ読み取り可能な記憶媒体に含めることが出来る。

コンピュータ読み取り可能な記憶媒体は、一時的ではない記憶媒体である場合がある。
例示的なコンピュータ読み取り可能な記憶媒体には、
（ｉ）その上で情報が永久的に記憶可能な書き込み不可の記憶媒体（例えば、ＣＤ－ＲＯＭドライブ、ＲＯＭチップ、又はあらゆる種類の固体不揮発性半導体メモリによって読み取り可能なＣＤ－ＲＯＭディスクなどのコンピュータ内の読み取り専用メモリデバイス）、
（ｉｉ）その上に変更可能な情報が記憶され得る書き込み可能な記憶媒体、例えば、ハードディスクドライブ又は任意のタイプの固体ランダムアクセス半導体メモリ、フラッシュメモリが含まれる。

上記の実施形態のうちの２つ以上は、適切な方法で組み合わせてもよい。

Claims (7)

1. 信頼の基点ＲｏＴ（２）であって、秘密情報を格納するのに安全な環境を提供し、安全にデータを共有するように構成された信頼の基点ＲｏＴ（２）と、
   前記基点ＲｏＴ（２）によって制御されたメモリーであって、通信デバイス（１）の製造（１０１）の際に、通信デバイス（１）のデバイス情報をメモリ内に保存するように構成されたメモリーと、
   前記ＲｏＴ（２）に関する情報をシステム（１０）に提供し、前記メモリ内に保存された装置情報をシステム（１０）に提供するように構成されたプロセッサとを備えることを特徴とする通信デバイス。
2. 前記通信デバイス（１）が１つ又は複数のシステムオンチップＳｏＣ（３）を有し、前記ＲｏＴ（２）が各ＳｏＣ（３）に対するデバイス情報のプログラミングを管理することを特徴とする請求項１に記載の通信デバイス。
3. 前記ＲｏＴ（２）が前記通信デバイス（１）の前記ＳｏＣ（３）のいずれにも埋め込まれていないことを特徴とする請求項２に記載の通信デバイス。
4. 前記ＲｏＴ（２）と前記通信デバイス（１）とを暗号的にバインドするのに使用するために、デバイス生産中（１０１）に前記通信デバイス（１）の各ＳｏＣ（３）との専用バインディング鍵に、前記ＲｏＴ（２）が合意するように構成されていることを特徴とする請求項３に記載の通信デバイス。
5. 前記通信デバイス（１）と前記ＲｏＴ（２）との間の通信を暗号化するためにデバイス鍵が使用されるように構成されていることを特徴とする請求項４に記載の通信デバイス。
6. 前記ＲｏＴ（２）が前記システム（１０）に１回だけブートストラップするように構成されていることを特徴とする上記請求項１から５のいずれか１項に記載の通信デバイス。
7. 前記ＲｏＴ（２）に関する前記情報が前記ＲｏＴ（２）の公開ｉｄから成ることを特徴とする上記請求項１から５のいずれか１項に記載の通信デバイス。