JP6894469B2

JP6894469B2 - 情報処理装置およびその制御プログラム

Info

Publication number: JP6894469B2
Application number: JP2019108731A
Authority: JP
Inventors: 東　和弘; 和弘東; 健司中山
Original assignee: Toppan Inc
Current assignee: Toppan Inc
Priority date: 2019-06-11
Filing date: 2019-06-11
Publication date: 2021-06-30
Anticipated expiration: 2039-06-11
Also published as: JP2020202500A

Description

本発明は、ＩｏＴデバイスの管理に関する。

上記技術分野において、特許文献１には、ＩｏＴシステムに含まれるＩｏＴデバイスとセンタサーバ間の相互認証を、通信装置としての管理サーバやルート認証局などの仲介により行う技術が開示されている。

特開２０１８−０８２３５３号公報特開２０１８−０９３３５２号公報特許第６３８６６８４号公報

しかしながら、上記文献に記載の技術では、ＩｏＴデバイスとセンタサーバ間の個々の相互認証をするのみで、ＩｏＴデバイスのクライアント証明書の有効期間を考慮した効率的な管理をすることができなかった。

本発明の目的は、上述の課題を解決する技術を提供することにある。

上記目的を達成するため、本発明に係る情報処理装置は、
ＩｏＴデバイスが備える情報処理部としての情報処理装置であって、
ネットワーク上でデータを暗号化し前記ＩｏＴデバイスを認証するために用いられる公開鍵および秘密鍵の配布、ならびに、前記ＩｏＴデバイスの信頼性を証明するクライアント証明書の配布を要求する要求メッセージであって、前記ＩｏＴデバイスに固有の識別子を含む要求メッセージを、デバイス管理サーバに送信する送信手段と、
前記デバイス管理サーバが前記要求メッセージに応答して機密に配布した、前記公開鍵と前記秘密鍵と前記クライアント証明書とを受信する受信手段と、
受信した前記公開鍵と前記秘密鍵と前記クライアント証明書とを保持する保持手段と、
前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを用いて、サービスを提供するサービス提供サーバとネットワーク上でデータを暗号化して送受信する暗号化通信手段と、
前記ＩｏＴデバイスの使用を停止する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを消去する消去手段とを、
備え、
前記消去手段は、さらに、前記公開鍵と前記秘密鍵と前記クライアント証明書とを更新する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを所定時間ごとに消去し、
前記送信手段は、前記保持手段に前記公開鍵と前記秘密鍵と前記クライアント証明書との少なくとも１つが保持されてない場合に、前記要求メッセージを前記デバイス管理サーバに送信する。

上記目的を達成するため、本発明に係る情報処理装置の制御プログラムは、
ＩｏＴデバイスが備える情報処理部としての情報処理装置の制御プログラムであって、
ネットワーク上でデータを暗号化し前記ＩｏＴデバイスを認証するために用いられる公開鍵および秘密鍵の配布、ならびに、前記ＩｏＴデバイスの信頼性を証明するクライアント証明書の配布を要求する要求メッセージであって、前記ＩｏＴデバイスに固有の識別子を含む要求メッセージを、デバイス管理サーバに送信する送信ステップと、
前記デバイス管理サーバが前記要求メッセージに応答して機密に配布した、前記公開鍵と前記秘密鍵と前記クライアント証明書とを受信する受信ステップと、
受信した前記公開鍵と前記秘密鍵と前記クライアント証明書とを保持手段に保持する保持ステップと、
前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを用いて、サービスを提供するサービス提供サーバとネットワーク上でデータを暗号化して送受信する暗号化通信ステップと、
前記ＩｏＴデバイスの使用を停止する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを消去する消去ステップと、
をコンピュータに実行させる情報処理装置の制御プログラムであって、
前記消去ステップにおいては、さらに、前記公開鍵と前記秘密鍵と前記クライアント証明書とを更新する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを所定時間ごとに消去し、
前記送信ステップにおいては、前記保持手段に前記公開鍵と前記秘密鍵と前記クライアント証明書との少なくとも１つが保持されてない場合に、前記要求メッセージを前記デバイス管理サーバに送信する。

本発明によれば、ＩｏＴデバイスのクライアント証明書の有効期間を考慮した効率的な管理をすることできる。

本発明の第１実施形態に係る情報処理装置の構成を示すブロック図である。本発明の第２実施形態に係るデバイス管理システムの構成を示すブロック図である。本発明の第２実施形態に係るデバイス管理システムの動作手順の概要を示すシーケンス図である。本発明の第２実施形態に係るデバイス管理システムの動作手順の概要を示すシーケンス図である。本発明の第２実施形態に係るアクティベーション要求手順を示すシーケンス図である。本発明の第２実施形態に係るアクティベーション要求コマンドのパラメータの構成を示す図である。本発明の第２実施形態に係るアクティベーション要求コマンドへの応答データの構成例を示す図である。本発明の第２実施形態に係るＳＳＬまたはＴＬＳによるデータ通信手順を示すシーケンス図である。本発明の第２実施形態に係るＳＳＬまたはＴＬＳによるデータ通信におけるサーバ証明書の構成を示す図である。本発明の第２実施形態に係るポーリング要求手順を示すシーケンス図である。本発明の第２実施形態に係るポーリング要求コマンドのパラメータの構成を示す図である。本発明の第２実施形態に係るポーリング要求コマンドへの応答データの構成例を示す図である。本発明の第２実施形態に係る情報処理部を含むＩｏＴデバイスの機能構成を示すブロック図である。本発明の第２実施形態に係る情報処理部を含むＩｏＴデバイスのハードウェア構成を示すブロック図である。本発明の第２実施形態に係る情報処理部の処理手順を示すフローチャートである。本発明の第３実施形態に係る情報処理部の機能構成を示すブロック図である。本発明の第４実施形態に係るコンテンツ保護部を組み込んだＩｏＴデバイスの構成を示すブロック図である。

以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素は単なる例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。本発明において使用される文言「デバイスに固有の識別子」は、デバイスを識別するためのデバイス情報、および／または、デバイスに提供されるサービスを識別するためのサービス情報を含む。

［第１実施形態］
本発明の第１実施形態としての情報処理装置１００について、図１を用いて説明する。情報処理装置１００は、インターネットで接続されるデバイスを管理するため制御する。

