JP5707486B2 - 鍵更新機構を有する鍵管理デバイス、システム及び方法 - Google Patents

Description

（関連出願の相互参照）
この出願は、２０１１年３月２３日付け提出された米国特許出願第１３／０６９，９８９号（それは２０１０年４月３０日付け提出された米国仮出願第６１／３２９，９１６号の優先権を主張するものである）の利益を主張する。それらの開示全体が参照によって本明細書に組み込まれる。

（技術分野）
本明細書で説明される好ましい実施形態は一般にスマートグリッド通信及び他の通信に関係する。特に、同一のマスターセッション鍵を使用する各々のアプリケーションの暗号鍵の鍵更新の頻度に依存しない鍵管理機構に関係する。

エネルギー資源の効率的利用及び管理が今日の世界でますます重要になっている。多くの国は、最先端の通信及び情報テクノロジーを用いてシステムに諸能力を加えることによって、パワーグリッド（送電網）（power grid）の近代化に重要性を生じさせている。

この変革はスマートグリッドイニシアティブ（Smart Grid initiatives）の傘下で起こっており、それによって、パワーグリッドが、例えば監視能力、解析能力、制御能力及び双方向通信能力などのような拡張機能を追加している。目標は、エネルギーを節約し、コストを削減し、信頼性及び透明性を増加させることである。これらの機能及び能力の多くは今日存在するが、それらは孤立して存在し、個々のＥＳＰによって制御される。スマートグリッドの目標は、エネルギー資源の効率的利用を通じてグリッドシステムのスループットを最大化するために、上で述べられた拡張機能をもつインフラストラクチャーを作成することである。

スマートグリッドインターオペラビリティプロジェクト（Smart Grid Interoperability project）及び米国電気電子技術者協会標準化団体（Institute of Electrical and Electronics Engineers Standard bodies）は、目標を達成するための最良の方法は複数の異なる技術及びレイヤで構成される通信ネットワークを作成することであると理解した。この通信ネットワークは、ワイドエリアネットワーク（ＷＡＮ）から顧客構内ネットワーク（customer premise networks）（例えば、ホームエリアネットワーク（ＨＡＮ）又はビジネスエリアネットワーク（ＢＡＮ））にわたるであろう。例えば、先進メータリング（Advanced Metering）、家庭電器（Home Appliances）は、ＨＡＮ又はＢＡＮのいずれにも接続することができ、そして、ＥＳＰに情報を送信するために、ＷＡＮを利用することができる。このシステムは、コミュニティのすべての利害関係者（stakeholders）が、今日それらが利用できるものよりも非常に効率的に、該システムとインターラクトし、該システムを監視し、該システムを管理することを潜在的に可能にできるであろう、今日のインターネットに類似する、情報スーパーハイウェイに変化する潜在能力を有する。

各電気サービスプロバイダ（ＥＳＰ）は通信及び情報テクノロジーの諸能力に刺激されているが、それらはまたパワーグリッドのコンポーネントが接続される物理的境界が存在しないかもしれないという事実について心配している。例えば、従来のグリッドとは異なり、先進メータリングシステムは、インターネットを介して、又は、攻撃の影響を受けやすい及び盗聴若しくはなりすましに弱い無線ネットワークを介して、ＥＳＰに接続されることがあり、それは、結局、グリッドの安全性及び信頼性を損なう可能性がある。したがって、通信及び情報セキュリティーは、そのような技術を採用するための主要な要件のうちの一つになっている。それゆえ、それの上で運ばれる情報は安全でセキュアであるという保証を提供するために、ネットワークを保護することは不可欠である。

今日、セキュリティー技術の大部分は、通信ネットワークセキュリティーに対処するために利用できるが、スマートグリッド環境が異なると、それによって、要件が異なってくる。例えば、先進メータリングシステム又はスマートメータの中の電気又はガスメータは、パーソナルエリア無線ネットワーク技術（例えば、ＺｉｇＢｅｅ（登録商標））をもつ低処理能力デバイスである（背景文献（background reference）８を参照）。これらのデバイスは、通常、典型的には４−１２ＫのＲＡＭ及び６４−２５６Ｋのフラッシュメモリをもつ低コスト無線デバイスと考えられる。しばしば、これらのデバイスは、低バンド幅リンクをもつバックホールに接続されることがある。リンク特性はまた、無線機能（例えばスリーピング又はアイドルのオペレーションモードなど）によって変わり得る。例えば、先進メータリングシステムは、常にアクティブのままであるよりはむしろ、電力を節約するために、ネットワークと同期して周期的にウェイクアップするかもしれない。デバイスの更なる要件は以下を含み得る：ｉ）メッシュトポロジーを使用してマルチホップネットワークをサポートすること（例えば、バックホールの範囲を後方に広げるために）；ｉｉ）複数のリンクレイヤ技術をサポートすること。これらの要件は、プロトコルオーバーヘッド及びパフォーマンスが最適化されるべきことを要求する。

先進メータはまた、単一のメータリングデータに加えて他の目的のために使用されることができる。背景文献１において開示されるように、ＡＮＳＩ Ｃ１２．２２は、リレー又はコンセントレータを介してピアリングする先進メータを使用することを可能にする。背景文献５において開示されるように、例えばＣＯＡＰのような他のアプリケーションが、単一のメータ上で同時に動作し得る。これらは非常に魅力的な特徴であり、先進メータを経済的により成長させ得るが、それらはセキュリティーに対して更なる要件を加える（例えば、各々のアプリケーションは認証される必要があり、また、システム（例えば、請求システム（billing system））に対するデータの完全性を維持する必要がある）。

鍵管理はかなり注目される分野であった（特にブラウザーベースのウェブアプリケーションでは）。特に、例えばＯＡｕｔｈ（背景文献１１に記載）、ＯｐｅｎＩＤ（背景文献１２に記載）、ＳＡＭＬ（背景文献１３に記載）及びその他のようなイニシアティブは、シングルサインオン（ＳＳＯ）能力を提供するために出現した。ポピュラーなＳＳＯイネーブラはＯＡｕｔｈである。それは、静的な信用証明書がサードパーティーとシェアされることを要求することなく、エンドユーザが、ネットワーク資源へのサードパーティーアクセスを認可するための機能を提供する。ＯＡｕｔｈは、ユーザエージェントリダイレクション及びサードパーティーとシェアされる一時的に発行された鍵により、これを達成する。他のポピュラーなＳＳＯ技術は、商用ウェブサービスに対するかなりの勢いを得たＯｐｅｎＩＤであり、幾つかの著名なウェブサービスプロバイダ（とりわけ、Ｇｏｏｇｌｅ、Ｙａｈｏｏ！、ＡＯＬ及びｆａｃｅｂｏｏｋのような）で使用されるものである。ＯｐｅｎＩＤは、オープンであり、ユーザが単一のデジタル識別情報により幾つかの異なるサービスにサインオンすることを可能にする分散アクセス制御機構である。ＯｐｅｎＩＤは、各々のサービスプロバイダにより提供されるサービスにアクセスするために、加入者のサービスプロバイダへの定期的なログオンを要求する。また、ちょうど出回り始めているＯｐｅｎＩＤに関連する脆弱性に関してセキュリティーの懸念がある。

例えば、背景文献１４において、著者は、例えば対称暗号、リレープロバイダー及びＯｐｅｎＩＤプロバイダーにおいて記憶される認証ステータスの時間長、及び、介入者攻撃に対する脆弱性のような、明らかにされた限界を扱う。セキュアアサーションマークアップ言語（ＳＡＭＬ）は、例えば企業ネットワークのようなセキュアなドメイン間に認証及び許可データを提供するテクニックである。ＳＡＭＬは、ＸＭＬにおいて定義され、同一のフェデレイション（連合）の下で複数ドメインにわたる認証及び許可タスクを容易にするために、連合された同一性管理技術を使用する。背景文献１５において、著者は、ＳＡＭＬの脆弱な実装をもたらすかもしれない、機密性、相互認証、完全性及びユーザ追跡に関する幾つかのセキュリティーフローを確認する。

しかし、ＯＡｕｔｈ、ＯｐｅｎＩＤ及びＳＡＭＬは、クロスレイヤ鍵管理を必要とする完全統合鍵管理を扱わない。幾つかの技術は、背景引用１６と１７に記載されているように、ＥＡＰとの統合を試みることによって、ケルベロス（Kerberos）の中のネットワークアクセス認証の欠如に取り組んだ。しかし、これらの技術は、ケルベロスと相互作用するために、修正されたＥＡＰメソッド（modified EAP methods）を必要とする。

また、例えばＥＡＰ（Extensible Authentication Protocol）（拡張認証プロトコル）、ＰＡＮＡ（Protocol for carrying Authentication for Network Access）（ネットワークアクセスのために認証を運ぶためのプロトコル）及びＡＮＳＩ Ｃ１２．２２（Protocol Specification For Interfacing to Data Communication Networks）（データ通信ネットワークとのインタフェースのためのプロトコル仕様）のような通信プロトコルが知られている。

例えば、ＡＮＳＩ Ｃ１２．２２は、スマートグリッド通信におけるメータアプリケーションプロトコルである。ＡＮＳＩ Ｃ１２．２２は、ＥＡＸ’を使用する。ＥＡＸ’は、ＥＡＸと１２８ビットＡＥＳとの組み合せであるブロック暗号アルゴリズムであり、アプリケーションレイヤ暗号化を提供するために、対称暗号鍵（symmetric cryptographic key）（又は暗号化鍵（ciphering key））を使用するデータ暗号化を提供する。ＡＮＳＩ Ｃ１２．２２は、二つ以上の暗号化鍵が同一のピアのために使用されることを可能にし、また、セッション開始時にそれらのうちから一つの暗号化鍵を選択する。

