JP6175600B2 - セキュリティドメインの制御方法 - Google Patents

Description

本発明は、信頼できない環境（untrusted environment）内においてセキュリティドメインを制御するためのシステム及び方法に関する。

本明細書において“信頼できない環境（untrusted environment）”とは、攻撃を意図する者によってメッセージの変更、削除、追加、又は再生が行われてしまう可能性のある何らかの通信環境又はネットワーキング環境を意味する。公衆インターネットは、信頼できない環境の一般的な例である。攻撃者に対してメッセージの変更、削除、追加、又は再生を禁止することができないためである。ケーブルテレビや衛星テレビの配信ネットワークも、信頼できない環境となり得る。セットトップ受信機／デコーダは、ひとたびエンドユーザに渡ってしまえば、「ハッキング」されて番組内容に対する権限のないアクセスが可能となり得るためである。

信頼できない環境で安全な通信を可能とするため、通常は、上述のような要因によりメッセージが無効となったことを検知するための暗号アルゴリズムや暗号メカニズムが用いられる。このような暗号手法では、通信相手が適切な暗号鍵を持っていることを必要とする。一般に、サービスプロバイダやオペレータは、セキュリティドメインを設定し、当該セキュリティドメイン内において、認定されたパーティに一組の暗号鍵を配信する。これらの暗号鍵により、認定されたパーティ間で安全な通信を容易に行うことができる。例えば、ケーブルテレビ及び衛星テレビの配信システムでは、オペレータが非公開の秘密鍵（private key）を用いて番組内容を暗号化するのが一般的である。認定された加入者には、これに対応する公開鍵（public key）が、セキュリティトークンとして配布される。この公開鍵により、ユーザは、番組内容を解読して視聴することができる。秘密鍵／公開鍵は、一般に、公衆インターネットにおいてセキュリティドメイン（例えば、仮想プライベートネットワーク（VPN、virtual private network））を設定する際にも用いられる。

上述したタイプの暗号化セキュリティシステムでは、周知のように、当該システムの安全性をハッカー達の技術進歩から守るべく、上述の鍵を（多くの場合、アルゴリズムも含めて）適宜更新する必要がある。一般に、セキュリティシステムのオペレータは、定期的に鍵を変更し、おそらくはそのサイズが大きくなるような変更を行う。セキュリティシステムによっては、アルゴリズムをも変更することが望ましい場合がある。このような変更は、例えば、ハッカーの主たる攻撃目標である衛星テレビの限定受信システム（conditional access system）においては一般的な課題である。

オペレータにおける問題は、（暗号鍵やアルゴリズムなどの）暗号構成要素の定期的な変更に伴う負荷やリスクが許容範囲を越えてしまうのではないかということ、及び、鍵交換の間隔が、望ましい間隔より長くなってしまうのではないかということである。このような鍵管理システムの複雑さは周知のとおりである。

（VPNや衛星テレビ配信ネットワークなどの）ある種のシステムでは、ユーザは適宜、安全な（信用のある）リソースへの接続を行わなければならないので、ある程度、鍵の更新タスクは簡略化される。例えばVPNでは、リモードユーザは、ＶＰＮのサービスへのアクセスに際して、安全なサーバへのログオンが要求される。また、ケーブルテレビ及び衛星テレビの配信ネットワークでは、番組内容の受信に際し、ユーザのセットトップ受信機／デコーダを安全な番組サーバに接続することが要求される。いずれの場合も、安全なリソースへの接続によりユーザのリモートデバイスに保存されたセキュリティトークンの世代が特定され、必要に応じて配布されたトークンが更新される。

しかしながら、ある種のシステムでは、ユーザが安全なリソースにログインすることはほとんどなく、又は全くない場合もある。このような状況は、一部の電子商取引システム、たとえば、ユーザが他のユーザとの間では交流するが当該システムのセンターサーバにはほとんど（又は全く）ログインしないようなシステムにおいて発生する。このような場合、ユーザのデバイスに保存されている鍵についての日付及び時刻の情報は信用することができず、したがってこれらの情報を用いて鍵の世代や更新の必要性を判断することはできない。また、ユーザの鍵を更新するための信頼性のあるメカニズムも設けられていない。

