特許 7559344 認可に基づくリソースアクセス制御システム、セキュアなコンポーネント、デバイス及び認可に基づくリソースアクセス制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-24

(45)【発行日】2024-10-02

(54)【発明の名称】認可に基づくリソースアクセス制御システム、セキュアなコンポーネント、デバイス及び認可に基づくリソースアクセス制御方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20240925BHJP

   G06F 21/78 20130101ALI20240925BHJP

   G06F 21/33 20130101ALI20240925BHJP

【ＦＩ】

G06F21/62

G06F21/78

G06F21/33

【請求項の数】 18

(21)【出願番号】P 2020072994

(22)【出願日】2020-04-15

(65)【公開番号】P2021170228

(43)【公開日】2021-10-28

【審査請求日】2023-02-21

【前置審査】

(73)【特許権者】

【識別番号】000002897

【氏名又は名称】大日本印刷株式会社

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】浅野 正徳

【審査官】吉田 歩

(56)【参考文献】

【文献】特表２０１７－５３７４２１（ＪＰ，Ａ）

【文献】特表２０１７－５０３２８９（ＪＰ，Ａ）

【文献】国際公開第２０２０／００９６５９（ＷＯ，Ａ１）

【文献】国際公開第２０２０／０５５５７４（ＷＯ，Ａ１）

【文献】特表２０１５－５３０８０２（ＪＰ，Ａ）

【文献】特開２０１７－１５７９８４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ ２１／７８

Ｇ０６Ｆ ２１／３３

(57)【特許請求の範囲】

【請求項1】

ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、
前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、
クライアントが動作するデバイスと
を備え、
前記デバイスは、
前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報を記憶するセキュアなコンポーネントを備え、
前記クライアントは、
前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、
前記リソースサーバは、
前記所定のサーバが発行したトークン情報の正当性を検証し、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御し、
前記セキュアなコンポーネントは、
前記クライアントが取得したトークン情報の正当性を検証するトークン検証機能を備え、
検証が成功した場合、前記トークン情報を記憶する、
認可に基づくリソースアクセス制御システム。

【請求項2】

ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、
前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、
クライアントが動作するデバイスと
を備え、
前記デバイスは、
前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報を記憶するセキュアなコンポーネントを備え、
前記クライアントは、
前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、
前記リソースサーバは、
前記所定のサーバが発行したトークン情報の正当性を検証し、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御し、
前記セキュアなコンポーネントは、
前記クライアントを認証するクライアント認証機能を備え、
前記クライアントの認証結果に応じて、前記クライアントとの間での前記トークン情報の授受の可否を決定する、
認可に基づくリソースアクセス制御システム。

【請求項3】

前記セキュアなコンポーネントは、
トラステッド実行環境又はセキュアエレメントである、
請求項１又は請求項２に記載の認可に基づくリソースアクセス制御システム。

【請求項4】

前記セキュアなコンポーネントは、
前記クライアントが取得したトークン情報の正当性を検証するトークン検証機能を備え、
検証が成功した場合、前記トークン情報を記憶する、
請求項２に記載の認可に基づくリソースアクセス制御システム。

【請求項5】

前記セキュアなコンポーネントは、
内部に保有する情報及び記憶したトークン情報を用いて新たなトークン情報を生成するトークン生成機能を備え、
前記クライアントは、
前記新たなトークン情報を前記リソースサーバへ送信し、
前記リソースサーバは、
前記新たなトークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する、
請求項１から請求項４のいずれか一項に記載の認可に基づくリソースアクセス制御システム。

【請求項6】

前記セキュアなコンポーネントは、
内部に保有する鍵を用いて改ざん検知コードを生成する検知コード生成機能を備え、
前記クライアントは、
前記新たなトークン情報に前記改ざん検知コードを付加して前記リソースサーバへ送信し、
前記リソースサーバは、
前記改ざん検知コードの検証結果に基づいて前記クライアントのリソースへのアクセスを制御する、
請求項５に記載の認可に基づくリソースアクセス制御システム。

【請求項7】

前記セキュアなコンポーネントは、
内部に保有する暗号化鍵を用いて前記新たなトークン情報を暗号化するトークン暗号化機能を備え、
前記クライアントは、
暗号化されたトークン情報を前記リソースサーバへ送信し、
前記リソースサーバは、
前記暗号化されたトークン情報を復号して得られた前記新たなトークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する、
請求項５に記載の認可に基づくリソースアクセス制御システム。

【請求項8】

前記セキュアなコンポーネントは、
前記クライアントを認証するクライアント認証機能を備え、
前記クライアントの認証結果に応じて、前記クライアントとの間での前記トークン情報の授受の可否を決定する、
請求項１に記載の認可に基づくリソースアクセス制御システム。

【請求項9】

前記セキュアなコンポーネントは、
外部のサーバとの間で秘匿通信路を開設する開設機能を備え、
前記セキュアなコンポーネントの内部機能、及び前記セキュアなコンポーネントが内部に保有する情報又は鍵の少なくとも一部が前記外部のサーバから更新可能である、
請求項１から請求項８のいずれか一項に記載の認可に基づくリソースアクセス制御システム。

【請求項10】

クライアントが動作するデバイスに実装されるセキュアなコンポーネントであって、
認可サーバが、ユーザ認証結果に基づいてリソースに対するアクセスを認可した結果、所定のサーバが発行するトークン情報を前記クライアントから取得して記憶し、
前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有し、前記所定のサーバが発行したトークン情報の正当性を検証し、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御するリソースサーバへ記憶したトークン情報を送信するために、前記記憶したトークン情報を前記クライアントへ出力し、
前記クライアントから取得したトークン情報の正当性を検証するトークン検証機能を備え、
検証が成功した場合、前記トークン情報を記憶する、
セキュアなコンポーネント。

【請求項11】

前記セキュアなコンポーネントは、
トラステッド実行環境又はセキュアエレメントである、
請求項１０に記載のセキュアなコンポーネント。

【請求項12】

内部に保有する情報及び記憶したトークン情報を用いて新たなトークン情報を生成するトークン生成機能を備え、
前記新たなトークン情報を前記リソースサーバへ送信するために、前記新たなトークン情報を前記クライアントへ出力する、
請求項１０又は請求項１１に記載のセキュアなコンポーネント。

【請求項13】

内部に保有する鍵を用いて改ざん検知コードを生成する検知コード生成機能を備え、
前記改ざん検知コードを付加した前記新たなトークン情報を前記リソースサーバへ送信するために、前記改ざん検知コードを付加した前記新たなトークン情報を前記クライアントへ出力する、
請求項１２に記載のセキュアなコンポーネント。

【請求項14】

内部に保有する暗号化鍵を用いて前記新たなトークン情報を暗号化するトークン暗号化機能を備え、
暗号化されたトークン情報を前記リソースサーバへ送信するために、前記暗号化されたトークン情報を前記クライアントへ出力する、
請求項１２に記載のセキュアなコンポーネント。

【請求項15】

前記クライアントを認証するクライアント認証機能を備え、
前記クライアントの認証結果に応じて、前記クライアントとの間での前記トークン情報の授受の可否を決定する、
請求項１０から請求項１４のいずれか一項に記載のセキュアなコンポーネント。

【請求項16】

外部のサーバとの間で秘匿通信路を開設する開設機能を備え、
前記セキュアなコンポーネントの内部機能、及び前記セキュアなコンポーネントが内部に保有する情報又は鍵の少なくとも一部が前記外部のサーバから更新可能である、
請求項１０から請求項１５のいずれか一項に記載のセキュアなコンポーネント。

【請求項17】

請求項１０から請求項１６のいずれか一項に記載のセキュアなコンポーネントを備え、クライアントが動作する、
デバイス。

【請求項18】

ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、
前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、
クライアントが動作するデバイスと
を備えるシステムの認可に基づくリソースアクセス制御方法であって、
前記デバイスは、
前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報をセキュアなコンポーネントに記憶し、
前記セキュアなコンポーネントは、
前記クライアントが取得したトークン情報の正当性を検証し、
検証が成功した場合、前記トークン情報を記憶し、
前記クライアントは、
前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、
前記リソースサーバは、
前記所定のサーバが発行したトークン情報の正当性を検証し、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する、
認可に基づくリソースアクセス制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、認可に基づくリソースアクセス制御システム、セキュアなコンポーネント、デバイス及び認可に基づくリソースアクセス制御方法に関する。

【背景技術】

【0002】

多くのＷｅｂサービスは、ＩＥＴＦ（Internet Engineering Task Force）において、ＯＡｕｔｈ２．０として定められた標準規格に従っている。このようなＷｅｂサービスでは、特定サービス事業者における認証の実施を基礎として、他のサービスへのログインやサービス間でのＡＰＩ連携の認可を行うことが可能であり、サービス連携が円滑に行えるようになっている。認証はある主体が特定の主体であることを識別することであり、認可は認証を行った主体に対してアクセスなどの権限を付与することである。

【0003】