しかし、ＡＮＳＩ Ｃ１２．２２は、ＥＡＸ’の暗号化鍵の動的な鍵更新（re-key）のための機能を定義しないので、使用されている鍵の強度は、同じ暗号化鍵を用いて暗号化されるデータの量が増えるにしたがい、弱められる。したがって、ＡＮＳＩ Ｃ１２．２２の暗号化鍵に鍵更新機構を提供することが必要である。

ＥＡＰを使用する方法は、２０１０年１１月に提出された“暗号化された情報を送信するための端末（Terminal for transmitting encrypted information）”と題されたOba, YによるＰＣＴ出願ＪＰ２００９＿６９９８２（背景文献２）において示される。この方法は、ＥＡＰ認証により生成される一つのＥＭＳＫ（Extended Master Key）（拡張マスター鍵）から一つのＡＮＳＩ Ｃ１２．２２の暗号化鍵を生成することに向けられる。それは、Ｃ １２．２２の鍵更新が必要な場合には、ＥＡＰの再認証を行い、新たに生成されたＥＭＳＫから新しいＡＮＳＩ Ｃ１２．２２の暗号化鍵を生成する。

前述のＰＣＴ出願ＪＰ２００９＿６９９８２において定義される鍵更新方法の強化として、同一のＥＭＳＫから二つ以上のアプリケーション暗号化鍵が生成されるユースケースを考える。

ＥＭＳＫの任意の子孫鍵（descendant key）の更新が必要になった場合、ＥＭＳＫを鍵更新するためにＥＡＰの再認証が起こることが必要であるため、同一のＥＭＳＫを使用するすべてのアプリケーションの暗号化鍵の更新が起こることになる。

一般に暗号化鍵の鍵更新の頻度は各々のアプリケーションの特徴に依存するが、より高い鍵更新頻度を要求するアプリケーションの暗号化鍵の鍵更新が起こるならば、それはそのような高い鍵更新頻度を要求しない他のアプリケーションの暗号化鍵の不必要な鍵更新をもたらすであろう。

この問題を解決するために、ＥＡＰの再認証の頻度が同一のＥＭＳＫを使用している各々のアプリケーションの暗号化鍵の鍵更新の頻度に依存しない鍵管理機構（key management mechanism）が必要である。

３．背景文献
以下の背景文献は、それらの全体が参照により本明細書に組み込まれる。
1. American National Standard. Protocol Specification For Interfacing to Data Communication Networks. ANSI C12.22-2008. 2008 （以下、［１］と記載する）.
2. Oba, Y, Terminal for transmitting encrypted information, JP2009_69982, November, 2010, PCT application （以下、［２］と記載する）.
3. SaloweyJ., Specification for the Derivation of Root Keys from an Extended Master Session Key (EM SK). （以下、［３］と記載する）.
4. Aboba B., Extensible Authentication Protocol (EAP), （以下、［４］と記載する）.
5. Shelby Z., CoAP Requirements and Features. （以下、［５］と記載する）.
6. Forsberg D., Protocol for Carrying Authentication for Network Access (PANA) （以下、［６］と記載する）.
7. Smart Grid Interoperability Standards Project （以下、［７］と記載する）.
8. ZigBee Alliance. ZigBee Specification. ZigBee Document 053474r18. 2009 6 （以下、［８］と記載する）.
9. A Patrick, J. Newbury, and S. Gargan, Two-way communications systems in the lectricity supply industry, IEEE Transactions on Power Delivery, 13:53-58, January, 1998 （以下、［９］と記載する）
10. Smart Power Directorate （以下、［１０］と記載する）.
11. Hammer-LahavE. The OAuth 1.0 Protocol. 2010 （以下、［１１］と記載する）.
12. OpeniD Authentication 2.0 Final Technical Specification （以下、（以下、［１２］と記載する）．
13. Dynamic Security Assertion Markup Language : Simplifying Single Sign-On. HardingP., JohanssonL. , KlingensteinN. : IEEE Security & Privacy, 2008. 8 （以下、［１３］と記載する）.
14. OhHyun-Kyung , JinSeung-Hun, The Security Limitations of SSO in OpenID. : ICACT 2008 （以下、［１４］と記載する）.
15. Security analysis of the SAML single sign-on browser/artifact profile. GrossT. : Computer Security Applications Conference 2003 （以下、［１５］と記載する）.
16. OhbaY., DasS. , DuttaA., Kerberized handover keying: a media-independent handover key management architecture.: ACM MobiArch 2007（以下、［１６］と記載する）.
17. A Kerberized Architecture for Fast Re-authentication in Heterogeneous Wireless Networks. LopezR., GarciaF. , OhbaY. : Mobile Networks and Applications, 2010 （以下、［１７］と記載する）.
18. AbobaB., SimonD. , EronenP. Extensible Authentication Protocol (EAP) Key Management Framework. 2008 8 （以下、［１８］と記載する）.
19. KaufmanC. Internet Key Exchange (IKEv2) Protocol. 2005 5 （以下、［１９］と記載する）.
20. Vogt C. A Solution Space Analysis for First-Hop IP Source Address Validation. 2009 January （以下、［２０］と記載する）.
21. OhbaY. , YeginA. , Definition of Master Key between PANA Client and Enforcement Point, 2009 （以下、［２１］と記載する）.
22. ZigBee Alliance. ZigBee Smart Energy Profile^TM 2.0 Technical Requirements Document. 2010 （以下、［２２］と記載する）.
23. Narayanan V. , Dondeti L. EAP Extensions for EAP Re-authentication Protocol (ERP). 2008 August （以下、［２３］と記載する）.

本発明の実施形態の上記の及び他の特徴及び利点は、以下の添付図面を参照しながらその詳細な例示的な実施形態を説明することによって、より明らかになる。
図１は、実施形態の鍵階層を示す図である。 図２は、実施形態のＥＡＰ鍵管理フレームワークに基づく鍵管理機構を示す図である。 図３は、実施形態のネットワークコンフィギュレーションを示す図である。 図４は、実施形態のＭＳＫ及びＥＭＳＫを確立するためのシーケンスを示す図である。 図５は、実施形態のＡＮＳＩ Ｃ１２．２２登録サービスのためのシーケンスを示す図である。 図６は、実施形態のＡＮＳＩ Ｃ１２．２２リゾルブサービスのためにシーケンスを示す図である。 図７は、実施形態のＣＯＡＰ／ＨＴＴＰのためのシーケンスを示す図である。 図８は、実施形態の鍵更新のためのシーケンスを示す図である。 図９は、実施形態のＥＡＰベースの完全統合モデル及び部分統合モデルを示す図である。 図１０は、実施形態の先進メータリングシステムのアーキテクチャーの基本的なコンポーネントを示す。 図１１は、多数のスマートメータを一つの有り得る実施形態のユーティリティオフィスとマッピングするための一つの有り得るコンフィギュレーションを示す。

詳細な説明

本発明は多くの様々な形において実現されても良く、幾つかの具体例は本開示が発明の原理の例を提供するものとして考えられるべきこと及びそのような例が本発明を本明細書で説明され及び／又は本明細書で図示される好ましい実施形態に制限することを意図しないことの理解の下で本明細書で説明される。

イントロダクション
本発明の好ましい実施形態は、既存の技術に見られる様々な不備を克服する。

幾つかの実施形態によれば、例としてスマートメータのための、鍵更新方法が提供される。該方法は、複数のアプリケーション又はアプリケーション内の複数の異なる用途のそれぞれに対して、個別の用途鍵の鍵配列を、一つのマスター鍵から、該鍵配列内の各用途鍵が互いに独立した暗号鍵になるように導出する鍵制御機構を提供することを含む。

幾つかの例において、前記方法は、前記鍵制御機構が、各アプリケーション毎に、一つのマスター鍵から一つのアプリケーションマスター鍵を導出し、該アプリケーションマスター鍵から前記鍵配列を導出することを含む。

幾つかの例において、本方法は、同一時刻において前記鍵配列内の唯一つの用途鍵が有効であり、前記鍵制御機構は、有効な用途鍵の鍵更新が必要である場合に、該有効な用途鍵に対応する配列インデックス値を、使用済みとして記憶し、前記鍵配列から未使用の用途鍵の一つを新たな有効な用途鍵として使用することを含む。

幾つかの例において、前記鍵制御機構は、記憶された前記配列インデックス値に１を加えた値に等しいインデックス値を有する用途鍵を、新たな有効な用途鍵として使用する。

幾つかの例において、前記鍵制御機構は、前記鍵配列の配列サイズを、前記用途鍵の更新の頻度に比例する値に設定する。

幾つかの例において、前記鍵制御機構は、前記用途鍵を使用する前記アプリケーションの制御メッセージを用いてネゴシエーションすることによって、前記鍵配列の配列サイズを決定する。

幾つかの例において、前記鍵制御機構は、ＥＡＰ、ＥＡＰ認証メソッド又はＥＡＰトランスポートプロトコルを用いてネゴシエーションすることによって、鍵配列の配列サイズを決定する。

幾つかの例において、前記鍵制御機構は、ＥＡＰトランスポートプロトコルとしてＰＡＮＡを使用する。

幾つかの例において、マスター鍵はＥＭＳＫである。

幾つかの例において、鍵導出ファクターのパラメータは、鍵配列の用途鍵に対応する配列インデックス値を含む。

幾つかの例において、前記アプリケーションのメッセージのそれぞれは、暗号化に使用される前記用途鍵に対応する配列インデックス値を含む。

幾つかの実施形態においては、前記鍵制御機構は、有効な用途鍵の鍵更新が必要である場合に、新たな有効な用途鍵の配列インデックス値を含むアプリケーションメッセージによって、対向するエンティティーに鍵更新を通知する。