図１に示すように、情報処理装置１００は、送信部１０１と、受信部１０２と、保持部１０３と、を含む。送信部１０１は、ネットワーク１３０上でデータを暗号化するために用いられる公開鍵および秘密鍵の配布、ならびにデバイス１１０の信頼性を証明するクライアント証明書の配布を要求する要求メッセージであって、デバイス１１０に固有の識別子を含む要求メッセージを、デバイス管理サーバ１２０に送信する。受信部１０２は、要求メッセージに応答して前記デバイス管理サーバ１２０が機密に配布した、公開鍵と秘密鍵とクライアント証明書とを受信する。保持部１０３は、受信した公開鍵と秘密鍵とクライアント証明書とを保持する。

本実施形態によれば、デバイスが使用する公開鍵と秘密鍵とクライアント証明書とをデバイス管理サーバに要求して、機密に配布された公開鍵と秘密鍵とクライアント証明書とを受信して保持するよう構成したので、ＩｏＴデバイスのクライアント証明書の有効期間を考慮した効率的な管理をすることができる。

［第２実施形態］
次に、本発明の第２実施形態に係る情報処理装置としての情報処理部を備えるデバイスを含むデバイス管理システムについて説明する。本実施形態に係る情報処理装置は、上記第１実施形態に加えて、デバイス管理サーバに、サービス提供サーバに対して使用する公開鍵と秘密鍵とクライアント証明書との配布を要求する。そして、デバイス管理サーバから公開鍵と秘密鍵とクライアント証明書とが機密に配布され、公開鍵と秘密鍵とクライアント証明書とを機密に保持する。さらに、本実施形態の情報処理装置は、デバイスの使用を停止する場合に、サービス提供サーバの指示を受けて保持された公開鍵と秘密鍵とクライアント証明書とを消去する。また、本実施形態の情報処理装置は、デバイス管理サーバから一意の識別子（本実施形態では、ＵＵＩＤ(Universally Unique Identifier）)を配布されて機密に保持し、以降のデバイス管理サーバへのアクセスに使用する。

《デバイス管理システム》
以下、図２乃至図５Ｃを参照して、本実施形態に係る情報処理装置としての情報処理部を備えるデバイスを含むデバイス管理システム２００の構成と動作を説明する。

（構成）
図２Ａは、本実施形態に係るデバイス管理システム２００の構成を示すブロック図である。

デバイス管理システム２００は、ＩｏＴデバイス２１０と、デバイス管理サーバ２２０と、サービス提供サーバ２３０と、デバイス製造者２４０と、を含む。

ＩｏＴデバイス２１０は、デバイス管理サーバ２２０に管理されサービス提供サーバ２３０からサービスを提供されるデバイスである。ＩｏＴデバイス２１０は、FOTA(Firmware Over The Air),TrustZone,TPM(Trusted Platform Module)などの機能を有してよい。デバイス管理サーバ２２０は、デバイス管理(Device management)と、証明書管理および鍵管理(Certification/Key management)との機能を有して、ＩｏＴデバイス２１０を管理するサーバである。サービス提供サーバ２３０は、デバイス管理サーバ２２０がＩｏＴデバイス２１０に機密に配布した証明書および鍵を認証し、ＩｏＴデバイス２１０にサービスを提供するWeb serversなどのサーバである。デバイス製造者２４０は、ＩｏＴデバイス２１０を製造する製造者であり、例えばＩｏＴデバイス２１０に固有の識別子などを含むデバイス情報を付して、Device Lifecycle Managementを実現させる。

（動作シーケンス）
図２Ｂおよび図２Ｃは、本実施形態に係るデバイス管理システム２００の動作手順の概要を示すシーケンス図である。

デバイス管理サーバ２２０は、ステップＳ２０１において、認証局としてサービス提供サーバ２３０に登録する。一方、ＩｏＴデバイス２１０は、ステップＳ２０５において、デバイスに固有の識別子となり得るデバイス情報を記憶する。また、ＩｏＴデバイス２１０は、ステップＳ２０７において、デバイスに固有の識別子となり得るサービス情報を記憶する。

その後、ステップＳ２１０において、デバイスを認証するためのデバイスアクティベーション処理として、ＩｏＴデバイス２１０からデバイス管理サーバ２２０に公開鍵と、秘密鍵と、ＩｏＴデバイス２１０が正当であること（信頼性）を証明するクライアント証明書とを要求して、取得して保持する。次に、ステップＳ２２０において、例えばＳＳＬ(Secure Sockets Layer)方式やＴＬＳ(Transport Layer Security)方式によるデータ通信を含むサービス処理として、ＩｏＴデバイス２１０からサービス提供サーバ２３０にサービスを要求して、サービスを受ける。ステップＳ２３０において、デバイスの使用を中止または停止するためのデバイスデアクティベーション処理として、デバイス管理サーバ２２０の指示に従い、ＩｏＴデバイス２１０から公開鍵と秘密鍵とクライアント証明書とを消去する。ここで、ステップＳ２１０の処理が要求部の要求ステップと、保持部の保持ステップとに相当する。また、ステップ２２０の処理が暗号化通信部の暗号化通信ステップに相当する。

デバイス認証のデバイスアクティベーション処理（Ｓ２１０）において、ＩｏＴデバイス２１０は、ステップＳ２１１において、デバイスに固有の識別子を添付した要求メッセージにより、公開鍵と秘密鍵とクライアント証明書とを要求する。なお、デバイスに固有の識別子には、デバイス情報やサービス情報が含まれてよい。デバイス管理サーバ２２０は、ステップＳ２１２において、デバイスに固有の識別子がデバイス管理サーバ２２０に登録済みかを確認する。そして、デバイス登録が確認できれば、デバイス管理サーバ２２０は、ステップＳ２１３において、サービス事業者の情報を含むクライアント証明書を生成する。デバイス管理サーバ２２０は、ステップＳ２１４において、ＩｏＴデバイス２１０からの要求に応答して公開鍵と秘密鍵とクライアント証明書とをＩｏＴデバイス２１０に機密に送信する。ＩｏＴデバイス２１０は、ステップＳ２１５において、受信した公開鍵と秘密鍵とクライアント証明書とを機密に記憶して保持する。

また、デバイス管理サーバ２２０は、ステップＳ２１６において、一意の識別子（例えば、ＵＵＩＤ）を生成する。そして、デバイス管理サーバ２２０は、ステップＳ２１７において、一意の識別子（ＵＵＩＤ）をＩｏＴデバイス２１０に機密に送信する。ＩｏＴデバイス２１０は、ステップＳ２１８において、受信した一意の識別子（ＵＵＩＤ）を機密に記憶して保持する。なお、ステップＳ２１６の一意の識別子（ＵＵＩＤ）の生成をステップＳ２１４の前に実行して、ステップＳ２１７の一意の識別子（ＵＵＩＤ）の送信はステップＳ２１４に含ませてもよい。また、公開鍵および秘密鍵と、クライアント証明書とを別々にデバイス管理サーバ２２０からＩｏＴデバイス２１０に機密に送信してもよい。