ＩｏＴシステムにおいても、Ｗｅｂサービスと同様に、認証（例えば、ＩｏＴデバイスの認証）と認可（例えば、ＩｏＴデバイスに対するＡＰＩ連携）のタイミングを分けて行われることが多い。また、ＩｏＴシステムでは、デバイス上で動作するアプリケーションのように、認証主体と認可主体が全てパブリックネットワーク上にあるとは限らない状況が存在する。このため、ＩｏＴシステムは、Ｗｅｂサービスのように、連携サービスが全てパブリックネットワーク上に存在する場合に比べて、セキュリティ的な課題がある。

【0004】

そこで、デバイス上で動作するアプリケーションに関して、ＯＡｕｔｈ２．０に従って、クライアント（クライアント端末上で動作するアプリケーション）が、予め記憶したシークレット（認可コード）を用いて認可サーバ（トークンエンドポイント）に対してアクセストークンの発行を要求し、認可サーバが発行したアクセストークンを受信し、そのアクセストークンを利用してリソースを取得するシステムが開示されている（特許文献１参照）。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１８－８４９７９号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかし、特許文献１のようなシステムでは、クライアント端末上にアクセストークンを保持するため、アクセストークン漏洩に基づくセキュリティリスクが存在する。すなわち、Ｗｅｂサービスと異なり、ＩｏＴデバイス上のアプリケーションだけでＯＡｕｔｈ２．０を利用する場合、ＩｏＴデバイス上にアクセストークンを保持せざるを得なくなるが、万一漏洩した場合、第三者に不正なリソースへのアクセスを許すおそれがある。また、ＩｏＴシステムは、長期間に亘って稼動するという特性上、一度ログインしたら継続してログインを続けることが多く、アクセストークンを無効にするための作業時間を設定することが難しい。また、頻繁なアクセストークンの更新は、ＩｏＴシステムが苦手とする通信トラフィックの増加や集中を招く。

【0007】

本発明は、斯かる事情に鑑みてなされたものであり、発行されたアクセストークンを長期間にわたって安全に保護することができる認可に基づくリソースアクセス制御システム、セキュアなコンポーネント、デバイス及び認可に基づくリソースアクセス制御方法を提供することを目的とする。

【課題を解決するための手段】

【0008】

本発明の実施の形態に係る認可に基づくリソースアクセス制御システムは、ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、クライアントが動作するデバイスとを備え、前記デバイスは、前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報を記憶するセキュアなコンポーネントを備え、前記クライアントは、前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、前記リソースサーバは、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【0009】

本発明の実施の形態に係るセキュアなコンポーネントは、クライアントが動作するデバイスに実装されるセキュアなコンポーネントであって、認可サーバが、ユーザ認証結果に基づいてリソースに対するアクセスを認可した結果、所定のサーバが発行するトークン情報を前記クライアントから取得して記憶し、前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバへ記憶したトークン情報を送信するために、前記記憶したトークン情報を前記クライアントへ出力する。

【0010】

本発明の実施の形態に係るデバイスは、前述のセキュアなコンポーネントを備え、クライアントが動作する。

【0011】

本発明の実施の形態に係る認可に基づくリソースアクセス制御方法は、ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、クライアントが動作するデバイスとを備えるシステムの認可に基づくリソースアクセス制御方法であって、前記デバイスは、前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報をセキュアなコンポーネントに記憶し、前記クライアントは、前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、前記リソースサーバは、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【発明の効果】

【0012】

本発明によれば、デバイスの長期稼働において、有効なトークンを保持し続けるリスク（漏洩等のセキュリティリスク）を低減しつつ、再認証やトークン更新に必要となる通信トラフィックを削減することができる。

【図面の簡単な説明】

【0013】

【図1】本実施の形態の認可に基づくリソースアクセス制御システムの構成の一例を示す模式図である。

【図2】ＲＦＣ８２５２に基づいてトークンの取得を行う場合のフローの一例を示す説明図である。

【図3】認可に基づくリソースアクセス制御システムでのトークンの取得を行う場合のフローの一例を示す説明図である。

【図4】トークンの内部検証の例を示す説明図である。

【図5】改ざん検知コードの付与による保護の例を示す説明図である。

【図6】トークンの暗号化による保護の例を示す説明図である。

【図7】クライアントアプリに対する認証の例を示す説明図である。

【図8】秘匿通信路による外部管理の例を示す説明図である。

【発明を実施するための形態】

【0014】

以下、本発明をその実施の形態を示す図面に基づいて説明する。図１は本実施の形態の認可に基づくリソースアクセス制御システムの構成の一例を示す模式図である。認可に基づくリソースアクセス制御システムは、デバイスとしてのＩｏＴデバイス１００、認可サーバ２００、トークンサーバ４００を備える。認可に基づくリソースアクセス制御システムは、さらに、リソースサーバ３００、セキュアなコンポーネント管理サーバ５００を備えてもよい。図１の例では、認可サーバ２００とトークンサーバ４００とを別々のサーバとして構成しているが、認可サーバ２００とトークンサーバ４００とを１つのサーバとして統合してもよい。

【0015】

ＩｏＴデバイス１００は、実装対象となっているデバイスであり、例えば、ＲＴＯＳ（Real Time Operating System）やＬｉｎｕｘ（登録商標）等が動作する組み込みボードなどを含む。ＩｏＴデバイスは、例えば、ＯＳを搭載して独立動作をすることができるデバイス（電子デバイスとも称する）であり、「モノのインターネット」（ＩｏＴ）でいうところの「モノ」に該当するデバイスである。ＩｏＴデバイス１００は、内部に不図示のＳｏＣ（System on Chip）、及びセキュアなコンポーネント５０を有する。ＩｏＴデバイス１００は、セキュアなコンポーネント５０を内蔵しつつ、リソースを使用するクライアントアプリ（クライアントとも称する）２０が動作するデバイスである。ＩｏＴデバイス１００の詳細は後述する。

【0016】

デバイス管理者は、ＩｏＴデバイス１００の管理者であり、ＩｏＴデバイス１００に対するアクセス権を持つと同時に、リソースを提供する事業者に対してユーザ登録を行っており、リソースを提供する事業者に対する認証を行う主体（ユーザ）である（Resource Ownerに相当する）。デバイス管理者は、ＩｏＴデバイス１００でクライアントアプリ２０を実行することで、所望の機能を実現することを期待しているユーザである。認可サーバ２００上でユーザ登録がされている。

【0017】

認可サーバ２００は、個々のユーザを認証した上で、当該ユーザの許可に基づき、リソースサーバ３００が有するリソース３０１へのアクセスを認可するためのサーバである。認可サーバ２００は、認可コード２０１を保持する。認可コード２０１は、デバイス管理者による認証、認可が行われた場合に動的に生成されるコードであり、基本的には１回限りの使い捨てのコードとすることができる。ここで、「認証」とは、あるユーザが特定のユーザであることを識別することであり、本実施の形態では、ユーザ名とパスワードで認証を行うこととしているが、認証方法は、これに限定されるものではない。また、「認可」は、認証を行ったユーザに対してアクセスなどの権限を付与することである。

【0018】

リソースサーバ３００は、リソース３０１を保持するサーバである。リソース３０１は、クライアントアプリ２０がアクセスを必要とするリソースであり、例えば、ファイル等のデータ、あるいは、データ以外として、例えば、ＡＰＩ（例えば、ディープラーニング用ＡＰＩなど）実行などの機能も含む。

【0019】

トークンサーバ４００は、認可サーバ２００の認可に基づき、トークン（アクセストークンとも称する）を発行するためのサーバである。なお、本明細書では、トークン情報は、トークンを意味するが、トークンに関連する情報やトークンに付随する情報を含めてもよい。トークンサーバ４００の詳細は後述する。

【0020】

セキュアなコンポーネント管理サーバ５００は、セキュアなコンポーネント５０の遠隔管理を目的とすることができる。セキュアなコンポーネント管理サーバ５００は、ＩｏＴデバイス１００内のセキュアなコンポーネント５０と通信（例えば、秘匿通信路経由の通信）を行い、セキュアなコンポーネント５０内部の機能や状態を更新することができる。

【0021】

図１に例示した各サーバをどの事業者が運営するかは個々のビジネスケースに応じて異なる。本実施の形態では、認可サーバ２００とリソースサーバ３００は、サービス事業者によって運営され、トークンサーバ４００とセキュアなコンポーネント管理サーバ５００は、セキュアなコンポーネント５０の製造者によって運営されている形態として説明するが、これに限定されるものではない。

【0022】

ＩｏＴデバイス１００は、セキュアなコンポーネント５０の他に、クライアントアプリ２０、クライアントアプリ証明書２１、ブラウザ１０を備える。

【0023】

クライアントアプリ２０は、リソースを提供する事業者の認可を経て、リソースにアクセスすることで機能を実現するアプリケーションである。クライアントアプリ２０は、リソースを提供する事業者とは別の主体（ベンダー等）によって開発されたアプリケーションである。

【0024】

クライアントアプリ証明書２１は、クライアントアプリ２０に対するコードサイニング証明書である。コードサイニング証明書は、クライアントアプリ２０にデジタル署名（例えば、クライアントアプリ２０のハッシュ値に対して秘密鍵署名が施されている）を行う電子署名用の証明書であり、クライアントアプリ２０の配布元を認証し、なりすましや内容の改ざんなどがされていないことを保証できる。

