考察

本章で提案している分散認証認可方式は，

3

章で示した自律的資源利用認証方 式におけるプライバシ保護機能を強化する方式である．そのため，主にプライ バシ保護の観点，安全性の観点の議論を通して，提案方式を考察する．

4.5.1. プライバシ保護の観点

（１）既存研究と課題

2.3

節でプライバシ問題を解決する方式として，本人性情報を含まない権限証 明書や属性証明書を利用する既存研究を示した．たとえば，

SPKI

（Simple Public

Key Infrastructure）の証明書[16]は，ID

を含まない権限証明書の一種であり

ID

の漏洩防止が可能となる．

文献[17]では，権限証明書を用いた

SSL

相互認証による匿名アクセス制御方 式を提案している．また,本人情報が含まれない属性証明書のみを利用する方式

[19][20][21]や権限証明書と属性証明書の両方を用いる方式 [22]が提案されて

いる．このような仕組みが可能なのは，本人性認証にもとづく権限・属性証明 書の発行フェーズと，その証明書の検証にもとづくサービス利用フェーズの分 離を実現しているためである．これは，利用者，サービス提供者，権限・属性 認証者の

3

者モデルを前提としているためである．これにより，権限・属性認 証者，サービス提供者双方に対して，利用者のサービス利用状況の秘匿を可能 としている．ただし，証明書発行フェーズと利用フェーズが異なるため，サー ビス提供者は，その証明書を保持している利用者が正しい利用者なのかを確認 できる必要がある．ここでは，これを保持証明とよぶ．

保持証明の方式としては，これまで，公開鍵を用いる方式と共通鍵を用いる 方式が提案されている．ただし，これらの鍵が固定的であるとすると，その鍵 から，権限や属性が関連付けられてしまう可能性がある．この問題に関して，

文献[17][22]では，権限や属性ごとに異なった公開鍵を利用し，証明書毎に，そ

れらの鍵を使い捨てにすることを提唱している．しかし，この場合，公開鍵ペ アの生成コストの軽減が課題となる．

また，文献[19] [20] [21]では，公開鍵よりも鍵生成コストが低い証明書毎に異 なる共通鍵や仮

ID

を用いた保持証明を提案している．しかし，これらの方式で は，事前に属性認証者から共通鍵を用いた認証情報をサービス提供者に送付す る必要がある．また，共通鍵を用いた保持証明のための特別なプロトコルを実 装する必要がある．そのため，図書閲覧サービスなど，ある程度サービス利用 範囲が限定されるケースや高機能なクライアント端末を利用できることが前提 となっている．そのため，本研究が対象としている公共環境に遍在している資 源を不特定多数の利用者が一時利用するような利用形態には適していない．さ らに，これらの方式では，匿名であってもサービス提供者へ利用者属性を開示 する．そのため，利用者側の心理的問題が，サービス普及の障害になることは 否めない．これらより，以下の２つが既存研究の課題である．

・３者モデルにおける保持証明の簡易化

・利用者属性開示に伴う心理的負担の軽減

（２）分散認証認可方式の特徴とその優位性

一方，分散認証認可方式においても，3 者モデルを基本としているところは，

同じである．しかし，実装方式と認証認可プロトコルが異なる．既存研究では，

権限・属性認証者による利用者認証，及び証明書発行機能を特定サーバに集約 していた．一方，提案方式では，利用者が携帯する IC カード上に分散配置して いる．

利用者属性とその属性に基づいた属性認証機能を IC カード上に実装し，利用 者属性に関するアクセス制御ポリシが利用権の形で外部から与えられる．そし て，その利用者の属性がアクセス制御ポリシに合致しているかどうかの判定が IC カード内で実行される．これは,既存研究のようにプライバシ情報が記された 証明書をサービス提供者に提示することを不要にしている．つまり，アクセス

87

制御ポリシに合致しているか否かの認証結果のみの通知によるサービス利用を 可能としている．

既存研究では，権限・属性認証者が発行した証明書が利用者の手に委ねられ てしまう方式である．そのため，利用者の追跡が不可能な保持証明を実装する 必要があった．しかし，提案方式では，アクセス制御ポリシが記述された利用 権は，発行サーバから暗号通信路を通して，利用者の所持する IC カード内の利 用者属性管理者が管理する領域（User Policy Decision）に格納される．そこ で属性認証が実施され，その結果が User Policy Assertion として，サービス 認可装置に通知される．そのため，利用者が関与できない．つまり，保持証明 に関しては，正しい利用者が正しい IC カードを保持していることの証明（IC カ ード保持証明と呼ぶ）に置き換えることができる．

これは，User Policy Decision を起動する際に指紋認証などの生体認証を付 加することで解決できる．IC カード保持証明により，サービス提供者がサービ ス提供時に正しい利用者属性管理者が発行した User Policy Assertion である ことを署名検証により確認するだけでよい．そのため，従来の保持証明のため に必要だった証明書毎の使い捨て公開鍵ペアや共通鍵を用いた特別なプロトコ ルを用いなくてもよいという利点がある．もちろん，この場合，IC カード保持 証明は，User Policy Decision を起動するフェーズに閉じており，サービス提 供者には伝えられない．

