JP7060362B2 - 電子デバイスのためのイベント証明書 - Google Patents

Description

本技術は、電子デバイスの分野に関する。特に、電子デバイスに対する暗号化による証明書の提供に関するものである。

モバイルバンキング、ヘルスケアサービスへのアクセス、雇用の詳細の取扱いなど、機密情報となり得る情報の扱いを伴うサービスにアクセスするために電子デバイスを使用することがますます増えてきている。また、拡大しつつあるモノのインターネット（Internet of Things：ＩｏＴ）の発展に伴って、例えば、温度データや、ユーザが存在するか否かを示す近接情報などのセンサ情報を提供可能な電子デバイスによって与えられた情報に基づき、暖房や空調、街路照明などのシステムを制御することがますます一般的になってきている。これらの場面では、電子デバイスとのやり取りが安全であることを信用するために、電子デバイスが所定の要件を満たすことをサービスプロバイダが確認できることが重要となり得る。サービスプロバイダは、電子デバイスを製造するために用いられる製造プロセスの最中や、その後のライフサイクルにおけるデバイスの改作において、所定のイベントが発生したことに対して自信を持つ必要がある場合もある。例えば、そのようなイベントとしては、デバイス製造業者によるコンポーネントへのシステム・オン・チップの埋込み、デバイスの特定の品質保証工程の通過、デバイスへの特定のソフトウェアの提供が挙げられる。暗号化技術によれば、必要な信頼の基礎を提供することができる。例えば、デバイスにはその製造中に暗号化キーが埋め込まれてもよく、デバイスは後にそのキーを用いて外部認証者にそのデバイスが所要のプロパティを満たしていることを証明することができる。

少なくとも幾つかの実施例によれば、
電子デバイスの検証方法であって
電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが提供する複数のイベント証明書を電子デバイスが受信したことを証明する、電子デバイスによって与えられた証明書情報を受信することと、
証明書情報が有効であるかどうかを示す検証結果を判定することと、
を具備する方法が提供される。

少なくとも幾つかの実施例によれば、
電子デバイスの検証を行う検証装置であって、
電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが提供する複数のイベント証明書を電子デバイスが受信したことを証明する、電子デバイスによって与えられた証明書情報を受信する通信回路と、
証明書情報が有効であるかどうかを示す検証結果を判定する処理回路と、
を具備する装置が提供される。

少なくとも幾つかの実施例によれば、
外部デバイスと通信を行う通信回路と、
電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが含む複数のイベント証明書を電子デバイスが受信したことを証明する証明書情報を含む検証要求を検証装置に送信するために通信回路を制御する処理回路と、
を具備する電子デバイスが提供される。

少なくとも幾つかの実施例によれば、
電子デバイスのための方法であって、
電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが含む複数のイベント証明書を電子デバイスが受信したことを証明する証明書情報を含む検証要求を生成することと、
検証要求を検証装置に送信することと、
を具備する方法が提供される。

少なくとも幾つかの実施例によれば、
電子デバイスのバッチの製造や改作を行う方法であって、
予め定められたイベントを電子デバイスのバッチのそれぞれについて行わせることと、
予め定められたイベントの発生の、暗号により認証された証明書を含むイベント証明書を電子デバイスのバッチのそれぞれに格納することと、
を具備し、
イベント証明書は、電子デバイスのバッチのそれぞれについて同じ暗号キーを用いて暗号により認証される方法が提供される。

少なくとも幾つかの実施例によれば、
電子デバイスのバッチのそれぞれについて予め定められたイベントを行わせる装置と、
予め定められたイベントの発生の、暗号により認証された証明書を含むイベント証明書を電子デバイスのバッチのそれぞれに格納する装置と、
を具備する電子デバイス製造装置であって、
イベント証明書は、電子デバイスのバッチのそれぞれについて同じ暗号キーを用いて暗号により認証される、電子デバイス製造装置が提供される。

少なくとも幾つかの実施例によれば、上記方法のいずれかを実行させるようデータ処理装置を制御するための命令を含むコンピュータプログラムが提供される。

本技術のさらなる態様、特徴及び利点は、添付の図面と共同して読まれる、以下の実施例の説明から明らかとなるであろう。

電子デバイスの製造の多段階プロセスの例を概略的に示す。 電子デバイスの例を概略的に示す。 製造プロセスの少なくとも一つの段階を実行する製造装置の例を示す。 電子デバイスのライフサイクル中に対応するイベントが発生したことを証明する、デバイスに埋め込まれたイベント証明書に基づき、デバイスがサービスにアクセスすることを許可されているかどうかを判断する技術を示す。 デバイスによって格納された複数のイベント証明書の例を示す。 生成後にデバイスによって格納された情報の例を示す。 デバイスによって格納されたイベント証明書のさらに詳細な例を示す。 改作段階におけるデバイスへのイベント証明書の埋め込みを示す。 電子デバイスがイベント証明書に基づいて認証される誕生段階を示す。 誕生段階における電子デバイスの認証方法を示すフロー図である。 以前にサービスへのアクセスが認められたデバイスがそのサービスに再登録可能な状態に戻される再生段階を示す。

サービスのプロバイダは、電子デバイスに対してある特定の行為を許可するために、そのデバイスが信用できるものとする特定のイベントをそのライフサイクル中に経てきたことをデバイスが証明できることを求める場合がある。例えば、そのようなイベントには、ハードウェアコンポーネントのインストール、ソフトウェアのインストール、デバイスが品質保証プログラムをパスすることなどが含まれ得る。ある特定の行為に必要な特定のイベントは、サービスプロバイダによって異なる。信頼の基礎を得る方法の一つとしては、ある特定の電子デバイスが、所要の処理工程を経てきたことが分かっている信頼できるデバイスの一つであるかどうかを判断する暗号手段によって検証可能なデバイス固有の秘密キーを、所要のイベントを経てきた各デバイスに提供することであってもよい。

しかしながら、この方法は幾つかの問題を抱えることもある。実際、電子デバイスの製造は、多段階プロセスであり、製造プロセスの様々な段階が異なるパーティによって行われることがある。もし、デバイスの全製造プロセスが安全であることを証明する一つのデバイス固有のキーを所定のデバイスに投入するとすると、その連鎖のうちの一つの製造業者が、キーの投入を行い、他のパーティが行った他の段階も実行されたことを証明するよう求められる場合がある。実際には、その製造業者は、様々な目的に向けられ、現製造業者の手から離れた後様々なパーティに引き継がれ、又は、現製造業者に到達する過程で複数の様々な手を経てきたデバイスの多くのバッチを処理しているかもしれない。従って、デバイスが所定の製造プロセスを経てきたことを証明できるためには、そのキーを投入する製造業者は、製造の連鎖を通る異なるルートを意図されたデバイスの異なるバッチを区別する必要があるかもしれない。また、デバイス固有の認証情報の利用は、既知のデバイスに関連するデバイス固有の情報の検証サービスプロバイダとの記録と同様に、製造プロセス中のそのデバイスとのより多くのオンライン通信を必要とし、より多くのネットワーク通信や、そのデバイス固有の認証情報の安全性を保護するためのより複雑な手段を必要とする場合がある。これら全ての要因によって、そのような電子デバイスの製造コストが増大してしまい、一部のデバイスが、デバイス自体のコストは比較的低いものの、ある程度のセキュリティ機能を必要とする比較的低リソースのデバイスである場合には、割に合わないこともある。これは、特に、比較的電力や面積に制約があるモノのインターネットのタイプのデバイスの場合に言えることであり、製造プロセスの効率化が有益となり得る。

以下に述べる実施例では、電子デバイスのライフサイクル中に特定のイベントが発生したことを証明する多数のイベント証明書を電子デバイスに提供することができる。例えば、イベントが異なる製造パーティによって行われた場合、各パーティがデバイスに個別のイベント証明書が投入し、その特定のパーティによって実施されるイベントが行われたことを証明する、暗号化により認証された証明書を提供する。電子デバイスの認証を行う際、そのデバイスは、２つ以上のイベント証明書を受信していたことを証明するために証明書情報をバリデータに送信することができ、バリデータは、その証明書情報が有効なものであるかどうかを示す認証結果を判定することができる。

従って、複数の個別のイベント固有の証明書をそれぞれ受信したことの証明を提供することにより、証明書の投入を行う現製造業者がその製造業者の制御管轄外のイベントについての証明を行う必要がないため、製造プロセスを大幅に簡素化することができ、所定のイベントがデバイスの特定のバッチで行われた場合、これらのデバイスのそれぞれは、後に製造者の連鎖からそれる可能性もあるそれらのデバイスのその後の行方に関係なく、対応するイベント証明書を投入されることができる。例えば、ある特定のセンサが最終的には冷蔵庫内で使用されることになるのか、それとも暖房装置内で使用されることになるのかを考慮する必要がない。

イベント証明書は、暗号により認証されている。暗号により認証されたメッセージには、暗号を用いて保護されたメッセージ、デジタル署名、メッセージ認証コード、一方向性関数が含まれていてもよい。

幾つかの実施例では、電子デバイスが検証装置に提供する証明書情報がイベント証明書自体であってもよい。この場合、イベント証明書の検証には、証明書のフォーマットが有効であること、及び／又は、対応する所要のイベントをデバイスに対して実行させるよう許可された既知の製造業者／改作者に関連するキーによって証明書の署名が行われたことの確認が含まれる。

また、イベント証明書は、実際に検証装置に送信されなくてもよく、その代わりに、電子デバイスにより以前に複数のイベント証明書が受信されたということを電子デバイスが確認したということを証明する、暗号により認証された証明書を電子デバイスが送信してもよい。従って、実際のイベント証明書の受信を電子デバイスが証明することができれば、それらが検証装置に送信されたということは必須ではない。例えば、実際のイベント証明書の代わりに、イベント証明書の識別子を特定する署名付きメッセージを送信してもよい。この例では、電子デバイスがイベント証明書の認証後もそれらを保存し続けることは必須ではなく、イベント証明書は、それが以前に見られて認証されたことを示す情報が電子デバイスによって一度、保存されると、破棄されてもよい。

幾つかの実施形態では、同じイベントを証明するために多くの電子デバイスに提供された、暗号により認証されたイベント証明書がそれぞれ異なる（例えば、証明書の使用を追跡するためにデバイス識別子が証明書に含まれていてもよい）ように、イベント証明書はデバイス固有のものであってもよい。

しかしながら、他の実施例では、２つ以上の異なる電子デバイスに対する所定のイベントの発生を証明するために同じイベント証明書を使用してもよい。従って、イベント証明書は、デバイスに依存しないものであってもよく、デバイス識別子などの特定の電子デバイスに固有の情報を含んでいなくてもよい。それは、特定のイベントを経ているデバイスのバッチに全く同じイベント証明書を投入することができることを意味するため、これにより、製造プロセスをさらに簡素化することができ、特定の証明書がどのデバイスに与えられているかを追跡する必要がないため、製造装置の管理の複雑性を軽減することが可能となる。

一実施例では、方法は、特定のイベント証明書の受信をすでに証明した他の電子デバイスの数を示す利用数を判定することと、その利用数に依存して検証結果を判定することとを備えていてもよい。例えば、イベント証明書は、特定の数のデバイス（例えば、そのイベント証明書をもともと投入されたバッチ内のデバイス数）での利用に限定することもでき、検証装置（又は、サービスプロバイダ装置）は、そのデバイスを承認すべきかどうかを判断するために、その利用数を設定された閾値と比較することができる。これにより、一つのデバイスに対するイベント証明書を傍受して別のデバイスに再利用する不正の試みの検出が可能となる。証明書の使用の閾値以上の回数が試みられたことを確認しても、どの具体的なデバイスが不正デバイスであるかを特定するには不十分な場合もあるが、にもかかわらず、これにより、サービスプロバイダは、対応するイベント証明書がもはや信頼できるものではないと判断し、これに対抗するための措置を講じることができる。

イベント証明書は、イベント証明書についての不正な試みや他の問題（例えば、上述の漏洩したイベント証明書を使用した不正デバイスや、その製造業者をもはや信頼できないということを意味するような方法でデバイスの製造を行なったとわかった特定の製造業者）が識別された場合に取り消すことができる。少なくとも一つの取り消されたイベント証明書の記録を保持することができ、検証結果は、証明書情報で証明された特定のイベント証明書が取消記録における取消されたイベント証明書のうちの一つであるかどうかによって決まってもよい。

幾つかの実施例では、デバイスが保持する各イベント証明書は、互いに完全に無関係なものであり得る。

しかしながら、幾つかの実施例では、デバイスのライフサイクル中の後のイベントの発生を証明するイベント証明書には、電子デバイスのライフサイクル中にその後のイベントよりも前に発生したはずの少なくとも一つの以前のイベントの発生を証明するための少なくとも一つのイベント証明書からの情報に依存するイベント連鎖情報が含まれていてもよい。デバイスにインストールされた連続したイベント証明書の間には暗号のリンクがあってもよい。例えば、各デバイスには、イベント証明書の特定の内容の暗号学的ハッシュが含まれていてもよく、一つのイベント証明書に対して生成されたハッシュには、以前にインストールされたイベント証明書のハッシュが含まれていてもよい。電子デバイスの検証を行う際、検証結果は、デバイスから受信したイベント証明書に関するイベント連鎖情報が、禁止された順番でイベントが発生したことを示しているかどうかによって決まってもよい。これは、例えば、デバイスが正当な製造業者の間の不正な製造業者を通過し、その不正な製造業者が追加のイベント証明書をデバイスに投入したか否かを検出するのに有用となり得る。バリデータは、予期されていない追加の証明書が投入されていることを検出することができ、その不正パーティがデバイスのセキュリティを脅かす何らかの行為を行なった場合に所定の行動を防ぐことができる。また、そのバリデータが信頼する正当な製造業者の間でさえ、許可されていない製造業者間のパスが存在する場合がある。例えば、ある一つのイベントが発生するまでは、別のイベントが安全に行われることができず、もし２番目のイベントが１番目のイベントより前に実際に行われたならば、デバイスのセキュリティを脅かす可能性がある。そのため、証明書同士を連鎖させることによって、禁止された順番で処理されたデバイスを検出することが可能となり、デバイスが信頼できるものかどうかについてより良い判断を行うことができる。

