第 3 章 ポリシ流通を基本とする 自律的資源利用認証方式自律的資源利用認証方式
3.3 システム設計
図
3.3
で示した機能配置図を前提とした場合の処理シーケンスは以下のよう になる．①利用者は，必要に応じてサービス提供者装置から利用権を取得して，IC カー ドの利用権管理により一時保管する．
②利用者は，資源の
PEP
に対して資源利用要求を出す．PEP は，Contexthandler
を経由してPDP，PIP
に行使判定処理を依頼する．③PDPは，PEPからの依頼により
IC
カードの利用権管理から利用権を取り出 す．④PIPは，
PEP
からの依頼によりIC
カードの利用者属性管理から利用者属性を，資源の資源属性管理から資源属性を収集し，PDPに通知する．
⑤PDPは，取得した利用権内のアクセス制御ポリシと
PIP
から通知された属性 情報により行使判定を行う．⑥判定結果は，Context handlerを通じて
PEP
に伝達され，判定結果に応じた サービスが利用者に提供される．PEP
の実行に際しては，責務（Obligation）を与えることがある．たとえば「必要なメッセージを要求者に伝えなさい」， あるいは，「指定した時間のみサービスを提供しなさい」などである．
29
正しい行使判定を可能にするためには，アクセス制御ポリシや各属性の管理主 体やその役割を明確にしたフレームワークが必要である【システム化要件
1】
． 行使判定時に，通常はIC
カード内に管理されている利用者属性を資源に提示 する必要がある．この際，正当なサービス提供者を装った悪意のあるサービス 提供者への利用者属性の漏洩を防ぐことができる仕組みが必要である【システ ム化要件2】
．それにより，【要件5】レベル 1
のプライバシ保護要件を満足させ る．また，この時，利用者属性は，無線／有線を問わず何らかの通信手段で，利用者の持つ
IC
カードから資源に送信される．そのため，通信路上での情報の 盗み見を防止する必要がある【システム化要件3】
．さらに，利用権の複製や偽 造などの利用権の不正利用を防止できる仕組みが必要である【システム化要件4]．これは，利用権の取得や行使など利用権がサービス提供者装置， IC
カード，資源間の通信路上を流通する際に盗み見の可能性があるためである．
3.3.2. 自律的資源利用認証フレームワーク
【システム化要件１】を満足するための自律的資源利用認証フレームワークを 図
3.4
に示す．また，各プレーヤの役割を表3.1
に示す．本フレームワークの特 徴は，以下の通りである．・利用者属性管理者やサービス提供者は他者が発行した
IC
カードに管理用のア プリケーションを搭載できること・利用者属性や資源属性を管理する主体と行使判定をする主体が異なるため適 正な判定を保証できること
・それぞれのプレーヤが保証すべき情報の管理や行使判定のための機能は，そ れぞれ同一の信頼ツリー下にある．そのため，それらが，ICカードや資源に 分散されても，行使判定処理に先立ち相互認証による正当性検証が可能であ ること．
IC card Issuer
Registration Authority
User Attribute Manager
( Server)
Use-right Policy Management IC card
Service Provider ( Server)
Resource Attribute Manager
( Server)
Resource Decision
Handler User
Attribute Management
Resource Attribute Management
Embedding Embedding
AP downloading / Use-right Policy issuing AP download /
User Attribute updating
Issuing
Setting AP download
permission
AP download permission
図
3.4 自律的資源利用認証フレームワーク
表
3.1 各プレーヤの役割
プレーヤ Player
役割 Role 登録認定局
Registration Authority
フレームワークに登場する各プレーヤの正当性を保証する主体．
各プレーヤに公開鍵証明書を発行．
ICカード発行者 IC card Issuer
ICカードを発行する主体．
利用者属性管理者 User Attribute Manager
利用者属性の正当性を保証する主体．
利用者属性に電子署名しUser Attribute Managementに格納．
サービス提供者 Service Provider
利用権を発行し，資源の一時利用サービスを提供する主体．利用権 の正当性，及びその行使判定結果の正当性を保証する主体．
資源属性管理者 Resource Attribute Manager
資源属性の正当性を保証する主体．
資源属性に電子署名しResource Attribute Managementに格納．
31
3.3.3. アクセス制御フレームワーク
本研究では，利用者が始めて訪れた外出先などで，資源を一時利用するよう な利用シーンを想定している．そのため，利用者自身がその場で対象資源のサ ービス提供者の良否を判断することは困難である．そこで，本研究では，利用 者から委任された利用者属性管理者が，利用者に代わってサービス提供者への 属性情報の開示可否を制御するモデルを採用した．これにより【システム化要 件２】を満足させる．また，その具体的な仕組みとして，アクセス許可証(Access
Permission License)を用いた属性情報へのアクセス制御フレームワーク（図 3.5）を導入した．アクセス制御フレームワークに基づいた利用者属性を開示す
る手順を以下に示す．IC card Attribute Information
User Attribute Management
Access Control
Registration Authority User Attribute
Manager
（Server）
Access Permission License
Service Provider
（Server）
Downloading
Decision Handler
Resource
Embedding
User Attribute acquisition
図 3.5 アクセス制御フレームワーク
①利用者属性管理者は，サービス提供者を事前に審査することにより，属性情 報を開示可能なサービス提供者を決定する．
②開示対象となる属性情報や読み書きなどのアクセス権限情報などが記述され たアクセス許可証がサービス提供者へ発行される．これには，利用者属性管 理者の電子署名が施されている．
③サービス提供者は，アクセス許可証が含まれる判定ハンドラを資源に埋め込 む．
④行使判定時，判定ハンドラは，該当するアクセス許可証を利用者属性管理に 提示する．
⑤利用者属性管理（User Attribute Management）のアクセス制御部(Access
Control)は，アクセス許可証の署名検証によりアクセス許可証の正しさを検
証する．その後，アクセス権限に従った属性情報(Attribute Information)へ のアクセスを許可する．このモデルは，利用者の属性情報を管理する利用者属性管理者に信頼の基点 をおいている．つまり，その利用者属性管理者が信頼するサービス提供者にの み利用者属性を開示することで，利用者属性が無制限に開示されてしまうこと を防止している．これにより，利用者属性管理者から信頼されないサービス提 供者は排除可能である．しかし，利用者属性管理者が許可した正当なサービス 提供者には，利用者属性は開示される．そのため，利用者は，開示される利用 者属性について，利用者属性管理者と合意を取ることが条件となる．
なお，手順②，③のアクセス許可証取得シーケンスを図
3.6
に，手順④，⑤の 利用者属性取得シーケンスを図3.7
に示す．図3.6，3.7
における略記号の意味 は以下の通りである．UAMS: User Attribute Manager Server SPS: Service Provider Server
RA: Registration Authority
UAM: User Attribute Management in IC card
33
また，公開鍵，秘密鍵，公開鍵証明書，アクセス許可証の図中の表記方法，
及び構成は以下の通りである．
P(X)
Y: public key of X issued by Y, S(X)
Y: secret key of X issued by Y,
CP(X)
Y: public key certificate of X signed by Y,
L<X, Y>
X: Access Permission License for Y signed by X
・P(SPS)RA,S(SPS)RA
・P(RA) RA
・CP(SPS)RA CP(UAMS)RA
CP(SPS)RA
Access permission license creating
L<P(UAMS)RA, P(SPS)RA>UAMS
User Attribute Manager Server (UAMS)
Service Provider Server (SPS)
Mutual authentication &
Encrypted Channel Establishment
Public-key certification exchange
Public-key certification exchange
・P(UAMS)RA,S(UAMS)RA
・P(RA) RA
・CP(UAMS)RA
Mutual authentication &
Encrypted Channel Establishment
Symmetric Key
・P(SPS)RA, S(SPS)RA
・P(RA) RA
・CP(SPS)RA
・P(UAMS)RA
・L<P(UAMS)RAP(SPS)RA>UAMS
Decision Handler Embedding
Decision
Handler図
3.6 アクセス許可証取得シーケンス
アクセス許可証取得シーケンスにおいては，信頼起点である登録認定局がそ れぞれ発行した公開鍵証明書による相互認証後，共通鍵（Symmetric Key）を 交換して，暗号通信路が構築される．その後，User Attribute Manager Server において，アクセス許可証が生成され，署名を施されて
Service Provider Server
に送信される．Service Provider Server では，相互認証時に取得したUser
Attribute Manager Server
の公開鍵（P(UAMS)RA）でアクセス許可証を検証す る．アクセス許可証は，Registration Authority
の公開鍵（P(RA) RA），Service Provider Server
の公開鍵（P(SPS)RA），秘密鍵（S(SPS)RA），公開鍵証明書（CP(SPS)RA），及び
User Attribute Manager Server
の公開鍵とともに，Decision Handler
に埋め込まれる．Decision Handler (Resource) User Attribute Management
(IC card)
Signature verification by P(UAMS)RA
Delegation verification
CP(UAM)UAMS
CP(SPS)RA
Public-key certification exchange
Public-key certification exchange
・P(UAM)UAMS, S(UAM)UAMS
・P(RA) RA
・P(UAMS)RA
・CP(UAM)UAMS
User Profile
・P(SPS)RA, S(SPS)RA
・P(RA) RA
・CP(SPS)RA
・P(UAMS)RA
・L<P(UAMS)RAP(SPS)RA>UAMS
L<P(UAMS)RA, P(SPS)RA>UAMS
Mutual authentication &
Encrypted Channel Establishment
Mutual authentication &
Encrypted Channel Establishment
Symmetric Key
図
3.7 利用者属性取得シーケンス
Access Control
が実装されるUser Attribute Management
は，図3.4
に示し たようにUser Attribute Manager Server
がIC
カードに埋め込む．その際，Registration Authority
の公開鍵，User Attribute Manager Server
が発行するUser Attribute Management
の公開鍵（P(UAM)UAMS），秘密鍵（S(UAM)UAMS）， 公開鍵証明書（CP(UAM)UAMS），及びUser Attribute Manager Server
の公開 鍵が埋め込まれる．利用者属性取得シーケンスにおいては，User Attribute35
Management
とDecision Handler
の間でそれぞれの公開鍵証明書が交換され て相互認証が行われる．この際，User Attribute Management からは，UserAttribute Manager Server
の署名が施された公開鍵証明書が送付される．Decision Handler
には，アクセス許可証取得シーケンスにおいて取得したUser Attribute Manager Server
の公開鍵が格納されているため，この公開鍵証明書 の検証が可能である．その後，暗号通信路が構築され，アクセス許可証が送付 される．送付されたアクセス許可証は，Registration Authority
が発行したUser Attribute Manager Server
の公開鍵で検証される．その結果に基づき，利用者 属性がDecision Handler
に送付される．3.3.4. オンデマンド暗号通信路
【システム化要件３】を阻害するセキュリティ脅威は，
IC
カードから資源に利 用者属性が送信される時の通信路上の情報の盗み見である．また，【システム化 要件４】を阻害するセキュリティ脅威は，利用権発行の際のサービス提供者装 置とIC
カード間の通信路と，行使判定の際のIC
カードと資源間の通信路上の 盗み見による利用権の不正利用である．そこで，これらの脅威を排除するため に，サービス提供者装置－ICカード間，IC
カード－資源間で，暗号通信路をオ ンデマンドで構築することとした．暗号通信路は，それぞれの公開鍵証明書を 交換し，図3.4
に示した自律的資源利用認証フレームワークに基づいた相互認証 実施後，共通鍵を交換することで構築される．オンデマンド暗号通信路構築手順（図