【0025】

ブラウザ１０は、Ｗｅｂブラウザであり、クライアントアプリ２０とは別のアプリケーションとして与えられる。

【0026】

セキュアなコンポーネント５０は、ＩｏＴデバイス１００内に存在する、通常のプログラム実行環境とは論理的又は物理的に隔離された、ストレージ（メモリ）を持つセキュアな実行環境である。本実施の形態では、セキュアなコンポーネント５０は、主にセキュアエレメント（ＳＥとも称する）を想定する。セキュアエレメントは、耐タンパ性を有するセキュリティチップで構成することができる。これにより、後述のように、発行されたトークン情報を長期間に亘って安全に保護することができる。また、トークン情報を頻繁に更新する必要もなく、トークン情報を無効にするための作業時間を設定する必要もない。

【0027】

セキュアなコンポーネント５０は、トラステッド実行環境（ＴＥＥとも称する）でもよい。トラステッド実行環境は、ＳｏＣ（System on Chip）上で、例えば、ＣＰＵ仮想化支援技術（例えば、ＴｒｕｓｔＺｏｎｅ（登録商標））と称される技術を用いることによって、ＳｏＣ内で区分された領域（いわゆるＴＥＥ：Trusted Execution Environment）を指し、通常実行環境（ＲＥＥ：Rich Execution Environmentとも称する）よりもセキュアな領域である。

【0028】

クライアントアプリ２０とセキュアなコンポーネント５０との間の通信路は、セキュアなコンポーネント５０の種類によって異なる。クライアントアプリ２０とセキュアエレメントとの間の通信は、例えば、ＩＳＯ７８１６／ＳＰＩ／Ｉ２Ｃ等のシリアル通信路を用いることができ、クライアントアプリ２０とＴＥＥとの間の通信は、例えば、ＡＰＩＩ／Ｆを介して行うことができる。

【0029】

セキュアなコンポーネント５０は、ＳＥ（ＴＥＥ）ＩＤ５１、カウンタ５２、トークン５３、トークン生成機能６０、トークン署名検証機能６１、トークン暗号化機能６２、トークンＭＡＣ付与機能６３、クライアント検証機能６４、秘匿通信路開設機能６５、トークン署名検証鍵（公開鍵）７１、トークン暗号化鍵７２、トークンＭＡＣ鍵７３、及びクライアント検証鍵（公開鍵）７４を内蔵する。

【0030】

ＳＥ（ＴＥＥ）ＩＤ５１は、セキュアなコンポーネント５０を一意に識別するためのＩＤである。ＳＥ（ＴＥＥ）ＩＤ５１は、ＳＥＩＤ５１、又はＴＥＥＩＤ５１の意味である。

【0031】

カウンタ５２は、セキュアなコンポーネント５０がトークンを生成する際、生成回数を計数する。

【0032】

トークン５３は、リソースサーバ３００のリソース３０１に対する認可を受けていることを証明する秘密情報である。トークン５３は、クライアントアプリ２０経由でトークンサーバ４００から受け取ることができる。トークン５３のデータ構造、内容については、以降説明する個々の実施例によって異なる。

【0033】

トークン生成機能６０は、セキュアなコンポーネント５０自身がトークンを生成する場合に実行する機能である。トークン生成機能６０は、ＳＥ（ＴＥＥ）ＩＤ５１やカウンタ５２の値をトークン（初期のトークンとも称する）に付加する等の処理を行って動的なトークンを生成する。

【0034】

トークン署名検証機能６１は、クライアントアプリ２０経由でトークンサーバ４００から受け取ったトークンに署名が添付されている場合、署名の検証を行う機能である。

【0035】

トークン暗号化機能６２は、暗号化トークンを授受する際に暗号化を行う機能である。

【0036】

トークンＭＡＣ付与機能６３は、トークンにＭＡＣ（Message Authentication Code：メッセージ認証コード）を付与する際に実行する機能である。

【0037】

クライアント検証機能６４は、クライアントアプリ２０との間でのトークン授受時にクライアント認証を行う際に実行する機能である。

【0038】

秘匿通信路開設機能６５は、セキュアなコンポーネント管理サーバ５００との間で秘匿通信路を開設する機能であり、例えば、ＴＬＳ（Transport Layer Security）等の通信機能を想定している。

【0039】

トークン署名検証鍵（公開鍵）７１は、受信したトークンに署名が添付されている場合、当該署名を検証するための鍵である。

【0040】

トークン暗号化鍵７２は、暗号化トークンを送出する際にトークンの暗号化に用いる鍵である。

【0041】

トークンＭＡＣ鍵７３は、トークンに付与するＭＡＣを計算するための鍵である。

【0042】

クライアント検証鍵（公開鍵）７４は、クライアント認証を行う際にクライアント証明書を検証する鍵である。

【0043】

トークンサーバ４００は、ＳＥ（ＴＥＥ）ＩＤ４０１、カウンタ４０２、トークン４０３、トークン正当性確認機能４１０、トークン署名生成機能４１１、トークン復号機能４１２、トークンＭＡＣ検証機能４１３、トークン署名生成鍵（秘密鍵）４２０、トークン復号鍵４２１、及びトークンＭＡＣ検証鍵４２２を有する。

【0044】

ＳＥ（ＴＥＥ）ＩＤ４０１は、トークンサーバ４００が出力するトークンの出力先のＩｏＴデバイス１００内のセキュアなコンポーネント５０を一意に識別するためのＩＤである。ＳＥ（ＴＥＥ）ＩＤ４０１は、ＳＥＩＤ４０１又はＴＥＥＩＤ４０１の意味である。

【0045】

カウンタ４０２は、セキュアなコンポーネント５０がトークンを生成する際、生成回数を計数するカウンタである。カウンタ４０２は、当該セキュアなコンポーネント５０からのトークンの受信回数と同期している。

【0046】

トークン４０３は、リソース３０１に対する認可を受けていることを証明する秘密情報である。トークン４０３は、クライアントアプリ２０からの適切な認可コード提示に応じて動的に生成される。

【0047】

トークン正当性確認機能４１０は、セキュアなコンポーネント５０が生成した動的なトークンの正当性を確認する機能である。トークン正当性確認機能４１０は、ＳＥ（ＴＥＥ）ＩＤ４０１やカウンタ４０２の値を参照してトークンの正当性を確認する。

【0048】

トークン署名生成機能４１１は、トークンに対して署名を生成し、当該トークンに付与する機能である。

【0049】

トークン復号機能４１２は、暗号化トークンを受信した際、暗号化トークンを復号する機能である。

【0050】

トークンＭＡＣ検証機能４１３は、トークンに付与されたＭＡＣを検証する機能である。

【0051】

トークン署名生成鍵（秘密鍵）４２０は、トークンに対して署名を生成する鍵である。

【0052】

トークン復号鍵４２１は、暗号化トークンを受信した際、暗号化トークンの復号に用いる鍵である。

【0053】

トークンＭＡＣ検証鍵４２２は、トークンに付与されたＭＡＣを照合するために使用する鍵である。

【0054】

セキュアなコンポーネント５０が動的にトークンを生成する場合、トークンサーバ４００は、トークンを生成可能なＳＥ（ＴＥＥ）ＩＤ４０１のリストと、当該ＳＥ（ＴＥＥ）ＩＤ４０１がトークンを生成した回数を記録している。セキュアなコンポーネント５０の製造者であれば、各個体のＩＤ管理を元々手掛けていることもあり、比較的容易に管理できるので、トークンサーバ４００の運営は、セキュアなコンポーネント５０の製造者又は当該製造者と協業関係にある事業者が行うことが好ましい。なお、トークンサーバ４００を運営する事業者は、サービス事業者であってもよい。

【0055】

次に、本実施の形態の認可に基づくリソースアクセス制御システムの処理について説明する。デバイス（例えば、ＩｏＴデバイス１００を含む）上で動作するアプリケーションがＯＡｕｔｈ２．０を利用する場合については、ＩＥＴＦ（Internet Engineering Task Force）は、ＲＦＣ８２５２に基づく認可フローを定義している。従って、ＲＦＣ８２５２は、ＮａｔｉｖｅアプリケーションがＯＡｕｔｈ２．０を使う際のベストプラクティスであると言える。ＯＡｕｔｈ２．０では、インプリシットグランドによる認可の手順を定めているが、インプリシットグランドは、ＲＦＣ８２５２では非推奨となっているからである。そこで、まず、ＩｏＴデバイス１００のクライアントアプリ２０をＮａｔｉｖｅアプリケーションとみなし、ＲＦＣ８２５２に基づく認可フローについて説明する。

【0056】

図２はＲＦＣ８２５２に基づいてトークンの取得を行う場合のフローの一例を示す説明図であり、図３は認可に基づくリソースアクセス制御システムでのトークンの取得を行う場合のフローの一例を示す説明図である。図２及び図３のいずれも、ＲＦＣ８２５２に基づく認可のフローに従っている。図２で示す符号Ｐ１～Ｐ１６は、図３で示す符号Ｐ１～Ｐ１６に対応する。以下、符号Ｐ１～Ｐ１６で示す処理について説明する。