本発明は、セキュリティシステムのオペレータがセキュリティトークンの暗号パラメータを変更するための実用的な方法を提供する。本方法では、現在使用しているトークンについての日付や時刻の情報を参照することなく、単に新しい鍵を発行して流通させることで、古い鍵を無効にすることができる。システムのオペレータは、これらのパラメータの変更時期を任意に選択することができ、例えば現在の脅威や確認されている脆弱性に応じて選択することができる。

したがって、本発明の一の態様は、セキュリティドメインの制御方法を提供する。この方法は、順序付けられた一連のセキュリティドメインの系列を定義するステップと、一の前記セキュリティドメインをカレントドメインとして選定するステップと、カレントセキュリティドメインの下で複数のセキュリティトークンを生成するステップと、を有する。各トークンは、一のパーティと他のパーティとの間で、暗号化により安全が保証されたメッセージを交換するよう構成されている。ここで、他のパーティは、前記カレントセキュリティドメインの下で定義されたトークン、前記系列においてその次に位置する少なくとも一つのセキュリティドメインで生成されたトークン、及び前記系列においてその前に位置する少なくとも一つのセキュリティドメインで生成されたトークン、のうちのいずれか一のトークンを保持するものとする。さらに、本制御方法は、引き続いて前記系列において次に位置する一のセキュリティドメインをカレントセキュリティドメインとして選定するステップを有する。

本発明の更なる特徴及び利点は、添付図面と以下に示す詳細な説明から明らかとなる。

本発明の代表的な実施形態に係るセュリティシステムの構成方法を示すブロック図である。 図１に示すシステムにおける、メッセージ交換処理の一例を示すブロック図である。 図１に示すシステムにおける、メッセージ交換処理の一例を示すメッセージフロー図である。 本発明の第２の実施形態に係るシステムにおける、メッセージ交換処理の一例を示すブロック図である。

添付図面においては、同様の構成要素については同様の符号を付して示すものとする。

本発明の説明においては、セキュリティトークンの有効期限は、信頼できない環境内では意味を為さないものとする。セキュリティトークンについての信用の置けるリアルタイムクロックが存在しないためである。管理されていない端末装置（例えば、加入者の通信デバイス）が用いている日時基準（date and time reference）を信用することはできない。そのような日時基準は、ハッカーにより簡単に書き換えられてしまうからである。

本発明は、セキュリティトークンの陳腐化を強制することにより、古いセキュリティトークンに有効期限を与えることのできるシステムを提供する。

これを行うため、サービスプロバイダは、順序付けられた一連のセキュリティドメインの系列に従ってセキュリティトークンを生成する。各セキュリティドメインは、その系列内での位置を表すドメインＩＤによって識別されるものとすることができる。各セキュリティドメインは、そのセキュリティドメイン内で発行される鍵についての認証機関（CA、Certification Authority）と、暗号化構成要素（アルゴリズムを含む）と、を含むことができる。ここで、認証機関又は暗号化構成要素のいずれかは、当該系列内の他のセキュリティドメインのものと同じとしてもよいし、異なるものとしてもよい。所与のセキュリティドメインの下で発行された各セキュリティトークンは、一のパーティが、同じセキュリティドメインの下で発行されたセキュリティトークンを持つ他のパーティ及び上記系列内において隣接する少なくとも２つのセキュリティドメインのいずれかの下で発行されたセキュリティトークンを持つ他のパーティとの間で、信頼できるメッセージを交換できるように構成される。

この構成によりサービスプロバイダは、適切と考えられる態様で、かつ適切と思われる時期に、新しいセキュリティドメインを設定することができる。セキュリティドメインが設定されると、現在のセキュリティドメイン（カレントセキュリティドメイン）の下で発行されたトークンを受信したパーティは、そのカレントセキュリティドメインの下で発行されたトークン、上記系列においてその前に位置するドメインの下で発行されたトークン、及びその系列においてその次に位置するドメインの下で発行されたトークンを持つパーティと、信頼できるメッセージを交換することができる。