幾つかの実施形態においては、前記鍵制御機構は、アプリケーションとしてＡＮＳＩ Ｃ１２．２２を使用する。

幾つかの実施形態においては、前記鍵制御機構は、有効用途鍵が鍵更新をする必要がある場合に、新たな有効用途鍵の配列インデックス値を含む制御メッセージによって、対向するエンティティーに鍵更新を通知する。

幾つかの実施形態においては、前記鍵制御機構は、アプリケーションとしてＣＯＡＰを使用する。

本発明の幾つかの他の実施形態によれば、複数のアプリケーション又はアプリケーション内の複数の異なる用途のそれぞれに対して、個別の用途鍵の鍵配列を、一つのマスター鍵から、該鍵配列内の各用途鍵が互いに独立した暗号鍵になるように導出する鍵制御機構を含むスマートメータが提供される。

本発明の幾つかの他の実施形態によれば、マルチレイヤ及びマルチプロトコル環境に適応できる方法で単一の統合鍵管理フレームワークによりマルチレイヤ認証を回避するために、単一のピアエンティティー認証の試行から複数の通信レイヤの複数のプロトコルのための各暗号化鍵を生成する統合鍵管理機構を含む通信ネットワークシステムが提供される。

幾つかの例において、前記システムは、複数のプロトコルの暗号化のブートストラッピングをサポートする鍵管理フレームワークを更に含む。

幾つかの例において、本システムはスマートグリッドシステムである。

様々な実施形態の上記の及び／又は他の態様、特徴及び／又は利点は添付の図面と併せて以下の説明を考慮して更に認識されるであろう。様々な実施形態は、該当する場合、異なる態様、特徴及び／又は利点を包含及び／又は除外することができる。その上、様々な実施形態は、該当する場合、他の実施形態の１又は複数の態様又は特徴を結合することができる。特定の実施形態の態様、特徴及び／又は利点の説明は、他の実施形態又は特許請求の範囲を制限するものとして解釈されてはならない。

詳細な議論
好ましい実施形態において、これらの問題を解決する手段として、一つのＥＭＳＫから、同一の用途のために使用され、暗号的に互いに独立している二つ以上の用途鍵（purpose-specific keys）が導出される。ここでは、用途鍵は、アプリケーションの暗号化鍵であり、アプリケーションにおける各々の特定の用途のために又は（アプリケーションに一つの特定の用途だけがある場合には）各々のアプリケーションのために、定義されることができる。同一の用途の二つ以上の用途鍵の配列は、用途鍵配列と呼ばれる。通信の双方向において特定の用途のデータを保護するために、同一の用途鍵配列が用いられても良く、あるいは、各方向において、異なる用途鍵配列が使用されても良い。アプリケーションプロトコルそのものが暗号化機構を有する場合には、生成された用途鍵は、対応する用途のために定義されるアプリケーションプロトコルメッセージを暗号化するために用いられる。

アプリケーションプロトコルそのものが暗号化機構を有しないが、アプリケーションプロトコルのトランスポートプロトコルが暗号化機構を有する場合には、生成された用途鍵は、アプリケーションプロトコルのメッセージを載せているトランスポートプロトコルメッセージを暗号化するために用いられる。用途鍵配列は、アプリケーションごとに生成されるアプリケーションマスター鍵（ＡＰＭＫ）から導出される。

ＡＰＭＫは、［３］で定義される鍵導出アルゴリズムを使用してＥＭＳＫから導出されるＵＳＲＫ(Usage Specific Root Key)（用途ルート鍵）として定義される。
ＡＰＭＫ＝ＫＤＦ（ＥＭＳＫ、鍵ラベル、｜“￥０”｜オプションデータ｜長さ）
ここで、例えば、鍵ラベルは、ＡＰＭＫにバインドされるアプリケーションを特定する文字列であり、例えば、該文字列にapplication1@ietf.orgが用いられる。

オプションデータパラメータは、Ｎｕｌｌ（０ｘ００）であり、長さは、オクテット単位の鍵長である。ここで、長さは、アプリケーションに依存する。ＫＤＦ(Key Derivation Function)（鍵導出機能）の定義について［３］への参照がなされる。用途鍵配列ＰＫの第ｉ番目の配列要素ＰＫ［ｉ］は、ＡＰＭＫから以下のように導出される。

ＰＫ［ｉ］＝ＫＤＦ（ＡＰＭＫ、鍵ラベル、｜“￥０”｜オプションデータ｜長さ）
ここで、鍵ラベルは、アプリケーション内の用途を一意に識別する文字列であり、例えば、Appliction1_FunctionX@ietf.orgが使用される；オプションデータには、少なくとも“ｉ”を含める。更に、オプションデータに他の情報を含めても良い。

用途鍵配列が通信の一つの特定の方向に専用にされる場合に、鍵が使用される方向に関する情報も含まれても良い。長さパラメータは、オクテット単位の鍵長であり、用途に依存している。ＫＤＦ（鍵導出機能）の定義について［３］への参照がなされる。用途鍵配列のサイズは、アプリケーション毎に、アプリケーションにおける用途毎に、異なっていても良い。このときに、用途鍵配列のサイズは、配列における用途鍵の鍵更新の頻度に比例して決定されても良い。

さらに、用途鍵配列のサイズは、アプリケーションの制御メッセージを用いてアプリケーションのピアリングエンティティー（peering entities）間でのネゴシエーションに基づいて、動的に決定されても良い。

さらに、用途鍵配列のサイズは、ＥＡＰ再認証の際に、例えばＰＡＮＡ ［６］のような、ＥＡＰ、ＥＡＰ認証メソッド、又はＥＡＰトランスポートプロトコルによるネゴシエーションに基づいて、動的に決定されても良い。

各アプリケーションは、いずれの鍵配列要素が鍵更新を必要とするかを指定することにより用途鍵を更新する。鍵配列要素の指定の方法として、幾つかの方法が存在する。第一の方法は、メッセージを暗号化するために使用される鍵に対応する鍵配列インデックスを、メッセージのそれぞれに含ませるものである。例えば、ＡＮＳＩ Ｃ１２．２２の場合、＜鍵ＩＤ＞（<key-id>）が、鍵配列インデックスに相当する。

第二の方法は、鍵配列のインデックスを、アプリケーションの制御メッセージで交換するものである。そのインデックスの用途鍵を用いて制御メッセージを暗号化することによって、この制御メッセージを、安全に鍵更新を実行するのに用いることができる。同じ用途鍵配列の中で過去に既に使用したインデックスは、鍵更新の際に使用されない。さらに、現在使用中のインデックスと異なるインデックスの用途鍵で暗号化されたメッセージを受信した場合、該受信されたインデックスが以前使った用途鍵のうちの一つであるならば、鍵更新を行わないようにする。

これを実現するために、用途鍵配列ごとに過去に使用したインデックスのリストを保持する方法や、有効なインデックス又は現在使用中のインデックスを保持し、鍵配列の用途鍵の鍵更新が実行されるたびに、有効なインデックスの値を１ずつインクリメントする方法がある。用途鍵の鍵更新の際に未使用の（intact）インデックスが存在しない場合には、ＥＡＰの再認証が実行され、それは同一のＥＭＳＫを使用するすべてのアプリケーションのためのすべての用途鍵の鍵更新をもたらす。

説明に役立つ実施形態
図１に、ＡＮＳＩ Ｃ１２．２２のための鍵階層の説明に役立つ例が示される。ここでは、ＡＮＳＩ Ｃ１２．２２アプリケーションは、次の二つの用途について述べる；登録サービス（registration service）とリゾルブサービス（resolve service）。ここでは、ＡＮＳＩ Ｃ１２．２２のためのＡＰＭＫ鍵は、ＳＭＭＫ（スマートメータマスター鍵）と呼ばれる。鍵ラベルとして例えばsmmk@itef.orgが使用される。
ＳＭＭＫ（スマートメータマスター鍵）＝ＫＤＦ（ＥＭＳＫ、smmk@ietf.org｜“￥０”｜オプションデータ｜長さ）：
−オプションデータ＝Ｎｕｌｌ（０ｘ００）
−長さ＝６４
ＳＭＫ−ＨＨは、リゾルブサービスで使用される用途鍵配列であり、ＳＭＫ−ＥＥは、登録サービスで使用される用途鍵配列である。

用途鍵配列ＳＭＫ−ＨＨの各配列要素は、Ｃ １２．２２サーバ（例えば、スマートメータ）とＣ １２．２２サーバが接続するＣ １２．２２リレーとの間で、リゾルブ要求メッセージ及びリゾルブ応答メッセージを暗号化するために使用される。用途鍵配列ＳＭＫ−ＨＨの各配列要素に使用される鍵ラベルパラメータは、“ＳＭＫ−ＳＭ−ＣＴＲ”であり、オプションデータパラメータは、例えば、ＡＮＳＩ Ｃ１２．２１リレーＡｐタイトル｜ＡＮＳＩ Ｃ１２．２１鍵ＩＤ（ANSI C12.21 Relay Ap-Title | ANSI C 12.21 key-id）であり、長さパラメータは、１６である。
ＳＭＫ−ＳＭ−ＣＴＲ（スマートメータとコンセントレータとの間のスマートメータ鍵）＝ＫＤＦ（ＳＭＭＫ，“ＳＭＫ−ＳＭ−ＣＴＲ”｜“￥０”｜オプションデータ｜長さ）：
−オプションデータ：ＡＮＳＩ Ｃ１２．２１リレーＡｐタイトル｜ＡＮＳＩ Ｃ１２．２１鍵ＩＤ
−長さ＝１６
用途鍵配列ＳＭＫ−ＨＨの各配列要素は、Ｃ１２．２２サーバが、Ｃ１２．２２サーバと１Ｃ １２．２２マスターリレーとの間で登録要求メッセージ及び登録応答メッセージを暗号化するために使用される。