また、方法は、電子デバイスで発生する一つ以上のローカルイベントの発生時刻を示す監査ログを電子デバイスから受信することを備えていてもよい。バリデータは、監査ログに依存して検証結果を判定してもよい。例えば、その一つ以上のローカルイベントには、電子デバイスへの所与のイベント証明書のインストール、電子デバイスによる所与のプログラムコード機能の呼び出し、電子デバイスのブート処理、電子デバイスの一つ以上の属性の更新のうちの少なくとも一つが含まれていてもよい。そのようなイベントの発生時刻を記録することは、デバイスが製造プロセスの２つの工程間で異常に長い遅延に見舞われているときや、デバイスの対応するバッチが信頼できる製造業者に保持された既知の時刻と一致しない時刻にデバイスのブート処理が行われたり、その属性が更新されたりといった、デバイスの処理の不審なパターンの検出に役立つことができる。バリデータは、所定のイベント証明書に関連する電子デバイスのバッチが所定の製造業者によっていつ処理されたかを示すバッチ処理情報を保持してもよく、監査ログのバッチ処理情報との比較に依存して検証結果を判定してもよい。従って、イベント証明書自体がある特定のイベントの発生について暗号による証明を提供する一方で、デバイス自体によって生成され保存され得る他のイベント（ブート処理など）がある。このようなイベントは、暗号による署名や証明が行われないが、後にデバイスインテグリティの証明に使用可能な監査ログに記録されたイベントシーケンスの一部を形成することができる。

監査ログは、タイミングだけでなく、デバイスに接続された周辺デバイス（外部周辺機器や、デバイス内でバスに接続された、ローカル接続された周辺機器）の識別子などの他の追跡情報も記録することができ、不審な挙動の特定を可能にし得る。一般には、デバイスで発生するイベントに関連する監査ログを使用することによって、追加のイベント証明書が投入されたり、幾つかのイベント証明書が信頼できない製造業者／改作者によって削除されたり間違って形成されたりすることにならなかったとしても、不審な挙動の検出を可能とするため、電子デバイスに対する信頼をさらに高めることができる。

バリデータ（又はイベント証明書がローカルに検証される場合は、電子デバイス）が、所定のイベント証明書が所要のイベントに対して暗号によって認証された証明書であるかどうかの判断を行う、数多くの方法がある。一般に、所定のイベント証明書は、デバイスに対して対応するイベントを実行させることが許可された製造業者又は改作者に関連付けられた暗号化キーを用いて認証されてもよい。一実施例では、各イベント証明書には、その証明書の特定の内容の署名が付随してもよく、それは製造業者又は改作者に関連するキーを用いて生成される（このキーは、対称キーであってもよく、暗号化キー対の秘密キーであってもよい）。そして、バリデータや電子デバイスは、対称キーや秘密キーに対応する公開キーを用いた署名の照合を行うことにより、その署名が本物であることを確認することができる。他の実施例では、イベント証明書は、製造業者キー（対称又は秘密キー）を用いて暗号化された後、その証明書が有効であることを確認するために検証時に復号が行われる。デバイスが複数の製造工程を経てきたために、所定の行為を実行可能かどうかを確認するのに複数の証明書が必要な場合、それらの必要な証明書のそれぞれは、イベントを行うことを許可された製造業者又は改作者に関連する対応キーを用いて認証されてもよい。場合によっては、所定のイベントが複数の製造業者によって行われてもよい場合もあるため、認証プロセスには、提供されたイベント証明書の暗号による認証がどの製造業者又は改作者によっても行われなかった、もしくは、イベント証明書が有効なものであることが製造業者又は改作者の一つによって認証されたとの判定が行われるまで、そのイベントに関連した製造業者又は改作者の各プールに関連したキーを用いて所定のイベント証明書を認証することを試みることが含まれてもよい。

２つ以上の電子デバイスについてイベント証明書を認定するために同じ暗号化キーを用いてもよい。例えば、ある特定の製造業者が製造した全てのデバイスの認証を同じ製造業者キーで行ってもよい。デバイス固有の暗号化キーの必要性を回避することで、各デバイスにあつらえられた暗号化キーを生成する手段を提供することや、キーを安全に保存してデバイス固有のキーをバリデータに登録することは高価となり得るので、製造業者のオーバーヘッドが大幅に軽減される。また、デバイスの製造されたバッチのそれぞれを認証するために同じキーを使用することは、デバイスの実際の製造時に暗号化処理を行う必要がないことを意味し、なぜなら、デバイスのバッチに与えられる所定のイベント証明書に関連する暗号化認証は、オフラインで事前に準備してもよく、製造装置は単にその事前に準備された情報を各デバイスに投入すればよいだけであるからである。また、デバイス非依存のキーを使用することは、製造業者が、クエリーやもっと複雑なデバイス相互作用ではなく、各デバイスへの情報の一段階プッシュによって証明書を投入することができることを意味し、これにより、証明書の投入処理を高速化し、工場ワークフローのインテグレーションにより適したものとすることが可能である。

幾つかの実施例では、検証結果には、電子デバイスに対して所定の行為が許可されているかどうかの判定が含まれてもよい。証明書情報が認証された場合に実行が許される行為は異なってもよく、デバイスが用いられる特定の適用に固有のものであってもよい。例えば、この行為には、電子デバイスを所定のサービスにアクセス可能にすることが含まれてもよい。サービスへのアクセスには、例えば、デバイスがサービスプロバイダにデータをアップロードしたり、お返しにデータを受信したりするのを許可されることが含まれ得る。場合によっては、行為が許可されているかどうかを判定する際に行うチェックはイベント証明書の検証だけではなくてもよい。例えば、ハードウェアデバイス自体がセキュリティ要件を満たすかどうかの確認だけでなく、ユーザパスワード、生体認証情報などの認証情報に基づいたようなデバイスのユーザの検証もありうる。従って、電子デバイスによって所要のイベント証明書が提供されない又はその有効性が暗号により証明されない場合は所定の行為を阻止してもよい一方で、たとえ全ての必要な、暗号により認証されたイベント証明書が電子デバイスから入手可能だとしても、さらなるチェックが行われることもあるため、所定の行為を実行させるのに十分であるとは限らない。

あるいは、検証結果には、イベント証明書から得られる情報を示すデバイスレポートが含まれてもよく、これは、別の装置やソフトウェアプログラムによって、ある行為がデバイスで許可されているかどうかを判定するのに用いられる。

上記の証明書情報のチェックは、場合によっては、電子デバイスがアクセスを求めているサービスのサービスプロバイダによって直接行われてもよい。

しかしながら、サービスプロバイダ自体は、イベント証明書が本物であることを検証するための暗号法の対応を有していない場合が多い。また、そのデバイスに対して行為を行うことを許可された製造業者や改作者全てをある特定のサービスプロバイダが追跡するのは現実的ではないかもしれない。従って、イベント証明書の検証は、様々なサービスプロバイダの代わりにイベント証明書の認証を行うことができる第三者サーバーによって行われてもよい。この場合、イベント証明書から取り出された情報から得られた情報を含むデバイスレポートを所定のサービスのサービスプロバイダに提供することが特に有用であり得る。場合によっては、デバイスレポートは、証明書情報が有効であったかどうかの表示、及び／又は、電子デバイス上で実行されていたと確認されたイベントのリストを含むだけであってもよい。しかしながら、デバイスレポートには他の情報が含まれていてもよい。例えば、イベント証明書には、どの製造業者がイベントを行ったかについての特定の情報、又は、行われた特定のイベントの詳細が含まれていてもよい。イベント証明書は、サービスプロバイダにはすぐには理解できないかもしれないバイナリ形式に符号化されていてもよい。このように、場合によっては、イベント証明書の検証を行う第三者サーバーは、より有用な情報をサービスプロバイダに提供するために、イベント証明書の内容を拡張又は解析することによって得られた情報をデバイスレポートに含んでもよい。また、このレポートには、イベント証明書の使用（例えば、同じイベント証明書がこれまでに何台のデバイスによって使用されたか）に関する情報が含まれていてもよい。

上述のようにデバイスに対して所定の行為が許可されているかどうかを判定する方法を実行するために、検証装置が提供されてもよい。この検証装置は、デバイスから証明書情報を受信する通信回路と、証明書情報を検証し、その証明書情報が有効か否かに依存して、そして有効である場合、電子デバイスのライフサイクル中に発生するイベントとその証明書情報により識別されるイベント群に依存して、検証結果を判定する処理回路とを備えていてもよい。

それに対応して、電子デバイスは、外部デバイス（サーバーなど）と通信を行う通信回路と、その通信回路を制御して検証要求を検証装置に送信する処理回路であって、その検証要求が、複数のイベント証明書を電子デバイスが受信したことを証明する証明書情報を含む検証要求であって、それぞれのイベント証明書が、電子デバイスのライフサイクル中に各イベントが発生したことを証明する、暗号により認証された証明書を含む、処理回路とを有していてもよい。さらにまた、電子デバイスが、そのデバイスのライフサイクル中に複数のイベントについてそれぞれ個別のイベント証明書を複数受信したことを証明することによって、デバイスを製造する製造プロセスを簡素化することができる。

さらにまた、証明書情報は、イベント証明書自体であってもよいし、電子デバイスによってイベント証明書の受信が確認されたことを示す暗号により認証された証明書であってもよい。このイベント証明書は様々なフォーマットを有していてもよく、様々な種類の情報を含んでいてもよい。最も単純には、証明書には、特定のイベントが発生したことを示す識別子と、署名や製造業者キーを用いて適用される暗号など、その証明書が有効であることを認証する暗号手段とが含まれていればよい。

一実施例では、各イベント証明書は、イベント証明書の内容に適用される予め定められたハッシュ関数の結果に対応するハッシュ値と関連付けられてもよい。例えば、このハッシュ関数は、ハッシュ関数が分かっているだけではイベント証明書の内容を判定することが計算上、不可能であるように、暗号学的ハッシュ関数や一方向性関数であってもよい。これにより、電子デバイスに新しいイベント証明書が与えられた場合に、そのデバイス自体でイベント証明書のローカルチェックを行うことが可能となる。電子デバイスの処理回路は、その新しいイベント証明書のハッシュ値と、その新しいイベント証明書の内容に適用された予め定められたハッシュ関数の結果との間に不一致が検出されたときに、その新しいイベント証明書を記憶しないようにしてもよい。イベント証明書がデバイスに初めてインストールされたときに正しく形成されていることを確認することによって、例えば、粒子衝突によるランダムビットフリップやインストールプロセス中の他のエラーの、処理エラーによってデバイスが操作不能となってしまうリスクを軽減することができる。幾つかの実施例では、デバイスは、安全性の低いプロセスによるアクセスから（ハードウェアインフラや、暗号などのソフトウェア技術によって）保護された記憶装置の安全な領域を有していてもよい。イベント証明書の少なくとも一部（例えば、ハッシュ値やそのハッシュを得るために用いられるメッセージの別の部分）は、安全な記憶部に格納されてもよい。イベント証明書の他の部分は、通常の記憶部に、または、安全な記憶部に格納されてもよい。メッセージの少なくとも一部又はハッシュを安全な記憶部に格納することにより、非安全な部分が変更されたとしても、安全な部分を変更できないようにして、そのような変更を検出することができる。

一実施例では、デバイスに与えられる新しいイベント証明書にはもともとスタブ部が含まれていてもよく、新しいイベント証明書のハッシュ値は、スタブ部に依存していてもよい。しかしながら、スタブ部は、デバイスによって新しいイベント証明書が検証された後、電子デバイスの処理回路によって破棄されてもよい。従って、スタブ部は、デバイスの記憶回路に記憶されなくてもよい（もしくは、最初は記憶されるが、その後無効にされたり上書きされたりしてよい）。新しいイベント証明書は、ハッシュ値と、この新しいイベント証明書のスタブ部を除く内容とから得られた署名に関連付けられてもよい。証明書情報には、イベント証明書に関連付けられた署名や、イベント証明書に関連付けられた署名の有効性が認められたことを示すものが含まれていてもよい。各署名は、電子デバイスのライフサイクル中、対応するイベントを電子デバイスにおいて実行させる製造業者又は改作者と関連付けられた暗号キーを用いて生成されてもよい。スタブ部は、例えば、乱数値や疑似乱数値であってもよい。

署名ではなくハッシュを生成するのに用いられるスタブ部を、デバイスに与えられる元の証明書に含めることによって、デバイスから証明書を回収した攻撃者が、信頼されたデバイスのクローンを作成したり、別のデバイスが信頼されると不正に主張したりするために同じ証明書を他のデバイスに投入することが非常に困難となる。イベント証明書を回収した攻撃者がハッシュ値からスタブを再生成したり、様々な値を片っ端から試すことでスタブの再生成に成功したりすることは計算上、不可能であり、証明書のハッシュは、受信されたイベント証明書の内容をハッシュした結果とは一致しないので、スタブなしでは、他のデバイスが証明書を承認することはない。

