JP7725431B2 - 情報処理装置、情報処理プログラム、及び情報処理システム - Google Patents

Description

本実施形態は、情報処理装置、情報処理プログラム、及び情報処理システムに関する。

サイバーフィジカルシステム（Cyber-Physical System;ＣＰＳ）では、多数のデバイスとクラウド上のサーバが通信することで一つのシステムを構成する。システムをサイバー攻撃から守るため、レジスタラと呼ばれるサーバに、信頼できるデバイスと、デバイスごとの接続先のサーバをあらかじめ登録する手法が存在する。

BRSKI Cloud Registrar (https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-03.html) FIDO Device Onboard Specification v1.1 (https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/)

レジスタラにはデバイス証明書に関連付けて、そのデバイスが接続すべきＣＰＳサーバの情報があらかじめ記憶されている。レジスタラは、デバイス証明書を用いてデバイスを認証する。レジスタラはアクセスしてきたデバイスの認証に成功すると、そのデバイスに関連付けられたＣＰＳサーバの情報をデバイスに通知する。ＣＰＳのセキュリティリスクとして、デバイスの所有者とは異なる第三者が攻撃者となり、デバイス証明書を入手することが考えられる。攻撃者は、デバイス証明書を利用し、レジスタラに不正な接続先サーバを登録することができる。この場合、レジスタラは当該デバイスを不正な接続先サーバに誘導してしまう。これにより、デバイスからの情報漏洩及びデバイスの不正な制御等が発生する恐れがある。

そこで、本実施形態は、デバイスが正規でないサーバに誘導されることを回避できる情報処理装置、情報処理プログラム、及び情報処理システムを提供するものである。

本実施形態に係る情報処理装置は、ユーザのトークン発行要求に応じて第１トークンを発行する第１トークン発行部と、前記ユーザの情報と前記第１トークンとを対応づけて記憶する第１記憶部と、前記ユーザが所有するデバイスの所有登録情報を記憶する第２記憶部と、前記デバイスから提供される第１トークンを受け付ける第１トークン受付部と、前記第１トークンを提供した前記デバイスの情報が前記第１記憶部に記憶されており、前記第１トークン受付部により受け付けられた前記第１トークンが前記記憶部における前記第１トークンに一致するかの検証を含む所有者検証を行い、所有者検証が成功した前記第１トークンに対応する前記ユーザを前記デバイスの所有者として決定する所有者検証部と、前記所有者が決定された前記デバイスの情報を含む検証済みデータを記憶する第３記憶部とを備える。

第１の実施形態に係るＣＰＳの一例を示すシステム構成図である。 第１の実施形態に係るレジスタラの一構成例を示すブロック図である。 第１の実施形態に係るデバイスの一構成例を示すブロック図である。 第１の実施形態に係るデバイステーブルの一構成例である。 第１の実施形態に係るユーザテーブルの一構成例である。 第１の実施形態に係る所有登録テーブルの一構成例である。 第１の実施形態に係る検証済み所有登録テーブルの一構成例である。 第１の実施形態におけるシステムの動作を示すシーケンス図である。 所有者検証の動作を示すフローチャート図である。 所有権抹消処理の動作を示すフローチャート図である。 所有権移転処理の動作を示すフローチャート図である。 比較例のシステムの動作を示すシーケンス図である。 比較例の接続先ＣＰＳサーバの記憶例を示す図である。 比較例のセキュリティリスクを示すシーケンス図である。 第１の実施形態において攻撃を受けた場合の動作を示すシーケンス図である。 第２の実施形態におけるシステムの動作を示すシーケンス図である。 第３の実施形態に係るＣＰＳの一例を示すシステム構成図である。 第３の実施形態に係るレジスタラの一構成例を示すブロック図である。 第３の実施形態に係るデバイスの一構成例を示すブロック図である。 第３の実施形態における所有登録テーブルの一構成例である。 第３の実施形態におけるユーザ鍵テーブルの一構成例である。 第３の実施形態における所有証明書テーブルの一構成例である。 第３の実施形態におけるシステムの動作を示すシーケンス図である。 第４の実施形態に係るＣＰＳの一例を示すシステム構成図である。 第４の実施形態に係る所有者管理サーバの一構成例を示すブロック図である。 第４の実施形態に係る所有証明書発行サーバの一構成例を示すブロック図である。 第４の実施形態に係るデバイスの一構成例を示すブロック図である。 第４の実施形態における所有者証明トークンテーブルの一構成例である。 第４の実施形態におけるシステムの動作を示すシーケンス図である。 所有者証明トークン検証の動作を示すフローチャート図である。

以下、図面を参照しながら、本発明の実施形態について説明する。

（第１の実施形態）
図１は、第１の実施形態に係るレジスタラ（情報処理装置）１を備えたＣＰＳ（Cyber-Physical System）の一例を示すシステム構成図である。図１に示すシステムは、レジスタラ１、デバイス２、データベース（ＤＢ）３、及びＣＰＳサーバ４から構成される。図１に示すシステムの目的は、デバイス２とＣＰＳサーバ４を安全に初期設定し、両者が通信できるようにすることである。

レジスタラ１、データベース３及びＣＰＳサーバ４は、例えばクラウド上に配置され、ネットワーク６を介して、ユーザ５が所有するデバイス２と接続されている。

レジスタラ１は、デバイス２をユーザ指定のＣＰＳサーバ４（正規のＣＰＳサーバ）に初期登録する作業を支援するとともにデバイス２が不正なＣＰＳサーバに誘導されることを阻止することを実現するサーバである。レジスタラ１は、ユーザ５がデバイス２の正当な所有者であるかを検証する仕組みを備え、当該仕組みによる検証の結果を記憶・管理する。レジスタラ１は、検証により正当な所有者（ここではユーザ５）が決定されたデバイス２のみを、ユーザ５により指定されるＣＰＳサーバ４に誘導する。上記の仕組みにより攻撃者はデバイスの正当な所有者として認定されないため、デバイス２が攻撃者が指定したＣＰＳサーバに誘導されることは阻止される。

デバイス２は、ＣＰＳサーバ４と通信してＣＰＳサーバ４から任意のサービスの提供を受ける端末装置である。デバイス２は固有の秘密鍵（デバイス秘密鍵）と、それに対応する電子証明書（デバイス証明書）を有する。

データベース３は、レジスタラ１により読み書き可能な情報を記憶・管理するための記憶装置である。

ＣＰＳサーバ４は、デバイス２と通信してデバイス２に対して任意のサービスを提供するサーバである。

ユーザ５は、デバイス２を所有する、例えば１人の人間、１台のロボット、あるいは、人間又はロボットのグループである。ユーザ５は、デバイス２を用いてＣＰＳに参加する。ユーザ５は、レジスタラ１及びＣＰＳサーバ４に自身のユーザアカウントを作成し、保有している。

ネットワーク６は、主にデバイス２がレジスタラ１及びＣＰＳサーバ４と通信するために用いるネットワークである。ネットワーク６は、例えば、ローカルエリアネットワーク（ＬＡＮ）、及びインターネットを含む。

レジスタラ１、データベース３及びＣＰＳサーバ４は、有線又は無線で接続されていてもよいし、レジスタラ１の内部にデータベース３又はＣＰＳサーバ４が組み込まれていてもよい。

図２は、第１の実施形態に係るレジスタラ１の一構成例を示すブロック図である。図２で示すレジスタラ１は、所有者検証トークン発行部（第１トークン発行部）１１と、所有者検証トークン受付部（第１トークン受付部）１２と、所有者検証部１３と、デバイス登録受付部１４と、接続先ＣＰＳサーバ通知部（接続先通知部）１５と、所有権抹消処理部（抹消処理部）１６と、所有権移転処理部（移管処理部）１７とを備える。ただし、これらの要素のうちの一部を備えない構成も可能である。例えば、レジスタラ１は、所有権抹消処理部（抹消処理部）１６と、所有権移転処理部（移管処理部）１７とのうちの少なくとも一方を備えていなくてもよい。

所有者検証トークン発行部１１は、ユーザ５のトークン発行要求に応じて所有者検証トークン（第１トークン）を発行し、所有者検証トークンをユーザ５に送る。所有者検証トークン発行部１１は、発行した所有者検証トークンを、ユーザ５の情報と対応づけて、データベース３に記憶する。ユーザ５はデバイス２とは別にスマートフォン又はパーソナルコンピュータ等のユーザ端末を有しており、ユーザ端末を用いてレジスタラ１と通信することができる。以下の説明においてユーザ５が主体とする動作はユーザ５が保有するユーザ端末が行うことを意味する。またユーザ５に対して行う動作はユーザ５が保有するユーザ端末に対して行う動作であるとする。但し、ユーザ端末としてユーザがデバイス２を用いることがある場合があってもよいものとする。

所有者検証トークン受付部１２は、デバイス２から提供される所有者検証トークンを受け付けて、所有者検証部１３に所有者検証トークンを送る。

所有者検証トークン受付部１２は、デバイス２が、データベース３に記憶されたデバイス公開鍵（第１復号鍵）のいずれかに対応する、デバイス秘密鍵（第１暗号鍵）を有しているか否かを検証してもよい。所有者検証トークン受付部１２は、当該検証に基づいて、所有者検証トークンを受け付けてもよい。

所有者検証部１３は、所有者検証トークンを提供したデバイス２の情報（例えばデバイスＩＤ）がデータベース３に記憶されているか、及び所有者検証トークン受付部１２が受け付けた所有者検証トークンが、データベース３に記憶された所有者検証トークンと一致するか等を検証（以下、所有者検証）する。所有者検証の具体的な処理内容については後述する。

所有者検証部１３は、所有者検証が成功した、所有者検証トークンに対応するユーザ５（以下、検証済みユーザ）を、デバイス２の所有者として決定する。所有者検証部１３は、所有者が決定されたデバイス２の情報を含む検証済みデータを、データベース３に記憶する。さらに、所有者検証部１３は、検証済みユーザが指定する接続先ＣＰＳサーバの情報（例えばＵＲＬUniform Resource Locator）等）を、データベース３から取得する。

デバイス登録受付部１４は、ユーザ５からデバイス２の登録リクエストを受け付ける。登録リクエストには、デバイス２のデバイス証明書（第１証明書）が含まれる。デバイス証明書は、デバイス２のデバイス公開鍵の情報を含む。デバイス登録受付部１４はデバイス証明書を含む情報をデータベース３に記憶する。

登録リクエストにはユーザ５が指定する接続先ＣＰＳサーバの情報が含まれる。デバイス登録受付部１４は、デバイス２の情報と接続先ＣＰＳサーバの情報を関連づけて、データベース３に記憶する。

接続先ＣＰＳサーバ通知部１５は、所有者検証部１３から接続先ＣＰＳサーバの情報として例えば、ＵＲＬ（Uniform Resource Locator）を取得する。また、接続先ＣＰＳサーバ通知部１５は、デバイス２に対して、接続先ＣＰＳサーバの情報を通知する。

所有権抹消処理部１６は、検証済みユーザからの要求によって、データベース３内から、当該検証済みユーザの情報（検証済みユーザがデバイス２を所有するとの情報）を削除する。

所有権移転処理部１７は、検証済みユーザ及び新しいユーザからの要求によって、データベース３内の、デバイス２の所有者を、検証済みユーザから当該新しいユーザに書き換える。