これにより、連続するセキュリティドメインの間の相互運用性（interoperability）が確保されると共に、より古いドメインで発行されたトークンの有効性が徐々に減少していくこととなる。より古いトークンを持つパーティは、カレントドメインの下で発行されたトークンを持つパーティとの間で信頼できるメッセージを交換することはできないためである。その結果、強制的にトークンの更新を行うことのできるセンターサーバへのログインが要求されないような環境であっても、各パーティは、トークンが陳腐化してそのセキュリティシステム内の他のパーティとの間でのメッセージ交換ができなくなるのを避けるべく、トークンをカレントセキュリティドメインのものに更新する動機付けを持つこととなる。

ある実施形態では、トークンは、既知の方法で生成されて加入者の通信デバイスにダウンロードされる。この場合、加入者のトークンは、例えば加入者がトークンを使って安全なサーバにログインしたとき等に、適宜更新される。他の実施形態では、トークンは、物理デバイス（例えば、スマートカードなど）に埋め込まれてユーザに配布される。この場合、サービスプロバイダは、加入者が上記デバイス内に埋め込まれているトークンを更新するためのサービスや、古いデバイスを新しいデバイスと交換するためのサービスを提供する。

図１及び図２は、本発明に係るセキュリティシステムの構成を示す図である。図示のシステムは公開鍵暗号方式に基づくものであるが、同様の原理を対称アルゴリズム（symmetric algorithm）の用途に適用できることは、当業者にとり明らかである。

図１に示すセキュリティシステムは、ホストサーバ（本実施形態では、サービスプロバイダにより保守されている）と、複数の加入者（４つの加入者が図示されている）と、を含んでいる。各加入者は、公衆インターネットのような信頼できないデータネットワークを介した通信により接続されている。ホストサーバは、順序付けられた一連のセキュリティドメインの系列を管理し、当該系列を構成するセキュリティシステムの一つが「現在のドメイン（カレントドメイン）」として選定される。

図示の例では、各セキュリティドメインは、それぞれのドメインシリーズＩＤにより示されており、そのセキュリティドメインのための認証機関（CA、Certification Authority）と、当該認証機関が当該セキュリティドメインのために発行した公開鍵（PK、Public Key）と、を含んでいる。ほとんどの場合、系列内の各セキュリティドメインに対して同じ認証機関を選定することができるが、必ずしも同じ認証機関とする必要はない。原理的には、系列内の各セキュリティドメインは、必要であれば互いに異なる認証機関を持つことができる。しかしながら、いずれの場合においても、系列内の各セキュリティドメインに対して選定された認証機関が発行する公開鍵（ＰＫ）は、少なくともその系列内のセキュリティドメインの中ではユニークなものでなければならない。

運用の際には、選定されたカレントドメインの下で新しいトークンが発行される。この新しいトークンは、ユニークなトークンＩＤと、そのトークンに固有の秘密鍵（ＳＫｘ）及び公開鍵（ＰＫｘ）と、そのセキュリティドメインに選定された認証機関が発行したトークン公開鍵証明書と、カレントセキュリティドメインの公開鍵［ＰＫ（ｎｘ）］並びに上記系列内におけるその直前のセキュリティドメインの公開鍵及びその直後のセキュリティドメインの公開鍵と、を含んでいる。

或る実施形態では、トークンＩＤは、そのトークンが発行されたドメインのドメインシリーズＩＤを含むものとすることができる。また或る実施形態では、公開鍵［ＰＫ（ｎｘ）］は、公開鍵証明書の形式で保存されるものとすることができる。

図１及び図２に示す例では、代表的な４つの加入者（Ａ〜Ｄ）が示されており、そのうちの加入者Ｄのみが、現在選定されているカレントドメインの下で発行されたトークンを保持している。各加入者Ａ〜Ｃは、それぞれ、系列内においてより前に位置するドメインがカレントドメインとして選定された際に発行された古いトークンを保持している。

すなわち、加入者Ａは、セキュリティドメイン「ｎ１」の下で発行されたトークンを受信している。このトークンは、ドメインシリーズＩＤ（ｎ１）と、セキュリティドメインｎ１の認証機関が発行した証明書［ＣＡ（ｎ１）発行のＰｋａ］と、セキュリティドメインｎ１並びにセキュリティドメインｎ０及びｎ２の公開鍵［ＰＫ（ｎ０），ＰＫ（ｎ１），ＰＫ（ｎ２）］と、を含んでいる。