用途鍵配列ＳＭＫ−ＥＥの各配列要素に使用される鍵ラベルパラメータは、“ＳＭＫ−ＳＭ−ＭＤＭＳ”であり、オプションデータパラメータは、例えば、ＡＮＳＩ Ｃ１２．２１クライアントＡｐタイトル｜ＡＮＳＩ Ｃ１２．２１鍵ＩＤであり、長さは１６である。ここで、演算子は、前のデータと後のデータをこの順番で連結する演算を意味する。
ＳＭＫ−ＳＭ−ＭＤＭＳ（スマートメータとＭＤＭＳとの間のスマートメータ鍵）ＫＤＦ（ＳＭＭＫ、“ＳＭＫ−ＳＭ−ＭＤＭＳ”｜“￥０”｜オプションデータ｜長さ）
−オプションデータ：ＡＮＳＩ Ｃ１２．２１クライアントＡｐタイトル｜ＡＮＳＩ Ｃ１２．２１鍵ＩＤ
−長さ＝１６
この文書において、「暗号化」（encryption）という語は、「暗号化及び完全性保護」（encryption and an integrity protection）を含む。

図２に、この実施形態を使用する鍵管理システムの機能構成の一例が示される。ここでは、ＵＫＭＦは、統合鍵管理機能（Unified Key Management Function）である。アプリケーション１とアプリケーション２は、アプリケーションである。機能Ｘと機能Ｙは、アプリケーション２のアプリケーション固有機能（application-specific functions）である。ここで、各々のアプリケーション固有機能は、アプリケーションの中で異なる用途のために働く。

ＥＡＰピアは、［４］のＥＡＰピア機能である。ＥＡＰオーセンティケータ／サーバは、［４］のＥＡＰオーセンティケータとＥＡＰサーバを含む機能である。ＥＡＰピア下位レイヤとＥＡＰオーセンティケータ下位レイヤは、それぞれ、ＥＡＰピアとＥＡＰオーセンティケータの下位レイヤのプロトコルエンティティーである。ネットワーク側の各機能要素は、異なるノード上に実装されても良い。

また、ＥＡＰオーセンティケータ／サーバ機能要素のＥＡＰオーセンティケータ機能とＥＡＰサーバ機能は、異なるノードに実装されても良い。

ＥＡＰは、ネットワークアクセス認証の一部として、又は、アプリケーションレベル認証の一部として、実行されても良い。前者の場合、ＰＡＮＡ、ＩＥＥＥ８０２．１ｘ、ＰＫＭｖ２、又は、ＩＰレイヤよりも下位に定義される任意の他のＥＡＰトランスポートプロトコルが使用されても良い。後者の場合、ＰＡＮＡ、ＩＫＥｖ２、又は、ＩＰレイヤ又は上記で定義される任意の他のＥＡＰトランスポートプロトコルが使用されても良い。

ＵＫＭＦは、ＥＭＳＫを管理し、また、各アプリケーションについて、アプリケーションマスター鍵及び用途鍵配列を管理する。

アプリケーション１は、唯一の用途のために働く。

アプリケーション２は、二つの用途のために働く。一つは機能Ｘにより実現され、他の一つは機能Ｙにより実現される。

ＭＳＫ及びＥＭＳＫ ［４］は、ＥＡＰピアとＥＡＰオーセンティケータ／サーバ内のＥＡＰサーバ機能により生成され、ＵＫＭＦにより保持される。エンドホストのＵＫＭＦは、ＭＳＫから、ＥＡＰピア下位レイヤにより使用されるべき一つの鍵又は複数の鍵を生成し、該ＥＡＰピア下位レイヤは、該生成された鍵を保持し使用する。同様に、ネットワークのＵＫＭＦは、ＭＳＫから、ＥＡＰオーセンティケータ下位レイヤにより使用されるべき一つの鍵又は複数の鍵を生成し、該ＥＡＰオーセンティケータ下位レイヤは、該生成された鍵を保持し使用する。ＵＫＭＦは、ＥＭＳＫから、アプリケーション１とアプリケーション２のそれぞれのために、ＡＰＭＫを生成する。そして、アプリケーション１、アプリケーション２の機能Ｘ及びアプリケーション２の機能Ｙは、該生成されたＡＰＭＫを保持し、そして、上記の鍵導出アルゴリズムを用いてＡＰＭＫから用途鍵配列を生成する。

用途鍵の生成及び鍵更新のための基本的なシーケンスは下で示される。
１．ＥＡＰピアとＥＡＰオーセンティケータ／サーバとの間でＥＡＰ認証を実行する。
２．ＥＡＰ認証が成功すると、ＥＡＰピアとＥＡＰサーバはＭＳＫとＥＭＳＫをそれらのＵＫＭＦへ渡す。
３．エンドホストのＵＫＭＦとネットワークのＵＫＭＦは、ＭＳＫを生成し、そして、該ＭＳＫを、それぞれ、該ＥＡＰピア下位レイヤとＥＡＰオーセンティケータ下位レイヤへ渡す。ＥＡＰピア下位レイヤとＥＡＰオーセンティケータ下位レイヤは、該ＭＳＫを用いて下位レイヤ暗号化をブートストラップする。
４．エンドホスト及びネットワークのアプリケーション１、アプリケーション２の機能Ｘ及びアプリケーション２の機能Ｙは、それぞれ、必要に応じてアプリケーション暗号化を有効化して、ピアリングエンティティー間で、アプリケーション１、アプリケーション２の機能Ｘ及びアプリケーション２の機能Ｙのメッセージを送受信する。

・アプリケーション暗号化が必要であるが、ＡＰＭＫがまだ取得されないときは、それらは、それらのＵＫＭＦからＡＰＭＫを取得し、アプリケーションの特定の用途のために用途鍵配列を生成し、そして、該鍵配列の有効なインデックスを初期値（例えば、０）に設定する。

・用途鍵の鍵更新が必要であるときは、例えば該有効なインデックスを一つインクリメントさせることによって、該有効なインデックスが更新され、そして、該用途鍵配列の該新たな有効なインデックスが、アプリケーションメッセージの中に含められ、そして、該アプリケーションメッセージは、該インデックスに対応する用途鍵を用いて暗号化される。

・ピアリングノードから受信されたアプリケーションメッセージは、該メッセージに含まれる用途鍵配列のインデックスが、該ピアリングノードのための有効なインデックス（すなわち、現在使用中のインデックス）と異なり、かつ、該ピアリングノードのために以前に使用されたインデックスのうちの一つと同じであるならば、廃棄される。

次に、図３に、アプリケーションの具体的なセットを用いた鍵管理オペレーションの一例が示される。図３は、スマートメータ、コンセントレータ及びＭＤＭＳ(Meter Data Management System)（メータデータ管理システム）サーバからなる。スマートメータは、コンセントレータを介して、電力使用量（electric power usage）をＭＤＭＳサーバに提供する（メータリーディング）。

さらに、スマートメータは、メータリーディング以外にウェブアプリケーションのクライアントとして機能し、コンセントレータを介して、ＭＤＭＳサーバ上にあるウェブアプリケーションサーバとアプリケーションデータの交換を行う。デマンドレスポンスが、ウェブアプリケーションであっても良い。

各アプリケーションの機能の詳細を以下に述べる。

アプリケーション１はウェブアプリケーションであり、ＣＯＡＰ ［５］とＨＴＴＰがプロトコルとして使用される。スマートメータは、ＣＯＡＰクライアントを有する。コンセントレータは、ＣＯＡＰプロキシを有する。ＭＤＭＳサーバは、ＨＴＴＰサーバを有する。ＣＯＡＰメッセージは、ＣＯＡＰクライアントとＣＯＡＰプロキシとの間で交換される。ＣＯＡＰプロキシは、ＣＯＡＰクライアントとＨＴＴＰサーバとの間でＣＯＡＰ−ＨＴＴＰプロトコル変換を行う。ＣＯＡＰメッセージは、ＣＯＡＰクライアントとＣＯＡＰプロキシとの間で暗号化される。

アプリケーション２はメータリーディングアプリケーションであり、プロトコルとしてＡＮＳＩ Ｃ１２．２２を使用する。アプリケーション２は、二つの機能、機能Ｘと機能Ｙを有する。アプリケーション２の機能Ｘは、ＡＮＳＩ Ｃ１２．２２登録サービスを実現する。

ＡＮＳＩ Ｃ１２．２２登録サービスにおいて、スマートメータはＡＮＳＩ Ｃ１２．２２サーバであり、コンセントレータはＡＮＳＩ Ｃ１２．２２リレーであり、ＭＤＭＳサーバはＡＮＳＩ Ｃ１２．２２マスターリレー及びＡＮＳＩ Ｃ１２．２２クライアントである。ＡＮＳＩ Ｃ１２．２２リレーは、Ｃ１２．２２サーバとＣ１２．２２マスターリレーとの間で登録メッセージのフォワーダとして機能し、登録メッセージはＣ１２．２２サーバとＣ１２．２２マスターリレーとの間で暗号化される。

アプリケーション２の機能Ｙは、ＡＮＳＩ Ｃ１２．２２リゾルブサービスである。

ＡＮＳＩ Ｃ１２．２２リゾルブサービスにおいて、スマートメータは、ＡＮＳＩ Ｃ１２．２２サーバであり、コンセントレータはＡＮＳＩ Ｃ１２．２２リレーである。

Ｃ１２．２２リゾルブサービスにおいて、Ｃ１２．２２サーバは、Ｃ１２．２２リレーに、Ｃ １２．２２クライアントのトランスポートアドレスを問合せる。

問合せメッセージは、Ｃ１２．２２サーバとＣ１２．２２リレーとの間で暗号化される。