図３は、第１の実施形態に係るデバイス２の一構成例を示すブロック図である。図２で示すデバイス２は、所有者管理部２１と、所有者検証トークン記憶部（第５記憶部）２２、所有者検証トークン一時記憶部２３、デバイス証明書記憶部２４、デバイス秘密鍵記憶部２５、初期登録処理部２６、ＣＰＳ秘密鍵記憶部２７、ＣＰＳ証明書記憶部２８、及びファームウェア記憶部２９を備える。これらの要素のうちの一部が存在しなくてもよい。

所有者管理部２１は、所有者検証トークンの管理を行う。所有者管理部２１はユーザ５から所有者検証トークンを受け付けて、所有者検証トークンを所有者検証トークン記憶部２２に記憶する。また、所有者管理部２１は、レジスタラ１に所有者検証トークン等を送信し、接続先ＣＰＳサーバの情報（ＵＲＬ等）を問い合わせる。所有者管理部２１は、レジスタラ１からの指示を受けて所有者検証トークン記憶部２２に記憶された所有者検証トークンを削除してもよい。なお、所有者管理部２１は、接続すべきレジスタラ１のＵＲＬ等をあらかじめ記憶している。

所有者検証トークン記憶部２２は、所有者検証トークンを記憶する。ユーザ５は、所有者検証トークン記憶部２２の情報を読み取り可能だが、直接書き換えることはできない。所有者検証トークン記憶部２２の情報は、所有者管理部２１によって書き換えるものとする。

所有者検証トークンには、有効期限が設定されていてもよい。所有者管理部２１は、所有者検証トークンが記憶されていないとき、又は所有者検証トークンの有効期限が切れているときに、所有者検証トークン記憶部２２に新しい所有者検証トークンを記憶してもよい。

所有者検証トークン一時記憶部２３は、所有者検証トークンを一時的に記憶する記憶部であり、ユーザ５によって自由に読み取り、書き込み可能である。所有者管理部２１は、所有者検証トークン一時記憶部２３に書き込まれた所有者検証トークンを読み込み、所有者検証トークンを所有者検証トークン記憶部２２に記憶させる。

デバイス証明書記憶部２４は、デバイス証明書を記憶する。ユーザ５はデバイス証明書を読み出せるが、書き換えることはできない。デバイス証明書はデバイス２の製造時に記憶される。

デバイス秘密鍵記憶部２５はデバイス秘密鍵を記憶する。ユーザ５はデバイス秘密鍵を読み書きできない。デバイス秘密鍵はデバイス２の製造時に記憶される。所有者管理部２１は、デバイス秘密鍵記憶部２５からデバイス秘密鍵を取得できる。

初期登録処理部２６は、所有者管理部２１から接続先ＣＰＳサーバであるＣＰＳサーバ４の情報を受け取る。また、初期登録処理部２６はＣＰＳサーバ４と通信し、初期登録処理を行う。初期登録処理は、ＣＰＳサーバ４に、ＣＰＳサーバ４が有する暗号鍵（後述のサーバ秘密鍵）を用いて作成されるＣＰＳ証明書（対サーバ証明書）の発行を要求する処理を含む。

デバイス２は、ＣＰＳ秘密鍵記憶部２７を備えてもよい。ＣＰＳ秘密鍵記憶部２７は、デバイス２がＣＰＳサーバ４との認証で用いるＣＰＳ秘密鍵を記憶する。ユーザ５はＣＰＳ秘密鍵を読み書きできない。ＣＰＳ秘密鍵は、初期登録処理部２６によって書き換えられるものとする。

ＣＰＳ証明書記憶部２８は、ＣＰＳ証明書を記憶する。ユーザはＣＰＳ証明書を読み出せるが、書き換えられない。ＣＰＳ証明書は、ＣＰＳサーバ４によって発行され、初期登録処理部２６によってデバイス２のＣＰＳ証明書記憶部２８に記憶されるものとする。

ファームウェア記憶部２９は、デバイス２の動作を制御するファームウェアを記憶する記憶部であり、ユーザ５によって自由に読み取り、書き込み可能とする。ファームウェア記憶部２９は、初期登録処理部２６からの初期登録完了の通知を受け、ファームウェアを実行する。ファームウェアは、ＣＰＳサーバ４と通信して機能を果たす。

図４～図７は、第１の実施形態に係るデータベース３が記憶するデータの一例を示す図である。データベース３は、デバイステーブル（第４記憶部）、ユーザテーブル（第１記憶部）、所有登録テーブル（第２記憶部）、検証済み所有登録テーブル（第３記憶部）を有する。

図４は、デバイステーブルの一構成例である。デバイステーブルはデバイス証明書を記憶するテーブルであり、主キーとしてデバイスＩＤを有する。

図５は、ユーザテーブルの一構成例である。ユーザテーブルは、ユーザの情報と所有者検証トークンとを対応づけて記憶するテーブルであり、主キーとしてユーザＩＤを有する。ユーザテーブルは主キー以外の他の項目として、パスワードハッシュ、所有者検証トークン、所有者検証トークン有効期限を有する。

パスワードハッシュはユーザのログインパスワードのハッシュ値であり、ユーザ認証に用いられる。

所有者検証トークンはデバイスの所有者を検証するために用いる文字列であり、ユーザごとに異なるものが発行される。所有者検証トークンは、例えば、ユーザのアカウントが新規作成されたときに、レジスタラ１の所有者検証トークン発行部１１により発行される。あるいは、その他のタイミング、例えば、ユーザの指示に応じて、所有者検証トークンが発行されてもよい。

所有者検証トークン有効期限は、所有者検証トークンに設定された有効期限である。例えば、発行時点から１週間が有効期限となる。

図６は、所有登録テーブルの一構成例である。所有登録テーブルは、ユーザによって登録されたデバイスの情報（所有登録情報）と、そのデバイスが初期登録を行うべき接続先ＣＰＳサーバのＵＲＬとを記憶するテーブルである。所有登録テーブルは、主キーとして登録ＩＤを有し、他の項目としてはユーザＩＤ、デバイスＩＤを有する。ユーザＩＤ、デバイスＩＤにより、所有登録テーブルはユーザテーブル、デバイステーブルと紐付けられている。

図７は、検証済み所有登録テーブルの一構成例である。検証済み所有登録テーブルは、所有者検証が完了したデバイスのデバイスＩＤを主キーとし、当該デバイスＩＤに対応する所有登録テーブルの登録ＩＤを記憶する。すなわち、検証済み所有登録テーブルは、デバイスと、デバイスの所有者である検証済みユーザと、ユーザが指定する接続先ＣＰＳサーバとを紐付けている。

図８は、第１の実施形態におけるシステムの動作を示すシーケンス図である。最初に、レジスタラ１において、ユーザ５のユーザアカウントの作成が行われる（ステップＳ１）。ユーザアカウントの作成のための作業は、ユーザ５が行ってもよいし、所定の権限を有する者（例えば、システム管理者）が行ってもよい。ユーザアカウントの作成においては、ユーザ５からユーザＩＤとログインパスワードを送信する。レジスタラ１は、ログインパスワードからパスワードハッシュ値を算出する。レジスタラ１は、ユーザテーブルに、ユーザＩＤとパスワードハッシュとを含む新たなエントリを記憶する。

ユーザ５はレジスタラ１にログインし、所有者検証トークンの発行要求を送信する（ステップＳ２）。図２の所有者検証トークン発行部１１は、当該発行要求を受け取り、所有者検証トークンを新たに発行する（ステップＳ３）。所有者検証トークンには、有効期限が設定される。ユーザテーブルのユーザ５のエントリに、所有者検証トークンと有効期限とを記憶する。所有者検証トークン発行部１１は、ユーザ５に、発行された所有者検証トークンを提供する（ステップＳ４）。

所有者検証トークン発行部１１は、ユーザテーブルのユーザ５のエントリに、有効期限が切れていない所有者検証トークンが既に記憶されている場合、ステップＳ３の新たな所有者検証トークンの発行は省略することができる。この場合、ステップＳ４において、ユーザテーブルに記憶されている所有者検証トークンを、ユーザ５に提供してもよい。

また、ステップＳ１において、ユーザアカウントの作成と同時に所有者検証トークンを発行し、ユーザテーブルのエントリに所有者検証トークンを記憶してもよい。

次に、ユーザ５はデバイス２のデバイス証明書記憶部２４からデバイス証明書を取得する。また、ユーザ５は、接続先ＣＰＳサーバとして、ＣＰＳサーバ４を指定する。ユーザ５は、デバイス証明書と接続先ＣＰＳサーバのＵＲＬとを含む登録リクエストを、レジスタラ１に送信する（ステップＳ５）。

デバイス登録受付部１４は、登録リクエストを受け取り、デバイステーブルにデバイスＩＤとデバイス証明書とを含む新たなエントリを記憶する。また、デバイス登録受付部１４は、所有登録テーブルに、デバイステーブルに記憶したデバイスＩＤと、ユーザ５のユーザＩＤと、接続先ＣＰＳサーバのＵＲＬと、を含む新たなエントリを記憶する（ステップＳ６）。

デバイステーブルへのデバイス証明書の記憶は、事前に行われていてもよい。この場合、デバイス登録受付部１４は、登録リクエストから抽出されたデバイス証明書を有するデバイステーブルのエントリを読み出し、デバイスＩＤを取得する。そしてデバイス登録受付部１４は、所有登録テーブルに、取得したデバイスＩＤと、ユーザ５のユーザＩＤと、接続先ＣＰＳサーバのＵＲＬと、を含む新たなエントリを記憶する。

続いて、ユーザ５は、ステップＳ５で用いたデバイス証明書を、ＣＰＳサーバ４に記憶させる（ステップＳ７）。これにより、ＣＰＳサーバ４は、記憶されたデバイス証明書によって、デバイス２を認証することができる。

次に、ユーザ５はステップＳ４で取得した所有者検証トークンをデバイス２内の所有者検証トークン一時記憶部２３に書き込む（ステップＳ８）。このとき、ユーザテーブルに記憶されている所有者検証トークン有効期限を、あわせてデバイス２に書き込んでもよい。ユーザ５はデバイス２内の所有者管理部２１を起動し、書き込んだ所有者検証トークンの受け入れを依頼する。

所有者管理部２１は、所有者検証トークン記憶部２２の内容を確認する。所有者検証トークン記憶部２２に所有者検証トークンが記憶されていなかった場合、所有者管理部２１は所有者検証トークン一時記憶部２３に書き込まれた所有者検証トークンを、所有者検証トークン記憶部２２にコピーする（ステップＳ９）。ステップＳ８と同様に、有効期限を所有者検証トークン記憶部２２にあわせて記憶してもよい。

ステップＳ８において、所有者検証トークン記憶部２２に既に所有者検証トークンが記憶されている場合、所有者管理部２１は当該所有者検証トークンが有する有効期限を確認する。当該有効期限は、所有者検証トークン記憶部２２に記憶されている内容を参照して取得してもよいし、データベース３のユーザテーブルのエントリをレジスタラ１に問い合わせて取得してもよい。当該有効期限が切れている場合、所有者管理部２１は所有者検証トークン一時記憶部２３の所有者検証トークンを所有者検証トークン記憶部２２にコピー（上書き）する。当該有効期限が切れていない場合、所有者管理部２１は所有者検証トークン一時記憶部２３の所有者検証トークンをコピー（上書き）しない。この場合、所有者管理部２１はユーザ５にエラーを通知してもよい。