場合によっては、所定の電子デバイスに対してある特定のイベントが行われたものの、元のイベントが何らかの方法でキャンセルされたり覆されたりする何らかの行為がデバイス上で行われた場合、そのデバイスが本当に信頼できるものであるか確かではないこともある。例えば、あるソフトウェアがインストールされたことを示す証明書については、その証明書は、デバイスにおいてそのソフトウェアがインストールされ続けている場合のみ有効であればよく、そのソフトウェアに対していかなる形でも変更が行われることはなかったと信じることができる。従って、イベント証明書の幾つかの型は条件付きであってもよく、イベント証明書を提供する製造業者又は改作者は、電子デバイスが予め定められた条件を満たすことを条件に、予め定められたイベントの発生を証明することができる。この場合、電子デバイスの処理回路は、検証装置に検証要求を行うときに、その予め定められた条件がまだ満たされているかどうかの検証を行えばよく、その予め定められた条件が満たされていない場合は、条件付きイベント証明書が正当に受信されたことを示す証明書情報が送信されないようにすればよい。

例えば、予め定められた条件とは、その特定のソフトウェアが記憶回路の予め定められた領域にインストールされているということであってもよい。この条件付きイベント証明書によって、メモリの領域や、指定された領域の内容に何らかのハッシュ関数を適用することの期待値を示す期待ハッシュコードが特定されてもよい。特定のメモリ領域の内容をハッシュした結果が期待ハッシュコードに一致するかどうかチェックすることにより、デバイスは、前もってインストールされたソフトウェアがまだ変更されていないかどうか、ひいては条件付きイベント証明書を提供することは安全かどうかを判定することができる。

あるいは、メモリ領域の内容のハッシュは検証装置に送信されてもよく、検証装置は、ハッシュ結果が期待ハッシュコードと一致するかどうかをチェックすることにより、ソフトウェアのインテグリティを検証することができる。

電子デバイスは、デバイスを信頼できるものにする、デバイス上の特定のセキュリティ機構を提供するためのハードウェアアーキテクチャサポートを有していてもよい（幾つかの実施例では、そのようなハードウェアアーキテクチャ機能を有するシステム・オン・チップのインストールが、イベント証明書が要求されるイベントの一つであってもよい）。例えば、デバイスの処理回路は、安全性の低い実行環境で動作する安全性の低いコードによるアクセスから、安全な機能に関連付けられた特定のコードやデータを保護するために、安全な実行環境と安全性が低い実行環境とをサポートしてもよい。そのようなハードウェアアーキテクチャ技術の例としては、イギリス国ケンブリッジ市のＡＲＭ（登録商標）社により提供されるＴｒｕｓｔＺｏｎｅ（登録商標）アーキテクチャが挙げられる。このため、条件付きイベント証明書について予め定められた条件が満たされているかどうかの検証や、デバイスにインストールされる新しい証明書が正しく形成されているかどうかの検証といった電子デバイス上で行われる幾つかの工程は、セキュリティを向上させるために、安全な実行環境で実行するソフトウェアの制御の下で実行されてもよい。

電子デバイスを使用した、予め定められたサービスへのアクセス要求が検証要求に含まれる例では、デバイスは、アクセスが可能となったことを示す信号をバリデータやサービスプロバイダから受信してもよい。サービスへのアクセスが可能となったことに応答して、処理回路は、記憶回路からの複数のイベント証明書の削除、電子デバイスと検証装置との間の通信を保護するための少なくとも一つのデバイスキーの削除、検証装置に対して電子デバイスを識別するためのデバイス識別子の削除、電子デバイスと予め定められたサービスのサービスプロバイダとの間の通信を保護するための少なくとも一つのデバイスキーの格納、予め定められたサービスのサービスプロバイダに対して電子デバイスを識別するためのデバイス識別子の格納、のうちの少なくとも一つをトリガしてもよい。従って、イベント証明書は、デバイスに恒久的にインストールされなくてもよく、一旦、デバイスによるサービスへのアクセスが可能になると、イベント証明書は、もはや何の目的を果たすものでもなくなり、これらのイベント証明書を破棄して記憶容量を解放した方がより安全となり得る（特に、資源に制約のあるモノのインターネットのタイプのデバイスでは、与えられた記憶容量が非常に限られている場合がある）。同様に、検証装置との通信に関連するデバイス識別子の任意のデバイスキーを削除することができる。予め定められたサービスのサービスプロバイダとの通信に関連付けて新しいデバイスキー又は識別子を設定してもよい。これらの対策の全てが必須というわけではなく、特定のサービスによって、サービス登録時にどの工程を実行するかは、特定のサービスに固有に選択してもよい。例えば、場合によっては、サービス登録後にデバイスに対してさらなるライフサイクルのイベントを記録できるようにするために、イベント証明書、デバイス識別子又はデバイスキーを保持してもよい。

所定のサービスへのアクセスが可能となった後、デバイスをその後、別のサービスに、又は、別のユーザによって再利用し、そのデバイスの過去のライフサイクルの一部又は全ての特徴（例えば、過去の所有者が誰だったか）を忘れることが望ましい場合がある。そして、デバイスをサービス（前と同じサービスであってもよいし、別のサービスであってもよい）に再登録してもよい。これをサポートするため、所定のサービスプロバイダは、アクセスが可能となって以来、予め定められたサービスの使用から生じた情報をデバイスに削除させるトリガとなり得る再生要求を電子デバイスに発行可能であってもよい。再生要求の処理は、先と同様に、デバイスが以前に登録されていたサービスプロバイダから再生要求が来たことの認証といった、特定の暗号による認証の実行を必要とする場合がある。デバイスは、例えば、任意のアプリケーション固有のデータ又はキーを削除してもよい。

このようにデバイスが「再生」されると、上述のように前のサービス登録時に以前にインストールされたイベント証明書が削除された可能性があるため、サービスに再登録できるようにするために、デバイスに新しいイベント証明書をインストールすることが必要となる場合がある。従って、サービスプロバイダによって送られた再生要求には、少なくとも一つのイベントの発生を証明する少なくとも一つの再生イベント証明書が含まれてもよく、処理回路は、再生要求に応答して、その後の検証要求についての証明書情報を生成するために、少なくとも一つの再生イベント証明書を記憶回路に格納してもよい。

再生要求に含まれたイベント証明書は、最初のサービス登録時にデバイスが保持していた元のイベント証明書と同じでなくてもよい。例えば、デバイスが前回の登録の前に多くのイベント証明書を保持していたとしても、これらが全て削除された場合、サービスプロバイダは、そのサービスへの加入についてそのサービスプロバイダが要求するイベントが全て行われたと推測することしかできず、自身のサービスへのアクセスに不要な他のイベントが行われたか否かは証明することができない。従って、デバイスは、再生後は、元来そうであったのと同じ、様々なサービスに加入する能力を有しないかもしれない。にもかかわらず、デバイスが他のユーザに手渡されたならば再登録が可能となるように再生イベントを可能にすることは有効となり得る。再生イベント証明書は、場合によっては、デバイスの再登録を前と同じサービスプロバイダに効果的に限定するものであってもよい（例えば、サービスプロバイダは、デバイスが以前、そのサービスの要件を満たしていたという自身のイベント証明書を信じればよく、その後の試みでデバイスの再登録を行うことができるが、他のサービスプロバイダは別のサービスプロバイダによって提供された証明書を信用したがらないかもしれない）。

電子デバイスのバッチを製造する又は改作する方法は、予め定められたイベントをデバイスのバッチのそれぞれに対して行わせることと、予め定められたイベントの発生の、暗号により認証された証明書を含むイベント証明書をデバイスのバッチのそれぞれに記憶することとを備えていてもよく、ここで、イベント証明書は、デバイスのバッチのそれぞれに対して同じ暗号キーを用いて暗号により認証される。イベント証明書の暗号による認証をデバイスに依存しないものとすることにより、製造プロセスを大幅に簡素化することができる。バッチに対するイベント証明書は、各デバイスで同じであってもよく、デバイス固有の情報を含んでいてもよい。

場合によっては、例えば、一つの製造業者によってデバイスの同じバッチに対して複数の異なる処理工程が行われる場合、デバイスのバッチのそれぞれには複数のイベント証明書が製造業者により投入されてもよい。投入されたイベント証明書のそれぞれは、一つのイベントに対応していてもよい。デバイスのライフサイクル中に行われた同じイベントに対応する複数のイベント証明書を提供することができる。例えば、ある特定のイベント（例えば、ソフトウェアのインストール）が始まり、その同じイベントが終了したことを別々のイベント証明書によって証明してもよい。

イベント証明書には、電子デバイスから読み出された情報とは独立して生成された、予め用意された情報が含まれてもよい。これは、製造装置から電子デバイスへの通信が一方向性のものであり、電子デバイスからの応答を考慮する必要がないことを意味している。

上述の方法は、データ処理装置上で実行するソフトウェアの制御の下で行われてもよい。従って、コンピュータプログラムには、データ処理装置に上述の方法（新しくインストールされた証明書の検証及び／又は所定のサービスへのアクセス要求を行うために電子デバイス自体に対して行われる、検証装置における検証方法と、製造装置において行われる製造方法を含む）のいずれをも実行させるよう制御する命令が含まれていてもよい。このプログラムは、記録媒体に格納可能である。この記録媒体は、非一時的記録媒体であってもよい。

図１は、電子デバイスを製造するための多段階製造プロセスの例を示し、多くの異なるデバイス製造業者又は改作者０、１、２、３を含んでいる。各製造業者又は改作者は、デバイスの所定のバッチに対して一つ以上のイベントＡ－Ｆを行う。一般に、イベントには、製造業者／改作者がデバイスに対して行ういかなる行為、例えば、特定のハードウェアコンポーネント（システム・オン・チップやセキュリティモジュールなど）のインストール、デバイスへのソフトウェアのインストール、テスト手順や品質保証プログラムを用いたデバイスのテスト、特定のデバイスモードの起動、第三者サーバーによるデバイスに関する情報の記録などが含まれてもよい。デバイスの所定のバッチの製造には、異なるパーティによって実行され得る複数の段階が含まれる。例えば、図１の例では、バッチ０に対してイベントＡ、Ｄ、Ｅが行われ、イベントＡが製造業者０によって行われ、イベントＤ、Ｅが製造業者２によって行われる。バッチ１に対しては、イベントＡ、Ｆがそれぞれ製造業者０、３によって行われる。バッチ２に対しては、イベントＢ、Ｃ、Ｆが行われ、イベントＢ、Ｃが製造業者１によって行われ、イベントＦが製造業者３によって行われる。従って、デバイスの異なるバッチは、プロセスの特定の段階で特定の製造業者によって共通に処理される場合でも（例えば、バッチ１、２はいずれも、それらのライフサイクルの早い段階で異なる製造業者を通ってきたにもかかわらず、製造業者３によってイベントＦに関する処理が行われる）、製造の連鎖を通して異なるルートを取り得る。

図２は、電子デバイス２の例を示す。このデバイスは、プログラム命令に応答してデータ処理を行う処理回路４と、処理回路４によって処理されるデータや命令を記憶する記憶回路６とを有している。記憶回路６は、ハードウェア機構によって（例えば、信頼できる実効環境を提供するメモリ保護ユニットやセキュリティ機構を用いて）又はソフトウェア機構（例えば、暗号）によって保護される安全な領域８を有していてもよく、それにより、信頼できる環境内で実行されていないソフトウェアには、安全な領域８に記憶されたデータにアクセスできなくなる。デバイス２は、外部デバイスと通信を行うための通信インタフェース１０を有している。例えば、通信インタフェース１０は、ＷｉＦｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）などの他の様々な通信プロトコルを利用してもよい。デバイスは、温度、圧力、近くにいるユーザの近接性など特定の外部状況を検知するための一つ以上のセンサ１２を有していてもよい。備えられる特定のセンサ１２は、デバイスの目的によって決められればよい。図２はデバイスに備えられる可能性のあるハードウェアのほんの一例を示すものであって、他のコンポーネントも備えられていてもよいことは理解されよう。例えば、ユーザの相互作用が予想されるデバイスは、ユーザに対して情報を表示したり、ユーザからの入力を受信したりするためにディスプレイ及び／又はユーザインタフェースモジュールを備えていてもよい。他のタイプのデバイスとしては、単に、データを収集し、外部デバイスにそのデータを送信するセンサであってもよく、このようなタイプのデバイスはユーザインタフェースやディスプレイを必要としない。以下に説明する検証装置は、検証装置の処理回路４の方が電子デバイス内の処理回路よりも強力で、記憶部６がより大きい記憶容量を備えられているかもしれないものの、図２の電子デバイスから示されるものと同様の構成を有していてもよい。

図３は、所定の製造業者又は改作者によって提供された製造装置２０の例を示す。デバイスのバッチを処理するための処理ラインには、デバイスのバッチのそれぞれに対して予め定められた行為を行うための行為実行装置２２が含まれる。この行為は、例えば、ソフトウェアのインストール、ハードウェアコンポーネントの作成又はインストール、デバイスのテストなどであり得る。デバイスのバッチは、一つ以上の予め定められた行為が行為実行装置２２によって行われたことを証明する一つ以上の事前作成済み証明書２６をデバイスの各バッチに格納する証明書記憶装置２４に送られる。この事前作成済み証明書は、オフラインで用意されてもよく、関連する行為を実行する製造業者又は改作者に関連付けられた製造業者キーによって署名されていてもよい。複数のイベントが同じ製造業者によって行われる場合、それぞれが一つのイベントを証明する複数の証明書が投入されてもよい。図３は、行為がなされた後にデバイスを処理する証明書記憶装置２４を示しているが、証明書は行為がなされる前又はそれと同時に投入されてもよい。図３は、デバイスのバッチが行為実行装置２２から証明書記憶装置２４へと進むことを示しているが、バッチの他のデバイスがまだ行為実行ステージ２２にある間に、一部のデバイスが証明書記憶ステージ２４でイベント証明書の投入が行われるよう、デバイスの処理がパイプライン化されていてもよいことは理解されよう。また、場合によっては、行為実行装置及び証明書記憶装置は、同一の装置であってもよく、例えばソフトウェアをインストールするときに、同時に対応するイベント証明書がインストールされ得る。