ＥＡＰピア下位レイヤ及びＥＡＰオーセンティケータ下位レイヤとしてＰＡＮＡ ［６］が使用される。ＰＡＮＡにおいて、スマートメータは、ＰａＣ（ＰＡＮＡクライアント）であり、ＭＤＭＳサーバは、ＰＡＡ（ＰＡＮＡ認証エージェント）である。

他の実施形態において、ＰＡＡは他のノード（例えば、コンセントレータ又は図３中に示されていないアクセスルータ若しくはアクセスポイント）に存在しても良い。

次に、図４〜８に、鍵管理機構のオペレーションのためのシーケンス例が示される。図４〜８において、異なるノード間の矢印はノード間のプロトコルメッセージ交換を表し、機能ブロック内部の矢印は同一ノード内の機能要素間の情報の入出力を表す。また、矢印に付与された番号は、用途鍵の生成及び鍵更新のための上記の基本的なシーケンスのステップ番号に対応する。

番号に付与されたアスタリスク（＊）は、対応するステップがオプションであることを示す。

図４に、ＭＳＫとＥＭＳＫを確立するためのシーケンスの一例が示される。

詳細な生成手続きが以下に示される。
１． スマートメータとＭＤＭＳサーバとの間でＥＡＰ認証を実行する。
２． ＥＡＰ認証が成功すると、ＥＡＰピアとＥＡＰサーバは、ＭＳＫ及びＥＭＳＫを、それぞれのＵＫＭＦへ渡す。
３． スマートメータとＭＤＭＳサーバは、それぞれ、ＭＳＫを生成して、ＥＡＰピア下位レイヤとＥＡＰオーセンティケータ下位レイヤへ渡す。ＥＡＰピア下位レイヤとＥＡＰオーセンティケータ下位レイヤは、ＭＳＫを用いて、下位レイヤ暗号化をブートストラップする。

図５に、ＡＮＳＩ Ｃ１２．２２登録サービスのためのシーケンスの一例が示される。

詳細な登録手続きが以下に示される。
４ａ−スマートメータは、ＡＰＭＫをまだ取得していなければ、自身のＵＫＭＦからＡＰＭＫを取得して、有効なインデックスを初期化する。
４ｂ−スマートメータは、ＡＮＳＩ Ｃ１２．２２登録要求メッセージをコンセントレータへ送信する。
４ｃ−コンセントレータは、ＡＮＳＩ Ｃ１２．２２登録要求メッセージをＭＤＭＳサーバへフォワードする。
４ｄ−ＭＤＭＳサーバがまだＡＰＭＫを取得しないければ、自身のＵＫＭＦから取得し、ＡＰＭＫから用途鍵配列を生成し、有効なインデックスを初期化し、そして、受信したＡＮＳＩ Ｃ １２．２２登録要求メッセージで運ばれたインデックスにより指定される用途鍵を用いて、該受信したＡＮＳＩ Ｃ１２．２２登録要求メッセージを復号化する。
４ｅ−ＭＤＭＳサーバは、復号化に成功すれば、ＡＮＳＩ Ｃ１２．２２登録応答メッセージをコンセントレータへ送信する。
４ｆ−コンセントレータは、受信したＡＮＳＩ Ｃ１２．２２登録応答メッセージをスマートメータへフォワードする。

図６に、ＡＮＳＩ Ｃ １２．２２リゾルブサービス手続きのためのシーケンスの一例が示される。

詳細なリゾルブ手続きが以下に示される。
４ａ−スマートメータは、ＡＰＭＫをまだ取得していなければ、自身のＵＫＭＦからＡＰＭＫを取得して、有効なインデックスを初期化する。
４ｂ−スマートメータは、ＡＮＳＩ Ｃ１２．２２リゾルブ要求メッセージをコンセントレータへ送信する。

４ｃ−コンセントレータは、ＡＰＭＫをまだ取得していなければ、ＭＤＭＳサーバからＡＰＭＫを取得するために、ＡＰＭＫ取得要求メッセージをＭＤＭＳサーバへ送信する。ＡＰＭＫ取得要求メッセージには、スマートメータの識別情報及びアプリケーション識別情報（ＡＰＭＫ取得アルゴリズムの鍵ラベル値）が含まれる。
４ｄ−ＭＤＭＳサーバは、ＡＰＭＫをまだ取得していなければ、自身のＵＫＭＦからＡＰＭＫを取得する。
４ｅ−ＭＤＭＳサーバは、ＡＦＭＫを含むＡＰＭＫ取得応答メッセージをコンセントレータへ送信する。
４ｆ−コンセントレータは、ＡＰＭＫから用途鍵配列を生成し、有効なインデックスを初期化し、受信ＡＮＳＩ Ｃ１２．２２リゾルブ要求メッセージで運ばれるインデックスにより指定される用途鍵を用いてＡＮＳＩ Ｃ１２．２２リゾルブ要求メッセージの復号化に成功すれば、ＡＮＳＩ Ｃ１２．２２リゾルブ応答メッセージをスマートメータへ送信する。

さらに、ＡＰＭＫ取得要求メッセージとＡＰＭＫ取得応答メッセージは、ＡＮＳＩ Ｃ１２．２２取得メッセージとして定義されても良く、また、他のプロトコルのメッセージとして定義されても良い。

図７に、ＣＯＡＰ／ＨＴＴＰサービス手続きのためのシーケンスの一例が示される。

詳細なＣＯＡＰ／ＨＴＴＰサービス手続きが以下に示される。
４ａ−スマートメータは、ＡＰＭＫをまだ取得していなければ、自身のＵＫＭＦからＡＰＭＫを取得して、有効なインデックスを初期化する。
４ｂ−スマートメータは、ＣＯＡＰ要求メッセージをコンセントレータへ送信する。
４ｃ−コンセントレータは、ＡＰＭＫをまだ取得していなければ、ＭＤＭＳサーバからＡＰＭＫを取得するために、ＡＰＭＫ取得要求メッセージをＭＤＭＳサーバへ送信する。ＡＰＭＫ取得要求メッセージには、スマートメータの識別情報及びアプリケーション識別情報（ＡＰＭＫ取得アルゴリズムの鍵ラベル値）が含まれる。
４ｄ−ＭＤＭＳサーバは、ＡＰＭＫをまだ取得していなければ、自身のＵＫＭＦからＡＰＭＫを取得する。
４ｅ−ＭＤＭＳサーバは、ＡＰＭＫを含むＡＰＭＫ応答メッセージをコンセントレータへ送信する。
４ｆ−コンセントレータは、ＡＰＭＫから用途鍵配列を生成し、有効なインデックスを初期化し、受信したＣＯＡＰ要求メッセージで運ばれるインデックスにより指定される用途鍵を用いてＣＯＡＰ要求メッセージの復号化に成功すれば、ＨＴＴＰ要求メッセージをＭＤＭＳサーバへ送信する。
４ｇ−ＭＤＭＳサーバは、ＨＴＴＰ応答メッセージをコンセントレータへ送信する。
４ｈ−コンセントレータは、受信したＣＯＡＰ要求メッセージに含まれるインデックスにより指定される用途鍵を用いて暗号化したＣＯＡＰ応答メッセージをスマートメータに送信する。

さらに、ＡＰＭＫ取得要求メッセージとＡＰＭＫ取得応答メッセージは、ＨＴＴＰメッセージとして定義されても良く、また、他のプロトコルのメッセージとして定義されても良い。前者の場合には、ステップ４ｃは４ｆに、ステップ４ｅは４ｇにマージされても良い。

図８に、ＡＮＳＩ Ｃ１２．２２登録サービスのための用途鍵の鍵更新のためのシーケンスの一例が示される。

詳細な鍵更新手続きが以下に示される。

ここでは、スマートメータとＭＤＭＳサーバは、ＡＰＭＫをすでに取得しているものと仮定する。
４ａ−スマートメータは、新しい用途鍵配列インデックスを用いて暗号化したＡＮＳＩ Ｃ１２．２２登録要求メッセージを、コンセントレータへ送信する。
４ｂ−コンセントレータは、受信したＡＮＳＩ Ｃ１２．２２登録要求メッセージをＭＤＭＳサーバへフォワードする。
４ｃ−ＭＤＭＳサーバは、受信したＡＮＳＩ Ｃ１２．２２登録要求メッセージに含まれる用途鍵配列インデックスが有効なインデックスと異なることを検出すれば、このインデックスが登録のために過去にすでに使用されたインデックスのうちの一つであるかどうかを確認する。このインデックスがすでに使用されたインデックスのうちの一つであるならば、受信したメッセージは破棄され、何もされない。そうでなければ、このインデックスにより指定される用途鍵を用いてＡＮＳＩ Ｃ１．２．２２登録要求メッセージの復号化に成功すれば、ＭＤＭＳサーバは、このインデックスで有効なインデックスを置き換えて、ＡＮＳＩ Ｃ１２．２２登録応答メッセージをコンセントレータへ送信する。

４ｄ−コンセントレータは、ＡＮＳＩ Ｃ１２．２２登録応答メッセージをスマートメータへフォワードする。

更なる態様と実施形態
発明の更なる態様及び実施形態が以下のように説明される。
ａ．鍵管理機構
幾つかの実施形態においては、鍵管理機構は、同一の通信レイヤの中の複数のプロトコルにわたって又は異なる通信レイヤにわたって統合鍵管理機能（ＵＫＭＦ）を定義することに基づくものである。図９は、そのスキームの概念モデルを示す。図９は、アプリケーションレイヤプロトコル及びリンクレイヤプロトコルに言及するだけであるが、この概念は、ネットワークレイヤ及びトランスポートレイヤを含む任意の通信レイヤにおける暗号オペレーションを必要とする任意のプロトコルに広く適用できる。