デバイス２の所有者管理部２１はレジスタラ１に接続し、接続先ＣＰＳサーバを問い合わせる（ステップＳ１０）。具体的には、所有者管理部２１は、所有者検証トークン記憶部２２に記憶されている所有者検証トークンと、デバイス証明書記憶部２４に記憶されているデバイス証明書とを、レジスタラ１に送信する。

ステップＳ１～Ｓ９は、レジスタラ１に対する初期の登録処理であり、２回目以降、デバイス２から接続先ＣＰＳサーバを問い合わせる際には省略できる。また、デバイス２の所有者が変更された場合、ステップＳ２～Ｓ９の処理に代わって、後述の所有権移転処理を行うこともできる。

レジスタラ１の所有者検証トークン受付部１２は、デバイス２から所有者検証トークンとデバイス証明書とを受け取る。このとき、デバイス秘密鍵の検証をしてもよい（ステップＳ１１）。デバイス秘密鍵の検証では、所有者検証トークン受付部１２は、デバイステーブルに記憶されたデバイス公開鍵のいずれかに対応するデバイス秘密鍵をデバイス２が有しているかを検証する。例えば、デバイス２からデバイス秘密鍵で暗号化された所定のデータを受信し、所有者検証トークン受付部１２はデバイス公開鍵で所定のデータを復号できるか否かを検証する。

続いて、レジスタラ１内の所有者検証部１３は、デバイス２の所有者検証を行う（ステップＳ１２）。所有者検証の処理の詳細は後述する。所有者検証が成功した場合、所有者検証部１３は所有登録テーブルから所有者検証が成功したユーザ（検証済みユーザ）についてのエントリを読み出す。所有登録テーブルのエントリからは、接続先ＣＰＳサーバとしてＣＰＳサーバ４のＵＲＬを抽出できる。所有者検証部１３は、所有登録テーブルのエントリから抽出したＣＰＳサーバ４のＵＲＬを含む、接続情報をデバイス２に送信する（ステップＳ１３）。

デバイス２内の所有者管理部２１は接続先ＣＰＳサーバのＵＲＬを初期登録処理部２６に渡し、接続先ＣＰＳサーバに対する初期登録処理を依頼する。初期登録処理部２６は、ＣＰＳ秘密鍵を生成し、生成したＣＰＳ秘密鍵をＣＰＳ秘密鍵記憶部２７に記憶する。また、初期登録処理部２６は、証明書署名リクエスト（Certificate Signing Request;ＣＳＲ）を生成する。ＣＳＲは、例えば、ＣＰＳ公開鍵と、所定のデータとを含む。また、ＣＳＲはこれら列挙した情報に対してＣＰＳ秘密鍵を用いて施した、デジタル署名を含む。初期登録処理部２６は、ＣＳＲを接続先ＣＰＳサーバに送信することで、初期登録処理の要求を行う（ステップＳ１４）。

ＣＰＳサーバ４はステップＳ７で記憶されたデバイス証明書によって、ＣＳＲを認証する。ＣＰＳサーバ４は自身の有するサーバ秘密鍵を用いてＣＰＳ証明書を発行し、発行したＣＰＳ証明書をデバイス２に提供する（ステップＳ１５）。デバイス２内の初期登録処理部２６はＣＰＳ証明書を受け取ると、当該ＣＰＳ証明書をＣＰＳ証明書記憶部２８に格納する。

図９は、所有者検証の動作を示すフローチャート図である。所有者検証は、上述の通りレジスタラ１内の所有者検証部１３で行われる。

最初に、デバイステーブルチェックを行う（ステップＳ２１）。デバイステーブルチェックにおいては、デバイス２から取得したデバイス証明書を有するエントリが、デバイステーブルに存在するか否かを確認する。図８のステップＳ５を経ている場合は、通常はデバイステーブルに該当のエントリが存在する。

デバイステーブルに該当のエントリが存在する場合、デバイステーブルのエントリからデバイスＩＤを特定する（ステップＳ２２）。特定したデバイスＩＤより、検証済み所有登録テーブルチェックを行う（ステップＳ２３）。検証済み所有登録テーブルチェックにおいては、特定したデバイスＩＤを記憶したエントリが検証済み所有登録テーブルに存在するか否かを確認する。デバイス２の所有者検証をはじめて行う場合は、通常は検証済み所有登録テーブルに該当のエントリは存在しない。

検証済み所有登録テーブルに該当のエントリが存在しない場合、所有者検証トークンの有効性チェックを行う（ステップＳ２４）。デバイス２から取得した所有者検証トークンを記憶したエントリがユーザテーブルに存在し、かつ当該エントリの有効期限が切れていないという条件を満たす場合、所有者検証トークンは有効である。条件を満たさない場合は、所有者検証トークンは無効である。

所有者検証トークンが有効である場合、ユーザテーブルの当該所有者検証トークンを記憶したエントリから、所有者検証トークンに対応するユーザＩＤを特定する（ステップＳ２５）。続いて、所有登録テーブルチェックを行う（ステップＳ２６）。所有登録テーブルチェックでは、所有登録テーブルに、ステップＳ２２で特定したデバイスＩＤと、ステップＳ２５で特定したユーザＩＤとを有するエントリが存在しているか否かを確認する。図８のステップＳ５を経ている場合は、通常は所有登録テーブルチェックに該当のエントリが存在する。

所有登録テーブルに該当のエントリが存在する場合、所有登録テーブルのエントリから、登録ＩＤを特定する（ステップＳ２７）。ステップＳ２７で特定した登録ＩＤと、ステップＳ２２で特定したデバイスＩＤとを含む新たなエントリを、検証済み所有登録テーブルに記憶する（ステップＳ２８）。これにより、所有者検証トークンに対応するユーザ５が、デバイス２の所有者として決定される。

ステップＳ２７で特定した登録ＩＤにより、所有登録テーブルから当該登録ＩＤを有するエントリを読み出す（ステップＳ２９）。これにより、所有者検証は成功として終了する

ステップＳ２３で、検証済み所有登録テーブルに該当のエントリが存在する場合、検証済み所有登録テーブルから登録ＩＤを特定する（ステップＳ３０）。ステップＳ３０で特定した登録ＩＤに基づき、ステップＳ２９で所有登録テーブルからエントリを読み出す。これにより、所有者検証は成功として終了する。

デバイステーブルに該当のエントリが存在しない場合（ステップＳ２１）、所有者検証トークンが無効である場合（ステップＳ２４）、又は所有登録テーブルチェックに該当のエントリが存在しない場合（ステップＳ２６）は、デバイス２にエラーを通知する（ステップＳ３１）。これにより、所有者検証は失敗として終了する。

このように、所有者検証では、デバイス２が記憶する所有者検証トークンを用いて、デバイス２の正当な所有者を決定する。また、所有者検証の結果として所有者が決定されたデバイスに関する情報を検証済み所有登録テーブルに記憶する。

図１０は、所有権抹消処理の動作を示すフローチャート図である。所有権抹消処理は、レジスタラ１内の所有権抹消処理部１６で行われる。以下では、ユーザ５がデバイス２の所有権を放棄する例を説明する。

最初に、ユーザ５から所有権放棄リクエストを受け取る（ステップＳ４１）。所有権放棄リクエストには放棄対象のデバイス２のデバイスＩＤが含まれる。

次に、所有者チェックを行う（ステップＳ４２）。所有者チェックにおいては、ユーザ５がデバイス２の所有者であることを確認する。検証済み所有登録テーブルに、デバイス２のデバイスＩＤを有するエントリが存在し、かつ当該エントリの登録ＩＤと紐付く所有登録テーブルのエントリに、ユーザ５のユーザＩＤが記憶されているという条件を満たす場合、ユーザ５はデバイス２の所有者である。条件を満たさない場合、ユーザ５はデバイス２の所有者ではない。

ユーザ５がデバイス２の所有者である場合、検証済み所有登録テーブルのデバイス２のデバイスＩＤを有するエントリ及び、当該検証済み所有登録テーブルのエントリの登録ＩＤを有する所有登録テーブルのエントリを削除する（ステップＳ４３）。

また、デバイス２の所有者管理部２１と通信し、所有者検証トークン記憶部２２に記憶された所有者検証トークンを削除させる（ステップＳ４４）。これにより、所有権抹消処理を終了する。

ステップＳ４４で所有者検証トークンが削除されることにより、新しいユーザがデバイス２に、新たに所有者検証トークンを記憶させることができるようになる。これにより、所有権抹消処理の直後から、所有者検証により、新しいユーザがデバイス２の所有者として扱われることができる。なお、デバイス２が所有者検証トークンを削除しなかった場合でも、所有者検証トークンの有効期限を過ぎれば、新たに所有者検証トークンを記憶（上書き）させることができる。

ユーザ５がデバイス２の所有者ではない場合（ステップＳ４２）は、ユーザ５にエラーを通知する（ステップＳ４５）。これにより、所有権抹消処理を終了する。

このように、所有権抹消処理では、レジスタラ１はデバイス２の正当な所有者からの指示に従い、デバイス２について所有権を抹消（すなわち、デバイス２についての所有者の情報を抹消）する。また、レジスタラ１はデバイス２と通信し、デバイス２の所有者検証トークン記憶部２２をクリアする。これにより、デバイス２の新たな所有者について、図９の所有者検証を直ちに実行できるようになる。例えば、所有権を抹消したユーザ５がデバイス２を他のユーザに譲り渡した場合に、当該他のユーザが自身を新たな所有者として効率的に登録できる。

図１１は、所有権移転処理の動作を示すフローチャート図である。所有権移転処理は、レジスタラ１内の所有権移転処理部１７で行われる。以下では、ユーザ５がデバイス２の所有権を他のユーザに移転する例を説明する。

最初に、ユーザ５から所有権移転リクエストを受け取る（ステップＳ５１）。所有権移転リクエストには移転対象のデバイス２のデバイスＩＤと、移転先のユーザのユーザＩＤが含まれる。

次に、所有者チェックを行う（ステップＳ５２）。所有者チェックにおいては、ユーザ５がデバイス２の所有者であることを確認する。具体的な処理内容は、所有権抹消処理における所有者チェック（図１０のステップＳ４２）と同様である。

ユーザ５がデバイス２の所有者である場合、移転先のユーザに対して所有権移転の同意チェックを行う（ステップＳ５３）。移転先のユーザからの同意を得た場合は、所有登録テーブルにデバイス２のデバイスＩＤと、移転先のユーザのユーザＩＤとを含む新たなエントリを記憶する（ステップＳ５４）。ステップＳ５３において、移転先のユーザに接続先ＣＰＳサーバの情報の提供を要求してもよい。移転先のユーザから取得した接続先ＣＰＳサーバの情報を、ステップＳ５４で合わせて記憶してもよい。

次に、検証済み所有登録テーブルから、デバイス２のデバイスＩＤを有する古いエントリを削除する。また、ステップＳ５４で記憶した所有登録テーブルのエントリの登録ＩＤと、デバイス２のデバイスＩＤとを有する新たなエントリを、検証済み所有登録テーブルに記憶する（ステップＳ５５）。

ユーザ５がデバイス２の所有者ではない場合（ステップＳ５２）、又は移転先ユーザからの同意が得られない場合（ステップＳ５３）は、ユーザ５にエラーを通知する（ステップＳ５６）。これにより、所有権移転処理を終了する。