各証明書は、所定のイベントが行われたことを証明する、暗号により認証された証明書である。この証明書は、以下の実施例では「ホログラム」とも称される。図１の例のように電子デバイスが製造の連鎖を移動する際、デバイスのライフサイクルにおける各重要なイベントが所定のイベント証明書のインストールで記録される。どの特定のイベントがイベント証明書のインストールを正当化できるくらい重要だと見なされるかは、これらのデバイスの特定のアプリケーションによって決められればよい。以下に説明するフレームワークは、様々なアプリケーションやサービスに適用可能であり、証明書によって記録される特定のイベントは、アプリケーションによって異なってもよい。従って、図５に示すように、製造の連鎖を移動するデバイスは、多数のイベントについてイベント証明書３０のコレクションを作り上げてもよい。例えば、図１の例におけるバッチ０は、最終的にイベントＡ、Ｄ、Ｅに対応するイベント証明書３０を有することになってもよい。イベントＡの証明書は、製造業者／改作者０に関連付けられた製造業者キーＫ_Ｍ０によって署名され、イベントＤ、Ｅの証明書は、製造業者／改作者２に関連付けられたキーＫ_Ｍ２によって署名される。

図４に示すように、電子デバイスは、所定のクラウドサービスへのアクセスを求める際、これらの証明書を利用することができる。電子デバイスは、サービスプロバイダ５０へのサービスアクセス要求４０を発行する。要求には、デバイスの記憶部６に格納されたイベント証明書の一部（又は全て）が含まれる。サービスプロバイダ５０は、イベント証明書をチェックして特定の要件を満たしているかどうかを判定する責任がある検証装置６０に要求を転送する。具体的には、サービスプロバイダ５０は、デバイスがそのサービスへのアクセスを認められるために、デバイスのライフサイクル中に特定のイベントが発生することを求める場合がある。検証装置６０は、特定のイベントについて正当に暗号により認証された証明書に関する情報を記録する製造業者／証明書データベース６２を整備してもよい。幾つかのイベントは、複数の製造業者によって行われることが許されていてもよく、この場合、それぞれがそのイベントについて有効であると見なされる、異なる製造業者キーで署名が行われた、複数の異なる証明書が存在してもよい。また、証明書データベース６２には、取り消された証明書のリストや、証明書の許容使用限度に関する情報が含まれてもよい。検証装置６０は、検証装置６０が通信し得る様々なサービスプロバイダ５０の要件を記録し得るサービスプロバイダデータベース６４にアクセスを有していてもよい。例えば、各サービスプロバイダは、電子デバイスがそのサーバーにアクセスするのを承認するにはどのイベントが必要とされるかや、デバイスがそのサービスにアクセス可能となるまでにチェックすべき他の基準を特定してもよい。

検証装置６０は、与えられた証明書を、証明書データベース６２とサービスプロバイダデータベース６４の情報と比較することによってデバイス要求４０の検証を行う。サービスプロバイダが要求する各イベントに対して、デバイス２が正しい暗号により認証されたイベント証明書を提供できなければ、検証は失敗となる。検証が成功した場合、検証装置６０は、デバイスがサービスに対して承認され得ることを示すためにメッセージ６６をサービスプロバイダ５０に返す。このメッセージには、要求４０と共に与えられた証明書から得られたデバイスに関する特定の情報を提供し得るデバイスレポートが付随してもよい。

あるいは、サービスプロバイダデータベース６４はなくてもよく、検証が成功したかどうかを示すのではなく、検証装置６０によって与えられる検証応答６６が単に、イベント証明書がうまく形成されたこと（及び、必要に応じて、特定の情報を伝えること）のアサーションとなってもよい。この場合、証明書が有効であると仮定して、そのサービスへのアクセスを可能にするために他の要件が満たされているかどうかは、サービスプロバイダ５０の判断次第であり得る。

図４にはサービスプロバイダ５０と検証装置６０が別々のデバイスとして示されているが、他の実施例では、デバイス要求４０の検証をサービスプロバイダ５０によって行ってもよく、デバイス５０、６０を組み合わせることができる。従って、一般に、うまく形成されたイベント証明書の検証（署名のチェックなど）、証明書の意味の解析、その情報の特定のサービスプロバイダの要件との比較、デバイス２によるサービスへのアクセスを可能にするかどうかの判断の機能は、全て、サービスプロバイダ５０又は検証装置６０によって、もしくは全く別の動作主体によって与えられ得る機能である。

検証が成功した場合、サービスプロバイダ５０と電子デバイスは、サービス固有の通信６８を行ってもよい。例えば、デバイス２とサービスプロバイダ５０は、サービスプロバイダ５０とのその後の通信を保護するためのデバイス固有のキー情報を設定してもよいし、デバイスがアクセスする特定のサービスに固有の他の情報を設定してもよい。

上記技術の具体的な実施例について以下に説明する。本発明がこれらの具体的な実施例に限定されるものではないことは理解されよう。この技術は、デバイスのライフサイクルに関する情報の記録と証明に関し、特に、数多くの工程を経る製造プロセスに関するものである。その後、デバイスがこれらの工程を経たことを証明するウェブサービスが可能となる。この技術はまた、デバイスへの信頼のルート（Root of Trust）や他の情報の提供にまで及ぶ。所有者間でのデバイスの追跡を許さない方法でデバイスを安全に再提供することもサポートしている。

ＫＰＨ／証明書システムは、工場がデバイスの「誕生」を証明し、その後ウェブサービスにそのデバイスが「良好な」工場で誕生したことを確認させるのを可能にする。ＫＰＨ（キー提供ホスト）では、キーは、デバイスで生成され／デバイスへ投入され、そのキーが証明書サービス（検証装置）６０に知らされる。これにより、サービスは、メッセージがデバイスから生じたものだということ（それしかキーを知らないので）を後に確認することができる。このメカニズムを利用して、メッセージ（及び、具体的には、ホログラム）が所定のデバイスから生じていることを検証装置６０に証明することができる。この技術は、多段階製造／ライフサイクルへとそれらの概念を拡大する。デバイスは、生成され、複数回特殊化された後に「使用」されてもよい。この技術によれば、デバイスのライフサイクル中に証明された全ての工程を検証する手段が提供される。ＫＰＨによれば、その後のライフサイクル工程（ホログラム）をデバイスでのみ記憶し、その時点でのバックエンドとの通信の必要性をなくすことができる。

さらに、本技術は、デバイスが要求するオンライン通信の量を最小限に抑える手段によってそれを実現する。最初の「生成」が、バックエンドウェブシステムとの通信を行わずに、もしくは、遅延／バッチ通信により、行われるようにする。さらに、いかなるライフサイクル工程も、ネットワークアクセスを必要とせずに記録されることができるようにする。

また、本技術は、デバイス履歴は破棄／削除するが、重要な点を選択的に記憶する、例えば、医療デバイスが「ｎ」回使用されたことを記録しながら、デバイスの以前のユーザに関するキー／身元情報を安全に破棄し得る（これは、ホログラムを破棄すること、及び／又は他のもの、例えば、「ｎ」回使用を示すものと置換することによって行われる）、手段を提供する。

本技術は、この全てを少ない記憶容量／処理量で行うことが可能にし、ＩｏＴや他の制約付きデバイスに適したものとなる。

また、本技術は、デバイスごとに必要な暗号や他の処理の量を最小限に抑えることで工場への負担を軽減し、セキュリティ／性能において柔軟なトレードオフを可能にする。

また、本技術は、システムにおける不正行為を検出する手段が提供する。

このシステムは、以下の特徴を利用する。
・デバイス識別子と関連する秘密（キー）。
・工場が作成した証明書は、外部サーバーに送信されるのではなく、デバイスに格納され、キーにより保護される。
・証明書は署名によって保護されるが、証明書のオフライン生成をサポートし、証明書のバッチ処理（例えば、１０００個のデバイスに使用される証明書）を行うよう構成される。
・証明書の格納及び送信は、非常に効率的なスキームを用いて行われる。
・不正行為の検出が、不正利用が見つけられるよう証明書に含まれた予想利用情報によって可能となる（例えば、「この証明書は一回だけ使用してよい」）。

さらなる特徴を以下に述べる。
１）デバイス製造の複数の段階についての情報を収集し、これらの段階が全て行われたことをサーバーが証明できるようにする。
２）製造の各段階を担うエンティティはお互いを信頼していなくてもよい。
ａ．最終的なデバイス権限者［デバイスディレクトリや検証装置６０］は各製造エンティティとの関係しか必要としない。
ｂ．デバイスはエンティティを信頼していなくてもよい。
３）製造段階を担う２番目以降のエンティティは、
ａ．ネットワーク接続を必要としない。
ｂ．デバイス固有の情報を生成しなくてもよい。
ｃ．製造中又は製造後に暗号処理を行わなくてもよい。
ｄ．「ホログラム」を格納してその窃盗防止を行わなければならないが、デバイス固有の記録／受信の安全な格納を必要としない。通常、ホログラムの数はデバイスに比べてはるかに少ないので、これらの格納要件はより穏当である。
ｅ．クエリーやもっと複雑なデバイス相互作用ではなく、各デバイスへの情報の一段階「プッシュ」しか必要としない。したがって、これは、より高速で、工場ワークフローのインテグレーションにより適したものとなる。
４）攻撃者／不正エンティティ
ａ．一つのエンティティの攻撃に成功しても、他のエンティティに成り済ませない。
ｂ．一つのデバイスから秘密を盗んでも、他のエンティティに成り済ましたり、その情報を２番目のデバイスで再生したりできない。
５）セントラルサーバーは以下の場合に不正行為を検出できる。
ａ．工場で生成された「ホログラム」が許容された以上の回数、再利用された場合。
ｂ．主張されたライフサイクルが無効である場合。
６）リサイクルされたデバイスは
ａ．その過去のライフにリンクできない。
ｂ．セキュリティに関連するプロパティを保持する。
７）製造エンティティは、デバイスがいくつ製造されてきたかを、それらのデバイスが「誕生」するまで［誰にも］開示しなくてもよい。

デバイスのライフサイクルは複数の段階を通じて保護される。
１）生成
コアデバイスが生成される。これは、シリコン工場におけるＳｏＣ、完全に組み立てられたデバイス、又は中間の物であってもよい。デバイスライフサイクルにおいて関与できる段階が早ければ早いほど、そのライフサイクルの保護できる部分が大きくなる。
２）改作
これは、デバイス製造において重要なイベントである。この例としては、ＯＤＭによるコンポーネントへのＳｏＣの埋込み、デバイスのＱＡ工程の通過、又は、デバイスへのソフトウェアの提供が挙げられる。
３）誕生
これは、その「生成ストーリー」をサードパーティに証明したいと望む、デバイスの名目上の最初の使用である。具体例としては、ＩｏＴデバイスがそのバックエンドのクラウドサービスに初めて接続され、それが正当であることを証明したい場合が挙げられる。この時点では、「ライフ」段階での使用についての情報も提供される。
４）ライフ
ここでは、デバイスが使用され、ユーザ又はアカウント固有の特徴を証明することが望まれる。
５）再生
デバイスが再利用され、この時点で「ライフ」部分からの以前の履歴を安全に忘れさせる必要がある場合もある。本発明では、「再生」デバイスが「発生」デバイスと同じくらい新しいことを確かにするようにこれを行う手段が含まれる。

生成
デバイスの生成については、既存技術やその変形例を利用して各デバイスに固有の識別子及び秘密キーを与えることが提案されている。対応する公開キーは、ウェブサービス（デバイスディレクトリ６０）に格納されている。これを行う既存の手段が存在し、それに対して新しいアプローチが追加され、（デバイスＩＤ、公開キー、デバイス属性の）タプルは、それが既知の位置で生成されたことを示すよう、工場により署名されることができる。そして、その署名されたタプルは、この段階でデバイスディレクトリ６０に送信するのではなく、デバイス自体に格納されることができる。

デバイス生成の間は、デバイスは、デバイス上の他のソフトウェアや、サードパーティ／他の工場装置によって読取や変更ができない秘密キーを生成する（又は与えられる）。これを行うには既存のよく知られた手段が存在する。デバイスは、サードパーティによる読取／変更ができない情報の格納のために使用可能な、容量の小さい安全な記憶部を有する。（サードパーティはこの情報を消去できるかもしれないが、他の決定的な方法ではそれを読み出したり変更したりはできない）。

生成後、デバイスは、図６に示される情報を含む。データの大部分を通常の記憶部に格納することにより安全な記憶部を形成し、安全な記憶部に格納されたキーによって暗号化やその他の保護を行ってもよい。通常の記憶部に格納されているものなら何でも安全な記憶部に格納してもよい。製造業者キーにより署名された、デバイス公開キー、デバイスＩＤ及び他のいかなるデバイス属性を提供するレシートがデバイスに格納されてもよいし、帯域外のデバイスディレクトリ６０に送信されてもよい。

改作
改作段階では、工場（例えば、ＯＤＭ）は、例えば、特定の工場によるモジュールの生成など、その後の製造工程が完了したことを示す証明書をデバイスのために生成することを望む。