理想的には、暗号化機構をもつすべてのプロトコルにわたって、唯一のＵＫＭＦが存在する。これは完全統合モデル（fully unified model）と呼ばれ、図９ａに示される。他方、配備要件及び他のデザイン制約に応じて、幾つかのプロトコルは、専用鍵管理機能（dedicated key management function）（ＤＫＭＦ）を使用しても良く、一方、他は一つのＵＫＭＦを使用しても良い。このモデルは部分統合モデル（partially unified model）と呼ばれる。図９ｂは、部分統合モデルの典型的なインスタンスを表す。ここでは、アプリケーションレイヤプロトコルだけが一つのＵＫＭＦを使用し、リンクレイヤプロトコルは各ＤＫＭＦを使用する。一般に、プロトコルとＵＫＭＦ又はＤＫＭＦとの間のマッピングは、部分統合モデルでは任意であり得る。また、完全統合モデル及び部分統合モデルの両方において、ＵＫＭＦを使用するプロトコルは、一つのＤＫＭＦを有しても良い。ここで、ＤＫＭＦは、ＵＫＭＦにより管理されても良い（そのようなＤＫＭＦは図９に示されていない）。例えば、幾つかのアプリケーションプロトコルが、それ自身の特定用途鍵管理プロトコル（application-specific key management protocol）に基づくＤＫＭＦを有し得るならば、ＵＫＭＦは、該ＵＫＭＦを該ＤＫＭＦとバインドするために、該特定用途鍵管理プロトコルにより使用されるべき対称鍵を生成し得る。

完全統合モデル及び部分統合モデルの両方において、一対のＵＫＭＦの間でセキュリティーアソシエーションを確立するための初期ピアエンティティー認証は、ネットワークアクセス認証又はアプリケーションレベル認証に基づくことができる。例えば、デバイスが最初に帰属（attaches）するアクセスネットワークが、オープンアクセスネットワークならば、初期ピアエンティティー認証は、アプリケーションレベル認証に基づくことができる。

該概念上のモデルは複数のプロトコルの暗号化のブートストラッピングをサポートする任意の鍵管理フレームワークに適用できるのに十分に一般的であるが、ＥＡＰ鍵管理フレームワークが既存のアクセス技術（例えば、イーサネット（登録商標）、Ｗｉ−Ｆｉ及びＷｉＭａｘなど）で使用されているので、その使用を考える。

以下では、上で説明されたすべての要件を満たすためのそのベース（図２）としてＥＡＰ鍵管理フレームワーク ［１８］に基づく鍵管理機構の詳細な具体化が説明される。ＥＡＰ ［４］は、当初、ＰＰＰ（ポイントツーポイントプロトコル）のためのネットワークアクセス認証プロトコルのために設計され、ＩＰレイヤプロトコル及びより高いレイヤプロトコル（例えば、ＰＡＮＡ ［６］及びＩＫＥｖ２ ［１９］など）に加えて、ＩＥＥＥ ８０２．３、ＩＥＥＥ ８０２．１１及びＩＥＥＥ ８０２．１６を含む複数のデータリンクレイヤプロトコルにより採用された。ＰＡＮＡは、ＺｉｇＢｅｅ ＳＥＰ２．０（スマートエネルギープロフィール（Smart Energy Profile）２．０） ［２２］のために考えられている。ＥＡＰによりサポートされる認証アルゴリズムは、ＥＡＰメソッドと呼ばれる。ＥＡＰは、対称及び非対称鍵ベースの方法を含む幾つかの方法をサポートする。

鍵生成方法を使用するＥＡＰは、二つのタイプの鍵を、その下位レイヤにエクスポートする（ＭＳＫ（マスターセッション鍵）とＥＭＳＫ（拡張可能なマスターセッション鍵））。ＭＳＫの用途は、ＥＡＰの下位レイヤを保護するためであり、また、ＵＫＭＦを使用するプロトコルのエンドポイントは、ＥＡＰのそれらと同じことでないことが有り得るので、特に例えばＡＮＳＩ Ｃ１２．２２ [１]及びＣＯＡＰ ［１］のようなＡＭＩアプリケーションのために鍵を生成するために、ＥＭＳＫを使用が考えられ、その一方で、主にＥＡＰの下位レイヤを保護するためにＭＳＫを使用する。

幾つかのアプリケーションは、複数の機能を有する（該複数の機能のために、同一のアプリケーションにおける異なる機能のための異なる要素の間で、通信が行われる）。例えば、ＡＮＳＩ Ｃ１２．２２は、登録機能（該登録機能において、Ｃ１２．２２リレーのチェーンがエンドホストを登録する役割を果たす）、及び、リゾルブ機能（該リゾルブ機能において、該エンドホストからの最初のホップＣ１２．２２が、該エンドホストの通信ピアのトランスポートアドレスをリゾルブする役割を果たす）を定義する。そのようなアプリケーションのために、図２で示されるように、アプリケーションの特定の機能において必要とされ、エンドホストと通信する各々のネットワーク要素に対して、異なる鍵が、生成され、配布される。図２において、二つのアプリケーションはＵＫＭＦにより管理され、アプリケーション２は鍵マテリアルの異なるセットを使用する二つの機能を有する。エンドホストにおけるＵＫＭＦ及び他の要素の間の通信は、ローカルＡＰＩを使用して実現されること、及び、ネットワークにおけるＵＫＭＦ及び他の要素は、ローカルＡＰＩ又は通信エンティティーが同一のデバイスにおいて実装されるか否かに依存するプロトコルを使用して実現されることが仮定される。

ＥＡＰベースの統合鍵管理機構におけるＵＫＭＦの主なタスクは、ＥＡＰキーイングマテリアルを、それがエンドホストに存在するか又はネットワークに存在するかに応じて、ＥＡＰピア又はオーセンティケータ／サーバから受信し、その鍵コンシューマに対して、鍵マテリアルを導出して配布し、そして、ＭＳＫ及びＥＭＳＫの鍵更新が必要であるときにＥＡＰ再認証をトリガーする。図２において、アプリケーション１の要素、アプリケーション２の機能Ｘの要素、アプリケーション２の機能Ｙの要素、ＥＡＰピア及びオーセンティケータの下位レイヤは、鍵コンシューマである。

ＥＭＳＫがＥＡＰサーバの外部にエクスポートされることを禁止するＥＡＰ鍵管理フレームワーク ［１８］に適合するために、ネットワークにおけるＵＫＭＦは、ＥＡＰサーバと同じノードに存在することが期待される。
ＥＭＳＫの下の鍵階層は、以下のように、ＵＳＲＫ（用途ルート鍵）に基づいて、［３］で定義される：
ＵＳＲＫ＝ＫＤＦ（ＥＭＳＫ、鍵ラベル｜“＼０”｜オプションデータ｜長さ）。

ＥＡＰベースの統合鍵管理機構において、ＵＳＲＫは、アプリケーションレイヤ暗号化鍵のブートストラッピングのために使用される。同一のＥＭＳＫから導出される異なるアプリケーションレイヤ暗号化キーの間の暗号の独立性は、（ｉ）各々のアプリケーションごとに及び複数の機能を有するアプリケーションごとに、固有のＵＳＲＫラベルを割り当てること、及び、（ｉｉ）アプリケーションの各々の機能ごとに、アプリケーション固有ＵＳＲＫの子供鍵（child key）を定義すること（そこにおいて、各々の子供鍵は、同一のＵＳＲＫ導出アルゴリズムを使用して、しかし、ＥＭＳＫ及びアプリケーション内の固有ラベルの代わりにその親鍵（parent key）を使用して、導出される）によって保証される。ＵＳＲＫ及びその子供鍵の両方について、更なるパラメータ（例えば、鍵識別子及びエンドホストの識別子など）がオプションデータに含まれても良い。ＥＡＰキーイングマテリアル（すなわち、ＭＳＫ及びＥＭＳＫ）から導出される任意の鍵のライフタイムは、ＥＡＰキーイングマテリアルのライフタイムにより制限される。導出された鍵は、そのライフタイムが期限満了になっていない間、その鍵コンシューマにおいてキャッシュされても良い。

ｂ．鍵管理機構選択肢
スマートメータを、例えばイーサネット、ＰＬＣ、ＺｉｇＢｅｅ、Ｗｉ−Ｆｉ及び３ＧのようなＡＭＩネットワークに接続するために使用される幾つかのリンクレイヤ技術が存在するので、ＥＡＰベースの統合鍵管理スキームが、どのようにして、様々な方法でリンクレイヤ固有鍵（link-layer specific keys）を管理し得る様々なリンクレイヤ技術と連携することができるかについて考慮が必要とされる。二つの選択的な方法がある。