このように、所有権移転処理では、レジスタラ１はデバイス２の移転元であるユーザ５からの指示及び、移転先のユーザの同意によって、デバイス２の所有権を移転（すなわち、デバイス２の所有者に関する情報を変更）する。検証済み所有登録テーブルにおいてユーザＩＤが更新されるため、図９の所有者検証においても、移転先のユーザがデバイス２の正当な所有者であると認められる。

以下、本実施形態に係るシステムの有効性を示すため、図１２～図１４を用いて、比較例対象となるシステム（比較例のシステム）について説明する。
図１２は、比較例のシステムの動作を示すシーケンス図である。図１２で示す動作は、図８で示す動作と比較して、所有者検証（図８のステップＳ１２）が存在しないという点で大きく異なる。所有者検証を行わないことにともない、所有者検証トークンの要求から提供までの処理（ステップＳ２～Ｓ４）及び、所有者検証トークンをデバイス２へ記憶させる処理（ステップＳ８～Ｓ９）等も、存在しない。

図１２の動作においては、ユーザ５はデバイス証明書とＣＰＳサーバ４のＵＲＬとを含む登録リクエストをレジスタラ１に送信する（ステップＳ５’）。

レジスタラ１は、ＣＰＳサーバ４のＵＲＬをデバイス証明書と紐付けて、記憶する（ステップＳ６’）。図１３は、レジスタラ１に記憶された情報の一構成例を示す図である。

続いて、ユーザ５はデバイス証明書をＣＰＳサーバ４に登録する（ステップＳ７’）。デバイス２は、デバイス証明書を提示して接続先ＣＰＳサーバをレジスタラ１に問い合わせる（ステップＳ１０’）。レジスタラ１は、図１３に示す情報から、デバイス証明書が記憶されたエントリを読み出し、ＣＰＳサーバ４のＵＲＬを取得し、デバイス２に通知する（ステップＳ１３’）。その後は、図８のステップＳ１４～Ｓ１５と同様に、初期登録処理を行う（ステップＳ１４’）。

図１４は、比較例のシステムにおけるセキュリティリスクを示すシーケンス図である。前提として、攻撃者４１は、デバイス２のデバイス証明書を入手済みである。この状況は、デバイス証明書がデバイス２の製造者によって広く公開されている場合、容易に発生しうる。また、そうでなくても、デバイス２をユーザ５に販売した販売事業者は、そのデバイス証明書を入手できる可能性が高い。

攻撃者４１の目的は、ユーザ５の所有するデバイス２を、攻撃者４１が管理する不正なＣＰＳサーバ４２に誘導し、デバイス２から情報を盗む、又は不正な遠隔操作を仕掛けることにある。

攻撃者４１は、入手したデバイス２のデバイス証明書と、ＣＰＳサーバ４２のＵＲＬと、を含む登録リクエストをレジスタラ１に送信する（ステップＳ５’’）。レジスタラ１は、ＣＰＳサーバ４２のＵＲＬを、デバイス２のデバイス証明書と紐付けて記憶する（ステップＳ６’’）。続いて、攻撃者４１はデバイス証明書をＣＰＳサーバ４２に登録する（ステップＳ７’’）。

デバイス２は、デバイス証明書を提示して接続先ＣＰＳサーバをレジスタラ１に問い合わせる（ステップＳ１０’）。レジスタラ１は、図１２と同様に、デバイス証明書が記憶されたエントリを読み出すが、当該エントリには不正なＣＰＳサーバ４２のＵＲＬが記憶されている。これにより、レジスタラ１はデバイス２に接続先ＣＰＳサーバとして、不正なＣＰＳサーバ４２のＵＲＬを通知する（ステップＳ１３’’）。

デバイス２は、不正なＣＰＳサーバ４２と初期登録処理を行う（ステップＳ１４’’）。これにより、デバイス２は、ＣＰＳサーバ４２を介して、攻撃者４１に機密情報を漏洩（ステップＳ１６’’）してしまう、又は攻撃者４１から不正な遠隔操作（ステップＳ１６’’’）を受けてしまう恐れがある。

このように、図１２で示した比較例のシステムにおいては、攻撃者４１は、デバイス２のデバイス証明書を利用し、レジスタラ１に不正な接続先サーバ（ＣＰＳサーバ４２）を記憶させることができる。この場合、レジスタラ１はデバイス２をＣＰＳサーバ４２に誘導してしまう。これにより、デバイス２はＣＰＳサーバ４２を介して、攻撃者４１に情報を漏洩する、あるいは攻撃者４１から不正な制御等を受ける恐れがある。

図１５は、第１の実施形態のシステムにおいて、図１４と同様の攻撃を受けた場合の動作を示すシーケンス図である。ユーザ５は、図８で示した例と同様に、レジスタラ１に対してユーザアカウントの生成と所有者トークンの取得する処理（ステップＳ２）、デバイス証明書と接続先ＣＰＳサーバの登録の処理（ステップＳ５）を行うことで、所有登録テーブルに正規のＣＰＳサーバ４を記憶できる（ステップＳ６）。また、ユーザ５はデバイス証明書を正規のＣＰＳサーバ４を記憶させる（ステップＳ７）。

一方、攻撃者４１もユーザ５と同様に、ステップＳ２’’及びステップＳ５’’の処理を行うことで、所有登録テーブルに不正なＣＰＳサーバ４２を登録させることができる（ステップＳ６’’）。また、攻撃者４１はデバイス証明書を不正なＣＰＳサーバ４２を記憶させる（ステップＳ７’’）。

ステップＳ６’’が行われた後の時点において、デバイステーブルにはデバイス２のデバイス証明書を有するエントリとして、攻撃者が登録したエントリとユーザ５が登録した正規のエントリとの計２件（デバイス証明書に一意制約がある場合は、１件）記憶されている。また、ユーザテーブルにはユーザ５に関するエントリと、攻撃者４１に関するエントリの、計２件のエントリが記憶されている。ユーザ５のエントリと攻撃者４１のエントリには、それぞれ異なる所有者検証トークンが記憶されている。

所有登録テーブルには、デバイス２に対しユーザ５の指定する接続先ＣＰＳサーバ（ＣＰＳサーバ４）を記憶するエントリと、デバイス２に対し攻撃者４１の指定する接続先ＣＰＳサーバ（ＣＰＳサーバ４２）が記憶するエントリの、計２件のエントリが記憶されている。

ユーザ５は、自身に発行された所有者検証トークンを、ユーザ５が所持するデバイス２に書き込み、記憶させることができる（ステップＳ８～Ｓ９）。一方、攻撃者４１は、デバイス２を所持していないため、攻撃者４１に発行された所有者検証トークンをデバイス２に書き込むことができない。

デバイス２は、ユーザ５に発行された所有者検証トークンを利用し、レジスタラ１に接続先ＣＰＳの問い合わせを行う（ステップＳ１０）。レジスタラ１は、所有者検証を実施する（ステップＳ１２）。所有者検証は、図９に示した通りに行われる。デバイス２の所有者検証がはじめて行われた場合、図９のステップＳ２４～Ｓ２７において、ユーザ５に発行された所有者検証トークンに基づき、所有登録テーブルからユーザ５についてのエントリが抽出される。また、図９のステップＳ２８により、所有者検証トークンに対応するユーザ５が、デバイス２の所有者として決定される。

ステップＳ１２の所有者検証の結果、ユーザ５の指定するＣＰＳサーバ４が、接続先ＣＰＳサーバとして抽出される。レジスタラ１は、デバイス２にＣＰＳサーバ４のＵＲＬを含む情報を通知する（ステップＳ１３）。これにより、デバイス２は正規のＣＰＳサーバ４に対して初期登録処理（ステップＳ１４）を行うことができる。

図１５に示すように、ユーザ５及び攻撃者４１は、デバイス２のデバイス証明書をレジスタラ１に提示することで、所有登録テーブルに接続先ＣＰＳサーバを指定するエントリを記憶させることができる。しかし、所有登録テーブルにエントリを記憶しただけでは、デバイス２の正当な所有者と認められない。図９に示す所有者検証を実施することで、初めてデバイス２の正当な所有者が決定され、検証済み所有登録テーブルにその結果が記憶される。

このように、第１の実施形態においては、デバイス２を所持するユーザ５に所有者検証トークンを発行し、デバイス２にユーザ５の所有者検証トークンを記憶させている。また、デバイス２が記憶する所有者検証トークンに基づいて、所有者検証を行うことで、ユーザ５をデバイス２の正当な所有者と判別することができる。これにより、レジスタラ１はユーザ５が指定する、正当な接続先ＣＰＳサーバにデバイス２を誘導することができる。また、正当な所有者ではない者がデバイスを不正に制御すること、又は自身のサーバへ誘導することを防ぐことができる。

（第２の実施形態）
ＣＰＳサーバ４へデバイス証明書を記憶させる処理を、レジスタラ１の処理に組み込んでもよい。図１６は、第２の実施形態におけるシステムの動作を示すシーケンス図である。第１の実施形態においては、ユーザ５が、ＣＰＳサーバ４へデバイス証明書を記憶させた。第２の実施形態においては、レジスタラ１が、ＣＰＳサーバ４へデバイス証明書を記憶させるという点が異なる。

図１６に示す動作では、ユーザ５がデバイス証明書をＣＰＳサーバ４に記憶させる処理はない。所有者検証（ステップＳ１２）の直後に、ＣＰＳサーバ４へデバイス証明書を記憶させる処理（ステップＳ６１）が追加されている。ステップＳ６１では、ステップＳ１３で通知する接続先ＣＰＳサーバに対し、デバイステーブルから取得したデバイス証明書を記憶させる。

このように、第２の実施形態においては、レジスタラ１がＣＰＳサーバ４へデバイス証明書を記憶させる。ＣＰＳサーバ４へのデバイス証明書の記憶を、レジスタラ１の処理に組み込むことで、ユーザ５の手間を減らすことができる。

（第３の実施形態）
第１の実施形態において、レジスタラ１は、所有者検証の機能と、デバイスを接続先ＣＰＳサーバに誘導する機能の、２つの機能を有していた。２つの機能のうち、デバイスを接続先ＣＰＳサーバに誘導する機能を、レジスタラ１から分離させてもよい。

第３の実施形態においては、ランデブーサーバが、デバイスを接続先ＣＰＳサーバに誘導する機能を有する。図１４で示した例と同様に、攻撃者が不正なＣＰＳサーバをランデブーサーバに記憶させることが考えられる。この場合において、ランデブーサーバが通知するＣＰＳサーバが、正当な所有者のＣＰＳサーバであるか否かを、デバイス側でどのように検証するかが問題となる。

第３の実施形態では、レジスタラ１が、所有者検証の結果に基づく所有証明書（Ownership Voucher）を発行し、正当な所有者が指定したＣＰＳサーバに提供する。ＣＰＳサーバは、提供された所有証明書を、デバイスに対し提示する。これにより、デバイス側は接続先ＣＰＳサーバが、正当な所有者が指定したＣＰＳサーバであると確認できる。

図１７は、第３の実施形態に係るＣＰＳの一例を示すシステム構成図である。図１７に示すシステムは、図１に示すシステムと比較して、ランデブーサーバ７を備えるという点で異なる。ランデブーサーバ７は、必ずしもレジスタラ１と物理的に分離している必要はなく、レジスタラ１の内部に設けられていてもよい。

ランデブーサーバ７は、デバイス２からの問い合わせに応答し、ＣＰＳサーバ４にデバイス２を誘導する。