簡単な方法は、２つ目のレシートを生成して、デバイスディレクトリ６０に送信するか、デバイスに格納するであろう。これはもっともらしいが、本技術なら回避可能なデバイス毎の費用が生じてしまうことになる。代わりに、（仮想）ホログラムの概念を導入する。これらは、それらの物理的対照物のように、特定の事実、すなわち、それらが添付されたデバイスが特定の特性を有するということを証明する、事前に生成されたエンティティの形を取る。レシートとは異なり、ホログラムは、あらかじめ製造ラインから離れて生成することができるという利点がある。さらに、ホログラムは、以下の特定の特性が得られるよう構成される。
・ホログラムは、予め設定された限度まで、工場によって複数回、使用可能である。
・ホログラムは、Ｘ線走査などの特殊技術を用いてもデバイスから取り外したり、大量に再利用したりできない。
・ホログラムは、盗難や未使用を報告できる。
・ホログラムの不正使用は検出可能である。
・ホログラムの検証は、工場での迅速なデバイス上段階と、そのあとのデバイス「誕生」中のオンラインチェックの二段階である。
・ホログラムは、ネットワークアクセスの必要を回避するよう、デバイスに格納される。

ホログラムのフォーマットは、以下の通りである（これはフォーマットのほんの一例であり、他の例には、デバイス上で検証した後破棄できるスタブや、ホログラムが既知のエンティティ（キー）によって生成されたことを証明する署名が含まれ得る）。
（チケットスタブ、ホログラムＩＤ、アサーション、ハッシュ、署名）
・チケットスタブ：これはホログラムのハッシュに結合された無作為の識別子である。チケットスタブは、デバイスによって受け付けられ、デバイスから回収されたホログラムが再利用できないよう後に破棄される目的で、「新しい」ホログラムに必要である。
・ホログラムＩＤ：これは生成されたホログラムのそれぞれに固有の識別子であり、これにより、デバイスディレクトリ６０は、利用を監視し、それが予想範囲内であることを確実にすることができる。
・利用数［任意］：このホログラムＩＤのインスタンスがいくつ許容されているか。さもなければ、この情報がデバイスディレクトリ６０に格納されていると仮定される。
・アサーション：アサートされた属性の、標準化された形式での簡潔な（バイナリ／テキスト）記述。アサーションを行う工場／エンティティの表示を含む。
・ハッシュ：ホログラムがうまく形成されていることをデバイス上で迅速に検証することができるための、チケットスタブ、ホログラムＩＤ及びアサーションの安全なハッシュ。このハッシュは、デバイスの安全な記憶部に格納される（他の部分は通常の記憶部に格納される）。
・署名：工場の秘密キーを用いて生成されたホログラムＩＤ、アサーション及びハッシュの上の署名。これによって、ホログラムが既知のエンティティ（工場）によって生成され、変更されていないことが証明される。チケットスタブは署名のチェックが行われる前に破棄されるため、この署名にカバーされない。しかしながら、ハッシュは含まれるので、デバイスからホログラムを回収した攻撃者がスタブを再生成するのは不可能である。

各改作段階では、関連するホログラムをデバイスに格納する。２つのこのような段階の後では、デバイスの内容は図７に示すようになり得る。

図８は、所定の電子デバイス２についての改作段階の処理の例を示す。ステップＳ１では、製造装置２０は、電子デバイス２に一つ以上の行為を実行する。ステップＳ２では、実行された行為のうちの少なくとも一つに対して、それぞれが、行為を実行した製造業者又は改作者に関連付けられた暗号キーによって認証が行われた、一つ以上の証明書（ホログラム）を取得する。一つのホログラムは、複数の行為が行われたことを示してもよい。この行為は、物理的な行為ではなくてもよく、例えば、証明書の中にはデバイスが特定の製造業者を通過した（「デバイスがここにあった」）ことを単に証明するものがあってもよい。証明書は、デバイスの全バッチに用いられる事前作成済み証明書であってもよく、または、デバイス固有の情報を有していてもよい。ステップＳ３では、取得された証明書をデバイスに提供する（又は、各証明書を一つずつ別々に送信して提供してもよい）。各証明書について、デバイス２は検証チェックを行ってその証明書がよく形成されているかどうかを判定する。ステップＳ４では、デバイス２は、スタブ部を含む証明書の内容に暗号学的ハッシュ関数を適用することによりハッシュ値を生成する。必要に応じて、暗号学的ハッシュ関数への入力として用いられる値には、デバイスが保持する直近にインストールされた証明書に関連付けられたハッシュ関数が含まれてもよい（詳細は以下を参照）。デバイス２は、ハッシュ関数の結果が、その証明書に関連付けられた期待されるハッシュ値と一致するかどうかを判定する。ハッシュ結果が期待されるハッシュ値と一致しない場合、ステップＳ５で証明書を拒絶する。ハッシュ結果が期待されるハッシュ値と一致する場合、ステップＳ６で証明書を電子デバイス２の記憶回路６に格納する。少なくとも、格納された証明書に関連付けられたハッシュ値は安全な記憶領域に格納される。ステップＳ７では、証明書のスタブ部が破棄される（このスタブ部はデバイス６の記憶回路には格納されない）。製造装置２０から複数のイベント証明書を受信した場合、証明書のそれぞれに対してステップＳ４－Ｓ７が繰り返される。

誕生
誕生段階では、以下の一部又は全てを行うことが望まれる。
・署名が正当であることを確認する検証を行うことができるデバイスディレクトリ６０にホログラム（及びハッシュ）を送信する。
・ホログラムに格納されたバイナリ情報の解析／拡張を行って、サードパーティサービスが理解しやすいものにする。
・デバイスが正当である／特定のアサーションを含む既知のライフサイクルを有することをサードパーティサービスに通知する。
・アサーションに使用されていたデバイスの記憶領域を回復する。
・アプリケーションのライフの期間中に使用されるべき新しいデバイスＩＤと秘密鍵を生成する。
・元のデバイスキー及びアイデンティティを破棄する。

提案されたフローには、デバイスと、デバイスの管理を行うサードパーティサービスと、デバイスディレクトリ６０とが含まれる。他の同等のフローもある。
・デバイスは、全てのホログラムを含むメッセージを生成することによってフローを開始し、デバイスＩＤと共にハッシュを行い、デバイス秘密キーを用いてこのメッセージの署名を行う。
●必要に応じて、様々な周知のスキームにより、このデータの暗号化を行うこともできる。
●メッセージには、「新しい」ことを記すタイムスタンプや他のメタデータを含むこともできる。
●メッセージには、新しく生成された公開「移送」キー（Ｔ）を含むこともできる。
・このメッセージは、デバイスディレクトリ６０に直接又は（より可能性が高いのは）サードパーティサービスを介して送られる。
・一実装例においては、デバイスディレクトリ６０は、以下の検証を行う。
●署名がこのデバイスＩＤについて格納された公開キーに一致するかどうか
●ホログラム署名が全て正しいかどうか（並びに、適切なキーで生成されたかどうか）
・その後、デバイスディレクトリ６０は、証明書の詳細を含むレポートを生成する。
●これは、バイナリ形式又は解析／拡張形式であってもよい。
●レポートには、ホログラムの使用に関する情報も含まれてもよい（以下参照）。
・レポートは、サードパーティサービスに送られる。
・サードパーティサービスは、このデバイスが使用したいデバイスであるかどうかを検証することができる。
・そして、サードパーティサービスは、それを将来、識別するために、デバイスに送りたいキー／アイデンティティ／他のメッセージを生成することができる。
・その後、サードパーティサービスは、移送キー（Ｔ）を用いてこのデータを暗号化してデバイスに送信する。
・デバイスは、このメッセージを受信して復号に成功すると、
●このサービスに関連する新しいＩＤ／キー／データを格納し、
●任意選択で、ホログラム及び／又はデバイスＩＤ及び／又はデバイス秘密キーを削除し、
●誕生前のイベントと類似した方法でデバイスディレクトリ６０によって記録され後に証明が行われるメンテナンスなどのさらなるライフサイクルイベントを可能にするために、デバイスＩＤ／キーを保持してもよいことを表示する。

なお、デバイスディレクトリ６０は、サードパーティ固有のデバイスＩＤ／キー／他のデータを知ることはない。

以上はほんの一実装例であって、他の実装例も可能である。

「誕生」段階の間、デバイスディレクトリ６０は、それが目にするそれぞれ固有のホログラムの計数を取り続け、この利用数をサードパーティサービスに報告することができる。例えば、特定の証明書についての各ホログラムが、合意上、１００個のデバイスにしか使用してはいけない場合に、ホログラムの１０００のインスタンスが見られるならば、不正行為が行われたことを示している。これだけではどのデバイスが不正でどのデバイスが正当かを検出するには十分ではないが、有用な指標を与え、外部行為を行うこと（例えば、工場の監査）が可能になる。

ホログラムは、それぞれのバッチが異なるホログラムＩＤを有することで又は他の手段で区別される、バッチ単位での工場／製造ラインへの発表が可能である。バッチの盗難があったことが後に発覚した場合、デバイスディレクトリ６０は、その通知を受けてそのホログラムの取り消しを行うことができるが、盗まれたバッチを記録し、このバッチからのデバイスが「誕生」しないようにする。

図９は、誕生段階で電子デバイス２、サービスプロバイダ５０、及び検証装置６０によって行われる処理の例を示す。図９は、電子デバイス２とサービスプロバイダ５０の間で直接行われる通信を示すが、電子デバイス２は、仲介として機能するエージェントデバイス（例えば、コンピュータ、ノートパソコン、タブレット、もしくはスマートフォン）を介してサービスプロバイダ５０と通信を行うこともできる。これは、例えば、電子デバイス２の通信機能が、誕生段階の時点ではまだ完全に機能していない（完全な通信機能の起動が、デバイス２がサービスの承認を受けたならば行われる行為の一部である場合がある）場合に、又は、デバイス２自体がそれ自身の通信機能を有していない場合（例えば、周辺機器）に有用となり得る。

ステップＳ１０では、電子デバイス２は、その記憶回路６から格納された証明書（ホログラム）の少なくとも一部を読み出す。所定のサービスプロバイダにアクセスするにはどの特定の証明書が必要かがわかって分かっている場合、デバイス２は格納された証明書の一部を読み出し、その後の要求で必要とされないことが分かっているその他を削除することができる。しかしながら、多くの場合、デバイスが全ての格納された証明書を読み出して、それらを全てその後の要求に含め、どのイベント証明書が特定のサービスに関連したものであるかの決定を検証装置６０に任せる方がより簡単であり得る。

格納された証明書のいずれかが条件付き証明書である場合、電子デバイス２は、ステップＳ１１で、関連する条件が満たされているかどうかを判定する。例えば、デバイス２は、必要なソフトウェアがまだ特定のメモリ領域にインストールされ、変更されていないかどうかを確認する（以下に述べる先進メモリホログラムを参照）ため、そのメモリ領域の内容に対するハッシュの結果が期待されるハッシュ値に一致するかどうかのチェックを行ってもよい。他の条件のチェックとしては、デバイスが所定の動作モード（例えば、安全モード）で動作しているかどうかが挙げられる。条件付き証明書に関連する条件が満たされていない場合、この方法はステップＳ１２で終了し、要求の送信は行われない。全ての条件付き証明書に対して条件が満たされている場合、この方法はステップＳ１３へと進む（他のアプローチでは、条件が満たされていない証明書の場合でも、方法はステップＳ１３へと進むが、条件が満たされていないイベント証明書はその後の要求から排除してもよく、それにより、そのイベント証明書がその特定のサービスに必要なイベント証明書ではない場合に、満たされていない条件付きイベント証明書によってはサービスへのアクセスは阻害されない）。

ステップＳ１３では、デバイス２は、デバイス２に格納されたイベント証明書の全て又は一部を特定する要求をサービスプロバイダ５０に送信する。この要求は、生成段階でデバイスに割り当てられたデバイスキーを用いて署名されている。この要求は、サービスプロバイダ５０によって検証装置６０に転送される。ステップＳ１４では、検証装置６０は、その要求がサービスにアクセスするための要件を満たしているかどうかを判定する検証プロセスを実行する。この検証プロセスについては、図１０を参照してさらに詳細に以下で説明する。ステップＳ１５では、検証装置６０は、証明書の検証が成功した（すなわち、ホログラムが偽造されたものではない）かどうかを示すメッセージをサービスプロバイダ５０に返す。サービスプロバイダ５０には、任意選択で、イベント証明書から得られた情報を要約したデバイスレポートも送信してもよい。検証装置６０及び／又はサービスプロバイダ５０は、証明書の検証が成功した場合、デバイス２に対してサービスへのアクセスを認めるかどうかを判定してもよい（例えば、イベント証明書が有効であるかだけでなく、他の判断基準が存在する場合もある）。デバイス２に対してサービスへのアクセスを認める場合、ステップＳ１６では、サービスプロバイダ５０がそのサービスへのアクセスを可能にする（例えば、そのデバイスを有効なデバイスとして登録したり、そのサービスと協働して使用するためにデバイスを準備する他の動作を実行したりする）。場合によっては、イベント証明書に基づいた検証に加えて、サービスプロバイダ５０は、デバイスに対してサービスへのアクセスを認める前に他のチェック（例えば、ユーザ識別子、パスワードなどを用いたデバイスのユーザの認証）も行ってもよい。デバイス２が承認された場合、ステップＳ１７で、サービスプロバイダ５０は、デバイスに格納すべきサービス固有の情報（例えば、サービスにアクセスするためにデバイスにより使用される、デバイス識別子、キー、またはデータ）をデバイスに提供する。ステップＳ１８では、電子デバイス２は、デバイスの記憶部６に格納された一つ以上の（又は全ての）イベント証明書、誕生段階でサービスプロバイダ５０と交換したメッセージの暗号化に使用された検証キー、及び／又は、誕生段階でデバイスの識別に使用されたデバイス識別子を削除する。ステップＳ１９では、電子デバイス２は、ステップＳ１７で受信した（又はデバイス２自体に生成された）新しいサービス固有のキー、識別子又はデータを、その後のサービスへのアクセスするときに使用するために格納する。こうして、デバイス２はサービスにアクセスする準備が整う。