【0057】

Ｐ１（クライアントアプリの実行）：デバイス管理者は、クライアントアプリ２０を実行する。

【0058】

Ｐ２（ブラウザのオープン）：クライアントアプリ２０は、認可コードを返すためのリダイレクトＵＲＩ（Uniform Resource Identifier）をリクエストに含め、認可サーバ２００の認可ページをブラウザ１０で開く。リダイレクトＵＲＩは、クライアントアプリ２０が承認され、認可コードが付与されたとき、認可サーバ２００が、ブラウザ１０を別の場所へ遷移させる（リダイレクトする）場所である。ここでは、リダイレクトＵＲＩは、ＩｏＴデバイス１００内でクライアントアプリ２０自身を示すＵＲＩとする。

【0059】

Ｐ３（認可ページの転送）：ブラウザ１０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページを開く。

【0060】

Ｐ４（認証要求）：認可サーバ２００は、リクエストに含まれているリダイレクトＵＲＩが事前登録された正当な値であることを確認した上で、デバイス管理者に対するユーザ認証を要求する。ここでは、ユーザＩＤ及びパスワードの入力を要求する。なお、ユーザ認証は、ユーザＩＤ及びパスワードの入力に限定されるものではなく、例えば、生体情報を入力してもよい。

【0061】

Ｐ５（認証情報入力と認可）：デバイス管理者は、認可サーバ２００に対してユーザ認証情報を入力して認証を完了する。認証完了後、デバイス管理者は認可サーバ２００に対し、クライアントアプリ２０のリソースアクセスを許可する。認可サーバ２００は、ユーザの認可を確認した上で、トークン生成用の認可コードを生成する。

【0062】

Ｐ６（認可コード付きリダイレクトの実行）：認可サーバ２００は、ブラウザ１０に対し、リダイレクトＵＲＩを認可コードと共に返送し、リダイレクトを行う。

【0063】

Ｐ７（認可コードの取得）：ブラウザ１０は、リダイレクトＵＲＩを認可コードと共に開くと、当該ＵＲＩへのリクエストは、クライアントアプリ２０が受理することになる。ここで、クライアントアプリ２０は、ブラウザ１０から認可コードを取得する。

【0064】

Ｐ８（認可コードの提示）：クライアントアプリ２０は、トークンサーバ４００にアクセスし、認可コードを提示する。

【0065】

Ｐ９（認可コードの確認）：トークンサーバ４００は、クライアントアプリ２０から提示された認可コードが正当であるかを照合する。照合に失敗した場合、ここで処理を中断する。

【0066】

Ｐ１０（トークンの取得）：照合に成功した場合、トークンサーバ４００は、新たにトークンを生成し、生成したトークンをクライアントアプリ２０に返送する。

【0067】

Ｐ１１（トークンの保存）：クライアントアプリ２０は、セキュアなコンポーネント５０に対してトークンの書き込みを行う。

【0068】

Ｐ１２（トークンの取得要求）：クライアントアプリ２０は、リソース３０１を使用する際に、セキュアなコンポーネント５０に対してトークンの取得を要求する。

【0069】

Ｐ１３（トークンの取得）：セキュアなコンポーネント５０は、クライアントアプリ２０に対して、保存しているトークンを返送する。

【0070】

Ｐ１４（リソースへのアクセス（Ｗｉｔｈトークン））：クライアントアプリ２０は、セキュアなコンポーネント５０から取得したトークンを添付して、リソースサーバ３００に対してリソース３０１へのアクセスを要求する。

【0071】

Ｐ１５（トークンの確認）：リソースサーバ３００は、トークンサーバ４００に対して、クライアントアプリ２０から受領したトークンの正当性を確認する。トークンが正当でない場合、クライアントアプリ２０からのアクセスを拒否し、ここで処理を終了する。

【0072】

Ｐ１６（リソースの提供）：トークンが正当な場合、リソースサーバ３００は、クライアントアプリ２０にリソース３０１へのアクセスを提供する。

【0073】

上述のように、クライアントアプリ２０は、トークンサーバ４００から取得したトークンをセキュアなコンポーネント５０に保存する。これにより、ＩｏＴデバイス１００の長期稼働において、所定のサーバ（例えば、トークンサーバ４００）から取得した有効なトークンを保持し続けるリスク（例えば、漏洩等のセキュリティリスク）を低減しつつ、再認証やトークンの更新に必要となる通信トラフシックを削減することができる。また、トークンが安全に保存されるので、漏洩等を回避するために、トークンを頻繁に更新する必要もなく、トークンを無効にするための作業時間を設定する必要もない。

【0074】

セキュアなコンポーネント５０内において、トークンサーバ４００と同じトークン検証ロジックを実装しておくことにより、トークンをセキュアなコンポーネント５０に保存する際、当該トークンが正当な値であるか（不適切なトークンでないか）を確認し、トークンの改ざん等を防止することができる。以下では、検証アルゴリズムとして、公開鍵署名を用いる場合について説明する。なお、検証アルゴリズムは、公開鍵署名に限定されるものではなく、他の検証方法を用いてもよい。

【0075】

図４はトークンの内部検証の例を示す説明図である。以下、符号Ｐ２１～Ｐ３２で示す処理について説明する。

【0076】

Ｐ２１（クライアントアプリの実行）：デバイス管理者は、クライアントアプリ２０を実行する。

【0077】

Ｐ２２（ブラウザのオープン）：クライアントアプリ２０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページをブラウザ１０で開く。ここでは、リダイレクトＵＲＩは、ＩｏＴデバイス１００内でクライアントアプリ２０自身を示すＵＲＩとする。

【0078】

Ｐ２３（認可ページの転送）：ブラウザ１０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページを開く。

【0079】

Ｐ２４（認証要求）：認可サーバ２００は、リクエストに含まれているリダイレクトＵＲＩが事前登録された正当な値であることを確認した上で、デバイス管理者に対するユーザ認証を要求する。

【0080】

Ｐ２５（認証情報入力と認可）：デバイス管理者は、認可サーバ２００に対してユーザ認証情報を入力して認証を完了する。認証完了後、デバイス管理者は認可サーバ２００に対し、クライアントアプリ２０のリソースアクセスを許可する。認可サーバ２００は、ユーザの認可を確認した上で、トークン生成用の認可コードを生成する。

【0081】

Ｐ２６（認可コード付きリダイレクトの実行）：認可サーバ２００は、ブラウザ１０に対し、リダイレクトＵＲＩを認可コードと共に返送し、リダイレクトを行う。

【0082】

Ｐ２７（認可コードの取得）：ブラウザ１０は、リダイレクトＵＲＩを認可コードと共に開くと、当該ＵＲＩへのリクエストは、クライアントアプリ２０が受理することになる。ここで、クライアントアプリ２０は、ブラウザ１０から認可コードを取得する。

【0083】

Ｐ２８（認可コードの提示）：クライアントアプリ２０は、トークンサーバ４００にアクセスし、認可コードを提示する。

【0084】

Ｐ２９（認可コードの確認）：トークンサーバ４００は、クライアントアプリ２０から提示された認可コードが正当であるかを照合する。照合に失敗した場合、ここで処理を中断する。

【0085】

Ｐ３０（トークンの取得）：照合に成功した場合、トークンサーバ４００は、新たにトークンを生成する。このとき、トークンサーバ４００は、トークン署名生成機能４１１を呼び出し、自身が保持するトークン署名生成鍵（秘密鍵）４２０を用いてトークンに対して署名を行い、クライアントアプリ２０に返送する。

【0086】

Ｐ３１（トークンの検証）：クライアントアプリ２０は、セキュアなコンポーネント５０に対してトークンの書き込みを指示する。このとき、セキュアなコンポーネント５０は、トークンの書き込みに先立って、トークン署名検証機能６１を呼び出し、トークン署名検証鍵（公開鍵）７１を用いて、トークンに添付された署名を検証し、トークンの正当性検証を行う。検証に失敗した場合は、ここで処理を終了し、トークンの保存を行わない。

【0087】

Ｐ３２（トークンの保存）：検証に成功した場合、セキュアなコンポーネント５０は、トークンを保存する。Ｐ３２以降の処理は、図３に示す符号Ｐ１１以降の処理と同様であるが、リソースサーバ３００がクライアントアプリ２０から受領したトークンの正当性を確認する際に、Ｐ３１の処理を同様に、トークン署名検証鍵を用いてトークンを検証してもよい。

【0088】

上述のように、セキュアなコンポーネント５０がトークンを記憶する際、トークンの正当性を確認することにより、不正なトークンの挿入によるトークンの置き換え攻撃などのトークンの改ざん等を防止することができる。

【0089】

上述の例では、セキュアなコンポーネント５０に対してトークンを保存する構成であったが、セキュアなコンポーネント５０が動的にトークンを生成してもよい。以下では、トークンの改ざん検知コードの付与による保護及び暗号技術による保護について説明する。まず、トークンの動的生成と改ざん検知コードの付与による保護について説明する。

