実体のグループを定義する暗号化証明書を使うシステムおよび方法
【課題】
【解決手段】
暗号化証明書を発行するシステムおよび方法であって、１つ以上の前提条件を暗号化証明書に記述するステップを含む。１つ以上の前提条件は、１つ以上の実体の前提条件グループのメンバシップを含む。実体は、参加者、リソース、または権利などでもよい。本発明は、また、暗号化証明書での１つ以上の実体の目標グループの指定を必要とする。１つ以上の実体の前提条件グループの実体に、別の実体のグループのメンバとして加えられることを許可する１つ以上の前提条件グループ利害関係者が、暗号化証明書に署名する。また、暗号化証明書は、実体に１つ以上の目標グループのメンバとして加えられることを許可する１つ以上の目標グループ利害関係者によって署名される。前提条件の例は、とりわけ、別の実体のグループのメンバシップ、物理的特性、時間特性、場所特性、または位置特性の１つ以上に関連する。
【解決手段】
暗号化証明書を発行するシステムおよび方法であって、１つ以上の前提条件を暗号化証明書に記述するステップを含む。１つ以上の前提条件は、１つ以上の実体の前提条件グループのメンバシップを含む。実体は、参加者、リソース、または権利などでもよい。本発明は、また、暗号化証明書での１つ以上の実体の目標グループの指定を必要とする。１つ以上の実体の前提条件グループの実体に、別の実体のグループのメンバとして加えられることを許可する１つ以上の前提条件グループ利害関係者が、暗号化証明書に署名する。また、暗号化証明書は、実体に１つ以上の目標グループのメンバとして加えられることを許可する１つ以上の目標グループ利害関係者によって署名される。前提条件の例は、とりわけ、別の実体のグループのメンバシップ、物理的特性、時間特性、場所特性、または位置特性の１つ以上に関連する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、情報セキュリティの分野に関し、特に暗号化により安全確保するシステムに関する。
【背景技術】
【０００２】
暗号化は、数学的な規律、および情報セキュリティならびにそれに関連する課題、特に情報ならびに識別認証の暗号化／復号化に関するコンピュータサイエンスの領域である。「データ移動（data-in-movement）」アプリケーションと呼ばれるアプリケーションにおいては、通信チャンネルにおける通信参加者、例えば、クライアントノード、間での情報の流れの安全確保に、暗号化が広範囲に応用されている。暗号化は、データストレージ媒体およびデータベースにおける「データ非移動（data-at-rest）」アプリケーションとして知られるアプリケーションにおいても情報の安全確保に応用されている。
【０００３】
対称暗号化方式および非対称暗号化方式は、情報の暗号化および復号化、ならびに認証のための１つ以上の秘密パラメータを有する鍵を使った既知のクラスのアルゴリズムである。対称暗号化方式では、鍵が、通信参加者間に事前に知られている共有の秘密を表している。対称鍵アルゴリズムで安全を確保するシステムでは、比較的単純な暗号化および復号化計算が使われる。また、このようなシステムでは、通信参加者間での共有秘密鍵の選択、配布、および維持が必要とされる。セキュリティ違反および暗号解読家による発見の可能性を回避するため、配布および運用中は、共有秘密鍵を頻繁に変更して安全の確保を維持しなければならず、対称暗号化方式は、大規模システムでの安全確保には実用的ではなく、拡張が難しい。
【０００４】
非対称暗号化方式は、公開鍵と秘密鍵として知られる数学的に関連した鍵の対を使用しており、そのため通信参加者間における共有秘密鍵を事前に知る必要性がない。非対称暗号化方式は、計算的な負荷は大きいが、対称暗号化方式に関わる拡張性の不都合を克服する。公開鍵基盤（PKI）は、非対称鍵暗号化方式を使った情報の安全確保の既知のシステムである。このようなシステムでは、あるコンピュータステーションにおける当事者がランダムに生成した秘密鍵を使ってメッセージにデジタル的に署名し、別のコンピュータステーションの当事者がその秘密鍵に由来する配布された公開鍵を使って署名を検証する。通信参加者の公開鍵は、１つ以上の認証局（Certificate Authorities, CA）と呼ばれる信頼できる第三者機関により発行され、公開鍵証明書（Public Key Certificate）としても知られる対応するＩＤ証明書（Identity Certificate）で配布される。このようにして、ＰＫＩが、秘密鍵を持たない人に対してメッセージの秘密性を保持し、ＩＤ証明書が、関係する公開鍵とＩＤ証明書を有する誰もが、そのメッセージがその秘密鍵で作成されたことを検証できるようにする。したがって、ＰＫＩは、通信当事者がお互いに認証され、ＩＤ証明書の公開鍵情報をメッセージの暗号化および復号化に使うことができ、これにより、共有秘密鍵を事前交換することなしに、メッセージの機密性、完全性および認証を達成することができる。
【０００５】
ＩＤ証明書のそれぞれは、公開鍵と、名前、電子メールアドレス、などの情報で表される識別とを結び付けるデジタル署名を含んでいる。証明書をデジタル的に署名することにより、認証局（CA）は、公開鍵が識別、即ち、その証明書に記載の人、組織、サーバ、または他の実体、の所有物であることを証明する。ＣＡは、大抵、通信当事者により使用されるデジタル証明書を発行する信頼できる第三者機関である。信頼されるための要件として、ＣＡは、何らかの方法で通信当事者の識別の信用性を検証する義務を負わされる。もし当事者がＣＡを信頼し、その署名を検証できるときは、公開鍵がまさしく証明書で識別されている者の所有物であるということを検証できると見なされる。
【０００６】
いくつかの企業規模の公開鍵基盤（PKI）システムは、当事者の識別を確立するのに証明書の連鎖に依存している。そのような構成では、証明書は１つの認証局（CA）により発行され、そのＣＡのその目的での正当性はより高いレベルのＣＡによって確立され、さらにその上のレベルのＣＡがその正当性を確立する、などというようになっている。これにより、複数のＣＡからなる証明書の階層構造が作られ、この複数のＣＡは、大抵、１つ以上の組織である。ＣＡは、証明書の発行を、種々のコンピュータといくつかのソースから選択した相互運用ソフトウェアパッケージを使って管理することができる。これにより、ＰＫＩの運用での標準が重要となる。ＩＥＴＦのＰＫＩＸワークグループは、Ｘ．５０９として知られる証明書標準を含む公開鍵証明書フォーマットの標準化に関わっている。
【０００７】
暗号化を使った種々のポイント・ツー・ポイントの安全な通信プロトコルが既知である。このようなプロトコルの例としては、セキュア・ソケット・レイヤ（商標）（SSL）、トランスポート層セキュリティ（TLS）、セキュア・シェル（SSH）、ＩＰセキュリティ（IPsec）、および高度保証レベルＩＰ相互運用仕様（High Assurance Internet Protocol Interoperability Specification、HAIPIS）がある。ＳＳＬおよびＴＬＳは、通信中の傍受、改ざん、メッセージの偽造を回避するクライアント−サーバ・ベースのネットワーク内で通信するアプリケーションの暗号化エンドポイント認証を提供する。ＳＳＨは、ローカルコンピュータとリモートコンピュータ間の安全なチャンネルの確立を可能にする一組の標準とそれに関連するネットワークプロトコルである。このプロトコルは、リモートコンピュータを認証するのに公開鍵暗号化を使用する。ＩＰｓｅｃは、認証、データ機密性、およびメッセージの完全性のためのすべてのＩＰパケットを暗号化することにより、インターネットプロトコル（IP）通信の安全確保のための標準である。高度保証レベルＩＰ暗号化（High Assurance Internet Protocol Encryptor、HAIPE）は、国家安全保障局（National Security Agency、NSA、米国）の高度保証レベルＩＰ相互暗号化運用標準（High Assurance Internet Protocol Interoperability Standard、HAIPEIS）に準拠するタイプ１の暗号化装置である。使用される暗号化方式はスイートＡおよびスイートＢで、ＮＳＡにより、暗号近代化プログラム（Cryptographic Modernization Program）の一部として規定されている。ＨＡＩＰＥＩＳは、ＩＰｓｅｃに基づき、制限と強化とが付け加えられている。ＨＡＩＰＥは、一般に、安全なゲートウェイで、信頼できないまたはより低クラスのネットワークを介して、２つの少数集団間でのデータのやり取りを可能にする。前述のプロトコルを使うような従来の安全確保システムでは、暗号化されたメッセージが、ＣＡによる通信当事者の識別の認証に基づき、チャンネルを介し、大抵の場合、ファイアウォールを介して、通信される。従来の安全確保システムは、通信当事者の識別が認証される限り、当事者がチャンネルを介してお互いに通信することができるようにする。
【０００８】
アプリケーションは、通常、ユーザから提供された信用性に基づき、リソースへのアクセスを提供する。一般に、このようなアプリケーションは、ユーザの役割（role）を検証し、その役割に基づいてリソースへのアクセスを提供する。役割は、ポリシ（policy）を実施するため、しばしば財務アプリケーションまたは業務アプリケーションに使われる。例えば、アプリケーションが、要求をしているユーザが特定の役割のメンバであるか否かに応じて処理される取引の大きさに制限を課すかもしれない。事務職は、所定の閾値以下の取引を処理する認可を有し、上司はそれより高い制限を有し、そして副社長はさらに高い制限（または制限なし）を有するかもしれない。役割ベースのセキュリティは、アプリケーションが処置を完結するのに複数の承認を必要とする場合にも使うことができる。このような場合としては購買システムなどがあり、従業員の誰もが購入依頼を生成できるが、購買担当者しかその依頼を供給元に送ることのできる発注書に変換できないかもしれない。
【０００９】
既知の役割ベースの識別管理システムの１つが、Microsoft社から.NET Frameworkとして提供されている。.NET Frameworkでは、「プリンシパル」がユーザの識別と役割を表し、ユーザに代わって行動する。.NET Frameworkアプリケーションは、プリンシパルの識別または役割メンバシップ、あるいはその両者に基づき、認可の決定を行う。役割とは、セキュリティに関して同じ権利を有するプリンシパルの組に付された名称（銀行の窓口係、マネージャなど）である。プリンシパルは、１つ以上の役割のメンバであってもよい。したがって、アプリケーションは、役割メンバシップを使って、プリンシパルが要求された動作を行うことを許可されているか否かを判断することができる。
【００１０】
別の役割ベースのシステムには、EurekifyのSage Enterprise Role Manager（ERM、登録商標）と呼ばれる分析協調プラットフォームがあり、これにより、組織が、対象プラットフォームに展開された役割ベースの権利モデルの作成および管理をすることができる。Sage ＥＲＭは、組織が、その権利およびポリシを事業の観点から管理し、識別管理およびコンプライアンスの目標を達成する役割ベースアクセスコントロール（Role-Based Access Control、RBAC）の恩恵を生かすことができるようにする。
【００１１】
現在、オブジェクト・マネジメント・グループ（Object Management Group、OMG）が、役割ベースアクセスコントロール（role based access control、RBAC）ランタイム環境で適用されるＲＢＡＣポリシおよび担当者認可を定義する役割ベースアクセス・ポリシ（Roll Based Access Policy、RBAP）メタモデルの提案依頼書（OMG書類：bmi/2008-02-07）を作成している。このメタモデルは、モデリングツールとランタイムシステムとの間のＲＢＡＰモデルの交換に対応する非プラットフォーム依存モデル（PIM）となることを意図している。
【００１２】
従来の別の手法では、バークレー研究所としても知られるLawrence Berkeley National Laboratoryが、Akenti（http://dsd.lbl.gov/security/Akenti/homepage.html）と呼ばれるシステムを開発した。Akentiは、多数の利害関係者によってコントロールされている分散型ネットワークでのリソースへの制限されたアクセスを許容することに対して挙げられた問題に対処している。Akentiは、中心となる執行者および管理権限者を必要とせずに、アクセスコントロールポリシの表明と実施の方法を提供する。Akentiのアーキテクチャは、分散型ネットワーク環境での拡張性のあるセキュリティサービスを提供することを意図している。Akentiは、リソースの利害関係者のそれぞれが、他の利害関係者に依存せずに、そのアクセスコントロールの要件を執行できるように設計されている。Akentiは、それぞれの利害関係者が、その要件をいつでも変更し、新規の要件が即時に有効となることを確信させ、アクセスコントロール要件の表明での完全性および否認防止の高い保証を提供できるようにしている。
【００１３】
Akentiは、デジタル的に署名された証明書を使っている。証明書は、識別を主張（ＩＤ証明書）し、対象の属性を証明（属性証明書）し、または合致の条件を宣言（使用条件証明書）し得る。Akentiの証明書は、ユーザ識別認証とともにリソース使用要件およびユーザ属性認可を有することが可能である。Akentiにおける使用条件は利害関係者の要件に関連し、見込みのユーザは、リソースの使用を許可される前に、対応する属性証明書を示してそれを満たさなければならない。属性は、人または他の識別可能な実体の特性と関連している。Akentiの利害関係者は、その利害関係者によりコントロールされるリソースにアクセスするためにユーザが特定のグループに所属しなければならないという使用条件を課すことができる。したがって、そのようなリソースにアクセスをしたいユーザは、その特定のグループのメンバシップを対応する属性証明書で立証しなければならない。属性証明書は、ユーザまたはリソースが特定の使用条件に指定された属性を所有することを主張する。
【００１４】
Akentiのシステムでは、しかしながら、利害関係者はリソースに関係付けられている。そのような利害関係者はリソースへのアクセスを、ユーザが指定された属性に合致する必要があるという使用条件に基づいてコントロールしている。Akentiでは、リソースへのアクセスは、ユーザがリソース利害関係者に指定された属性要求に合致する限り許可される。Akentiシステムの欠点の１つは、リソース利害関係者ではない利害関係者または権限者のセキュリティ要件には適応していないことである。このような非リソース利害関係者は、リソース利害関係者がユーザのリソースへのアクセスを回避しない限りは、ユーザのリソースへのアクセス権についてのコントロールができない。言い換えれば、Akentiのリソース利害関係者は、非リソース利害関係者によってそのアクセスが禁止されるようなユーザのリソースへのアクセスを許可してしまうことになる。
【００１５】
ケルベロス（Kerberos）と呼ばれるコンピュータネットワーク認証プロトコルが知られており、安全ではないネットワークを介して通信する個人が安全な方法でお互いの識別を立証することができる。マサチューセッツ工科大学（MIT）から公開された一式のフリーソフトで、主にクライアント−サーバ・モデルにおいて、お互いの識別をクライアントおよびサーバの両者が検証するような相互認証を提供するケルベロス・プロトコルを実装することができる。ケルベロス・プロトコル・メッセージは、傍受およびリプレーアタックに対して保護されている。
【００１６】
ケルベロスは、対称鍵暗号化方式を基に構築されており、鍵配布センタ（Key Distribution Center、KDC）と称する信頼される第三者機関を必要とし、それは、認証サーバ（Authentication Server、AS）とチケット交付サーバ（Ticket Granting Server、TGS）との２つの論理的に分離された部分からなる。ケルベロスは、ユーザの識別を立証する「チケット」に基づいて動作する。
【００１７】
鍵配布センタ（KDC）は、秘密鍵のデータベースを維持する。クライアントかサーバに関わらず、ネットワーク上の実体のそれぞれは、それ自身と鍵配布センタ（KDC）のみが知っている秘密鍵を共有する。この鍵を知っていることが、実体の識別を立証することになる。２つの実体間の通信においては、ＫＤＣがセッション鍵を生成し、それは、それらの相互作用の安全確保に使うことができる。しかしながら、ケルベロス・プロトコルを使うには、「チケット」が、ＫＤＣ、またはセントラルサーバに問合せて検証されなければならず、実装されたシステムの単一障害発生点の問題を招くことになる。ケルベロスの単一障害発生点の特性は、組み込みシステムや自律システムなどの間欠的または故障傾向の通信能力を有するシステムにとっては都合が良くない。
【００１８】
したがって、情報システムのセキュリティ・ニーズがより複雑になっており、先進で高度な安全確保パラメータに基づいてアクセスをコントロールする安全なシステムおよび方法の必要性がある。
【発明の概要】
【００１９】
簡潔には、本発明の１つの態様によれば、暗号化証明書を発行するシステムまたは方法は、暗号化証明書に１つ以上の前提条件を記述する。前提条件は、実体の前提条件グループのメンバシップを含んでいる。決定を行うために前提条件グループのメンバシップを使うことにその承認を必要とする１つ以上の前提条件グループ利害関係者（または権限者）が、暗号化証明書に署名する。そのような承認に基づく決定の例は、グループのメンバシップへの加入、リソースへのアクセスの付与、または動作を行うことに関連している。１つの実施の形態では、前提条件グループの識別または名称は、前提条件グループ利害関係者の識別に関係する。例えば、利害関係者の公開鍵が、前提条件グループの識別の一部となり得る。別の実施の形態では、証明書がリソースへのアクセスの権利を付与する。証明書は、権利またはリソースへのアクセスをコントロールする１つ以上の利害関係者または権限者が署名し得る。
【００２０】
さらに、暗号化証明書を処理する方法は、実体の前提条件グループの少なくとも１つのメンバシップを含む前提条件の少なく１つを記述する暗号化証明書を受け取り、その暗号化証明書が、決定を行うために前提条件グループのメンバシップを使うことにその承認を必要とする前提条件グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断する。
【００２１】
本発明の別の態様によれば、暗号化証明書を発行するシステムまたは方法は、暗号化証明書に１つ以上の前提条件を記述する。１つ以上の前提条件は、実体の前提条件グループのメンバシップを含んでいる。実体は、参加者、リソース、または権利などでもよい。本発明は、また、１つ以上の実体の目標グループの名称を記述する。１つ以上の前提条件利害関係者または権限者が暗号化証明書に署名し、１つ以上の前提条件グループの実体に、別の１つ以上の実体の目標グループのメンバとして加えられることを許可する。前提条件の例は、とりわけ、１つ以上の別の実体のグループのメンバシップ、物理的特性、時間特性、場所特性、または位置特性に関連している。
【００２２】
本発明のさらなる詳細な特徴によれば、１つ以上の前提条件グループの名称は、前提条件グループのメンバに別のグループのメンバシップを許可する１つ以上の前提条件グループ利害関係者の名称、およびその１つ以上の前提条件グループでのメンバシップを許可する１つ以上の前提条件グループ利害関係者の名称を含んでいる。１つ以上の前提条件グループの名称は、さらに、１つ以上の前提条件グループの曖昧さの無い識別子を含んでいる。１つの実施の形態の例では、１つ以上の前提条件グループ利害関係者の名称は、１つ以上の前提条件グループ利害関係者の公開鍵を含んでいる。１つ以上の前提条件グループ利害関係者の署名は、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含んでいる。
【００２３】
同様に、１つ以上の目標グループの名称は、目標グループの実体の別のグループへのメンバシップまたは追加を許可する１つ以上の目標グループ利害関係者の名称、および実体に１つ以上の目標グループのメンバとなることを許可する１つ以上の目標グループ利害関係者の名称を含んでいる。１つ以上の目標グループ利害関係者の名称は、１つ以上の目標グループ利害関係者の公開鍵を含んでおり、１つ以上の目標グループ利害関係者の署名は、１つ以上の目標グループ利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含んでいる。
【００２４】
本発明のさらに別の態様によれば、暗号化証明書は、１つ以上の前提条件グループの名称と、１つ以上の目標グループの名称と、前提条件グループの実体に別のグループの実体となることを許可する前提条件グループ利害関係者の１つ以上の暗号化署名と、実体の名称を目標グループに加えることを許可する目標グループ利害関係者の１つ以上の暗号化署名とを含んでいる。
【００２５】
本発明のさらに別の態様によれば、暗号化証明書を処理するシステムは、複数の実体を含んでいる。システムは、また、１つ以上のメンバシップ証明書を含んでいる。メンバシップ証明書のそれぞれは、１つ以上の前提条件グループの名称、１つ以上の目標グループの名称、および１つ以上の前提条件グループ利害関係者ならびに目標グループ利害関係者として機能する１つ以上の利害関係者の名称を含んでいる。グループメンバシップ証明書は、前提条件グループの実体に別のグループの実体となることを許可する１つ以上の前提条件グループ利害関係者によって暗号化署名されていれば有効である。グループメンバシップ証明書は、さらに、実体を目標グループに加えることを許可する１つ以上の目標グループ利害関係者によって暗号化署名される。ノードは、実体から暗号化証明書を受け取る。ノードは、有効なグループメンバシップ証明書を検査し、受け取った暗号化証明書が、実体を有効なグループメンバシップ証明書で指定された前提条件グループに有効に結び付けるならば、その実体を有効なグループメンバシップ証明書で指定されている目標グループに加える。
【図面の簡単な説明】
【００２６】
【図１】図１は、リード、ライト、およびリード／ライトの権利によってストレージリソースと相互作用するクライアントステーション参加者のグループ化の一例を示す概念図である。
【００２７】
【図２】図２は、グループ名の一例を示す図である。
【００２８】
【図３】図３は、実体に関係する前提条件を目標グループに結び付けるグループメンバシップ証明書（GMC）を示す図である。
【００２９】
【図４】図４は、グループに関係する１つ以上の前提条件を目標グループに結び付けるＧＭＣを示す図である。
【００３０】
【図５】図５は、本発明の実施の形態の例を実装するシステムのブロック図である。
【００３１】
【図６】図６は、参加者のグループ化のＧＭＣの一例を示す図である。
【００３２】
【図７】図７は、リソースのグループ化のＧＭＣの例を示す図である。
【００３３】
【図８】図８は、権利のグループ化のＧＭＣの例を示す図である。
【発明を実施するための形態】
【００３４】
本発明は、実体のグループを定義するために暗号化証明書を応用するシステムまたは方法に関する。グループ化される実体は性質がさまざまであってもよく、暗号化証明書で名称付け、または識別される能力以上の特性を有することを必要とされない。実体の例としては、物理的および論理的実体の両者である人間、プロセッシングユニット、ノード、クライアントステーション、ファイルシステム、コンピュータハードウェア、コンピュータプログラムの実行インスタンス、リードまたはライトアクセス権、オペレーティングシステム権、ストレージリソース、コンピュータリソース、および／または通信リソース、あるいは他のグループが含まれる。
【００３５】
図１は、１つ以上の権利によってストレージリソースと相互作用するクライアントステーション参加者のグループ化の一例を示す概念図である。参加者は、秘密の保持、およびその秘密を漏らすことなく他の参加者にその秘密の認識の立証が、例えば、ANSI X9.63、IEEE 1363-2000、およびISO/IEC 15946-3で標準化された楕円曲線ＭＱＶ（Elliptic Curve MQV）プロトコルのような相互認証プロトコルを使って可能な任意の実体からなる。１つの実施の形態では、参加者は、ハードウェアまたはソフトウェアで実現でき、暗号化された公開鍵を使って識別化、または名称付けされることができる。参加者は、とりわけ、ウェブ・クライアント、ＳＱＬクライアント、ファイルサーバ、イーサネットカード、パーティション、アプリケーション、ノード、システム、コンピュータ、または機器であってもよい。
【００３６】
１つの実施の形態では、参加者は、リソースと直接的に、およびリソースを介して他の参加者と間接的に相互作用が可能な実体からなる。リソースは、非参加者実体からなり、それには、限定されるものではないが、実行され、使用され、利用され、作成され、または保護されるいかなるハードウェア、ファームウェア、データ、および／またはソフトウェアが含まれる。リソースは、参加者ではない。暗号的にグループ化できる本発明に係るリソースの例には、ファイルシステムに保存されるファイル、ネットワークスタック（network stack）のポート、コンピュータのランダムアクセスメモリ、などが挙げられる。他のリソースの例としては、使用可能なあらゆるプロセッシングパワー、リンク、通信チャンネル、Ｉ／Ｏバス、メモリバス、ハードウェアまたはソフトウェアとともに、ソケットライブラリ、プロトコルスタック、デバイスドライバなどが含まれる。リソースには、あらゆる適切な非対称および／または対称鍵暗号化アルゴリズムおよび本発明に係る方法を実装する暗号化／復号化ユニットも含むことができる。
【００３７】
本発明の１つの実施の形態では、リソースは、必要な権利を有する参加者によって作用または消費され得る実体である。権利は、１つ以上の参加者と１つ以上のリソースとの間で許容される相互作用からなる。例えば、ファイルリソースに関係する権利には、そのファイルリソースからのリード（読み込み）またはそのファイルリソースへのライト（書き込み）、あるいはその両者の権利が挙げられる。別の例としては、ランダムアクセスメモリ（RAM）を使ってプログラムを実行する権利がある。
【００３８】
上述のように、１つの実施の形態の例では、参加者は、秘密を保持し、その秘密を漏らすことなくその秘密の認識を他の参加者に立証することができるので、暗号化公開鍵により名称付け、または識別化される。しかし、リソースおよび権利は、そのリソースまたは権利を識別するのに十分に詳細なリソースまたは権利の記述を使って名称付けされ、参照され、または識別される。
【００３９】
一般に、本発明は、１つ以上の名称付けされた実体、例えば、参加者、リソース、または権利がグループのメンバか否かを判断する手段としての１つ以上の証明書を使用、および作成するシステムまたは方法に関する。本発明の証明書は、セントラルサーバに問合せすることなしに検証することができる。選択的に、本発明を実装したシステムまたは方法は、識別可能なさらなる情報を複数の実体またはグループのいずれかと関係するまたは結び付けることができるさらなる証明書を含んでもよい。したがって、本発明においては、グループメンバシップ証明書（Group Membership Certificate、GMC）として知られる１つ以上の証明書が、１つ以上の実体が１つ以上の目標グループのメンバであるか否かを定義している。個別の実体および１つ以上の実体のグループは、ＧＭＣに、目標グループのメンバシップが指定される。ＧＭＣは、目標グループ名の名称とともに、１つ以上のグループメンバシップ前提条件（group membership prerequisite condition、GMPC）を記述している。典型的なＧＭＰＣの例では、そのＧＭＰＣの充足可能性が評価される際に、ＧＭＣに依存する当事者により検証可能な条件との合致の証明を必要とするかもしれない。その条件には、別の名称のグループのメンバシップ、特定の名称を有する実体であることの証明、および状態、高さ、幅、形状、時間、場所、位置、配置、振幅、位相、周波数、電流、電圧、抵抗などに関連する特性を含む物理的（例、機械的、光学的、熱的、幾何学的など）、非物理的、時間的または非時間的特性を有することの証明が含まれる。典型的な証明の例には、現在の配置と所定の配置との合致の証明、生体特性の合致の証明、現在の日時と所定の日時との合致の証明などがある。
【００４０】
例えば、複数の実体は、メンバシップに必要な前提条件に合致する場合、それ自体が目標グループのメンバとなり得る指定された前提条件グループの一部となることが可能である。このように、それぞれのＧＭＣは、指定された目標グループのメンバシップ前提条件を表す。定義された満足基準に従って１つ以上の前提条件を満足させることにより、実体に目標グループのメンバシップが付与される。本発明のさまざまな実施の形態では、目標グループのメンバシップ前提条件満足基準は、それぞれの前提条件を満足させること、前提条件の１つを満足させること、その演算子が論理積（AND）および宣言肢（OR）とからなるブール代数の式で記述される前提条件の組み合わせを満足させること、総数ｎ個の前提条件のｍ個を満足させること、のいずれか１つと関連することができる。
【００４１】
上述のように、実体に目標グループのメンバシップが付与されるには、グループメンバシップ前提条件を満足させることが必要である。以下に記述するように、必要な権限を有する利害関係者がグループメンバシップ証明書（GMC）に署名して１つ以上のグループメンバシップ前提条件（GMPC）を目標グループに結び付け、これにより、１つ以上の前提条件に合致する１つ以上の実体が指定された目標グループのメンバとなることができる。
【００４２】
このように、本発明は、グループの名称に追加の情報を含むことを必要とすることにより、実体をグループ化する既存の証明書ベースの方法を拡張している。１つの実施の形態の例では、グループ名は、直接的または間接的に、決定の要素としてグループのメンバシップを使用することにその許可が必要とされる権限者の公開鍵を含んでいる。このことは、決定と使用の権限者の組が等しいときにのみ、２つのグループが同じ名称を有することになる。グループ名は、本発明の情報と制約とが含まれ適用される限りにおいて、他の情報を含んでもよく、本発明を実装するシステムにおける平等性のさらなる制約を有してもよい。よって、それぞれのグループメンバシップ証明書（GMC）は、１つ以上の前提条件を目標グループの名称に結び付ける。図２に、グループ名のテンプレートの例を示す。
【００４３】
本発明の１つの実施の形態の例では、２つのタイプのグループメンバシップ証明書（GMC）が実装されている。図３は、実体に関係する前提条件を目標グループに結び付けるＧＭＣを示し、図４は、他のグループのメンバシップのための１つ以上の前提条件を目標グループに結び付けるＧＭＣを示す。図３のＧＭＣの例によれば、グループメンバシップ前提条件は、実体が特定の名称、例えば、ジョン・ドウ、を有し、目標グループに所属することの証明を含み、その実体のその目標グループへの結び付きがＧＭＣの適切な利害関係者の署名により明示されている。図４のＧＭＣの例によれば、グループメンバシップ前提条件は、別の名称の前提条件グループのメンバシップの証明を含み、同じく、その名称の前提条件のグループの目標グループへの結び付きがＧＭＣの適切な利害関係者の署名により明示されている。
【００４４】
したがって、グループメンバシップ証明書（GMC）の有効性は、そのＧＭＣの必要な利害関係者による有効な暗号化署名の存在によって判断され、それがグループメンバシップ前提条件を１つ以上の目標グループのメンバシップと結び付ける。利害関係者は、１つ以上の目標グループの名称およびグループメンバシップ前提条件（GMPC）で指定されたグループまたは個人の名称で識別される。本発明の１つの実施の形態によれば、「トゥ・ザ・グループ（to-the-group、グループへ）」利害関係者と呼ばれる１つの種類の利害関係者は、目標グループへの加入の許可を付与する。目標グループに所属する一組の実体の拡張には、証明書にトゥ・ザ・グループ利害関係者の署名が必要である。「フロム・ザ・グループ（from-the-group、グループから）」利害関係者と呼ばれる別の種類の利害関係者は、グループ名で識別される。このようなグループ名は、直接的または間接的に、決定の要素としてそのグループのメンバシップを使用することにその許可が必要とされる権限者の公開鍵を含んでいる。例えば、フロム・ザ・グループ利害関係者は、１つのグループの実体に別のグループのメンバになること、またはそのグループのメンバシップの証明に権利のような追加の情報を結び付けることの許可を付与する。目標グループのメンバシップの前提条件として、あるグループのメンバシップの証明の使用を許可するためには、ＧＭＣにフロム・ザ・グループ利害関係者の署名が必要である。フロム・ザ・グループ利害関係者の署名は、前提条件としてそのグループのメンバシップを必要とする権利を付与する証明書など、情報をそのグループに結び付ける他の証明書にも必要である。
【００４５】
グループメンバシップ証明書（GMC）に現れるグループの名称は、前提条件グループまたは目標グループに関わらず、複数の部分からなる。第一に、グループ名は、それぞれのトゥ・ザ・グループ利害関係者の暗号化公開鍵を判断するのに十分な情報を含んでいる。第二に、グループ名は、それぞれのフロム・ザ・グループ利害関係者の暗号化公開鍵を判断するのに十分な情報を含んでいる。利害関係者の一組を記述する情報の形式の一例は、利害関係者の公開鍵の明示的にリストすることである。あるいは、その識別子を公開鍵に結び付ける固有のＩＤ証明書に転換する識別子の一組が使われてもよい。選択的に、グループの名称には、同じトゥ・ザ・グループとフロム・ザ・グループ利害関係者の組を有する他のグループからそのグループを区別する役割をする１つ以上の曖昧さのない識別子が含まれてもよい。曖昧さのない識別子の例には、テキスト普通名詞、デジタル画像、デジタル音、これら識別子の暗号化ハッシュ、またはこれら識別子の組み合わせが含まれる。
【００４６】
図３に示すグループメンバシップ証明書（GMC）は、実体が名称を与えられていることの証明を必要とする１つのグループメンバシップ前提条件（GMPC）を含んでいる。さらに、ＧＭＣは、証明書がメンバシップを付与するグループの１つの目標グループの名称を含んでいる。目標グループ名は、曖昧さのない識別子、および任意の数の変数ｍで表されるトゥ・ザ・グループ利害関係者の識別子ならびに変数ｎで表されるフロム・ザ・グループ利害関係者の識別子からなる。前提条件実体名を目標グループ名に結び付けることを有効にするため、図３のＧＭＣは、目標グループのトゥ・ザ・グループ利害関係者１〜ｎの署名を含んでいる。上述のように、図３の目標グループのトゥ・ザ・グループ利害関係者１〜ｎは、目標グループのメンバシップに、図３のＧＭＣに指定される前提条件実体名が含まれるように拡張することができる。図３のＧＭＣは、別のグループのメンバシップへの前提条件としてグループのメンバシップの証明を必要としないので、ＧＭＣの有効性にフロム・ザ・グループ利害関係者の署名は必要とされない。
【００４７】
図４に示すグループメンバシップ証明書（GMC）は、変数ｋで表される数の前提条件グループ名からなる任意の数のグループメンバシップ前提条件（GMPC）を含んでおり、それぞれが、実体に、目標グループへのメンバシップを得るために、対応する前提条件グループのメンバシップを立証することを必要とする。このＧＭＣは、グループメンバシップがＧＭＣの前提条件として使用されるときに、ＧＭＣ有効性の署名要件を立証するように設計されている。図４のＧＭＣの前提条件としてメンバシップがリストされた各グループの名称は、任意の数の変数ｍで表されるトゥ・ザ・グループ利害関係者、および変数ｎで表されるフロム・ザ・グループ利害関係者とを有する。これらの変数は、前提条件グループの名称の範囲内とされ、ＧＭＣのそれぞれの前提条件グループ名においては、異なる値のｍおよびｎを使用することができる。前提条件名の目標グループ名への結びつきを有効とするために、図４のＧＭＣは、２つのタイプの利害関係者の署名を含んでいる。図４のＧＭＣは、前提条件としてメンバシップがリストされたグループのフロム・ザ・グループ利害関係者の署名を含んでいる。また、図４のＧＭＣには、図４の目標グループのトゥ・ザ・グループ利害関係者の１〜ｎの署名が必要とされ、それにより、図４のＧＭＣで指定された前提条件グループのメンバシップを証明できる実体を盛り込んで目標グループのメンバシップを拡張することができる。
【００４８】
本発明を実装したシステムは、基本的にグループのメンバシップについての記述からなるグループメンバシップ証明書（GMC）のそれぞれを調べることによって、グループのメンバシップについて学習する。システムは、当初、グループは空であると考える。このようなシステムは、その後、ＧＭＣを調べて、実体がグループのメンバとなるのに十分な条件を学習する。本発明の１つの実施の形態では、システムが、複数のＧＭＣが同じ目標グループを有する異なるグループメンバシップ前提条件（GMPC）を含むことを知った場合は、いずれかの証明書の前提条件を満たすことで、実体が目標グループのメンバシップを得るのに十分であるとする。よって、グループのメンバシップから除外される実体側に、およびそのシステムへのさらなるＧＭＣの導入または追加に発行されるＧＭＣエラーのそれぞれへのアクセスを有しないシステムは、所定のグループのメンバシップを有する実体の数を増加することはできるが、減少させることはできない。このように、セントラルサーバに問合せをすることなく、ＧＭＣを検証することができる。よって、ケルベロスのシステムとは違って、単一障害発生点を招くことはない。
【００４９】
２つのグループ名は、第１のグループ名のトゥ・ザ・グループ利害関係者およびフロム・ザ・グループ利害関係者の一組が、第２のグループ名のトゥ・ザ・グループ利害関係者およびフロム・ザ・グループ利害関係者の一組と同じで、第１のグループ名の曖昧さの無い識別子が第２のグループ名の曖昧さの無い識別子と同じである場合、同一のグループを称することになる。
【００５０】
本発明では、ＧＭＣを種々の状況に適用できる。本発明の１つの適用例は、参加者、リソース、および／または権利間で許容される関係を記述するセキュリティ・ポリシ（SP）の生成、評価、および実施である。参加者、リソース、および／または権利間の関係は、対応する利害関係者によって許可され、参加者のリソースへのアクセスを、もしあれば、権利に従って、仲介する１つ以上のガードによって実施される。
【００５１】
図５は、本発明を使った強制アクセスコントロール・セキュリティ・ポリシ（SP）の実施を実装するシステムの一例を示す。このシステムは、１つ以上のノードを使って実装されている。ノードには、通常、コード、プログラム、および／またはアプリケーションを実行する１つ以上のＣＰＵ、マイクロプロセッサ、埋め込み型コントローラ、デジタルシグナルプロセッサ（DSP）などのプロセッシングユニット（不図示）が含まれる。それぞれのノードは、有線または無線ノード、クライアント、サーバ、ルータ、ハブ、アクセスポイント、およびリソースを使って他の機器と通信する他の既知の機器、の１つまたは組み合わせであってもよい。
【００５２】
１つの実施の形態の例では、図５のノードは、分離カーネル（Separation kernel、SK）のコントロールの下にハードウェア上で実行されるパーティション、および有線または無線ネットワークを介してノードに接続される任意の数のクライアントを含んでいる。本発明の１つの実施の形態の例によれば、ノードは、ＳＫのコントロールの下で実行される。本発明において使用することができるＳＫのクラスの一例は、国家安全保障局（National Security Agency、NSA）から公開されている「U.S. Government Protection Profile for Separation Kernels in Environment Requiring High Robustness（高ロバスト性要求環境における分離カーネルの米国政府保護プロファイル、SKPP）」という題の保護プロファイル（Protection Profile、PP）に記載されており、参照により、その全体が本明細書に援用される。本発明は、ＳＫの使用または不使用でのクライアント−サーバ・モード、リアルタイムおよびノンリアルタイム分散型ネットワーク、セントラルネットワーク、ピアツーピア・ネットワーク、埋め込み型システムなどのような、あらゆるタイプのコンピューティング・モデルを使用するあらゆるシステムまたはネットワークにおいて使用できることに留意すべきである。
【００５３】
本発明の１つの実施の形態の例によれば、図５に示す少なくとも１つのノードは、対応する分離カーネル（SK）のコントロールの下で実行される。分離カーネルのそれぞれは、そのホストソフトウェアプログラムに、不正な改ざんを防止し、かつ回避することが不可能な高保証性のパーティションと情報フローコントロールの特性を提供する。分離カーネルは、ハードウェアおよび／またはソフトウェア機構で、その主な機能は、ノードの複数のパーティションの生成である。パーティションは、１つ以上のセキュリティ・ポリシ（SP）のすべてまたはその一部を実装する構成データに従って、そのコントロールの下のリソースから分離カーネルによって実装される抽象化である。さらに詳細に説明すると、本発明は、システムのセキュリティ・パラメータを実装する利害関係者によって署名されたセキュリティ・ポリシを使用する。それぞれの分離カーネルパーティションは、少なくとも１つの対象および／またはリソースを含んでいる。対象とは、機能を行うノードのコントロールの範囲内の実体であり、その機能は、例えば、ノード相互間通信機能である。リソースは、対象によって個別にまたは同時に使用され、リソース内の情報への対象のアクセスを許容する。本発明のシステムの参加者は、同一のノード、または１つ以上の通信チャンネルを介して互いに接続された異なるノードにおける１つ以上の分離カーネルによって定義されるノード、パーティション、または対象で実現される。
【００５４】
分離カーネル（SK）のコントロールの下で動作しているノードは、ノード上のパーティションで実行される対象およびリソースを、セキュリティ・ポリシ（SP）に違反する情報フローから保護する。分離カーネルは、リソースをポリシ・ベースの同値類に分離し、分離カーネルの構成データに従ってパーティションに割り当てられた対象およびリソース間の情報フローをコントロールする。１つの実施の形態では、ノードは、単一の分離カーネルを実行するハードウェアリソースからなり、そこでは、分離カーネルが、分離カーネルの構成データに従って、ノードの複数のパーティション間、および／またはその範囲内の情報フローをコントロールする。特に、それぞれのノードは、それぞれ独自の分離カーネルを実行し、その分離カーネルはそのノード固有のリソースを保護する。好ましくは、分離カーネル構成データの仕様が一義的で、試験官が、ポリシ、およびポリシによって指定されるそれぞれのリソース割り当てルールによって、ある接続が許容されるか否かを判断（恐らくツールを使って）できることである。
【００５５】
本発明は、公開鍵ならびに秘密鍵、および所望のセキュリティ・ポリシ（SP）の実装に必要なデジタル的に署名された承認の生成または取得のために、種々のツールを使っている。それぞれのノードは、公開鍵と秘密鍵との対からなる関係するノード識別（NI）を有している。ノードにおけるそれぞれのパーティションは、対応するパーティション識別（PI）を有している。各パーティションのＰＩは、パーティションが生成されたノードのＮＩの公開鍵およびノード上のそのパーティションを呼称する固有のインデックスからなる一対の値からなる。
【００５６】
図５に示すシステムでは、パーティションのファイルシステムのリソースを保護することを信頼できるパーティションに、ガードが実装されている。ガードは、そのアクセスがセキュリティ・ポリシ（SP）と一貫性がなければ、参加者として作動するクライアントに、ファイルシステム・パーティションへのアクセスが得られないことを確保しなければならない。ファイルシステム・パーティションには、セキュリティ・ポリシに適合するクライアントのみがアクセス可能である。１つの実施の形態では、ファイルシステム・パーティションは、提示されるそれぞれの要求を満たそうとし、セキュリティ・ポリシの実施には参加しない。代わりに、１つのクライアントのデータを他のクライアントから保護するポリシがガードによって実装される。ネットワークは、クライアントを、ファイルシステム・パーティションの基準モニタとして作動するガード・パーティションに接続する。クライアントは、分離カーネルオペレーティングシステム、またはMicrosoft Windows（登録商標）やLinuxなどの従来のオペレーティングシステムのいずれかを実行することができる。別の実施の形態では、ファイルシステムへのアクセスに、リソース利害関係者の認可も必要とすることができる。
【００５７】
ガードは、ハードウェアまたはソフトウェアで実現することができる。ガードの一例には、分割通信システム（Partitioning Communications System、PCS）、仮想プライベートネットワーク（VPN）実装が挙げられる。ＰＣＳは、本願の出願人に譲渡された2005年5月10日付け出願の米国特許出願11/125099号に開示されており、参照により援用される。ＰＣＳは、マルチレベル・セキュア（MLS）システムに対応し、それにより、多くのより高レベルの技術を重ねて安全な分散型通信を可能にする。このように、ＰＣＳは、信頼できる分散型システム実装の構成ブロックとして使用することができる。ＰＣＳは、１つ以上のチャンネルを介して別のノードまたはクライアントとデータのやり取りをするノード内の通信コントロール要素である。ＰＣＳは、分離カーネル（SK）によりコントロールされるパーティション間のデータフロー・ポリシに対応している。ＰＣＳは、対応するＳＫのコントロール下で実行されている、または実行されていないノード／クライアント間の通信を提供するハードウェアおよび／またはソフトウェアの組み合わせを配備する。このようにして、ＰＣＳは、そのセキュリティが、物理的なハードウェアの分離や保護、または特定のネットワークハードウェアに依存しないマルチドメイン・ネットワークの生成を可能にする。
【００５８】
本発明においては、図５に示すガードは、広範囲な種類のリソースの保護またはコントロールをすることができ、このリソースには、イーサネットスイッチ、ネットワークルータ、オペレーティングシステム・カーネル、表示モニタ、キーボード、マウス、プロジェクタ、ケーブル・セットトップボックス、デスクトップコンピュータ、ラップトップコンピュータ、サーバ・コンピュータ、サテライト、センサ、シュータ（shooter）、無人機、航空電子工学機器、ビデオ／オーディオ機器、電話、携帯電話、電話交換機、テレビ放送装置、テレビ、データベース・サーバ、クロスドメイン・ガード、分離カーネル、ファイルサーバ、ビデオおよび／またはオーディオ・サーバ、スマートカード、またはＰＤＡが挙げられる。
【００５９】
本発明においては、グループメンバシップ証明書（GMC）は、セキュリティ・ポリシ（SP）の対象となるあらゆるタイプの実体のグループ化に使われる。例えば、ＧＭＣは、後から権利と関係付けられる参加者のグループの作成に使われてもよい。個々の参加者それぞれを所望の権利と関係付ける従来の役割ベースアクセスコントロール（RBAC）システムとは異なり、本発明に係るグループ化は、より簡潔で管理可能なステートメントのセキュリティ・ポリシを可能にする。本発明のＧＭＣの適用は、グループ名を記述する個別のトゥ・ザ・グループ利害関係者とフロム・ザ・グループ利害関係者との組の存在によって、従来の役割ベースアクセスコントロールよりも、より高い表現力をもたらす。この利害関係者の分離は、あるグループへの実体の加入を認めることを信頼された利害関係者の組と、そのグループへの権利または別グループへのアクセスを得るためにそのグループのメンバシップを使う権利を割り当てることを信頼された利害関係者の組とが同じではない場合に望ましい。例えば、品質管理検査官は、ある無線通信機を標準準拠の無線通信機を表すグループに加入させることを信頼されているかもしれないが、別の利害関係者（例えば、ＦＣＣ（米国連邦通信委員会））が、その無線通信機を特定周波数で無線通信機が送信できるグループに加入させることに関与しているかもしれない。
【００６０】
別の実施の形態では、グループメンバシップ証明書（GMC）は、リソースのグループを作成することで、セキュリティ・ポリシの実装に使うことができる。特定のリソースを指定して権利を付与する代わりに、本発明の実施の形態では、適用されるＧＭＣで定義されるリソースのグループのそれぞれのリソースにわたる権利を付与する。例えば、リソースがコンピュータファイルの場合、それらのファイルを対応するＧＭＣで定義されるグループのメンバとすることができる。このグループで定義されたファイルの組は、新規のＧＭＣが発行されることによって増やされることができる。さらに別の実施の形態では、権利をグループ化でき、参加者は、所定のリソースにおける権利のグループのそれぞれの権利を付与されることができる。さらに、ＧＭＣのあらゆる組み合わせを１つのシステムとして組み合わせられ、参加者、リソース、および／または権利を必要に応じてグループ化することができる。
【００６１】
したがって、本発明のグループメンバシップ証明書（GMC）は、所望のセキュリティ・ポリシの実施に使うことができる。ＧＭＣは、クライアントによりネットワークを介して特定の名称を有するなどの前提条件を満たすことをガードに証明した後で、そのガードに提示することができる。この証明は、Ｘ．５０９のＩＤ証明書の提示との組み合わせで、ＥＣＭＱＶなどの暗号化認証および鍵設定プロトコルの実行によって達成することができる。ＧＭＣを使ったマルチレベル・セキュリティにBell-LaPadulaモデルを実装したい利害関係者は、クライアントを参加者として扱い、そのクライアントを使う個人のセキュリティ・クリアランスレベルに従ってグループ化してもよい。さらに、ファイルシステムのパーティションをリソースとして扱い、その機密レベルに従ってグループ化してもよい。クライアントを使う個人のセキュリティ・クリアランスレベル以外の要素を、クライアントに所定のファイルシステム・パーティションへのアクセスの権利が与えられるべきかの判断の一因としてもよい。本発明は、これらの決定の構成要素を個別に表現することができ、各構成要素の充足の判断を、認可決定の結果へのコントロールを失うことなく、異なる当事者に委任することができる。
【００６２】
例として、機密レベルの極秘ファイルシステム・パーティションへのアクセスをコントロールする利害関係者は、それらのパーティションへのリードアクセスに、以下のような条件が必要と決定するかもしれない。それらは、クライアントを使用する個人は機密レベルまたはそれより高いセキュリティ・クリアランスレベルを有すること、クライアントが安全の確保された施設内に存在すること、クライアントが安全で確実なオペレーティングシステム上で実行されていること、である。さらに、この機密レベル利害関係者は、クライアントに対するこれらの事実のそれぞれを判断することが可能な個人または機関を知っており、それぞれの条件を個別に検証することを、その認識する個人または機関に委任することを望んでいる。しかしながら、この利害関係者は、異なる検証を行っているその個人または機関に、これらの判断を別の状況において使う能力を委任したいとは思わない。
【００６３】
本発明を使って、機密レベルの利害関係者は、４つのグループを指定する。第１の指定グループには、機密クリアされたクライアントコンピュータであることが記述され、機密レベル利害関係者をそのグループの唯一のトゥ・ザ・グループ利害関係者および唯一のフロム・ザ・グループ利害関係者として含んでいる。これにより、機密レベル利害関係者が、そのグループへの権利を提供するグループメンバシップ証明書（GMC）の発行が可能な唯一の実体であること、および機密レベル利害関係者が、そのグループにクライアントを加入させるＧＭＣの発行が可能な唯一の権限者であることが保証される。
【００６４】
続いて、機密レベル利害関係者は、極秘機密ファイルシステムへのアクセスのために満たされなければならない前提条件それぞれに１つの追加グループを指定する。これらの追加グループの名称には、その条件を検証することが信頼された機関がトゥ・ザ・グループ利害関係者として、そして機密レベル利害関係者がフロム・ザ・グループ利害関係者としてリストされている。これにより、委任された利害関係者が、条件の検証を表わすグループにクライアントを加入させる唯一の実体であり、機密レベル利害関係者が、それらの条件の検証のグループを前提条件として使って証明書を発行できる唯一の利害関係者であることが保証される。これらのグループは、目標グループでのメンバシップの前提条件を表している。
【００６５】
最後に、機密レベル利害関係者が、図６に示すように、グループメンバシップ証明書（GMC）に署名をし、前提条件の検証を表す３つのグループのメンバであるクライアントが機密レベル・クライアントグループのメンバとなることができる。機密レベル利害関係者がこれらの前提条件グループのフロム・ザ・グループ利害関係者であり、目標グループのトゥ・ザ・グループ利害関係者であるので、ＧＭＣが有効であり、これ以外の署名が必要とはされない。誰かが新規のクライアントコンピュータで機密レベル・クライアントグループのメンバシップを必要とする情報にアクセスしたい場合、その人は、前提条件グループに指定されている機密レベル利害関係者に指定されたトゥ・ザ・グループ利害関係者とやり取りし、その条件が満足されたことをそれらの利害関係者に納得させることができる。その条件検証利害関係者が納得させられると、その条件検証利害関係者は、そのクライアントコンピュータを前提条件実体とし、検証した条件を表わしているグループを目標グループとしてリストしたＧＭＣを発行することができる。条件検証利害関係者が、グループ名にリストされたトゥ・ザ・グループ権限者であり、他のグループが関係していないので、ＧＭＣはそれ以上の署名を必要としない。よって、新規クライアントが、機密レベル利害関係者と関わり合うことなく、条件検証利害関係者を委任された利害関係者とのやり取りを必要とするのみで、機密レベル・クライアントグループのメンバとなることができる。
【００６６】
本発明は、ガードがそのセキュリティ感度レベルに従って保護するリソースをグループ化することにより、図５に示すガードをさらに強化するために使用することができる。例えば、パーティション１およびパーティション２の２つのファイルシステム・パーティションが機密レベルの感度を有する場合、機密レベル利害関係者は、それら両者のリソースパーティションを含む機密レベル感度グループを作成することができる。このグループは、図７に示すようなリソースをグループ化するグループメンバシップ証明書（GMC）を使って作成することができる。図７の証明書を有するガードは、パーティション１およびパーティション２の両者に適用されるそれらの証明書の目標グループの参加者に権利を付与することができる。
【００６７】
図５に示すシステムのさらなる改善として、ＧＭＣを使って権利を組み合わせてグループ化する。例えば、１つの名称が複数の権利を伝える場合、個々の権利をリードおよびライトとすると、リードアクセス権とライトアクセス権とに名称付けられたグループとなる。「全コントロール」と名付けられた実体を、図８に示す証明書を使って、これら両者のグループに加入させることができる。ガードがこのＧＭＣを保有する場合、ガードは、この「全コントロール」実体を、リードアクセス権グループおよびライトアクセス権グループのメンバシップにより、リードおよびライトの権利を所有するものとして扱うことができる。
【００６８】
前述によれば、１つの実施の形態の例では、グループ名は、決定、例えば、リソースへのアクセス許可、機能の実施、または別のグループへのメンバシップの付与、を行うのにそのグループのメンバシップを使うことにそれら利害関係者の承認を必要とする１つ以上の利害関係者の識別、例えば、これらの利害関係者の公開鍵と、直接的または間接的に、関係している。また、利害関係者は、前提条件グループの実体に１つ以上の目標グループのメンバとして追加されることを許可するため、暗号化証明書に署名することができる。さらに、暗号化証明書を処理する方法としては、実体の前提条件グループの少なくとも１つのメンバシップを含む前提条件の少なくとも１つを記述する暗号化証明書を受け取り、その暗号化証明書が、決定をするためにその前提条件グループのメンバシップを使うことにその承認が必要とされる前提条件グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断する。
【００６９】
１つの実施の形態では、分離カーネルの各リソースは、それらのリソースへのアクセスを承認しなければならない１つ以上のリソース利害関係者により、さらにコントロールされることができる。承認には、その１つ以上のリソース利害関係者が、対応する暗号化認可証（cryptographic authorization permit、CAP）に署名する。このＣＡＰについては、2007年4月9日付けの米国特許出願11/783,359号「SYSTEM AND METHOD FOR ACCESSING INFORMATION RESOURCES USING CRYPTOGRAPHIC AUTHORIZATION PERMITS」に公開されており、参照によって本願に援用される。１つの実施の形態においては、それぞれの公開鍵を使って、ＣＡＰは１つ以上のリソース利害関係者によって署名され、グループメンバシップ証明書（GMC）は１つ以上のトゥ・ザ・グループおよびフロム・ザ・グループ利害関係者によって署名される。１つ以上のリソース利害関係者の承認のみでは、参加者のリソースへのアクセスには十分ではない。よって、１つ以上のフロム・ザ・グループ利害関係者が、前提条件グループのメンバのリソースへのアクセスを別個に承認する。このようにして、前提条件グループのメンバシップの条件に基づいて、権利またはリソースへのアクセスを提供するためにＧＭＣとＣＡＰの概念を組み合わせてもよい。実際に、ＣＡＰとＧＭＣは、同一のまたは異なる証明書で実施することができる。
【００７０】
１つの実施の形態の例では、分割通信システム（PCS）は、チャンネル接続性ポリシおよびリソース管理ポリシの２つのセキュリティ・ポリシに従って、チャンネルを介する相互作用の仲介をする。チャンネル接続性ポリシは、許可できる接続を定義する。このポリシは、基本的に、すべてのアクセス権を定義するアクセス権コントロールポリシである。リソース管理ポリシは、チャンネルの実現に使われる共有通信リソースが、チャンネル間にどのように割り当てられるか、およびそのチャンネルが共有リソースの使用を介して互いに影響（協調的にまたは不慮に）する範囲を記述する。
【００７１】
チャンネルは、発信元パーティションから、任意の物理的または論理的な構成要素を含む同一または異なるノードに存在する１つ以上の送信先パーティションへの入力情報または出力情報の１方向の流れのための接続からなる。リードアクセス権は、許可されたパーティションに、チャンネルからメッセージのリード（読み込み）ができるようにし、ライトアクセス権は、許可されたパーティションに、チャンネルにメッセージのライト（書き込み）ができるようにする。チャンネルは、ノード間の、ポイント・ツー・ポイント、ポイント・ツー・マルチポイント、またはマルチポイント・ツー・マルチポイントの通信を実現するために使われる。各チャンネルは、通信されるメッセージに関係する対称暗号化／復号化鍵を有する。対称鍵は、チャンネルアクセス権が許可された後のチャンネルを介するメッセージの通信に使われる当事者間の共有秘密鍵である。共有秘密鍵は、セキュリティ・パラメータでの定義に従って定期的に変更されるものである。
【００７２】
ネットワークの個別のノードにおけるパーティション間のすべての通信は、チャンネルを介するメッセージの通信、即ちリードまたはライト、によって達成される。グループメンバシップ証明書（GMC）を使って、１つ以上のパーティションを、チャンネルの１つまたはそのグループへのライトアクセス権、リードアクセス権、またはその両者が付与された参加者として、グループ化することができる。また、ライトアクセス権、リードアクセス権、またはその両者を、個別の参加者もしくはチャンネル、または参加者もしくはチャンネルのグループに適用されるように、ＧＭＣを使ってグループ化することができる。
【００７３】
あるいは、１つ以上のリソース利害関係者によって署名されて発行された暗号化認可証（CAP）は、パーティションのリード、ライト、またはリードおよびライトのアクセス権をチャンネルに付与し、１つ以上のトゥ・ザ・グループおよびフロム・ザ・グループ利害関係者によって署名されて発行されたグループメンバシップ証明書（GMC）は、その参加者が指定された前提条件グループのメンバシップ条件を満足するのであれば、リソースまたはそのグループにアクセスする参加者をグループ化する。それぞれのチャンネルは、そのチャンネルからのメッセージの読み込みまたはそのチャンネルにメッセージを書き込みするのに必要なアクセス権を付与する責任のある１つ以上の関係するリソース利害関係者を有する。各チャンネルの識別には、そのチャンネルのリードおよびライトの権利をコントロールするリソース利害関係者の公開鍵、およびリソース利害関係者のコントロールによる固有なチャンネルインデックスが含まれる。同一のインデックスが付けられているが異なるリソース利害関係者のコントロールによる識別を有するチャンネルは、異なるチャンネルとみなされる。
【００７４】
図５に示すシステムの実施の形態の例では、コントロールパーティションとアプリケーションパーティション（ユーザパーティションとも呼ばれる）との２つのタイプのパーティションが使われている。すべてのパーティション間のノード内での相互作用は、分離カーネルと連携して、そのノードのコントロールパーティションによりコントロールされる。コントロールパーティションは、分離カーネル、そのノード内の他のパーティション、および他のノードのコントロールパーティションとのみやり取りをする。特定の実装ではパーティションの機能が多数のパーティションを使って実装されているものもあるが、各ノードは、コントロールパーティションの少なくとも１つを有する。コントロールパーティションは、そのノードの秘密鍵ならびに公開鍵、他のノードの公開鍵、およびシステムセキュリティを実装する暗号化認可証（CAP）ならびにグループメンバシップ証明書（GMC）を含むセキュリティデータ値を安全に格納（秘密の偽造できない方法で）する。アプリケーションパーティションは、対応する構成データおよびＣＡＰおよびＧＭＣの認可許可パラメータに従い、ローカルな分離カーネルに許可された手段を介して、コントロールパーティションを含む同一ノードの他のパーティションとやり取りする。コントロールパーティションは、それぞれの利害関係者によって署名されたＣＡＰまたはＧＭＣを受けたとき、分離カーネルのセキュリティ・ポリシのセキュリティ・パラメータが変更される機構を提供する。
【００７５】
メッセージをやり取りする前に、分割通信システム（PCS）は、通信に参加するノードが、その通信を許可する一貫性のある構成データを有することを確保する。ＰＣＳは、アクセスハードウェア／ソフトウェア、暗号化ハードウェア／ソフトウェアなどのそれぞれの共有リソースに対し、初期化し、そしてそれらのリソースを試験する。それぞれのチャンネルについては、送信チャンネル・エンドポイント（channel endpoint、CE）のパーティションが、それぞれの受信チャンネル・エンドポイントと相互認証を行い、共有秘密鍵を確立する。暗号化されている相互認証は、そのチャンネルへのアクセス権の許可に関係している。この認証は、通信対象の識別とともにそのアクセス権の検証からなる。対象の識別の検証は、ＥＣＭＱＶプロトコルを実行して、含まれるノードおよび／またはパーティションの識別を認証することによって行われてもよい。このプロトコルが成功裡に実行されると、認証を行ったチャンネル・エンドポイントのみが知る共有秘密鍵をもたらすことになる。チャンネルを介する通信の権利の検証は、対象にチャンネルへのアクセスを許可する暗号化認可証（CAP）およびグループメンバシップ証明書（GMC）に含まれる署名の検証を必要とする。それらの署名が、そのチャンネルの識別においてチャンネルの保護に責任があると特定される利害関係者と対応することを確保するために、さらなる検証が行われなければならない。最後に、チャンネル・エンドポイントがＣＡＰおよびＧＭＣで指定されている対象と前のステップでその識別が検証されている対象とを合致させる。すべてのチャンネル・エンドポイントで上述のステップが成功裡に行われれば、共有秘密鍵がチャンネルを介してやり取りされるメッセージの暗号化および復号化に使用されることになる。
【００７６】
共有リソースおよびチャンネルの初期化が完了すると、分割通信システム（PCS）は、チャンネルがメッセージのやり取りができる状態であることが通知される。チャンネルへのアクセスは、公表されたセキュリティ・ポリシに従って暗号化認可証（CAP）またはグループメンバシップ証明書（GMC）の発行に責任のある１つ以上の利害関係者の個別の許可を必要とする。ＣＡＰおよび／またはＧＭＣを介するチャンネルへのアクセスは、多数の権限者による個別の認可を必要としてもよい。上述のように、本発明は、セキュリティ・パラメータを実施する権限者によって署名されたポリシを使用する。１つの実施の形態の例では、署名されたポリシは、ＣＡＰならびにＧＭＣのリストおよび対応する利害関係者の公開鍵のリストを含んでいる。ポリシは、チャンネルの保護に責任のある１つ以上の利害関係者、およびグループメンバシップのコントロールに責任のある１つ以上の利害関係者によって署名されている。ＧＭＣとＣＡＰとの組み合わせは、あらゆる情報システムにおける拡張性の高いセキュリティ・ポリシの実装をもたらす。ＧＭＣは、参加者を、ＣＡＰが参加者の識別の代わりに前提条件として使用できる同等のクラスにグループ化することができ、これにより、繰り返しが回避される。さらには、ＧＭＣを介する推移的結合は、グループを他のグループとの結合的および分離的な組み合わせに関して定義できることにより、さらなる拡張性をもたらす。これは、役割（または属性）を参加者に直接結び付ける他のスキームとは対照的である。
【００７７】
上述により、実体のグループ化の認可は、１つ以上の利害関係者によって発行された公開鍵に基づき、それぞれのグループメンバシップ証明書（GMC）は、その利害関係者によってデジタル的に署名された暗号化証明書からなり、実体のグループ化は、そのような実体のグループ化を許可する前提条件をコントロールする１つ以上の利害関係者の暗号化署名を必要とすることが理解されよう。
【００７８】
本発明は、システムのノード数に事前の制限を設けずに、セキュリティ・ポリシを実施する。また、本発明は、認識されるセキュリティドメインの数、またはそのドメインで実施される情報フロー・ポリシについていかなる制限をも必要としない。これにより、システムのセキュリティ・ポリシは、展開されているソフトウェアを変更することなく、必要に応じて動的に変更することができる。さらに、本発明で作成されたシステムは、検証を行うのに第三者機関（権限者または利害関係者を含む）へのアクセスに依存しない。検証は、グループメンバシップ証明書（GMC）および利害関係者の公開鍵を処理する任意の実体によって行うことができる。そのようなシステムは、任意のノードが欠如または故障したときでも、パフォーマンスまたはセキュリティを、ほとんど、またはまったく劣化させずに機能を継続する。本発明は、軍事用途、機密レベル情報、業務担当者のみが知るべき制限された事項、銀行業務、および個別の口座に個別のパーティションを使う清算センタに使用することができる。
【技術分野】
【０００１】
本発明は、一般に、情報セキュリティの分野に関し、特に暗号化により安全確保するシステムに関する。
【背景技術】
【０００２】
暗号化は、数学的な規律、および情報セキュリティならびにそれに関連する課題、特に情報ならびに識別認証の暗号化／復号化に関するコンピュータサイエンスの領域である。「データ移動（data-in-movement）」アプリケーションと呼ばれるアプリケーションにおいては、通信チャンネルにおける通信参加者、例えば、クライアントノード、間での情報の流れの安全確保に、暗号化が広範囲に応用されている。暗号化は、データストレージ媒体およびデータベースにおける「データ非移動（data-at-rest）」アプリケーションとして知られるアプリケーションにおいても情報の安全確保に応用されている。
【０００３】
対称暗号化方式および非対称暗号化方式は、情報の暗号化および復号化、ならびに認証のための１つ以上の秘密パラメータを有する鍵を使った既知のクラスのアルゴリズムである。対称暗号化方式では、鍵が、通信参加者間に事前に知られている共有の秘密を表している。対称鍵アルゴリズムで安全を確保するシステムでは、比較的単純な暗号化および復号化計算が使われる。また、このようなシステムでは、通信参加者間での共有秘密鍵の選択、配布、および維持が必要とされる。セキュリティ違反および暗号解読家による発見の可能性を回避するため、配布および運用中は、共有秘密鍵を頻繁に変更して安全の確保を維持しなければならず、対称暗号化方式は、大規模システムでの安全確保には実用的ではなく、拡張が難しい。
【０００４】
非対称暗号化方式は、公開鍵と秘密鍵として知られる数学的に関連した鍵の対を使用しており、そのため通信参加者間における共有秘密鍵を事前に知る必要性がない。非対称暗号化方式は、計算的な負荷は大きいが、対称暗号化方式に関わる拡張性の不都合を克服する。公開鍵基盤（PKI）は、非対称鍵暗号化方式を使った情報の安全確保の既知のシステムである。このようなシステムでは、あるコンピュータステーションにおける当事者がランダムに生成した秘密鍵を使ってメッセージにデジタル的に署名し、別のコンピュータステーションの当事者がその秘密鍵に由来する配布された公開鍵を使って署名を検証する。通信参加者の公開鍵は、１つ以上の認証局（Certificate Authorities, CA）と呼ばれる信頼できる第三者機関により発行され、公開鍵証明書（Public Key Certificate）としても知られる対応するＩＤ証明書（Identity Certificate）で配布される。このようにして、ＰＫＩが、秘密鍵を持たない人に対してメッセージの秘密性を保持し、ＩＤ証明書が、関係する公開鍵とＩＤ証明書を有する誰もが、そのメッセージがその秘密鍵で作成されたことを検証できるようにする。したがって、ＰＫＩは、通信当事者がお互いに認証され、ＩＤ証明書の公開鍵情報をメッセージの暗号化および復号化に使うことができ、これにより、共有秘密鍵を事前交換することなしに、メッセージの機密性、完全性および認証を達成することができる。
【０００５】
ＩＤ証明書のそれぞれは、公開鍵と、名前、電子メールアドレス、などの情報で表される識別とを結び付けるデジタル署名を含んでいる。証明書をデジタル的に署名することにより、認証局（CA）は、公開鍵が識別、即ち、その証明書に記載の人、組織、サーバ、または他の実体、の所有物であることを証明する。ＣＡは、大抵、通信当事者により使用されるデジタル証明書を発行する信頼できる第三者機関である。信頼されるための要件として、ＣＡは、何らかの方法で通信当事者の識別の信用性を検証する義務を負わされる。もし当事者がＣＡを信頼し、その署名を検証できるときは、公開鍵がまさしく証明書で識別されている者の所有物であるということを検証できると見なされる。
【０００６】
いくつかの企業規模の公開鍵基盤（PKI）システムは、当事者の識別を確立するのに証明書の連鎖に依存している。そのような構成では、証明書は１つの認証局（CA）により発行され、そのＣＡのその目的での正当性はより高いレベルのＣＡによって確立され、さらにその上のレベルのＣＡがその正当性を確立する、などというようになっている。これにより、複数のＣＡからなる証明書の階層構造が作られ、この複数のＣＡは、大抵、１つ以上の組織である。ＣＡは、証明書の発行を、種々のコンピュータといくつかのソースから選択した相互運用ソフトウェアパッケージを使って管理することができる。これにより、ＰＫＩの運用での標準が重要となる。ＩＥＴＦのＰＫＩＸワークグループは、Ｘ．５０９として知られる証明書標準を含む公開鍵証明書フォーマットの標準化に関わっている。
【０００７】
暗号化を使った種々のポイント・ツー・ポイントの安全な通信プロトコルが既知である。このようなプロトコルの例としては、セキュア・ソケット・レイヤ（商標）（SSL）、トランスポート層セキュリティ（TLS）、セキュア・シェル（SSH）、ＩＰセキュリティ（IPsec）、および高度保証レベルＩＰ相互運用仕様（High Assurance Internet Protocol Interoperability Specification、HAIPIS）がある。ＳＳＬおよびＴＬＳは、通信中の傍受、改ざん、メッセージの偽造を回避するクライアント−サーバ・ベースのネットワーク内で通信するアプリケーションの暗号化エンドポイント認証を提供する。ＳＳＨは、ローカルコンピュータとリモートコンピュータ間の安全なチャンネルの確立を可能にする一組の標準とそれに関連するネットワークプロトコルである。このプロトコルは、リモートコンピュータを認証するのに公開鍵暗号化を使用する。ＩＰｓｅｃは、認証、データ機密性、およびメッセージの完全性のためのすべてのＩＰパケットを暗号化することにより、インターネットプロトコル（IP）通信の安全確保のための標準である。高度保証レベルＩＰ暗号化（High Assurance Internet Protocol Encryptor、HAIPE）は、国家安全保障局（National Security Agency、NSA、米国）の高度保証レベルＩＰ相互暗号化運用標準（High Assurance Internet Protocol Interoperability Standard、HAIPEIS）に準拠するタイプ１の暗号化装置である。使用される暗号化方式はスイートＡおよびスイートＢで、ＮＳＡにより、暗号近代化プログラム（Cryptographic Modernization Program）の一部として規定されている。ＨＡＩＰＥＩＳは、ＩＰｓｅｃに基づき、制限と強化とが付け加えられている。ＨＡＩＰＥは、一般に、安全なゲートウェイで、信頼できないまたはより低クラスのネットワークを介して、２つの少数集団間でのデータのやり取りを可能にする。前述のプロトコルを使うような従来の安全確保システムでは、暗号化されたメッセージが、ＣＡによる通信当事者の識別の認証に基づき、チャンネルを介し、大抵の場合、ファイアウォールを介して、通信される。従来の安全確保システムは、通信当事者の識別が認証される限り、当事者がチャンネルを介してお互いに通信することができるようにする。
【０００８】
アプリケーションは、通常、ユーザから提供された信用性に基づき、リソースへのアクセスを提供する。一般に、このようなアプリケーションは、ユーザの役割（role）を検証し、その役割に基づいてリソースへのアクセスを提供する。役割は、ポリシ（policy）を実施するため、しばしば財務アプリケーションまたは業務アプリケーションに使われる。例えば、アプリケーションが、要求をしているユーザが特定の役割のメンバであるか否かに応じて処理される取引の大きさに制限を課すかもしれない。事務職は、所定の閾値以下の取引を処理する認可を有し、上司はそれより高い制限を有し、そして副社長はさらに高い制限（または制限なし）を有するかもしれない。役割ベースのセキュリティは、アプリケーションが処置を完結するのに複数の承認を必要とする場合にも使うことができる。このような場合としては購買システムなどがあり、従業員の誰もが購入依頼を生成できるが、購買担当者しかその依頼を供給元に送ることのできる発注書に変換できないかもしれない。
【０００９】
既知の役割ベースの識別管理システムの１つが、Microsoft社から.NET Frameworkとして提供されている。.NET Frameworkでは、「プリンシパル」がユーザの識別と役割を表し、ユーザに代わって行動する。.NET Frameworkアプリケーションは、プリンシパルの識別または役割メンバシップ、あるいはその両者に基づき、認可の決定を行う。役割とは、セキュリティに関して同じ権利を有するプリンシパルの組に付された名称（銀行の窓口係、マネージャなど）である。プリンシパルは、１つ以上の役割のメンバであってもよい。したがって、アプリケーションは、役割メンバシップを使って、プリンシパルが要求された動作を行うことを許可されているか否かを判断することができる。
【００１０】
別の役割ベースのシステムには、EurekifyのSage Enterprise Role Manager（ERM、登録商標）と呼ばれる分析協調プラットフォームがあり、これにより、組織が、対象プラットフォームに展開された役割ベースの権利モデルの作成および管理をすることができる。Sage ＥＲＭは、組織が、その権利およびポリシを事業の観点から管理し、識別管理およびコンプライアンスの目標を達成する役割ベースアクセスコントロール（Role-Based Access Control、RBAC）の恩恵を生かすことができるようにする。
【００１１】
現在、オブジェクト・マネジメント・グループ（Object Management Group、OMG）が、役割ベースアクセスコントロール（role based access control、RBAC）ランタイム環境で適用されるＲＢＡＣポリシおよび担当者認可を定義する役割ベースアクセス・ポリシ（Roll Based Access Policy、RBAP）メタモデルの提案依頼書（OMG書類：bmi/2008-02-07）を作成している。このメタモデルは、モデリングツールとランタイムシステムとの間のＲＢＡＰモデルの交換に対応する非プラットフォーム依存モデル（PIM）となることを意図している。
【００１２】
従来の別の手法では、バークレー研究所としても知られるLawrence Berkeley National Laboratoryが、Akenti（http://dsd.lbl.gov/security/Akenti/homepage.html）と呼ばれるシステムを開発した。Akentiは、多数の利害関係者によってコントロールされている分散型ネットワークでのリソースへの制限されたアクセスを許容することに対して挙げられた問題に対処している。Akentiは、中心となる執行者および管理権限者を必要とせずに、アクセスコントロールポリシの表明と実施の方法を提供する。Akentiのアーキテクチャは、分散型ネットワーク環境での拡張性のあるセキュリティサービスを提供することを意図している。Akentiは、リソースの利害関係者のそれぞれが、他の利害関係者に依存せずに、そのアクセスコントロールの要件を執行できるように設計されている。Akentiは、それぞれの利害関係者が、その要件をいつでも変更し、新規の要件が即時に有効となることを確信させ、アクセスコントロール要件の表明での完全性および否認防止の高い保証を提供できるようにしている。
【００１３】
Akentiは、デジタル的に署名された証明書を使っている。証明書は、識別を主張（ＩＤ証明書）し、対象の属性を証明（属性証明書）し、または合致の条件を宣言（使用条件証明書）し得る。Akentiの証明書は、ユーザ識別認証とともにリソース使用要件およびユーザ属性認可を有することが可能である。Akentiにおける使用条件は利害関係者の要件に関連し、見込みのユーザは、リソースの使用を許可される前に、対応する属性証明書を示してそれを満たさなければならない。属性は、人または他の識別可能な実体の特性と関連している。Akentiの利害関係者は、その利害関係者によりコントロールされるリソースにアクセスするためにユーザが特定のグループに所属しなければならないという使用条件を課すことができる。したがって、そのようなリソースにアクセスをしたいユーザは、その特定のグループのメンバシップを対応する属性証明書で立証しなければならない。属性証明書は、ユーザまたはリソースが特定の使用条件に指定された属性を所有することを主張する。
【００１４】
Akentiのシステムでは、しかしながら、利害関係者はリソースに関係付けられている。そのような利害関係者はリソースへのアクセスを、ユーザが指定された属性に合致する必要があるという使用条件に基づいてコントロールしている。Akentiでは、リソースへのアクセスは、ユーザがリソース利害関係者に指定された属性要求に合致する限り許可される。Akentiシステムの欠点の１つは、リソース利害関係者ではない利害関係者または権限者のセキュリティ要件には適応していないことである。このような非リソース利害関係者は、リソース利害関係者がユーザのリソースへのアクセスを回避しない限りは、ユーザのリソースへのアクセス権についてのコントロールができない。言い換えれば、Akentiのリソース利害関係者は、非リソース利害関係者によってそのアクセスが禁止されるようなユーザのリソースへのアクセスを許可してしまうことになる。
【００１５】
ケルベロス（Kerberos）と呼ばれるコンピュータネットワーク認証プロトコルが知られており、安全ではないネットワークを介して通信する個人が安全な方法でお互いの識別を立証することができる。マサチューセッツ工科大学（MIT）から公開された一式のフリーソフトで、主にクライアント−サーバ・モデルにおいて、お互いの識別をクライアントおよびサーバの両者が検証するような相互認証を提供するケルベロス・プロトコルを実装することができる。ケルベロス・プロトコル・メッセージは、傍受およびリプレーアタックに対して保護されている。
【００１６】
ケルベロスは、対称鍵暗号化方式を基に構築されており、鍵配布センタ（Key Distribution Center、KDC）と称する信頼される第三者機関を必要とし、それは、認証サーバ（Authentication Server、AS）とチケット交付サーバ（Ticket Granting Server、TGS）との２つの論理的に分離された部分からなる。ケルベロスは、ユーザの識別を立証する「チケット」に基づいて動作する。
【００１７】
鍵配布センタ（KDC）は、秘密鍵のデータベースを維持する。クライアントかサーバに関わらず、ネットワーク上の実体のそれぞれは、それ自身と鍵配布センタ（KDC）のみが知っている秘密鍵を共有する。この鍵を知っていることが、実体の識別を立証することになる。２つの実体間の通信においては、ＫＤＣがセッション鍵を生成し、それは、それらの相互作用の安全確保に使うことができる。しかしながら、ケルベロス・プロトコルを使うには、「チケット」が、ＫＤＣ、またはセントラルサーバに問合せて検証されなければならず、実装されたシステムの単一障害発生点の問題を招くことになる。ケルベロスの単一障害発生点の特性は、組み込みシステムや自律システムなどの間欠的または故障傾向の通信能力を有するシステムにとっては都合が良くない。
【００１８】
したがって、情報システムのセキュリティ・ニーズがより複雑になっており、先進で高度な安全確保パラメータに基づいてアクセスをコントロールする安全なシステムおよび方法の必要性がある。
【発明の概要】
【００１９】
簡潔には、本発明の１つの態様によれば、暗号化証明書を発行するシステムまたは方法は、暗号化証明書に１つ以上の前提条件を記述する。前提条件は、実体の前提条件グループのメンバシップを含んでいる。決定を行うために前提条件グループのメンバシップを使うことにその承認を必要とする１つ以上の前提条件グループ利害関係者（または権限者）が、暗号化証明書に署名する。そのような承認に基づく決定の例は、グループのメンバシップへの加入、リソースへのアクセスの付与、または動作を行うことに関連している。１つの実施の形態では、前提条件グループの識別または名称は、前提条件グループ利害関係者の識別に関係する。例えば、利害関係者の公開鍵が、前提条件グループの識別の一部となり得る。別の実施の形態では、証明書がリソースへのアクセスの権利を付与する。証明書は、権利またはリソースへのアクセスをコントロールする１つ以上の利害関係者または権限者が署名し得る。
【００２０】
さらに、暗号化証明書を処理する方法は、実体の前提条件グループの少なくとも１つのメンバシップを含む前提条件の少なく１つを記述する暗号化証明書を受け取り、その暗号化証明書が、決定を行うために前提条件グループのメンバシップを使うことにその承認を必要とする前提条件グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断する。
【００２１】
本発明の別の態様によれば、暗号化証明書を発行するシステムまたは方法は、暗号化証明書に１つ以上の前提条件を記述する。１つ以上の前提条件は、実体の前提条件グループのメンバシップを含んでいる。実体は、参加者、リソース、または権利などでもよい。本発明は、また、１つ以上の実体の目標グループの名称を記述する。１つ以上の前提条件利害関係者または権限者が暗号化証明書に署名し、１つ以上の前提条件グループの実体に、別の１つ以上の実体の目標グループのメンバとして加えられることを許可する。前提条件の例は、とりわけ、１つ以上の別の実体のグループのメンバシップ、物理的特性、時間特性、場所特性、または位置特性に関連している。
【００２２】
本発明のさらなる詳細な特徴によれば、１つ以上の前提条件グループの名称は、前提条件グループのメンバに別のグループのメンバシップを許可する１つ以上の前提条件グループ利害関係者の名称、およびその１つ以上の前提条件グループでのメンバシップを許可する１つ以上の前提条件グループ利害関係者の名称を含んでいる。１つ以上の前提条件グループの名称は、さらに、１つ以上の前提条件グループの曖昧さの無い識別子を含んでいる。１つの実施の形態の例では、１つ以上の前提条件グループ利害関係者の名称は、１つ以上の前提条件グループ利害関係者の公開鍵を含んでいる。１つ以上の前提条件グループ利害関係者の署名は、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含んでいる。
【００２３】
同様に、１つ以上の目標グループの名称は、目標グループの実体の別のグループへのメンバシップまたは追加を許可する１つ以上の目標グループ利害関係者の名称、および実体に１つ以上の目標グループのメンバとなることを許可する１つ以上の目標グループ利害関係者の名称を含んでいる。１つ以上の目標グループ利害関係者の名称は、１つ以上の目標グループ利害関係者の公開鍵を含んでおり、１つ以上の目標グループ利害関係者の署名は、１つ以上の目標グループ利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含んでいる。
【００２４】
本発明のさらに別の態様によれば、暗号化証明書は、１つ以上の前提条件グループの名称と、１つ以上の目標グループの名称と、前提条件グループの実体に別のグループの実体となることを許可する前提条件グループ利害関係者の１つ以上の暗号化署名と、実体の名称を目標グループに加えることを許可する目標グループ利害関係者の１つ以上の暗号化署名とを含んでいる。
【００２５】
本発明のさらに別の態様によれば、暗号化証明書を処理するシステムは、複数の実体を含んでいる。システムは、また、１つ以上のメンバシップ証明書を含んでいる。メンバシップ証明書のそれぞれは、１つ以上の前提条件グループの名称、１つ以上の目標グループの名称、および１つ以上の前提条件グループ利害関係者ならびに目標グループ利害関係者として機能する１つ以上の利害関係者の名称を含んでいる。グループメンバシップ証明書は、前提条件グループの実体に別のグループの実体となることを許可する１つ以上の前提条件グループ利害関係者によって暗号化署名されていれば有効である。グループメンバシップ証明書は、さらに、実体を目標グループに加えることを許可する１つ以上の目標グループ利害関係者によって暗号化署名される。ノードは、実体から暗号化証明書を受け取る。ノードは、有効なグループメンバシップ証明書を検査し、受け取った暗号化証明書が、実体を有効なグループメンバシップ証明書で指定された前提条件グループに有効に結び付けるならば、その実体を有効なグループメンバシップ証明書で指定されている目標グループに加える。
【図面の簡単な説明】
【００２６】
【図１】図１は、リード、ライト、およびリード／ライトの権利によってストレージリソースと相互作用するクライアントステーション参加者のグループ化の一例を示す概念図である。
【００２７】
【図２】図２は、グループ名の一例を示す図である。
【００２８】
【図３】図３は、実体に関係する前提条件を目標グループに結び付けるグループメンバシップ証明書（GMC）を示す図である。
【００２９】
【図４】図４は、グループに関係する１つ以上の前提条件を目標グループに結び付けるＧＭＣを示す図である。
【００３０】
【図５】図５は、本発明の実施の形態の例を実装するシステムのブロック図である。
【００３１】
【図６】図６は、参加者のグループ化のＧＭＣの一例を示す図である。
【００３２】
【図７】図７は、リソースのグループ化のＧＭＣの例を示す図である。
【００３３】
【図８】図８は、権利のグループ化のＧＭＣの例を示す図である。
【発明を実施するための形態】
【００３４】
本発明は、実体のグループを定義するために暗号化証明書を応用するシステムまたは方法に関する。グループ化される実体は性質がさまざまであってもよく、暗号化証明書で名称付け、または識別される能力以上の特性を有することを必要とされない。実体の例としては、物理的および論理的実体の両者である人間、プロセッシングユニット、ノード、クライアントステーション、ファイルシステム、コンピュータハードウェア、コンピュータプログラムの実行インスタンス、リードまたはライトアクセス権、オペレーティングシステム権、ストレージリソース、コンピュータリソース、および／または通信リソース、あるいは他のグループが含まれる。
【００３５】
図１は、１つ以上の権利によってストレージリソースと相互作用するクライアントステーション参加者のグループ化の一例を示す概念図である。参加者は、秘密の保持、およびその秘密を漏らすことなく他の参加者にその秘密の認識の立証が、例えば、ANSI X9.63、IEEE 1363-2000、およびISO/IEC 15946-3で標準化された楕円曲線ＭＱＶ（Elliptic Curve MQV）プロトコルのような相互認証プロトコルを使って可能な任意の実体からなる。１つの実施の形態では、参加者は、ハードウェアまたはソフトウェアで実現でき、暗号化された公開鍵を使って識別化、または名称付けされることができる。参加者は、とりわけ、ウェブ・クライアント、ＳＱＬクライアント、ファイルサーバ、イーサネットカード、パーティション、アプリケーション、ノード、システム、コンピュータ、または機器であってもよい。
【００３６】
１つの実施の形態では、参加者は、リソースと直接的に、およびリソースを介して他の参加者と間接的に相互作用が可能な実体からなる。リソースは、非参加者実体からなり、それには、限定されるものではないが、実行され、使用され、利用され、作成され、または保護されるいかなるハードウェア、ファームウェア、データ、および／またはソフトウェアが含まれる。リソースは、参加者ではない。暗号的にグループ化できる本発明に係るリソースの例には、ファイルシステムに保存されるファイル、ネットワークスタック（network stack）のポート、コンピュータのランダムアクセスメモリ、などが挙げられる。他のリソースの例としては、使用可能なあらゆるプロセッシングパワー、リンク、通信チャンネル、Ｉ／Ｏバス、メモリバス、ハードウェアまたはソフトウェアとともに、ソケットライブラリ、プロトコルスタック、デバイスドライバなどが含まれる。リソースには、あらゆる適切な非対称および／または対称鍵暗号化アルゴリズムおよび本発明に係る方法を実装する暗号化／復号化ユニットも含むことができる。
【００３７】
本発明の１つの実施の形態では、リソースは、必要な権利を有する参加者によって作用または消費され得る実体である。権利は、１つ以上の参加者と１つ以上のリソースとの間で許容される相互作用からなる。例えば、ファイルリソースに関係する権利には、そのファイルリソースからのリード（読み込み）またはそのファイルリソースへのライト（書き込み）、あるいはその両者の権利が挙げられる。別の例としては、ランダムアクセスメモリ（RAM）を使ってプログラムを実行する権利がある。
【００３８】
上述のように、１つの実施の形態の例では、参加者は、秘密を保持し、その秘密を漏らすことなくその秘密の認識を他の参加者に立証することができるので、暗号化公開鍵により名称付け、または識別化される。しかし、リソースおよび権利は、そのリソースまたは権利を識別するのに十分に詳細なリソースまたは権利の記述を使って名称付けされ、参照され、または識別される。
【００３９】
一般に、本発明は、１つ以上の名称付けされた実体、例えば、参加者、リソース、または権利がグループのメンバか否かを判断する手段としての１つ以上の証明書を使用、および作成するシステムまたは方法に関する。本発明の証明書は、セントラルサーバに問合せすることなしに検証することができる。選択的に、本発明を実装したシステムまたは方法は、識別可能なさらなる情報を複数の実体またはグループのいずれかと関係するまたは結び付けることができるさらなる証明書を含んでもよい。したがって、本発明においては、グループメンバシップ証明書（Group Membership Certificate、GMC）として知られる１つ以上の証明書が、１つ以上の実体が１つ以上の目標グループのメンバであるか否かを定義している。個別の実体および１つ以上の実体のグループは、ＧＭＣに、目標グループのメンバシップが指定される。ＧＭＣは、目標グループ名の名称とともに、１つ以上のグループメンバシップ前提条件（group membership prerequisite condition、GMPC）を記述している。典型的なＧＭＰＣの例では、そのＧＭＰＣの充足可能性が評価される際に、ＧＭＣに依存する当事者により検証可能な条件との合致の証明を必要とするかもしれない。その条件には、別の名称のグループのメンバシップ、特定の名称を有する実体であることの証明、および状態、高さ、幅、形状、時間、場所、位置、配置、振幅、位相、周波数、電流、電圧、抵抗などに関連する特性を含む物理的（例、機械的、光学的、熱的、幾何学的など）、非物理的、時間的または非時間的特性を有することの証明が含まれる。典型的な証明の例には、現在の配置と所定の配置との合致の証明、生体特性の合致の証明、現在の日時と所定の日時との合致の証明などがある。
【００４０】
例えば、複数の実体は、メンバシップに必要な前提条件に合致する場合、それ自体が目標グループのメンバとなり得る指定された前提条件グループの一部となることが可能である。このように、それぞれのＧＭＣは、指定された目標グループのメンバシップ前提条件を表す。定義された満足基準に従って１つ以上の前提条件を満足させることにより、実体に目標グループのメンバシップが付与される。本発明のさまざまな実施の形態では、目標グループのメンバシップ前提条件満足基準は、それぞれの前提条件を満足させること、前提条件の１つを満足させること、その演算子が論理積（AND）および宣言肢（OR）とからなるブール代数の式で記述される前提条件の組み合わせを満足させること、総数ｎ個の前提条件のｍ個を満足させること、のいずれか１つと関連することができる。
【００４１】
上述のように、実体に目標グループのメンバシップが付与されるには、グループメンバシップ前提条件を満足させることが必要である。以下に記述するように、必要な権限を有する利害関係者がグループメンバシップ証明書（GMC）に署名して１つ以上のグループメンバシップ前提条件（GMPC）を目標グループに結び付け、これにより、１つ以上の前提条件に合致する１つ以上の実体が指定された目標グループのメンバとなることができる。
【００４２】
このように、本発明は、グループの名称に追加の情報を含むことを必要とすることにより、実体をグループ化する既存の証明書ベースの方法を拡張している。１つの実施の形態の例では、グループ名は、直接的または間接的に、決定の要素としてグループのメンバシップを使用することにその許可が必要とされる権限者の公開鍵を含んでいる。このことは、決定と使用の権限者の組が等しいときにのみ、２つのグループが同じ名称を有することになる。グループ名は、本発明の情報と制約とが含まれ適用される限りにおいて、他の情報を含んでもよく、本発明を実装するシステムにおける平等性のさらなる制約を有してもよい。よって、それぞれのグループメンバシップ証明書（GMC）は、１つ以上の前提条件を目標グループの名称に結び付ける。図２に、グループ名のテンプレートの例を示す。
【００４３】
本発明の１つの実施の形態の例では、２つのタイプのグループメンバシップ証明書（GMC）が実装されている。図３は、実体に関係する前提条件を目標グループに結び付けるＧＭＣを示し、図４は、他のグループのメンバシップのための１つ以上の前提条件を目標グループに結び付けるＧＭＣを示す。図３のＧＭＣの例によれば、グループメンバシップ前提条件は、実体が特定の名称、例えば、ジョン・ドウ、を有し、目標グループに所属することの証明を含み、その実体のその目標グループへの結び付きがＧＭＣの適切な利害関係者の署名により明示されている。図４のＧＭＣの例によれば、グループメンバシップ前提条件は、別の名称の前提条件グループのメンバシップの証明を含み、同じく、その名称の前提条件のグループの目標グループへの結び付きがＧＭＣの適切な利害関係者の署名により明示されている。
【００４４】
したがって、グループメンバシップ証明書（GMC）の有効性は、そのＧＭＣの必要な利害関係者による有効な暗号化署名の存在によって判断され、それがグループメンバシップ前提条件を１つ以上の目標グループのメンバシップと結び付ける。利害関係者は、１つ以上の目標グループの名称およびグループメンバシップ前提条件（GMPC）で指定されたグループまたは個人の名称で識別される。本発明の１つの実施の形態によれば、「トゥ・ザ・グループ（to-the-group、グループへ）」利害関係者と呼ばれる１つの種類の利害関係者は、目標グループへの加入の許可を付与する。目標グループに所属する一組の実体の拡張には、証明書にトゥ・ザ・グループ利害関係者の署名が必要である。「フロム・ザ・グループ（from-the-group、グループから）」利害関係者と呼ばれる別の種類の利害関係者は、グループ名で識別される。このようなグループ名は、直接的または間接的に、決定の要素としてそのグループのメンバシップを使用することにその許可が必要とされる権限者の公開鍵を含んでいる。例えば、フロム・ザ・グループ利害関係者は、１つのグループの実体に別のグループのメンバになること、またはそのグループのメンバシップの証明に権利のような追加の情報を結び付けることの許可を付与する。目標グループのメンバシップの前提条件として、あるグループのメンバシップの証明の使用を許可するためには、ＧＭＣにフロム・ザ・グループ利害関係者の署名が必要である。フロム・ザ・グループ利害関係者の署名は、前提条件としてそのグループのメンバシップを必要とする権利を付与する証明書など、情報をそのグループに結び付ける他の証明書にも必要である。
【００４５】
グループメンバシップ証明書（GMC）に現れるグループの名称は、前提条件グループまたは目標グループに関わらず、複数の部分からなる。第一に、グループ名は、それぞれのトゥ・ザ・グループ利害関係者の暗号化公開鍵を判断するのに十分な情報を含んでいる。第二に、グループ名は、それぞれのフロム・ザ・グループ利害関係者の暗号化公開鍵を判断するのに十分な情報を含んでいる。利害関係者の一組を記述する情報の形式の一例は、利害関係者の公開鍵の明示的にリストすることである。あるいは、その識別子を公開鍵に結び付ける固有のＩＤ証明書に転換する識別子の一組が使われてもよい。選択的に、グループの名称には、同じトゥ・ザ・グループとフロム・ザ・グループ利害関係者の組を有する他のグループからそのグループを区別する役割をする１つ以上の曖昧さのない識別子が含まれてもよい。曖昧さのない識別子の例には、テキスト普通名詞、デジタル画像、デジタル音、これら識別子の暗号化ハッシュ、またはこれら識別子の組み合わせが含まれる。
【００４６】
図３に示すグループメンバシップ証明書（GMC）は、実体が名称を与えられていることの証明を必要とする１つのグループメンバシップ前提条件（GMPC）を含んでいる。さらに、ＧＭＣは、証明書がメンバシップを付与するグループの１つの目標グループの名称を含んでいる。目標グループ名は、曖昧さのない識別子、および任意の数の変数ｍで表されるトゥ・ザ・グループ利害関係者の識別子ならびに変数ｎで表されるフロム・ザ・グループ利害関係者の識別子からなる。前提条件実体名を目標グループ名に結び付けることを有効にするため、図３のＧＭＣは、目標グループのトゥ・ザ・グループ利害関係者１〜ｎの署名を含んでいる。上述のように、図３の目標グループのトゥ・ザ・グループ利害関係者１〜ｎは、目標グループのメンバシップに、図３のＧＭＣに指定される前提条件実体名が含まれるように拡張することができる。図３のＧＭＣは、別のグループのメンバシップへの前提条件としてグループのメンバシップの証明を必要としないので、ＧＭＣの有効性にフロム・ザ・グループ利害関係者の署名は必要とされない。
【００４７】
図４に示すグループメンバシップ証明書（GMC）は、変数ｋで表される数の前提条件グループ名からなる任意の数のグループメンバシップ前提条件（GMPC）を含んでおり、それぞれが、実体に、目標グループへのメンバシップを得るために、対応する前提条件グループのメンバシップを立証することを必要とする。このＧＭＣは、グループメンバシップがＧＭＣの前提条件として使用されるときに、ＧＭＣ有効性の署名要件を立証するように設計されている。図４のＧＭＣの前提条件としてメンバシップがリストされた各グループの名称は、任意の数の変数ｍで表されるトゥ・ザ・グループ利害関係者、および変数ｎで表されるフロム・ザ・グループ利害関係者とを有する。これらの変数は、前提条件グループの名称の範囲内とされ、ＧＭＣのそれぞれの前提条件グループ名においては、異なる値のｍおよびｎを使用することができる。前提条件名の目標グループ名への結びつきを有効とするために、図４のＧＭＣは、２つのタイプの利害関係者の署名を含んでいる。図４のＧＭＣは、前提条件としてメンバシップがリストされたグループのフロム・ザ・グループ利害関係者の署名を含んでいる。また、図４のＧＭＣには、図４の目標グループのトゥ・ザ・グループ利害関係者の１〜ｎの署名が必要とされ、それにより、図４のＧＭＣで指定された前提条件グループのメンバシップを証明できる実体を盛り込んで目標グループのメンバシップを拡張することができる。
【００４８】
本発明を実装したシステムは、基本的にグループのメンバシップについての記述からなるグループメンバシップ証明書（GMC）のそれぞれを調べることによって、グループのメンバシップについて学習する。システムは、当初、グループは空であると考える。このようなシステムは、その後、ＧＭＣを調べて、実体がグループのメンバとなるのに十分な条件を学習する。本発明の１つの実施の形態では、システムが、複数のＧＭＣが同じ目標グループを有する異なるグループメンバシップ前提条件（GMPC）を含むことを知った場合は、いずれかの証明書の前提条件を満たすことで、実体が目標グループのメンバシップを得るのに十分であるとする。よって、グループのメンバシップから除外される実体側に、およびそのシステムへのさらなるＧＭＣの導入または追加に発行されるＧＭＣエラーのそれぞれへのアクセスを有しないシステムは、所定のグループのメンバシップを有する実体の数を増加することはできるが、減少させることはできない。このように、セントラルサーバに問合せをすることなく、ＧＭＣを検証することができる。よって、ケルベロスのシステムとは違って、単一障害発生点を招くことはない。
【００４９】
２つのグループ名は、第１のグループ名のトゥ・ザ・グループ利害関係者およびフロム・ザ・グループ利害関係者の一組が、第２のグループ名のトゥ・ザ・グループ利害関係者およびフロム・ザ・グループ利害関係者の一組と同じで、第１のグループ名の曖昧さの無い識別子が第２のグループ名の曖昧さの無い識別子と同じである場合、同一のグループを称することになる。
【００５０】
本発明では、ＧＭＣを種々の状況に適用できる。本発明の１つの適用例は、参加者、リソース、および／または権利間で許容される関係を記述するセキュリティ・ポリシ（SP）の生成、評価、および実施である。参加者、リソース、および／または権利間の関係は、対応する利害関係者によって許可され、参加者のリソースへのアクセスを、もしあれば、権利に従って、仲介する１つ以上のガードによって実施される。
【００５１】
図５は、本発明を使った強制アクセスコントロール・セキュリティ・ポリシ（SP）の実施を実装するシステムの一例を示す。このシステムは、１つ以上のノードを使って実装されている。ノードには、通常、コード、プログラム、および／またはアプリケーションを実行する１つ以上のＣＰＵ、マイクロプロセッサ、埋め込み型コントローラ、デジタルシグナルプロセッサ（DSP）などのプロセッシングユニット（不図示）が含まれる。それぞれのノードは、有線または無線ノード、クライアント、サーバ、ルータ、ハブ、アクセスポイント、およびリソースを使って他の機器と通信する他の既知の機器、の１つまたは組み合わせであってもよい。
【００５２】
１つの実施の形態の例では、図５のノードは、分離カーネル（Separation kernel、SK）のコントロールの下にハードウェア上で実行されるパーティション、および有線または無線ネットワークを介してノードに接続される任意の数のクライアントを含んでいる。本発明の１つの実施の形態の例によれば、ノードは、ＳＫのコントロールの下で実行される。本発明において使用することができるＳＫのクラスの一例は、国家安全保障局（National Security Agency、NSA）から公開されている「U.S. Government Protection Profile for Separation Kernels in Environment Requiring High Robustness（高ロバスト性要求環境における分離カーネルの米国政府保護プロファイル、SKPP）」という題の保護プロファイル（Protection Profile、PP）に記載されており、参照により、その全体が本明細書に援用される。本発明は、ＳＫの使用または不使用でのクライアント−サーバ・モード、リアルタイムおよびノンリアルタイム分散型ネットワーク、セントラルネットワーク、ピアツーピア・ネットワーク、埋め込み型システムなどのような、あらゆるタイプのコンピューティング・モデルを使用するあらゆるシステムまたはネットワークにおいて使用できることに留意すべきである。
【００５３】
本発明の１つの実施の形態の例によれば、図５に示す少なくとも１つのノードは、対応する分離カーネル（SK）のコントロールの下で実行される。分離カーネルのそれぞれは、そのホストソフトウェアプログラムに、不正な改ざんを防止し、かつ回避することが不可能な高保証性のパーティションと情報フローコントロールの特性を提供する。分離カーネルは、ハードウェアおよび／またはソフトウェア機構で、その主な機能は、ノードの複数のパーティションの生成である。パーティションは、１つ以上のセキュリティ・ポリシ（SP）のすべてまたはその一部を実装する構成データに従って、そのコントロールの下のリソースから分離カーネルによって実装される抽象化である。さらに詳細に説明すると、本発明は、システムのセキュリティ・パラメータを実装する利害関係者によって署名されたセキュリティ・ポリシを使用する。それぞれの分離カーネルパーティションは、少なくとも１つの対象および／またはリソースを含んでいる。対象とは、機能を行うノードのコントロールの範囲内の実体であり、その機能は、例えば、ノード相互間通信機能である。リソースは、対象によって個別にまたは同時に使用され、リソース内の情報への対象のアクセスを許容する。本発明のシステムの参加者は、同一のノード、または１つ以上の通信チャンネルを介して互いに接続された異なるノードにおける１つ以上の分離カーネルによって定義されるノード、パーティション、または対象で実現される。
【００５４】
分離カーネル（SK）のコントロールの下で動作しているノードは、ノード上のパーティションで実行される対象およびリソースを、セキュリティ・ポリシ（SP）に違反する情報フローから保護する。分離カーネルは、リソースをポリシ・ベースの同値類に分離し、分離カーネルの構成データに従ってパーティションに割り当てられた対象およびリソース間の情報フローをコントロールする。１つの実施の形態では、ノードは、単一の分離カーネルを実行するハードウェアリソースからなり、そこでは、分離カーネルが、分離カーネルの構成データに従って、ノードの複数のパーティション間、および／またはその範囲内の情報フローをコントロールする。特に、それぞれのノードは、それぞれ独自の分離カーネルを実行し、その分離カーネルはそのノード固有のリソースを保護する。好ましくは、分離カーネル構成データの仕様が一義的で、試験官が、ポリシ、およびポリシによって指定されるそれぞれのリソース割り当てルールによって、ある接続が許容されるか否かを判断（恐らくツールを使って）できることである。
【００５５】
本発明は、公開鍵ならびに秘密鍵、および所望のセキュリティ・ポリシ（SP）の実装に必要なデジタル的に署名された承認の生成または取得のために、種々のツールを使っている。それぞれのノードは、公開鍵と秘密鍵との対からなる関係するノード識別（NI）を有している。ノードにおけるそれぞれのパーティションは、対応するパーティション識別（PI）を有している。各パーティションのＰＩは、パーティションが生成されたノードのＮＩの公開鍵およびノード上のそのパーティションを呼称する固有のインデックスからなる一対の値からなる。
【００５６】
図５に示すシステムでは、パーティションのファイルシステムのリソースを保護することを信頼できるパーティションに、ガードが実装されている。ガードは、そのアクセスがセキュリティ・ポリシ（SP）と一貫性がなければ、参加者として作動するクライアントに、ファイルシステム・パーティションへのアクセスが得られないことを確保しなければならない。ファイルシステム・パーティションには、セキュリティ・ポリシに適合するクライアントのみがアクセス可能である。１つの実施の形態では、ファイルシステム・パーティションは、提示されるそれぞれの要求を満たそうとし、セキュリティ・ポリシの実施には参加しない。代わりに、１つのクライアントのデータを他のクライアントから保護するポリシがガードによって実装される。ネットワークは、クライアントを、ファイルシステム・パーティションの基準モニタとして作動するガード・パーティションに接続する。クライアントは、分離カーネルオペレーティングシステム、またはMicrosoft Windows（登録商標）やLinuxなどの従来のオペレーティングシステムのいずれかを実行することができる。別の実施の形態では、ファイルシステムへのアクセスに、リソース利害関係者の認可も必要とすることができる。
【００５７】
ガードは、ハードウェアまたはソフトウェアで実現することができる。ガードの一例には、分割通信システム（Partitioning Communications System、PCS）、仮想プライベートネットワーク（VPN）実装が挙げられる。ＰＣＳは、本願の出願人に譲渡された2005年5月10日付け出願の米国特許出願11/125099号に開示されており、参照により援用される。ＰＣＳは、マルチレベル・セキュア（MLS）システムに対応し、それにより、多くのより高レベルの技術を重ねて安全な分散型通信を可能にする。このように、ＰＣＳは、信頼できる分散型システム実装の構成ブロックとして使用することができる。ＰＣＳは、１つ以上のチャンネルを介して別のノードまたはクライアントとデータのやり取りをするノード内の通信コントロール要素である。ＰＣＳは、分離カーネル（SK）によりコントロールされるパーティション間のデータフロー・ポリシに対応している。ＰＣＳは、対応するＳＫのコントロール下で実行されている、または実行されていないノード／クライアント間の通信を提供するハードウェアおよび／またはソフトウェアの組み合わせを配備する。このようにして、ＰＣＳは、そのセキュリティが、物理的なハードウェアの分離や保護、または特定のネットワークハードウェアに依存しないマルチドメイン・ネットワークの生成を可能にする。
【００５８】
本発明においては、図５に示すガードは、広範囲な種類のリソースの保護またはコントロールをすることができ、このリソースには、イーサネットスイッチ、ネットワークルータ、オペレーティングシステム・カーネル、表示モニタ、キーボード、マウス、プロジェクタ、ケーブル・セットトップボックス、デスクトップコンピュータ、ラップトップコンピュータ、サーバ・コンピュータ、サテライト、センサ、シュータ（shooter）、無人機、航空電子工学機器、ビデオ／オーディオ機器、電話、携帯電話、電話交換機、テレビ放送装置、テレビ、データベース・サーバ、クロスドメイン・ガード、分離カーネル、ファイルサーバ、ビデオおよび／またはオーディオ・サーバ、スマートカード、またはＰＤＡが挙げられる。
【００５９】
本発明においては、グループメンバシップ証明書（GMC）は、セキュリティ・ポリシ（SP）の対象となるあらゆるタイプの実体のグループ化に使われる。例えば、ＧＭＣは、後から権利と関係付けられる参加者のグループの作成に使われてもよい。個々の参加者それぞれを所望の権利と関係付ける従来の役割ベースアクセスコントロール（RBAC）システムとは異なり、本発明に係るグループ化は、より簡潔で管理可能なステートメントのセキュリティ・ポリシを可能にする。本発明のＧＭＣの適用は、グループ名を記述する個別のトゥ・ザ・グループ利害関係者とフロム・ザ・グループ利害関係者との組の存在によって、従来の役割ベースアクセスコントロールよりも、より高い表現力をもたらす。この利害関係者の分離は、あるグループへの実体の加入を認めることを信頼された利害関係者の組と、そのグループへの権利または別グループへのアクセスを得るためにそのグループのメンバシップを使う権利を割り当てることを信頼された利害関係者の組とが同じではない場合に望ましい。例えば、品質管理検査官は、ある無線通信機を標準準拠の無線通信機を表すグループに加入させることを信頼されているかもしれないが、別の利害関係者（例えば、ＦＣＣ（米国連邦通信委員会））が、その無線通信機を特定周波数で無線通信機が送信できるグループに加入させることに関与しているかもしれない。
【００６０】
別の実施の形態では、グループメンバシップ証明書（GMC）は、リソースのグループを作成することで、セキュリティ・ポリシの実装に使うことができる。特定のリソースを指定して権利を付与する代わりに、本発明の実施の形態では、適用されるＧＭＣで定義されるリソースのグループのそれぞれのリソースにわたる権利を付与する。例えば、リソースがコンピュータファイルの場合、それらのファイルを対応するＧＭＣで定義されるグループのメンバとすることができる。このグループで定義されたファイルの組は、新規のＧＭＣが発行されることによって増やされることができる。さらに別の実施の形態では、権利をグループ化でき、参加者は、所定のリソースにおける権利のグループのそれぞれの権利を付与されることができる。さらに、ＧＭＣのあらゆる組み合わせを１つのシステムとして組み合わせられ、参加者、リソース、および／または権利を必要に応じてグループ化することができる。
【００６１】
したがって、本発明のグループメンバシップ証明書（GMC）は、所望のセキュリティ・ポリシの実施に使うことができる。ＧＭＣは、クライアントによりネットワークを介して特定の名称を有するなどの前提条件を満たすことをガードに証明した後で、そのガードに提示することができる。この証明は、Ｘ．５０９のＩＤ証明書の提示との組み合わせで、ＥＣＭＱＶなどの暗号化認証および鍵設定プロトコルの実行によって達成することができる。ＧＭＣを使ったマルチレベル・セキュリティにBell-LaPadulaモデルを実装したい利害関係者は、クライアントを参加者として扱い、そのクライアントを使う個人のセキュリティ・クリアランスレベルに従ってグループ化してもよい。さらに、ファイルシステムのパーティションをリソースとして扱い、その機密レベルに従ってグループ化してもよい。クライアントを使う個人のセキュリティ・クリアランスレベル以外の要素を、クライアントに所定のファイルシステム・パーティションへのアクセスの権利が与えられるべきかの判断の一因としてもよい。本発明は、これらの決定の構成要素を個別に表現することができ、各構成要素の充足の判断を、認可決定の結果へのコントロールを失うことなく、異なる当事者に委任することができる。
【００６２】
例として、機密レベルの極秘ファイルシステム・パーティションへのアクセスをコントロールする利害関係者は、それらのパーティションへのリードアクセスに、以下のような条件が必要と決定するかもしれない。それらは、クライアントを使用する個人は機密レベルまたはそれより高いセキュリティ・クリアランスレベルを有すること、クライアントが安全の確保された施設内に存在すること、クライアントが安全で確実なオペレーティングシステム上で実行されていること、である。さらに、この機密レベル利害関係者は、クライアントに対するこれらの事実のそれぞれを判断することが可能な個人または機関を知っており、それぞれの条件を個別に検証することを、その認識する個人または機関に委任することを望んでいる。しかしながら、この利害関係者は、異なる検証を行っているその個人または機関に、これらの判断を別の状況において使う能力を委任したいとは思わない。
【００６３】
本発明を使って、機密レベルの利害関係者は、４つのグループを指定する。第１の指定グループには、機密クリアされたクライアントコンピュータであることが記述され、機密レベル利害関係者をそのグループの唯一のトゥ・ザ・グループ利害関係者および唯一のフロム・ザ・グループ利害関係者として含んでいる。これにより、機密レベル利害関係者が、そのグループへの権利を提供するグループメンバシップ証明書（GMC）の発行が可能な唯一の実体であること、および機密レベル利害関係者が、そのグループにクライアントを加入させるＧＭＣの発行が可能な唯一の権限者であることが保証される。
【００６４】
続いて、機密レベル利害関係者は、極秘機密ファイルシステムへのアクセスのために満たされなければならない前提条件それぞれに１つの追加グループを指定する。これらの追加グループの名称には、その条件を検証することが信頼された機関がトゥ・ザ・グループ利害関係者として、そして機密レベル利害関係者がフロム・ザ・グループ利害関係者としてリストされている。これにより、委任された利害関係者が、条件の検証を表わすグループにクライアントを加入させる唯一の実体であり、機密レベル利害関係者が、それらの条件の検証のグループを前提条件として使って証明書を発行できる唯一の利害関係者であることが保証される。これらのグループは、目標グループでのメンバシップの前提条件を表している。
【００６５】
最後に、機密レベル利害関係者が、図６に示すように、グループメンバシップ証明書（GMC）に署名をし、前提条件の検証を表す３つのグループのメンバであるクライアントが機密レベル・クライアントグループのメンバとなることができる。機密レベル利害関係者がこれらの前提条件グループのフロム・ザ・グループ利害関係者であり、目標グループのトゥ・ザ・グループ利害関係者であるので、ＧＭＣが有効であり、これ以外の署名が必要とはされない。誰かが新規のクライアントコンピュータで機密レベル・クライアントグループのメンバシップを必要とする情報にアクセスしたい場合、その人は、前提条件グループに指定されている機密レベル利害関係者に指定されたトゥ・ザ・グループ利害関係者とやり取りし、その条件が満足されたことをそれらの利害関係者に納得させることができる。その条件検証利害関係者が納得させられると、その条件検証利害関係者は、そのクライアントコンピュータを前提条件実体とし、検証した条件を表わしているグループを目標グループとしてリストしたＧＭＣを発行することができる。条件検証利害関係者が、グループ名にリストされたトゥ・ザ・グループ権限者であり、他のグループが関係していないので、ＧＭＣはそれ以上の署名を必要としない。よって、新規クライアントが、機密レベル利害関係者と関わり合うことなく、条件検証利害関係者を委任された利害関係者とのやり取りを必要とするのみで、機密レベル・クライアントグループのメンバとなることができる。
【００６６】
本発明は、ガードがそのセキュリティ感度レベルに従って保護するリソースをグループ化することにより、図５に示すガードをさらに強化するために使用することができる。例えば、パーティション１およびパーティション２の２つのファイルシステム・パーティションが機密レベルの感度を有する場合、機密レベル利害関係者は、それら両者のリソースパーティションを含む機密レベル感度グループを作成することができる。このグループは、図７に示すようなリソースをグループ化するグループメンバシップ証明書（GMC）を使って作成することができる。図７の証明書を有するガードは、パーティション１およびパーティション２の両者に適用されるそれらの証明書の目標グループの参加者に権利を付与することができる。
【００６７】
図５に示すシステムのさらなる改善として、ＧＭＣを使って権利を組み合わせてグループ化する。例えば、１つの名称が複数の権利を伝える場合、個々の権利をリードおよびライトとすると、リードアクセス権とライトアクセス権とに名称付けられたグループとなる。「全コントロール」と名付けられた実体を、図８に示す証明書を使って、これら両者のグループに加入させることができる。ガードがこのＧＭＣを保有する場合、ガードは、この「全コントロール」実体を、リードアクセス権グループおよびライトアクセス権グループのメンバシップにより、リードおよびライトの権利を所有するものとして扱うことができる。
【００６８】
前述によれば、１つの実施の形態の例では、グループ名は、決定、例えば、リソースへのアクセス許可、機能の実施、または別のグループへのメンバシップの付与、を行うのにそのグループのメンバシップを使うことにそれら利害関係者の承認を必要とする１つ以上の利害関係者の識別、例えば、これらの利害関係者の公開鍵と、直接的または間接的に、関係している。また、利害関係者は、前提条件グループの実体に１つ以上の目標グループのメンバとして追加されることを許可するため、暗号化証明書に署名することができる。さらに、暗号化証明書を処理する方法としては、実体の前提条件グループの少なくとも１つのメンバシップを含む前提条件の少なくとも１つを記述する暗号化証明書を受け取り、その暗号化証明書が、決定をするためにその前提条件グループのメンバシップを使うことにその承認が必要とされる前提条件グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断する。
【００６９】
１つの実施の形態では、分離カーネルの各リソースは、それらのリソースへのアクセスを承認しなければならない１つ以上のリソース利害関係者により、さらにコントロールされることができる。承認には、その１つ以上のリソース利害関係者が、対応する暗号化認可証（cryptographic authorization permit、CAP）に署名する。このＣＡＰについては、2007年4月9日付けの米国特許出願11/783,359号「SYSTEM AND METHOD FOR ACCESSING INFORMATION RESOURCES USING CRYPTOGRAPHIC AUTHORIZATION PERMITS」に公開されており、参照によって本願に援用される。１つの実施の形態においては、それぞれの公開鍵を使って、ＣＡＰは１つ以上のリソース利害関係者によって署名され、グループメンバシップ証明書（GMC）は１つ以上のトゥ・ザ・グループおよびフロム・ザ・グループ利害関係者によって署名される。１つ以上のリソース利害関係者の承認のみでは、参加者のリソースへのアクセスには十分ではない。よって、１つ以上のフロム・ザ・グループ利害関係者が、前提条件グループのメンバのリソースへのアクセスを別個に承認する。このようにして、前提条件グループのメンバシップの条件に基づいて、権利またはリソースへのアクセスを提供するためにＧＭＣとＣＡＰの概念を組み合わせてもよい。実際に、ＣＡＰとＧＭＣは、同一のまたは異なる証明書で実施することができる。
【００７０】
１つの実施の形態の例では、分割通信システム（PCS）は、チャンネル接続性ポリシおよびリソース管理ポリシの２つのセキュリティ・ポリシに従って、チャンネルを介する相互作用の仲介をする。チャンネル接続性ポリシは、許可できる接続を定義する。このポリシは、基本的に、すべてのアクセス権を定義するアクセス権コントロールポリシである。リソース管理ポリシは、チャンネルの実現に使われる共有通信リソースが、チャンネル間にどのように割り当てられるか、およびそのチャンネルが共有リソースの使用を介して互いに影響（協調的にまたは不慮に）する範囲を記述する。
【００７１】
チャンネルは、発信元パーティションから、任意の物理的または論理的な構成要素を含む同一または異なるノードに存在する１つ以上の送信先パーティションへの入力情報または出力情報の１方向の流れのための接続からなる。リードアクセス権は、許可されたパーティションに、チャンネルからメッセージのリード（読み込み）ができるようにし、ライトアクセス権は、許可されたパーティションに、チャンネルにメッセージのライト（書き込み）ができるようにする。チャンネルは、ノード間の、ポイント・ツー・ポイント、ポイント・ツー・マルチポイント、またはマルチポイント・ツー・マルチポイントの通信を実現するために使われる。各チャンネルは、通信されるメッセージに関係する対称暗号化／復号化鍵を有する。対称鍵は、チャンネルアクセス権が許可された後のチャンネルを介するメッセージの通信に使われる当事者間の共有秘密鍵である。共有秘密鍵は、セキュリティ・パラメータでの定義に従って定期的に変更されるものである。
【００７２】
ネットワークの個別のノードにおけるパーティション間のすべての通信は、チャンネルを介するメッセージの通信、即ちリードまたはライト、によって達成される。グループメンバシップ証明書（GMC）を使って、１つ以上のパーティションを、チャンネルの１つまたはそのグループへのライトアクセス権、リードアクセス権、またはその両者が付与された参加者として、グループ化することができる。また、ライトアクセス権、リードアクセス権、またはその両者を、個別の参加者もしくはチャンネル、または参加者もしくはチャンネルのグループに適用されるように、ＧＭＣを使ってグループ化することができる。
【００７３】
あるいは、１つ以上のリソース利害関係者によって署名されて発行された暗号化認可証（CAP）は、パーティションのリード、ライト、またはリードおよびライトのアクセス権をチャンネルに付与し、１つ以上のトゥ・ザ・グループおよびフロム・ザ・グループ利害関係者によって署名されて発行されたグループメンバシップ証明書（GMC）は、その参加者が指定された前提条件グループのメンバシップ条件を満足するのであれば、リソースまたはそのグループにアクセスする参加者をグループ化する。それぞれのチャンネルは、そのチャンネルからのメッセージの読み込みまたはそのチャンネルにメッセージを書き込みするのに必要なアクセス権を付与する責任のある１つ以上の関係するリソース利害関係者を有する。各チャンネルの識別には、そのチャンネルのリードおよびライトの権利をコントロールするリソース利害関係者の公開鍵、およびリソース利害関係者のコントロールによる固有なチャンネルインデックスが含まれる。同一のインデックスが付けられているが異なるリソース利害関係者のコントロールによる識別を有するチャンネルは、異なるチャンネルとみなされる。
【００７４】
図５に示すシステムの実施の形態の例では、コントロールパーティションとアプリケーションパーティション（ユーザパーティションとも呼ばれる）との２つのタイプのパーティションが使われている。すべてのパーティション間のノード内での相互作用は、分離カーネルと連携して、そのノードのコントロールパーティションによりコントロールされる。コントロールパーティションは、分離カーネル、そのノード内の他のパーティション、および他のノードのコントロールパーティションとのみやり取りをする。特定の実装ではパーティションの機能が多数のパーティションを使って実装されているものもあるが、各ノードは、コントロールパーティションの少なくとも１つを有する。コントロールパーティションは、そのノードの秘密鍵ならびに公開鍵、他のノードの公開鍵、およびシステムセキュリティを実装する暗号化認可証（CAP）ならびにグループメンバシップ証明書（GMC）を含むセキュリティデータ値を安全に格納（秘密の偽造できない方法で）する。アプリケーションパーティションは、対応する構成データおよびＣＡＰおよびＧＭＣの認可許可パラメータに従い、ローカルな分離カーネルに許可された手段を介して、コントロールパーティションを含む同一ノードの他のパーティションとやり取りする。コントロールパーティションは、それぞれの利害関係者によって署名されたＣＡＰまたはＧＭＣを受けたとき、分離カーネルのセキュリティ・ポリシのセキュリティ・パラメータが変更される機構を提供する。
【００７５】
メッセージをやり取りする前に、分割通信システム（PCS）は、通信に参加するノードが、その通信を許可する一貫性のある構成データを有することを確保する。ＰＣＳは、アクセスハードウェア／ソフトウェア、暗号化ハードウェア／ソフトウェアなどのそれぞれの共有リソースに対し、初期化し、そしてそれらのリソースを試験する。それぞれのチャンネルについては、送信チャンネル・エンドポイント（channel endpoint、CE）のパーティションが、それぞれの受信チャンネル・エンドポイントと相互認証を行い、共有秘密鍵を確立する。暗号化されている相互認証は、そのチャンネルへのアクセス権の許可に関係している。この認証は、通信対象の識別とともにそのアクセス権の検証からなる。対象の識別の検証は、ＥＣＭＱＶプロトコルを実行して、含まれるノードおよび／またはパーティションの識別を認証することによって行われてもよい。このプロトコルが成功裡に実行されると、認証を行ったチャンネル・エンドポイントのみが知る共有秘密鍵をもたらすことになる。チャンネルを介する通信の権利の検証は、対象にチャンネルへのアクセスを許可する暗号化認可証（CAP）およびグループメンバシップ証明書（GMC）に含まれる署名の検証を必要とする。それらの署名が、そのチャンネルの識別においてチャンネルの保護に責任があると特定される利害関係者と対応することを確保するために、さらなる検証が行われなければならない。最後に、チャンネル・エンドポイントがＣＡＰおよびＧＭＣで指定されている対象と前のステップでその識別が検証されている対象とを合致させる。すべてのチャンネル・エンドポイントで上述のステップが成功裡に行われれば、共有秘密鍵がチャンネルを介してやり取りされるメッセージの暗号化および復号化に使用されることになる。
【００７６】
共有リソースおよびチャンネルの初期化が完了すると、分割通信システム（PCS）は、チャンネルがメッセージのやり取りができる状態であることが通知される。チャンネルへのアクセスは、公表されたセキュリティ・ポリシに従って暗号化認可証（CAP）またはグループメンバシップ証明書（GMC）の発行に責任のある１つ以上の利害関係者の個別の許可を必要とする。ＣＡＰおよび／またはＧＭＣを介するチャンネルへのアクセスは、多数の権限者による個別の認可を必要としてもよい。上述のように、本発明は、セキュリティ・パラメータを実施する権限者によって署名されたポリシを使用する。１つの実施の形態の例では、署名されたポリシは、ＣＡＰならびにＧＭＣのリストおよび対応する利害関係者の公開鍵のリストを含んでいる。ポリシは、チャンネルの保護に責任のある１つ以上の利害関係者、およびグループメンバシップのコントロールに責任のある１つ以上の利害関係者によって署名されている。ＧＭＣとＣＡＰとの組み合わせは、あらゆる情報システムにおける拡張性の高いセキュリティ・ポリシの実装をもたらす。ＧＭＣは、参加者を、ＣＡＰが参加者の識別の代わりに前提条件として使用できる同等のクラスにグループ化することができ、これにより、繰り返しが回避される。さらには、ＧＭＣを介する推移的結合は、グループを他のグループとの結合的および分離的な組み合わせに関して定義できることにより、さらなる拡張性をもたらす。これは、役割（または属性）を参加者に直接結び付ける他のスキームとは対照的である。
【００７７】
上述により、実体のグループ化の認可は、１つ以上の利害関係者によって発行された公開鍵に基づき、それぞれのグループメンバシップ証明書（GMC）は、その利害関係者によってデジタル的に署名された暗号化証明書からなり、実体のグループ化は、そのような実体のグループ化を許可する前提条件をコントロールする１つ以上の利害関係者の暗号化署名を必要とすることが理解されよう。
【００７８】
本発明は、システムのノード数に事前の制限を設けずに、セキュリティ・ポリシを実施する。また、本発明は、認識されるセキュリティドメインの数、またはそのドメインで実施される情報フロー・ポリシについていかなる制限をも必要としない。これにより、システムのセキュリティ・ポリシは、展開されているソフトウェアを変更することなく、必要に応じて動的に変更することができる。さらに、本発明で作成されたシステムは、検証を行うのに第三者機関（権限者または利害関係者を含む）へのアクセスに依存しない。検証は、グループメンバシップ証明書（GMC）および利害関係者の公開鍵を処理する任意の実体によって行うことができる。そのようなシステムは、任意のノードが欠如または故障したときでも、パフォーマンスまたはセキュリティを、ほとんど、またはまったく劣化させずに機能を継続する。本発明は、軍事用途、機密レベル情報、業務担当者のみが知るべき制限された事項、銀行業務、および個別の口座に個別のパーティションを使う清算センタに使用することができる。
【特許請求の範囲】
【請求項１】
暗号化証明書を発行する方法であって、
前提条件の少なくとも１つを該暗号化証明書に記述するステップであって、該前提条件の少なくとも１つが、実体の前提条件グループの少なくとも１つのメンバシップを含むステップと、
決定を行うために該前提条件グループのメンバシップを使うことにその承認を必要とする前提条件グループ利害関係者の少なくとも１つが該暗号化証明書に署名するステップと、を含む方法。
【請求項２】
請求項１に記載の方法であって、前記決定が、別グループのメンバシップへの実体の加入、リソースへのアクセスの付与、権利の付与、または動作を行うこと、の少なくとも１つに関連する方法。
【請求項３】
請求項１に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前記前提条件グループ利害関係者の識別に関係する方法。
【請求項４】
請求項３に記載の方法であって、前記前提条件グループ利害関係者の少なくとも１つの前記識別が、その利害関係者の公開鍵を含む方法。
【請求項５】
請求項１に記載の方法であって、前記暗号化証明書が、権利またはリソースへのアクセスをコントロールする１つ以上のリソース利害関係者によって、さらに署名される方法。
【請求項６】
請求項１に記載の方法であって、１つ以上の前記前提条件グループ利害関係者が、前提条件グループの実体に目標グループの少なくとも１つの実体となることを許可し、前記暗号化証明書が、該目標グループの少なくとも１つにメンバとして加えられることを実体に許可する目標グループ利害関係者の少なくとも１つによってさらに署名される方法。
【請求項７】
請求項１に記載の方法であって、前記前提条件の少なくとも１つが、別の実体のグループのメンバシップ、物理的特性、非物理的特性、時間特性、非時間特性、場所特性、位置特性、の少なくとも１つと関連する方法。
【請求項８】
請求項１に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前提条件グループの実体に別の実体のグループのメンバとなることを許可する前記前提条件グループ利害関係者の少なくとも１つの名称、および前記前提条件グループの少なくとも１つでの実体のメンバシップを許可する前提条件グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項９】
請求項８に記載の方法であって、前記前提条件グループの少なくとも１つの前記名称が、さらに、前提条件グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項１０】
請求項８に記載の方法であって、前提条件グループ利害関係者の名称が、該前提条件グループ利害関係者の公開鍵を含み、該前提条件グループ利害関係者の署名が、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む方法。
【請求項１１】
請求項６に記載の方法であって、目標グループの名称が、該目標グループの実体メンバの別のグループへのメンバシップを許可する目標グループ利害関係者の少なくとも１つの名称、および実体に該目標グループのメンバとなることを許可する目標グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項１２】
請求項１１に記載の方法であって、前記目標グループの名称が、さらに、目標グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項１３】
請求項１１に記載の方法であって、前記目標グループ利害関係者の名称が、前記目標グループ利害関係者の公開鍵を含み、前記目標グループ利害関係者の署名が、前記目標グループ利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む方法。
【請求項１４】
請求項１に記載の方法であって、実体が、参加者、リソース、または権利の少なくとも１つを含む方法。
【請求項１５】
暗号化証明書の処理方法であって、
該暗号化証明書を受け取るステップであって、該暗号化証明書が、実体の前提条件グループの少なくとも１つのメンバシップを含む前提条件の少なくとも１つを記述するステップと、
該暗号化証明書が、決定を行うために該前提条件グループのメンバシップを使うことにその承認を必要とする前提条件グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断するステップと、を含む方法。
【請求項１６】
請求項１５に記載の方法であって、前記決定が、別グループのメンバシップへの実体の加入、リソースへのアクセスの付与、権利の付与、または動作を行うこと、の少なくとも１つに関連する方法。
【請求項１７】
請求項１５に記載の方法であって、１つ以上の前記前提条件グループ利害関係者が、前提条件グループの実体に目標グループの少なくとも１つの実体となることを許可し、さらに、前記暗号化証明書が、該目標グループの少なくとも１つにメンバとして加えられることを実体に許可する目標グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断するステップを含む方法。
【請求項１８】
請求項１５に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前記前提条件グループ利害関係者の少なくとも１つの識別に関係する方法。
【請求項１９】
請求項１８に記載の方法であって、前記前提条件グループ利害関係者の少なくとも１つの前記識別が、その利害関係者の公開鍵を含む方法。
【請求項２０】
請求項１５に記載の方法であって、さらに、前記暗号化証明書が、権利またはリソースへのアクセスをコントロールするリソース利害関係者の少なくとも１つによって有効に署名されているか否かを判断するステップを含む方法。
【請求項２１】
請求項１５に記載の方法であって、前記前提条件が、別の実体のグループのメンバシップ、物理的特性、非物理的特性、時間特性、非時間特性、場所特性、位置特性、の少なくとも１つと関連する方法。
【請求項２２】
請求項１５に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前提条件グループの実体に別の実体のグループのメンバとなることを許可する前提条件グループ利害関係者の少なくとも１つの名称、および前記前提条件グループの少なくとも１つでの実体のメンバシップを許可する前提条件グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項２３】
請求項２２に記載の方法であって、前記前提条件グループの少なくとも１つの前記名称が、さらに、前記前提条件グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項２４】
請求項２２に記載の方法であって、前提条件グループ利害関係者の前記名称が、該前提条件グループ利害関係者の公開鍵を含み、該前提条件グループ利害関係者の署名が、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む方法。
【請求項２５】
請求項１７に記載の方法であって、目標グループの少なくとも１つの名称が、該目標グループの少なくとも１つの実体メンバの別のグループへのメンバシップを許可する目標グループ利害関係者の少なくとも１つの名称、および該目標グループの少なくとも１つのメンバとなることを実体に許可する目標グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項２６】
請求項２５に記載の方法であって、前記目標グループの少なくとも１つの名称が、さらに、目標グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項２７】
請求項２５に記載の方法であって、目標グループ利害関係者の名称が、該目標グループ利害関係者の公開鍵を含み、該目標グループ利害関係者の署名が、該目標グループ利害関係者の秘密鍵を使って作られた証明書の暗号化署名を含む方法。
【請求項２８】
請求項１５に記載の方法であって、実体が、参加者、リソース、または権利の少なくとも１つを含む方法。
【請求項２９】
暗号化証明書であって、
１つ以上の前提条件グループの名称と、
決定を行うために該前提条件グループのメンバシップを使うことにその承認を必要とする１つ以上の前提条件グループ利害関係者の暗号化署名と、を含む暗号化証明書。
【請求項３０】
請求項２９に記載の暗号化証明書であって、１つ以上の前記前提条件グループ利害関係者が、前提条件グループの実体に１つ以上の目標グループの実体となることを許可する暗号化証明書。
【請求項３１】
請求項２９に記載の暗号化証明書であって、さらに、１つ以上の目標グループの名称、および実体を目標グループに加えることを許可する１つ以上の目標グループ利害関係者の暗号化署名を含む暗号化証明書。
【請求項３２】
請求項２９に記載の暗号化証明書であって、前記決定が、別グループのメンバシップへの実体の加入、リソースへのアクセスの付与、権利の付与、または動作を行うこと、の少なくとも１つに関連する暗号化証明書。
【請求項３３】
請求項２９に記載の暗号化証明書であって、前記前提条件グループの名称が、１つ以上の前記前提条件グループ利害関係者の識別に関係する暗号化証明書。
【請求項３４】
請求項３３に記載の暗号化証明書であって、前提条件グループ利害関係者の前記識別が、その利害関係者の公開鍵を含む暗号化証明書。
【請求項３５】
請求項２９に記載の暗号化証明書であって、さらに、権利またはリソースへのアクセスをコントロールする１つ以上のリソース利害関係者の暗号化署名を含む暗号化証明書。
【請求項３６】
請求項２９に記載の暗号化証明書であって、前記前提条件が、別の実体のグループのメンバシップ、物理的特性、非物理的特性、時間特性、非時間特性、場所特性、位置特性、の少なくとも１つと関連する暗号化証明書。
【請求項３７】
請求項２９に記載の暗号化証明書であって、前提条件グループの前記名称が、前提条件グループの実体に実体の目標グループの少なくとも１つのメンバとなることを許可する１つ以上の前提条件グループ利害関係者の名称、および該前提条件グループの少なくとも１つでの実体のメンバシップを許可する１つ以上の前提条件グループ利害関係者の名称を含む暗号化証明書。
【請求項３８】
請求項３７に記載の暗号化証明書であって、前記前提条件グループの前記名称が、さらに、前記前提条件グループの曖昧さの無い識別子の少なくとも１つを含む暗号化証明書。
【請求項３９】
請求項３７に記載の暗号化証明書であって、前提条件グループ利害関係者の前記名称が、該前提条件グループ利害関係者の公開鍵を含み、該前提条件グループ利害関係者の署名が、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む暗号化証明書。
【請求項４０】
請求項３０に記載の暗号化証明書であって、さらに、目標グループの名称を含む暗号化証明書。
【請求項４１】
請求項４０に記載の暗号化証明書であって、前記目標グループの前記名称が、該目標グループの実体メンバの別のグループへのメンバシップを許可する１つ以上の目標グループ利害関係者の名称、および該目標グループのメンバとなることを実体に許可する１つ以上の目標グループ利害関係者の名称を含む暗号化証明書。
【請求項４２】
請求項４１に記載の暗号化証明書であって、前記目標グループの前記名称が、さらに、目標グループの曖昧さの無い識別子の少なくとも１つを含む暗号化証明書。
【請求項４３】
請求項４１に記載の暗号化証明書であって、目標グループ利害関係者の前記名称が、該目標グループ利害関係者の公開鍵を含み、該目標グループ利害関係者の署名が、該目標グループ利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む暗号化証明書。
【請求項４４】
請求項２９に記載の暗号化証明書であって、実体が、参加者、リソース、または権利の少なくとも１つを含む暗号化証明書。
【請求項４５】
暗号化証明書を処理するシステムであって、
複数の実体と、
１つ以上のグループメンバシップ証明書であって、それぞれが１つ以上の前提条件グループの名称と１つ以上の目標グループの名称とを含むグループメンバシップ証明書と、
１つ以上の前提条件グループ利害関係者および目標グループ利害関係者として機能する１つ以上の利害関係者であって、グループメンバシップ証明書が前提条件グループの実体名が別のグループの実体名となることを許可する１つ以上の前提条件グループ利害関係者によって暗号化署名されていれば有効であり、さらに、該グループメンバシップ証明書が１つ以上の目標グループに実体名を加えることを許可する１つ以上の目標グループ利害関係者に暗号化署名される利害関係者と、
実体から暗号化証明書を受け取るノードであって、該ノードが有効なグループメンバシップ証明書を検査し、受け取った該暗号化証明書が対応する実体を該有効なグループメンバシップ証明書に含まれる前提条件グループに有効に結び付けるならば、該対応する実体名を該有効なグループメンバシップ証明書で指定される目標グループに加えるノードと、を備えるシステム。
【請求項１】
暗号化証明書を発行する方法であって、
前提条件の少なくとも１つを該暗号化証明書に記述するステップであって、該前提条件の少なくとも１つが、実体の前提条件グループの少なくとも１つのメンバシップを含むステップと、
決定を行うために該前提条件グループのメンバシップを使うことにその承認を必要とする前提条件グループ利害関係者の少なくとも１つが該暗号化証明書に署名するステップと、を含む方法。
【請求項２】
請求項１に記載の方法であって、前記決定が、別グループのメンバシップへの実体の加入、リソースへのアクセスの付与、権利の付与、または動作を行うこと、の少なくとも１つに関連する方法。
【請求項３】
請求項１に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前記前提条件グループ利害関係者の識別に関係する方法。
【請求項４】
請求項３に記載の方法であって、前記前提条件グループ利害関係者の少なくとも１つの前記識別が、その利害関係者の公開鍵を含む方法。
【請求項５】
請求項１に記載の方法であって、前記暗号化証明書が、権利またはリソースへのアクセスをコントロールする１つ以上のリソース利害関係者によって、さらに署名される方法。
【請求項６】
請求項１に記載の方法であって、１つ以上の前記前提条件グループ利害関係者が、前提条件グループの実体に目標グループの少なくとも１つの実体となることを許可し、前記暗号化証明書が、該目標グループの少なくとも１つにメンバとして加えられることを実体に許可する目標グループ利害関係者の少なくとも１つによってさらに署名される方法。
【請求項７】
請求項１に記載の方法であって、前記前提条件の少なくとも１つが、別の実体のグループのメンバシップ、物理的特性、非物理的特性、時間特性、非時間特性、場所特性、位置特性、の少なくとも１つと関連する方法。
【請求項８】
請求項１に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前提条件グループの実体に別の実体のグループのメンバとなることを許可する前記前提条件グループ利害関係者の少なくとも１つの名称、および前記前提条件グループの少なくとも１つでの実体のメンバシップを許可する前提条件グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項９】
請求項８に記載の方法であって、前記前提条件グループの少なくとも１つの前記名称が、さらに、前提条件グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項１０】
請求項８に記載の方法であって、前提条件グループ利害関係者の名称が、該前提条件グループ利害関係者の公開鍵を含み、該前提条件グループ利害関係者の署名が、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む方法。
【請求項１１】
請求項６に記載の方法であって、目標グループの名称が、該目標グループの実体メンバの別のグループへのメンバシップを許可する目標グループ利害関係者の少なくとも１つの名称、および実体に該目標グループのメンバとなることを許可する目標グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項１２】
請求項１１に記載の方法であって、前記目標グループの名称が、さらに、目標グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項１３】
請求項１１に記載の方法であって、前記目標グループ利害関係者の名称が、前記目標グループ利害関係者の公開鍵を含み、前記目標グループ利害関係者の署名が、前記目標グループ利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む方法。
【請求項１４】
請求項１に記載の方法であって、実体が、参加者、リソース、または権利の少なくとも１つを含む方法。
【請求項１５】
暗号化証明書の処理方法であって、
該暗号化証明書を受け取るステップであって、該暗号化証明書が、実体の前提条件グループの少なくとも１つのメンバシップを含む前提条件の少なくとも１つを記述するステップと、
該暗号化証明書が、決定を行うために該前提条件グループのメンバシップを使うことにその承認を必要とする前提条件グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断するステップと、を含む方法。
【請求項１６】
請求項１５に記載の方法であって、前記決定が、別グループのメンバシップへの実体の加入、リソースへのアクセスの付与、権利の付与、または動作を行うこと、の少なくとも１つに関連する方法。
【請求項１７】
請求項１５に記載の方法であって、１つ以上の前記前提条件グループ利害関係者が、前提条件グループの実体に目標グループの少なくとも１つの実体となることを許可し、さらに、前記暗号化証明書が、該目標グループの少なくとも１つにメンバとして加えられることを実体に許可する目標グループ利害関係者の少なくとも１つによって有効に署名されているか否かを判断するステップを含む方法。
【請求項１８】
請求項１５に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前記前提条件グループ利害関係者の少なくとも１つの識別に関係する方法。
【請求項１９】
請求項１８に記載の方法であって、前記前提条件グループ利害関係者の少なくとも１つの前記識別が、その利害関係者の公開鍵を含む方法。
【請求項２０】
請求項１５に記載の方法であって、さらに、前記暗号化証明書が、権利またはリソースへのアクセスをコントロールするリソース利害関係者の少なくとも１つによって有効に署名されているか否かを判断するステップを含む方法。
【請求項２１】
請求項１５に記載の方法であって、前記前提条件が、別の実体のグループのメンバシップ、物理的特性、非物理的特性、時間特性、非時間特性、場所特性、位置特性、の少なくとも１つと関連する方法。
【請求項２２】
請求項１５に記載の方法であって、前記前提条件グループの少なくとも１つの名称が、前提条件グループの実体に別の実体のグループのメンバとなることを許可する前提条件グループ利害関係者の少なくとも１つの名称、および前記前提条件グループの少なくとも１つでの実体のメンバシップを許可する前提条件グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項２３】
請求項２２に記載の方法であって、前記前提条件グループの少なくとも１つの前記名称が、さらに、前記前提条件グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項２４】
請求項２２に記載の方法であって、前提条件グループ利害関係者の前記名称が、該前提条件グループ利害関係者の公開鍵を含み、該前提条件グループ利害関係者の署名が、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む方法。
【請求項２５】
請求項１７に記載の方法であって、目標グループの少なくとも１つの名称が、該目標グループの少なくとも１つの実体メンバの別のグループへのメンバシップを許可する目標グループ利害関係者の少なくとも１つの名称、および該目標グループの少なくとも１つのメンバとなることを実体に許可する目標グループ利害関係者の少なくとも１つの名称を含む方法。
【請求項２６】
請求項２５に記載の方法であって、前記目標グループの少なくとも１つの名称が、さらに、目標グループの曖昧さの無い識別子の少なくとも１つを含む方法。
【請求項２７】
請求項２５に記載の方法であって、目標グループ利害関係者の名称が、該目標グループ利害関係者の公開鍵を含み、該目標グループ利害関係者の署名が、該目標グループ利害関係者の秘密鍵を使って作られた証明書の暗号化署名を含む方法。
【請求項２８】
請求項１５に記載の方法であって、実体が、参加者、リソース、または権利の少なくとも１つを含む方法。
【請求項２９】
暗号化証明書であって、
１つ以上の前提条件グループの名称と、
決定を行うために該前提条件グループのメンバシップを使うことにその承認を必要とする１つ以上の前提条件グループ利害関係者の暗号化署名と、を含む暗号化証明書。
【請求項３０】
請求項２９に記載の暗号化証明書であって、１つ以上の前記前提条件グループ利害関係者が、前提条件グループの実体に１つ以上の目標グループの実体となることを許可する暗号化証明書。
【請求項３１】
請求項２９に記載の暗号化証明書であって、さらに、１つ以上の目標グループの名称、および実体を目標グループに加えることを許可する１つ以上の目標グループ利害関係者の暗号化署名を含む暗号化証明書。
【請求項３２】
請求項２９に記載の暗号化証明書であって、前記決定が、別グループのメンバシップへの実体の加入、リソースへのアクセスの付与、権利の付与、または動作を行うこと、の少なくとも１つに関連する暗号化証明書。
【請求項３３】
請求項２９に記載の暗号化証明書であって、前記前提条件グループの名称が、１つ以上の前記前提条件グループ利害関係者の識別に関係する暗号化証明書。
【請求項３４】
請求項３３に記載の暗号化証明書であって、前提条件グループ利害関係者の前記識別が、その利害関係者の公開鍵を含む暗号化証明書。
【請求項３５】
請求項２９に記載の暗号化証明書であって、さらに、権利またはリソースへのアクセスをコントロールする１つ以上のリソース利害関係者の暗号化署名を含む暗号化証明書。
【請求項３６】
請求項２９に記載の暗号化証明書であって、前記前提条件が、別の実体のグループのメンバシップ、物理的特性、非物理的特性、時間特性、非時間特性、場所特性、位置特性、の少なくとも１つと関連する暗号化証明書。
【請求項３７】
請求項２９に記載の暗号化証明書であって、前提条件グループの前記名称が、前提条件グループの実体に実体の目標グループの少なくとも１つのメンバとなることを許可する１つ以上の前提条件グループ利害関係者の名称、および該前提条件グループの少なくとも１つでの実体のメンバシップを許可する１つ以上の前提条件グループ利害関係者の名称を含む暗号化証明書。
【請求項３８】
請求項３７に記載の暗号化証明書であって、前記前提条件グループの前記名称が、さらに、前記前提条件グループの曖昧さの無い識別子の少なくとも１つを含む暗号化証明書。
【請求項３９】
請求項３７に記載の暗号化証明書であって、前提条件グループ利害関係者の前記名称が、該前提条件グループ利害関係者の公開鍵を含み、該前提条件グループ利害関係者の署名が、その利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む暗号化証明書。
【請求項４０】
請求項３０に記載の暗号化証明書であって、さらに、目標グループの名称を含む暗号化証明書。
【請求項４１】
請求項４０に記載の暗号化証明書であって、前記目標グループの前記名称が、該目標グループの実体メンバの別のグループへのメンバシップを許可する１つ以上の目標グループ利害関係者の名称、および該目標グループのメンバとなることを実体に許可する１つ以上の目標グループ利害関係者の名称を含む暗号化証明書。
【請求項４２】
請求項４１に記載の暗号化証明書であって、前記目標グループの前記名称が、さらに、目標グループの曖昧さの無い識別子の少なくとも１つを含む暗号化証明書。
【請求項４３】
請求項４１に記載の暗号化証明書であって、目標グループ利害関係者の前記名称が、該目標グループ利害関係者の公開鍵を含み、該目標グループ利害関係者の署名が、該目標グループ利害関係者の秘密鍵を使って作られた暗号化証明書の暗号化署名を含む暗号化証明書。
【請求項４４】
請求項２９に記載の暗号化証明書であって、実体が、参加者、リソース、または権利の少なくとも１つを含む暗号化証明書。
【請求項４５】
暗号化証明書を処理するシステムであって、
複数の実体と、
１つ以上のグループメンバシップ証明書であって、それぞれが１つ以上の前提条件グループの名称と１つ以上の目標グループの名称とを含むグループメンバシップ証明書と、
１つ以上の前提条件グループ利害関係者および目標グループ利害関係者として機能する１つ以上の利害関係者であって、グループメンバシップ証明書が前提条件グループの実体名が別のグループの実体名となることを許可する１つ以上の前提条件グループ利害関係者によって暗号化署名されていれば有効であり、さらに、該グループメンバシップ証明書が１つ以上の目標グループに実体名を加えることを許可する１つ以上の目標グループ利害関係者に暗号化署名される利害関係者と、
実体から暗号化証明書を受け取るノードであって、該ノードが有効なグループメンバシップ証明書を検査し、受け取った該暗号化証明書が対応する実体を該有効なグループメンバシップ証明書に含まれる前提条件グループに有効に結び付けるならば、該対応する実体名を該有効なグループメンバシップ証明書で指定される目標グループに加えるノードと、を備えるシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１１−５２４６６１（Ｐ２０１１−５２４６６１Ａ）
【公表日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１１−５０９４４９（Ｐ２０１１−５０９４４９）
【出願日】平成２０年５月１６日（２００８．５．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００６３４６
【国際公開番号】ＷＯ２００９／１３９７５０
【国際公開日】平成２１年１１月１９日（２００９．１１．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．Ｌｉｎｕｘ
【出願人】（５１０３０３５３４）オブジェクティブ インターフェイス システムズ，インク． (1)
【Ｆターム（参考）】
【公表日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２０年５月１６日（２００８．５．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００６３４６
【国際公開番号】ＷＯ２００９／１３９７５０
【国際公開日】平成２１年１１月１９日（２００９．１１．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．Ｌｉｎｕｘ
【出願人】（５１０３０３５３４）オブジェクティブ インターフェイス システムズ，インク． (1)
【Ｆターム（参考）】
[ Back to top ]