また，サービス提供者がサービス提供時に知りえるのは，正しい利用者属性 管理者の User Policy Decision かどうかだけである．これは，利用者属性管理 者が多くの利用者の属性を管理しているという想定においては，サービスの利 用履歴から個人を追跡することは現実的でない．

一方，デジタル署名を拡張したグループ署名と呼ばれる匿名認証技術[40]が 提案されている．これは，認証時にある特定のグループに所属しているかどう かをグループ署名により検証する方式であり，保持証明が不要で，かつ匿名性 が維持される方式である．しかし，グループ署名は，通常のデジタル署名の 10

倍以上の計算量[41]が必要であり，専用の LSI を具備した IC カードや携帯電話 [42]での利用が前提となる．

以上より，利用者属性を秘匿した上でアクセス制御が実施できる点，煩雑な保 持証明を実装する必要が無い点，汎用の暗号処理プロセッサを具備した IC カー ドが利用できる点において既存研究よりも優位である．

4.5.2. 安全性の観点

セキュリティ脅威としては，

・ 利用権の不正利用

・ User Policy Assertion の不正利用

・ 利用者属性漏洩によるプライバシ侵害

・ 分散認証認可に関する各種情報の改ざん

が考えられる．「利用権の不正利用」に関しては，利用権を不正に入手して利用 される場合と，利用者属性の未更新や失効による不正判定がされてしまう場合 に分類できる．

「不正入手」に関しては，利用権発行時に，正当でない利用者に利用権を渡し てしまうケース，通信路上からの漏洩によるケース， IC カードやサービス提供 者サーバなどの装置から漏洩するケースが考えられる．提案方式では，利用権 発行時にサービス提供者サーバ－IC カード間で，相互認証実施後，暗号通信路 を構成することとしている．これにより，不正な利用者を排除し，通信路から の漏洩を防止することが可能である．また，IC カードは，耐タンパ性があるこ とが前提のため漏洩の危険性は低い．サービス提供者サーバに関しては，デー タセンタなどの管理された領域に設置することで，盗難などによる漏洩のリス ク低減が可能である．

「不正判定」に関しては，今回，利用権取得時に，利用者属性管理者による最 新の利用者属性確認日をチェックすることとした．これにより，規定日数を超 えている場合，警告や利用制限を行うことで，正しくない利用者属性により不 正な判定を防止できる仕組みを提案している．ただし，この場合，規定日数が

89

長くなれば，利用者属性確認に関わる利用者負担は小さくなる．しかし，不正 判定のリスクが大きくなり，短くなればその逆となる．つまり，利用者負担と 不正判定のリスクはトレードオフの関係になる．

今回想定している利用シーンは，カーシェアリングや無線 LAN 等の一時利用 の際に，利用者の属性に応じてサービスレベルを可変にすることである．つま り，一時的な利用であっても，個々の利用者に合わせたサービスを提供するこ とが目的である．そのため，仮に異なるサービスレベルがある限定された期間 提供されたとしても，サービス提供者，利用者にとってよりメリットが大きい と考える．これは，これまでより多くの利用者にその利用者に合わせたサービ スを提供できるという利点の方がが大きいためである．ただし，認証局が証明 書の失効情報を配布するケースと比較すると利用者属性の不整合の期間が長く なる可能性がある．そのため，提供するサービス種別や利用制限規定日数の決 め方については，注意が必要である．

「User Policy Assertion の不正利用」に関しては，サービス利用時に，正当 でないサービス認可装置に User Policy Assertion を渡してしまうケース，通 信路上からの漏洩によるケース，サービス認可装置から漏洩するケースが考え られる．提案方式では，サービス利用時に，IC カードとサービス認可装置間で，

相互認証実施後，それぞれ署名が施された利用権 ID や乱数を交換する．これに より，不正なサービス認可装置を排除する．さらに，仮に User Policy Assertion が通信路で盗み見されても，乱数のチェックによりセッションリプレイの抑止 が可能である．サービス認可装置からの漏洩に関しては，仮に漏洩しても User Policy Assertion を用いたセッションリプレイは不可能なので，サービス不正 利用は防止できる．

「利用者属性漏洩によるプライバシ侵害」に関しては，利用者属性そのものが 流出してしまうケース，なんらかの手段で利用者属性が類推されてしまうケー スが考えられる．耐タンパ性が前提のため利用者属性そのものが IC カード外に 流出する可能性は低い．また，利用者がサービスを利用する際，サービス認可 装置は，利用権 ID と User Policy Assertion を受け取る．利用権 ID からアク

ドキュメント内 個人適応型ユビキタス環境 (ページ 98-105)