加入者Ｂは、セキュリティドメイン「ｎ２」の下で発行されたトークンを受信している。このトークンは、ドメインシリーズＩＤ（ｎ２）と、セキュリティドメインｎ２の認証機関が発行した証明書［ＣＡ（ｎ２）発行のＰｋｂ］と、セキュリティドメインｎ２並びにセキュリティドメインｎ１及びｎ３の公開鍵［ＰＫ（ｎ１），ＰＫ（ｎ２），ＰＫ（ｎ３）］と、を含んでいる。

加入者Ｃは、セキュリティドメイン「ｎ３」の下で発行されたトークンを受信している。このトークンは、ドメインシリーズＩＤ（ｎ３）と、セキュリティドメインｎ３の認証機関が発行した証明書［ＣＡ（ｎ３）発行のＰｋｃ］と、セキュリティドメインｎ３並びにセキュリティドメインｎ２及びｎ４の公開鍵［ＰＫ（ｎ２），ＰＫ（ｎ３），ＰＫ（ｎ４）］と、を含んでいる。

加入者Ｄは、セキュリティドメイン「ｎ４」の下で発行されたトークンを受信している。このトークンは、ドメインシリーズＩＤ（ｎ４）と、セキュリティドメインｎ４の認証機関が発行した証明書［ＣＡ（ｎ４）発行のＰｋｄ］と、セキュリティドメインｎ４並びにセキュリティドメインｎ３及びｎ５の公開鍵［ＰＫ（ｎ３），ＰＫ（ｎ４），ＰＫ（ｎ５）］と、を含んでいる。

本構成では、加入者ＡとＢとはメッセージを交換することができる。これらの加入者は、保持している認証機関発行の公開鍵の一部が一致しているため、これらの一致する公開鍵により、加入者Ａのｎ１ドメインのトークンは加入者Ｂから受信したメッセージの正当性を確認することができ、加入者Ｂのｎ２ドメインのトークンは加入者Ａからのメッセージの正当性を確認することができる。また、加入者Ｂは、保持している認証機関発行の公開鍵の一部が加入者Ｃの保持する公開鍵とも一致しているので、加入者Ａ及びＣの両者とメッセージを交換することができる。

同様に、加入者Ｃは、加入者Ｂ及びＤの両者とメッセージを交換することができる。ただし、加入者Ｂは、加入者Ｄとの間でメッセージを交換することはできず、加入者Ａは、加入者Ｃ又はＤとの間でメッセージを交換することはできない。このように、系列内において連続する各セキュリティドメインがカレントドメインに選定されるにつれて、古いセキュリティドメインの下で発行されたトークンは、徐々に有用度が下がり、最後には無用なものとなる。

図３は、加入者ＡとＢとの間で行われるメッセージ交換処理の一例を示している。この例では、加入者Ａから加入者Ｂへ信頼できるメッセージを送信することを目標とする。そこで、加入者Ａの通信デバイスは、加入者ＡのトークンのドメインシリーズＩＤの標識を含むチャレンジメッセージを送信する。或る実施形態では、ドメインシリーズＩＤは加入者ＡのトークンＩＤの一部を構成するものとすることができるが、必ずしもそうである必要はない。

加入者Ｂの通信デバイスは、チャレンジメッセージを受信すると、自身のトークンに含まれる公開鍵のセットをチェックして、加入者Ａのセキュリティドメイン（ｎ１）用の公開鍵を有しているか否かを判断することができる。この例では、上記検証チェックの結果は「ｙｅｓ」となり、加入者Ｂの通信デバイスはこれに対応するＡｃｋ（ＯＫ）メッセージを加入者Ａに返信する。

加入者Ａの通信デバイスは、Ａｃｋ（ＯＫ）メッセージを受信すると、自身のトークンを使って暗号化された信頼できるメッセージを生成して送信する。このメッセージには、加入者Ｂに対する加入者Ａの証明書が含まれる。加入者Ｂの通信デバイスは、この信頼できるメッセージを受信すると、自身のトークンを使って、加入者Ａのセキュリティドメインの公開鍵［ＰＫ（ｎ１）］を取得し、上記受信したメッセージに含まれる証明書の正当性を確認する。