レジスタラ１は、所有者検証によってユーザ５がデバイス２の正当な所有者であることを検証する。また、レジスタラ１は、ユーザ５の指定するＣＰＳサーバの要求に応じて、デバイス２の所有証明書を発行する。

図１８は、第３の実施形態に係るレジスタラ１の一構成例を示すブロック図である。図１８で示すレジスタラ１は、図２で示した構成要素に加えて、さらにユーザ鍵ペア生成部５１、所有証明書ヘッダ発行部５２、所有証明書発行部５３、所有証明書移管部５４を備える。なお、図１８では所有権抹消処理部１６及び所有権移転処理部１７について、図示を省略している。

ユーザ鍵ペア生成部５１は、ユーザごとに対となるユーザ公開鍵（第２復号鍵）とユーザ秘密鍵（第２暗号鍵）を生成し、ユーザ公開鍵とユーザ秘密鍵のペアをデータベース３に記憶する。

第３の実施形態における所有者検証部１３は、所有者検証トークンに基づき、図９で示した所有者検証を行う。所有者検証によってデバイス２の所有者（図１８の例では、ユーザ５）を決定し、所有者検証の結果として所有者の情報を所有証明書ヘッダ発行部５２に通知する。

所有証明書ヘッダ発行部５２は、所有証明書ヘッダ（第２証明書）を発行し、所有証明書ヘッダをデバイス２に送信する。所有証明書ヘッダは、例えばFIDO Device Onboard規格で定義されるデータ構造を有する。また、所有証明書ヘッダは、デバイス２の所有者のユーザ公開鍵を含む。

所有証明書発行部５３は、デバイス２から後述のＨＭＡＣ（Hash-based Message Authen-tication Code又はデバイス認証コード）値を受け付け、ＨＭＡＣ値と所有証明書ヘッダとから所有証明書を発行し、データベース３に記憶する。

所有証明書移管部５４は、ＣＰＳサーバ４からの移管リクエスト（所有証明書の移管のリクエスト）を受け付ける。所有証明書移管部５４は、データベース３に記憶されている所有証明書と、ユーザ秘密鍵で施した電子署名と、を含む移管済み所有証明書を発行する。

図１９は、第３の実施形態に係るデバイス２の一構成例を示すブロック図である。図１９で示すデバイス２は、図３で示した構成要素に加えて、所有証明書管理部６１と、デバイス認証情報記憶部６２と、ＨＭＡＣ秘密鍵記憶部６３とを備える。なお、図１９では所有者検証トークン一時記憶部２３、ＣＰＳ秘密鍵記憶部２７、ＣＰＳ証明書記憶部２８、デバイス秘密鍵記憶部２５及びデバイス証明書記憶部２４について、図示を省略している。

第３の実施形態における所有者管理部２１は、ユーザ５から所有者検証トークンを受け付けて記憶するとともに、レジスタラ１に所有者検証トークンを送信することで、所有証明書ヘッダの発行を要求する。また、所有者管理部２１は、ランデブーサーバ７に接続先ＣＰＳサーバの情報（ＵＲＬ等）を問い合わせる。なお、所有者管理部２１は、接続すべきランデブーサーバ７のＵＲＬ等をあらかじめ記憶している。

所有証明書管理部６１は、レジスタラ１と通信し、所有証明書発行に必要な処理を行う。具体的には、ＨＭＡＣ秘密鍵を生成し、ＨＭＡＣ秘密鍵記憶部６３に記憶する。また、所有証明書管理部６１は、所有証明書ヘッダとＨＭＡＣ秘密鍵とによりハッシュ値（ＨＭＡＣ値）を算出する。所有証明書管理部６１は、レジスタラ１に対し、ＨＭＡＣ値を送信することで、所有証明書の発行を要求する。なお、所有証明書管理部６１は、接続すべきレジスタラ１のＵＲＬ等をあらかじめ記憶している。

デバイス認証情報記憶部６２は、所有証明書発行に必要なデバイス認証情報（後述）を記憶する。デバイス認証情報記憶部６２対しては、所有証明書管理部６１だけが読み書きできる。

ＨＭＡＣ秘密鍵記憶部６３は、所有証明書に付与するメッセージ認証コードＨＭＡＣを生成するためのＨＭＡＣ秘密鍵を記憶する。ＨＭＡＣ秘密鍵記憶部６３は、所有証明書管理部６１だけが読み書きできる。

第３の実施形態における初期登録処理部２６は、初期登録処理を行うとともに、ＣＰＳサーバ４に移管済み所有証明書の提示を要求し、デバイス認証情報記憶部６２に記憶された情報に基づいて、移管済み所有証明書を検証する。

図２０は、第３の実施形態における所有登録テーブルの一構成例である。第３の実施形態における所有登録テーブルは、接続先ＣＰＳサーバのＵＲＬの記憶を有しないという点で、第１の実施形態と異なる。

図２１は、第３の実施形態におけるデータベース３が記憶する、ユーザ鍵テーブルの一構成例である。ユーザ鍵テーブルは、各ユーザについてユーザ秘密鍵とユーザ公開鍵のペアを記憶するテーブルであり、主キーとしてユーザＩＤを有する。

図２２は、第３の実施形態におけるデータベース３が記憶する、所有証明書テーブルの一構成例である。所有証明書テーブルは、ユーザ及びデバイスの組ごとの所有証明書を記憶するテーブルであり、主キーとして所有証明書ＩＤを有する。所有証明書テーブルは他の項目として、ユーザＩＤ、デバイスＩＤ及び所有証明書データを有する。

図２３は、第３の実施形態におけるシステムの動作を示すシーケンス図である。図２３の動作では、最初に、図８の例と同様に、ユーザ５のユーザアカウントの作成を行う（ステップＳ１）。次に、レジスタラ１内のユーザ鍵ペア生成部５１にて、ユーザ鍵ペアの発行を行う（ステップＳ７１）。ユーザ鍵テーブルに、ユーザ５のユーザ公開鍵とユーザ秘密鍵を含む新たなエントリを記憶する。

続いて、図８の例と同様に、ユーザ５はレジスタラ１に所有者検証トークンの発行を要求（ステップＳ２）する。レジスタラ１は所有者検証トークンを発行（ステップＳ３）し、ユーザ５に送信する。ユーザ５はデバイス証明書をレジスタラ１に記憶させる（ステップＳ５）とともに、所有者検証トークンをデバイス２に記憶させる（ステップＳ９）。

デバイス２の所有者管理部２１がレジスタラ１に対して所有者検証トークンを送信する。図８の例と同様だが、図２３の例ではデバイス２は接続先ＣＰＳサーバの情報の提供ではなく、所有証明書ヘッダの発行を要求する（ステップＳ７２）。

レジスタラ１の所有者検証部１３は図８の例と同様に、所有者検証を行う（ステップＳ１２）。所有者検証が成功した場合、所有者検証部１３は所有登録テーブルから検証済みユーザについてのエントリを読み出す。ユーザ鍵テーブルから、当該検証済みユーザのユーザＩＤを有するエントリを読み出す。当該ユーザ鍵テーブルのエントリからは、ユーザ公開鍵が取得できる。

所有証明書ヘッダ発行部５２は、所有者検証部１３が取得したユーザ公開鍵を含む所有証明書ヘッダを生成する。所有証明書ヘッダ発行部５２は、デバイス２に所有証明書ヘッダを発行するとともに、ＨＭＡＣ値を要求する（ステップＳ７３）。

デバイス２の所有証明書管理部６１は、レジスタラ１から所有証明書ヘッダを受け取り、所有証明書ヘッダをデバイス認証情報記憶部６２に保存する。また、所有証明書管理部６１はＨＭＡＣ秘密鍵を新たに生成し、ＨＭＡＣ秘密鍵記憶部に保存する（ステップＳ７４）。所有証明書管理部６１は、このＨＭＡＣ秘密鍵を用いて所有証明書ヘッダに対するＨＭＡＣ値を算出する。

所有証明書管理部６１は、所有証明書ヘッダとＨＭＡＣ秘密鍵とによりＨＭＡＣ値を算出する。所有証明書管理部６１は、レジスタラ１に対し、ＨＭＡＣ値を送信し、所有証明書の発行を要求する（ステップＳ７５）。

レジスタラ１の所有証明書発行部５３は、デバイス２からＨＭＡＣ値を受け付け、ＨＭＡＣ値と所有証明書ヘッダとから所有証明書を発行する（ステップＳ７６）。所有証明書発行部５３は、所有証明書と、ステップＳ１２で読み出した所有登録テーブルのエントリが有する、ユーザＩＤ及びデバイスＩＤと、を含む新たなエントリを、所有証明書テーブルに記憶する。

ユーザ５は、ＣＰＳサーバ４に対し、所有証明書の移管についてユーザ５の認可を受けていることを示すトークン（以下、認可トークン）の発行処理を行う（ステップＳ７７）。認可トークンは、例えばOAuth2規格にのっとって発行される。ユーザ５が、ＣＰＳサーバ４に所有証明書の移管について、認可処理の開始を通知する。ＣＰＳサーバ４は、ユーザ５をレジスタラ１にリダイレクトさせ、レジスタラ１へ認可することを求める。ユーザ５がレジスタラ１へ認可すると、レジスタラ１からＣＰＳサーバ４に対して認可トークンを発行する。

ＣＰＳサーバ４は、レジスタラ１に対して移管リクエストを送信する（ステップＳ７８）。移管リクエストは、認可トークンと、移管対象のデバイスＩＤと、ＣＰＳサーバ４のサーバ公開鍵と、を含む。また、移管リクエストは、これら列挙した情報に対してサーバ秘密鍵を用いて施した、デジタル署名を含む。

レジスタラ１の所有証明書移管部５４は、ＣＰＳサーバ４から移管リクエストを受け付ける。所有証明書移管部５４は、移管リクエストを検証する（ステップＳ７９）。移管リクエストの検証は、例えば認可トークンが正当であるかの検証を含む。また、所有証明書移管部５４は、移管リクエストが有するデジタル署名を、サーバ公開鍵によって検証する。さらに、所有証明書移管部５４は、所有証明書テーブルに、認可トークンで認証されたユーザのユーザＩＤと、移管リクエストが有する移管対象のデバイスＩＤと、を含むエントリが存在するかを検証する。所有証明書移管部５４は、所有証明書テーブルにエントリが存在する場合は、当該エントリから所有証明書を読み出す。

所有証明書移管部５４は、上記検証が成功した場合、読み出した所有証明書を、移管リクエスト中に含まれるサーバ公開鍵を当該所有証明書に追加することより拡張する。また、所有証明書移管部５４は、拡張した所有証明書に対してユーザ秘密鍵で電子署名を施すことで、移管済み所有証明書を作成する。所有証明書移管部５４は、ＣＰＳサーバ４に対して、作成した移管済み所有証明書を送信する（ステップＳ８０）。

ＣＰＳサーバ４は、ステップＳ８０で取得した移管済み所有証明書をランデブーサーバ７に記憶させる（ステップＳ８１）。これにより、ランデブーサーバ７は、ＣＰＳサーバ４がデバイス２の正当な接続先ＣＰＳサーバであると認識する。

デバイス２は、ランデブーサーバ７に接続先ＣＰＳサーバの情報を問い合わせる。ランデブーサーバ７は、ＣＰＳサーバ４のＵＲＬを含む、接続情報をデバイス２に通知する（ステップＳ８２）。