データ通信を含むサービス処理（Ｓ２２０）において、ＩｏＴデバイス２１０は、ステップＳ２２１において、デバイス認証（Ｓ２１０）で取得した公開鍵とクライアント証明書を添付してサービス提供サーバ２３０にサービス（アクセス）を要求する。サービス提供サーバ２３０は、ステップＳ２２２において、公開鍵とクライアント証明書とに基づいてＩｏＴデバイス２１０が正当なデバイスか否かを認証する。正当なデバイスと認証されたならば、サービス提供サーバ２３０は、ステップＳ２２３において、サービス（アクセス）許可として、サーバ公開鍵を含み、サービス提供サーバ２３０が正当なサービス提供者であることを証明するサーバ証明書をＩｏＴデバイス２１０に送信する。ＩｏＴデバイス２１０は、ステップＳ２２４において、受信したサーバ証明書によりサービス提供サーバ２３０が正当なサービス提供者であること認証する。ＩｏＴデバイス２１０とサービス提供サーバ２３０との互いの認証がされると、ステップＳ２２５およびＳ２２６において、ＩｏＴデバイス２１０とサービス提供サーバ２３０との間で暗号化データの送受信が実行される。

デバイスの使用を中止または停止するためのデバイスデアクティベーション処理（Ｓ２３０）において、ＩｏＴデバイス２１０は、ステップＳ２３１において、サービス提供サーバ２３０にデバイス認証（Ｓ２１０）で取得した一意の識別子（ＵＵＩＤ）を用いてポーリングする。デバイス管理サーバ２２０は、ステップＳ２３３において、ＩｏＴデバイス２１０が使用中止になる場合には、公開鍵と秘密鍵とクライアント証明書との削除指示をＩｏＴデバイス２１０に送信する。ＩｏＴデバイス２１０は、ステップＳ２３４において、機密に保持された公開鍵と秘密鍵とクライアント証明書とをＩｏＴデバイス２１０から消去する。

なお、ＩｏＴデバイス２１０の使用中止は、デバイス管理サーバ２２０の判断であっても、ステップＳ２３２に示すようにサービス提供サーバ２３０から通知されても、ＩｏＴデバイス２１０からの要求であってもよい。さらに、他の条件に基づいてもよく特に制限はない。例えば、デバイス管理サーバ２２０との１回のセッション毎、あるいは、所定セッションごとに消去して更新するように構成してもよい。また、所定時間経過ごとに、消去して更新するように構成してもよい。

（アクティベーション要求：図中では、“Activate req”で示す）
図３Ａは、本実施形態に係るアクティベーション要求手順を示すシーケンス図である。図３Ａにおいて、ＩｏＴデバイス２１０は、ＳＥ(Secure Element)３１１とＳＥ制御部３１２とを含む情報処理部３１０（本実施形態の情報処理装置に相当）と、ＤＥ(Device Element)３２０と、を備える。ここで、ＳＥ３１１は、公開鍵、秘密鍵、クライアント証明書、あるいは、一意の識別子（ＵＵＩＤ）を機密に保持する保持部を構成する。また、ＳＥ制御部３１２は、デバイス管理サーバ２２０との通信による情報取得およびＳＥ３１１に対する情報の機密保持を制御する。また、ＤＥ３２０は、ＩｏＴデバイス２１０に固有の処理を行う部分であり、例えばＩｏＴデバイス２１０がセンサならばセンサ部分、ＩｏＴデバイス２１０がスマートフォンならばスマートフォンとしての機能部分などを表している。なお、この機能部の分け方は、本実施形態においてＩｏＴデバイス２１０を説明する一例であって別の機能部に分けることもできる。

情報処理部３１０のＳＥ制御部３１２は、ステップＳ３０１において、デバイス管理サーバ２２０にアクティベーション要求(Activate req)を送信する。アクティベーション要求のBodyにはパラメータ、例えば、ＪＳＯＮとして、デバイスに固有の識別子が設定される。デバイスに固有の識別子としては、デバイス情報やサービス情報が含まれてよい。

ステップＳ３０３において、デバイス管理サーバ２２０からＳＥ制御部３１２に、アクティベーション要求の応答として、例えばStatus 200(HTTP Status CodeのＯＫ)が機密に返され、そのBodyにはバイナリデータが含まれている。このバイナリデータは、ステップＳ３０５において、ＳＥ制御部３１２からＳＥ３１１に送信され、ステップＳ３０７においてＳＥ３１１からの機密保持完了を示すＳＥレスポンスを受けると、最初のバイナリデータがＳＥ３１１内に保持されたことが分かる。

以降、ステップＳ３１０において、ＳＥ制御部３１２は、ＳＥ３１１からのＳＥレスポンスを次のバイナリデータを要求する再開要求(Resume req)としてデバイス管理サーバ２２０に送信し、次のバイナリデータを機密に受信し、ＳＥ３１１に機密に保持する処理を繰り返す。このバイナリデータに、公開鍵と秘密鍵とクライアント証明書、および／または、一意の識別子（ＵＵＩＤ）のデータが含まれている。

最後に、ＳＥ制御部３１２は、ステップＳ３２１において、デバイス管理サーバ２２０に対し再開要求(Resume req)を送信する。しかし、所望データの送信が完了したデバイス管理サーバ２２０からは、ステップＳ３２３において、例えばStatus 204(HTTP Status CodeのNo Content)を返し、アクティベーション要求の手順が終了する。

図３Ｂは、本実施形態に係るアクティベーション要求コマンドのパラメータ３００の構成を示す図である。図３Ｂには、ＪＳＯＮ(JavaScript（登録商標） Object Notation)の例を示すが、本実施形態と同様の動作を実現する他の異なるパラメータであってもよい。