図３を参照して上述したチャレンジ送信と応答送信とを用いる方法では、送信パーティと受信パーティとの間でリアルタイム接続を確立する必要があり、リアルタイム接続を用いることができない場合には、メッセージ転送を行うための複雑な遅延転送プロトコルが必要になる、という制限が生ずる。上述したように、或る実施形態では、トークンＩＤはそのトークンが発行されたドメインのドメインシリーズＩＤを含むものとすることができる。

例えば、一つの可能な実施形態として、トークンＩＤを１５ビットのデータフィールドで構成するものとし、最初の１１ビットがトークンを一意的に表し、その後ろの４ビットがドメインシリーズＩＤを構成するものとすることができる。当業者にとり、他の適切なフォーマットが存在することは明らかであり、所望の他のフォーマットを適宜使用することができる。この方法によりドメインシリーズＩＤをトークンＩＤに埋め込むと、図３に示すような受信パーティ（上述の例における加入者Ｂ）から送信パーティへのチャレンジメッセージの送信が不要になるという利点が生ずる。

必要なのは、送信パーティが所望の受信者のトークンＩＤを知ることである。この情報は、種々の方法で送信パーティに渡すことができるので、チャレンジ送信／応答送信の処理では必須であった２つのパーティ間のリアルタイム接続の要件は不要なものとすることができる。

図４は、他の実施形態を示す図である。図示の実施形態では、カレントドメインの下で発行された新しい各トークンは、当該トークンに固有な秘密鍵（ＳＫｘ）及び公開鍵（ＰＫｘ）と、そのセキュリティドメインについて選定された認証機関により発行された証明書と、カレントセキュリティドメイン並びに次のセキュリティドメイン及び直前の２つのセキュリティドメインにおける公開鍵［ＰＫ（ｎｘ）］と、を有している。

すなわち、例えば加入者Ｃのトークンは、図１及び図２に示す実施形態と同様にドメインシリーズＩＤ（ｎ３）とセキュリティドメインｎ３の認証機関が発行した証明書［ＣＡ（ｎ３）発行のＰｋｃ］とを有しているが、本実施形態では新たにセキュリティドメインｎ１〜ｎ４についての４つの公開鍵［ＰＫ（ｎ１），ＰＫ（ｎ２），ＰＫ（ｎ３），ＰＫ（ｎ４）］を有している。

同様に、加入者Ｄのトークンは、図１及び図２に示す実施形態と同様にドメインシリーズＩＤ（ｎ４）とセキュリティドメインｎ４の認証機関が発行した証明書［ＣＡ（ｎ４）発行のＰｋｄ］とを有しているが、本実施形態では新たにセキュリティドメインｎ２〜ｎ５についての４つの公開鍵［ＰＫ（ｎ２），ＰＫ（ｎ３），ＰＫ（ｎ４），ＰＫ（ｎ５）］を有している。

この構成においては、加入者Ａは、加入者Ｃにメッセージを送信することができる。加入者Ｃのトークンは、加入者Ａのセキュリティドメインの公開鍵［ＰＫ（ｎ１）］を有しているためである。ただし、加入者Ａは、加入者Ｃからメッセージを受信することはできない。加入者Ａのトークンは、加入者Ｃのセキュリティドメインの公開鍵［ＰＫ（ｎ３）］を有さず、加入者Ｃの証明書を確認することができないからである。

同様に、加入者Ｂは、加入者Ｄにメッセージを送信することはできるが、加入者Ｄからメッセージを受信することはできない。この構成は、より古いトークンの有用性をより漸進的に低下させる。より古いトークンを保持するパーティは、カレントセキュリティドメインの下で発行されたトークンを保持するパーティとの通信能力が低下していくが、当該パーティとの通信が完全に遮断されるわけではないからである。

上述したように、ユーザのセキュリティトークンは、当該ユーザの古いトークンがカレントセキュリティドメインの下で発行された新しいトークンに置き換わることによって更新される。しかしながら、サービスプロバイダは、カレントドメインの下でセキュリティトークンを更新することもできる。すなわち、系列を構成する次のセキュリティドメインを生成することなく、セキュリティトークンを更新することができる。例えば、加入者が安全なサーバにログインしたときに、認証機関の公開鍵を追加又は削除することにより当該ユーザのセキュリティトークンを修正して、他のセキュリティドメインの下で発行されたトークンを保持するユーザとの信用できるメッセージ交換を行えるように、当該ユーザの通信能力を変更することができる。