図８の例と同様、初期登録処理部２６は、ＣＰＳサーバ４の接続情報に基づいて、ＣＰＳサーバ４との初期登録処理を行う（ステップＳ１４）。また、初期登録処理部２６は、ＣＰＳサーバ４から移管済み所有証明書を受け取り、移管済み所有証明書を検証する（ステップＳ８３）。

移管済み所有証明書の検証においては、例えばデバイス認証情報記憶部６２に記憶されたユーザ公開鍵のハッシュ値と、移管済み所有証明書に含まれるユーザ公開鍵のハッシュ値が、一致するか否かの検証を行う。また、移管済み所有証明書に含まれるＨＭＡＣ値を、ＨＭＡＣ秘密鍵記憶部６３に記憶されるＨＭＡＣ秘密鍵によって検証する。また、移管済み所有証明書に含まれる電子署名を、ユーザ公開鍵にて検証する。移管済み所有証明書の検証が成功した場合、デバイス２はＣＰＳサーバ４を正当な接続先であると確認する。

このように、第３の実施形態では、レジスタラ１が所有者検証により、デバイス２の所有者（図２３の例では、ユーザ５）を決定し、所有証明書を発行する。さらに、ユーザ５から認可を受けたＣＰＳサーバ４に対して所有証明書を移管できる。ＣＰＳサーバ４は、所有証明書を、ランデブーサーバ７及びデバイス２に対し提示することにより、ユーザ５のＣＰＳサーバであると証明できる。

（第４の実施形態）
第３の実施形態において、レジスタラ１は、所有者検証の機能と、所有証明書の発行機能の、２つの機能を有していた。第４の実施形態では、レジスタラ１のこれら２つの機能のうち所有証明書の発行機能を分離して、所有証明書の発行機能を有する所有証明書発行サーバを新たに設ける。

図２４は、第４の実施形態に係るＣＰＳの一例を示すシステム構成図である。図２４に示すシステムは、図１７に示すシステムと比較して、所有者管理サーバ７１、所有証明書発行サーバ（証明書発行装置）７２、所有者データベース７３、及び所有証明書データベース７４を備えるという点で異なる。所有者管理サーバ７１及び所有者データベース７３は、所有証明書の発行機能が取り除かれたレジスタラ１及び当該レジスタラ１が使用するデータベース３に、それぞれ対応する。

所有者管理サーバ７１と所有証明書発行サーバ７２は、必ずしも物理的に分離している必要はなく、所有者管理サーバ７１の内部に所有証明書発行サーバ７２に含めてもよい。また、所有者管理サーバ７１と所有証明書発行サーバ７２のいずれかが、ランデブーサーバ７を兼ねてもよい。

所有者管理サーバ７１は、デバイスの所有者検証と管理の機能を有する。また、所有者検証によってユーザ５がデバイス２の正当な所有者であることを検証する。

所有証明書発行サーバ７２は、ユーザ５の指定するＣＰＳサーバの要求に応じて、デバイス２の所有証明書を発行する。その際、所有者管理サーバ７１と通信して、デバイス２の正当な所有者を確認する。

所有者データベース７３は、所有者管理サーバ７１が所有者に関する情報を記憶・管理するための記憶装置である。

所有証明書データベース７４は、所有証明書発行サーバ７２が所有証明書に関する情報を記憶・管理するための記憶装置である。

図２５は、第４の実施形態に係る所有者管理サーバ７１の一構成例を示すブロック図である。図２５で示す所有者管理サーバ７１の構成は、基本的には図２に示すレジスタラ１の構成に準じる。図２５で示す所有者管理サーバ７１は、図２の例と比較して、接続先ＣＰＳサーバ通知部１５を備えていない。また、所有者証明トークン発行部（第２トークン発行部）８１及びデバイス詳細情報開示部（情報開示部）８２を備えるという点が異なる。

所有者検証部１３は、所有者検証トークンに基づき、図９で示した所有者検証を行う。所有者検証によってデバイス２の所有者（図２５の例では、ユーザ５）を決定する。

所有者証明トークン発行部８１は、所有者検証部１３による所有者検証の結果を取得し、デバイス２に対して、デバイス２の正当な所有者を示す所有者証明トークン（第２トークン）を発行する。

デバイス詳細情報開示部８２は、所有証明書発行サーバ７２に対し、所有者証明トークンの検証に必要なデータを提供する。具体的には、デバイス詳細情報開示部８２は、所有証明書発行サーバ７２から所有者証明トークンを受け取り、所有者証明トークンに紐づくデバイス２の所有者のユーザＩＤと、デバイス２のデバイス証明書とを開示する。

図２６は、第４の実施形態に係る所有証明書発行サーバ７２の一構成例を示すブロック図である。図２６で示す所有証明書発行サーバ７２は、図１８で示すレジスタラ１の構成要素である、ユーザ鍵ペア生成部５１、所有証明書ヘッダ発行部５２、所有証明書発行部５３、及び所有証明書移管部５４を備える。また、ユーザアカウント作成リクエスト受付部９１、所有者証明トークン受付部（第２トークン受付部）９２、及び所有者証明トークン検証部９３（第２トークン検証部）を、新たに備える。

ユーザアカウント作成リクエスト受付部９１は、ユーザ５からの要求により、所有者管理サーバ７１からユーザ５の情報を受け取り、ユーザ鍵ペアの生成をユーザ鍵ペア生成部５１に指示する。

所有者証明トークン受付部９２は、デバイス２から所有者証明トークンと、デバイス証明書を受け付けるとともに、デバイス２から所有者証明トークンの検証要求を受け付ける。

所有者証明トークン検証部９３は、所有者管理サーバ７１から必要なデータ（例えば、所有者証明トークンの有効か否かの情報、デバイス２の情報、デバイス２の所有者の情報）を受け取り、所有者証明トークンを検証し、検証の結果として所有者の情報を所有証明書ヘッダ発行部５２に通知する。

図２７は、第４の実施形態に係るデバイス２の一構成例を示すブロック図である。図２７で示すデバイス２は、図１９で示した構成要素に加えて、所有者証明トークン記憶部１０１を備える。

第４の実施形態におけるデバイス２の所有者管理部２１は、ユーザ５から所有者検証トークンを受け付けて記憶するとともに、所有者管理サーバ７１に所有者検証トークンを送信することにより、所有者証明トークンの発行を要求する。所有者管理部２１は、自身の接続すべき所有者管理サーバのＵＲＬなどをあらかじめ記憶している。

第４の実施形態におけるデバイス２の所有証明書管理部６１は、所有証明書発行サーバ７２と通信し、所有証明書発行に必要な処理を行う。具体的には、所有証明書発行サーバ７２に対し、ＨＭＡＣ値を送信し、所有証明書の発行を要求する。なお、所有証明書管理部６１は、接続すべき所有証明書発行サーバ７２のＵＲＬ等をあらかじめ記憶している。

所有者証明トークン記憶部１０１は、所有者管理サーバ７１から受け取る所有者証明トークンを記憶する。所有者証明トークン記憶部１０１には所有者管理部２１のみ書き込むことができ、所有者管理部２１と所有証明書管理部６１だけが所有者証明トークン記憶部１０１から読み出すことができる。

第４の実施形態における所有者データベース７３は、第１の実施形態と同様のデバイステーブル、ユーザテーブル、検証済み所有登録テーブルを有し、また、第３の実施形態と同様の所有登録テーブル（図２０参照）を有する。さらに所有者データベース７３は、所有者証明トークンテーブルを新たに有する。

図２８は、所有者証明トークンテーブルの一構成例である。所有者証明トークンテーブルは、デバイスごとの所有者証明トークンを記憶するテーブルであり、主キーとして所有者証明トークンのトークン文字列を有する。所有証明書テーブルは他の項目として、デバイスＩＤ及び所有者証明トークンの有効期限を有する。

第４の実施形態における所有証明書データベース７４は、第３の実施形態と同様のユーザ鍵テーブル（図２１参照）、所有証明書テーブル（図２２参照）を有する。

図２９は、第４の実施形態におけるシステムの動作を示すシーケンス図である。図２９の動作では、最初に、図８の例と同様に、所有者管理サーバ７１においてユーザ５のユーザアカウントの作成を行う（ステップＳ１）。続いて、ユーザ５は所有者管理サーバ７１に所有者検証トークンの発行を要求（ステップＳ２）する。所有者管理サーバ７１は所有者検証トークンを発行（ステップＳ３）し、所有者検証トークンをユーザ５に送信する。ユーザ５はデバイス証明書を所有者管理サーバ７１に記憶させる（ステップＳ５）。

次に、ユーザ５は所有証明書発行サーバ７２にユーザアカウントの作成リクエストを送信する（ステップＳ９１）。

所有証明書発行サーバ７２のユーザアカウント作成リクエスト受付部９１は、所有者管理サーバ７１と通信し、ユーザアカウント作成リクエストの送信者のユーザ５のユーザＩＤを確認する。これは例えば、OpenID Connect規格を用いて実現される。次に、所有証明書発行サーバ７２のユーザ鍵ペア生成部５１は、所有証明書データベース７４のユーザ鍵テーブルに、ユーザ５のユーザ秘密鍵とユーザ公開鍵を含む新たなエントリを記憶する（ステップＳ９２）。

ユーザ５は、図８の例と同様に、所有者検証トークンをデバイス２に記憶させる（ステップＳ９）。デバイス２内の所有者管理部２１が所有者管理サーバ７１に対して所有者検証トークンを送信する。この動作は、図８の例と同様だが、図２９の例ではデバイス２は接続先ＣＰＳサーバの情報の提供ではなく、所有者証明トークンの発行を要求する（ステップＳ９３）。

所有者管理サーバ７１の所有者検証部１３は図８の例と同様に、所有者検証を行う（ステップＳ１２）。所有者検証が成功した場合、所有者検証部１３は所有登録テーブルから検証が成功したユーザ（検証済みユーザ）についてのエントリを読み出す。

所有者管理サーバ７１はデバイス２について新たに所有者証明トークンを発行し、所有者証明トークンを所有者証明トークンテーブルに保存する。所有者証明トークンの有効期限は、例えば発行時から２４時間後に設定する。所有者管理サーバ７１は、発行した所有者証明トークンをデバイス２に返信する（ステップＳ９４）。

デバイス２の所有者管理部２１は所有者証明トークンを受け取り、所有者証明トークン記憶部１０１に保存する（ステップＳ９５）。所有証明書管理部６１は所有証明書発行サーバ７２に所有者証明トークン及びデバイス証明書を提示し、所有証明書ヘッダの発行を要求する（ステップＳ９６）。

所有証明書発行サーバ７２の所有者証明トークン受付部９２は、デバイス２から所有者証明トークン及びデバイス証明書を受け取る。所有者証明トークン検証部９３は、後述の所有者証明トークン検証を、所有者管理サーバ７１と連携して行う（ステップＳ９７）。なお、所有者証明トークン受付部９２が受け取ったデバイス証明書は、本実施形態においては第１デバイス証明書と呼ぶ。

所有者証明トークン検証部９３の所有者証明トークン検証が成功した場合、所有証明書ヘッダ発行部５２はデバイス２からの要求に基づき、所有証明書ヘッダを発行する（ステップＳ７３）。

デバイス２は、図２３の例と同様に、ＨＭＡＣ秘密鍵を新たに生成する（ステップＳ７４）。また、デバイス２は、ＨＭＡＣ値を所有証明書発行サーバ７２に送信する（ステップＳ７５）。所有証明書発行サーバ７２は、所有証明書を発行する（ステップＳ７６）。