図１０は、イベント証明書に基づいてデバイス要求４０を検証するために、検証装置６０及び／又はサービスプロバイダ装置５０によって実行され得るステップを示すフロー図である。例えば、図１０のステップは、図９のステップＳ１４で実行されてもよい。検証装置６０やサービスプロバイダ装置５０でどの特定のステップを実行するかは、実装上の選択である。

ステップＳ１００で、検証装置６０又はサービスプロバイダ装置５０は、電子デバイス２から受信したイベント証明書のうちの一つについて、要求に関連するデバイス署名が電子デバイス２の既知の公開キーと一致するかどうかを判定する。例えば、この公開キーは、証明機関から取得してもよいし、そのデバイスのデバイス証明書と関連付けられていてもよい。このデバイス署名が一致しない場合、ステップ１０２で証明書が無効であると判断される。

ステップＳ１０４では、検証装置６０又はサービスプロバイダ装置５０は、イベント証明書のフォーマットが有効であるかどうかを判定し、そうでない場合は、ステップＳ１０２で証明書が無効であると判断される。ステップＳ１０６では、検証装置６０又はサービスプロバイダ装置５０は、電子デバイスに対して対応するイベントを実行することを許可された製造業者又は改作者のいずれか一つの公開キーを用いてイベント証明書の署名の検証を行えるかどうかをチェックする。イベントによっては、そのイベントを行える製造業者又は改作者は一つしか存在しない場合もある。しかしながら、所定のイベントに対して複数の許可された製造業者／改作者が存在するので、署名の検証は、異なる製造業者／改作者に関連付けられた２つ以上のキーを用いて行われてもよい。許可された製造業者／改作者のいずれのキーを用いてもイベント証明書の署名が検証できなかった場合は、再び、ステップＳ１０２で証明書が無効であると判断される。実際には、全ての可能なキーを用いて検証を試みることを回避するため、イベント証明書には、証明書の検証に使用すべき製造業者キーを特定するキー特定情報が含まれていてもよい。

ステップＳ１０８では、検証装置６０又はサービスプロバイダ装置５０は、イベント証明書が、もはや承認できない取り消された証明書の取消リストに入っているかどうか判定を行う。イベント証明書は、例えば、キーが漏洩していたり、証明書の生成に使用された署名アルゴリズムがもはや安全ではないと見なさたりなど、多くの理由で取り消され得る（よって、有効な製造プロセスを経た不正ではないデバイスでも、サービスにアクセスしようとした時に、それが制御範囲外の理由によりイベント証明書が取り消されていたために、エラーを受信する場合がある）。イベント証明書がこの取消リストに入っている場合は、再び、ステップＳ１０２でイベント証明書が無効であると判断される。

ステップＳ１１０では、検証装置６０又はサービスプロバイダ装置５０は、そのイベント証明書の利用数、すなわち、以前の検証で特定のイベントに関連付けられたイベント証明書がどれだけの電子デバイスによって使用されたかを判定する。場合によっては、検証装置６０又はサービスプロバイダ装置５０は、利用回数が一定の閾値以上であるかどうかチェックし、利用数がその閾値以上である場合にイベント証明書を無効として拒絶してもよい。例えば、最大数を製造業者データベース６２に記憶してもよいし、電子デバイスによって与えられた際にイベント証明書自体から抽出してもよい。イベントＸについての証明書をすでに使用したデバイスの数を追跡するために、カウンタが検証装置６０又はサービスプロバイダ装置５０によって保持されてもよい。最大数は、例えば、その特定のイベント証明書を伴って製造されたデバイスのバッチにおけるデバイス数に対応してもよい。このデバイス数以上が同じイベント証明書を使用していることを検出される場合、不正行為を特定することができ、その証明書は取消リストに加えられてもよい。他の例では、イベント証明書の有効性は利用数に依存していなくてもよく、代わりに、検証装置６０又はサービスプロバイダ装置５０によってその利用数をデバイスレポートに単に含めて、利用数が無効な利用を示しているかどうかの判断を他者が行えるようにしてもよい。

ステップＳ１１２では、検証装置６０又はサービスプロバイダ装置５０は、イベント証明書の内容を解析し、イベント証明書から他の情報（例えば、発生したイベントやそれを行った製造業者の情報など）を抽出する。ステップＳ１１４では、検証装置６０又はサービスプロバイダ装置５０は、イベント証明書が有効または無効と見なされたかを示し、そのイベント証明書に基づいて解析された他の情報を示すために、電子デバイス２のためのデバイスレポートを更新する。このデバイスレポートには、それぞれが、電子デバイスから送信され、検証装置６０又はサービスプロバイダ装置５０によって検証されたイベント証明書の一つに対応する多くのエントリが含まれてもよい。ステップＳ１１６では、検証装置６０又はサービスプロバイダ装置５０は、まだ処理されていないイベント証明書が残っているかどうかをチェックし、もしそうである場合、この方法はステップ１００に戻って次のイベント証明書の検証を行う。全てのイベント証明書が処理された場合、デバイスレポートがステップ１１８でサービスプロバイダ５０に返される。

ステップＳ１２０では、サービスプロバイダは、このデバイスレポートを用いて、デバイスレポートにおいて有効なイベント証明書が特定されたイベントのリストに基づき、デバイスに対してサービスへのアクセスを認めるのに必要な特定の要件をデバイスが満たしているかどうかを判定する。場合によっては、サービスプロバイダは、２つ以上の二者択一のイベント群（例えば、イベントＡ、Ｂ、Ｃ、又はイベントＤ、Ｅ、Ｆ、…）を有効である（例えば、２つの異なる製造連鎖を示す）として受け付ける場合もある。従って、サービスプロバイダによって適用されたテストには、有効なイベントのリストを簡単なリスト、正規表現、又は、より複雑な一致条件と比較することが含まれてもよい。

図１０では図示されていないが、幾つかの実施例では、検証装置又はサービスプロバイダは、イベント証明書を最初に信頼すべきかどうかを確認するために、デバイス証明を（例えば、デバイス公開キーを用いてデバイス署名を照合することにより）行う。例えば、イベント証明書を与える検証要求は、製造時にデバイスに投入されるデバイス秘密キーによってまとめて署名が行われてもよく、デバイスキーは、デバイス証明書に関連付けられた公開キーを用いて照合されてもよい。デバイス証明書を検証することができたら、検証装置又はサービスプロバイダは、検証要求に含まれるイベント証明書の検証を継続して行ってもよい。

所定の実施例については、図１０の検証ステップの全てを実行する必要はないことは理解されよう。例えば、実装例によっては、所定の証明書に対して最大デバイス数が設定されていなかったり、取消リストが設けられていなかったりする。また、ステップは、図１０に示される順番とは異なる順番で実行されてもよく、その一部のチェックを並行して行ってもよい。また、例えば、以下に述べるように電子デバイスに対してイベントを行う順番をチェックしたり、以下に述べるようにデバイスによって与えられた監査ログを用いて不審なイベントのタイミングがあるかどうかをチェックしたりといった、さらなる検証ステップを設けてもよい。図１０は、イベント証明書を用いた可能な検証プロセスのほんの一例にすぎないことは理解されよう。

図９及び図１０の例では、イベント証明書自体が、検証要求とともに、デバイス２から検証装置６０又はサービスプロバイダ５０に送信される。しかしながら、これは必須ではない。例えば、他の実装例としては、破棄される署名に対して、検証サーバー６０の代わりにデバイス２によってインストール時にホログラムの検証を行い、その後、誕生時において、デバイス２がイベント証明書群（それぞれ、対応する製造業者／改作者キーで署名済み）を前もって受信し、それらのイベント証明書がデバイスにおいて正しく検証されたことを証明する一つの暗号により認証された証明書（デバイスの公開キーで署名済み）を送信することによって、サーバーに対して証明を行う。つまり、デバイスは、所定のホログラム群（Ｈ１、Ｈ２、Ｈ３）を受信したことを検証装置に証明してもよい。

別の選択としては、要求Ｓ１３により送られた証明書情報は、デバイス２が正しいデバイスであることを証明するが、そのデバイスについて発生した有効なイベント群を明示的には特定しない。例えば、デバイスは初めに「私は次にＨ１かＨ２を期待する」を把握していてもよく、Ｈ１を入手すると、Ｈ１には次は「Ｈ３又はＨ５」の情報などが含まれる。従って、各ホログラムは、次の段階ではどのホログラムが有効であるかに関する情報を特定することができ、デバイスは、次にインストールされたホログラムが正しいかどうかを検証することができる。ここまでの全てのホログラムが期待された連鎖に従うならば、デバイスは、有効な製造連鎖を経たことの（「私は良いデバイスである」ということを証明する）証明書（デバイスキーで署名済み）を特定する検証装置６０又はサービスプロバイダ５０に検証要求Ｓ１３を送信してもよい。どの段階においても、デバイスはどの許容可能な行為が次に来るかしか把握していないが、有効な連鎖を経た／経ていないことをサーバーに証明することができる。

再生
デバイスを再利用し、それらの過去の一部／全ての側面（例えば、前の所有者は誰だったか）を忘れさせる必要がある場合がある。これを行うために、サードパーティサービスは以下を実行する。
・「改作段階」に関する処理を行うために、保持されるべき情報（例えば、このデバイスは良い）を含むホログラムを生成してデバイスに送信する。（このメッセージは、通常、「誕生」段階で提供されたキーを用いて保護されている）。
・全てのアプリケーションレベルのデータ／キーを破棄するようデバイスを構成する。
・デバイスは、ここで、再生ホログラムに記録されたものを除き、その過去のライフに関する事前の知識なしに再び「誕生」できる状態となる。
・なお、再生段階の間は、デバイスは、デバイスディレクトリ６０にエントリを有していないので、デバイスディレクトリ６０に送られたメッセージには署名がされていない。このメッセージは、他の手段、例えば、デバイスディレクトリの公開キーを用いた暗号化によって保護されなければならない。再生メッセージのリプレイを防止するには、通常、再生ホログラムは一回の使用に制限され、デバイスディレクトリ６０は過去に見た全てのホログラムのリストを保持する。

図１１は、再生段階においてサービスプロバイダ５０とデバイス２との間で実行される処理の例を示す。ステップＳ３０では、サービスプロバイダ５０は、デバイスが特定のイベントを経験したことを証明する少なくとも一つの再生証明書を生成する。例えば、再生証明書は、デバイスが過去にその特定のサービスの要件を満たすものとして認められたこと（上述のように、過去にデバイスの検証に用いられたイベント証明書はもう削除された可能性があるので、再生証明書は各イベントを個別に証明することができない場合がある）を証明してもよい。ステップＳ３１では、サービスプロバイダ５０は、再生証明書を含む再生要求をデバイス２に送信する。再生要求は、サービスプロバイダに関連付けられた暗号（対称又は秘密）キーにより署名されている。ステップＳ３２では、デバイス２は、対応するサービスプロバイダキー（対称又は秘密）を用いてサービスプロバイダの署名を検証する。この署名検証に成功した場合、デバイス２は、ステップＳ３３で、デバイスの以前のライフにおけるサービスへのアクセスに関連するサービス固有のキー、識別子、データを破棄し、ステップＳ３４で、デバイスは再生証明書を格納する。図１１では図示されていないが、再生段階は、その後の誕生段階でデバイスが自身を特定できるようにするために、サービスプロバイダが、生成段階で与えられたデバイス識別子及びキーと同様の新しい一時的なアイデンティティ（識別子及びデバイスキー）をデバイスに与えることも含んでよい。こうして、デバイスは別の発生段階を経て、サービスへの再登録が行えるようになる。

先進「メモリ」ホログラム
上述の基本的なホログラムスキームは、デバイスが何らかの改作イベントを通過したことを示す。

ホログラムの２つ目の形式を用いて、特定のソフトウェアがデバイスにインストールされたことを示すことができる。

このホログラムは、１つ目の拡張である。ここで、アサーションは、
［差別化因子］［メモリスタートアドレス］［長さ］［期待されたハッシュコード］
の形を有するが、ここで、
●差別化因子
これは、このホログラムが「メモリ」タイプのものであることを示すマーカーである。あるいは、マーカーは特別なホログラムＩＤによって示されてもよい。
●メモリスタートアドレス／長さ
これは、メモリの領域を示す。
●期待されたハッシュコード
これは、特定の位置におけるメモリのハッシュの期待値を示す。

「誕生」段階の間にこのホログラムを処理する場合、デバイス自体は、サーバーに接触する前に、まず、メモリ範囲の表示が正しいソフトウェアを含む（すなわち、期待されたハッシュコードと一致する）かどうかを確認する。この場合、デバイスは、ソフトウェアが正しいことを証明している。

連結ホログラム
上述の技術の任意選択の拡張を以下の文章に説明する。様々な製造工程において証明書（ホログラム）を電子デバイス２に投入する際、ホログラムをまとめて暗号化により連鎖させてもよい。これは、後に、デバイスがＯＤＭ製造時に通った正確なパスを評価し、拒絶または承認され得ることを意味している。暗号化による連結は、インポートされたホログラム間で行われてもよく、これに対して後に証明や検証を行うことができる。

さらに、アサーション間の連結は、いわば公の記録に挿入することができ、これによりこの結合全体をブロック連鎖と見なすことができる。これは、デバイスが最初から最後のステップまでに通ったまさにそのルートを認証者が証明できることを意味している。これにより、供給連鎖内における課題や他の問題を見つけ出すことに役立てることができる。従ってさらに、ホログラムを暗号化により結合し、この事実を証明する公の台帳を生成する。これは、デバイスが製造時に通ったまさにそのパスが証明されることも意味している。