アクティベーション要求コマンドのパラメータ３００は、サービス情報３３０とデバイス情報３４０とを含む。サービス情報３３０は、サービスプロバイダーＩＤ(SP)と、サービスＩＤ(sv)と、サービスバージョン(version)などを含む。デバイス情報３４０は、ＩｏＴデバイスの造者名(manufacturer)と、ＩｏＴデバイスのモデル名(model)と、ＩｏＴデバイスのシリアル番号(serial)と、ＩｏＴデバイスのソフトウェアバージョン(sw_ver)と、ＩｏＴデバイスのハードウェアバージョン(hw_ver)と、を含む。なお、サービス情報３３０とデバイス情報３４０は、上記例に限定されるものではない。また、サービス固有拡張データ(extended object)は、サービスについての拡張データである。

図３Ｃは、本実施形態に係るアクティベーション要求コマンドへの応答データ３０１の構成例を示す図である。応答データ３０１は、クライアント証明書３５０と、公開鍵および秘密鍵３６０と、一意の識別子（ＵＵＩＤ）３７０と、を含む。クライアント証明書３５０には、発行先としてサービス事業者などが含まれ、発行者として証明書の発行機関が含まれ、有効期限が含まれる。なお、これら応答データ３０１のＳＥ３１１への機密な保持は、クライアント証明書３５０と、公開鍵および秘密鍵３６０とが関連付けられていれば、共通の記憶領域に保持されても異なる記憶領域に保持されてもよい。

（サービスアクセス要求）
図４Ａは、本実施形態に係るＳＳＬまたはＴＬＳによるデータ通信手順を示すシーケンス図である。なお、図４Ａにおいては、例えばＩｏＴデバイス２１０がセンサの場合であって、サービス提供サーバ２３０に検出データを送信する例を説明する。ただし、サービス提供サーバ２３０からのデータ受信、あるいは、アプリケーションプログラムの受信などの処理も、図３Ａとデータの流れが逆になるだけで類似しており、重複する説明は省略する。また、図４Ａにおいて、図３Ａと同様の構成要素には同じ参照番号を付して、重複する説明は省略する。

図４Ａにおいては、ＩｏＴデバイス２１０に、サービス提供サーバ２３０とのＳＳＬまたはＴＬＳによるデータ通信を処理するＳＳＬ／ＴＬＳ処理部４１３が含まれる。なお、図４Ａには、ＳＥ制御部３１２を図示していないが情報処理部３１０に含まれている。

ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４０１において、ＳＥ３１１から公開鍵とクライアント証明書とを読み出す。このＳＥ３１１からの公開鍵とクライアント証明書との読み出しは、ＳＥ制御部３１２を経由して行われてよい。ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４０３において、サービス提供サーバ２３０へのアクセス（サービス）要求を、公開鍵およびクライアント証明書と共に送信する。そして、アクセス（サービス）要求の応答として、ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４０５において、サービス提供サーバ２３０からサーバ証明書を含むアクセス許可通知を受信する。ここで、ＳＳＬ／ＴＬＳのハンドシェイクでＤＨＥ(Ephemeral Diffie-Hellman)を用いる場合は、ステップＳ４０７において別途の鍵交換処理が実行される。

ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４０９において、ＤＥ３２０に送信データ（本例の場合は、センサデータ）を要求する。その後、ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４１０において、ＤＥ３２０からサービス提供サーバ２３０へのセンサデータの送信を繰り返す。なお、１回の送信で全データが送信される場合は、繰り返しはない。ステップＳ４２１において、ＤＥ３２０からセンサデータの送信終了が通知されると、ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４２３において、センサデータ終了をサービス提供サーバ２３０に通知する。そして、ＳＳＬ／ＴＬＳ処理部４１３は、ステップＳ４２５において、ＳＳＬ／ＴＬＳ処理部４１３からの受信完了通知を受信して、サービスを終了する。そして、ＩｏＴデバイス２１０とサービス提供サーバ２３０は他のフェーズに移行する。この場合に、サービスを提供するサービス提供サーバ２３０が変更されてもよい。

図４Ｂは、本実施形態に係るＳＳＬまたはＴＬＳによるデータ通信におけるサーバ証明書４５０の構成を示す図である。

サーバ証明書４５０は、データとして、証明書の発行先（ウェブサイトの所有者：本実施形態のサービス提供サーバ２３０の所有者に相当）と、証明書の発行者（証明書の発行機関：本実施形態のデバイス管理サーバ２２０の所有者に相当）と、証明書の有効期間などを含む。また、ＲＡＳ方式を使用する場合、サーバ証明書４５０は、ウェブサイトのＲＡＳ秘密鍵に対応するＲＡＳ公開鍵を含んでいる。

（ポーリング要求：図中では、“Polling req”で示す）
図５Ａは、本実施形態に係るポーリング要求手順を示すシーケンス図である。なお、図５Ａにおいて、図３Ａと同様の構成要素およびステップには同じステップ番号を付して、重複する説明は省略する。

情報処理部３１０のＳＥ制御部３１２は、ステップＳ５０１において、デバイス管理サーバ２２０にポーリング要求(Polling req)を送信する。ポーリング要求のBodyにはパラメータ、例えば、ＪＳＯＮとして、アクティベーション要求で取得された一意の識別子（ＵＵＩＤ）が設定される。以下のステップＳ３０３〜Ｓ２３２の処理は、バイナリデータが鍵や証明書の削除を指示する指示コマンドである以外は同様である。

図５Ｂは、本実施形態に係るポーリング要求コマンドのパラメータ５００の構成を示す図である。

ポーリング要求コマンドのパラメータ５００は、一意の識別子（ＵＵＩＤ）である。本実施形態においては、３６文字が使用されているがこれに限定されない。この、ＵＵＩＤは、アクティベーション要求でデバイス管理サーバ２２０から機密に配布されたＵＵＩＤである。

図５Ｃは、本実施形態に係るポーリング要求コマンドへの応答データ５１０の構成例を示す図である。

ポーリング要求コマンドへの応答データ５１０は、本実施形態においては、デバイス管理サーバ２２０からの公開鍵と秘密鍵とクライアント証明書との削除指示が含まれるが、これに限定されるものではない。

《デバイスの機能構成》
図６は、本実施形態に係る情報処理部３１０を含むＩｏＴデバイス２１０の機能構成を示すブロック図である。なお、図６において、図３Ａ、図４Ａ、図５Ａと同様の構成要素には同じ参照番号を付して、重複する説明を省略する。

ＩｏＴデバイス２１０は、本実施形態の情報処理部３１０を構成するＳＥ３１１およびＳＥ制御部３１２と、ＤＥ３２０と、ＳＳＬ／ＴＬＳ処理部４１３とを備える。