或る実施形態では、トークンの最新版を他のトークンに引き渡すように、プロセッサ１０を制御するファームウェアが構成される。例えば、上述したように、ユーザのセキュリティトークンは、セキュリティドメインが変更されなくても、更新したり修正したりすることができる。この場合、プロセッサのファームウェアは、同じドメインシリーズＩＤを持つ他のトークンへの変更に関する情報を通信するように動作する。この情報は、例えば、コンテンツ転送メッセージ（content transfer message）内に埋め込まれた暗号化されたフィールドにより行われる。プロセッサ１０は、コンテンツ転送メッセージを受信すると、このフィールドを解読してトークン変更情報を抽出し、必要に応じて、当該情報に従って自身のトークンの内容を更新する。

上述した本発明の各実施形態は、単に一例を示したものである。すなわち、本発明の範囲は、添付の特許請求の範囲によってのみ限定される。

Claims (6)

1. 互いに通信する機能を有する複数のデバイスで構成されるネットワークシステムの通信の安全性を管理し制御する方法であって、
   ホストサーバが、ドメインＩＤと鍵とをそれぞれに割り付けることにより一連のセキュリティドメインのシリーズを定義するステップと、
   常に一つの前記セキュリティドメインのみがカレントドメインとなっているように、前記ホストサーバが、前記一連のセキュリティドメインのそれぞれをカレントドメインに順次選定するステップと、
   前記ホストサーバが、前記カレントドメインの下で第１のセキュリティトークンを生成して、当該第１のセキュリティトークンを第１のデバイスに配信するステップと、
   を含み、
   前記第１のセキュリティトークンは、
   前記第１のデバイスに、前記カレントドメインの下で前記ホストサーバが生成した第２のセキュリティトークンを持つ第２のデバイスとの間、前記セキュリティドメインの前記シリーズにおいて前記カレントドメインの次に位置する前記セキュリティドメインの下で前記ホストサーバが生成した第３のセキュリティトークンを持つ第３のデバイスとの間、及び前記セキュリティドメインの前記シリーズにおいて前記カレントドメインの前に位置する前記セキュリティドメインの下で前記ホストサーバが生成した第４のセキュリティトークンを持つ第４のデバイスとの間、での、暗号により安全が保証されたメッセージの交換を可能にさせるように、
   前記カレントドメインにおける少なくとも一つの鍵と、前記カレントドメインの次に位置する前記セキュリティドメインにおける少なくとも一つの鍵と、前記カレントドメインの前に位置する前記セキュリティドメインにおける少なくとも一つの鍵と、を含む一組の鍵で構成されている、
   方法。
2. 前記第１のセキュリティトークンは、前記第１のデバイスに、前記セキュリティドメインの前記シリーズにおいて前記カレントドメインの前に位置する２つの前記セキュリティドメインの下で前記ホストサーバが生成した第５のセキュリティトークンを持つ第５のデバイスと間での、暗号化により安全が保証されたメッセージの交換を可能にさせるよう構成されている、請求項１に記載の方法。
3. 前記各セキュリティドメインは、公開鍵基盤（PKI、Public Key Infrastructure）を用いて定義され、かつ、それぞれに公開鍵を備える、請求項１に記載の方法。
4. 前記第１のセキュリティトークンは、前記カレントドメイン、前記シリーズにおけるその次のセキュリティドメイン、及び前記系列におけるその前のセキュリティドメインのそれぞれの公開鍵を有する、請求項３に記載の方法。
5. 前記第１のセキュリティトークンは、さらに、前記シリーズにおける二つ前のセキュリティドメインの公開鍵を備える、請求項４に記載の方法。
6. 前記ネットワークの安全が保証されたサーバにデバイスがログインしたときに、当該デバイス内に保持されているセキュリティトークンを自動的に更新するステップ、を更に有する、請求項１に記載の方法。

Images