第１のアーキテクチャー上の選択肢において、ＥＡＰが、ネットワークアクセス認証及びアプリケーションレイヤ暗号化のブートストラッピングの両方のために使用される。ここで、ＥＡＰは、リンクレイヤ固有ＥＡＰトランスポートを使用してリンクレイヤにおいて又はＰＡＮＡ ［６］を使用してネットワークレイヤにおいて、実行される。ＥＡＰトランスポートとしてＰＡＮＡを使用するリンクレイヤ鍵管理に関して、二つのケースが存在する。
・第１のケースにおいて、リンクレイヤ暗号化は、ＰＡＮＡと独立して、無効化又は有効化されても良い。この場合において、暗号又は非暗号アクセス制御は、ＩＰレイヤ又はより上のレイヤにおいて提供される。暗号アクセス制御の例は、ＩＰｓｅｃである。非暗号アクセス制御の例は、ＳＡＶＩ（ソースアドレス確認改善（Source Address Validation Improvements）） ［２０］である。この場合において、リンクレイヤ暗号化は、リンクレイヤ固有認証及びＥＡＰをサポートしないことが有り得る鍵合意機構（key agreement mechanism）を使用して有効化されても良く、そして、ＵＭＴＳは、すなわち、そのような機構の一つである。ＵＫＭＦは、アプリケーションレイヤ暗号化のための、そして、任意的にＩＰレイヤ暗号化のための、鍵管理の一部であるが、リンクレイヤ暗号化のための鍵管理の一部ではない、という点で、このケースは部分統合モデルに属する。
・第２のケースにおいて、リンクレイヤ暗号化は、ＰＡＮＡを使用してブートされる。そして、そこにおいて、リンクレイヤマスター鍵がＰＡＮＡセキュリティーアソシエーションを使用してリンクの二つのエンドポイントの間でセキュアに確立される。そして、リンクレイヤマスター鍵は、リンクレイヤ暗号化鍵を確立するために、セキュアアソシエーションプロトコルにより使用される。リンクレイヤマスター鍵は、個々の鍵又はリンクレイヤの信用モデル（trust model）に依存するグループ鍵であっても良い。リンクレイヤマスター鍵が個別の鍵であるとき、該鍵は、もっぱら、特定のリンクのエンドポイントの間で使用される。そのような個別の鍵の例は、［２１］におけるＰＥＭＫ（ＰａＣ−ＥＰマスター鍵）である。グループ鍵が使用されるとき、信用モデルは、同一のグループ鍵を所有するすべてのノードが信頼されるものとして考えられることを提供する。グループ鍵を使用する典型的なリンクレイヤ技術は、ＺｉｇＢｅｅ ［８］である。グループ鍵は、一旦、それがネットワークに対して成功裏に認証するならば、各々のノードにセキュアに配送される必要がある。ＰＡＮＡは、グループ鍵配送を保護するために使用されても良い。このケースは、完全統合モデルに属する。

第２のアーキテクチャー上の選択肢において、ＥＡＰは、アプリケーションレイヤ暗号化のブートストラッピングだけのために使用される。ＰＡＮＡが、アプリケーションレベル認証のためのＥＡＰトランスポートとして使用される。ＩＫＥｖ２ ［１９］は、ＵＤＰ上の別のＥＡＰトランスポートであるが、しかしながら、ＩＫＥｖ２は、ハードウェア制約されたデバイスにとって負担である可能性があるＤｉｆｆｉｅ−Ｈｅｉｌｍａｎアルゴリズムを要求するので、ＰＡＮＡは、スマートメータのために好ましい点に留意される。リンクレイヤ又はネットワークレイヤにおけるアクセス制御は、暗号化アプリケーションレイヤのブートストラッピングのために、このＥＡＰと独立して実行されても良い。このアーキテクチャーは、部分統合モデルに属する。このモデルのユースケースの例は、ＡＮＳＩ Ｃ１２．２２ホストとＡＮＳＩ Ｃ１２．２２マスターリレーとの間のＡＮＳＩ Ｃ１２．２２暗号化鍵をブートストラッピングためのものである。ここで、ＡＮＳＩ Ｃ１２．２２ホストは、ＰａＣ（ＰＡＮＡクライアント）であり、ＡＮＳＩ Ｃ１２．２２マスターリレーは、ＰＡＡ（ＰＡＮＡ認証エージェント）である。

ＥＡＰの現在の適用性はネットワークアクセス認証 ［４］のためのものであるので、両方のアーキタクチャー上の選択肢は、アプリケーションレイヤ暗号化をブートするためのアプリケーションレベル認証をサポートするためにＥＡＰ適用性の拡張を要求し得る。他方、ＥＡＰ適用性のそのような拡張は、ＥＡＰ自体の修正を必ずしも要求することなく、可能である。次ののサブセクションは、我々の統合鍵管理機構に適合するためにＥＡＰ適用性を拡張するためにどのような更なる考慮が必要であるかを説明する。

ｃ．アプリケーションレイヤ暗号化のブートストラッピング
ＥＡＰベースの統合鍵管理機構は、アプリケーションレイヤ暗号化のブートストラッピングのために必要な情報を発見することを、エンドホスト用の機構に要求する。
以下の情報が発見される必要がある。
・アプリケーションレイヤ暗号化のブートストラッピングをサポートするＥＡＰオーセンティケータのトランスポート識別子。
・ＥＡＰからのアプリケーションレイヤ暗号化のブートストラッピングをサポートするアプリケーション識別子のセット。
・ＥＡＰからのアプリケーションレイヤ暗号化のブートストラッピングをサポートする各々のアプリケーションごとの、ネットワークにおける（１又は複数の）アプリケーションエンドポイントの識別子。

ｄ．鍵更新アプリケーションレイヤ暗号化鍵
ＥＡＰベースの統合鍵管理機構において、更なる鍵更新機構なしで、ＥＭＳＫから導出されるアプリケーションレイヤ暗号化鍵の鍵更新が、ＥＡＰ再認証を介して実行される。ＥＭＳＫの鍵更新は、それから導出されるすべての鍵を置き換えるあろう。したがって、最適化の観点から、ＥＭＳＫ鍵更新の頻度をできる限り低減できるようにシステムを設計することは望ましい。鍵更新問題に対処するために三つの独立した解決がある。

第１の解決は、ＥＡＰ再認証のために、［２３］の場合のようにＥＲＰ（ＥＡＰ再認証プロトコルのためのＥＡＰ拡張）を使用することである。ＥＲＰはＥＭＳＫの鍵更新なしに動作するので、完全統合モデルが使用され、ネットワークアクセスのためのＥＡＰ再認証が起こるときでさえ、この解決はＥＭＳＫの鍵更新を回避することができる。

第２の解決は、第２の鍵管理選択肢を使用すること（すなわち、アプリケーションレイヤ暗号化のブートストラッピングだけのためにＰＡＮＡにより運ばれるＥＡＰを使用すること）である。ＥＡＰがネットワークアクセスのために使用されず、エンドホストのＩＰアドレス変更に対処するために、ＰＡＮＡがそれ自身のモビリティ管理機構を有するので、エンドホストが、そのネットワーク接続ポイント（network point of attachment）を変更するときに、この解決は、ＥＭＳＫ鍵更新を避けることができる。

第３の解決は、所定のアプリケーションの各々の機能のために、（アプリケーションレイヤ暗号化鍵の単一のセットの代わりに）アプリケーションレイヤ暗号化鍵の複数のセットを生成し、鍵更新が必要なときに、アプリケーションレイヤ暗号化鍵の有効セットを変更することである。例えば、ＡＮＳＩ Ｃ１２．２２は、暗号化鍵の配列を定義する。ここで、鍵ＩＤ又は配列インデックスは、各々のセキュリティー可能メッセージ（security-enabled message）で運ばれ、鍵の変更は、鍵ＩＤ値を変更することによってなされる。鍵配列のサイズは、アプリケーションの特徴に基づいて決められても良い。例えば、アプリケーションのための配列サイズは、それがアプリケーションの平均鍵更新頻度に比例するように、セットされても良い。

ｅ．例示的な先進メータリングインフラストラクチャー（ＡＭＩ）システムアーキテクチャー
図１０は、ＡＭＩシステムの基本的なコンポーネントを示す。コンシューマの住宅に設置されるスマートメータは、メータリングデータをユーティリティオフィス内のメータデータ管理システム（ＭＤＭＳ）へプッシュする；又は、ＭＤＭＳは、メータリングデータをスマートメータからプルする。さらに、スマートメータは、ＭＤＭＳから、又は、ＭＤＭＳを介したデマンドレスポンス管理システム（ＤＲＭＳ）から、デマンドレスポンス（ＤＲ）信号を受信することができる。さらに、スマートメータは、コンシューマのエネルギー使用量を表示するための家庭内ディスプレイ及び家庭におけるエネルギー使用量を調整するためのホームサーバと通信し得る。

スマートメータは、ＤＲ信号及びメータリングデータの交換のために、公共のワイドエリアネットワーク（ＷＡＮ）（それはおそらくインターネットであろう）によって、ＭＤＭＳと通信する。ここでは、ＡＮＳＩ Ｃ１２．２２が、ＭＤＭＳとスマートメータとの間のアプリケーションプロトコルとして考慮される。ＡＮＳＩ Ｃ１２．２２は、セキュリティー機構を提供するが、それには動的鍵管理（鍵更新）機構が欠如している。さらに、ネットワークアクセス認証が、近隣エリアネットワーク（Neighborhood Area Network）（ＮＡＮ）において要求される。これらの要件を満たすために、我々の統合鍵管理機構は、上で示したように第１の構造上の選択肢に基づき図１１で示すように使用されることができる。多数のスマートメータが一つのＮＡＮに帰属され得るので、メータリングデータを収集するためにデータコンセントレータが設置される。この場合において、コンセントレータとスマートメータとの間のＮＡＮのためのネットワークアクセス認証のためにＰＡＮＡが使用される。コンセントレータは、ＡＮＳＩ Ｃ１２．２２リレー及びＰＡＮＡ ＦＡＡとして動作し、スマートメータは、ＡＮＳＩ Ｃ １２．２２ホスト及びＰＡＮＡ ＰａＣとして動作する。

認証及び鍵確立手続きの概略は以下で示される：
１．スマートメータは、ブートストラッピングにおいて、コンセントレータとのＰＡＮＡネゴシエーションを始める。ＥＡＰトランスポートのためにＰＡＮＡが使用される。
２．コンセントレータは、スマートメータとＭＤＭＳとの間でＥＡＰメッセージを中継する。コンセントレータとＭＤＭＳとの間でＥＡＰトランスポートのためにＡＡＡプロトコル（例えば、ＲＡＤＩＵＳ又はＤｉａｍｅｔｅｒ）が使用される。
３．スマートメータは、ＡＮＳＩ Ｃ１２．２２ネットワークに接続するのを許可され、そして、ＡＮＳＩ Ｃ１２．２２暗号化鍵は、ＥＡＰ認証が成功した後に、スマートメータ、コンセントレータ及びＭＤＭＳにより共有される。該鍵は、ＥＡＰ ＥＭＳＫから生成される。
４．ＡＮＳＩ Ｃ１２．２２暗号化鍵の鍵更新が必要なときは、ＡＮＳＩ Ｃ１２．２２暗号化鍵の期限が切れる前に、ＥＡＰ再認証が、ＰＡＮＡ再認証の一部として実行されるであろう。