【0090】

図５は改ざん検知コードの付与による保護の例を示す説明図である。以下、符号Ｐ４１～Ｐ５８で示す処理について説明する。

【0091】

Ｐ４１（クライアントアプリの実行）：デバイス管理者は、クライアントアプリ２０を実行する。

【0092】

Ｐ４２（ブラウザのオープン）：クライアントアプリ２０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページをブラウザ１０で開く。ここでは、リダイレクトＵＲＩは、ＩｏＴデバイス１００内でクライアントアプリ２０自身を示すＵＲＩとする。

【0093】

Ｐ４３（認可ページの転送）：ブラウザ１０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページを開く。

【0094】

Ｐ４４（認証要求）：認可サーバ２００は、リクエストに含まれているリダイレクトＵＲＩが事前登録された正当な値であることを確認した上で、デバイス管理者に対するユーザ認証を要求する。ここでは、ユーザＩＤ及びパスワードの入力を要求する。

【0095】

Ｐ４５（認証情報入力と認可）：デバイス管理者は、認可サーバ２００に対してユーザ認証情報を入力して認証を完了する。認証完了後、デバイス管理者は認可サーバ２００に対し、クライアントアプリ２０のリソースアクセスを許可する。認可サーバ２００は、ユーザの認可を確認した上で、トークン生成用の認可コードを生成する。

【0096】

Ｐ４６（認可コード付きリダイレクトの実行）：認可サーバ２００は、ブラウザ１０に対し、リダイレクトＵＲＩを認可コードと共に返送し、リダイレクトを行う。

【0097】

Ｐ４７（認可コードの取得）：ブラウザ１０は、リダイレクトＵＲＩを認可コードと共に開くと、当該ＵＲＩへのリクエストは、クライアントアプリ２０が受理することになる。ここで、クライアントアプリ２０は、ブラウザ１０から認可コードを取得する。

【0098】

Ｐ４８（認可コードの提示）：クライアントアプリ２０は、トークンサーバ４００にアクセスし、認可コードを提示する。

【0099】

Ｐ４９（認可コードの確認）：トークンサーバ４００は、クライアントアプリ２０から提示された認可コードが正当であるかを照合する。照合に失敗した場合、ここで処理を中断する。

【0100】

Ｐ５０（トークンの取得）：照合に成功した場合、トークンサーバ４００は、新たに初期トークンを生成し、生成した初期トークンをクライアントアプリ２０に返送する。

【0101】

Ｐ５１（トークンの保存）：クライアントアプリ２０は、セキュアなコンポーネント５０に対して初期トークンの書き込みを行う。

【0102】

Ｐ５２（トークンの取得要求）：クライアントアプリ２０は、リソース３０１を使用する際に、セキュアなコンポーネント５０に対してトークンの取得を要求する。

【0103】

Ｐ５３（ＩＤおよびカウンタ付きトークンの生成）：セキュアなコンポーネント５０は、トークン生成機能６０を呼び出し、自身が保持する固有のＩＤ５１と、トークン生成回数を記録するカウンタ５２の値を初期トークンに付加し、ＩＤおよびカウンタ付きトークンを生成する。セキュアなコンポーネント５０は、トークンを生成後、カウンタ５２の値に１を加算する。

【0104】

Ｐ５４（トークンへのＭＡＣ付与）：セキュアなコンポーネント５０は、自身が保持するトークンＭＡＣ鍵７３を用いて、ＩＤおよびカウンタ付きトークンに対するＭＡＣ（メッセージ認証コード）を計算し、計算したＭＡＣをトークンに付与する。ＭＡＣ計算は、トークンのデータ列に対して、既存のＭＡＣ計算アルゴリズム（例えば、ＨＭＡＣ－ＳＨＡ２５６など）を用いることができる。

【0105】

Ｐ５５（リソースへのアクセス（Ｗｉｔｈトークン））：クライアントアプリ２０は、セキュアなコンポーネント５０から取得したＩＤおよびカウンタ付きトークンをＭＡＣとともに添付して、リソースサーバ３００に対してリソース３０１へのアクセスを要求する。

【0106】

Ｐ５６（トークンのＭＡＣ検証）：リソースサーバ３００は、トークンサーバ４００に対して、クライアントアプリ２０から受領したＩＤおよびカウンタ付きトークンの検証を依頼する。トークンサーバ４００は、トークンＭＡＣ検証機能４１３を呼び出し、自身が保持するトークンＭＡＣ検証鍵４２２を用いてトークンに付与されているＭＡＣを検証する。基本的には、セキュアなコンポーネント５０で実行したＭＡＣ計算と同一の計算を行ってＭＡＣを導出し、トークンに付与されているＭＡＣと一致比較すればよい。両者が不一致の場合、不正なトークンとみなし、ここで処理を終了する。

【0107】

Ｐ５７（トークンの正当性検証）：トークンサーバ４００は、トークンからＩＤを取得してトークン送信元のセキュアなコンポーネント５０を特定すると共に、当該ＩＤに対応して保持しているカウンタ４０２の値を読み出し、リソースサーバ３００から取得したトークンに埋め込まれたカウンタ値と比較する。比較終了後、トークンサーバ４００は、カウンタ４０２の値に１を加算する。ＩＤが見つからなかった場合、またはカウンタ値が一致しなかった場合、不正なトークンとみなし、ここで処理を終了する。

【0108】

Ｐ５８（リソースの提供）：トークンが正当な場合、リソースサーバ３００は、クライアントアプリ２０にリソース３０１へのアクセスを提供する。

【0109】

上述の例のように、セキュアなコンポーネント５０は、内部に保有する情報及び記憶した初期トークンを用いて、ＩＤおよびカウンタ付きトークン（新たなトークン）を生成する。内部に保有する情報は、新たなトークンを生成するための秘匿情報であれば、例えば、固有のＩＤ、トークン生成回数を記録するカウンタ値や乱数要素など、どのような情報を用いてもよい。

【0110】

クライアントアプリ２０は、新たなトークンをリソースサーバ３００へ送信する。リソースサーバ３００は、新たなトークンの検証結果に基づいてクライアントアプリ２０のリソース３０１へのアクセスを制御する。すなわち、検証が成功すれば、クライアントアプリ２０はリソース３０１にアクセスすることができる。このように、クライアント側でトークンを動的に生成し、リソースサーバ３００で当該トークンを検証することにより、トークンの再利用（トークンを用いたリプレイアタック）やなりすまし等を防止できる。

【0111】

また、上述のように、改ざん検知コード（上述の例では、ＭＡＣ）をトークンに付与することで、秘密鍵を知らない攻撃者は改ざん検知コードを計算することができず、トークン検証側で正当に取り扱われるトークンとＭＡＣを生成することができなくなる。これにより、トークンの偽造や改ざんを防止できる。

【0112】

上述の例では、鍵付きハッシュによりＭＡＣを付与して改ざん検知を行っているが、改ざん検知のアルゴリズムは、上述の例に限定されるものではなく、適宜所要のアルゴリズムを用いることができる。

【0113】

次に、トークンの動的生成と暗号化による保護について説明する。

【0114】

図６はトークンの暗号化による保護の例を示す説明図である。以下、符号Ｐ６１～Ｐ７８で示す処理について説明する。

【0115】

Ｐ６１（クライアントアプリの実行）：デバイス管理者は、クライアントアプリ２０を実行する。

【0116】

Ｐ６２（ブラウザのオープン）：クライアントアプリ２０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページをブラウザ１０で開く。ここでは、リダイレクトＵＲＩは、ＩｏＴデバイス１００内でクライアントアプリ２０自身を示すＵＲＩとする。

【0117】

Ｐ６３（認可ページの転送）：ブラウザ１０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページを開く。

【0118】

Ｐ６４（認証要求）：認可サーバ２００は、リクエストに含まれているリダイレクトＵＲＩが事前登録された正当な値であることを確認した上で、デバイス管理者に対するユーザ認証を要求する。ここでは、ユーザＩＤ及びパスワードの入力を要求する。

【0119】

Ｐ６５（認証情報入力と認可）：デバイス管理者は、認可サーバ２００に対してユーザ認証情報を入力して認証を完了する。認証完了後、デバイス管理者は認可サーバ２００に対し、クライアントアプリ２０のリソースアクセスを許可する。認可サーバ２００は、ユーザの認可を確認した上で、トークン生成用の認可コードを生成する。

【0120】

Ｐ６６（認可コード付きリダイレクトの実行）：認可サーバ２００は、ブラウザ１０に対し、リダイレクトＵＲＩを認可コードと共に返送し、リダイレクトを行う。

【0121】

Ｐ６７（認可コードの取得）：ブラウザ１０は、リダイレクトＵＲＩを認可コードと共に開くと、当該ＵＲＩへのリクエストは、クライアントアプリ２０が受理することになる。ここで、クライアントアプリ２０は、ブラウザ１０から認可コードを取得する。

【0122】

Ｐ６８（認可コードの提示）：クライアントアプリ２０は、トークンサーバ４００にアクセスし、認可コードを提示する。

【0123】