ＳＥ制御部３１２は、通信制御部６０１と、要求メッセージ送信部６０２と、鍵および証明書受信部６０３と、鍵および証明書保持部６０４と、鍵および証明書消去部６０５と、ＳＳＬ／ＴＬＳ処理部４１３と、を備える。

通信制御部６０１は、ネットワークを介して、デバイス管理サーバ２２０やサービス提供サーバ２３０との通信を制御する。なお、通信制御部６０１は、ＳＥ制御部３１２およびＳＳＬ／ＴＬＳ処理部４１３の通信制御に兼用されてもよいし、それぞれ別個に設けられてもよい。要求メッセージ送信部６０２は、デバイス管理サーバ２２０への要求メッセージ（例えば、Ａctivate reqやPolling reqなど）を送信する。鍵および証明書受信部６０３は、デバイス管理サーバ２２０から要求メッセージに応答して返信された公開鍵と秘密鍵とクライアント証明書とを受信する。鍵および証明書保持部６０４は、受信された公開鍵と秘密鍵とクライアント証明書とをＳＥ３１１に機密に保持する。鍵および証明書消去部６０５は、ＩｏＴデバイス２１０を使用しなくなった場合に、あるいは、使用を避ける場合、あるいは、定期的にデバイス認証を更新する場合などに、デバイス管理サーバ２２０からの指示で公開鍵と秘密鍵とクライアント証明書とを消去する。ＳＳＬ／ＴＬＳ処理部４１３は、受信して機密に保持された公開鍵と秘密鍵とクライアント証明書とを用いてＳＳＬ方式やＴＬＳ方式によりサービス提供サーバ２３０との暗号化データの通信を実行する。

《デバイス制御装置のハードウェア構成》
図７は、本実施形態に係る情報処理部３１０を含むＩｏＴデバイス２１０のハードウェア構成を示すブロック図である。

図７で、ＣＰＵ(Central Processing Unit)７１０は演算制御用のプロセッサであり、プログラムを実行することで図６の機能を実現する。なお、ＣＰＵ７１０は、それぞれの機能に対応して複数あってもよく、例えば、後述するNon Secure WorldとSecure Worldとは、異なるＣＰＵで実現してもよい。また、ＳＥ制御部の処理とデバイスの処理とを、異なるＣＰＵで並行に実行してもよい。ＲＯＭ(Read Only Memory)７２０は、初期データおよびプログラムなどの固定データおよびプログラムを記憶する。ネットワークインタフェース７３０は、ネットワークを介して、デバイス管理サーバ２２０やサービス提供サーバ２３０との通信を制御する。ＳＥ３１１は、情報処理部３１０に含まれる機密情報の保持部であり、デバイス管理サーバ２２０に認証されて取得され、サービス提供サーバ２３０とのＳＳＬ／ＴＬＳ処理に使用される、公開鍵と秘密鍵とクライアント証明書とを機密に記憶する。また、ＳＥ３１１は、デバイス管理サーバ２２０へのアクセスに使用される一意の識別子（ＵＵＩＤ）も記憶する。

ＲＡＭ(Random Access Memory)７４０は、ＣＰＵ７１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ７４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。送信コマンド７４１は、ＳＥ制御部３１２が外部装置に対して送信するアクティベーションやポーリングなどのコマンドである。送信パラメータ７４２は、送信コマンド７４１に付与されるＪＳＯＮなどのパラメータである。送信データ７４３は、送信コマンド７４１に付与される、例えばデバイスがセンサ機能を有する場合は検出データである。受信コマンド７４４は、ＳＥ制御部３１２が外部装置から受信するコマンドである。受信パラメータ７４５は、受信コマンド７４４に付与される、例えばＳＥ３１１からの機密情報の削除指示を含むパラメータである。受信データ７４６は、受信コマンド７４４に付与される、例えばデバイスがアプリケーションを更新・変更可能な場合はアプリケーションプログラムである。入出力データ７４８は、入出力インタフェース７６０を介して入出力機器などと交換するデータである。

ストレージ７５０は、データベースや各種のパラメータ、あるいは本実施形態の実現に必要な以下のデータまたはプログラムが記憶さる不揮発メモリである。デバイス情報３４０は、図３Ｂに示したアクティベーションコマンドのパラメータとして使用され得るデータである。サービス情報３３０は、図３Ｂに示したアクティベーションコマンドのパラメータとして使用され得るデータである。通信アルゴリズム７５１は、本ＩｏＴデバイス２１０のＳＥ制御部３１２やＳＳＬ／ＴＬＳ処理部４１３がデバイス管理サーバ２２０やサービス提供サーバ２３０と通信ために使用する通信プロトコルやシーケンス、フォーマットなどを記憶する。

ストレージ７５０には、以下のプログラムが格納される。デバイス制御プログラム７５２は、本ＩｏＴデバイス２１０全体を制御するプログラムである。ＳＥ制御プログラム７５３は、図３Ａ、図５Ａおよび図６のＳＥ制御部３１２を実現するプログラムである。ＳＥ制御プログラム７５３は、デバイスアクティベーションモジュール７５４とデバイスデアクティベーションモジュール７５５とを含む。デバイスアクティベーションモジュール７５４は、デバイス管理サーバ２２０との間でデバイスをアクティベーションする、すなわち、公開鍵と秘密鍵とクライアント証明書とを受信してＳＥ３１１に機密に保持するモジュールである。デバイスデアクティベーションモジュール７５５は、デバイス管理サーバ２２０からの指示でデバイスをデアクティベーション、すなわち、アクティベーション時に取得した公開鍵と秘密鍵とクライアント証明書とを消去するモジュールである。サービスプログラム７５６は、サービス提供サーバ２３０と接続してサービスを受けるためのプログラムであり、サービスアクティベーションモジュール７５７を有する。サービスアクティベーションモジュール７５７は、サービス提供サーバ２３０との間でサービスをアクティベーションして実行するモジュールである。

入出力インタフェース７６０は、入出力デバイスとのデータ入出力を制御するためのインタフェースを行なう。本実施形態においては、入出力インタフェース７６０には、表示部７６１と、操作部７６２と、デバイスがセンサの場合のセンサ部７６３とが接続される。入出力インタフェース７６０には、さらに、撮像部やＧＰＳ位置算出部、などが接続されてもよい。

なお、図７のＲＡＭ７４０やストレージ７５０には、ＩｏＴデバイス２１０や情報処理部３１０が有する汎用の機能や他の実現可能な機能に関連するプログラムやデータは図示されていない。