ユーザ５は、図２３の例と同様に、ＣＰＳサーバ４に対し、認可トークンの発行処理を行う（ステップＳ７７）。認可トークンは、OAuth2規格にのっとりユーザ５から認可を受けた所有者管理サーバ７１が発行してもよい。ＣＰＳサーバ４は、所有証明書発行サーバ７２に対して移管リクエストを送信する（ステップＳ７８）。

所有証明書発行サーバ７２は、移管リクエストを検証する（ステップＳ７９）。上記の通り、所有者管理サーバ７１が認可トークンを発行する場合、ステップＳ７９の検証において認可トークンを所有者管理サーバ７１に送信し、認可トークンがユーザ５による認可を示すものか否かを確認してもよい。

続いて、所有証明書発行サーバ７２は、ＣＰＳサーバ４に対して、作成した移管済み所有証明書を送信する（ステップＳ８０）。ＣＰＳサーバ４は、移管済み所有証明書をランデブーサーバ７に記憶させる（ステップＳ８１）。デバイス２は、ランデブーサーバ７からＣＰＳサーバ４の接続情報を取得する（ステップＳ８２）。デバイス２は、ＣＰＳサーバ４との初期登録処理及び、移管済み所有証明書の検証を行う（ステップＳ８３）。

図３０は、所有者証明トークン検証の動作を示すフローチャート図である。所有者証明トークン検証は、所有証明書発行サーバ７２と所有者管理サーバ７１が連携して行う。まず、所有証明書発行サーバ７２の所有者証明トークン検証部９３が、所有者管理サーバ７１に、デバイス２から取得した所有者証明トークンを送信する（ステップＳ１０１）。

ステップＳ１１１～Ｓ１１７の処理は、所有者管理サーバ７１のデバイス詳細情報開示部８２が行う。まず、所有証明書発行サーバ７２から受け取った所有者証明トークンのチェックを行う（ステップＳ１１１）。所有者証明トークンのチェックにおいては、当該所有者証明トークンを有する所有者証明トークンテーブルのエントリが存在し、かつ、当該エントリの有効期限が現在日時以降であるという条件を満たすか否かを検証する。当該条件を満たす場合、所有者証明トークンは有効であり、満たさない場合、所有者証明トークンは無効である。

所有者証明トークンが有効であった場合、所有者証明テーブルのエントリから、デバイスＩＤを特定する（ステップＳ１１２）。

続いて、検証済み所有登録テーブルチェックを行う（ステップＳ１１３）。本チェックにおいては、ステップＳ１１２で特定したデバイスＩＤを有する、検証済み所有登録テーブルのエントリが存在するか否かを確認する。デバイス２についての所有者検証を経ている場合は、通常はエントリが存在する。

検証済み所有登録テーブルに、該当のエントリが存在する場合、当該エントリから登録ＩＤを特定する（ステップＳ１１４）。

次に、特定した登録ＩＤを有する所有登録テーブルのエントリから、デバイス２の所有者（ユーザ５）のユーザＩＤが特定できる（ステップＳ１１５）。

続いて、特定したデバイスＩＤを有するデバイステーブルのエントリから、デバイス証明書を取得する。デバイス証明書と、ステップＳ１１５で特定したユーザＩＤとを、所有証明書発行サーバに送信する（ステップＳ１１６）。

所有者証明トークンが無効であった場合（ステップＳ１１１）、又は、検証済み所有登録テーブルに該当のエントリが存在しなかった場合（ステップＳ１１３）は、所有証明書発行サーバ７２にエラーを通知する（ステップＳ１１７）。

ステップＳ１０２～Ｓ１０５の処理は、所有証明書発行サーバ７２の所有者証明トークン検証部９３が行う。所有者管理サーバ７１からデバイス証明書とユーザＩＤを受け取っている場合は、デバイス証明書一致チェックを行う（ステップＳ１０２）。デバイス証明書一致チェックにおいては、所有者管理サーバ７１から受け取ったデバイス証明書と、デバイス２から受け取った第１デバイス証明書が、一致しているか否かを確認する。

デバイス証明書が一致している場合、ユーザチェックを行う（ステップＳ１０３）。ユーザチェックにおいては、所有者管理サーバ７１から受け取ったユーザＩＤを有するユーザ鍵テーブルのエントリが、存在するか否かを確認する。ユーザ５から所有証明書発行サーバ７２へユーザアカウントの作成リクエストを送信している場合、通常はエントリが存在する。

ユーザ鍵テーブルに該当のエントリが存在する場合、当該エントリからユーザ公開鍵を取得する（ステップＳ１０４）。所有者証明トークン検証は成功として終了する。

所有者管理サーバ７１からエラーの通知があった場合（ステップＳ１１７）、デバイス証明書が不一致であった場合（ステップＳ１０２）、又はユーザ鍵テーブルに該当のエントリが存在しない場合（ステップＳ１０３）は、デバイス２にエラーを通知する（ステップＳ１０５）。所有者証明トークン検証は失敗として終了する。

このように、第４の実施形態では、所有証明書の発行を行う所有証明書発行サーバ７２が、所有者検証を行う所有者管理サーバ７１と、所有者証明トークンを用いて連携することができる。これにより、所有証明書発行サーバ７２は、デバイス２の正当な所有者（図２９では、ユーザ５）に対して所有証明書を発行できる。

また、第４の実施形態に対して、他の初期登録手法を組み合わせることも可能である。例えば、デバイス２に対してＣＰＳ証明書を発行するサーバを立ち上げ、そのサーバが所有者管理サーバ７１の発行した所有者証明トークンを受け付けるようにすることもできる。この構成によれば、デバイス２の正当な所有者であるユーザ５が、デバイス２に対してＣＰＳ証明書を発行できるようになる。

なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。

［付記］
［項目１］
ユーザのトークン発行要求に応じて第１トークンを発行する第１トークン発行部と、
前記ユーザの情報と前記第１トークンとを対応づけて記憶する第１記憶部と、
前記ユーザが所有するデバイスの所有登録情報を記憶する第２記憶部と、
前記デバイスから提供される前記第１トークンを受け付ける第１トークン受付部と、
前記第１トークンを提供した前記デバイスの情報が前記第２記憶部に記憶されており、前記第１トークン受付部により受け付けられた前記第１トークンが前記第１記憶部における前記第１トークンに一致するかの検証を含む所有者検証を行い、所有者検証が成功した前記第１トークンに対応する前記ユーザを前記デバイスの所有者として決定する所有者検証部と、
前記所有者が決定された前記デバイスの情報を含む検証済みデータを記憶する第３記憶部と、を備える情報処理装置。
［項目２］
前記第１トークンは、有効期限を有し、
前記所有者検証は、前記第１トークンの前記有効期限に基づく検証を含む、
項目１に記載の情報処理装置。
［項目３］
前記ユーザからの前記デバイスの第１復号鍵を含むデバイス証明書を受け付けるデバイス登録受付部と、
前記デバイス登録受付部が受け付けた前記デバイス証明書を含むデータを記憶する第４記憶部を備え、
前記第１トークン受付部は、前記デバイスが、前記第４記憶部に記憶される前記デバイス証明書に含まれる前記第１復号鍵に対応する第１暗号鍵を有するか否かの検証に基づいて、前記デバイスの提供する前記第１トークンを受け付ける、
項目１又は２に記載の情報処理装置。
［項目４］
前記デバイスに対して、接続先のサーバの情報を通知する接続先通知部を備え、
前記第２記憶部は、前記接続先のサーバの情報を前記所有者が決定された前記デバイスの前記情報と関連づけて記憶する、
項目１～３のいずれか一項に記載の情報処理装置。
［項目５］
前記所有者検証が成功した前記ユーザからの要求によって、前記第３記憶部の前記検証済みデータに関する情報を削除する抹消処理部をさらに備える、
項目１～４のいずれか一項に記載の情報処理装置。
［項目６］
前記所有者検証が成功した前記ユーザからの要求と、新たなユーザからの要求とに基づいて、前記デバイスの所有者を前記新たなユーザに変更する処理を行うことにより、前記第３記憶部の前記検証済みデータを前記新たなユーザに関する情報に更新する、移管処理部をさらに備える、
項目１～５のいずれか一項に記載の情報処理装置。
［項目７］
前記ユーザごとに、対となる第２復号鍵と第２暗号鍵を生成するユーザ鍵ペア生成部と、
前記デバイスに対し、前記第２復号鍵を含む所有証明書ヘッダを発行する所有証明書ヘッダ発行部と、
前記デバイスからデバイス認証コードを受け付け、前記所有証明書ヘッダと前記デバイス認証コードに基づいて、所有証明書を発行する所有証明書発行部と、
前記所有者が決定された前記デバイスの接続先のサーバに対し、前記所有証明書と、前記第２暗号鍵で暗号化されたデータとを含む移管済み所有証明書を発行する所有証明書移管部を備える、
項目１～６のいずれか一項に記載の情報処理装置。
［項目８］
前記デバイスからの要求を受けて、前記デバイスの所有者である前記ユーザを示す第２トークンを発行する第２トークン発行部を備える、
項目１～７のいずれか一項に記載の情報処理装置。
［項目９］
前記ユーザからの要求により前記ユーザの情報を含むユーザアカウントを作成するユーザアカウント作成リクエスト受付部と
前記ユーザからの前記デバイスの第１復号鍵を含むデバイス証明書を受け付けるデバイス登録受付部と、
前記デバイスから前記第２トークンの検証要求と前記デバイスが保持している第１デバイス証明書とを受け付ける第２トークン受付部と、
前記第２トークンに関連する前記ユーザを含む情報と前記デバイス証明書とを前記第２トークンの検証用に前記第２トークン検証部に開示する情報開示部と、
前記情報開示部により開示される前記ユーザを含む情報及び前記デバイス証明書と、前記第１デバイス証明書と前記ユーザアカウントの前記ユーザの情報とに基づき、前記第２トークンを検証する第２トークン検証部と、
を備える、
項目８に記載の情報処理装置。
［項目１０］
項目２に記載の情報処理装置と、
前記デバイスと、を備え、
前記デバイスは、前記第１トークンを含むデータを記憶する第５記憶部と、前記第１トークンを、前記情報処理装置に送信する所有者管理部、を備える、
情報処理システム。
［項目１１］
前記所有者管理部は、前記第５記憶部に記憶された第１トークンの前記有効期限が切れているとき又は、前記第５記憶部に第１トークンが記憶されていないときにのみ、前記第５記憶部に第１トークンを含むデータを記憶させる、
項目１０に記載の情報処理システム。
［項目１２］
前記デバイスは、接続先のサーバに対し初期登録処理を行う初期登録処理部を備え、
前記情報処理装置は、前記デバイスに、前記接続先のサーバの情報を通知する、
項目１０又は１１に記載の情報処理システム。
［項目１３］
前記初期登録処理は、前記接続先のサーバに対し前記サーバの有する暗号鍵によって作成される対サーバ証明書の発行を要求する処理を含む、
項目１２に記載の情報処理システム。
［項目１４］
ユーザごとに、対となる第２復号鍵と第２暗号鍵を生成するユーザ鍵ペア生成部と、
前記デバイスに対し、前記第２復号鍵を含む所有証明書ヘッダを発行する所有証明書ヘッダ発行部と、
前記デバイスからデバイス認証コードを受け付け、前記所有証明書ヘッダと前記デバイス認証コードに基づいて、所有証明書を発行する所有証明書発行部と、
前記所有者が決定された前記デバイスの接続先のサーバに対し、前記所有証明書と、前記第２暗号鍵で暗号化されたデータとを含む移管済み所有証明書を発行する移管済み所有証明書発行部を有する、
証明書発行装置を備える、
項目１０～１３のいずれか一項に記載の情報処理システム。
［項目１５］
前記情報処理装置は、
前記デバイスからの要求を受けて、前記デバイスの所有者である前記ユーザを示す第２トークンを発行する第２トークン発行部と、
前記ユーザからの前記デバイスの第１復号鍵を含むデバイス証明書を受け付けるデバイス登録受付部と、
前記第２トークンに関連する前記ユーザを含む情報と前記デバイス証明書とを開示する情報開示部を備え、
前記証明書発行装置は、
前記ユーザからの要求により前記ユーザの情報を含むユーザアカウントを作成するユーザアカウント作成リクエスト受付部と、
前記デバイスから、前記第２トークンの検証要求と前記デバイスが保持している第１デバイス証明書とを受け付ける第２トークン受付部と、
前記情報開示部により開示される前記ユーザを含む情報及び前記デバイス証明書と、前記第１デバイス証明書及び前記ユーザアカウントの前記ユーザの情報とに基づき、前記第２トークンを検証する第２トークン検証部と、を備える、
項目１４に記載の情報処理システム。
［項目１６］
ユーザのトークン発行要求に応じて第１トークンを発行するステップと、
前記ユーザの情報と前記第１トークンとを対応づけて第１記憶部に記憶するステップと、
前記ユーザが所有するデバイスの所有登録情報を第２記憶部に記憶するステップと、
前記デバイスから提供される第１トークンを受け付けるステップと、
前記第１トークンを提供した前記デバイスの情報が前記第２記憶部に記憶されており、受け付けた前記第１トークンが前記第１記憶部における前記第１トークンに一致するかの検証を含む所有者検証を行い、所有者検証が成功した前記第１トークンに対応する前記ユーザを前記デバイスの所有者として決定するステップと、
前記所有者が決定された前記デバイスの情報を含む検証済みデータを第３記憶部に記憶するするステップと、
をコンピュータに実行させるための情報処理プログラム。