Ｐ６９（認可コードの確認）：トークンサーバ４００は、クライアントアプリ２０から提示された認可コードが正当であるかを照合する。照合に失敗した場合、ここで処理を中断する。

【0124】

Ｐ７０（トークンの取得）：照合に成功した場合、トークンサーバ４００は、新たに初期トークンを生成し、生成した初期トークンをクライアントアプリ２０に返送する。

【0125】

Ｐ７１（トークンの保存）：クライアントアプリ２０は、セキュアなコンポーネント５０に対して初期トークンの書き込みを行う。

【0126】

Ｐ７２（トークンの取得要求）：クライアントアプリ２０は、リソース３０１を使用する際に、セキュアなコンポーネント５０に対してトークンの取得を要求する。

【0127】

Ｐ７３（ＩＤおよびカウンタ付きトークンの生成）：セキュアなコンポーネント５０は、トークン生成機能６０を呼び出し、自身が保持する固有のＩＤ５１と、トークン生成回数を記録するカウンタ５２の値を初期トークンに付加し、ＩＤおよびカウンタ付きトークンを生成する。セキュアなコンポーネント５０は、トークンを生成後、カウンタ５２の値に１を加算する。

【0128】

Ｐ７４（トークンの暗号化）：セキュアなコンポーネント５０は、トークン暗号化機能６２を呼び出し、自身が保持するトークン暗号化鍵７２を用いて、ＩＤおよびカウンタ付きトークンを暗号化する。使用する暗号化アルゴリズムは、非対称鍵暗号（ＲＳＡ等）、対象鍵暗号（共通鍵暗号）（ＡＥＳ：Advanced Encryption Standard等）のいずれでもよい。本実施例では、共通鍵を用いてＡＥＳで暗号化している。

【0129】

Ｐ７５（リソースへのアクセス（Ｗｉｔｈトークン））：クライアントアプリ２０は、セキュアなコンポーネント５０から取得した暗号化トークンを添付して、リソースサーバ３００に対してリソース３０１へのアクセスを要求する。

【0130】

Ｐ７６（トークンの復号）：リソースサーバ３００は、トークンサーバ４００に対して、クライアントアプリ２０から受領した暗号化トークンの検証を依頼する。トークンサーバ４００は、トークン復号機能４１２を呼び出し、自身が保持するトークン復号鍵４２１を用いて暗号化トークンを復号し、ＩＤおよびカウンタ付きトークンを得る。

【0131】

Ｐ７７（トークンの正当性検証）：トークンサーバ４００は、トークンからＩＤを取得してトークン送信元のセキュアなコンポーネント５０を特定すると共に、当該ＩＤに対応して保持しているカウンタ４０２の値を読み出し、リソースサーバ３００から取得したトークンに埋め込まれたカウンタ値と比較する。比較終了後、トークンサーバ４００は、カウンタ４０２の値に１を加算する。ＩＤが見つからなかった場合、またはカウンタ値が一致しなかった場合、不正なトークンとみなし、ここで処理を終了する。

【0132】

Ｐ７８（リソースの提供）：トークンが正当な場合、リソースサーバ３００は、クライアントアプリ２０にリソース３０１へのアクセスを提供する。

【0133】

上述の例においても、図５の場合と同様に、セキュアなコンポーネント５０は、内部に保有する情報及び記憶した初期トークンを用いて、ＩＤおよびカウンタ付きトークン（新たなトークン）を生成する。すなわち、トークンサーバ４００が発行した固定値のトークンを使い続けるのではなく、セキュアなコンポーネント５０とトークンサーバ４００が、鍵とセキュアなコンポーネント５０の状態に関する情報（例えば、ＩＤ、カウンタ）を個別に保持した上で、鍵を用いて両者の上方の整合性を検証する形でトークンの正当性検証を行う。

【0134】

ＯＡｕｔｈ２．０をはじめとする従来技術においては、トークンが搾取された場合の不正アクセスを防止することが技術的に困難であり、代替策としてトークンの有効期間の削減、トークンの無効化、署名検証等を行っていたが、いずれもクライアント側に対する通信負荷の増大をもたらしていた。

【0135】

一方で本実施例の場合、上述のように、セキュアなコンポーネント５０側のＩＤをトークンに添付することで、トークン送信元の正当性を検証できる。また、カウンタをトークンに添付することで、トークンの再利用を防止できる。さらに、トークンは暗号化されているので、偽造や解読が困難である。これにより、ＩｏＴデバイス１００は、トークンのリフレッシュ等の追加通信を行うことなく、リソースサーバ３００に対する通信のみを行うことができ、セキュリティを維持しつつ最適な通信を行うことができる。

【0136】

なお、本実施例で採用しているトークンの暗号化、復号の方法や正当性検証方法（ＩＤ
とカウンタ）は一例であり、トークン生成や正当性検証に係るアルゴリズム、検証ポリシーは適宜の方法を用いることができる。

【0137】

セキュアなコンポーネント５０にトークンを記憶することで、通常のファイルストレージのように直接搾取される危険性は低下したものの、クライアントアプリ２０のふりをした不正なアプリによって、セキュアなコンポーネント５０からトークンを読み出して搾取されるリスクはなお存在し得る。この場合、クライアントアプリ２０とセキュアなコンポーネント５０との間で共通鍵を保持し、クライアントアプリ２０とセキュアなコンポーネント５０との間でセキュアチャネルを開設することでトークンの搾取を防止できる。さらに、以下では、クライアント証明書の提示を行うことでクライアントアプリ２０を検証する方法について説明する。

【0138】

図７はクライアントアプリに対する認証の例を示す説明図である。以下、符号Ｐ８１～Ｐ９８で示す処理について説明する。

【0139】

Ｐ８１（クライアントアプリの実行）：デバイス管理者は、クライアントアプリ２０を実行する。

【0140】

Ｐ８２（ブラウザのオープン）：クライアントアプリ２０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページをブラウザ１０で開く。ここでは、リダイレクトＵＲＩは、ＩｏＴデバイス１００内でクライアントアプリ２０自身を示すＵＲＩとする。

【0141】

Ｐ８３（認可ページの転送）：ブラウザ１０は、認可コードを返すためのリダイレクトＵＲＩをリクエストに含め、認可サーバ２００の認可ページを開く。

【0142】

Ｐ８４（認証要求）：認可サーバ２００は、リクエストに含まれているリダイレクトＵＲＩが事前登録された正当な値であることを確認した上で、デバイス管理者に対するユーザ認証を要求する。

【0143】

Ｐ８５（認証情報入力と認可）：デバイス管理者は、認可サーバ２００に対してユーザ認証情報を入力して認証を完了する。認証完了後、デバイス管理者は認可サーバ２００に対し、クライアントアプリ２０のリソースアクセスを許可する。認可サーバ２００は、ユーザの認可を確認した上で、トークン生成用の認可コードを生成する。

【0144】

Ｐ８６（認可コード付きリダイレクトの実行）：認可サーバ２００は、ブラウザ１０に対し、リダイレクトＵＲＩを認可コードと共に返送し、リダイレクトを行う。

【0145】

Ｐ８７（認可コードの取得）：ブラウザ１０は、リダイレクトＵＲＩを認可コードと共に開くと、当該ＵＲＩへのリクエストは、クライアントアプリ２０が受理することになる。ここで、クライアントアプリ２０は、ブラウザ１０から認可コードを取得する。

【0146】

Ｐ８８（認可コードの提示）：クライアントアプリ２０は、トークンサーバ４００にアクセスし、認可コードを提示する。

【0147】

Ｐ８９（認可コードの確認）：トークンサーバ４００は、クライアントアプリ２０から提示された認可コードが正当であるかを照合する。照合に失敗した場合、ここで処理を中断する。

【0148】

Ｐ９０（トークンの取得）：照合に成功した場合、トークンサーバ４００は、新たにトークンを生成し、生成したトークンをクライアントアプリ２０に返送する。

【0149】

Ｐ９１（クライアントアプリ証明書の送信）：クライアントアプリ２０は、トークンの書き込みに先立って、セキュアなコンポーネント５０に対してクライアントアプリ証明書２１を送信する。

【0150】

Ｐ９２（クライアントアプリ証明書の検証）：セキュアなコンポーネント５０は、クライアント検証機能６４を呼び出し、自身が保持しているクライアント検証鍵（公開鍵）７４を用いて、送信されたクライアントアプリ証明書２１を検証する。具体的には、セキュアなコンポーネント５０は、クライアントアプリ２０のハッシュ値を計算し、計算したハッシュ値と、クライアントアプリ証明書２１に含まれる暗号化ハッシュ値を復号して得た値とを比較し、一致していることを確認する。不一致の場合、クライアントアプリ２０は不正なクライアントアプリであるとみなし、ここで処理を終了する。

【0151】

Ｐ９３（トークンの保存）：クライアントアプリ証明書の検証が成功した場合、クライアントアプリ２０は、セキュアなコンポーネント５０に対してトークンの書き込みを行う。セキュアなコンポーネント５０は、クライアントアプリ証明書の検証が完了していることを確認した上で、トークンを内部に保存する。

【0152】