《デバイス制御装置の処理手順》
図８は、本実施形態に係る情報処理装置としての情報処理部３１０の処理手順を示すフローチャートである。このフローチャートは、図７のＣＰＵ７１０がＲＡＭ７４０を使用して実行し、図６のＳＥ制御部３１２の機能構成部を実現する。

ＳＥ制御部３１２は、ステップＳ８２０において、ＳＥ３１１に公開鍵、秘密鍵、クライアント証明書が記憶されているか否かをチェックする。そして、ＳＥ制御部３１２は、ステップＳ８２１において、ＳＥ３１１内に公開鍵、秘密鍵、クライアント証明書が有るか無いかにより、分岐する。公開鍵、秘密鍵、クライアント証明書が無いと判定した場合、ＳＥ制御部３１２は、ステップＳ８２３において、対応するパラメータとしてデバイス情報やサービス情報から選ばれたデバイスに固有の識別子を取得して設定する。ＳＥ制御部３１２は、ステップＳ８２５において、アクティベーションメッセージを送信する。ＳＥ制御部３１２は、ステップＳ８２７において、アクティベーションメッセージへの応答を待つ。アクティベーションメッセージへの応答を受信すると、ＳＥ制御部３１２は、ステップＳ８２９において、応答メッセージを受信する。そして、ＳＥ制御部３１２は、ステップＳ８３１において、応答メッセージから公開鍵と秘密鍵とクライアント証明書とを抽出して機密にＳＥ３１１に記憶する。なお、図示していないが、一意の識別子（ＵＵＩＤ）も受信して機密にＳＥ３１１に記憶する。

ＳＥ３１１内に公開鍵、秘密鍵、クライアント証明書が有ると判定された場合、ＳＥ制御部３１２は、ステップＳ８４１において、所定の閾値時間が経過したか否かを判定する。所定の閾値時間が経過したと判定した場合、ＳＥ制御部３１２は、ステップＳ８４３において、対応するパラメータとして、一意の識別子（ＵＵＩＤ）をＳＥ３１１から取得して設定する。ＳＥ制御部３１２は、ステップＳ８４５において、ポーリングメッセージを送信する。ＳＥ制御部３１２は、ステップＳ８４７において、ポーリングメッセージへの応答を待つ。ポーリングメッセージへの応答を受信すると、ＳＥ制御部３１２は、ステップＳ８４９において、公開鍵と秘密鍵とクライアント証明書との消去指示であるか否かを判定する。公開鍵と秘密鍵とクライアント証明書との消去指示であれば、ＳＥ制御部３１２は、ステップＳ８５１において、公開鍵と秘密鍵とクライアント証明書との消去処理を実行する。公開鍵と秘密鍵とクライアント証明書との消去指示でなければ、ＳＥ制御部３１２は、ステップＳ８４９において、他の指示された処理を実行する。

なお、ＳＥ３１１に公開鍵、秘密鍵、クライアント証明書が記憶されているか否かのチェックにおいては、全てが揃っている場合を有り、１つでも欠けていれば無いと判定するのが望ましい。

本実施形態によれば、公開鍵と秘密鍵とクライアント証明書とをデバイスの要求に基づいて機密に配布して機密保持し、デバイスが使用停止になる場合に公開鍵と秘密鍵とクライアント証明書とを消去するよう構成したので、ＩｏＴデバイスのクライアント証明書の有効期間を考慮したさらに効率的な管理をすることできる。

［第３実施形態］
次に、本発明の第３実施形態に係るデバイス管理システムについて説明する。本実施形態に係るデバイス管理システムのデバイスは、上記第２実施形態と比べると、デバイス内にSecure World (Secure OS Part)とNon Secure World (Non Secure OS Part)とを有する。そして、公開鍵と秘密鍵とクライアント証明書、または、一意の識別子（ＵＵＩＤ）がSecure Worldに保持される点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。なお、本実施形態の構成および動作の詳細は、特許文献２を参照されたい。

《キーセットを格納する記憶部を機密部分に配置するソフトウェア階層》
図９は、本実施形態に係る情報処理部の機能構成を示すブロック図である。すなわち、本実施形態に係るコンテンツ保護部を組み込んだデバイスで、キーセットを格納する記憶部を機密部分に配置したＩｏＴデバイス２１０のソフトウェア階層を示す図である。本実施形態のキーセットを格納する記憶部は、ハードウェア的に分離されたSecure World９２５内に、Middleware's Secure Data Part９２６として確保される。

ＩｏＴデバイス２１０のソフトウェア階層は、Application層（９０１および９０２）と、Middlewareとして提供されるHDCP SDK層（９１０）と、Middlewareとして提供される本実施形態の暗号化／復号層Middleware（９２０）と、ＯＳとの接続層（９３１、９３２および９３３）と、ＯＳ層（９４１および９４２）と、ファームウェア(Firmware)層９６０と、ハードウェア層（９５０、９５１および９５２）とを有する。

（Application層）
User Application９０１は、暗復号化処理とセキュアに扱うべきデータを読み書きの機能が必要なユーザが独自に開発するアプリケーションを示す。一方、User Application９０２は、HDCP SDK９１０のＡＰＩを使用してHDCP対向機とのＡＫＥ(Authentication and Key Exchange)開始の指示や、検出したトポロジーチェンジに対する具体的な動作の制御を行うアプリケーションを示す。ソース機器の場合は、ＡＫＥの完了後、送信するストリーミングデータを生成してHDCP SDK９１０に入力する。一方、シンク機器の場合、ＡＫＥ完了後、HDCP SDK９１０が復号化したストリーミングデータの描画処理を行う。なお、Applicationは上記例に限定されない。種々の暗号化や復号に関連するハードウェアを利用するApplicationが接続可能である。

（HDCP SDK層：所定の通信プロトコルのMiddleware）
HDCP SDK９１０は、例えば、HDCP 2.2 の仕様（HDCP Specification Rev. 2.2 Interface Independent Adaptation）に基づき、以下の機能を提供する。
(1) ＤＣＰ(Digital Content Protection, LLC) が発行するデバイス鍵を使用して、対向となるHDCP機器とＡＫＥを実行してセッションキーを共有する。
(2) セッションキーを使用したストリーミングデータの暗号化/復号化を行なう。
(3) 接続されているHDCP機器のトポロジーチェンジの検出と通知を行なう。
(4) HDCPソース機器の場合、ＳＲＭ(System Renewability Message)リストに基づいた無効機器の検出を行なう。