１ レジスタラ、２ デバイス、３ データベース、４ ＣＰＳサーバ、５ ユーザ、６ ネットワーク、７ ランデブーサーバ、１１ 所有者検証トークン発行部、１２ 所有者検証トークン受付部、１３ 所有者検証部、１４ デバイス登録受付部、１５ 接続先ＣＰＳサーバ通知部、１６ 所有権抹消処理部、１７ 所有権移転処理部、２１ 所有者管理部、２２ 所有者検証トークン記憶部、２３ 所有者検証トークン一時記憶部、２４ デバイス証明書記憶部、２５ デバイス秘密鍵記憶部、２６ 初期登録処理部、２７ ＣＰＳ秘密鍵記憶部、２８ ＣＰＳ証明書記憶部、２９ ファームウェア記憶部、４１ 攻撃者、４２ ＣＰＳサーバ、５１ ユーザ鍵ペア生成部、５２ 所有証明書ヘッダ発行部、５３ 所有証明書発行部、５４ 所有証明書移管部、６１ 所有証明書管理部、６２ デバイス認証情報記憶部、６３ ＨＭＡＣ秘密鍵記憶部、７１ 所有者管理サーバ、７２ 所有証明書発行サーバ、７３ 所有者データベース、７４ 所有証明書データベース、８１ 所有者証明トークン発行部、８２ デバイス詳細情報開示部、９１ ユーザアカウント作成リクエスト受付部、９２ 所有者証明トークン受付部、９３ 所有者証明トークン検証部、１０１ 所有者証明トークン記憶部

Claims (16)

1. ユーザのトークン発行要求に応じて第１トークンを発行する第１トークン発行部と、
   前記ユーザの情報と前記第１トークンとを対応づけて記憶する第１記憶部と、
   前記ユーザが所有するデバイスの所有登録情報を記憶する第２記憶部と、
   前記デバイスから提供される前記第１トークンを受け付ける第１トークン受付部と、
   前記第１トークンを提供した前記デバイスの情報が前記第２記憶部に記憶されており、前記第１トークン受付部により受け付けられた前記第１トークンが前記第１記憶部における前記第１トークンに一致するかの検証を含む所有者検証を行い、所有者検証が成功した前記第１トークンに対応する前記ユーザを前記デバイスの所有者として決定する所有者検証部と、
   前記所有者が決定された前記デバイスの情報を含む検証済みデータを記憶する第３記憶部と、を備える情報処理装置。
2. 前記第１トークンは、有効期限を有し、
   前記所有者検証は、前記第１トークンの前記有効期限に基づく検証を含む、
   請求項１に記載の情報処理装置。
3. 前記ユーザからの前記デバイスの第１復号鍵を含むデバイス証明書を受け付けるデバイス登録受付部と、
   前記デバイス登録受付部が受け付けた前記デバイス証明書を含むデータを記憶する第４記憶部を備え、
   前記第１トークン受付部は、前記デバイスが、前記第４記憶部に記憶される前記デバイス証明書に含まれる前記第１復号鍵に対応する第１暗号鍵を有するか否かの検証に基づいて、前記デバイスの提供する前記第１トークンを受け付ける、
   請求項１又は２に記載の情報処理装置。
4. 前記デバイスに対して、接続先のサーバの情報を通知する接続先通知部を備え、
   前記第２記憶部は、前記接続先のサーバの情報を前記所有者が決定された前記デバイスの前記情報と関連づけて記憶する、
   請求項１又は２に記載の情報処理装置。
5. 前記所有者検証が成功した前記ユーザからの要求によって、前記第３記憶部の前記検証済みデータに関する情報を削除する抹消処理部をさらに備える、
   請求項１又は２に記載の情報処理装置。
6. 前記所有者検証が成功した前記ユーザからの要求と、新たなユーザからの要求とに基づいて、前記デバイスの所有者を前記新たなユーザに変更する処理を行うことにより、前記第３記憶部の前記検証済みデータを前記新たなユーザに関する情報に更新する、移管処理部をさらに備える、
   請求項１又は２に記載の情報処理装置。
7. 前記ユーザごとに、対となる第２復号鍵と第２暗号鍵を生成するユーザ鍵ペア生成部と、
   前記デバイスに対し、前記第２復号鍵を含む所有証明書ヘッダを発行する所有証明書ヘッダ発行部と、
   前記デバイスからデバイス認証コードを受け付け、前記所有証明書ヘッダと前記デバイス認証コードに基づいて、所有証明書を発行する所有証明書発行部と、
   前記所有者が決定された前記デバイスの接続先のサーバに対し、前記所有証明書と、前記第２暗号鍵で暗号化されたデータとを含む移管済み所有証明書を発行する所有証明書移管部を備える、
   請求項１又は２に記載の情報処理装置。
8. 前記デバイスからの要求を受けて、前記デバイスの所有者である前記ユーザを示す第２トークンを発行する第２トークン発行部を備える、
   請求項１又は２に記載の情報処理装置。
9. 前記ユーザからの要求により前記ユーザの情報を含むユーザアカウントを作成するユーザアカウント作成リクエスト受付部と
   前記ユーザからの前記デバイスの第１復号鍵を含むデバイス証明書を受け付けるデバイス登録受付部と、
   前記デバイスから前記第２トークンの検証要求と前記デバイスが保持している第１デバイス証明書とを受け付ける第２トークン受付部と、
   前記第２トークンに関連する前記ユーザを含む情報と前記デバイス証明書とを開示する情報開示部と、
   前記情報開示部により開示される前記ユーザを含む情報及び前記デバイス証明書と、前記第１デバイス証明書と前記ユーザアカウントの前記ユーザの情報とに基づき、前記第２トークンを検証する第２トークン検証部と、
   を備える、
   請求項８に記載の情報処理装置。
10. 請求項２に記載の情報処理装置と、
    前記デバイスと、を備え、
    前記デバイスは、前記第１トークンを含むデータを記憶する第５記憶部と、前記第１トークンを、前記情報処理装置に送信する所有者管理部、を備える、
    情報処理システム。
11. 前記所有者管理部は、前記第５記憶部に記憶された第１トークンの前記有効期限が切れているときに、前記第５記憶部に新たな第１トークンを記憶させる、
    請求項１０に記載の情報処理システム。
12. 前記デバイスは、接続先のサーバに対し初期登録処理を行う初期登録処理部を備え、
    前記情報処理装置は、前記デバイスに、前記接続先のサーバの情報を通知する、
    請求項１０に記載の情報処理システム。
13. 前記初期登録処理は、前記接続先のサーバに対し前記サーバの有する暗号鍵によって作成される対サーバ証明書の発行を要求する処理を含む、
    請求項１２に記載の情報処理システム。
14. ユーザごとに、対となる第２復号鍵と第２暗号鍵を生成するユーザ鍵ペア生成部と、
    前記デバイスに対し、前記第２復号鍵を含む所有証明書ヘッダを発行する所有証明書ヘッダ発行部と、
    前記デバイスからデバイス認証コードを受け付け、前記所有証明書ヘッダと前記デバイス認証コードに基づいて、所有証明書を発行する所有証明書発行部と、
    前記所有者が決定された前記デバイスの接続先のサーバに対し、前記所有証明書と、前記第２暗号鍵で暗号化されたデータとを含む移管済み所有証明書を発行する移管済み所有証明書発行部を有する、
    証明書発行装置を備える、
    請求項１０に記載の情報処理システム。
15. 前記情報処理装置は、
    前記デバイスからの要求を受けて、前記デバイスの所有者である前記ユーザを示す第２トークンを発行する第２トークン発行部と、
    前記ユーザからの前記デバイスの第１復号鍵を含むデバイス証明書を受け付けるデバイス登録受付部と、
    前記第２トークンに関連する前記ユーザを含む情報と前記デバイス証明書とを開示する情報開示部を備え、
    前記証明書発行装置は、
    前記ユーザからの要求により前記ユーザの情報を含むユーザアカウントを作成するユーザアカウント作成リクエスト受付部と、
    前記デバイスから、前記第２トークンの検証要求と前記デバイスが保持している第１デバイス証明書とを受け付ける第２トークン受付部と、
    前記情報開示部により開示された前記ユーザを含む情報及び前記デバイス証明書と、前記第１デバイス証明書及び前記ユーザアカウントの前記ユーザの情報とに基づき、前記第２トークンを検証する第２トークン検証部と、を備える、
    請求項１４に記載の情報処理システム。
16. ユーザのトークン発行要求に応じて第１トークンを発行するステップと、
    前記ユーザの情報と前記第１トークンとを対応づけて第１記憶部に記憶するステップと、
    前記ユーザが所有するデバイスの所有登録情報を第２記憶部に記憶するステップと、
    前記デバイスから提供される第１トークンを受け付けるステップと、
    前記第１トークンを提供した前記デバイスの情報が前記第２記憶部に記憶されており、受け付けた前記第１トークンが前記第１記憶部における前記第１トークンに一致するかの検証を含む所有者検証を行い、所有者検証が成功した前記第１トークンに対応する前記ユーザを前記デバイスの所有者として決定するステップと、
    前記所有者が決定された前記デバイスの情報を含む検証済みデータを第３記憶部に記憶するステップと、
    をコンピュータに実行させるための情報処理プログラム。