Ｐ９４（トークンの取得要求）：クライアントアプリ２０は、リソース３０１を使用する際に、セキュアなコンポーネント５０に対してトークンの取得を要求する。このとき、Ｐ９２で行った、クライアントアプリ証明書の検証を再度実施する。

【0153】

Ｐ９５（トークンの取得）：クライアントアプリ証明書の検証が成功した場合、セキュアなコンポーネント５０は、クライアントアプリ２０に対して、保存しているトークンを返送する。

【0154】

Ｐ９６（リソースへのアクセス（Ｗｉｔｈトークン））：クライアントアプリ２０は、セキュアなコンポーネント５０から取得したトークンを添付して、リソースサーバ３００に対してリソース３０１へのアクセスを要求する。

【0155】

Ｐ９７（トークンの確認）：リソースサーバ３００は、トークンサーバ４００に対して、クライアントアプリ２０から受領したトークンの正当性を確認する。トークンが正当でない場合、クライアントアプリ２０からのアクセスを拒否し、ここで処理を終了する。

【0156】

Ｐ９８（リソースの提供）：トークンが正当な場合、リソースサーバ３００は、クライアントアプリ２０にリソース３０１へのアクセスを提供する。

【0157】

上述の実施例によれば、不正なアプリによって、トークンの不正な設定や搾取を防止できる。

【0158】

クライアント検証鍵（公開鍵）７４は、セキュアなコンポーネント５０に予め保持されており、一般のユーザがクライアント検証鍵（公開鍵）７４を変更することはできない。また、リプレイアタックを防止するため、クライアントアプリ２０のハッシュ値計算は、セキュアなコンポーネント５０自身が直接計算することが望ましい。なお、クライアントアプリ証明書２１によるクライアント認証は一例であって、これに限定されるものではなく、他のどのような方法でクライアント認証を行ってもよい。

【0159】

以上のとおり、ＩｏＴデバイス１００側にセキュアなコンポーネント５０を組み込むことにより、ＩｏＴデバイス１００上で適切にセキュリティを維持したまま、認可メカニズムを利用することができる。一方で、ＩｏＴデバイス１００のセキュリティを維持するためには、内部に保持する鍵や各機能などの内部状態を適切に保守管理し、必要に応じて当該内部状態を更新できることが望ましい。以下では、ＩｏＴデバイス１００の内部状態の更新について説明する。

【0160】

図８は秘匿通信路による外部管理の例を示す説明図である。以下、符号Ｐ１０１～Ｐ１０６で示す処理について説明する。

【0161】

Ｐ１０１（ＩｏＴデバイスの電源投入）：デバイス管理者がＩｏＴデバイス１００を使用するためＩｏＴデバイス１００に電源を投入する。

【0162】

Ｐ１０２（セキュアなコンポーネントへの状態確認指示）：ＩｏＴデバイス１００は、電源が投入されると、セキュアなコンポーネント５０に対して内部状態の更新が必要かどうか、状態確認指示を行う。

【0163】

Ｐ１０３（秘匿通信路開設機能の呼び出し）：セキュアなコンポーネント５０は、状態確認指示を受けて、自身の内部の秘匿通信路開設機能６５を呼び出す。

【0164】

Ｐ１０４（秘匿通信路の開設）：秘匿通信路開設機能６５は、セキュアなコンポーネント管理サーバ５００に対して秘匿通信路を開設する。ここでは、ＴＬＳ（Transport Layer Security）通信を想定しているが、他の通信プロトコルを用いたセキュアチャネルを使用してもよい。セキュアなコンポーネント５０が自らネットワーク通信機能を持たない場合は、ＩｏＴデバイス１００の通信機能を使用してもよい。ただし、秘匿通信路のエンドポイントは、あくまでもセキュアなコンポーネント５０とセキュアなコンポーネント管理サーバ５００の間である。

【0165】

Ｐ１０５（更新対象コンテンツの準備）：セキュアなコンポーネント管理サーバ５００は、秘匿通信路開設を受けて、更新すべきコンテンツを準備する。本実施例では、例えば、トークン暗号化鍵の危殆化に備え、新たな鍵の更新を行うものとする。なお、更新対象は、トークン暗号化鍵に限定されない。セキュアなコンポーネント管理サーバ５００は、更新対象となる鍵の生成、準備を行う。

【0166】

Ｐ１０６（コンテンツの送信）：セキュアなコンポーネント管理サーバ５００は、秘匿通信路経由でセキュアなコンポーネント５０に対してコンテンツを送信する。ここでは、セキュアなコンポーネント管理サーバ５００は、トークン暗号化鍵７２をセキュアなコンポーネント５０に送信している。本実施例のように、対向するコンテンツが他のサーバ上に存在する場合は、当該サーバに対して別途秘匿通信路を開設して更新を行うことができる。ここでは、トークンサーバ４００に対して秘匿通信路を開設し、トークン復号鍵４２１の更新を同時に行う。

【0167】

これにより、セキュアなコンポーネント５０のトークンに関する機能又は状態を遠隔で更新することができ、ＩｏＴデバイス１００のセキュリティを維持することができる。

【0168】

上述の実施例では、鍵の更新について例示したが、更新対象は鍵に限定されるものではなく、セキュアなコンポーネント５０が保持している任意のコンテンツを更新することができる。例えば、セキュアなコンポーネント５０がＪａｖａ Ｃａｒｄ（商標）プラットフォームをサポートしたセキュアエレメントの場合、各種処理（暗号化処理、生成処理、署名検証処理等）がＪａｖａ Ｃａｒｄアプレットとして実装されていれば、アプレットの更新により各種機能を更新することができる。また、トークンに関する機能の有効化・無効化を切り替えるフラグを用意するような実施例の場合、当該フラグを秘匿通信路経由で更新することで、遠隔から認可機能の有効・無効を切り替えることが可能となる。また、本実施例では、更新を確実に行うため、電源投入を遠隔管理のトリガとしているが、これに限定されるものではなく、クライアントアプリの起動、ＩｏＴデバイス上の他のアプリの動作など、他のアクションをトリガとしてもよい。

【0169】

本実施の形態の認可に基づくリソースアクセス制御システムは、ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、クライアントが動作するデバイスとを備え、前記デバイスは、前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報を記憶するセキュアなコンポーネントを備え、前記クライアントは、前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、前記リソースサーバは、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【0170】

本実施の形態のセキュアなコンポーネントは、クライアントが動作するデバイスに実装されるセキュアなコンポーネントであって、認可サーバが、ユーザ認証結果に基づいてリソースに対するアクセスを認可した結果、所定のサーバが発行するトークン情報を前記クライアントから取得して記憶し、前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバへ記憶したトークン情報を送信するために、前記記憶したトークン情報を前記クライアントへ出力する。

【0171】

本実施の形態のデバイスは、前述のセキュアなコンポーネントを備え、クライアントが動作する。

【0172】

本実施の形態の認可に基づくリソースアクセス制御方法は、ユーザ認証結果に基づいてリソースに対するアクセスを認可する認可サーバと、前記認可サーバの認可結果に基づいてアクセスが制御されるリソースを有するリソースサーバと、クライアントが動作するデバイスとを備えるシステムの認可に基づくリソースアクセス制御方法であって、前記デバイスは、前記認可サーバがリソースに対するアクセスを認可した結果、前記クライアントが取得する、所定のサーバが発行するトークン情報をセキュアなコンポーネントに記憶し、前記クライアントは、前記セキュアなコンポーネントに記憶したトークン情報を前記リソースサーバへ送信し、前記リソースサーバは、前記トークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【0173】

認可サーバは、ユーザ認証結果に基づいてリソースに対するアクセスを認可する。リソースサーバは、認可サーバの認可結果に基づいてアクセスが制御されるリソースを有する。デバイス（ＩｏＴデバイスとも称する）は、クライアント（クライアントアプリケーション）が動作する。デバイスは、認可サーバがリソースに対するアクセスを認可した結果、クライアントが取得する、所定のサーバが発行するトークン情報を記憶するセキュアなコンポーネントを備える。

【0174】

すなわち、クライアントは、所定のサーバが発行するトークン情報を取得し、取得したトークン情報をデバイス内のセキュアなコンポーネントに記憶する。これにより、デバイスの長期稼働において、所定のサーバ（例えば、トークンサーバ）から取得した有効なトークン情報を保持し続けるリスク（例えば、漏洩等のセキュリティリスク）を低減しつつ、再認証やトークン情報の更新に必要となる通信トラフシックを削減することができる。

【0175】

クライアントは、セキュアなコンポーネントに記憶したトークン情報をリソースサーバへ送信する。リソースサーバは、トークン情報の検証結果に基づいてクライアントのリソースへのアクセスを制御する。すなわち、検証が成功すれば、クライアントはリソースにアクセスすることができる。これにより、発行されたトークン情報を長期間に亘って安全に保護することができる、認可に基づくリソースアクセス制御システムを実現できる。

【0176】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、トラステッド実行環境又はセキュアエレメントである。

【0177】

本実施の形態のセキュアなコンポーネントは、トラステッド実行環境又はセキュアエレメントである。

【0178】