HDCP SDK９１０のSecure Data Partは、ＡＫＥのシーケンスで扱うデータのうち、HDCPの仕様によりセキュアに扱うことが定められているデータを扱う箇所であり、例えば、セッションキーやDCPが発行するデバイス鍵などを保持する。一方、HDCP SDK９１０のNon Secure Data Partは、ＡＫＥのシーケンスで扱うデータのうち、ネットワーク上に非暗号データとして流れるなど、HDCPの仕様によりセキュアに扱うことが定められていないデータを扱う箇所であり、例えば、DCPが発行する公開鍵やHDCP機器の機能を示すフラグなどを保持する。また、HDCP SDK９１０のCommunication Partは、ＡＫＥを行う際に使用するネットワーク通信セッションの確立や、ＡＫＥ完了後、セッションキーにより暗復号化されたストリーミングデータのやり取りを行う。

本実施形態において、HDCP SDK９１０は、ＡＫＥのシーケンスで扱うデータのうち、HDCPの仕様によりセキュアに扱うことが定められているデータ以外を扱う箇所であり、例えば、セッションキーやDCPが発行するデバイス鍵などを保持するためのSecure Data Partを有さない。Secure Data Partは、ハードウェア的に分離されたSecure World９２５内に、Middleware's Secure Data Part９２６として確保される。

（暗号化／復号層のMiddleware）
暗号化／復号層Middleware９２０は、Non Secure OS上のNon Secure OS Part(Non Secure World)９２４と、Secure OS上のSecure OS Part(Secure World)９２５と、に分離されている。

Non Secure World９２４は、User Application９０１または９０２から直接、あるいは、HDCP SDK層９１０を介してインタフェースするPublic API９２１と、ハードウェアとの接続を管理するPrivate Layer９２２と、Secure World９２５とのハードウェア的に分離されたデータ転送を行なうためのPorting Layer９２７と、を有する。

一方、Secure World９２５は、Non Secure World９２４とのハードウェア的に分離されたデータ転送を行なうためのPorting Layer９２８と、Secure World９２５内でハードウェアとの接続を管理するPrivate Layer９２２と、Secure World９２５内でハードウェア層９５１および９５２を各々制御するPorting Layer９２３と、Middleware's Secure Data Part９２６と、を有する。

なお、Porting Layer９２７とPorting Layer９２８との間のデータ転送９２９は、ファームウェア(Firmware)層９６０まで戻ることによって、ハードウェア的に分離される。

（ＯＳとの接続層）
ＯＳとの接続層は、新たに、Secure World９２５をSecureＯＳ層９４２と接続するSoC depended Secure Middleware for Secure OS９３３、を有する。

（ＯＳ層）
ＯＳ層は、Non Secure World９２４に対応するNon Secure OS driverおよびNon Secure OS９４１と、Secure World９２５に対応するSecure OS driverおよびSecure OS９４２と、を有する。

（ファームウェア層）
ファームウェア層９６０は、Non Secure World９２４とSecure World９２５とをハードウェア的に分離する。

（ハードウェア層）
ハードウェア層は、SoC９５０と、各ハードウェア９５１あるいは９５２と、を有する。図９においては、Secure Storage Feature９５１とHardware Accelerated９５２とを示すが、これらに限定されない。他の機密保護の暗号化や復号に関連する機能を有するハードウェアが接続可能である。

（Secure World）
Secure WorldとHDCP SDK９１０を組み合わせた場合、HDCP SDK９１０のSecure Data PartがSecure OS内に入り、Non Secure OS上で動作するHDCP SDKは、Secure Data Interfaceを使用してSecure OS内で動作するSecure Data Partとやり取りを行うことになる。

本実施形態によれば、上記実施形態の効果に加えて、暗号鍵やサーバ証明書などをSecure World内に保持するので、機密性をさらに高めることができる。

［第４実施形態］
次に、本発明の第３実施形態に係るデバイス管理システムについて説明する。本実施形態に係るデバイス管理システムのデバイスは、上記第２実施形態および第３実施形態と比べると、デバイス内に、デバイス固有の識別子を用いて暗号化した公開鍵と秘密鍵とクライアント証明書とを保持するコンテンツ保護部を組み込んだ点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。なお、本実施形態の構成および動作の詳細は、特許文献３を参照されたい。

《コンテンツ保護部を組み込んだデバイスの構成》
図１０は、本実施形態に係るコンテンツ保護部１０２１を組み込んだＩｏＴデバイス２１０の構成を示すブロック図である。

ＩｏＴデバイス２１０は、アプリケーション１０１１と、暗号化コンテンツ格納部１０１２と、デバイス固有の識別子（ＩＤ）の記憶部１０１３と、を備える。暗号化コンテンツ格納部１０１２には、ブロック暗号化された暗号化コンテンツ１００２が格納される。また、デバイス固有の識別子（ＩＤ）としては、ＩｏＴデバイス２１０の製造時に不揮発に記憶された製造番号などが使用されてよい。

アプリケーション１０１１は、本実施形態のコンテンツ保護部１０２１として機能するミドルウェア(Middleware)を含み、コンテンツ保護部１０２１のブロック暗号化および復号部１０４１に、コンテンツを分割したブロックに固有のブロック番号１０２２およびコンテンツを識別するコンテンツＩＤを提供する。

コンテンツ保護部１０２１として機能するミドルウェア(Middleware)は、コンテンツ保護処理部１０３１と、キーセット記憶部１０３２と、を有する。キーセット記憶部１０３２は、少なくとも公開鍵と秘密鍵とを含むキーセット１０３３を記憶する。

コンテンツ保護処理部１０３１は、ブロック暗号化および復号部１０４１と、キーセットのＲＳＡ署名検証部１０４２と、記憶部１０１３のデバイス固有の識別子によるＲＳＡ秘密鍵生成部１０４３と、復号ＲＳＡ秘密鍵によるブロック暗号鍵セット生成部１０４４と、を含む。ブロック暗号化および復号部１０４１は、ブロックに固有のブロック番号１０２２およびコンテンツを識別するコンテンツＩＤを用いて、復号されたブロック暗号鍵セットにより、入力された入力コンテンツ１００１をブロック暗号化して、暗号化コンテンツ１００２を生成する。