他方、ＭＤＭＳ及びスマートメータがコンセントレータなしで直接通信するモデルもまた考慮されることができる。このモデルは、非コンセントレータモデルと呼ばれる。非コンセントレータモデルは、一般的に、少数のスマートメータをもつＮＡＮのために使用される。

認証の概略とこのモデルの鍵確立手続きは、以下の通りである：
１．スマートメータは、ブートストラッピングにおいて、ＭＤＭＳとのＰＡＮＡネゴシエーションを始める。ＥＡＰトランスポートのためにＰＡＮＡが使用される。
２．スマートメータは、ＥＡＰ認証が成功した後に、ＭＤＭＳと、ＡＮＳＩ Ｃ１２．２２暗号化鍵を共有する。該鍵は、ＥＡＰ ＥＭＳＫから生成される。
３．ＡＮＳＩ Ｃ １２．２２暗号化鍵の鍵更新が必要なときは、ＡＮＳＩ Ｃ １２．２２暗号化鍵の期限が切れる前に、ＥＡＰ再認証が、ＰＡＮＡ再認証の一部として実行されるであろう。

統合鍵管理機構は、東芝マイクロプロセッサＴＬＣＳ−９００をもつ組み込みデバイス上のＥＡＰ及びＰＡＮＡとして実装されても良い。ＰＡＮＡ及びＥＡＰ実装のフットプリント（footprint）は、３０ＫＢ未満であっても良い。それは、提案された統合鍵管理機構のＥＡＰ及びＥＡＰ下位レイヤ部分が上で説明される要件を満たすことを示す。

統合鍵管理機構…それは単一のピアエンティティー認証の試行から複数の通信レイヤの複数のプロトコルのために暗号化鍵を生成することができる…は、特にスマートメータリング（ここでは、スマートメータが各々のプロトコルについてピアエンティティー認証の試行を反復することが負担である可能性がある低コスト無線デバイスであると仮定される）のためのスマートグリッドのユースケースに適している。ピアエンティティー認証がネットワークアクセス認証又はアプリケーションレベル認証であることができるという点で、上述の機構は柔軟である。上で考慮されたＥＡＰベースの統合鍵管理機構に関する詳細は、ＥＡＰが既存のリンクレイヤ技術のために広く使用されており、そして、ＥＭＳＫからブートされる暗号化鍵の鍵更新効率を考慮することは重要であることを示す。

さらにまた、統合鍵管理機構は、商用のマイクロプロセッサ上のＥＡＰ及びＰＡＮＡに関する予備的なインプリメーテーションの実績により、アプリケーションレベル認証だけでなくネットワークアクセス認証のために、ＡＮＳＩ Ｃ１２．２２ベースのスマートメータリングアプリケーション及びＰＡＮＡと統合される。今後、ＥＶ（電気自動車）がスマートグリッドのコンポーネントとして考えられる。

本発明の幅広い範囲
本発明の例示的な実施形態が本明細書で説明されたが、本発明は、本明細書で説明される様々な好ましい実施形態に制限されず、本開示に基づき等業者により認識されるであろう等価な要素、変形、省略、（例えば、様々な実施形態にわたる態様の）組み合せ、脚色適応及び／又は改変を有する任意の又はすべての実施形態を含む。特許請求の範囲における制限（例えば後で加えられるものを含む）は、特許請求の範囲で使用される言語に基づいて幅広く解釈されるべきであり、そして、本明細書において又は出願の手続き追行の間に説明される例に制限されず、それは非排他的であるものとして解釈されるべきである。例えば、本開示おいて、用語「望ましくは（preferably）」は、非排他的であり、「望ましくは、しかし、制限されない（preferably, but not limited to）」を意味する。この開示において、そして、この出願の手続き追行の間、ミーンズプラスファンクション又はステッププラスファンクションの制限は、特定の請求項の制限について、以下の状況のすべてがその制限内に存在する場合にだけ使用される：ａ）「ための手段」又は「ためのステップ」が明示的に記載されている；ｂ）対応する機能が明示的に記載されている；そして、ｃ）構造、材料又はその構造をサポートする動作が記載されていない。この開示において、そして、この出願の手続き追行の間、用語「本発明」又は「発明」は、本開示の中の１又は複数の態様への参照として使用され得る。言語本発明又は発明は、臨界の識別として不適当に解釈されてはならず、すべての態様又は実施形態にわたってあてはまることと不適当に解釈されてはならなず（すなわち、本発明は多数の態様及び実施形態を有することが理解されるべきであり）、また、本出願又は請求項の範囲を制限するように不適当に解釈されてはならない。この開示において、そして、この出願の手続き追行の間、用語「実施形態」は、任意の態様、特徴、プロセス又はステップ、その任意の組み合せ、及び／又はその任意の部分などを説明するのに用いられることができる。幾つかの例において、様々な実施形態は、重複する特徴を含み得る。この開示において、以下の省略された用語が使用され得る：「例えば（for example）」を意味する「e.g.」。

Claims (15)

1. 通信デバイスのための鍵更新方法において、
   二つ以上の用途鍵配列を、一つのマスター鍵から導出する鍵制御機構を提供するように、マイクロプロセッサを設定することと、
   同一のアプリケーションにおける二つ以上の用途のそれぞれが異なる用途鍵配列を使用するように、前記同一のアプリケーションにおける前記二つ以上の用途のうちの一つについて前記二つ以上の用途鍵配列のうちの一つを使用し、前記同一のアプリケーションにおける前記二つ以上の用途のうちの他の一つについて前記二つ以上の用途鍵配列のうちの他の一つを使用することと、
   唯一の用途を有するアプリケーションについて一つの用途鍵配列を使用することを含み、
   前記用途鍵配列は、暗号的に互いに独立している同一の用途の二つ以上の用途鍵を含む方法。
2. 前記鍵制御機構は、各アプリケーション毎に、一つのアプリケーションマスター鍵を一つのマスター鍵から導出し、該アプリケーションマスター鍵から前記鍵配列を導出する、請求項１の方法。
3. 同一時刻において前記鍵配列内の唯一つの用途鍵が有効であり、
   前記鍵制御機構は、有効な用途鍵の鍵更新が必要である場合に、該有効な用途鍵に対応する配列インデックス値を、使用済みとして記憶し、前記鍵配列から未使用の用途鍵の一つを新たな有効な用途鍵として使用する、請求項２の方法。
4. 前記鍵制御機構は、記憶された前記配列インデックス値に１を加えた値に等しいインデックス値を有する用途鍵を、新たな有効な用途鍵として使用する、請求項３の方法。
5. 前記鍵制御機構は、前記鍵配列の配列サイズを、前記用途鍵の更新の頻度に比例する値に設定する、請求項１の方法。
6. 前記鍵制御機構は、前記用途鍵を使用する前記アプリケーションの制御メッセージを用いてネゴシエーションすることによって、前記鍵配列の配列サイズを決定する、請求項１の方法。
7. 前記アプリケーションのメッセージのそれぞれは、暗号化に使用される前記用途鍵に対応する配列インデックス値を含む、請求項１の方法。
8. 前記鍵制御機構は、有効な用途鍵の鍵更新が必要である場合に、新たな有効な用途鍵の配列インデックス値を含むアプリケーションメッセージによって、対向するエンティティーに鍵更新を通知する、請求項７の方法。
9. 前記鍵制御機構は、有効な用途鍵が鍵更新をする必要がある場合に、新たな有効な用途鍵の配列インデックス値を含む制御メッセージによって、対向するエンティティーに鍵更新を通知する、請求項７の方法。
10. 前記通信デバイスは、スマートメータである、請求項１の方法。
11. 前記スマートメータは、電気自動車、家庭電器、フォトボルタイクス用装置、充電式バッテリー又は他のデバイスの使用に関するメータリングのためである、請求項１０の方法。
12. 前記スマートメータは、消費量又は使用情報を計測し、通信ネットワークを介してその情報を監視及び請求書作成のためにプロバイダーへ伝える、請求項１１の方法。
13. パワーグリッドネットワーク中に分散されるリレーに接続される複数のメータリングデバイスからデータを受信するように構成される通信デバイスにおいて、
    マイクロプロセッサを含み、
    前記マイクロプロセッサは、
    二つ以上の用途鍵配列を、一つのマスター鍵から導出する鍵制御機構を実行し、
    前記用途鍵配列は、暗号的に互いに独立している同一の用途の二つ以上の用途鍵を含み、
    同一のアプリケーションにおける二つ以上の用途のそれぞれが異なる用途鍵配列を使用するように、前記同一のアプリケーションにおける前記二つ以上の用途のうちの一つについて前記二つ以上の用途鍵配列のうちの一つを使用し、前記同一のアプリケーションにおける前記二つ以上の用途のうちの他の一つについて前記二つ以上の用途鍵配列のうちの他の一つを使用し、
    唯一の用途を有するアプリケーションについて一つの用途鍵配列を使用するように、設定される、
    通信デバイス。
14. 前記デバイスは、メータデータ管理サーバである、請求項１３の通信デバイス。
15. 前記複数のメータリングデバイスのそれぞれは、電気自動車、家庭電器、フォトボルタイクス用装置、充電式バッテリー又は他のデバイスの使用に関するメータリングためのスマートメータである、請求項１３の通信デバイス。

Images