一実施例では、デバイスに対して行われた後のイベントに対応する後のホログラムに対してハッシュＨ_Ｎが生成されると、前にインストールされたホログラムのハッシュＨ_Ｎ－１も含まれる。最初のホログラムについては、使用するそれ以前のハッシュがないので、ハッシュにはそれより前のハッシュが含まれない。こうすることにより、ホログラムの暗号的連鎖が形成される（そしてそれらの順序もここで明確になる）。

誕生段階では、電子デバイス２は、以下の情報を検証サーバー６０に返してもよい。
●署名（ハッシュ１｜ハッシュ２｜…｜ハッシュｎ｜ノンスサーバー）、すなわち、全てのハッシュ＋ノンス（鮮度指標）の署名（または、全てのハッシュを送信するのではなく、ハッシュ１、ハッシュ２、…、ハッシュｎの更なるハッシュを生成してもよく、サーバーへ送られるデータ量を軽減するよう、この一つの更なるハッシュを全ての個別ハッシュの代わりに送信してもよい）
●ホログラム１～ｎ
●ハッシュ１～ｎ
●デバイスＩＤ

サーバー６０は、登録すべき電子デバイス２との通信が行われる際にノンスを伝えて、登録が過去の返答ではなく新しいものであり、このノンスが、ＩｏＴデバイスによって署名付きの応答として返される（このようなノンスは上記の例でも利用可能である）ことを保証するようにする。

検証サーバー６０は、返された情報の「ブロッブ（blob）」をチェックして、以下の判定を行う。
ａ）このＩｏＴは一体存在するのか？（このＩｏＴデバイスからのレシートに対して照合が可能なデバイスＩＤを使用）（この時点でも通過したのか、あらかじめ工場２０からサーバー６０へ帯域外で伝えられたのか）
ｂ）その返送された情報のブロッブは新鮮か（返送されたブロッブにおけるノンスを、最初にサーバー６０からデバイス２へ送られたノンスと比較することによって）？
ｃ）そのインテグリティが有効か？移動中に変更されたか？（署名を検証することによって）

サーバー６０が全てのホログラム（及び他のデータ）を受信すると、（上述のイベント連鎖のため）それらが正しい順序に並んでいることをチェックして確認し、各ホログラムに対して、（どんなポリシーであろうとそれに従って）それぞれにおけるアサーションが読取可能かどうかチェックする。これは、不正ＯＤＭがホログラムをＩｏＴデバイスに挿入しようとする場合に、サーバーがこれをアサーションとして検出し、その署名を行うキーが予想するものとは一致しないことを意味している。

イベント証明書の連鎖が有効であるかどうかを判断するため、検証サーバー６０は、以下の一つまたは複数を定義するデータへのアクセスを有していてもよい（もしくは、これは範囲外であり、代わりにＯＥＭサーバーによって処理されてもよい）。
●どのホログラムサーバーが存在し、それらの公開キー及びアサーション。
●電子デバイス２がその最初のステップから誕生までに正当に通る可能性のあるパス。ホログラムが連結される可能性のあるパスがここでは要求され、サーバーはこれを把握すべきである（又は、複数のパスが許容される場合にデバイス２が通る可能性のあるパス）、もしくは、デバイスがどのパスを通るかは関係ない特定のサービス／アプリケーションについては、サーバーはこの追加のチェックを無視することができる。
●証明書を提供するパーティのアイデンティティを確認するための各製造業者／改作者／工場の公開キーや同等の暗号キー。従って、ＩｏＴデバイスのレシートが提示された場合、その証明者の公開キーがあらかじめ知られているかどうかしか確認できない（そのレシートを信頼することはできない）。

デバイスがその生成時に通る可能性のあるパスは、以下のように見なされてもよい。

つまり、ＩｏＴデバイスはＳｉＰからＯＥＭまで複数のパスを通ることができる。
・ＳｉＰ－＞ＯＤＭ１－＞ＯＤＭＸ－＞ＯＥＭ
・ＳｉＰ－＞ＯＤＭ２－＞ＯＤＭＹ－＞ＯＥＭ
・ＳｉＰ－＞ＯＤＭ１－＞ＯＤＭＹ－＞ＯＥＭ
・ＳｉＰ－＞ＯＤＭ２－＞ＯＤＭＸ－＞ＯＥＭ

一方、ＳｉＰ－＞ＯＤＭ１－＞ＯＤＭ２－＞ＯＥＭは不正ルートであり、上記ポリシー（グラフ）では許されていない。

さらに、ＯＤＭの経路変更の問題については、電子デバイス２が様々な製造段階を通る場合、各工場は、関連するホログラムを対象となる電子デバイス２に投入するためにホログラムサーバーを使用することができる。各ホログラムでは、所定の工場（又は段階）、例えば、「スオミ工場＃３－ＱＡ合格」を特定するといえるアサーションが存在する。ＩｏＴデバイスが様々な工場段階を通過する際に各ホログラムがその他と連鎖される方法のおかげで、登録サーバーは（または、どの将来の時点でも）、デバイスが誕生までに通ったステップを、それらが有効であったことを確実にするように有効にすることができる。

つまり、ＩｏＴデバイスが通過する工場がＳｉＰ－＞ＯＤＭＡ－＞ＯＤＭＢ－＞ＯＤＭＤ－＞ＯＥＭであり、ＯＤＭＢはブラックリストに載っているものであったならば、ホログラムを検証しようとするときに、それが登録サーバーによって検出され、そういうものとしてこの電子デバイスをブラックリストに載せて、承認されないようにする。また、その製造業者ＯＤＭＢが「不正」なだけではなく、それは完全に未知であるため、ホログラムの連鎖では許されざるべきである場合もある。同様に、予想されたホログラムが所望のパスからなくなっている、すなわち、上記例の場合、ＳｉＰがＯＥＭに直接結合しているならば、デバイスが、ＩｏＴデバイス製造（ＯＥＭ）によってそう概説したように製造時に必要なＯＤＭのステップを通らなかったはずなので、これも問題の兆候である。

要約すれば、電子デバイスのライフサイクル中の後のイベントの発生を証明するイベント証明書には、電子デバイスのライフサイクル中で当該後のイベントよりも前に発生したはずの少なくとも一つの前のイベントの発生を証明する少なくとも一つのイベント証明書からの情報に依存するイベント連鎖情報が含まれていてもよい。例えば、そのイベント連鎖情報は、少なくとも一つの前のイベント証明書についての対応するハッシュ値に依存するハッシュ値であってもよい。検証装置は、受信したイベント証明書に関するイベント連鎖情報が、禁止された順番でイベントが発生したことを示している場合に、その電子デバイスに対して予め定められた行為が行われないようにしてもよい。

タイムスタンプ付きホログラム
上記技術のさらなる拡張について以下に説明する。これは、上記連結ホログラムの拡張と共に実行可能であり、あるいは、連結ホログラムの拡張が利用されていなくても適用可能である。様々な製造工程において電子デバイスにホログラムを投入する場合、電子デバイスにおいて発生する一つまたは複数のローカルイベントの発生時刻を示す監査ログが電子デバイスによって記録されてもよい。検証装置は、検証時に、その監査ログに基づいて、予め定められた行為が許可されているかどうかを（イベント証明書自体に基づく検証に加えて）判定してもよい。この監査ログに記録されたローカルイベントは、イベント証明書のインストールや使用、又は製造連鎖の過程でのデバイスの取り扱いに関連する重要なイベントであってもよい。例えば、各ホログラムがデバイスに挿入された同期時刻を監査ログに記録してもよい。さらに、すべてのブート処理の記録と（任意選択で）呼び出された関数（function）も今後のＯＤＭ不正検出のために記録される。接続されたハードウェア周辺機器のマップも監視してもよい。検証装置は、特定のイベント証明書に関連するデバイスのバッチが処理されたときを示す情報にアクセスを有してもよく、それは、予め定められた行為を許可するかどうかを判定するために監査ログと比較することができる。

そのような監査ログを利用することによって、デバイスがその生成中に不正な製造業者／改作者を訪れたが、その不正な製造業者／改作者によってホログラムのインストールや変更は行われなかった場合を検証装置によって検出できる可能性が高くなる。つまり、ＳｉＰ－＞ＯＤＭＡ－＞ＯＤＭＢ－＞ＯＤＭＤ－＞ＯＥＭが合法であると仮定する。しかしながら、デバイスがＯＤＭＡとＯＤＭＢとの間の移動中に傍受され、他のパーティＯＤＭＸへ持って行かれたならば、予想されるホログラムが全て存在することから、エンドデバイスはそれでも検証を行う。

したがって、デバイスの「誕生」時（又は他の任意の関心時）に、デバイスがＳｉＰからＯＥＭまで想定された正しいパスをたどったかどうか、かつ、そのような主張を無効にする可能性のある迂回が行われなかったかを分析する手段が提供される。つまり、全ての関連するホログラムが検証され所定の位置にあることに加えて、システムに提供された追加記録を用いてデバイスの分析を行い、それが正しく製造されたことを確認することができる。

呼び出された関連する関数、もしくは関心のあるフローのインストール時刻と（デバイス誕生までの）保護された記録を追加することにより、可能な限り高いレベルの保証が可能となる。デバイスは、安全な世界（保護された実行環境）を有し、ブート処理後は常にその安全な世界で起動され得る。これは、この安全な世界は変更できないため、記録の改ざんや変更が不可能であることを意味している。また、接続された周辺機器のハードウェア識別子が監査ログに記録された場合、改ざんも検出される可能性がある。

デバイスの「誕生」後は、監査ログ機能を破棄（デバイスのサービスへのアクセスが可能となった後にその誕生段階で用いられたイベント証明書やキー／識別子を破棄するのと同様）してもよいし、終了させてもよく、すなわち、不正ＯＤＭの検出のためだけに機能し、常にアクティブであると考える必要はない。

工場のプロセスの各ステップの間、ホログラムがデバイス２に挿入されると、正確な時刻（簡略化のため同期したＵＴＣ）が、そのホログラムインストールに対応するタイムスタンプとしてＩｏＴデバイスにも書き込まれてもよい。これにより、あとで全てのホログラムの検証が行われるときに分析可能なタイムラインがＩｏＴデバイス２に与えられる。タイムラインは、いつ、すべてのホログラムがデバイスに投入されたかを示す。これはホログラムを投入するホログラムサーバーによって、又は、デバイス自体（もしくはその両方）によって実現可能である。ホログラムサーバーかデバイスのいずれがその時刻を記録するかは、ホログラムサーバー又はデバイスから得られるまさにその信頼によって決めればよい。両方を一緒に利用する（ホログラムサーバーとデバイスの両方で時刻を記録する）ことにより、セキュリティを向上させる妥協案を提供することができる。

これに加えて、ＩｏＴデバイスが（「誕生」するまで）ブート処理を行うたびに、ソフトウェアは常に安全な世界でスタートするため、ＩｏＴデバイスは、これらのスタートのレコードを追加の監査ログに記憶してもよい。この追加のファイルは、（安全な記憶部に格納されているにもかかわらず）一定のレコード数（例えば、ＦＩＦＯ方式又は実行可能ないかなる方法で上書きできる最後の１００回分のブートサイクル）に大きさが限られている場合がある。また、監査ログには、実行されてきた関連する関数に対するカウンタも含まれていてもよい。例えば、最後の３４５回分全てのブートサイクルを記憶するのではなく、３４５と示すカウンタを記憶し、最後の１００回分のブートサイクルが残っているものすべてとし、これにより、（記憶容量が「無制限」にある場合を除き）スペースが節約される。まさに何をどれだけ記憶するかは、実装によって異なってもよい。

電子デバイス２上の固有のハードウェアによってサポートされている場合、デバイス２は、他の関連する情報（安全な世界のどの関数が呼び出されたかなど）と共に、各スタートについてのタイムスタンプも書き込むことができる。ＩｏＴデバイスに［予備］バッテリーがない場合、又は、あっても信頼できない場合は、単調カウンタを用いてブート処理に対する厳密な命令を行ってもよいが、必ずしも実際の時刻と一致するわけではない。このカウンタは、任意選択で、ＯＴＰメモリや他の利用可能なハードウェアによって支持されてもよい。従って、記録された時刻が絶対（同期時刻）である必要はない。

この監査ログの目的は、ＩｏＴデバイスが正当な製品となるまでに通る過程の検証を支援することである。工場でのホログラムの投入から離れたブートサイクルは、不審なアクティビティを示唆することができ、ＩｏＴデバイスが実際の製品となるまでに複数の反復処理が行われたことを示す場合もある。これにより、ＩｏＴデバイスが良好な共通のフローをたどったものなのか、不正な何かが発生したのかを判定するのに有用となる。

さらに、この監査ログは、ＩｏＴデバイスが「誕生」するまでに使い切られ、その後、破棄されるか使われないままとなって、不正ＯＤＭアクティビティの判定のために把握するのに関連するのは最初のステップだけで、エンドユーザによって使用されるようになる後のものではないという考えである。または、一方で、この機能は、問題が発生した場合のデバッグやアシストとしても利用されてもよく、ＩｏＴデバイスを利用するエンドユーザによる不正利用の摘発に利用されてもよい。

この概念によって軽減しようとする脅威モデルとしては、デバイスが「通常」の工場のフローの外部によって手を加えられることである。ここでの仮定は、ハードウェアコンポーネントが挿入されたり変更が加えられたりすると、デバイスは、元の［意図された］フローを再開する前に、正しく機能することを確実にするため少なくともパワーサイクルされると仮定するのが妥当であるということである。もちろん、これは厳密に必要とされるわけではないが、この概念は、そのときだけは、デバイスが正当（？）なデバイスになるまでに行ったサイクルをよりよく説明するのに役立つであろう。