ここで、ブロック暗号化および復号部１０４１で使用される復号されたブロック暗号鍵セットは、次の手順で生成される。
(1)キーセット記憶部１０３２に記憶された、暗号化ブロック暗号鍵セットとＲＳＡ公開鍵と暗号化ＲＳＡ秘密鍵とのＲＳＡ署名されたキーセット１０３３を、ＲＳＡ署名検証部１０４２で検証する。
(2)検証されたキーセットの暗号化ＲＳＡ秘密鍵を、ＲＳＡ秘密鍵生成部１０４３において記憶部１０１３のデバイス固有の識別子で復号して、復号ＲＳＡ秘密鍵を生成する。
(3)検証されたキーセットの暗号化ブロック暗号鍵セットを、ブロック暗号鍵セット生成部１０４４において復号ＲＳＡ秘密鍵により復号して、復号ブロック暗号鍵セットを生成する。

なお、本実施形態においては、暗号化と復号化は全く同じ構造になるので、プログラムで実装するのが容易である点、暗号化・復号化の際に使う「カウンタ」をContent IDとブロック番号から生成し、ブロックを任意の順番で暗号化・復号化することができることなどから、カウンタモード（CTRモード：CounTeR mode）を使用する。CTRモードは、１ずつ増加していくカウンタを暗号化して鍵ストリームを作りだすブロック暗号方式であり、カウンタの初期値は暗号化のたびにInitial Vector とContent ID、inputCtrとを元にして作る。しかしながら、使用するブロック暗号は、CTRモードに限定されない。

このように、ＲＳＡ検証およびデバイス固有の識別子で復号したコンテンツ保護用鍵をコンテンツの暗号化および復号に使用するので、コンテンツ保護用鍵の不正取得によってもコンテンツの不正使用を充分に防ぐデバイスまたはデバイスが組み込まれた情報処理装置を提供することができる。

本実施形態によれば、上記実施形態の効果に加えて、コンテンツ保護用鍵の不正取得によってもコンテンツの不正使用を充分に防ぐことができる。

［他の実施形態］
なお、上記実施形態においては、ＩｏＴデバイスとサービス提供サーバ間のデータ暗号化通信としてＳＳＬ方式またはＴＬＳ方式を使用したが、他の方式であってもよい。その場合、使用されたデータ暗号化通信方式で使用される鍵や証明書などの情報をデバイスがあらかじめデバイス管理サーバから取得することになる。これらの構成においても、同様に効果を奏することができる。また、デバイス管理サーバから情報処理装置に機密に配布される情報は、サービス提供サーバに対して有用な情報であればよく、公開鍵、秘密鍵およびクライアント証明書の組に限定されるものではない。また、公開鍵、秘密鍵、クライアント証明書を機密保持する構成として図９または図１０の構成例を示したが、この構成に限定されるものではない。

また、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の範疇に含まれる。

また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する情報処理プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるＷＷＷ(World Wide Web)サーバも、本発明の範疇に含まれる。特に、少なくとも、上述した実施形態に含まれる処理ステップをコンピュータに実行させるプログラムを格納した非一時的コンピュータ可読媒体（non-transitory computer readable medium）は本発明の範疇に含まれる。

Claims

ＩｏＴデバイスが備える情報処理部としての情報処理装置であって、
ネットワーク上でデータを暗号化し前記ＩｏＴデバイスを認証するために用いられる公開鍵および秘密鍵の配布、ならびに、前記ＩｏＴデバイスの信頼性を証明するクライアント証明書の配布を要求する要求メッセージであって、前記ＩｏＴデバイスに固有の識別子を含む要求メッセージを、デバイス管理サーバに送信する送信手段と、
前記デバイス管理サーバが前記要求メッセージに応答して機密に配布した、前記公開鍵と前記秘密鍵と前記クライアント証明書とを受信する受信手段と、
受信した前記公開鍵と前記秘密鍵と前記クライアント証明書とを保持する保持手段と、
前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを用いて、サービスを提供するサービス提供サーバとネットワーク上でデータを暗号化して送受信する暗号化通信手段と、
前記ＩｏＴデバイスの使用を停止する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを消去する消去手段とを、
備え、
前記消去手段は、さらに、前記公開鍵と前記秘密鍵と前記クライアント証明書とを更新する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを所定時間ごとに消去し、
前記送信手段は、前記保持手段に前記公開鍵と前記秘密鍵と前記クライアント証明書との少なくとも１つが保持されてない場合に、前記要求メッセージを前記デバイス管理サーバに送信する情報処理装置。
前記消去手段は、前記デバイス管理サーバから前記情報処理装置に設定された一意の識別子（ＵＵＩＤ：Universally Unique Identifier）を有する、前記デバイス管理サーバへのポーリング要求に応答する削除メッセージに基づいて、前記公開鍵と前記秘密鍵と前記クライアント証明書とを消去する請求項１に記載の情報処理装置。
前記情報処理装置は非機密部(Non Secure World)と機密部(Secure World)とを有し、前記保持手段は、前記公開鍵と前記秘密鍵と前記クライアント証明書とを機密に処理して保持する前記機密部にあり、前記識別子を用いて暗号化した前記公開鍵と前記秘密鍵と前記クライアント証明書とを保持する請求項１または２に記載の情報処理装置。
ＩｏＴデバイスが備える情報処理部としての情報処理装置の制御プログラムであって、
ネットワーク上でデータを暗号化し前記ＩｏＴデバイスを認証するために用いられる公開鍵および秘密鍵の配布、ならびに、前記ＩｏＴデバイスの信頼性を証明するクライアント証明書の配布を要求する要求メッセージであって、前記ＩｏＴデバイスに固有の識別子を含む要求メッセージを、デバイス管理サーバに送信する送信ステップと、
前記デバイス管理サーバが前記要求メッセージに応答して機密に配布した、前記公開鍵と前記秘密鍵と前記クライアント証明書とを受信する受信ステップと、
受信した前記公開鍵と前記秘密鍵と前記クライアント証明書とを保持手段に保持する保持ステップと、
前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを用いて、サービスを提供するサービス提供サーバとネットワーク上でデータを暗号化して送受信する暗号化通信ステップと、
前記ＩｏＴデバイスの使用を停止する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを消去する消去ステップと、
をコンピュータに実行させる情報処理装置の制御プログラムであって、
前記消去ステップにおいては、さらに、前記公開鍵と前記秘密鍵と前記クライアント証明書とを更新する場合に、前記保持手段に保持された前記公開鍵と前記秘密鍵と前記クライアント証明書とを所定時間ごとに消去し、
前記送信ステップにおいては、前記保持手段に前記公開鍵と前記秘密鍵と前記クライアント証明書との少なくとも１つが保持されてない場合に、前記要求メッセージを前記デバイス管理サーバに送信する情報処理装置の制御プログラム。