セキュアなコンポーネントは、トラステッド実行環境又はセキュアエレメントである。トラステッド実行環境は、ＳｏＣ（System on Chip）上で、例えば、ＣＰＵ仮想化支援技術（例えば、ＴｒｕｓｔＺｏｎｅ（登録商標））と称される技術を用いることによって、ＳｏＣ内で区分された領域（いわゆるＴＥＥ：Trusted Execution Environment）を指し、通常実行環境（ＲＥＥ：Rich Execution Environmentとも称する）よりもセキュアな領域である。セキュアエレメントは、耐タンパ性を有するセキュリティチップで構成することができる。これにより、発行されたトークン情報を長期間に亘って安全に保護することができる。また、トークン情報を頻繁に更新する必要もなく、トークン情報を無効にするための作業時間を設定する必要もない。

【0179】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、前記クライアントが取得したトークン情報の正当性を検証するトークン検証機能を備え、検証が成功した場合、前記トークン情報を記憶する。

【0180】

本実施の形態のセキュアなコンポーネントは、前記クライアントから取得したトークン情報の正当性を検証するトークン検証機能を備え、検証が成功した場合、前記トークン情報を記憶する。

【0181】

セキュアなコンポーネントは、クライアントが取得したトークン情報の正当性を検証し、検証が成功した場合、トークン情報を記憶する。すなわち、セキュアなコンポーネントがトークン情報を記憶する際、トークン情報の正当性を確認する。これにより、不正なトークン情報の挿入によるトークン情報の置き換え攻撃などのトークン情報の改ざん等を防止することができる。

【0182】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、内部に保有する情報及び記憶したトークン情報を用いて新たなトークン情報を生成するトークン生成機能を備え、前記クライアントは、前記新たなトークン情報を前記リソースサーバへ送信し、前記リソースサーバは、前記新たなトークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【0183】

本実施の形態のセキュアなコンポーネントは、内部に保有する情報及び記憶したトークン情報を用いて新たなトークン情報を生成するトークン生成機能を備え、前記新たなトークン情報を前記リソースサーバへ送信するために、前記新たなトークン情報を前記クライアントへ出力する。

【0184】

セキュアなコンポーネントは、内部に保有する情報及び記憶したトークン情報を用いて新たなトークン情報を生成する。内部に保有する情報は、新たなトークン情報を生成するための秘匿情報であれば、例えば、固有のＩＤ、トークン情報生成回数を記録するカウンタ値や乱数要素など、どのような情報を用いてもよい。

【0185】

クライアントは、新たなトークン情報をリソースサーバへ送信する。リソースサーバは、新たなトークン情報の検証結果に基づいてクライアントのリソースへのアクセスを制御する。すなわち、検証が成功すれば、クライアントはリソースにアクセスすることができる。このように、クライアント側でトークン情報を動的に生成し、リソースサーバで当該トークン情報を検証することにより、トークン情報の再利用（トークン情報を用いたリプレイアタック）やなりすまし等を防止できる。

【0186】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、内部に保有する鍵を用いて改ざん検知コードを生成する検知コード生成機能を備え、前記クライアントは、前記新たなトークン情報に前記改ざん検知コードを付加して前記リソースサーバへ送信し、前記リソースサーバは、前記改ざん検知コードの検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【0187】

本実施の形態のセキュアなコンポーネントは、内部に保有する鍵を用いて改ざん検知コードを生成する検知コード生成機能を備え、前記改ざん検知コードを付加した前記新たなトークン情報を前記リソースサーバへ送信するために、前記改ざん検知コードを付加した前記新たなトークン情報を前記クライアントへ出力する。

【0188】

セキュアなコンポーネントは、内部に保有する鍵を用いて改ざん検知コードを生成する。クライアントは、新たなトークン情報に改ざん検知コードを付加してリソースサーバへ送信する。リソースサーバは、改ざん検知コードの検証結果に基づいてクライアントのリソースへのアクセスを制御する。すなわち、検証が成功すれば、クライアントはリソースにアクセスすることができる。

【0189】

改ざん検知コードの付与を行うことにより、セキュアなコンポーネントの内部に保有する鍵（秘密鍵）を知らない攻撃者は改ざん検知コードを計算することができず、トークン情報の検証側で改ざん検知コードの検証を行うことができない。これにより、トークン情報の偽造や改ざんを防止できる。

【0190】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、内部に保有する暗号化鍵を用いて前記新たなトークン情報を暗号化するトークン暗号化機能を備え、前記クライアントは、暗号化されたトークン情報を前記リソースサーバへ送信し、前記リソースサーバは、前記暗号化されたトークン情報を復号して得られた前記新たなトークン情報の検証結果に基づいて前記クライアントのリソースへのアクセスを制御する。

【0191】

本実施の形態のセキュアなコンポーネントは、内部に保有する暗号化鍵を用いて前記新たなトークン情報を暗号化するトークン暗号化機能を備え、暗号化されたトークン情報を前記リソースサーバへ送信するために、前記暗号化されたトークン情報を前記クライアントへ出力する。

【0192】

セキュアなコンポーネントは、内部に保有する暗号化鍵を用いて新たなトークン情報を暗号化する。クライアントは、暗号化されたトークン情報をリソースサーバへ送信する。リソースサーバは、暗号化されたトークン情報を復号して得られた新たなトークン情報の検証結果に基づいてクライアントのリソースへのアクセスを制御する。すなわち、セキュアなコンポーネントとリソースサーバとが対向する鍵を保持し、動的に生成されたトークン情報に暗号化技術を適用して保護する。

【0193】

トークン情報は、暗号化されているため、偽造や解読が困難であり、トークン情報の構造を攻撃者に把握されるリスクを無くし、トークン情報の改ざんによるリソースの不正使用を防止できる。

【0194】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、前記クライアントを認証するクライアント認証機能を備え、前記クライアントの認証結果に応じて、前記クライアントとの間での前記トークン情報の授受の可否を決定する。

【0195】

本実施の形態のセキュアなコンポーネントは、前記クライアントを認証するクライアント認証機能を備え、前記クライアントの認証結果に応じて、前記クライアントとの間での前記トークン情報の授受の可否を決定する。

【0196】

セキュアなコンポーネントは、クライアントを認証し、クライアントの認証結果に応じて、クライアントとの間でのトークン情報の授受の可否を決定する。すなわち、クライアントが、トークン情報をセキュアなコンポーネントに記憶する場合、あるいは、クライアントが、セキュアなコンポーネントからトークン情報を取り出す場合、セキュアなコンポーネントは、要求元のクライアント（アプリ）を認証する。これにより、不正なアプリによって、トークン情報の不正な設定や搾取を防止できる。

【0197】

本実施の形態の認可に基づくリソースアクセス制御システムにおいて、前記セキュアなコンポーネントは、外部のサーバとの間で秘匿通信路を開設する開設機能を備え、前記セキュアなコンポーネントの内部機能、及び前記セキュアなコンポーネントが内部に保有する情報又は鍵の少なくとも一部が前記外部のサーバから更新可能である。

【0198】

本実施の形態のセキュアなコンポーネントは、外部のサーバとの間で秘匿通信路を開設する開設機能を備え、前記セキュアなコンポーネントの内部機能、及び前記セキュアなコンポーネントが内部に保有する情報又は鍵の少なくとも一部が前記外部のサーバから更新可能である。

【0199】

セキュアなコンポーネントは、外部のサーバとの間で秘匿通信路を開設する開設機能を備える。セキュアなコンポーネントの内部機能、及びセキュアなコンポーネントが内部に保有する情報又は鍵の少なくとも一部が外部のサーバから更新可能である。すなわち、セキュアなコンポーネントが開設した秘匿通信路経由でセキュアなコンポーネントの内部状態を変更することができる。これにより、セキュアなコンポーネントのトークン情報に関する機能又は状態を遠隔で更新することができ、デバイスのセキュリティを維持することができる。

【符号の説明】

【0200】

１０ ブラウザ
２０ クライアントアプリ
２１ クライアントアプリ証明書
５０ セキュアなコンポーネント
５１ ＳＥ（ＴＥＥ）ＩＤ
５２ カウンタ
５３ トークン
６０ トークン生成機能
６１ トークン署名検証機能
６２ トークン暗号化機能
６３ トークンＭＡＣ付与機能
６４ クライアント検証機能
６５ 秘匿通信路開設機能
７１ トークン署名検証鍵（公開鍵）
７２ トークン暗号化鍵
７３ トークンＭＡＣ鍵
７４ クライアント検証鍵（公開鍵）
１００ ＩｏＴデバイス
２００ 認可サーバ
２０１ 認可コード
３００ リソースサーバ
３０１ リソース
４００ トークンサーバ
４０１ ＳＥ（ＴＥＥ）ＩＤ
４０２ カウンタ
４０３ トークン
４１０ トークン正当性確認機能
４１１ トークン署名生成機能
４１２ トークン復号機能
４１３ トークンＭＡＣ検証機能
４２０ トークン署名生成鍵（秘密鍵）
４２１ トークン復号鍵
４２２ トークンＭＡＣ検証鍵
５００ セキュアなコンポーネント管理サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】