例えば、デバイスのバッチが以下のように生成されたとする。

つまり、最初のホログラムは、１３時１３分１３秒に遭遇され、最後に見たのは１４時１３分１２秒であった（すなわち、ホログラムＩＤは０ｘＦ００ＢＡ）。同じ論理が上記の続いて示されるホログラムにも当てはまる。ここでは、そのバッチのフローを示し、１４時１３分１２秒の後は別のデバイスのバッチが異なるホログラムＩＤで生成された。

ここで、このデバイスに予想される連鎖としては、ホログラム１がホログラム２の前に来て、両者が（任意選択で、前述の拡張と同様に連結されて）それに応じて検証される。また、ホログラムＩＤは、不正についてチェックされ、ホログラムアサーションの検証も行われる（上記の通り）。

次に、デバイス２が持っている監査ログが（ホログラムに加えて）以下の監査ログを示したとする（これは極めて単純化した例であることが理解されよう）。

幾つかのことが推論される。
１．ｉｍｐｏｒｔＨｏｌｏｇｒａｍ（）関数が１月６日の２０時００分に呼び出され、供給されたホログラムのインポートに失敗した（Ｈ１が意図されたパラメータと一致しなかったため）。これは、上述のとおり、このデバイスでは、ホログラム１とホログラム２の間ではホログラムをインポートすべきではなく、これが不審であることから、何かがおかしいことを示す。
２．１月９日の１０時１０分に、デバイスのブート処理が行われ、他の特定の安全な世界の関数は何も呼び出されなかった。しかしながら、上記ホログラム表にも見られるように、１月１０日の０１時２３分に３番目のホログラムのインポート（最初に見られた）に成功した。よって、この場合、デバイスはなぜブート処理を行ったのか？それは型どおりのチェックだったのか、デバイスはその時点で３番目のＯＤＭへのルート上にあるべきなので、これはつまりは、行われるべきではなかった不正ブートだったのか、その後ブート処理は行われ（るべきでは）なかったのか？従って、これはさらに調査が必要なものとなる可能性が高い不審な挙動を示し得る。監査ログにもっと多くの関数が記録されていたなら、デバイスがなぜブート処理を行ったのか、ブート処理後に何を行ったのかを説明できた可能性がある。
３．また、（そのようにサポートされた場合）ソフトウェアは、接続された周辺機器、バスマスターなどを全て追跡することができ、型どおりのチェック中に新しいものが（最後のチェックから）変更されたことが分かった場合、監査ログへのエントリが書き込まれていたであろう。これは許容可能な挙動である可能性もあるし、正当な部分を別のものへと不正に置換することを示唆している可能性もある（デバイスがもはや正当なものではないことを示している場合もある）。もちろん、これは取り替えられた部分が元のものとは異なるＩＤを有していると仮定した場合である。

登録時に検証装置６０によって全てのデバイスのチェックを行うことは必須ではない（監査ログのチェックはホログラムの検証よりも計算コストが高くつく場合がある）。従って、場合によっては、その分析を行うより強い必要性がない限り、検証サーバー６０によって、さらなる分析を行う一部のデバイスを選択し、大部分のデバイスについてはスキップしてもよい（けれども、一斉に許容できない登録には時間が加算される可能性が最も高い）。

本願において、「するよう構成された」という表現は、装置の構成要素が規定の動作を実行可能な構成を有することを意味するものとして用いられる。ここで、「構成」とは、ハードウェアやソフトウェアの配置やそれらを相互に接続する方法を指す。例えば、装置は、規定された動作を提供するための専用ハードウェアを備えていたり、その機能を果たすようプログラムされたプロセッサやその他の処理装置であってもよい。「するよう構成された」は、装置の構成要素が、規定された動作を提供するために何らかの変更を加える必要があるということを意味するものではない。

添付の図面を参照して本発明の例示的な実施例を本明細書に詳細に説明してきたが、本発明はこのような明確な実施形態に限定されるものではなく、添付の特許請求の範囲により規定された本発明の範囲や精神から逸脱することなく、当業者によって様々な変更や改良を行えることを理解されたい。

Claims (34)

1. 電子デバイスの検証方法であって、
   前記電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが提供する複数のイベント証明書を前記電子デバイスが受信したことを証明する、前記電子デバイスによって与えられた証明書情報を検証装置によって受信することと、
   前記証明書情報が有効であるかどうかを示す検証結果を前記検証装置によって判定することと、
   を具備する方法。
2. 前記証明書情報には前記複数のイベント証明書が含まれる、請求項１に記載の方法。
3. 前記証明書情報には、前記電子デバイスにより前記複数のイベント証明書が受信されたことを前記電子デバイスが確認したことを証明する少なくとも一つの暗号により認証された証明書が含まれる、請求項１に記載の方法。
4. 複数の異なる電子デバイスについての所与のイベントの発生を証明するために、同じイベント証明書が使用される、請求項１～３のいずれか一項に記載の方法。
5. 特定のイベント証明書を受信したことをすでに証明した他の電子デバイスの数を示す利用数を前記検証装置によって判定することと、
   前記利用数に依存して前記検証結果を前記検証装置によって判定することと、
   を具備する、請求項１～４のいずれか一項に記載の方法。
6. 少なくとも一つの取り消されたイベント証明書の記録を前記検証装置によって保持することと、
   前記証明書情報において証明された特定のイベント証明書が前記少なくとも一つの取り消されたイベント証明書であるかどうかに依存して前記検証結果を判定することと、
   を具備する、請求項１～５のいずれか一項に記載の方法。
7. 前記電子デバイスの前記ライフサイクル中の後のイベントの発生を証明するイベント証明書には、前記電子デバイスの前記ライフサイクル中の前記後のイベントよりも前に発生したはずの少なくとも一つの前のイベントの発生を証明するための少なくとも一つのイベント証明書からの情報に依存するイベント連鎖情報が含まれている、請求項１～６のいずれか一項に記載の方法。
8. 前記複数のイベント証明書についての前記イベント連鎖情報が、禁止された順番でイベントが発生したことを示しているかどうかに依存して前記検証結果を前記検証装置によって判定することを具備する、請求項７に記載の方法。
9. 前記電子デバイスで発生する一つ以上のローカルイベントの発生の時刻を示す監査ログを前記電子デバイスから前記検証装置によって受信することと、
   前記監査ログに依存して前記検証結果を前記検証装置によって判定することと、
   を具備する、請求項１～８のいずれか一項に記載の方法。
10. 前記一つ以上のローカルイベントには、
    前記電子デバイスへの所与のイベント証明書のインストール、
    前記電子デバイスによる所与のプログラムコード機能の呼び出し、
    前記電子デバイスのブート処理、及び
    前記電子デバイスの一つ以上の属性の更新
    のうちの少なくとも一つが含まれている、請求項９に記載の方法。
11. 前記監査ログの、所与のイベント証明書に関連付けられた電子デバイスのバッチが所与の製造業者によっていつ処理されたかを示す情報との比較に依存して前記検証結果を前記検証装置によって判定することを具備する、請求項９又は１０に記載の方法。
12. 対応する所要のイベントを前記電子デバイスについて実行させることが許可された製造業者又は改作者に関連付けられた暗号キーを用いて検証されたときに、所与のイベント証明書が有効であると判定される、請求項１～１１のいずれか一項に記載の方法。
13. 複数の電子デバイスについてのイベント証明書を検証するために同じ暗号化キーが使用される、請求１２に記載の方法。
14. 前記検証結果には、予め定められた行為が前記電子デバイスについて許可されているかどうかの判定が含まれている、請求項１～１３のいずれか一項に記載の方法。
15. 前記検証結果には、前記複数のイベント証明書から得られる情報を示すデバイスレポートが含まれている、請求項１～１４のいずれか一項に記載の方法。
16. 電子デバイスの検証を行う検証装置であって、
    前記電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが提供する複数のイベント証明書を前記電子デバイスが受信したことを証明する、前記電子デバイスによって与えられた証明書情報を受信する通信回路と、
    前記証明書情報が有効であるかどうかを示す検証結果を判定する処理回路と、
    を具備する装置。
17. 外部デバイスと通信を行う通信回路と、
    電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが含む複数のイベント証明書を前記電子デバイスが受信したことを証明する証明書情報を含む検証要求を検証装置に送信するために前記通信回路を制御する処理回路と、
    を具備する電子デバイス。
18. 前記証明書情報には前記複数のイベント証明書が含まれる、請求項１７に記載の電子デバイス。
19. 前記証明書情報には、前記電子デバイスにより前記複数のイベント証明書が受信されたことを前記電子デバイスが確認したことを証明する少なくとも一つの暗号により認証された証明書が含まれる、請求項１７に記載の電子デバイス。
20. 各イベント証明書が、前記イベント証明書の内容に適用される予め定められたハッシュ関数の結果に対応するハッシュ値と関連付けられている、請求項１７～１９のいずれか一項に記載の電子デバイス。
21. 前記電子デバイスに与えられた新しいイベント証明書に応答して、前記処理回路が、前記新しいイベント証明書の前記ハッシュ値と、前記新しいイベント証明書の前記内容に適用される前記予め定められたハッシュ関数の結果との間に不一致が検出されたときに、前記記憶回路内の前記新しいイベント証明書を拒絶するよう構成されている、請求項２０に記載の電子デバイス。
22. 前記処理回路が、前記新しいイベント証明書の検証が行われた後、前記新しいイベント証明書の前記内容のスタブ部を破棄するよう構成され、前記ハッシュ値が前記スタブ部に依存している、請求項２１に記載の電子デバイス。
23. 前記新しいイベント証明書が、前記ハッシュ値と、前記スタブ部を除く前記新しいイベント証明書の内容とから得られた署名に関連付けられ、
    前記証明書情報には、前記複数のイベント証明書に関連付けられた前記署名や、前記複数のイベント証明書に関連付けられた前記署名が検証されていることの表示が含まれている、請求項２２に記載の電子デバイス。
24. 前記署名が、前記電子デバイスの前記ライフサイクル中に前記電子デバイスに対応するイベントを実行させる製造業者又は改作者と関連付けられた暗号キーを用いて署名される、請求項２３に記載の電子デバイス。
25. 前記電子デバイスの前記ライフサイクル中の後のイベントの発生を証明するイベント証明書について、前記ハッシュ値が、前記電子デバイスの前記ライフサイクル中の前記後のイベントよりも前に発生したはずの少なくとも一つの前のイベントの発生を証明する少なくとも一つのイベント証明書からの情報に依存する、請求項２０～２４のいずれか一項に記載の電子デバイス。
26. 前記処理回路は、前記電子デバイスで発生する一つ以上のローカルイベントの発生の時刻を示す監査ログを保持するよう構成され、
    前記検証要求には、前記監査ログの少なくとも一部が含まれる、請求項１７～２５のいずれか一項に記載の電子デバイス。
27. 前記イベント証明書の一つには、前記電子デバイスによって予め定められた条件が満たされることを条件に前記デバイスの前記ライフサイクルにおける予め定められたイベントの発生を証明するための条件付きイベント証明書が含まれ、
    前記処理回路は、前記予め定められた条件が満たされているかどうかの検証を行い、前記予め定められた条件が満たされていないときは、前記条件付きイベント証明書が正当に受信されたことを証明する証明書情報の送信を妨げるよう構成されている、請求項１７～２６のいずれか一項に記載の電子デバイス。
28. 前記予め定められた条件には、特定のソフトウェアが前記記憶回路の予め定められた領域にインストールされていることが含まれる、請求項２７に記載の電子デバイス。
29. 前記検証要求には、前記電子デバイスを用いて予め定められたサービスにアクセスする要求が含まれる、請求項１７～２８のいずれか一項に記載の電子デバイス。
30. 前記予め定められたサービスへのアクセスが可能となったことに応答して、前記処理回路が、
    記憶回路からの前記複数のイベント証明書の削除、
    前記電子デバイスと前記検証装置との間の通信を保護するための少なくとも一つのデバイスキーの削除、
    前記検証装置に対して前記電子デバイスを識別するためのデバイス識別子の削除、
    前記電子デバイスと前記予め定められたサービスのサービスプロバイダとの間の通信を保護するための少なくとも一つのデバイスキーの格納、
    前記予め定められたサービスの前記サービスプロバイダに対して前記電子デバイスを識別するためのデバイス識別子の格納、
    のうちの少なくとも一つをトリガするよう構成されている、請求項２９に記載の電子デバイス。
31. 前記予め定められたサービスのサービスプロバイダから受信された再生要求を受信したことに応答して、前記処理回路が、前記予め定められたサービスへの前記アクセスが可能になってからの前記予め定められたサービスの使用から生じた情報を削除するよう構成されている、請求項２９又は３０に記載の電子デバイス。
32. 前記再生要求には、少なくとも一つのイベントの発生を証明する少なくとも一つの再生イベント証明書が含まれ、
    前記再生要求に応答して、前記処理回路が、その後の検証要求についての証明書情報を生成するために、前記少なくとも一つの再生イベント証明書を記憶回路に格納するよう構成されている、請求項３１に記載の電子デバイス。
33. 電子デバイスのための方法であって、
    前記電子デバイスのライフサイクル中のそれぞれのイベントの発生の、暗号により認証された証明書をそれぞれが含む複数のイベント証明書を前記電子デバイスが受信したことを証明する証明書情報を含む検証要求を前記電子デバイスによって生成することと、
    前記検証要求を前記電子デバイスによって検証装置に送信することと、
    を具備する方法。
34. 請求項１～１５及び３３のいずれか一項に記載の方法を実行させるようデータ処理装置を制御するための命令を含む、コンピュータプログラム。

Images