セキュアテレメトリックリンク
通信プロトコルを使用して、データプライバシー、メッセージの完全性、メッセージの新しさ、及びユーザ認証を、特に、ボディエリアネットワークの埋め込み可能医療デバイスへのテレメトリックトラフィック、及び、ボディエリアネットワークの埋め込み可能医療デバイスからのテレメトリックトラフィックに提供する。暗号化、メッセージの完全性、及びメッセージの新しさは、デバイス識別番号及び疑似乱数から導出されたトークンのようなノンス及びエフェメラルセッションキーの使用を通じて提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ通信設定においてセキュア通信を提供することに関し、特に、埋め込み可能医療デバイスと外部デバイス管理ハードウェアとの間のテレメトリーにおけるセキュリティ、埋め込み可能医療デバイスと他の埋め込み可能医療デバイスとの間のテレメトリーにおけるセキュリティ、及び外部医療デバイスと他の外部医療デバイスとの間のテレメトリーにおけるセキュリティの提供においてセキュアな通信を提供することに関する。
【背景技術】
【０００２】
埋め込み可能医療デバイス（「ＩＭＤ」）に関する技術の改良、特に、電力貯蔵、保全、及び小型化の分野におけるＩＭＤに関する技術の改良によって、現代の埋め込み可能医療デバイスには無線電気通信機能を装備することが可能になっている。このような通信の利益には、たとえばバッテリー寿命の残量、発生した治療イベント数、又は特定の患者の健康データといった情報を送信するようにＩＭＤに要求する能力、及び、治療法、治療頻度等を変更する命令をデバイスへ送信する能力が含まれる。これらの通信のすべては、患者の健康及び治療成果を最大にするすべての関係者側の必要性によって動機付けられており、この成功の判断基準の一環として、ＩＭＤを患者から除去しなければならない状況又は患者に関する何らかの侵襲的な処置が必要となる状況を回避するという要望によっても後押しされている。何らかの外科的又は侵襲的な処置に伴う危険に付随するものは、適用可能な標準治療（standard of care）に従ってこのような処置が行われるとき、このような処置に関連付けられるコストである。
【０００３】
ＩＭＤを患者内に残している間、ＩＭＤと通信する利益を利用する際に、無線通信が、理想的には適しており、現在まで、ＩＭＤがその埋め込まれた状態にある間にＩＭＤと情報を定期的に交換する唯一の実用的な方法である。したがって、通信が、ＩＭＤ若しくは管理デバイスへ又はＩＭＤ若しくは管理デバイスから送信されているか否かにかかわらず、さらに、（たとえば、更新された命令がＩＭＤへ送信されることとは対照的に）測定値が送信されているか否かにかかわらず、ＩＭＤ管理のために電気通信を使用することには、ＩＭＤへの通信及びＩＭＤからの通信、或いは、体外（すなわち、埋め込まれていない）ＩＭＤ管理デバイス間の通信（本明細書では、交互に「テレメトリー」と総称する）が含まれ得る。
【０００４】
テレメトリー、特にＩＭＤテレメトリーは、病状又は他の健康状態の治療をより便利且つ効果的にすることができるが、テレメトリーを使用することによって、第三者がこのようなデバイスの管理に干渉できないように保証することが重要である。たとえば、盗聴のみであっても、たとえば医療保険のプライバシー及び説明責任に関する法律（「ＨＩＰＡＡ」）といった特定のデータプライバシー制度のもとで保護され得る患者データを危険にさらすおそれがある。さらに危ういことには、管理デバイスから医療デバイスへのテレメトリー通信が干渉を受ける場合、意図されていた重要な療法が、埋め込みデバイスをホスティング（hosting）している患者に対して施されないおそれがあり、その結果、おそらく、治療効果は準最適なものになる。悪意のある第三者が、通信をインターセプトして、その通信を、デバイスへの偽の命令に置き換えた場合、又は、正当な命令であってもそれを繰り返して、正しくない療法若しくは過度の療法を埋め込み物に施させた場合には、埋め込み物のホストに対して悪影響を与えるおそれがある。
【０００５】
現在まで、ＩＭＤテレメトリーの用途に適したほとんどの一般的な無線通信プロトコルは、方向性を有するプロトコルではなく、「ブロードキャスト」のプロトコルである。したがって、ＩＭＤがテレメトリー信号の範囲内にある（又は、通信がＩＭＤから開始されたときは、受信デバイスがＩＭＤの範囲内にある）場合、その信号へのアクセスが介護人及び／又は患者によって意図されたものであろうとなかろうと、その信号の範囲内にあるいずれの受信デバイスも、その信号にアクセスできると一般に想定することができる。
【０００６】
ＩＭＤを伴う多くのテレメトリートランザクションの距離範囲が短いことによって、或る程度、或る種の物理レイヤ認証は達成されている。換言すれば、認可されていない関係者が送信デバイスの非常に近くにいなければならないことから、盗聴者（又は盗聴者のツール）の物理的な存在は、このような情報を正当に送信又は受信する関係者に視覚的にはっきりと見えることになるので、ＩＭＤに関係する通信へのほとんどの不正アクセスは実現不可能である。しかしながら、テレメトリーの適用の範囲は絶えず拡大しており、或る段階で、たとえば、患者が医師待合室に腰掛けている間、対象とする受信デバイスが完全に別の部屋にあっても、ＩＭＤにインターロゲートすることが考えられ得る。ＩＭＤと外部ハードウェアとの間の通信に必要な距離が大きくなるにつれて、侵入者又は盗聴者が、通信信号の受信、通信信号への干渉、さらには通信信号の操作を行う機会も多くなる。
【０００７】
また、メッセージが「新鮮」であることも重要である。すなわち、メッセージが、近時において一度しか送信されていないことも重要である。たとえば、療法が適用されているにもかかわらず、患者の生理的状態の変化がないことを偽って示す診断センサからのデータの複製通信の結果、療法が過度になるか、又は付帯リスクを有する他の不要な医療介入が行われるおそれがある。メッセージプライバシー（すなわち、暗号化）に加えて、真のデータセキュリティには、メッセージの完全性及びメッセージの新しさ（message freshness）の双方も必要とされる。３つのすべてがなければ、悪意のある第三者によって悪用されるおそれのある隙間が存在するか、又はさらには、悪意がなくてもエラーを許容するおそれのある隙間が存在する。もちろん、このような悪用が起こり得るか否かは、特に設計の立場から関連はない。テレメトリーのセキュリティは、検討されているインターセプトのシナリオから生じる問題の実際の可能性に関係なく、あらゆる盗聴又はインターセプトを防止するように保証されるべきである。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
テレメトリーセキュリティに対するこれまでの手法は、たとえば、サーバベースの認証及びストレージを伴っていた。このように、永久的なキー情報が、機器上に記憶されることはなかった。しかしながら、この手法では、２４時間利用可能なサーバへのセキュアな通信チャネルが必要とされる。また、この手法では、臨床医は、ボディエリアネットワーク（ＢＡＮ）デバイス又はノードを管理するよりも前に、サーバシステムに対して認証を受ける必要がある。
【０００９】
代替的に、バイオメトリックトークン（キーフォブ（key fob）等）が、ＩＭＤサポート機器をＩＭＤに対して認証するのに使用されてきた。しかしながら、この手法によって認証キー（バイオメトリックキー及びＩＭＤキーの双方）が喪失されやすく、トークンも、ＩＭＤ管理を行うために提示する患者によって忘れられる可能性があり、これによって、不都合なことに、ケアの延期が必要となりがちである。パスワードによって増強されたトークンも、同様に、喪失されやすく、ノンコンプライアンス（トークンを予約に持ってこない、又は、認証情報を忘れる）を受けやすく、同様に、喪失又は盗難にあった場合に、危険にさらされやすかった。
【課題を解決するための手段】
【００１０】
本発明は、特にＩＭＤ及び他の医療デバイスの管理に良く適したテレメトリー通信のセキュアシステムを提供する。ＩＭＤへの通信及びＩＭＤからの通信、並びに、外部デバイスへの通信及び外部デバイスからの通信を保護するシステムが提供される。このシステムは、通信ノードへの通信及び通信ノードからの通信、特にＩＭＤへの通信及びＩＭＤからの通信が正当なものであることを保証するために、１つ又は複数の認証方法と共に、暗号化のシステムを実施する。特定の実施の形態では、たとえば、データ暗号化及びキー管理の厳格な手法によって、正当性が保証され、好ましくは、認証は、認証カード又はトークンを保持することに加えて、少なくとも１つのモダリティを使用してセキュアにされる。
【００１１】
特定の実施の形態では、本発明は、近接性に依存した「バックドア」を提供する。当該バックドアは、特定の患者の医療デバイスのネットワーク内のノード間又はモジュール間の通信を可能にするのに通常必要とされる認証情報なしで任意のＩＭＤへのアクセス及びその管理を可能にすることができる。医療デバイスのネットワークは、「ボディエリアネットワーク」又は「ＢＡＮ」と呼ばれる。また、本発明は、いくつかの実施の形態では、認証が、認証情報を実際に送信する（もちろん、認証情報が危険にさらされやすくなるおそれがある）ことなく実行されるという点で、厳密認証、すなわち、同一性のゼロ知識証明も提供する。
【００１２】
患者及び認可された介護人に反する興味又は動機を有する、認可されていない第三者は、盗聴者の素性、ロケーション、又は動機にかかわらず、本明細書では、「攻撃者」と総称される。攻撃者は、通信を実際に混乱させることなく単に盗聴することを望む場合もあるし、場合によっては患者に関する保護されている健康情報を取得することを望む場合もあるし、ＢＡＮノード製造者に独自のＢＡＮノードの振る舞いの態様を知りたい場合もある。これらの目的のために、本発明の実施の形態は、暗号の使用を通じてメッセージプライバシー（すなわち、暗号化）を提供する。
【００１３】
十分な電気通信能力及び計算能力を有する攻撃者は、ＢＡＮのノード間のすべての通信をインターセプトして制御し、ＢＡＮのノード間のメッセージの削除、変更、複製、又は別の変更のいずれかを行うことができる場合があることも考えられ得る。本発明の実施の形態は、たとえばＩＭＤへの命令及びＩＭＤによって診断ノードに提供される情報が正当なものであることを保証するメッセージ認証プロトコルの使用を通じて、メッセージの完全性（すなわち、メッセージ認証）を提供する。同様に、新しく生成されたセッションキー及びトークンベースのシステムを通じて、又は、本発明の代替的な実施の形態ではタイムスタンプの使用を通じて、メッセージの新しさを保証することもできる。本発明は、特定の実施の形態では、メッセージの完全性（送信されたメッセージが、それらのメッセージが対象とする受信者によって、変更されていない状態で受信される）及びメッセージの新しさ（メッセージが、タイムリーに受信され、且つ、攻撃者によって送信された、前に送信されたメッセージのコピーではない）という補助的な要請に基づいて、メッセージが、秘密キーを有しない者からセキュアに維持されることを可能にする。
【００１４】
本発明の実施の形態によって与えられる保護にもかかわらず、通信の保護は、好ましくは、最適な患者ケアという全体的な原則によって動機づけられ、且つ、必要な場合には、その全体的な原則を補助する。したがって、本発明の特定の実施の形態は、特定の緊急事態又は他の強制的な状況において、健康への不利な影響を防ぐために、緊急事態介護人がデバイスに対して自身を認証する時間又は証明書を有するか否かにかかわらず、この実施態様の特定のセキュリティの機能を迂回するデバイスに対して、「バックドア」によるデバイスとの通信を許可することができる。
【００１５】
本発明の実施の形態によるセキュリティメカニズム及びプロトコルは、セキュリティサービスがセットアップされて、通信デバイスのうちの少なくとも１つに関して（迂回されるのではなく）有効にされていることを必要とし、ブロック暗号の一実施態様の使用をさらに必要とする場合がある。他の実施の形態では、本発明を実施するＢＡＮのすべての通信デバイスは、同一のボディエリアネットワークキーＫＢＡＮを共有し、新しい各テレメトリーセッションの開始時に新しいセッションキーＫｓｅｓを協同して生成する。最初に、このようなデバイス識別情報交換が、通信セッションをオープンするために必要とされるセキュアにされていない交換を介して行われる。着信するパケット及び発信するパケットの双方のパケット長は、好ましくは、セッションの継続時間の間固定され、指定された長さに合致しないパケットは、好ましくは、ネットワークの物理レイヤにおいて拒絶される。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態によるボディエリアネットワークの一般的なネットワークトポロジを示す図である。
【図２】本発明の実施形態によるネットワークノード間のネットワークキーのセキュアな送信のプロトコルを示す図である。
【図３】ネットワークキー送信プロトコルの一代替的な実施形態を示す図である。
【図４】本発明の一実施形態による２つの体外デバイスを有するボディエリアネットワークのトポグラフィを示す図である。
【図５】本発明によるネットワークキー伝播プロトコルの一代替的な実施形態を示す図である。
【図６】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図７】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図８】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図９】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図１０】本発明の実施形態によるセッションキーの生成のデータフロー図である。
【図１１】本発明の実施形態によるメッセージのＣＴＲモードの暗号化及び解読のデータフローを示す図である。
【図１２】本発明の実施形態によるノンスレジスタのデータ構造を示す図である。
【図１３】本発明の一実施形態によるテレメトリーパケットのデータ構造を示す図である。
【図１４】本発明の一実施形態によるメッセージの暗号化／解読及び認証のデータフローを示す図である。
【図１５】本発明の一実施形態による概略的なハードウェアアーキテクチャを示す図である。
【図１６】本発明の一実施形態の緊急事態アクセスプロトコルのネットワークトポグラフィを示す図である。
【図１７】本発明の一実施形態による緊急事態アクセスプロトコルの疑似プロトコル及びデータフローを示す図である。
【図１８】セキュアにされたウェイクアップパケットのグラフィカル表現を示す図である。
【図１９】セキュアにされたウェイクアップパケットのＭＡＣの生成を示すブロック図である。
【図２０】セキュアにされたウェイクアップパケットを送受信するプロセスのフローチャートである。
【図２１】セキュアにされたウェイクアップパケットを送受信するプロセスのフローチャートである。
【発明を実施するための形態】
【００１７】
本発明による無線ネットワークの一セキュリティ実施様態の実施形態は、さまざまな層のセキュリティ又はさまざまな度合いの多要素認証を実施することができる。本明細書で検討されるこれらのセキュリティの層は、たとえば、通常、入出力ファシリティ（たとえば、ポート）、１つ又は複数の中央処理装置（チップ等）、及び複数のメモリロケーションを有するスマートカード、すなわち小さなプラスチックカード又はフォブによって実施することができる。スマートカード技術は、「ユーザが有する物（something the user has）」レベルのセキュリティとして、単独で機能することによるか、又は、たとえば「ユーザが知っている物（something the user knows）」（すなわち、パスワード）若しくは「ユーザである物（something the user is）」（すなわち、ユーザに関連付けられたバイオメトリックパラメータ）と結び付けられた多要素認証のコンポーネントとして機能することによるかのいずれかで、セキュリティを実施するのに使用することができる。本発明に従って実施されるようなカードは、好ましくは、時に「プロセッサカード」又は「マイクロプロセッサ多機能カード」と呼ばれるタイプのメモリ、少なくとも１つのプロセッサ、及びデータ処理機能を有する。これらのカードは、好ましくは、国際標準化機構の、電気接点を有する集積回路カード（Integrated Circuit Cards with Electrical Contact）の標準規格ＩＳＯ７８１６で指定されたタイプのものとすることができ、この仮定は、本明細書の代表的な実施形態に関してなされる。特定の実施形態では、特定の患者認証は、スマートカードデバイスを介して管理されるが、しかしながら、ＩＭＤのデバイスキーは、好ましくは、暗号化されていない形ではスマートカード上に記憶されない。
【００１８】
本発明のいくつかの実施形態は、本明細書で、テレメトリー通信のタイムライン、すなわち、テレメトリー通信の「新しさ」として知られているものの確証を提供する。たとえば、一度正当に規制することができる治療法（therapeutic modality）は、悪意のある第三者によって繰り返し可能なものであってはならない。第三者が、単なる暗号化のみに基づいた通信を盗聴できる場合、その第三者は、その命令を反復して繰り返すことができる。悪意のある第三者が、たとえＩＭＤへのメッセージの内容を知らない場合であっても、第三者は、このメッセージを繰り返すことが患者のためにならないことを合理的に予測することができる。第三者は、十分な試行錯誤によって、メッセージの内容を完全に無視してでも危険な影響を実施するおそれがある。したがって、本発明の実施形態は、メッセージの新しさを保証してこのような攻撃を防止するシステムも達成する。本明細書では、「暗号化された」及び「セキュアにされた」という用語は、一般に同義ではないことが理解されよう。暗号化されたメッセージは、プライバシー（すなわち、機密性）のみが保証されているメッセージである。セキュアにされたメッセージは、プライバシー、完全性、新しさ、及び同一性が保証されているメッセージである。この後者の概念は、ユーザ認証（メッセージが、それを明らかに送信した人（又はノード）から実際に来たものである）及びメッセージ認証（メッセージが、送信者によって送信された形態を有し、且つ、正当な送信者によって意図された時刻にのみに送信されたものであり、それ以外の時に送信されていないもの）の双方の認証の概念を組み込んでいる。
【００１９】
本明細書では、通信を送信又は受信するノード（すなわち、医療デバイスの文脈では、埋め込まれたデバイス若しくは外部のデバイス、センサ、プログラマ、モニタ、又はＢＡＮ内の他の器具）を暗号学の慣習に従って「アリス（Alice）」又は「ボブ（Bob）」と呼ぶ場合がある。デバイスのユーザ又は患者について明示的に述べていない限り（たとえば、アリスの患者又は「ホスト」、すなわち、アリスデバイスを埋め込まれている患者）、アリス又はボブはデバイス又はノードを指す。また、特定の実施形態では、スマートカードが、信頼される第三者認証局に通常関連付けられているいくつかの機能を実行でき、カードの保持者による（たとえば、保持者のパスワード及びバイオメトリック認証による）認証時に、カードが、システム内の信頼される関係者とみなされ、カードの保持者のＩＭＤに対応するＩＭＤキーを保持するという点で、スマートカード（スマートカードリーダ／ライタに挿入されている時のスマートカードを含む）という用語を使用する。システムの認可されたアドミニストレータ又はユーザがメッセージの送信又は受信を可能にすることを意図していない第三者（又は、このような人物の制御下にあるデバイス）は、一般に、「攻撃者」と呼ばれる。また、暗号学と一致して、ビット単位の排他的論理和演算（すなわち、ビット単位のモジュロ２加算）については、シンボル
【００２０】
【数１】
又は「ＸＯＲ」を使用し、連結については、シンボル｜又は‖を使用する。本明細書ではしばしば、ソフトウェア又はハードウェアが、感覚のあるエージェントであることを示唆しているように思われるよう、特定のソフトウェアプロセス又はハードウェアコンポーネントは、特定の情報を「知っている」、「要求する」、「予測する」、若しくは「送信する」、又は、特定の機能若しくはアクティビティを実行する（たとえば「計算する」）として説明される。このような擬人化した言及は、問題となっているハードウェア又はソフトウェアが意識、動機、又は知性（人工的又はそれ以外）を有することを示すか又は暗に意味することを意図するものではなく、これらの表現は、一般に、人間であろうが、又は他のハードウェア若しくはソフトウェアのプロセス若しくはコンポーネントであろうが、それによってプログラミング又は命令された通りにソフトウェア又はハードウェアが自動的に挙動することを示すのに使用されることが、当業者には理解されよう。たとえば、特定の値を「予測する」と言われるソフトウェアプロセスは、規則に従わない引数がエラーハンドリングコードによって処理される、特定の変数タイプ又は値であるように指定された引数を有するソフトウェア関数を指す場合がある。
【００２１】
図１は、本発明の実施形態によるボディエリアネットワークのトポグラフィを示している。プログラマ「ボブ」１１０及びＩＭＤ「アリス」１１５から成る一例示のボディエリアネットワーク（ＢＡＮ）１００が示されている。これらの２つのノード、アリス及びボブは、非セキュアチャネル１２０を介して非セキュアテレメトリーセッション１１７をすでに確立している。プログラマ１１０は、認証デバイス１３０との（たとえば、有線接続１２５を介した）セキュア通信用に接続されている。認証デバイス１３０は、ここでは、バイオメトリック入力窓１３５を有するスマートカードリーダ／ライタである。これらの実施形態によれば、本明細書でより十分に説明するように、各場合において、患者によって携行されてＩＭＤ管理で使用されるスマートカードに基づき、セキュリティの増大する順に、以下の情報を認証データとして使用することができる。
【００２２】
本発明の典型的な実施形態では、最低でも、デバイスの患者（又は、適用可能な場合には、他の認可されたアドミニストレータ）が、ＫｄｅｖＡ（デバイス１１５用のキー）、ＩＤＡ（デバイス１１５用の識別番号）として注記される情報を含むスマートカード１４０（患者が有する物）を提示する。さらなるセキュリティは、患者のスマートカード１４０にパスワードＫＰＷ１５０を加えたもの、すなわち、本明細書でＥ（ＫｄｅｖＡ；ＫＰＷ）、ＩＤＡとして注記されるものを使用することによって提供することができる。パスワードＫＰＷ１５０（患者が有する物であり、且つ、患者が知っている物）も、スマートカード素子１４５上に記憶されている。Ｅ（ＫｄｅｖＡ；ＫＰＷ）は、すなわち、デバイスキーＫｄｅｖＡがパスワードＫＰＷ（すなわち「パスワードキー」）によって暗号化されたものである。ここで、Ｅ（ｘ；ｙ）は、キー「ｙ」を使用して「ｘ」をセキュアにするのに使用される暗号化の関数を示し、別の言い方をすれば、特定の暗号文＝Ｅ（平文；キー）を示す。特定の実施形態では、ユーザの認証は、患者のスマートカード１４０又は非電子的な情報カードに、パスワードＫＰＷ１５０を加え、バイオメトリックスキャンＫｂｉｏ、すなわち「バイオメトリックキー」１５５（患者が有する物であり、知っている物であり、且つ、患者である物）を加えたもの、すなわち、本明細書でＥ（Ｅ（ＫｄｅｖＡ；ＫＰＷ）；ＫｂｉО）、ＩＤＡとして注記されるもの、によって実行される。
【００２３】
図１に示すように、アリスの患者（図示せず）には、スマートカードデバイス１４０が提供されている。スマートカードデバイス１４０は、メモリ、ファームウェア、ローカルストレージ、及び／又は組み合わせ素子１４５を含む。アリスの患者は、スマートカード１４０をパスワード１５０及び患者のバイオメトリック特徴で初期化している。患者のバイオメトリック特徴は、ここでは、指紋１５５である。
【００２４】
本発明の特定の実施形態では、スマートカード１４０、又は、スマートカードリーダ１３０若しくはオンボードプログラマノード１１０に取って代わる或るインターフェースとインターフェースするＵＳＢ／Ｆｉｒｅｗｉｒｅ（登録商標）キーフォブを利用して、本明細書のセキュリティ方式の態様を実施することができる。特定の実施形態では、このようなスマートカード又はキーフォブは、すでに実施され且つスマートカード１４０又はキーフォブに実装された、特定の暗号及びメッセージ認証コード（ＭＡＣ）、たとえばチップハードウェアに実施された暗号及びメッセージ認証コード（ＭＡＣ）、又は代替的に、ＲＯＭ又はフラッシュメモリに記憶されている暗号及びメッセージ認証コード（ＭＡＣ）を有し、これらは、スマートカード又はキーフォブ上の素子１４５として抽象的に示されている。
【００２５】
ＩＭＤを含むＢＡＮをセットアップ又は初期化して、上述したプロトコルに従ってＢＡＮキーを伝播するときに、まず、患者は、自身のＩＭＤの認証マテリアル（たとえば、スマートカード１４０）をブリッジデバイス１１０に提供する。このスマートカード１４０は、たとえば、ＩＭＤ１１５と共に発行する（且つ、術後に患者に与える）こともできるし、前もって存在する患者のスマートカードデバイス１４０上に必要な情報を入力することもできる。特定の実施形態では、患者は、自身のスマートカード１４０を（ここでは、インターフェースデバイス１３０を介して）ブリッジデバイス１１０内に挿入した後、自身のパーソナルパスワードＫｐｗ１５０をブリッジデバイス１１０内に入力するように促され（プログラマ１１０に実装されて存在するＧＵＩを介して、又は、適切な別個のインターフェースを介して、理想的には、患者自身のパーソナルメモリから入力される）、さらに、指紋１５５又は網膜スキャン等、患者の一意のバイオメトリック識別子から導出された値であるバイオメトリックキーＫｂｉｏを提示する。ブリッジデバイス１１０は、好ましくは、Ｋｐｗ１５０及び／又はＫｂｉｏ１５５をしばらくの間記憶することなく、スマートカードリーダ１３０を介してパーソナルパスワードＫｐｗ１５０及びバイオメトリックキーＫｂｉｏ１５５をスマートカード１４０に引き渡す。スマートカード１４０は、Ｋｐｗ１５０及びＫｂｉｏ１５５を使用して、ＫｄｅｖＡ１７０を解読することができる（すなわち、スマートカードは、Ｋｐｗ１５０及びＫｂｉｏ１５５を使用して、ＫｄｅｖＡ１７０を求めることができる）。特定の実施形態では、認証が完了するまで、暗号化されていないＫｄｅｖＡ１７０が、当初、スマートカード１４０のＲＡＭ若しくは他のメモリ又はストレージ素子１４５に存在する場合がある。認証が行われると、好ましくは、ＫｄｅｖＡ１７０は、その後、削除され、ＫｄｅｖＡ１７０の暗号化された形態に置き換えられる。代替的に、スマートカード１４０の代わりに非電子的な認証マテリアルを、ＩＭＤのＫｄｅｖＡがテキスト又はバーコードの形態で印刷された非電子的カードの形態でブリッジデバイス１１０に提供することができる。ＩＭＤのＫｄｅｖＡは、ＢＡＮによって、図３のプロトコルに従い伝播される。
【００２６】
本発明のこの実施形態のキー配信プロトコルは、ＩＭＤからブリッジデバイスへの現在のＢＡＮキーのセキュア無線配信、及びブリッジデバイスからＩＭＤへの現在のＢＡＮキーのセキュア無線配信を、もっぱら患者のＢＡＮ内において提供する。このプロトコルは、さらに、ＢＡＮキーそのものだけでなく、送信者及び受信者の認証及び検証も実行する。その上、本発明は、スマートカード１４０が通信に利用可能であることが必要条件であるために、攻撃者が、攻撃者のＢＡＮ内へデバイスを組み入れたり、ＢＡＮキーの配信中にデバイスになりすましたり、配信プロセスそのものを盗聴したり、以前の通信の複製に基づいて反復攻撃を企てたりすることも防止する。好ましくは、ＫｄｅｖＡキーは、ブリッジデバイス１１０上ではなく、スマートカード１４０上にセキュアに留まる。したがって、たとえブリッジデバイス１１０が攻撃者に盗まれた場合であっても、攻撃者は、デバイスキーＫｄｅｖＡを知ることは決してない。本明細書で一般にＫｄｅｖＸ（ＫｄｅｖＡ１７０等）として示されるデバイスキーは、好ましくは、アリス１１５等の埋め込みデバイスに関しては工場でプログラミングされ、ブリッジデバイス１１０、スマートローカルデバイス、及びダムローカル（dumb-local）デバイスに関しても同様に工場でプログラミングすることができる。これらの後者のデバイスは、外部でラベル付けされたＫｄｅｖを有することもできるし、必要に応じて生成されて割り当てられた乱数Ｋｄｅｖを有することもできる。ダムローカルデバイスの限界のために（特に、ダムローカルデバイスがヒューマンインターフェースを有しないという点で）、このようなデバイスは、好ましくは、工場で割り当てられて外部でラベル付けされたＫｄｅｖＸを有する。代替的に、本明細書で説明する、工場で割り当てられる実施態様又は工場でプログラミングされる実施態様のいずれも、通常の「ファームウェアアップグレード」手順を介したフラッシュメモリの更新に付随して供給されるＫｄｅｖＸ又は類似の情報を代わりに有することができる。本明細書では、異なるキー値及び他の変数を指定するのに、次の省略形が使用される。ＫｄｅｖＸは、Ｘの名称を有する指定されたノードの秘密デバイスキーである。ＫＢＡＮは、現在のＢＡＮセッションキーである。ＩＤＸは、デバイスＩＤである。ここで、Ｘは、指定されたノードの名称である。
【００２７】
本発明の代表的な実施形態におけるさまざまなプライバシー及びメッセージの完全性の機能を実施するのに適したセキュリティ方式は、次世代暗号化標準（「ＡＥＳ」）である。ＡＥＳは、Ｒｉｎｊｄａｅｌと類似しているが、固定のブロックサイズ及びキーサイズを有し、米国連邦政府及び通信業界によって一般に使用される標準である。ＡＥＳは、本明細書でさらに説明するように、構成ＣＴＲ＋ＣＢＣ−ＭＡＣで適切に使用することができる。
【００２８】
ＢＡＮキーは、特定のキーの実施形態では、体内デバイス、特にＩＭＤ１１５等の埋め込み物から、ＢＡＮ１００の他の体外「ブリッジ」デバイス１１０へセキュアに通信される。また、ＢＡＮキーは、ＢＡＮ１００のブリッジデバイス１１０から埋め込み物１１５へもセキュアに通信されるべきである。本発明の実施形態によれば、２つの体外デバイス１１０間の通信又は体内デバイス１１５と体外デバイス１１０との間の通信を提供する基礎となる通信セッション１２０が存在する。この通信セッション１２０は、セキュアにされていない場合がある。セキュア通信（このようなセキュリティは、暗号化だけでなく完全性及び新しさの確証も含む）は、埋め込まれたデバイス１１５によって保持された認証マテリアルによって提供される。埋め込みデバイス１１５は、ＢＡＮキーをブリッジデバイス１１０へ配信する。ブリッジデバイス１１０は、適切な認証マテリアル１６０と、乱数生成ファシリティ１６５等のプロセスとを所有する。埋め込まれたデバイス１１５は、適切な認証マテリアル１６０とプロセスとを所有するブリッジデバイス１１０からＢＡＮキーを受信することもできる。本発明の実施形態によれば、以下のプロトコルによって、本発明のセキュリティプロトコルを使用できるブリッジデバイスへのＢＡＮキーのセキュアな無線配信が可能になる。
【００２９】
図２は、本発明の特定の実施形態によるネットワークノード間のネットワークキーのセキュアな送信のプロトコルを示している。図２に示すように、埋め込みアリス１１５は、ボブ１１０がＢＡＮキーを確立又は取得することを望むことをアリス１１５に示す「ＢＡＮキーを配信する（deliver BAN-key）」セッション要求２１０をブリッジデバイスのボブ１１０から受信する。アリス１１５及びボブ１１０は、最初に、テレメトリック通信セッション２１５を開始しなければならない。このテレメトリック通信セッションでは、アリス１１５は、新しく生成された乱数ＱＡをボブ１１０に提供する。次に、アリス１１５の人間のアドミニストレータ（たとえば、アリスデバイス１１５が埋め込まれた患者）は、スマートカードリーダを通じて電子認証マテリアル（ＥＡＭ）、たとえばスマートカード１４０をボブ１１０に提示しなければならない。この認証マテリアルは、通常、スマートカード１４０又はＵＳＢ／ＩＥＥＥ１３９４（「Ｆｉｒｅｗｉｒｅ（登録商標）」）フォブの形態を取り、図１のアリスのデバイスキー１７０（オプションとして暗号化されている）ＫｄｅｖＡ、１７５、アリスのＩＤ番号ＩＤＡ、及び使用されるブロック暗号（たとえば、１２８ビットＡＥＳ）を実施できるオンボードマイクロプロセッサを含むものである。ＥＡＭ１４０上に存在するＫｄｅｖＡ１７０のコピーも暗号化される場合、アリスの人間のオペレータは、ＰＩＮ又はパスワード入力及びオプションのバイオメトリックデータ１５５等、デバイスキー１７０を解読するのに必要な秘密情報も、たとえばキーパッド入力（図示せず）を介してボブ１１０に手動で与えるべきである。これらのステップが完了すると、ボブ１１０は、メッセージ２２０を準備してＥＡＭ１４０へ配信する。メッセージ２２０は、次のもの、すなわち、電子認証マテリアル１４０上に存在するＫｄｅｖＡ１７０のコピーを解読するのに必要なＱＡ、ＩＤＡ、ＩＤＢ、及び（必要に応じて）秘密情報２２５（ＰＷ１５０及びバイオメトリックデータ１５５）を含む。この即座のトランザクションに続いて、ボブ１１０は、好ましくは、ＰＷ１５０のあらゆるローカルな記録及びあらゆるバイオメトリック情報１５５を削除する。ＥＡＭ１４０は、以下で詳細に説明するように、その組み込まれたマイクロプロセッサ１８０を使用して、２つの１２８ビット乱数Ｑ１及びＱ２を生成する。次に、ＥＡＭ１４０は、キー入力としてＫｄｅｖＡ１７０を使用し、ノンスとしてＱＡを使用して、アリス１１５への、ブロック暗号でセキュアにされたメッセージ２３０を準備する。このセキュアにされたメッセージ２３０は、暗号化されたペイロードとしてＩＤＡ、ＩＤＢ、Ｑ１、及びＱ２を含む。次に、ＥＡＭ１４０は、このセキュアにされたメッセージ２３０を、Ｑ１及びＱ２の「セキュアにされていない」（すなわち、平文）コピーと共にボブ１１０へ渡す。次に、ボブ１１０は、ＥＡＭ１４０からアリス１１５への配達人として機能して、ＥＡＭ１４０のセキュアにされたメッセージ２３０をメッセージ２３５としてアリスへ送信し、Ｑ１及びＱ２のセキュアにされていないコピーを一時的に記憶する。アリス１１５が、ボブのテレメトリー送信２３５を経由してＥＡＭのメッセージ２３０を受信すると、アリス１１５は、メッセージ２３５を即座に解読し、自身のＩＤ１７５が正確であることを検証し、次いで、ボブのＩＤ（図１の１８２）を検証する。アリスが受信したメッセージ２３５が、その完全性チェックに合格した場合、メッセージ２３５がＫｄｅｖＡ１７０及びＱＡを使用してセキュアにされたものであるという理由で、メッセージ２３５は真正なもの（ボブ１１０を介してアリスの患者のＥＡＭ１４０からのもの）及び新鮮なものの双方であるということが、アリス１１５に保証される。
【００３０】
アリス１１５が、ＢＡＮキーをボブ１１０へ配信する場合、アリス１１５は、Ｑ１及び
【００３１】
【数２】
から成るセキュアにされていないメッセージ２４０を準備して、ボブ１１０へ送信することができる。ここで、ＫＢＡＮは、現在のＢＡＮ１００のキーである。ボブ１１０は、アリスのメッセージ２４０を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証し、自身のローカルなＱ２を、受信された
【００３２】
【数３】
とＸＯＲし、その結果はＫＢＡＮになる。
【００３３】
他方、アリス１１５が、ボブ１１０からＢＡＮキーを受信する場合、アリス１１５は、Ｑ１から成る、セキュアにされていないメッセージ２４５を準備してボブ１１０へ送信することができる。ボブ１１０は、アリスのメッセージ２４５を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証する。次に、ボブ１１０は、
【００３４】
【数４】
を含む、セキュアにされていないメッセージ２５０を準備してアリス１１５へ送信することができる。アリス１１５は、ボブのメッセージ２５０を受信すると、自身のローカルなＱ２を、受信されたメッセージ２５０の
【００３５】
【数５】
とＸＯＲし、その結果はＫＢＡＮになる。
【００３６】
図３は、図１及び図２のＥＡＭ１４０以外の認証アイテムを使用する、ボディエリアネットワークキー送信プロトコルの代替的な一実施形態を示している。この実施形態によれば、あまり高度でない非電子的認証マテリアルを使用するあまりセキュアでないプロトコルが次のように進行し得る。すなわち、プロトコル３００のこの実施形態によれば、ボブ１１０は、すでに述べたように「ＢＡＮキーを配信する」セッション要求２１０を開始することができ、埋め込み物１１５であるアリスは、「ＢＡＮキーを配信する」セッション要求２１０を、ボブ１１０であるブリッジデバイスから受信する。アリス１１５及びボブ１１０は、最初に、テレメトリック通信セッション２１５を開始しなければならない。このテレメトリック通信セッションでは、アリス１１５は、新しく生成された乱数ＱＡをボブ１１０に提供する。次に、アリス１１５の人間のアドミニストレータ（たとえば、アリスデバイスが埋め込まれた患者）は、３１０において、ＫｄｅｖＡ１７０及びＩＤＡ１７５から成る非電子的な認証マテリアルをボブ１１０に提示することができる。この認証マテリアルは、たとえば、英数字文字で又はバーコードとして認証カード上に印刷して、光学式スキャナリーダデバイスで読み出すことができる。この光学式スキャナリーダデバイスは、たとえば、ボブの内部のもの又はボブに不可欠なものとすることができるか、又は代替的に、ボブと信号通信する（たとえば、ボブとネットワーク接続された）別個のデバイスとすることができる。代替的に、認証マテリアルは、人間のアドミニストレータが、ＧＵＩを介して又はキーパッドに認証マテリアルをタイプ入力することによって、ブリッジデバイスのボブ１１０内へ手動で直接入力することもできる。次に、ボブ１１０は、（本明細書で説明したように、又は他の手段によって）自身のブロック暗号を使用して、上述したような２つの１２８ビット乱数Ｑ１及びＱ２を生成する。次に、ボブ１１０は、キー入力としてＫｄｅｖＡ１７０を使用し、ノンスとしてＱＡを使用して、アリス１１５への、ブロック暗号でセキュアにされたメッセージ２３５を準備する。このセキュアにされたメッセージ２３５は、ＩＤＡ１７５、ＩＤＢ１８２、Ｑ１、及びＱ２を含む。次に、ボブ１１０は、このセキュアにされたメッセージ２３５をアリス１１５へ送信し、Ｑ１及びＱ２のセキュアにされていないコピーを一時的に記憶する。アリス１１５が、ボブのメッセージ２３５を受信すると、アリス１１５は、そのメッセージを即座に解読し、自身のＩＤ１７５が正確であることを検証し、次いで、ボブのＩＤ１８２を検証する。アリスが受信したメッセージ２３５が、その完全性チェックに合格した場合、メッセージ２３５がＫｄｅｖＡ１７５及びＱＡを使用してセキュアにされたものであるという理由で、メッセージ２３５は真正なもの（すなわち、ボブ１１０からのもの）及び新鮮なものの双方であるということが、アリス１１５に保証される。他のＢＡＮキーの生成及び送信は、上述したように行われる。
【００３７】
アリス１１５が、ＢＡＮキーをボブ１１０へ配信する場合、アリス１１５は、Ｑ１及び
【００３８】
【数６】
から成るセキュアにされていないメッセージ２４０を準備して、ボブ１１０へ送信することができる。ここで、ＫＢＡＮは、現在のＢＡＮ１００のキーである。ボブ１１０は、アリスのメッセージ２４０を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証し、自身のローカルなＱ２を、受信された
【００３９】
【数７】
とＸＯＲし、その結果はＫＢＡＮになる。他方、アリス１１５が、ボブ１１０からＢＡＮキーを受信することを望む場合、アリス１１５は、Ｑ１から成る、セキュアにされていないメッセージを準備してボブ１１０へ送信することができる。ボブ１１０は、アリスのメッセージを受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証する。次に、ボブ１１０は、
【００４０】
【数８】
を含む、セキュアにされていないメッセージを準備してアリスへ送信する。アリスは、ボブのメッセージを受信すると、自身のローカルなＱ２を、受信された
【００４１】
【数９】
とＸＯＲし、その結果はＫＢＡＮになる。
【００４２】
本発明の実施形態は、送受信機モジュールが属するデバイスのクラスに依存して、製造者が、そのモジュールを少なくとも４つの永久的な状態のうちの１つにすることができるシステムを提供する。これらのクラスは、一般に、（１）埋め込みデバイス（ＩＭＤ）、（２）ブリッジデバイス、（３）スマートローカルデバイス、及び（４）ダムローカルデバイスとしてカテゴリー化することができる。スマートローカルデバイスは、ユーザ入力用のファシリティ（たとえば、外部の薬ポンプ、外部の血糖計コントローラ、及び埋め込みコントローラ）を含む広範囲のグラフィカルユーザインターフェース（ＧＵＩ）を有するデバイスである。ブリッジデバイスは、広範囲のＧＵＩ及びユーザ入力を有し、さらに、埋め込みデバイス（たとえば、医師プログラマ、並びに、より機能豊富で強力な埋め込みコントローラ及びホームモニタ）に対して自身を認証することができる。ダムローカルデバイスは、ＧＵＩもユーザ入力も有しないデバイスである。ただし、或る限られたユーザディスプレイが存在する場合がある。ダムローカルデバイスには、キーフォブ、外部の血糖計、コムリンク、並びに特定の限られた能力の患者コントローラ及びホームモニタが含まれ得る。
【００４３】
ＢＡＮのさまざまなノードを構成するデバイスのタイプにかかわらず、これらのデバイスが、必要な最小の計算資源とセキュアに通信するために、すべてのデバイスは、好ましくは、ＢＡＮキーＫＢＡＮを共有する。たとえば、本発明によれば、ブリッジデバイス及び／又はスマートローカルデバイスは、セッション単位で、他のブリッジデバイス、スマートローカルデバイス、ダムローカルデバイス、及び埋め込まれたデバイスへ正当なＢＡＮキーを配信することができ、具体的には、埋め込みデバイスは、ＢＡＮの認可されたブリッジデバイス（たとえば、プログラマ機器）へ現在のＢＡＮキーをセキュアに配信するか、又は、認可されたブリッジデバイス（たとえば、プログラマ機器）から現在のＢＡＮキーをセキュアに受信する。本発明の特定の実施形態では、ＢＡＮキーの配信中のデバイスなりすまし、ＢＡＮキー配信の盗聴、及び／又は反射攻撃（すなわち、実質的なメッセージの内容の部分的な理解若しくは推測のみを含むか、又は、そのような理解も含まない、盗聴された通信の単なる繰り返し）を防止するか又は妨げるキー配信プロトコルが使用される。体外（すなわち、身体の外部）のＢＡＮデバイスは、ＩＭＤの秘密デバイスキーを決して受信しないので、プログラマ等の患者のＢＡＮのデバイスは、ＩＭＤの一意のデバイスキーを知ることは決してなく、一意のデバイスキーは、常に秘密の状態に維持されて、通信されず、たとえ、そのＩＭＤのＢＡＮで使用される体外機器が喪失又は盗難されても、存在するセッション認証情報は使用されていないものとなり、ＩＭＤの秘密キーは、体外機器上に決して記憶されていないので、ＩＭＤは危険にさらされない。ＢＡＮキーは、好ましくは、ＢＡＮの体外デバイス（たとえば、ブリッジデバイス及びスマートローカルデバイス）からＢＡＮの他の体外デバイス（たとえば、ブリッジデバイス、スマートローカルデバイス、及びダムローカルデバイス）へセキュアに通信される。これを行うために、本発明の特定の実施形態では、基礎となる無線通信方法の標準的なハンドシェイク、セッション要求、又は他のあらかじめ確立されたプロトコルに従って、セキュアにされていないテレメトリーセッションが確立される。ＢＡＮキーを受信するデバイスは、人間によって管理されている場合、ＢＡＮキーを配信するデバイスを操作する人間がＢＡＮキー受信者の認証を検証できるようにするために、その人間に、受信デバイスのデバイスキーＫｄｅｖ及び受信デバイスのＩＤ番号を視覚的に提供できなければならない。特にデバイスキーＫｄｅｖは、好ましくは、最初のデバイスが通過するすべてのデバイスから一意であるわけではない場合でも、少なくともＢＡＮに組み込まれる他のデバイスに対して一意である。また、特定の実施形態では、スマートローカルデバイス及びブリッジデバイスは、自身に提供されているかも知れないＢＡＮキーを、ＢＡＮの他の適任のデバイス（すべてのダムローカルデバイス及び／又は他のスマートローカルデバイス及び／又は他のブリッジデバイス）へセキュアに配信するのに使用される。本発明の代表的な実施形態によれば、ＢＡＮキーは、ＢＡＮの無線接続機能を介してセキュアに提供される。
【００４４】
図４は、本発明の一実施形態による２つの体外デバイスを有するボディエリアネットワーク４００を示している。この実施形態では、前の例のようなＩＭＤではなく、スマートローカルデバイス４１５又はブリッジデバイス４２０等の体外デバイスへＢＡＮキーを配信する体外デバイス（アリス）４１０が、ＢＡＮキー配信要求を開始することができる。前のＢＡＮキー伝播の例と同様に、テレメトリック通信セッションが、非セキュアチャネル１２０を介して（たとえば、ハンドシェイク又は他のあらかじめ確立された互換性のあるセッションプロトコルによって）、ＢＡＮキーを受信するデバイス（ボブ）１１０と確立され、ボブ１１０は、（ボブデバイス１１０のメモリ、ストレージ、又は他のハードウェア若しくはソフトウェアの素子４３５に実装されたＲＮＧファシリティによって生成される）新しく生成された乱数ＱＢを、メッセージ４２５を介してアリス４１０へ送信する必要がある。アリス４１０及びボブ１１０が、本発明に従って、非セキュアチャネル１２０を介して別の方法でテレメトリーセッションを確立すると、アリス４１０（又は、ＢＡＮキー交換セッションを管理する人間）は、ボブのデバイスキーＫｄｅｖＢ４３０を視覚的に獲得することできる（且つ、ＧＵＩ又は他の入力を介してアリス４１０に入力することができる）。デバイスキーＫｄｅｖＢ４３０は、たとえば、ボブの外装に貼付されたラベルに印刷することもできるし、ボブの電子ＧＵＩ上に表示することもでき、また、図４に抽象的に示すオンボードメモリ又はローカルストレージ素子４３５にも記憶される。アリス及びボブは、通常、テレメトリーセッションの最初の時点でＩＤ（ＩＤＡ及びＩＤＢ）を交換し、通信４４５及び４５０を介してそれらの各ＩＤを他の関係者に提供する。ほとんどの場合に、アリス４１０は、ボブ１１０のポーリング又はインターロゲートを行い、メッセージ４４５を介してボブの識別番号（ＩＤＢ）４４０を取得することもできる。
【００４５】
アリスは、ＩＤＢ４４０及びＫｄｅｖＢ４３０を獲得すると、オンボードメモリ又はセキュアストレージ４５５に記憶されているＩＤＡ（アリスのＩＤ番号）及びＢＡＮキーにアクセスすることができ、ＩＤＡ、ＩＤＢ及び現在のＢＡＮキーＫＢＡＮを含むメッセージ４６０を準備して、ボブへ送信することができる。ＩＤＡ、ＩＤＢ及び現在のＢＡＮキーＫＢＡＮはすべて、（以下で説明するように、ブロック暗号へのノンス入力としてのＱＢと共に）ブロック暗号へのキー入力としてボブのデバイスキーＫｄｅｖＢ４３０を使用してセキュアにされる。ボブ１１０は、アリスの送信４６０を受信すると、ＫｄｅｖＢ４３０を使用してアリスのメッセージ４６０を解読して検証し、受信されたＩＤＡ、ＩＤＢ、及びＫＢＡＮをログ記録する。次に、ボブは、ＩＤＡ、ＩＤＢを含むメッセージ４６５を準備して、アリス４１０へ送信する。ＩＤＡ、ＩＤＢはすべて、ＫＢＡＮ及びＱＢ＋１（すなわち、ＱＢをインクリメントしたもの）でセキュアにされる。アリス４１０は、ボブのメッセージ４６５を受信して解読／検証すると、自身が受信したＩＤが、自身が送信したＩＤと一致することを検証する。
【００４６】
ダムローカルデバイス４７０の場合、デバイスキーＫｄｅｖＸは、好ましくは、「工場において」ランダム又は任意に選ぶことができ、デバイス４７０内のファームウェア（又は、代替的にフラッシュメモリ）４３５に永久的にプログラミングすることができる。ダムローカルデバイス４７０は、本明細書で定義されるように、一般に、有効なＧＵＩを有しないので、Ｋｄｅｖ４３０は、好ましくは、デバイス４７０の外装、デバイス４７０の文書、又はデバイスそのものに貼付されるべきラベルに印刷され、開始後に除去される。これとは対照的に、スマートローカルデバイス４１５及びブリッジデバイス４２０は、本明細書で定義されるように、ＧＵＩを有し、それによって、自身のデバイスキー４３０を（ダムローカルデバイスと同様に）外部ラベルを経由して利用可能にすることもできるし、デバイスのＧＵＩを通じて利用可能にすることもできる。Ｋｄｅｖは、攻撃者が、認可されていないＢＡＮからテレメトリーノードデバイスにアクセスするために知る必要がある唯一の情報であるので、Ｋｄｅｖをできるだけ秘密の状態に維持することが重要である。スマートローカルデバイス４１５及びブリッジデバイス４２０の場合、デバイスキーＫｄｅｖがオンボードメモリ／ストレージ４３５又は４５５にのみ記憶され、もっぱらデバイスのＧＵＩを経由して利用可能であり、デバイスのＧＵＩとの対話が必要とされる場合に、デバイスの外側に印刷されることとは対照的に、Ｋｄｅｖは、明らかに、よりセキュアである。
【００４７】
ＫｄｅｖＢ４３０等のデバイスキーは、好ましくは、（フラッシュメモリ４３５内を含む）ダムローカルデバイス４７０内にハードプログラミングされる一方、スマートローカルデバイス４１５及びブリッジデバイス４２０については、デバイスキーはハードプログラミングされる必要はない。したがって、本発明の特定の実施形態では、スマートローカルデバイス４１５及びブリッジデバイス４２０のデバイスキーのプライバシーは、デバイスキーが必要とされるごとに、デバイスキーがランダムに生成される場合に最大にすることができる。デバイスキーの新しく生成された乱数を使用し、それによって、ＧＵＩを経由してデバイスキーを観察可能にすることを必要とすることによって、新しいデバイスキーが生成されるごとに、可能なデバイスキーの確率分布が（疑似乱数ジェネレータの一様性まで）効果的に一様になるという点で、スマートローカルデバイス４１５及びブリッジデバイス４２０に、ハイジャック（すなわち、認可されてない使用又はアクセス）からの特別な免疫が提供される。これは、デバイスキー４３０を推測しようとしている攻撃者４７５が、新しいデバイスキー４３０が生成されるごとに、自身の検索を最初からやり直す必要があることを意味する。したがって、本発明の特定の実施形態では、新しく生成された乱数が、スマートローカルデバイス４１５及びブリッジデバイス４２０のデバイスキーを生成するのに使用される。すべてのメッセージ、すなわち、ＢＡＮキーによるキー付き（keyed）メッセージ及びデバイスキーによるキー付きメッセージをセキュアにするのにブロック暗号を使用することができる。たとえば、過度のオーバーヘッドなしで強力なセキュリティを与えるブロック暗号は、１２８ビットＡＥＳとすることができる。デバイスキーが、ブロック暗号の長さよりも短い場合、ブロック暗号の引数の長さに達するために必要とされる回数だけ、デバイスキーを繰り返して、それ自体に連結することができる。
【００４８】
図５は、図４のネットワークキー伝播プロトコルを疑似プロトコル表記で示している。このプロトコルは、ＢＡＮキーが、ＢＡＮ４００の体外デバイス（ブリッジデバイス４２０及びスマートローカルデバイス４１５）からＢＡＮ４００の他の体外デバイス（ブリッジデバイス４２０、スマートローカルデバイス４１５、及びダムローカルデバイス４７０のいずれか）へどのようにセキュアに通信されるのかを記述している。ＢＡＮキーを受信するデバイス、この場合、ボブ１１０は、ブリッジデバイス、スマートローカルデバイス、ダムローカルデバイス等の体外デバイスへＢＡＮキーを配信するデバイス（この場合、アリス４１０）を操作する人間に、受信デバイス１１０のデバイスキーＫｄｅｖ４３０及び受信デバイスのＩＤ番号４４０を視覚的に提供できなければならない。最初に、ボブ１１０は、「ＢＡＮキーを配信する」セッション要求２１０をアリス４１０から受信する。アリス４１０及びボブ１１０は、最初に、図４のメッセージ４２５と同様に、ボブ１１０が新しく生成された乱数ＱＢをアリス４１０に提供するテレメトリック通信セッション２１５を開始しなければならない。本発明の特定の実施形態によれば、スマートローカルデバイス４１５及びブリッジデバイス４２０は、ＢＡＮキーを有する場合に、ＢＡＮ４００の他の適任のデバイス（すべてのダムローカルデバイス４７０及び／又は他のスマートローカルデバイス４１５及び／又は他のブリッジデバイス４２０）へＢＡＮキーをセキュアに配信することを担当する。したがって、以下のプロトコルは、適任のＢＡＮ４００のデバイスへのＢＡＮキーのセキュアな無線配信を可能にするのに適切である。
【００４９】
図５に示すように、ＢＡＮキーを配信するデバイス（アリス４１０）によって開始される「ＢＡＮキーを配信する」セッション要求２１０は、まず、ＢＡＮキーを受信するデバイス（ボブ１１０）とのセキュアにされていない通信セッション２１５を確立することから成る。アリス４１０及びボブ１１０がテレメトリーセッションを確立すると、ボブ１１０も、アリス４１０に、新たに生成された６４ビット疑似乱数ＱＢをメッセージ２１５を介して送信する必要がある。
【００５０】
スマートローカルデバイス４１５及びブリッジデバイス４２０のファームウェアが、着信する「ＢＡＮキー配信」コマンド２１０を拒否する場合には、人間のユーザが、スマートローカルデバイス４１５又はブリッジデバイス４２０を「新しいＢＡＮキーを受理する」モードにしない限り、デバイスハイジャックを防止するさらなる極めて強力な方法を実現することができる。新しいＢＡＮキーの受理に人間の介入を必要とすることは、専用の物理ボタン又はスイッチをダムローカルデバイス４７０に追加することによってダムローカルデバイス４７０において実施することができる。
【００５１】
スマートローカルデバイス４１５及びブリッジデバイス４２０のファームウェア４３５、４５５が、着信する「ＢＡＮキー配信」コマンドを拒否する場合には、デバイスに接近した人間のユーザが、スマートローカルデバイス又はブリッジデバイスを「新しいＢＡＮキーを受理する」モードにしない限り、デバイスハイジャックを防止するさらなる極めて強力な方法を実現することができる。新しいＢＡＮキーの受理に人間の介入を必要とするこのアイデアは、物理ボタン又はスイッチ（埋め込まれた「リセット」ボタン等）をダムローカルデバイス４７０に追加することによってダムローカルデバイス４７０においても実現することができる。新しいＢＡＮキーを受理するのに人間との対話を必要とすることは、実際に、（攻撃者がデバイスとの物理的な接触を達成しないという条件で）起こり得るあらゆるデバイスハイジャックを排除するが、本明細書で説明するように、ＢＡＮキー配信プロトコルに対する他の攻撃は可能であり、本発明の他の実施形態によって対処される。
【００５２】
図４及び図５のＢＡＮキー配信プロトコルの最後のステップにおいて、ボブ１１０は、ＫＢＡＮでセキュアにされたメッセージ４６５をアリス４１０へ送信することができ、したがって、キー配信プロトコルが成功したことを確認する。この確認信号は、アプリケーションレイヤに渡すことができ、次いで、視覚信号及び／又は音響信号の形態で「配信成功」通知として人間のユーザへ通信することができる。
【００５３】
本発明のブリッジデバイス４２０及びスマートローカルデバイス４１５は、特定の実施形態では、ＢＡＮキーをリセットすることができ、それによって、以下で説明するように、セッションキーもリセットすることができる。たとえば、患者又は医師の命令で、ブリッジデバイス４２０及びスマートローカルデバイス４１５は、受信機のデバイスＩＤ及びデバイスキーを使用することによって、ＢＡＮキーをローカルデバイス４１５、４７０及び／又は他のブリッジデバイス４２０へ配信することができる。本発明の特定の実施形態では、埋め込まれたデバイス又はブリッジデバイス４２０がＢＡＮに存在するか否かにかかわらず、スマートローカルデバイス４１５は、ＢＡＮキーを生成することができる。一般に、ＢＡＮキーを更新する必要がある唯一の時は、ＢＡＮキーを有するデバイスが喪失又は盗難された時である。本発明による特定の実施形態では、現在の攻撃者の処理能力に基づくと、ＢＡＮキーは、危険にさらされることを回避するために約数百年に１度の頻度でしか更新する必要がない。
【００５４】
ネットワーキング資源の制約条件のために、本発明の特定の実施形態では、共通の秘密キーが、特定のボディエリアネットワーク（ＢＡＮ）のすべてのデバイスによって共有される。このＢＡＮキーＫＢＡＮは、ＢＡＮ内のすべての通信をセキュアにするのに使用される。ＢＡＮ内では、テレメトリーセッションを次のように確立することができる。すなわち、テレメトリーセッションを開始するいずれかのデバイスのコマンド時に、共有されたＢＡＮキーが、現在のテレメトリーセッションで通信することを望むすべてのＢＡＮメンバーによって与えられる、新しく生成されて共有される乱数と共に、セッションキーＫｓｅｓにされる。このセッションキーＫｓｅｓは、テレメトリーセッションの継続時間の間、ＢＡＮで通信されるすべてのメッセージをセキュアにするのに使用される。テレメトリーセッションがクローズされると、現在のセッションキーは廃棄される。
【００５５】
ノード間の通信セッションをオープンするために、最初に、たとえば、ハンドシェイク、セッション要求／受理、又は他のセッション開始プロトコルによって、セキュアにされていない交換が通信デバイス間で行われる。好ましくは、着信するパケット長及び発信するパケット長は固定であり、その上、本発明による特定の実施形態では、物理レイヤハードウェアが、これらのパケット長を予測するようにセットアップされる。したがって、それよりも短いパケット又は長いパケットを「不良」とフラグ付けして拒絶することができる。使用される、関連のある暗号のインスタンスが利用可能でなければならない。本発明と共に使用するためのさまざまな適切な暗号化標準の１つは、ＦＩＰＳ承認の１２８ビットＡＥＳブロック暗号（ＦＩＰＳ ＰＵＢ １９７）である。暗号化は、ＡＥＳの「カウンタモード」（ＣＴＲモード）で適切に行うことができる。メッセージの新しさは、トークンのようなノンス（すなわち、使い捨ての疑似乱数）の使用を通じてチェックすることができる。また、特定の実施形態では、たとえば、ＡＥＳの「暗号ブロック連鎖メッセージ認証コードモード」（ＣＢＣ−ＭＡＣモード）の使用によって、メッセージの完全性が維持される。本発明のテレメトリーセキュリティシステムでは、本明細書で論述するように、疑似乱数をその時々に生成しなければならない。乱数は、コンピュータ生成された数を指すとき、技術的に正確に言えば、コンピュータ生成された数が実際には決定的であるという点で、（真の乱数とは対照的に）いわゆる疑似乱数を指すことができる。しかしながら、疑似乱数は、全体関数（overall function）が、可観測にするために全体的に確率的プロセスとして振舞うように、好ましくは、十分に複雑な若しくは多様な状態又は補助関数から導出される。この数の実際の値は重要ではなく、特定の実施形態では、数は、暗号の種、メッセージ認証関数の種、さらには、別の疑似乱数生成の種として使用できることが理解されよう。数の実際の値は、疑似乱数の関数については重要ではないので、数の値は、任意であると言うことができる。任意とは、本明細書では、一般に「偶然」と同義であることが意図されている。一般に、本発明が、疑似乱数の使用をどこで必要としようとも、その機能は、たとえば、代替的な疑似乱数ジェネレータ、又は、本発明の代替的な実施形態によるハードウェア生成された乱数に置き換えることができる。特定の実施形態では、上述したＦＩＰＳ承認のＡＥＳブロック暗号仕様は、ＡＮＳＩ Ｘ９．３１仕様（付録Ａ．２．４）に基づくＮＩＳＴ推奨の疑似乱数ジェネレータ（ＰＲＮＧ）を実施したものを提供する。これは、本発明の典型的な実施形態に適している。ＡＮＳＩ Ｘ．９．３１ ＰＲＮＧ仕様のこの特定の実施形態は、ＡＥＳブロック暗号（ＦＩＰＳ ＰＵＢ １９７）を使用する。このタイプの実施形態は、一時に１２８ビットのＰＲＮＧ疑似乱数を生成する。
【００５６】
図６〜図９は、本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図を示している。図６は、本発明の実施形態による、図９の乱数ジェネレータの最初のステップのデータフロー図を示している。特定の実施形態では、１２８ビット疑似乱数（ＰＲＮ）の生成は、ＡＮＳＩ Ｘ９．３１で指定されているように、ＡＥＳブロック暗号を使用して実施され、過度のオーバーヘッドなく、予測される攻撃者の処理能力の観点から十分なセキュリティ及びプライバシーを提供する。初期事項として、１２８ビット乱数ＫＲ６１０及びＲ０が、ＰＲＮＧに利用可能である。ＰＲＮＧキーであるＫＲ６１０は、変化せず、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５に常にロードされる。Ｒ０は、ＰＲＮＧが１２８ビット乱数を生成するごとに、新しい現在のＰＲＮ（Ｒ１，Ｒ２，…）で更新されるＰＲＮＧの秘密ランダム初期化ベクトル（secret and random initialization vector）である。ＫＲ６１０及び現在のＲの双方は、新しいいずれの疑似乱数の生成にも必要とされるので、メモリ又はセキュアローカルストレージに記憶することができる。
【００５７】
この実施形態では、あらゆる（ｉ＋１）番目のＰＲＮの生成は、次のように進行する。すなわち、図６に示すように、ブロック暗号６２０（この例では、１２８ビットＡＥＳ）が、キー入力６１５としてＫＲ６１０を使用してノンス６２５を暗号化するのに使用される。ノンス６２５は、たとえば、そのノードの現在のリアルタイムクロック値から構成することができ、１２８ビットレジスタを経由してブロック暗号６２０の１２８ビットｄａｔａ＿ｉ入力６３０にロードすることができる。（リアルタイムクロックが、１２８ビットよりも長い場合には、リアルタイムクロックの最下位１２８ビットを使用することができる。）リアルタイムクロックが１２８ビットよりも短い場合には、０の個数にリアルタイムクロックのビット数を加えたものが１２８に等しくなるように、ノンス６２５の最上位ビットを０でパッディングすることができる。リアルタイムクロックが、ノンス６２５を生成するのに使用されようとされまいと、ブロック暗号６２０から出力される中間値ｄａｔａ＿ｏ６３５は、本明細書では、Ｖ１６４０と呼ばれる場合がある。
【００５８】
図７は、本発明による疑似乱数ジェネレータの一実施形態における図６のステップに続くステップを示している。図７に示すように、中間値Ｖ１６４０は、現在のＲ７１０（最初の乱数の場合はＲ０であり、（ｉ＋１）番目の乱数の場合はＲｉである）とＸＯＲされる。次に、この１２８ビット値
【００５９】
【数１０】
６２５をブロック暗号６２０で暗号化することができる。具体的には、ＫＲ６１０を、たとえば１２８ビットレジスタからブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードすることができる。それに続いて、
【００６０】
【数１１】
６２５を、別の１２８ビットレジスタを経由してブロック暗号６２０のｄａｔａ＿ｉ入力６３０にロードすることができる。中間値Ｖ２７２０は、ブロック暗号６２０のｄａｔａ＿ｏ出力６３５である。
【００６１】
図８は、本発明による疑似乱数ジェネレータの一実施形態における図７のステップに続くステップを示している。この実施形態では、１２８ビット中間値Ｖ１６４０及びＶ２７２０が、互いにＸＯＲされ、ブロック暗号６２０で暗号化される。具体的には、ＫＲ６１０が、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされる。
【００６２】
【数１２】
６２５の結果は、別の１２８ビットレジスタを経由してブロック暗号６２０のｄａｔａ＿ｉ６３０入力にロードされる。ブロック暗号６２０の出力ｄａｔａ＿ｏ６３５は、新しいＰＲＮ Ｒｉ＋１８１０を含む。さらなる１２８ビットＰＲＮが必要とされる場合には、新しいノンス６２５（たとえば、現在のリアルタイムクロックデータ）を使用し、且つ、新しく更新されたＰＲＮ Ｒｉ＋１８１０を使用して、ＲＮＧプロセスを繰り返すことができる。さらなる乱数が必要とされない場合、Ｒｉ＋１は、今後のセッションにおける今後のＰＲＮの生成に備えてメモリに記憶される。ＰＲＮＧキーＫＲ６１０は、メモリ又はセキュアローカルストレージに記憶することができる。
【００６３】
要約すれば、ＲＰＮＧキーの生成は、好ましくは、図９に示すように、次のように進行する。ブロック暗号が、関数Ｅ（ｄａｔａ＿ｉ；ｋｅｙ＿ｉ）＝ｄａｔａ＿ｏによって表され、ここで、Ｅが、関数への関連のある引数並びにｄａｔａ＿ｉ６３０及びｋｅｙ＿ｉ６１５（ｉ≧０を有する）を有するＡＥＳ関数６２０を表す場合、アルゴリズムは、ブロック暗号を通る３つのステップのネストされた処理又は反復的な処理に従って要約することができる。すなわち、
ステップ１．Ｖ１６４０＝Ｅ（ノンス６２５；ＫＲ６１０）
ステップ２．
【００６４】
【数１３】
ステップ３．
【００６５】
【数１４】
である。上記ステップの３つすべてを結合することによって、
【００６６】
【数１５】
が与えられる。
【００６７】
本発明の特定の実施形態では、ＰＲＮ生成には、１２８ビットＡＥＳブロック暗号６２０及びモジュロ２加算機能の使用、ブロック暗号をバッファリングする３つの１２８ビットレジスタ、リアルタイムクロック又は別のノンス６２５のソースへのアクセス、並びに２つの１２８ビットの数Ｒｉ７１０及びＫＲ６１０のストレージ空間が割り当てられる。これらのうち、Ｒｉ及びＫＲのストレージ空間は、本発明の他の態様及び機能には利用可能でない場合がある。好ましくは、２つの１２８ビット乱数は、たとえば製造の際に、本発明のモジュールの実施態様に「インストール」することができる。これらの乱数のうちの一方（ＫＲ６１０）は、永久的なものとすることができ、他方Ｒ０７１０は、好ましくは、新しい疑似乱数が生成されるごとに、更新することができる。
【００６８】
本発明によるセキュアテレメトリーセッションは、好ましくは、１つ又は複数の通信デバイスがセキュアセッションを要求するといつでも開始される。セキュア通信セッションのセットアップは、２ステップのプロセスである。この２ステップのプロセスによって、すべての通信デバイスには、同じセッションキーＫｓｅｓが提供される。ステップ１において、すべての通信デバイスは、Ｒｘと呼ばれる事前に生成された疑似乱数、たとえば６４ビット乱数、を交代でアナウンスする。ここで、「ｘ」は、異なるデバイスをインデックスする。上述し且つ図６〜図９に示したように、特定の実施形態では、疑似乱数が次のセキュアセッションに直ちに利用可能であるように、疑似乱数は、前のセキュア通信セッションの終了時に生成される。これらの疑似乱数の生成は、好ましくは、本明細書の開示に従って行うことができるが、疑似乱数又はハードウェア生成された乱数を生成する他の方法を本発明に従って代用することもできる。
【００６９】
事前に生成された乱数のアナウンスに続いて、次のステップは、セキュアセッションの確立を提供し、すべての通信デバイスが共通のセッションキー（Ｋｓｅｓ）を計算することを必要とする。この共通のセッションキーは、その後、セキュアセッションの継続時間の間、データトラフィックをセキュアにするのに使用される。Ｋｓｅｓは、独立に計算されるが、ブロック暗号等の暗号を使用して各デバイスによって全く同一に計算される。１２８ビットＡＥＳブロック暗号は、本発明の典型的な実施形態に適している。
【００７０】
図１０は、本発明の実施形態によるセッションキーの生成のデータフロー図である。共通セッションキーは、事前に確立されたＢＡＮキーＫＢＡＮ及び通信ノードの乱数のすべて｛Ｒ１，Ｒ２，Ｒ３…｝から導出することができる。特定の実施形態では、Ｋｓｅｓは、ブロック暗号６２０への「キー入力」６１５内にＫＢＡＮをロードし且つブロック暗号６２０の「データイン」６３０内にデバイスの乱数１０１０をロードすることによって計算することができる。これは、本発明の特定の実施形態では、ファームウェア制御によって成し遂げることができる。具体的には、最初の２つのデバイスの６４ビット乱数が連結されて１２８ビットの数にされる。次に、この１２８ビットの数が、ブロック暗号６２０の「データイン」６３０にロードされる。セキュアセッションを確立することを望むデバイスが２つしか存在しない場合、ブロック暗号６２０の１２８ビット出力６３５が、セッションキーＫｓｅｓとなる。単一のセッション内でセキュアに通信することを望むデバイスが３つ以上存在する場合、再びブロック暗号６２０の「データイン」６３０を入力して上述したように処理される前に、ブロック暗号６２０の出力６３５が、続いて、次の２つのデバイス１０２０の連結された１２８ビット（２×６４ビット）乱数にＸＯＲされる（すなわち、モジュロ２加算される）。暗号（ここでは、１２８ビットＡＥＳ）のＸＯＲ導出値６３５への適用は、好ましくは、デバイスの乱数のすべてを通過するのに必要な回数だけ繰り返される。ここで、ブロック暗号６２０の最終出力６３５は、Ｋｓｅｓ１０３０である。セキュアセッションに含まれるデバイスが奇数個存在する場合、１２８ビット連結の「空」のスロットを６４個の０で満たすことができる。セキュア通信セッションの終了時に、エフェメラル（ephemeral）Ｋｓｅｓ１０３０を「削除」することができ、新しい各セキュアテレメトリーセッションが提供されると、その開始時に、新しいセッションキー１０３０が計算される。
【００７１】
説明したように、特定の実施形態で情報をセキュアにすることは、たとえばカウンタ（ＣＴＲ）モードで使用されるブロック暗号が使用されることを含めて、暗号に基づくことができる。このように、ブロック暗号は、キー付き疑似乱数キーストリームを生成するという点で、ストリームに適用することができる（又は、受信側ノードにおいて、平文を生成して解読を行うために暗号文に対して適用することができる）。このキー付き疑似乱数キーストリームは、その後、暗号化文を生成するために平文に対してＸＯＲされる。図１１は、本発明の実施形態によるメッセージのＣＴＲモードの暗号及び解読のデータフローを示している。図示するように、共有セッションキー１０３０は、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされ、セッションキー１０３０は、（上述したように、セキュアセッションの開始時に計算された後）メモリ又はストレージからレジスタにロードすることができる。１２８ビットノンス（すなわち、１回だけ使用される数）１１１０は、別の１２８ビットレジスタを経由して、ブロック暗号６２０のｄａｔａ＿ｉ入力６３０にロードされる。
【００７２】
図１２は、本発明の実施形態によるノンスレジスタのデータ構造を示している。この実施形態では、図１２に示すように、１２８ビットノンス１１１０の最上位８バイト１２１０が、実際には、８バイトのアップカウンタ１２１０である一方、そのカウンタの下位側の６バイト１２１５は、インスティゲーティングデバイス（instigating device）の乱数Ｒｘ１２２０の最下位６バイト［すなわち、ビット４７〜ビット０］で開始される。乱数Ｒｘ１２２０は、図１０のセッションキー１０３０の生成に貢献されたものであることが理解されよう。本発明によるテレメトリーパケットが、セキュアセッションで受信又は送信されるごとに、カウンタ１２１０の値がインクリメントされる。（８バイトカウンタ１２２０のすぐ下の）次のノンスバイト１２２５は、図１２のビット「ｍ」１２３０であるモードビット１２３０を含む。本明細書で説明するように、このビットは、ノンスがＣＴＲモード暗号化／解読に使用されているときは、論理０に設定することができ、ノンスがメッセージの完全性に使用されているときは、モードビットは論理１に設定される。モードビットの下の７ビットフィールドであるブロック番号フィールド１２４０は、あらゆるパケットの開始時に論理０００００００にリセットされ、そのパケット内の暗号化／解読に使用されるキーストリームマテリアルの各１２８ビットブロックの生成時にインクリメントされる。たとえば、各テレメトリーパケットが、暗号化／解読に３００ビットのキーストリームマテリアルを必要とした場合、キーストリームの最初の１２８ビットは、０００００００を使用して生成され、２番目の１２８ビットは、００００００１を使用して生成され、３番目の１２８ビットは、０００００１０を使用して生成される（１つずつインクリメントされる。キーストリームマテリアルの３００ビットがパケットごとに必要とされる例では、キーストリームマテリアルの最後の１２８ビットのうちの４４ビットのみが必要とされることに留意する）。１２８ビットノンス１１１０の残りの７バイト（最下位７バイト１２４０）は、好ましくは、永久的に論理０に設定することができる。
【００７３】
反射攻撃を防止することを助ける同期されたタイムスタンプではなく、又は、このタイムスタンプに加えて、本発明の特定の実施形態では、あらゆるセキュアテレメトリックセッションの開始時に新しいセッションキーＫｓｅｓ１０３０を計算することによって、メッセージの新しさ及びユーザ認証が提供される。この新しいセッションキー１０３０は、セキュアセッションの参加者のそれぞれによって生成された乱数の貢献度（contribution）の関数である。しかしながら、セッション内の反射攻撃について、さらなる新しさのメカニズムを提供することができる。この場合、セキュアセッションのデバイスは、セッションノンスの自身のローカルコピーにおけるカウンタを、その現在の値よりも小さな値にリセットすることを決して可能にすべきでない。テレメトリー通信セッションが中断されるか、又は、他の或る理由から、基礎となる通信プロトコル内で「リセット」若しくは再同期する必要がある場合、セキュアセッションのデバイスが再同期するために、現在のセッションノンスはアナウンスされることが必要な場合がある。攻撃者は、おそらく、他のセッション参加者のノンスを前の値にリセットし、それによって、攻撃者が、前のノンス値を使用した古いメッセージを反射できるように試みることによって、このような状況の悪用を企てている可能性がある。このように、セッションノンスは、かなりのネットワークトークンとして機能する。ノンスカウンタが増加のみ行う場合、２６４個を超えるパケットが単一のセキュアセッションで通信されることはないという条件で、過去のセッション内メッセージは、以前のノンスを有するので、古いメッセージは、決して正当なノンスを有しない。なお、２６４個を超えるパケットが単一のセキュアセッションで通信されることは、起こりそうもないことである。
【００７４】
図１１に示すように、本発明の実施形態では、暗号化及び解読は、好ましくは、ブロック暗号６２０の１２８ビット出力バスｄａｔａ＿ｏ６３５と、暗号化用のペイロード平文から取られた１２８ビットデータブロック１１１５、及び、解読用のペイロード暗号文から取られた１２８ビットデータブロック１１１５との間でビット単位のモジュロ２加算（ＸＯＲ）を実行することによって行われる。本発明の特定の実施形態では、パケットヘッダは暗号化されない。
【００７５】
図１３は、本発明の一実施形態によるテレメトリーパケット１３００のデータ構造を示している。１２８ビットメッセージブロック１１１５のそれぞれは、ブロック暗号６２０の異なる出力６３５とＸＯＲ１１２０を行うことができる。たとえば、図１３のメッセージブロックｍ１１３１０は、キーストリームブロック（すなわち、ブロック暗号６２０のｄａｔａ＿ｏバス６３５を残した１２８ビットブロック）ｓ１とＸＯＲされ、メッセージブロックｍ２（パケットの次の１２８ビット１３２０）は、ｓ２とＸＯＲされる。他のメッセージブロックについても同様にＸＯＲされる。前述したように、異なるノンス１１１０は、各キーストリームブロック６３５の生成で使用される。特定の実施形態では、同じノンス１１１０が、同じセッション内で２回使用されることは決してない。したがって、８バイトノンスカウンタ１２１０が、その最大値（０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ）に達すると、セキュアセッションを終了することができ、新しいセッションキーが一括して計算される。この実施形態では、単一のセッションキーを使用して通信できるテレメトリーパケットの個数は、２６４個（インスティゲータ（instigator）の乱数の最下位６バイトが０ｘｈ００００００００００００である場合に対応する）から２６４−２４８個（インスティゲータの乱数の最下位６バイトが０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦの場合に対応する）である。１０進数では、これらの数は、それぞれ１．８４４６７×１０１９及び１．８４４６４×１０１９であり、したがって、実際にこれらのパケット数に決して達する可能性がないことが理解されよう。
【００７６】
たとえばＴＤＭＡ構造といったセキュアにされたネットワークでは、好ましくは、デバイスは、非送信の期間中にセキュアな通信を維持するために、そのデバイスが、自身に割り当てられた窓の期間中に実際にブロードキャストするか否かにかかわらず、自身のノンスカウンタをインクリメントする。この非送信の時間の間、デバイスは、エネルギーを保存するために自身の無線の電源を切ることができる。電源投入時に、デバイスは、セッションノンスの経過を追跡してきており、依然として、後に電源投入することができ、セキュアに通信することができる。代替的に、テレメトリーネットワークセッションの「マスタ」又は「ビーコン」は、ネットワークセッション内で新しい「ラウンド」を開始するごとに、現在のノンスカウンタをセキュアにせずにブロードキャストすることができる。
【００７７】
本発明の特定の実施形態では、ＭＡＣは、各テレメトリーパケットについて計算され、各テレメトリーパケットにアペンドされる。また、本発明の特定の実施形態では、１つのパケットサイズ及びパケット構造が使用される。このようなパケット構造の１つの可能な実施形態が、図１３に示されている。図示するように、本発明によるパケット１３００は、４２ビット（５．２５バイト）ヘッダ１３１０、３０バイトペイロード１３１５、及び３バイトＭＡＣ１３２０から構成することができる。
【００７８】
本発明の特定の実施形態では、ブロック暗号（たとえば、１２８ビットＡＥＳ）をＣＢＣ−ＭＡＣモードで使用して、メッセージの平文のキー付きハッシュ値（メッセージ認証コード、すなわちＭＡＣ）を生成することができる。このキー付きハッシュ値は、図１３に示すように、１３２０において、送信時にそのメッセージ１３１５の暗号化された形態にアペンドされる。これらのパケット１３００及びそれにアペンドされたＭＡＣ１３２０を受信すると、受信機は、パケットペイロード１３１５を解読し、それらの解読されたパケットに関するＭＡＣを計算し、受信機は受信されたペイロード１３１５から導出した、計算されたＭＡＣ値を、本パケット１３００にアペンドされて受信されたＭＡＣ値１３２０と比較する。これらのＭＡＣが一致した場合、パケット１３００は受理される。当然、ＭＡＣが矛盾した場合、パケット１３００は廃棄又は再要求される。ＭＡＣ１３２０が、本発明に従って計算され、各パケット１３１５にアペンドされる場合、従来技術のテレメトリーシステムにおけるパケットごとのＣＲＣの代わりにＭＡＣ１３２０を使用することができる。本明細書でさまざまに詳述したように、特定のパケットがセキュアにされずに送信される限りにおいて、付加的に、（ＣＲＣのような）キー付きでない（unkeyed）完全性チェックメカニズムを適用することができる。この完全性チェックは、ハードウェアＣＲＣの使用を通じて実現することもできるし、代替的に、公に知られたキー及びノンスを有するＣＢＣ−ＭＡＣを使用することによって（たとえば、双方について０ｘ００００００００００００００００００００００００００００００００を使用することによって）実現することもできる。
【００７９】
ＭＡＣ１３２０を使用するこの実施形態では、パケットペイロード１３１５（すなわち、暗号化されるパケットの部分）の長さは３０バイトである（したがって、１ビットのみのノンスレジスタブロック番号フィールド１２３５を必要とする）が、ノンスレジスタブロック番号フィールド１２３５は、同じノンスレジスタ構造１１１０を使用して、４０９６バイトと同じ長さのより長いパケットペイロードの使用を可能にすることができる将来のテレメトリー方式に備えて７ビットに固定することができる。
【００８０】
図１４に示す本発明の代表的な一実施形態によるＣＢＣ−ＭＡＣ生成／検証アルゴリズムでは、最初に、共有セッションキー１０３０（ＣＴＲモード暗号化／解読に使用されるものと同じもの）が、１２８ビットレジスタ１４３０を経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされる。ブロック暗号６２０のｄａｔａ＿ｉ入力６１５には、ノンスの９７ビットの最上位ビット（必要に応じて、ブロック番号フィールドをトランケートする）と最大で最初の３１ビットまでの平文パケットのビット（通常はヘッダ情報から成る）とを連結したもの１４３５をロードすることができる。ノンスレジスタ１１１０のモードビット１２３０は、論理１に設定することができる。典型的な実施形態では、ＣＢＣ−ＭＡＣアルゴリズムがＭＡＣ生成に使用されているのかＭＡＣ検証に使用されているのかにかかわらず、ＣＢＣ−ＭＡＣ処理は、各パケットの解読された形態（すなわち、メッセージ平文）に対して行われる。この実施形態では、したがって、受信されたパケットは、それらのパケットのＭＡＣが検証可能になる前に、解読されなければならない。
【００８１】
図１４の最初のブロック暗号６２０の出力（ｄａｔａ＿ｏ）６３５は、１４３５における９７ビットノンスに連結された平文に続く次の１２８ビットとビット単位でＸＯＲすることができる。次に、このＸＯＲの結果は、第２のブロック暗号１４４０の入力６３０にロードされる。次に、第２のブロック暗号１４４０の出力６３５は、パケット１３００の１３１５からのパケット平文の最後の１２８ビット（必要に応じて０がパッディングされる）とＸＯＲされ、次いで、第３のブロック暗号１４４５によって処理される。この実施形態では、パケットヘッダ及びパケットペイロードのビット合計が２８７ビット以下であるので、ＭＡＣが、第３のブロックの１２８ビット出力（ｄａｔａ＿ｏ）であることから、ＣＢＣ−ＭＡＣのラウンドはそれ以上必要とされない。ＭＡＣが、本発明の代替的な一実施形態に従って、より長いパケットに対して必要とされる場合、出力をＸＯＲしてさらなるブロック暗号６２０に通すことによって、さらなる平文ブロックを処理することができる。一般に、ｍ個のブロックの平文について、ｍ回のＸＯＲ／ブロック暗号ラウンド６３０が必要とされる。ここで、最後のブロック暗号のｄａｔａ＿ｏ出力６３５がＭＡＣ１４５０となる。図１４には、３つのブロック暗号コア６２０、１４４０、１４４５が示されているが、特定の実施形態では、１つのコアしか実際にハードウェアで実施されず、実際には、ＸＯＲ出力は、第１のブロック暗号６２０のｄａｔａ＿ｉ入力６３０へ送られることに留意されたい。図１４に示す３つのコア６２０、１４４０、１４４５は、ＣＢＣ−ＭＡＣアルゴリズムを例示するようにのみ意図されている。
【００８２】
図１４に示すように、本発明の特定の実施形態では、ＣＢＣ−ＭＡＣ出力１４５０の最下位２４ビット（ビット２３〜ビット０）のみが、処理されたパケット１３００の最後にＭＡＣ１３２０としてアペンドされる。これによって、ＣＢＣ−ＭＡＣ関数（この場合、１２８ビット）の基礎となる暗号強度は危険にさらされない。
【００８３】
セキュアにされたセッションに参加する各デバイスは、好ましくは、あらゆるパケット１３３０の送信時及び受信時に自身の各セッションノンスカウンタ１２１０をインクリメントする。このように、一時にセキュアセッションの１つのデバイスしか送信していないので、ノンスインクリメントは、プロキシトークンとして機能し、したがって、複数のデバイスを同時に送信できないことが確実にされる。特定の実施形態では、テレメトリーパケットは比較的長いので、ノードは、特定の状況で、ＢＡＮグループの中でノンス同期を場合によっては喪失する可能性がある。基礎となる通信プロトコルによってサポートされる場合、本発明の特定の実施形態では、デバイスは、自身の現在の平文ノンスをフレームヘッダに定期的に含めて、ノンス同期チェックを提供することができる。典型的な実施形態では、ノンス同期は、一般に、現在のノンス１１１０をＮＡＣＫパケットに常に含めることによって回復することもできるし、基礎となる通信プロトコルに存在するネイティブ回復技法が何であってもそれを通じて回復することもできる。好ましくは、本明細書でさらに説明するように、すべてのデバイスは、ａ）セッションノンスのデバイスのコピー内のカウンタが、デバイスがメンテナンスメッセージで受信するあらゆるノンスと少なくとも同程度の大きさであるべきであるというルール、及び、ｂ）ノンスカウンタが０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦに達すると、新しいセッションキーを計算しなければならないというルール、に従い、ノンスは、２回使用されることはなく、したがって、メッセージの新しさが保証される。
【００８４】
好ましくは、暗号化／解読は、ヘッダ１３１０ではなく、テレメトリーパケットペイロード１３１５に適用されるべきである。本発明のこの実施形態は、攻撃者に利用可能な既知の平文及び必要とされるキーストリームの長さの双方を最小にする傾向がある。さらに、これによって、パケットヘッダ１３１０が物理レイヤハードウェアを通じて伝播している間に、キーストリームマテリアルを計算してバッファリングするブロック暗号時間が与えられる。本発明の特定の実施形態では、単一のブロック暗号コア６２０（たとえば、ＡＥＳブロック暗号）は、暗号化関数及びＭＡＣ関数の双方を実施するのに使用されるが、これは、好ましくは、ランタイムにブロックごとにＣＴＲモードをＣＢＣ−ＭＡＣモードと交互に用いるのではなく、最初に、パケット全体のペイロードデータ１３１５の分量について、ＣＲＴモードを使用して十分なキーストリームマテリアルを生成して記憶することによって行われる。暗号化／解読された１２８ビットブロックが利用可能になると、ＣＢＣ−ＭＡＣモードを使用して、引き続きＭＡＣが生成／検証される。図１５は、本発明の一実施形態によるパケット（３２バイト以下のペイロード）のＣＴＲモード及びＣＢＣ−ＭＡＣモードのＡＥＳベースの混合使用について提案されたハードウェアレイアウトを示している。
【００８５】
一般に、本発明によるノードの一ハードウェア実施態様は、１２８ビットＡＥＳブロック暗号の１つのインスタンス（及び対応する専用の１２８ビットレジスタ）と、１２８ビットＢＡＮキー用のキープアライブストレージ又は不揮発性ストレージとを必要とする。セッションノンスは、セッションキー（Ｒｘ）へのインスティゲーティングデバイスの乱数の貢献のみから成るので、セキュアにされたネットワークのすべてのデバイスは、さらなる送信を行う必要なく、セッションノンスを知っている。図１５に示すように、単一のブロック暗号６２０を使用して、ｄａｔａ＿ｉ入力６３０に対する（入力１５１０を介した）キーストリーム又は（入力１５１５を介した）ＣＢＣ−ＭＡＣ入力のいずれかが処理される。ブロック暗号６２０の出力６３５であるレジスタ１５１５は、平文１５２５とＸＯＲされて、平文データ１５２５が暗号化される。
【００８６】
本発明の特定の実施形態では、（セッションをオープンし、乱数を共有するのに使用されるパケットのように）パケットをセキュアにせずに通信する必要がある限りにおいて、キー付きでない完全性チェックが依然として使用される。この完全性チェックは、たとえば、ハードウェアＣＲＣの使用を通じて実施することもできるし、（双方について０ｘ００００００００００００００００００００００００００００００００のような）おそらく、公に知られた秘密キー及びノンスを有するＣＢＣ−ＭＡＣを使用することによって実施することもできる。
【００８７】
キーストリームマテリアルが生成され、第１のキーストリームレジスタ１５１０及び第２のキーストリームレジスタ１５１５にそれぞれ記憶される。第２のキーストリーム１５１５レジスタのキーストリームマテリアルが使い切られると、第１のキーストリームレジスタ１５１０が、キーストリームレジスタ１５１５に並行してロードされる。第１の平文ブロックは、レジスタ１５２０に記憶され、（第１のキーストリームレジスタ１５１０のキーストリームマテリアルが、第２のキーストリームレジスタ１５１５に移されると）ブロック暗号処理６２０に続く結果の第１のＭＡＣブロックが、第１のキーストリームレジスタ１５１０に記憶される。第１のＭＡＣブロックは、１５２５からの平文の第２のブロックとＸＯＲされ、ブロック暗号６２０に通される。次に、最後のＭＡＣ１５３０の最下位２４ビットが、図１３の暗号化されたデータ１３１５にアペンドされる。
【００８８】
本発明による無線テレメトリーシステムでは、本明細書で開示したように、通常、体内デバイスと体外デバイスとの間の通信セッションを完全に無線で開始、実行、及びクローズすることができる。したがって、論述したように、認可されていない且つ／又は悪意のある関係者が、埋め込まれたデバイス又はＢＡＮの他のノードと通信することを防止することが重要である。しかしながら、実際には、認可されていない体外デバイス（医師プログラマ器具、緊急対応機器等）及びそのユーザ（これらのユーザは、埋め込み物の秘密キーにアクセスできないという意味で認可されていないが、患者のＢＡＮにアクセスする患者の明白な又は暗黙の同意又は指示を有する）が、それにもかかわらず、埋め込まれたデバイスと通信することが必要な状況が発生し得ることが理解されよう。このような状況は、たとえば、埋め込み物自体によって引き起こされていようがいまいが、患者が危機的な事象、さらには、命に関わる生理学的事象を受けている緊急の状況で発生し得る。たとえば、患者は、おそらく意識不明であり、識別マテリアルを有しない場合がある。また、上記プロトコルによる認証が禁止されているか又は実現不可能である過度の不便さのために、上述したような本発明の態様におけるフル認証が実現可能でない状況も発生し得る。たとえば、患者は、医師と会うための予約で大きな距離を移動してきた場合があるが、到着した時に、自身のスマートカード、又は、体外ノードが埋め込み物と通信できるようにするのに必要な他のマテリアルを忘れてきた又は置き忘れてきたことに気付く場合もあるし、患者は、自身の認証パスワードを忘れてしまっている場合もある。これらの状況では、「バックドア」、すなわち、ＩＭＤ ＢＡＮノードとインターフェースする方法（しかし、代表的な実施形態では、ノードの秘密デバイスキーＫｄｅｖを導出することなく）が、限られた原則で、本発明によるシステムのセキュリティプロトコルを迂回する方法でノードへの正当なアクセスを可能にすることができる。したがって、患者の予約を再スケジューリングする不便さが回避され、又は、真の緊急の状況では、患者への重要なケアが可能になる。
【００８９】
本発明の一実施形態では、たとえば或る距離にわたって、たとえば無線プロトコルとして、無線で動作する便利なバックドアメカニズムを提供することができる。一方、本発明の特定の実施形態では、バックドアは、無線ではなく、バックドアをオープンできる機器は、幅広く利用可能な場合がある（したがって、攻撃者が獲得することが容易である）。したがって、特定の実施形態におけるバックドアは、キーを共有するすべてのノードデバイスのセキュリティが、理由が何であれ、バックドアキーの相対的な機密性を危険にさらす動機を有する攻撃者によってノードデバイスの獲得時に取り返しのつかないほど危険にさらされるような方法では実施されない。したがって、無線バックドアが実施される本発明の特定の実施形態では、好ましくは、埋め込み物又はノード（たとえば、アリス１１５）全体の限られた量の機能しか、バックドアキーの通信時に動作可能ではない。たとえば、無線バックドアが利用可能である特定の実施態様では、無線バックドアを使用して、埋め込み物をそれぞれの静止（すなわち「スタンバイ」）モードにのみすることができる。より具体的には、たとえば、ペースメーカは、６０ｂｐｍモードに入ることができる一方、埋め込み可能な除細動器又はニューラルシミュレータ又は薬ポンプは、無線バックドアによって療法一時停止モードにすることができる。
【００９０】
図１６を参照して、本発明の特定の実施形態では、「物理的」バックドア１６１０、すなわち、無線通信チャネル１２０を使用しないアクセス方法、が提供される。これらの実施形態では、バックドアアクセスを求めるデバイス１１０と、アクセスされるノード１１５及び／又はその患者（埋め込められたデバイスの場合）との間の物理的な接触（又は近接近）によってのみ、認証なしのＢＡＮノード１１５へのアクセスが行われる。これは、特定のＢＡＮノード１１５では、ホール効果センサ又は磁気リードスイッチ等の近接場磁気センサの使用によって実施することができる。好ましくは、このセンサ１６１０は、通信チャネルそれ自体をもたらさず、（上記で説明したように）本発明の実施形態によって必要とされる認証要件なしで、モジュールを、機器が埋め込み物（複数可）又は他のノードと通信できるオープンモードにすることのみのために使用される。代替的に、バックドアは、磁気テレメトリー等の近い範囲のテレメトリーの手段を開始することができ、このテレメトリーでは、接近することによって、通信チャネルの使用が実際に可能になる。
【００９１】
また、特定の実施形態では、緊急機器１１０が通信セッションをクローズすると、バックドア１６１０はクローズする。すなわち、オープン通信チャネルがクローズされ、デバイス１１５へさらに通信するには、たとえば本明細書で提供したような適用可能な認証情報が必要とされるか、又は代替的に、別のバックドア通信セッションの確立が必要とされる。このバックドアの使用の効果は、無線ルータ等の無線ネットワーク器具の埋め込まれたリセットボタンと比較することができる。リセットによって、リモートの第三者が無線ルータの態様を変更することが可能になるが、この状態は、デバイスにおける物理的な動作なしでは提供されない。デバイスへのこの物理的なアクセスは、デバイス又はノードに対する変更を管理する管理認証の代理として行われる。
【００９２】
バックドアは、ＫＢＡＮをＢＡＮの他のデバイスへ配信する目的で、ＩＭＤからそのＫＢＡＮを抽出する好ましい手段としても使用することができる。また、バックドアは、ＩＭＤがエフェメラルＫＢＡＮ（ＫＢＡＮとして一時的に使用されるローカルに生成された乱数）を送信することを要求するのにも使用することができる。このエフェメラルＫＢＡＮは、そのテレメトリーセッションの継続時間の間にのみ有効である。バックドアアクセスの結果、ＫＢＡＮ又はエフェメラルＫＢＡＮの無線送信が可能になる実施態様では、エフェメラルＫＢＡＮを回復するのに必要なクレデンシャルに関して、ＩＭＤがＫＢＡＮを送信するために、追加されたクレデンシャルが必要とされる場合がある。このようなクレデンシャルは、たとえば１０秒といった延長された時間期間の間近接スイッチを起動することを含むことができる。ここで、エフェメラルＫＢＡＮの回復は、同じ近接スイッチの起動の時に３秒間だけ認可することができる。
【００９３】
ＩＭＤ１１５に対するバックドア１６１０は、次のように具現化することができる。最初に、アリス１１５及びボブ１１０は、メッセージ１６１５及び１６２０を介してＩＤ（ＩＤＡ、ＩＤＢ）を交換することによって非セキュアチャネル１２０による通信セッションをオープンする。次に、ボブ１１０は、非セキュアチャネル１２０を介して、アリス１１５のバックドア回路部１６１０に電源を投入するようにアリス１１５に依頼する。このバックドア回路部１６１０は、通常ならば電源オフされ、たとえば磁石を接近させることのような、いずれの外部事象にも応答しない。たとえば、オフの時、バックドアは、「ロックされている」と言われる場合がある。バックドア回路部１６１０がオンになり、したがって、バックドア１６１０が「ロック解除」されると、ボブ１１０は、上述したように、磁気スイッチ又はホール効果センサ等の手段によってアリスのバックドアを物理的にオープンすることができる。好ましくは、バックドア１６１０が、所定のタイムアウト前に物理的にオープンされない場合、アリス１１５は、自身のバックドア回路部１６１０の電源を自動的に切り、バックドア１６１０を再ロックして、ホスト患者に接近することが攻撃者に可能である場合に攻撃を回避する。
【００９４】
バックドア１６１０のオープンに続いて、アリス１１５は、自身のＲＦ送信電力を削減し（それによって、信号の有効な送信範囲を削減し）、次いで、メッセージ１６３０によってボブ１１０へＫＢＡＮ１６２５を送信する。アリス１１５は、この送信を行うと直ちに、自身のバックドア回路部１６１０の電源を切る。代表的な実施形態では、ＢＡＮキーの要求は、バックドアプロトコルの開始に暗に示されているので、ボブ１１０によるＢＡＮキーの要求は必要ではない。
【００９５】
図１７は、図１６の実施形態による緊急事態アクセスプロトコルの疑似プロトコル及びデータフローを示している。図１７に示すように、ブリッジデバイス１１０は、バックドアセッション要求１７１０によってＢＡＮキーを取得することができる。バックドアセッション要求１７１０に続いて、２つのノードは、２１５において、セキュアにされていないテレメトリーセッションを確立する。次に、ブリッジデバイス１１０は、バックドア回路部１６１０に電源が投入されることを要求することができる（１７１５）。これに応答して、ＩＭＤ１１５は、１７２０において、自身のバックドア回路部１６１０に電源を投入し、１７２５において、バックドア回路部１６１０に電源が投入されたことをブリッジデバイス１１０に確認する。次に、ブリッジデバイス１１０は、磁気スイッチ、ホール効果センサ、又は、バックドア１６１０を備える他の接近に基づくスイッチを接近させることによって、電源が投入されたバックドア１６１０を起動することができる。これは、１７３０によって示されている。
【００９６】
バックドア１６１０がオープンすると（１７３０）、ＩＭＤ１１５は、１７３５に示すように、バックドアが接近ノード１１０によってオープンされたことに気付き、その後、１６２５において、非セキュアテレメトリーチャネル１２０によってＢＡＮキーを送信する。特定の実施形態では、ブリッジデバイス１１０は、１７３０において、ＢＡＮキーの受信の確認を送信することができるが、典型的な実施形態では、ＩＭＤ１１５は、ＢＡＮキーを送信するとバックドア１６１０の電源を直ちに切り、バックドアのオープンの別の要求１７１５が要求される。
【００９７】
ＢＡＮ内の所与のデバイス又はノードが、上記セキュリティパラメータに従って十分にセキュアなテレメトリーセッションを開始することなく別のノードへデータを送信することが好都合であるさまざまな状況が存在する。たとえば、ＢＡＮは、セキュアな双方向リンクを確立できない送信のみのタイプのセンサである１つ又は複数のノードを含む場合がある。患者アクティベータ（patient activator）のような他のデバイスは、直ちに効果を与えることができるデータを送信することができる。したがって、本発明の実施形態は、データを含むウェイクアップパケットをセキュアにすること、及び、限られた量のセキュアなその後の通信を提供する。この文脈において、十分にセキュアなプロトコルは、一般的なセキュリティの確立と呼ばれ、あまり煩わしくないプロトコルは、ウェイクアップセキュリティ等と呼ばれる。
【００９８】
図１８は、ＢＡＮ内の認可されたデバイス（たとえば、アリス１１５）によって生成されたようなセキュアにされたウェイクアップパケット２０００をブロックの形態で示す図である。ウェイクアップパケット２０００は、特にアリス１１５のＩＤ、パケットを受信するノードのＩＤ等のような、図示しない他のデータも含むことができる。簡潔に言えば、ウェイクアップパケットは、４バイトの暗号化されていないデータ２０１０、３バイトのＭＡＣ２０２０、及び３バイトのＭＣＴＲ２０３０を含む。ＭＣＴＲは、特定のデバイスに関連付けられた３バイトのメッセージカウンタ値である。このメッセージカウンタ値は、ＢＡＮの各デバイス内に記憶され、その特定のデバイスが新しいセキュアなウェイクアップパケットを作成するごとにインクリメントされる。ＢＡＮ内の各デバイスは、ネットワーク内のあらゆるデバイスのオンメモリに常にＭＣＴＲの値を維持する。新しいデバイスがＢＡＮに追加された場合、ＭＣＴＲのすべての値がリセットされる。ＭＣＴＲ値は、ウェイクアップパケット２０００では暗号化されない。ＢＡＮの各デバイスは、ＭＣＴＲ値を維持することに加えて、目的とする受信者（複数可）として各デバイスを識別するのに使用される１バイト値であるレセプタビットマップも含む。
【００９９】
ＭＣＴＲの値の追跡と共にＭＡＣ２０２０の生成によって、セキュリティがプロトコルに提供される。認可された受信デバイス（たとえば、ボブ１１０）は、受信時に、ＭＣＲ値２０３０を評価する。メッセージは、適切でない場合には無視される。適切である場合には、ＭＣＡは次に復号される。データ２０１０は、認証された場合には利用され、認証されない場合には、データは無視される。一実施形態では、ＡＣＫ／ＮＡＣＫメッセージ以外のそれ以上の交換は可能ではない。別の実施形態では、ウェイクアップパケットが認証されると、各ノードは、一般的なセキュリティの開始を必要とすることなく、限られた量のデータ（たとえば、１フレーム）の送信を可能にされる。
【０１００】
図１９は、ＡＥＳブロック暗号２０９０を実行することによる（及び、先に図示して説明したような）ＭＡＣ２０２０の生成を示している。ＡＥＳブロック暗号２０９０の「ノンス」レジスタには、データセット２０４５がロードされる。データセット２０４５は、送信者のＩＤ（ＩＤｓｅｎｄｅｒ）を最上位６バイトとして含み、送信者の現在のＭＣＴＲ値（ＭＣＴＲｓｅｎｄｅｒ）を次の３バイトとして含む。次の４バイトは、送信されるデータであり、最後のバイトは、目的とする受信者（複数可）を示すレセプタビットマップである。ＢＡＮキー２１００も、ＡＥＳブロック暗号２０９０に入力される。ＡＥＳブロック暗号２０９０の結果の出力２１１０から、最下位３バイトのデータが、ＭＣＡ２０２０として指定される。
【０１０１】
図２０は、セキュアウェイクアップパケットを生成及び送信するためのプロセスのフローチャートである。この例では、「アリス」１１５は、「ボブ」１１０へデータパケットを通信することを意図している。アリス１１５は、４バイトのデータ（たとえば、アリスのセンサデータ、患者アクティベータのコマンド等）を生成又は獲得する（２２００）。アリス１１５は、ＭＣＴＲの現在の値をメモリから読み出し（２２１０）、図１９に関して説明したようにＡＥＳブロック暗号２０９０をポピュレートする（２２２０）。ＭＡＣが取得され、アリス１１５は、４バイトのデータ、ＭＡＣ、及びＭＣＴＲ値を含むウェイクアップパケット２０００を構成する（２２４０）。好ましくは、ＢＡＮ内の各デバイスは、許容可能な送信時間を指定している。アリス１１５は、適切な時間窓の期間中、構成されたメッセージを送信する（２２５０）。新しいセキュアウェイクアップメッセージが構成された時、アリス１１５は、ＭＣＴＲをインクリメントする（２２６０）。
【０１０２】
メッセージが適切に受信されたと仮定すると、アリス１１５は、受信者からＡＣＫメッセージを受信することができる（２２７０）。ＡＣＫメッセージが、予測されるが受信されない場合、又は、他のエラーが発生した場合、アリス１１５は、新しいＭＡＣを生成せず、且つ、ＭＣＴＲをインクリメントせずに同じメッセージを再送することができる（２２５０）。ＡＣＫがアリス１１５によって受信されると、ネイティブモードセッションが確立される（２２８０）。一実施形態では、これは、単に、アリスがデータの送信及び（適切な場合に）ＡＣＫメッセージの受信に成功したという点で、セッションが終了される（２２９０）ことを意味する。代替的な一構成では、ネイティブモードセッションを確立する（２２８０）ことによって、セッションに携わるＢＡＮの各デバイスは、たとえば１フレームといった限られた量のデータを送信することが可能になる。したがって、破線で示すように、アリス１１５は、さらなるフレームデータを送信する（２３００）。ネイティブセッションの各デバイスは、送信することが可能になり、したがって、アリス１１５は、ＢＡＮの別のデバイスからデータのフレームを受信することができる（２３１０）。ＡＣＫ／ＮＡＣＫメッセージが可能になり（２３２０）、セッションは、その後、終了される。
【０１０３】
このように、ウェイクアップパケットがセキュアにされ、少量のデータが、一般的なセキュリティを確立せずに送信可能である。大量のデータを送信する必要がある場合、前述したように、一般的なセキュリティプロトコルが実施される。
【０１０４】
図２１は、たとえばボブ１１０といった受信ノードが、可能性のあるセキュアにされたウェイクアップメッセージの受信時に用いるプロセスのフローチャートである。ボブ１１０は、メッセージを受信し（２４００）、送信者を識別する（２４１０）。これは、たとえばアリス１１５への送信用に割り当てられたネットワークタイムスロットに基づいて行うこともできるし、他の識別手段に基づいて行うこともできる。いずれの場合も、ボブ１１０は、それが、その称するところ、メッセージを送信したアリス１１５であること、及び、ボブ１１０が目的とする受信者であることを識別する。ボブ１１０は、送信されたメッセージからＭＣＴＲ値を抽出し（２４２０）、ボブ１１０がアリス１１５についてメモリに記憶しているＭＣＴＲ値と比較する（２４３０）。ステップ２４４０において、受信されたＭＣＴＲ値が、ボブ１１０がアリスについて記憶している値よりも小さい場合、メッセージは無視される（２４５０）。ＭＣＴＲ値が、記憶されている値よりも大きい場合、ボブ１１０は、受信されたＭＣＴＲが正しいと一時的に仮定し（２４６０）、受信された値の利用に進む。同様に、受信されたＭＣＴＲ値が、記憶されている値に等しい場合、ボブ１１０は次のステップに進む。
【０１０５】
いずれの場合も、受信されたＭＣＴＲを利用して、アリス１１５と同じ方法で、ＡＥＳブロック暗号２０９０によってＭＡＣが計算される。ボブ１１０によって計算されたＭＡＣ値は、ボブ１１０によって受信されたＭＡＣ値と比較される（２４８０）。これらのＭＡＣ値が一致しない場合、メッセージは無視される（２４９０）。これらのＭＡＣ値が一致する場合、ボブ１１０は、ネイティブモードに入り（２５００）、それに従ってデータを受理する（２５１０）。ボブ１１０は、アリス１１５に関連したＭＣＴＲ値を更新する（２５１５）。この結果、増分値が、アリス１１５によって送信されたＭＣＴＲ値の有効に加えられる。オプションとして、ボブ１１０は、ＡＣＫ／ＮＡＣＫメッセージをセキュアにして送信することができる（２５２０）。セッションは、その後、終了される（２５３０）。
【０１０６】
代替的な一実施形態では、ネイティブモードに入った（２５００）各ノードは、さらなるデータのフレームを送信することができる。したがって、ボブ１１０は、さらなる量のデータをアリス１１５へ送信することができ（２５４０）、同様に、アリス１１５は、さらなるデータのフレームを送信することができる（２５５０）。セッションキーは、セッション間の新しさを保証するために、ＭＡＣ出力の一部によって定められる。各ノードは、適切なＡＣＫ／ＮＡＣＫメッセージ２５２０を送信することが可能になり、セッションは、その後、終了される（２５３０）。ＡＥＳ＿ｏｕｔ２１１０、ＢＡＮキー２１００がＫｓｅｓの代わりに利用され、ノンスカウンタの最下位３バイトがＭＣＴＲ値で開始され、次に最上位２バイトがＭＣＴＲ値の最下位２バイトを利用し、最上位バイトが０で開始される点を除いて、パケット及びフレームは、一般的なセキュリティに関して、前述したようにセキュアにされる。
【０１０７】
送信前に、オプションとして、ユーザデータの４バイトにデータプライバシー（暗号化）を適用することができる。暗号化及びその後の解読は、（ちょうどネイティブモード通信について行われるように）これらの４バイトのユーザバイトを４バイトのキーストリームとＸＯＲすることによって実現することができる。４バイトのキーストリームは、２１１０の未使用バイトから得ることもできるし、アリス及びボブの双方に知られている異なるノンス値を使用したブロック暗号の別の実行から得ることもできる。
【０１０８】
本発明のさまざまな実施形態を説明してきたが、これらのさまざまな実施形態は、例示であって限定することを意図するものではない。開示された主題の複数の部分は、本発明の精神及び範囲内にあり、明示的に述べられていない実施形態において組み合わせることができる。
【技術分野】
【０００１】
本発明は、データ通信設定においてセキュア通信を提供することに関し、特に、埋め込み可能医療デバイスと外部デバイス管理ハードウェアとの間のテレメトリーにおけるセキュリティ、埋め込み可能医療デバイスと他の埋め込み可能医療デバイスとの間のテレメトリーにおけるセキュリティ、及び外部医療デバイスと他の外部医療デバイスとの間のテレメトリーにおけるセキュリティの提供においてセキュアな通信を提供することに関する。
【背景技術】
【０００２】
埋め込み可能医療デバイス（「ＩＭＤ」）に関する技術の改良、特に、電力貯蔵、保全、及び小型化の分野におけるＩＭＤに関する技術の改良によって、現代の埋め込み可能医療デバイスには無線電気通信機能を装備することが可能になっている。このような通信の利益には、たとえばバッテリー寿命の残量、発生した治療イベント数、又は特定の患者の健康データといった情報を送信するようにＩＭＤに要求する能力、及び、治療法、治療頻度等を変更する命令をデバイスへ送信する能力が含まれる。これらの通信のすべては、患者の健康及び治療成果を最大にするすべての関係者側の必要性によって動機付けられており、この成功の判断基準の一環として、ＩＭＤを患者から除去しなければならない状況又は患者に関する何らかの侵襲的な処置が必要となる状況を回避するという要望によっても後押しされている。何らかの外科的又は侵襲的な処置に伴う危険に付随するものは、適用可能な標準治療（standard of care）に従ってこのような処置が行われるとき、このような処置に関連付けられるコストである。
【０００３】
ＩＭＤを患者内に残している間、ＩＭＤと通信する利益を利用する際に、無線通信が、理想的には適しており、現在まで、ＩＭＤがその埋め込まれた状態にある間にＩＭＤと情報を定期的に交換する唯一の実用的な方法である。したがって、通信が、ＩＭＤ若しくは管理デバイスへ又はＩＭＤ若しくは管理デバイスから送信されているか否かにかかわらず、さらに、（たとえば、更新された命令がＩＭＤへ送信されることとは対照的に）測定値が送信されているか否かにかかわらず、ＩＭＤ管理のために電気通信を使用することには、ＩＭＤへの通信及びＩＭＤからの通信、或いは、体外（すなわち、埋め込まれていない）ＩＭＤ管理デバイス間の通信（本明細書では、交互に「テレメトリー」と総称する）が含まれ得る。
【０００４】
テレメトリー、特にＩＭＤテレメトリーは、病状又は他の健康状態の治療をより便利且つ効果的にすることができるが、テレメトリーを使用することによって、第三者がこのようなデバイスの管理に干渉できないように保証することが重要である。たとえば、盗聴のみであっても、たとえば医療保険のプライバシー及び説明責任に関する法律（「ＨＩＰＡＡ」）といった特定のデータプライバシー制度のもとで保護され得る患者データを危険にさらすおそれがある。さらに危ういことには、管理デバイスから医療デバイスへのテレメトリー通信が干渉を受ける場合、意図されていた重要な療法が、埋め込みデバイスをホスティング（hosting）している患者に対して施されないおそれがあり、その結果、おそらく、治療効果は準最適なものになる。悪意のある第三者が、通信をインターセプトして、その通信を、デバイスへの偽の命令に置き換えた場合、又は、正当な命令であってもそれを繰り返して、正しくない療法若しくは過度の療法を埋め込み物に施させた場合には、埋め込み物のホストに対して悪影響を与えるおそれがある。
【０００５】
現在まで、ＩＭＤテレメトリーの用途に適したほとんどの一般的な無線通信プロトコルは、方向性を有するプロトコルではなく、「ブロードキャスト」のプロトコルである。したがって、ＩＭＤがテレメトリー信号の範囲内にある（又は、通信がＩＭＤから開始されたときは、受信デバイスがＩＭＤの範囲内にある）場合、その信号へのアクセスが介護人及び／又は患者によって意図されたものであろうとなかろうと、その信号の範囲内にあるいずれの受信デバイスも、その信号にアクセスできると一般に想定することができる。
【０００６】
ＩＭＤを伴う多くのテレメトリートランザクションの距離範囲が短いことによって、或る程度、或る種の物理レイヤ認証は達成されている。換言すれば、認可されていない関係者が送信デバイスの非常に近くにいなければならないことから、盗聴者（又は盗聴者のツール）の物理的な存在は、このような情報を正当に送信又は受信する関係者に視覚的にはっきりと見えることになるので、ＩＭＤに関係する通信へのほとんどの不正アクセスは実現不可能である。しかしながら、テレメトリーの適用の範囲は絶えず拡大しており、或る段階で、たとえば、患者が医師待合室に腰掛けている間、対象とする受信デバイスが完全に別の部屋にあっても、ＩＭＤにインターロゲートすることが考えられ得る。ＩＭＤと外部ハードウェアとの間の通信に必要な距離が大きくなるにつれて、侵入者又は盗聴者が、通信信号の受信、通信信号への干渉、さらには通信信号の操作を行う機会も多くなる。
【０００７】
また、メッセージが「新鮮」であることも重要である。すなわち、メッセージが、近時において一度しか送信されていないことも重要である。たとえば、療法が適用されているにもかかわらず、患者の生理的状態の変化がないことを偽って示す診断センサからのデータの複製通信の結果、療法が過度になるか、又は付帯リスクを有する他の不要な医療介入が行われるおそれがある。メッセージプライバシー（すなわち、暗号化）に加えて、真のデータセキュリティには、メッセージの完全性及びメッセージの新しさ（message freshness）の双方も必要とされる。３つのすべてがなければ、悪意のある第三者によって悪用されるおそれのある隙間が存在するか、又はさらには、悪意がなくてもエラーを許容するおそれのある隙間が存在する。もちろん、このような悪用が起こり得るか否かは、特に設計の立場から関連はない。テレメトリーのセキュリティは、検討されているインターセプトのシナリオから生じる問題の実際の可能性に関係なく、あらゆる盗聴又はインターセプトを防止するように保証されるべきである。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
テレメトリーセキュリティに対するこれまでの手法は、たとえば、サーバベースの認証及びストレージを伴っていた。このように、永久的なキー情報が、機器上に記憶されることはなかった。しかしながら、この手法では、２４時間利用可能なサーバへのセキュアな通信チャネルが必要とされる。また、この手法では、臨床医は、ボディエリアネットワーク（ＢＡＮ）デバイス又はノードを管理するよりも前に、サーバシステムに対して認証を受ける必要がある。
【０００９】
代替的に、バイオメトリックトークン（キーフォブ（key fob）等）が、ＩＭＤサポート機器をＩＭＤに対して認証するのに使用されてきた。しかしながら、この手法によって認証キー（バイオメトリックキー及びＩＭＤキーの双方）が喪失されやすく、トークンも、ＩＭＤ管理を行うために提示する患者によって忘れられる可能性があり、これによって、不都合なことに、ケアの延期が必要となりがちである。パスワードによって増強されたトークンも、同様に、喪失されやすく、ノンコンプライアンス（トークンを予約に持ってこない、又は、認証情報を忘れる）を受けやすく、同様に、喪失又は盗難にあった場合に、危険にさらされやすかった。
【課題を解決するための手段】
【００１０】
本発明は、特にＩＭＤ及び他の医療デバイスの管理に良く適したテレメトリー通信のセキュアシステムを提供する。ＩＭＤへの通信及びＩＭＤからの通信、並びに、外部デバイスへの通信及び外部デバイスからの通信を保護するシステムが提供される。このシステムは、通信ノードへの通信及び通信ノードからの通信、特にＩＭＤへの通信及びＩＭＤからの通信が正当なものであることを保証するために、１つ又は複数の認証方法と共に、暗号化のシステムを実施する。特定の実施の形態では、たとえば、データ暗号化及びキー管理の厳格な手法によって、正当性が保証され、好ましくは、認証は、認証カード又はトークンを保持することに加えて、少なくとも１つのモダリティを使用してセキュアにされる。
【００１１】
特定の実施の形態では、本発明は、近接性に依存した「バックドア」を提供する。当該バックドアは、特定の患者の医療デバイスのネットワーク内のノード間又はモジュール間の通信を可能にするのに通常必要とされる認証情報なしで任意のＩＭＤへのアクセス及びその管理を可能にすることができる。医療デバイスのネットワークは、「ボディエリアネットワーク」又は「ＢＡＮ」と呼ばれる。また、本発明は、いくつかの実施の形態では、認証が、認証情報を実際に送信する（もちろん、認証情報が危険にさらされやすくなるおそれがある）ことなく実行されるという点で、厳密認証、すなわち、同一性のゼロ知識証明も提供する。
【００１２】
患者及び認可された介護人に反する興味又は動機を有する、認可されていない第三者は、盗聴者の素性、ロケーション、又は動機にかかわらず、本明細書では、「攻撃者」と総称される。攻撃者は、通信を実際に混乱させることなく単に盗聴することを望む場合もあるし、場合によっては患者に関する保護されている健康情報を取得することを望む場合もあるし、ＢＡＮノード製造者に独自のＢＡＮノードの振る舞いの態様を知りたい場合もある。これらの目的のために、本発明の実施の形態は、暗号の使用を通じてメッセージプライバシー（すなわち、暗号化）を提供する。
【００１３】
十分な電気通信能力及び計算能力を有する攻撃者は、ＢＡＮのノード間のすべての通信をインターセプトして制御し、ＢＡＮのノード間のメッセージの削除、変更、複製、又は別の変更のいずれかを行うことができる場合があることも考えられ得る。本発明の実施の形態は、たとえばＩＭＤへの命令及びＩＭＤによって診断ノードに提供される情報が正当なものであることを保証するメッセージ認証プロトコルの使用を通じて、メッセージの完全性（すなわち、メッセージ認証）を提供する。同様に、新しく生成されたセッションキー及びトークンベースのシステムを通じて、又は、本発明の代替的な実施の形態ではタイムスタンプの使用を通じて、メッセージの新しさを保証することもできる。本発明は、特定の実施の形態では、メッセージの完全性（送信されたメッセージが、それらのメッセージが対象とする受信者によって、変更されていない状態で受信される）及びメッセージの新しさ（メッセージが、タイムリーに受信され、且つ、攻撃者によって送信された、前に送信されたメッセージのコピーではない）という補助的な要請に基づいて、メッセージが、秘密キーを有しない者からセキュアに維持されることを可能にする。
【００１４】
本発明の実施の形態によって与えられる保護にもかかわらず、通信の保護は、好ましくは、最適な患者ケアという全体的な原則によって動機づけられ、且つ、必要な場合には、その全体的な原則を補助する。したがって、本発明の特定の実施の形態は、特定の緊急事態又は他の強制的な状況において、健康への不利な影響を防ぐために、緊急事態介護人がデバイスに対して自身を認証する時間又は証明書を有するか否かにかかわらず、この実施態様の特定のセキュリティの機能を迂回するデバイスに対して、「バックドア」によるデバイスとの通信を許可することができる。
【００１５】
本発明の実施の形態によるセキュリティメカニズム及びプロトコルは、セキュリティサービスがセットアップされて、通信デバイスのうちの少なくとも１つに関して（迂回されるのではなく）有効にされていることを必要とし、ブロック暗号の一実施態様の使用をさらに必要とする場合がある。他の実施の形態では、本発明を実施するＢＡＮのすべての通信デバイスは、同一のボディエリアネットワークキーＫＢＡＮを共有し、新しい各テレメトリーセッションの開始時に新しいセッションキーＫｓｅｓを協同して生成する。最初に、このようなデバイス識別情報交換が、通信セッションをオープンするために必要とされるセキュアにされていない交換を介して行われる。着信するパケット及び発信するパケットの双方のパケット長は、好ましくは、セッションの継続時間の間固定され、指定された長さに合致しないパケットは、好ましくは、ネットワークの物理レイヤにおいて拒絶される。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態によるボディエリアネットワークの一般的なネットワークトポロジを示す図である。
【図２】本発明の実施形態によるネットワークノード間のネットワークキーのセキュアな送信のプロトコルを示す図である。
【図３】ネットワークキー送信プロトコルの一代替的な実施形態を示す図である。
【図４】本発明の一実施形態による２つの体外デバイスを有するボディエリアネットワークのトポグラフィを示す図である。
【図５】本発明によるネットワークキー伝播プロトコルの一代替的な実施形態を示す図である。
【図６】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図７】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図８】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図９】本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。
【図１０】本発明の実施形態によるセッションキーの生成のデータフロー図である。
【図１１】本発明の実施形態によるメッセージのＣＴＲモードの暗号化及び解読のデータフローを示す図である。
【図１２】本発明の実施形態によるノンスレジスタのデータ構造を示す図である。
【図１３】本発明の一実施形態によるテレメトリーパケットのデータ構造を示す図である。
【図１４】本発明の一実施形態によるメッセージの暗号化／解読及び認証のデータフローを示す図である。
【図１５】本発明の一実施形態による概略的なハードウェアアーキテクチャを示す図である。
【図１６】本発明の一実施形態の緊急事態アクセスプロトコルのネットワークトポグラフィを示す図である。
【図１７】本発明の一実施形態による緊急事態アクセスプロトコルの疑似プロトコル及びデータフローを示す図である。
【図１８】セキュアにされたウェイクアップパケットのグラフィカル表現を示す図である。
【図１９】セキュアにされたウェイクアップパケットのＭＡＣの生成を示すブロック図である。
【図２０】セキュアにされたウェイクアップパケットを送受信するプロセスのフローチャートである。
【図２１】セキュアにされたウェイクアップパケットを送受信するプロセスのフローチャートである。
【発明を実施するための形態】
【００１７】
本発明による無線ネットワークの一セキュリティ実施様態の実施形態は、さまざまな層のセキュリティ又はさまざまな度合いの多要素認証を実施することができる。本明細書で検討されるこれらのセキュリティの層は、たとえば、通常、入出力ファシリティ（たとえば、ポート）、１つ又は複数の中央処理装置（チップ等）、及び複数のメモリロケーションを有するスマートカード、すなわち小さなプラスチックカード又はフォブによって実施することができる。スマートカード技術は、「ユーザが有する物（something the user has）」レベルのセキュリティとして、単独で機能することによるか、又は、たとえば「ユーザが知っている物（something the user knows）」（すなわち、パスワード）若しくは「ユーザである物（something the user is）」（すなわち、ユーザに関連付けられたバイオメトリックパラメータ）と結び付けられた多要素認証のコンポーネントとして機能することによるかのいずれかで、セキュリティを実施するのに使用することができる。本発明に従って実施されるようなカードは、好ましくは、時に「プロセッサカード」又は「マイクロプロセッサ多機能カード」と呼ばれるタイプのメモリ、少なくとも１つのプロセッサ、及びデータ処理機能を有する。これらのカードは、好ましくは、国際標準化機構の、電気接点を有する集積回路カード（Integrated Circuit Cards with Electrical Contact）の標準規格ＩＳＯ７８１６で指定されたタイプのものとすることができ、この仮定は、本明細書の代表的な実施形態に関してなされる。特定の実施形態では、特定の患者認証は、スマートカードデバイスを介して管理されるが、しかしながら、ＩＭＤのデバイスキーは、好ましくは、暗号化されていない形ではスマートカード上に記憶されない。
【００１８】
本発明のいくつかの実施形態は、本明細書で、テレメトリー通信のタイムライン、すなわち、テレメトリー通信の「新しさ」として知られているものの確証を提供する。たとえば、一度正当に規制することができる治療法（therapeutic modality）は、悪意のある第三者によって繰り返し可能なものであってはならない。第三者が、単なる暗号化のみに基づいた通信を盗聴できる場合、その第三者は、その命令を反復して繰り返すことができる。悪意のある第三者が、たとえＩＭＤへのメッセージの内容を知らない場合であっても、第三者は、このメッセージを繰り返すことが患者のためにならないことを合理的に予測することができる。第三者は、十分な試行錯誤によって、メッセージの内容を完全に無視してでも危険な影響を実施するおそれがある。したがって、本発明の実施形態は、メッセージの新しさを保証してこのような攻撃を防止するシステムも達成する。本明細書では、「暗号化された」及び「セキュアにされた」という用語は、一般に同義ではないことが理解されよう。暗号化されたメッセージは、プライバシー（すなわち、機密性）のみが保証されているメッセージである。セキュアにされたメッセージは、プライバシー、完全性、新しさ、及び同一性が保証されているメッセージである。この後者の概念は、ユーザ認証（メッセージが、それを明らかに送信した人（又はノード）から実際に来たものである）及びメッセージ認証（メッセージが、送信者によって送信された形態を有し、且つ、正当な送信者によって意図された時刻にのみに送信されたものであり、それ以外の時に送信されていないもの）の双方の認証の概念を組み込んでいる。
【００１９】
本明細書では、通信を送信又は受信するノード（すなわち、医療デバイスの文脈では、埋め込まれたデバイス若しくは外部のデバイス、センサ、プログラマ、モニタ、又はＢＡＮ内の他の器具）を暗号学の慣習に従って「アリス（Alice）」又は「ボブ（Bob）」と呼ぶ場合がある。デバイスのユーザ又は患者について明示的に述べていない限り（たとえば、アリスの患者又は「ホスト」、すなわち、アリスデバイスを埋め込まれている患者）、アリス又はボブはデバイス又はノードを指す。また、特定の実施形態では、スマートカードが、信頼される第三者認証局に通常関連付けられているいくつかの機能を実行でき、カードの保持者による（たとえば、保持者のパスワード及びバイオメトリック認証による）認証時に、カードが、システム内の信頼される関係者とみなされ、カードの保持者のＩＭＤに対応するＩＭＤキーを保持するという点で、スマートカード（スマートカードリーダ／ライタに挿入されている時のスマートカードを含む）という用語を使用する。システムの認可されたアドミニストレータ又はユーザがメッセージの送信又は受信を可能にすることを意図していない第三者（又は、このような人物の制御下にあるデバイス）は、一般に、「攻撃者」と呼ばれる。また、暗号学と一致して、ビット単位の排他的論理和演算（すなわち、ビット単位のモジュロ２加算）については、シンボル
【００２０】
【数１】
又は「ＸＯＲ」を使用し、連結については、シンボル｜又は‖を使用する。本明細書ではしばしば、ソフトウェア又はハードウェアが、感覚のあるエージェントであることを示唆しているように思われるよう、特定のソフトウェアプロセス又はハードウェアコンポーネントは、特定の情報を「知っている」、「要求する」、「予測する」、若しくは「送信する」、又は、特定の機能若しくはアクティビティを実行する（たとえば「計算する」）として説明される。このような擬人化した言及は、問題となっているハードウェア又はソフトウェアが意識、動機、又は知性（人工的又はそれ以外）を有することを示すか又は暗に意味することを意図するものではなく、これらの表現は、一般に、人間であろうが、又は他のハードウェア若しくはソフトウェアのプロセス若しくはコンポーネントであろうが、それによってプログラミング又は命令された通りにソフトウェア又はハードウェアが自動的に挙動することを示すのに使用されることが、当業者には理解されよう。たとえば、特定の値を「予測する」と言われるソフトウェアプロセスは、規則に従わない引数がエラーハンドリングコードによって処理される、特定の変数タイプ又は値であるように指定された引数を有するソフトウェア関数を指す場合がある。
【００２１】
図１は、本発明の実施形態によるボディエリアネットワークのトポグラフィを示している。プログラマ「ボブ」１１０及びＩＭＤ「アリス」１１５から成る一例示のボディエリアネットワーク（ＢＡＮ）１００が示されている。これらの２つのノード、アリス及びボブは、非セキュアチャネル１２０を介して非セキュアテレメトリーセッション１１７をすでに確立している。プログラマ１１０は、認証デバイス１３０との（たとえば、有線接続１２５を介した）セキュア通信用に接続されている。認証デバイス１３０は、ここでは、バイオメトリック入力窓１３５を有するスマートカードリーダ／ライタである。これらの実施形態によれば、本明細書でより十分に説明するように、各場合において、患者によって携行されてＩＭＤ管理で使用されるスマートカードに基づき、セキュリティの増大する順に、以下の情報を認証データとして使用することができる。
【００２２】
本発明の典型的な実施形態では、最低でも、デバイスの患者（又は、適用可能な場合には、他の認可されたアドミニストレータ）が、ＫｄｅｖＡ（デバイス１１５用のキー）、ＩＤＡ（デバイス１１５用の識別番号）として注記される情報を含むスマートカード１４０（患者が有する物）を提示する。さらなるセキュリティは、患者のスマートカード１４０にパスワードＫＰＷ１５０を加えたもの、すなわち、本明細書でＥ（ＫｄｅｖＡ；ＫＰＷ）、ＩＤＡとして注記されるものを使用することによって提供することができる。パスワードＫＰＷ１５０（患者が有する物であり、且つ、患者が知っている物）も、スマートカード素子１４５上に記憶されている。Ｅ（ＫｄｅｖＡ；ＫＰＷ）は、すなわち、デバイスキーＫｄｅｖＡがパスワードＫＰＷ（すなわち「パスワードキー」）によって暗号化されたものである。ここで、Ｅ（ｘ；ｙ）は、キー「ｙ」を使用して「ｘ」をセキュアにするのに使用される暗号化の関数を示し、別の言い方をすれば、特定の暗号文＝Ｅ（平文；キー）を示す。特定の実施形態では、ユーザの認証は、患者のスマートカード１４０又は非電子的な情報カードに、パスワードＫＰＷ１５０を加え、バイオメトリックスキャンＫｂｉｏ、すなわち「バイオメトリックキー」１５５（患者が有する物であり、知っている物であり、且つ、患者である物）を加えたもの、すなわち、本明細書でＥ（Ｅ（ＫｄｅｖＡ；ＫＰＷ）；ＫｂｉО）、ＩＤＡとして注記されるもの、によって実行される。
【００２３】
図１に示すように、アリスの患者（図示せず）には、スマートカードデバイス１４０が提供されている。スマートカードデバイス１４０は、メモリ、ファームウェア、ローカルストレージ、及び／又は組み合わせ素子１４５を含む。アリスの患者は、スマートカード１４０をパスワード１５０及び患者のバイオメトリック特徴で初期化している。患者のバイオメトリック特徴は、ここでは、指紋１５５である。
【００２４】
本発明の特定の実施形態では、スマートカード１４０、又は、スマートカードリーダ１３０若しくはオンボードプログラマノード１１０に取って代わる或るインターフェースとインターフェースするＵＳＢ／Ｆｉｒｅｗｉｒｅ（登録商標）キーフォブを利用して、本明細書のセキュリティ方式の態様を実施することができる。特定の実施形態では、このようなスマートカード又はキーフォブは、すでに実施され且つスマートカード１４０又はキーフォブに実装された、特定の暗号及びメッセージ認証コード（ＭＡＣ）、たとえばチップハードウェアに実施された暗号及びメッセージ認証コード（ＭＡＣ）、又は代替的に、ＲＯＭ又はフラッシュメモリに記憶されている暗号及びメッセージ認証コード（ＭＡＣ）を有し、これらは、スマートカード又はキーフォブ上の素子１４５として抽象的に示されている。
【００２５】
ＩＭＤを含むＢＡＮをセットアップ又は初期化して、上述したプロトコルに従ってＢＡＮキーを伝播するときに、まず、患者は、自身のＩＭＤの認証マテリアル（たとえば、スマートカード１４０）をブリッジデバイス１１０に提供する。このスマートカード１４０は、たとえば、ＩＭＤ１１５と共に発行する（且つ、術後に患者に与える）こともできるし、前もって存在する患者のスマートカードデバイス１４０上に必要な情報を入力することもできる。特定の実施形態では、患者は、自身のスマートカード１４０を（ここでは、インターフェースデバイス１３０を介して）ブリッジデバイス１１０内に挿入した後、自身のパーソナルパスワードＫｐｗ１５０をブリッジデバイス１１０内に入力するように促され（プログラマ１１０に実装されて存在するＧＵＩを介して、又は、適切な別個のインターフェースを介して、理想的には、患者自身のパーソナルメモリから入力される）、さらに、指紋１５５又は網膜スキャン等、患者の一意のバイオメトリック識別子から導出された値であるバイオメトリックキーＫｂｉｏを提示する。ブリッジデバイス１１０は、好ましくは、Ｋｐｗ１５０及び／又はＫｂｉｏ１５５をしばらくの間記憶することなく、スマートカードリーダ１３０を介してパーソナルパスワードＫｐｗ１５０及びバイオメトリックキーＫｂｉｏ１５５をスマートカード１４０に引き渡す。スマートカード１４０は、Ｋｐｗ１５０及びＫｂｉｏ１５５を使用して、ＫｄｅｖＡ１７０を解読することができる（すなわち、スマートカードは、Ｋｐｗ１５０及びＫｂｉｏ１５５を使用して、ＫｄｅｖＡ１７０を求めることができる）。特定の実施形態では、認証が完了するまで、暗号化されていないＫｄｅｖＡ１７０が、当初、スマートカード１４０のＲＡＭ若しくは他のメモリ又はストレージ素子１４５に存在する場合がある。認証が行われると、好ましくは、ＫｄｅｖＡ１７０は、その後、削除され、ＫｄｅｖＡ１７０の暗号化された形態に置き換えられる。代替的に、スマートカード１４０の代わりに非電子的な認証マテリアルを、ＩＭＤのＫｄｅｖＡがテキスト又はバーコードの形態で印刷された非電子的カードの形態でブリッジデバイス１１０に提供することができる。ＩＭＤのＫｄｅｖＡは、ＢＡＮによって、図３のプロトコルに従い伝播される。
【００２６】
本発明のこの実施形態のキー配信プロトコルは、ＩＭＤからブリッジデバイスへの現在のＢＡＮキーのセキュア無線配信、及びブリッジデバイスからＩＭＤへの現在のＢＡＮキーのセキュア無線配信を、もっぱら患者のＢＡＮ内において提供する。このプロトコルは、さらに、ＢＡＮキーそのものだけでなく、送信者及び受信者の認証及び検証も実行する。その上、本発明は、スマートカード１４０が通信に利用可能であることが必要条件であるために、攻撃者が、攻撃者のＢＡＮ内へデバイスを組み入れたり、ＢＡＮキーの配信中にデバイスになりすましたり、配信プロセスそのものを盗聴したり、以前の通信の複製に基づいて反復攻撃を企てたりすることも防止する。好ましくは、ＫｄｅｖＡキーは、ブリッジデバイス１１０上ではなく、スマートカード１４０上にセキュアに留まる。したがって、たとえブリッジデバイス１１０が攻撃者に盗まれた場合であっても、攻撃者は、デバイスキーＫｄｅｖＡを知ることは決してない。本明細書で一般にＫｄｅｖＸ（ＫｄｅｖＡ１７０等）として示されるデバイスキーは、好ましくは、アリス１１５等の埋め込みデバイスに関しては工場でプログラミングされ、ブリッジデバイス１１０、スマートローカルデバイス、及びダムローカル（dumb-local）デバイスに関しても同様に工場でプログラミングすることができる。これらの後者のデバイスは、外部でラベル付けされたＫｄｅｖを有することもできるし、必要に応じて生成されて割り当てられた乱数Ｋｄｅｖを有することもできる。ダムローカルデバイスの限界のために（特に、ダムローカルデバイスがヒューマンインターフェースを有しないという点で）、このようなデバイスは、好ましくは、工場で割り当てられて外部でラベル付けされたＫｄｅｖＸを有する。代替的に、本明細書で説明する、工場で割り当てられる実施態様又は工場でプログラミングされる実施態様のいずれも、通常の「ファームウェアアップグレード」手順を介したフラッシュメモリの更新に付随して供給されるＫｄｅｖＸ又は類似の情報を代わりに有することができる。本明細書では、異なるキー値及び他の変数を指定するのに、次の省略形が使用される。ＫｄｅｖＸは、Ｘの名称を有する指定されたノードの秘密デバイスキーである。ＫＢＡＮは、現在のＢＡＮセッションキーである。ＩＤＸは、デバイスＩＤである。ここで、Ｘは、指定されたノードの名称である。
【００２７】
本発明の代表的な実施形態におけるさまざまなプライバシー及びメッセージの完全性の機能を実施するのに適したセキュリティ方式は、次世代暗号化標準（「ＡＥＳ」）である。ＡＥＳは、Ｒｉｎｊｄａｅｌと類似しているが、固定のブロックサイズ及びキーサイズを有し、米国連邦政府及び通信業界によって一般に使用される標準である。ＡＥＳは、本明細書でさらに説明するように、構成ＣＴＲ＋ＣＢＣ−ＭＡＣで適切に使用することができる。
【００２８】
ＢＡＮキーは、特定のキーの実施形態では、体内デバイス、特にＩＭＤ１１５等の埋め込み物から、ＢＡＮ１００の他の体外「ブリッジ」デバイス１１０へセキュアに通信される。また、ＢＡＮキーは、ＢＡＮ１００のブリッジデバイス１１０から埋め込み物１１５へもセキュアに通信されるべきである。本発明の実施形態によれば、２つの体外デバイス１１０間の通信又は体内デバイス１１５と体外デバイス１１０との間の通信を提供する基礎となる通信セッション１２０が存在する。この通信セッション１２０は、セキュアにされていない場合がある。セキュア通信（このようなセキュリティは、暗号化だけでなく完全性及び新しさの確証も含む）は、埋め込まれたデバイス１１５によって保持された認証マテリアルによって提供される。埋め込みデバイス１１５は、ＢＡＮキーをブリッジデバイス１１０へ配信する。ブリッジデバイス１１０は、適切な認証マテリアル１６０と、乱数生成ファシリティ１６５等のプロセスとを所有する。埋め込まれたデバイス１１５は、適切な認証マテリアル１６０とプロセスとを所有するブリッジデバイス１１０からＢＡＮキーを受信することもできる。本発明の実施形態によれば、以下のプロトコルによって、本発明のセキュリティプロトコルを使用できるブリッジデバイスへのＢＡＮキーのセキュアな無線配信が可能になる。
【００２９】
図２は、本発明の特定の実施形態によるネットワークノード間のネットワークキーのセキュアな送信のプロトコルを示している。図２に示すように、埋め込みアリス１１５は、ボブ１１０がＢＡＮキーを確立又は取得することを望むことをアリス１１５に示す「ＢＡＮキーを配信する（deliver BAN-key）」セッション要求２１０をブリッジデバイスのボブ１１０から受信する。アリス１１５及びボブ１１０は、最初に、テレメトリック通信セッション２１５を開始しなければならない。このテレメトリック通信セッションでは、アリス１１５は、新しく生成された乱数ＱＡをボブ１１０に提供する。次に、アリス１１５の人間のアドミニストレータ（たとえば、アリスデバイス１１５が埋め込まれた患者）は、スマートカードリーダを通じて電子認証マテリアル（ＥＡＭ）、たとえばスマートカード１４０をボブ１１０に提示しなければならない。この認証マテリアルは、通常、スマートカード１４０又はＵＳＢ／ＩＥＥＥ１３９４（「Ｆｉｒｅｗｉｒｅ（登録商標）」）フォブの形態を取り、図１のアリスのデバイスキー１７０（オプションとして暗号化されている）ＫｄｅｖＡ、１７５、アリスのＩＤ番号ＩＤＡ、及び使用されるブロック暗号（たとえば、１２８ビットＡＥＳ）を実施できるオンボードマイクロプロセッサを含むものである。ＥＡＭ１４０上に存在するＫｄｅｖＡ１７０のコピーも暗号化される場合、アリスの人間のオペレータは、ＰＩＮ又はパスワード入力及びオプションのバイオメトリックデータ１５５等、デバイスキー１７０を解読するのに必要な秘密情報も、たとえばキーパッド入力（図示せず）を介してボブ１１０に手動で与えるべきである。これらのステップが完了すると、ボブ１１０は、メッセージ２２０を準備してＥＡＭ１４０へ配信する。メッセージ２２０は、次のもの、すなわち、電子認証マテリアル１４０上に存在するＫｄｅｖＡ１７０のコピーを解読するのに必要なＱＡ、ＩＤＡ、ＩＤＢ、及び（必要に応じて）秘密情報２２５（ＰＷ１５０及びバイオメトリックデータ１５５）を含む。この即座のトランザクションに続いて、ボブ１１０は、好ましくは、ＰＷ１５０のあらゆるローカルな記録及びあらゆるバイオメトリック情報１５５を削除する。ＥＡＭ１４０は、以下で詳細に説明するように、その組み込まれたマイクロプロセッサ１８０を使用して、２つの１２８ビット乱数Ｑ１及びＱ２を生成する。次に、ＥＡＭ１４０は、キー入力としてＫｄｅｖＡ１７０を使用し、ノンスとしてＱＡを使用して、アリス１１５への、ブロック暗号でセキュアにされたメッセージ２３０を準備する。このセキュアにされたメッセージ２３０は、暗号化されたペイロードとしてＩＤＡ、ＩＤＢ、Ｑ１、及びＱ２を含む。次に、ＥＡＭ１４０は、このセキュアにされたメッセージ２３０を、Ｑ１及びＱ２の「セキュアにされていない」（すなわち、平文）コピーと共にボブ１１０へ渡す。次に、ボブ１１０は、ＥＡＭ１４０からアリス１１５への配達人として機能して、ＥＡＭ１４０のセキュアにされたメッセージ２３０をメッセージ２３５としてアリスへ送信し、Ｑ１及びＱ２のセキュアにされていないコピーを一時的に記憶する。アリス１１５が、ボブのテレメトリー送信２３５を経由してＥＡＭのメッセージ２３０を受信すると、アリス１１５は、メッセージ２３５を即座に解読し、自身のＩＤ１７５が正確であることを検証し、次いで、ボブのＩＤ（図１の１８２）を検証する。アリスが受信したメッセージ２３５が、その完全性チェックに合格した場合、メッセージ２３５がＫｄｅｖＡ１７０及びＱＡを使用してセキュアにされたものであるという理由で、メッセージ２３５は真正なもの（ボブ１１０を介してアリスの患者のＥＡＭ１４０からのもの）及び新鮮なものの双方であるということが、アリス１１５に保証される。
【００３０】
アリス１１５が、ＢＡＮキーをボブ１１０へ配信する場合、アリス１１５は、Ｑ１及び
【００３１】
【数２】
から成るセキュアにされていないメッセージ２４０を準備して、ボブ１１０へ送信することができる。ここで、ＫＢＡＮは、現在のＢＡＮ１００のキーである。ボブ１１０は、アリスのメッセージ２４０を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証し、自身のローカルなＱ２を、受信された
【００３２】
【数３】
とＸＯＲし、その結果はＫＢＡＮになる。
【００３３】
他方、アリス１１５が、ボブ１１０からＢＡＮキーを受信する場合、アリス１１５は、Ｑ１から成る、セキュアにされていないメッセージ２４５を準備してボブ１１０へ送信することができる。ボブ１１０は、アリスのメッセージ２４５を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証する。次に、ボブ１１０は、
【００３４】
【数４】
を含む、セキュアにされていないメッセージ２５０を準備してアリス１１５へ送信することができる。アリス１１５は、ボブのメッセージ２５０を受信すると、自身のローカルなＱ２を、受信されたメッセージ２５０の
【００３５】
【数５】
とＸＯＲし、その結果はＫＢＡＮになる。
【００３６】
図３は、図１及び図２のＥＡＭ１４０以外の認証アイテムを使用する、ボディエリアネットワークキー送信プロトコルの代替的な一実施形態を示している。この実施形態によれば、あまり高度でない非電子的認証マテリアルを使用するあまりセキュアでないプロトコルが次のように進行し得る。すなわち、プロトコル３００のこの実施形態によれば、ボブ１１０は、すでに述べたように「ＢＡＮキーを配信する」セッション要求２１０を開始することができ、埋め込み物１１５であるアリスは、「ＢＡＮキーを配信する」セッション要求２１０を、ボブ１１０であるブリッジデバイスから受信する。アリス１１５及びボブ１１０は、最初に、テレメトリック通信セッション２１５を開始しなければならない。このテレメトリック通信セッションでは、アリス１１５は、新しく生成された乱数ＱＡをボブ１１０に提供する。次に、アリス１１５の人間のアドミニストレータ（たとえば、アリスデバイスが埋め込まれた患者）は、３１０において、ＫｄｅｖＡ１７０及びＩＤＡ１７５から成る非電子的な認証マテリアルをボブ１１０に提示することができる。この認証マテリアルは、たとえば、英数字文字で又はバーコードとして認証カード上に印刷して、光学式スキャナリーダデバイスで読み出すことができる。この光学式スキャナリーダデバイスは、たとえば、ボブの内部のもの又はボブに不可欠なものとすることができるか、又は代替的に、ボブと信号通信する（たとえば、ボブとネットワーク接続された）別個のデバイスとすることができる。代替的に、認証マテリアルは、人間のアドミニストレータが、ＧＵＩを介して又はキーパッドに認証マテリアルをタイプ入力することによって、ブリッジデバイスのボブ１１０内へ手動で直接入力することもできる。次に、ボブ１１０は、（本明細書で説明したように、又は他の手段によって）自身のブロック暗号を使用して、上述したような２つの１２８ビット乱数Ｑ１及びＱ２を生成する。次に、ボブ１１０は、キー入力としてＫｄｅｖＡ１７０を使用し、ノンスとしてＱＡを使用して、アリス１１５への、ブロック暗号でセキュアにされたメッセージ２３５を準備する。このセキュアにされたメッセージ２３５は、ＩＤＡ１７５、ＩＤＢ１８２、Ｑ１、及びＱ２を含む。次に、ボブ１１０は、このセキュアにされたメッセージ２３５をアリス１１５へ送信し、Ｑ１及びＱ２のセキュアにされていないコピーを一時的に記憶する。アリス１１５が、ボブのメッセージ２３５を受信すると、アリス１１５は、そのメッセージを即座に解読し、自身のＩＤ１７５が正確であることを検証し、次いで、ボブのＩＤ１８２を検証する。アリスが受信したメッセージ２３５が、その完全性チェックに合格した場合、メッセージ２３５がＫｄｅｖＡ１７５及びＱＡを使用してセキュアにされたものであるという理由で、メッセージ２３５は真正なもの（すなわち、ボブ１１０からのもの）及び新鮮なものの双方であるということが、アリス１１５に保証される。他のＢＡＮキーの生成及び送信は、上述したように行われる。
【００３７】
アリス１１５が、ＢＡＮキーをボブ１１０へ配信する場合、アリス１１５は、Ｑ１及び
【００３８】
【数６】
から成るセキュアにされていないメッセージ２４０を準備して、ボブ１１０へ送信することができる。ここで、ＫＢＡＮは、現在のＢＡＮ１００のキーである。ボブ１１０は、アリスのメッセージ２４０を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証し、自身のローカルなＱ２を、受信された
【００３９】
【数７】
とＸＯＲし、その結果はＫＢＡＮになる。他方、アリス１１５が、ボブ１１０からＢＡＮキーを受信することを望む場合、アリス１１５は、Ｑ１から成る、セキュアにされていないメッセージを準備してボブ１１０へ送信することができる。ボブ１１０は、アリスのメッセージを受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証する。次に、ボブ１１０は、
【００４０】
【数８】
を含む、セキュアにされていないメッセージを準備してアリスへ送信する。アリスは、ボブのメッセージを受信すると、自身のローカルなＱ２を、受信された
【００４１】
【数９】
とＸＯＲし、その結果はＫＢＡＮになる。
【００４２】
本発明の実施形態は、送受信機モジュールが属するデバイスのクラスに依存して、製造者が、そのモジュールを少なくとも４つの永久的な状態のうちの１つにすることができるシステムを提供する。これらのクラスは、一般に、（１）埋め込みデバイス（ＩＭＤ）、（２）ブリッジデバイス、（３）スマートローカルデバイス、及び（４）ダムローカルデバイスとしてカテゴリー化することができる。スマートローカルデバイスは、ユーザ入力用のファシリティ（たとえば、外部の薬ポンプ、外部の血糖計コントローラ、及び埋め込みコントローラ）を含む広範囲のグラフィカルユーザインターフェース（ＧＵＩ）を有するデバイスである。ブリッジデバイスは、広範囲のＧＵＩ及びユーザ入力を有し、さらに、埋め込みデバイス（たとえば、医師プログラマ、並びに、より機能豊富で強力な埋め込みコントローラ及びホームモニタ）に対して自身を認証することができる。ダムローカルデバイスは、ＧＵＩもユーザ入力も有しないデバイスである。ただし、或る限られたユーザディスプレイが存在する場合がある。ダムローカルデバイスには、キーフォブ、外部の血糖計、コムリンク、並びに特定の限られた能力の患者コントローラ及びホームモニタが含まれ得る。
【００４３】
ＢＡＮのさまざまなノードを構成するデバイスのタイプにかかわらず、これらのデバイスが、必要な最小の計算資源とセキュアに通信するために、すべてのデバイスは、好ましくは、ＢＡＮキーＫＢＡＮを共有する。たとえば、本発明によれば、ブリッジデバイス及び／又はスマートローカルデバイスは、セッション単位で、他のブリッジデバイス、スマートローカルデバイス、ダムローカルデバイス、及び埋め込まれたデバイスへ正当なＢＡＮキーを配信することができ、具体的には、埋め込みデバイスは、ＢＡＮの認可されたブリッジデバイス（たとえば、プログラマ機器）へ現在のＢＡＮキーをセキュアに配信するか、又は、認可されたブリッジデバイス（たとえば、プログラマ機器）から現在のＢＡＮキーをセキュアに受信する。本発明の特定の実施形態では、ＢＡＮキーの配信中のデバイスなりすまし、ＢＡＮキー配信の盗聴、及び／又は反射攻撃（すなわち、実質的なメッセージの内容の部分的な理解若しくは推測のみを含むか、又は、そのような理解も含まない、盗聴された通信の単なる繰り返し）を防止するか又は妨げるキー配信プロトコルが使用される。体外（すなわち、身体の外部）のＢＡＮデバイスは、ＩＭＤの秘密デバイスキーを決して受信しないので、プログラマ等の患者のＢＡＮのデバイスは、ＩＭＤの一意のデバイスキーを知ることは決してなく、一意のデバイスキーは、常に秘密の状態に維持されて、通信されず、たとえ、そのＩＭＤのＢＡＮで使用される体外機器が喪失又は盗難されても、存在するセッション認証情報は使用されていないものとなり、ＩＭＤの秘密キーは、体外機器上に決して記憶されていないので、ＩＭＤは危険にさらされない。ＢＡＮキーは、好ましくは、ＢＡＮの体外デバイス（たとえば、ブリッジデバイス及びスマートローカルデバイス）からＢＡＮの他の体外デバイス（たとえば、ブリッジデバイス、スマートローカルデバイス、及びダムローカルデバイス）へセキュアに通信される。これを行うために、本発明の特定の実施形態では、基礎となる無線通信方法の標準的なハンドシェイク、セッション要求、又は他のあらかじめ確立されたプロトコルに従って、セキュアにされていないテレメトリーセッションが確立される。ＢＡＮキーを受信するデバイスは、人間によって管理されている場合、ＢＡＮキーを配信するデバイスを操作する人間がＢＡＮキー受信者の認証を検証できるようにするために、その人間に、受信デバイスのデバイスキーＫｄｅｖ及び受信デバイスのＩＤ番号を視覚的に提供できなければならない。特にデバイスキーＫｄｅｖは、好ましくは、最初のデバイスが通過するすべてのデバイスから一意であるわけではない場合でも、少なくともＢＡＮに組み込まれる他のデバイスに対して一意である。また、特定の実施形態では、スマートローカルデバイス及びブリッジデバイスは、自身に提供されているかも知れないＢＡＮキーを、ＢＡＮの他の適任のデバイス（すべてのダムローカルデバイス及び／又は他のスマートローカルデバイス及び／又は他のブリッジデバイス）へセキュアに配信するのに使用される。本発明の代表的な実施形態によれば、ＢＡＮキーは、ＢＡＮの無線接続機能を介してセキュアに提供される。
【００４４】
図４は、本発明の一実施形態による２つの体外デバイスを有するボディエリアネットワーク４００を示している。この実施形態では、前の例のようなＩＭＤではなく、スマートローカルデバイス４１５又はブリッジデバイス４２０等の体外デバイスへＢＡＮキーを配信する体外デバイス（アリス）４１０が、ＢＡＮキー配信要求を開始することができる。前のＢＡＮキー伝播の例と同様に、テレメトリック通信セッションが、非セキュアチャネル１２０を介して（たとえば、ハンドシェイク又は他のあらかじめ確立された互換性のあるセッションプロトコルによって）、ＢＡＮキーを受信するデバイス（ボブ）１１０と確立され、ボブ１１０は、（ボブデバイス１１０のメモリ、ストレージ、又は他のハードウェア若しくはソフトウェアの素子４３５に実装されたＲＮＧファシリティによって生成される）新しく生成された乱数ＱＢを、メッセージ４２５を介してアリス４１０へ送信する必要がある。アリス４１０及びボブ１１０が、本発明に従って、非セキュアチャネル１２０を介して別の方法でテレメトリーセッションを確立すると、アリス４１０（又は、ＢＡＮキー交換セッションを管理する人間）は、ボブのデバイスキーＫｄｅｖＢ４３０を視覚的に獲得することできる（且つ、ＧＵＩ又は他の入力を介してアリス４１０に入力することができる）。デバイスキーＫｄｅｖＢ４３０は、たとえば、ボブの外装に貼付されたラベルに印刷することもできるし、ボブの電子ＧＵＩ上に表示することもでき、また、図４に抽象的に示すオンボードメモリ又はローカルストレージ素子４３５にも記憶される。アリス及びボブは、通常、テレメトリーセッションの最初の時点でＩＤ（ＩＤＡ及びＩＤＢ）を交換し、通信４４５及び４５０を介してそれらの各ＩＤを他の関係者に提供する。ほとんどの場合に、アリス４１０は、ボブ１１０のポーリング又はインターロゲートを行い、メッセージ４４５を介してボブの識別番号（ＩＤＢ）４４０を取得することもできる。
【００４５】
アリスは、ＩＤＢ４４０及びＫｄｅｖＢ４３０を獲得すると、オンボードメモリ又はセキュアストレージ４５５に記憶されているＩＤＡ（アリスのＩＤ番号）及びＢＡＮキーにアクセスすることができ、ＩＤＡ、ＩＤＢ及び現在のＢＡＮキーＫＢＡＮを含むメッセージ４６０を準備して、ボブへ送信することができる。ＩＤＡ、ＩＤＢ及び現在のＢＡＮキーＫＢＡＮはすべて、（以下で説明するように、ブロック暗号へのノンス入力としてのＱＢと共に）ブロック暗号へのキー入力としてボブのデバイスキーＫｄｅｖＢ４３０を使用してセキュアにされる。ボブ１１０は、アリスの送信４６０を受信すると、ＫｄｅｖＢ４３０を使用してアリスのメッセージ４６０を解読して検証し、受信されたＩＤＡ、ＩＤＢ、及びＫＢＡＮをログ記録する。次に、ボブは、ＩＤＡ、ＩＤＢを含むメッセージ４６５を準備して、アリス４１０へ送信する。ＩＤＡ、ＩＤＢはすべて、ＫＢＡＮ及びＱＢ＋１（すなわち、ＱＢをインクリメントしたもの）でセキュアにされる。アリス４１０は、ボブのメッセージ４６５を受信して解読／検証すると、自身が受信したＩＤが、自身が送信したＩＤと一致することを検証する。
【００４６】
ダムローカルデバイス４７０の場合、デバイスキーＫｄｅｖＸは、好ましくは、「工場において」ランダム又は任意に選ぶことができ、デバイス４７０内のファームウェア（又は、代替的にフラッシュメモリ）４３５に永久的にプログラミングすることができる。ダムローカルデバイス４７０は、本明細書で定義されるように、一般に、有効なＧＵＩを有しないので、Ｋｄｅｖ４３０は、好ましくは、デバイス４７０の外装、デバイス４７０の文書、又はデバイスそのものに貼付されるべきラベルに印刷され、開始後に除去される。これとは対照的に、スマートローカルデバイス４１５及びブリッジデバイス４２０は、本明細書で定義されるように、ＧＵＩを有し、それによって、自身のデバイスキー４３０を（ダムローカルデバイスと同様に）外部ラベルを経由して利用可能にすることもできるし、デバイスのＧＵＩを通じて利用可能にすることもできる。Ｋｄｅｖは、攻撃者が、認可されていないＢＡＮからテレメトリーノードデバイスにアクセスするために知る必要がある唯一の情報であるので、Ｋｄｅｖをできるだけ秘密の状態に維持することが重要である。スマートローカルデバイス４１５及びブリッジデバイス４２０の場合、デバイスキーＫｄｅｖがオンボードメモリ／ストレージ４３５又は４５５にのみ記憶され、もっぱらデバイスのＧＵＩを経由して利用可能であり、デバイスのＧＵＩとの対話が必要とされる場合に、デバイスの外側に印刷されることとは対照的に、Ｋｄｅｖは、明らかに、よりセキュアである。
【００４７】
ＫｄｅｖＢ４３０等のデバイスキーは、好ましくは、（フラッシュメモリ４３５内を含む）ダムローカルデバイス４７０内にハードプログラミングされる一方、スマートローカルデバイス４１５及びブリッジデバイス４２０については、デバイスキーはハードプログラミングされる必要はない。したがって、本発明の特定の実施形態では、スマートローカルデバイス４１５及びブリッジデバイス４２０のデバイスキーのプライバシーは、デバイスキーが必要とされるごとに、デバイスキーがランダムに生成される場合に最大にすることができる。デバイスキーの新しく生成された乱数を使用し、それによって、ＧＵＩを経由してデバイスキーを観察可能にすることを必要とすることによって、新しいデバイスキーが生成されるごとに、可能なデバイスキーの確率分布が（疑似乱数ジェネレータの一様性まで）効果的に一様になるという点で、スマートローカルデバイス４１５及びブリッジデバイス４２０に、ハイジャック（すなわち、認可されてない使用又はアクセス）からの特別な免疫が提供される。これは、デバイスキー４３０を推測しようとしている攻撃者４７５が、新しいデバイスキー４３０が生成されるごとに、自身の検索を最初からやり直す必要があることを意味する。したがって、本発明の特定の実施形態では、新しく生成された乱数が、スマートローカルデバイス４１５及びブリッジデバイス４２０のデバイスキーを生成するのに使用される。すべてのメッセージ、すなわち、ＢＡＮキーによるキー付き（keyed）メッセージ及びデバイスキーによるキー付きメッセージをセキュアにするのにブロック暗号を使用することができる。たとえば、過度のオーバーヘッドなしで強力なセキュリティを与えるブロック暗号は、１２８ビットＡＥＳとすることができる。デバイスキーが、ブロック暗号の長さよりも短い場合、ブロック暗号の引数の長さに達するために必要とされる回数だけ、デバイスキーを繰り返して、それ自体に連結することができる。
【００４８】
図５は、図４のネットワークキー伝播プロトコルを疑似プロトコル表記で示している。このプロトコルは、ＢＡＮキーが、ＢＡＮ４００の体外デバイス（ブリッジデバイス４２０及びスマートローカルデバイス４１５）からＢＡＮ４００の他の体外デバイス（ブリッジデバイス４２０、スマートローカルデバイス４１５、及びダムローカルデバイス４７０のいずれか）へどのようにセキュアに通信されるのかを記述している。ＢＡＮキーを受信するデバイス、この場合、ボブ１１０は、ブリッジデバイス、スマートローカルデバイス、ダムローカルデバイス等の体外デバイスへＢＡＮキーを配信するデバイス（この場合、アリス４１０）を操作する人間に、受信デバイス１１０のデバイスキーＫｄｅｖ４３０及び受信デバイスのＩＤ番号４４０を視覚的に提供できなければならない。最初に、ボブ１１０は、「ＢＡＮキーを配信する」セッション要求２１０をアリス４１０から受信する。アリス４１０及びボブ１１０は、最初に、図４のメッセージ４２５と同様に、ボブ１１０が新しく生成された乱数ＱＢをアリス４１０に提供するテレメトリック通信セッション２１５を開始しなければならない。本発明の特定の実施形態によれば、スマートローカルデバイス４１５及びブリッジデバイス４２０は、ＢＡＮキーを有する場合に、ＢＡＮ４００の他の適任のデバイス（すべてのダムローカルデバイス４７０及び／又は他のスマートローカルデバイス４１５及び／又は他のブリッジデバイス４２０）へＢＡＮキーをセキュアに配信することを担当する。したがって、以下のプロトコルは、適任のＢＡＮ４００のデバイスへのＢＡＮキーのセキュアな無線配信を可能にするのに適切である。
【００４９】
図５に示すように、ＢＡＮキーを配信するデバイス（アリス４１０）によって開始される「ＢＡＮキーを配信する」セッション要求２１０は、まず、ＢＡＮキーを受信するデバイス（ボブ１１０）とのセキュアにされていない通信セッション２１５を確立することから成る。アリス４１０及びボブ１１０がテレメトリーセッションを確立すると、ボブ１１０も、アリス４１０に、新たに生成された６４ビット疑似乱数ＱＢをメッセージ２１５を介して送信する必要がある。
【００５０】
スマートローカルデバイス４１５及びブリッジデバイス４２０のファームウェアが、着信する「ＢＡＮキー配信」コマンド２１０を拒否する場合には、人間のユーザが、スマートローカルデバイス４１５又はブリッジデバイス４２０を「新しいＢＡＮキーを受理する」モードにしない限り、デバイスハイジャックを防止するさらなる極めて強力な方法を実現することができる。新しいＢＡＮキーの受理に人間の介入を必要とすることは、専用の物理ボタン又はスイッチをダムローカルデバイス４７０に追加することによってダムローカルデバイス４７０において実施することができる。
【００５１】
スマートローカルデバイス４１５及びブリッジデバイス４２０のファームウェア４３５、４５５が、着信する「ＢＡＮキー配信」コマンドを拒否する場合には、デバイスに接近した人間のユーザが、スマートローカルデバイス又はブリッジデバイスを「新しいＢＡＮキーを受理する」モードにしない限り、デバイスハイジャックを防止するさらなる極めて強力な方法を実現することができる。新しいＢＡＮキーの受理に人間の介入を必要とするこのアイデアは、物理ボタン又はスイッチ（埋め込まれた「リセット」ボタン等）をダムローカルデバイス４７０に追加することによってダムローカルデバイス４７０においても実現することができる。新しいＢＡＮキーを受理するのに人間との対話を必要とすることは、実際に、（攻撃者がデバイスとの物理的な接触を達成しないという条件で）起こり得るあらゆるデバイスハイジャックを排除するが、本明細書で説明するように、ＢＡＮキー配信プロトコルに対する他の攻撃は可能であり、本発明の他の実施形態によって対処される。
【００５２】
図４及び図５のＢＡＮキー配信プロトコルの最後のステップにおいて、ボブ１１０は、ＫＢＡＮでセキュアにされたメッセージ４６５をアリス４１０へ送信することができ、したがって、キー配信プロトコルが成功したことを確認する。この確認信号は、アプリケーションレイヤに渡すことができ、次いで、視覚信号及び／又は音響信号の形態で「配信成功」通知として人間のユーザへ通信することができる。
【００５３】
本発明のブリッジデバイス４２０及びスマートローカルデバイス４１５は、特定の実施形態では、ＢＡＮキーをリセットすることができ、それによって、以下で説明するように、セッションキーもリセットすることができる。たとえば、患者又は医師の命令で、ブリッジデバイス４２０及びスマートローカルデバイス４１５は、受信機のデバイスＩＤ及びデバイスキーを使用することによって、ＢＡＮキーをローカルデバイス４１５、４７０及び／又は他のブリッジデバイス４２０へ配信することができる。本発明の特定の実施形態では、埋め込まれたデバイス又はブリッジデバイス４２０がＢＡＮに存在するか否かにかかわらず、スマートローカルデバイス４１５は、ＢＡＮキーを生成することができる。一般に、ＢＡＮキーを更新する必要がある唯一の時は、ＢＡＮキーを有するデバイスが喪失又は盗難された時である。本発明による特定の実施形態では、現在の攻撃者の処理能力に基づくと、ＢＡＮキーは、危険にさらされることを回避するために約数百年に１度の頻度でしか更新する必要がない。
【００５４】
ネットワーキング資源の制約条件のために、本発明の特定の実施形態では、共通の秘密キーが、特定のボディエリアネットワーク（ＢＡＮ）のすべてのデバイスによって共有される。このＢＡＮキーＫＢＡＮは、ＢＡＮ内のすべての通信をセキュアにするのに使用される。ＢＡＮ内では、テレメトリーセッションを次のように確立することができる。すなわち、テレメトリーセッションを開始するいずれかのデバイスのコマンド時に、共有されたＢＡＮキーが、現在のテレメトリーセッションで通信することを望むすべてのＢＡＮメンバーによって与えられる、新しく生成されて共有される乱数と共に、セッションキーＫｓｅｓにされる。このセッションキーＫｓｅｓは、テレメトリーセッションの継続時間の間、ＢＡＮで通信されるすべてのメッセージをセキュアにするのに使用される。テレメトリーセッションがクローズされると、現在のセッションキーは廃棄される。
【００５５】
ノード間の通信セッションをオープンするために、最初に、たとえば、ハンドシェイク、セッション要求／受理、又は他のセッション開始プロトコルによって、セキュアにされていない交換が通信デバイス間で行われる。好ましくは、着信するパケット長及び発信するパケット長は固定であり、その上、本発明による特定の実施形態では、物理レイヤハードウェアが、これらのパケット長を予測するようにセットアップされる。したがって、それよりも短いパケット又は長いパケットを「不良」とフラグ付けして拒絶することができる。使用される、関連のある暗号のインスタンスが利用可能でなければならない。本発明と共に使用するためのさまざまな適切な暗号化標準の１つは、ＦＩＰＳ承認の１２８ビットＡＥＳブロック暗号（ＦＩＰＳ ＰＵＢ １９７）である。暗号化は、ＡＥＳの「カウンタモード」（ＣＴＲモード）で適切に行うことができる。メッセージの新しさは、トークンのようなノンス（すなわち、使い捨ての疑似乱数）の使用を通じてチェックすることができる。また、特定の実施形態では、たとえば、ＡＥＳの「暗号ブロック連鎖メッセージ認証コードモード」（ＣＢＣ−ＭＡＣモード）の使用によって、メッセージの完全性が維持される。本発明のテレメトリーセキュリティシステムでは、本明細書で論述するように、疑似乱数をその時々に生成しなければならない。乱数は、コンピュータ生成された数を指すとき、技術的に正確に言えば、コンピュータ生成された数が実際には決定的であるという点で、（真の乱数とは対照的に）いわゆる疑似乱数を指すことができる。しかしながら、疑似乱数は、全体関数（overall function）が、可観測にするために全体的に確率的プロセスとして振舞うように、好ましくは、十分に複雑な若しくは多様な状態又は補助関数から導出される。この数の実際の値は重要ではなく、特定の実施形態では、数は、暗号の種、メッセージ認証関数の種、さらには、別の疑似乱数生成の種として使用できることが理解されよう。数の実際の値は、疑似乱数の関数については重要ではないので、数の値は、任意であると言うことができる。任意とは、本明細書では、一般に「偶然」と同義であることが意図されている。一般に、本発明が、疑似乱数の使用をどこで必要としようとも、その機能は、たとえば、代替的な疑似乱数ジェネレータ、又は、本発明の代替的な実施形態によるハードウェア生成された乱数に置き換えることができる。特定の実施形態では、上述したＦＩＰＳ承認のＡＥＳブロック暗号仕様は、ＡＮＳＩ Ｘ９．３１仕様（付録Ａ．２．４）に基づくＮＩＳＴ推奨の疑似乱数ジェネレータ（ＰＲＮＧ）を実施したものを提供する。これは、本発明の典型的な実施形態に適している。ＡＮＳＩ Ｘ．９．３１ ＰＲＮＧ仕様のこの特定の実施形態は、ＡＥＳブロック暗号（ＦＩＰＳ ＰＵＢ １９７）を使用する。このタイプの実施形態は、一時に１２８ビットのＰＲＮＧ疑似乱数を生成する。
【００５６】
図６〜図９は、本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図を示している。図６は、本発明の実施形態による、図９の乱数ジェネレータの最初のステップのデータフロー図を示している。特定の実施形態では、１２８ビット疑似乱数（ＰＲＮ）の生成は、ＡＮＳＩ Ｘ９．３１で指定されているように、ＡＥＳブロック暗号を使用して実施され、過度のオーバーヘッドなく、予測される攻撃者の処理能力の観点から十分なセキュリティ及びプライバシーを提供する。初期事項として、１２８ビット乱数ＫＲ６１０及びＲ０が、ＰＲＮＧに利用可能である。ＰＲＮＧキーであるＫＲ６１０は、変化せず、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５に常にロードされる。Ｒ０は、ＰＲＮＧが１２８ビット乱数を生成するごとに、新しい現在のＰＲＮ（Ｒ１，Ｒ２，…）で更新されるＰＲＮＧの秘密ランダム初期化ベクトル（secret and random initialization vector）である。ＫＲ６１０及び現在のＲの双方は、新しいいずれの疑似乱数の生成にも必要とされるので、メモリ又はセキュアローカルストレージに記憶することができる。
【００５７】
この実施形態では、あらゆる（ｉ＋１）番目のＰＲＮの生成は、次のように進行する。すなわち、図６に示すように、ブロック暗号６２０（この例では、１２８ビットＡＥＳ）が、キー入力６１５としてＫＲ６１０を使用してノンス６２５を暗号化するのに使用される。ノンス６２５は、たとえば、そのノードの現在のリアルタイムクロック値から構成することができ、１２８ビットレジスタを経由してブロック暗号６２０の１２８ビットｄａｔａ＿ｉ入力６３０にロードすることができる。（リアルタイムクロックが、１２８ビットよりも長い場合には、リアルタイムクロックの最下位１２８ビットを使用することができる。）リアルタイムクロックが１２８ビットよりも短い場合には、０の個数にリアルタイムクロックのビット数を加えたものが１２８に等しくなるように、ノンス６２５の最上位ビットを０でパッディングすることができる。リアルタイムクロックが、ノンス６２５を生成するのに使用されようとされまいと、ブロック暗号６２０から出力される中間値ｄａｔａ＿ｏ６３５は、本明細書では、Ｖ１６４０と呼ばれる場合がある。
【００５８】
図７は、本発明による疑似乱数ジェネレータの一実施形態における図６のステップに続くステップを示している。図７に示すように、中間値Ｖ１６４０は、現在のＲ７１０（最初の乱数の場合はＲ０であり、（ｉ＋１）番目の乱数の場合はＲｉである）とＸＯＲされる。次に、この１２８ビット値
【００５９】
【数１０】
６２５をブロック暗号６２０で暗号化することができる。具体的には、ＫＲ６１０を、たとえば１２８ビットレジスタからブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードすることができる。それに続いて、
【００６０】
【数１１】
６２５を、別の１２８ビットレジスタを経由してブロック暗号６２０のｄａｔａ＿ｉ入力６３０にロードすることができる。中間値Ｖ２７２０は、ブロック暗号６２０のｄａｔａ＿ｏ出力６３５である。
【００６１】
図８は、本発明による疑似乱数ジェネレータの一実施形態における図７のステップに続くステップを示している。この実施形態では、１２８ビット中間値Ｖ１６４０及びＶ２７２０が、互いにＸＯＲされ、ブロック暗号６２０で暗号化される。具体的には、ＫＲ６１０が、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされる。
【００６２】
【数１２】
６２５の結果は、別の１２８ビットレジスタを経由してブロック暗号６２０のｄａｔａ＿ｉ６３０入力にロードされる。ブロック暗号６２０の出力ｄａｔａ＿ｏ６３５は、新しいＰＲＮ Ｒｉ＋１８１０を含む。さらなる１２８ビットＰＲＮが必要とされる場合には、新しいノンス６２５（たとえば、現在のリアルタイムクロックデータ）を使用し、且つ、新しく更新されたＰＲＮ Ｒｉ＋１８１０を使用して、ＲＮＧプロセスを繰り返すことができる。さらなる乱数が必要とされない場合、Ｒｉ＋１は、今後のセッションにおける今後のＰＲＮの生成に備えてメモリに記憶される。ＰＲＮＧキーＫＲ６１０は、メモリ又はセキュアローカルストレージに記憶することができる。
【００６３】
要約すれば、ＲＰＮＧキーの生成は、好ましくは、図９に示すように、次のように進行する。ブロック暗号が、関数Ｅ（ｄａｔａ＿ｉ；ｋｅｙ＿ｉ）＝ｄａｔａ＿ｏによって表され、ここで、Ｅが、関数への関連のある引数並びにｄａｔａ＿ｉ６３０及びｋｅｙ＿ｉ６１５（ｉ≧０を有する）を有するＡＥＳ関数６２０を表す場合、アルゴリズムは、ブロック暗号を通る３つのステップのネストされた処理又は反復的な処理に従って要約することができる。すなわち、
ステップ１．Ｖ１６４０＝Ｅ（ノンス６２５；ＫＲ６１０）
ステップ２．
【００６４】
【数１３】
ステップ３．
【００６５】
【数１４】
である。上記ステップの３つすべてを結合することによって、
【００６６】
【数１５】
が与えられる。
【００６７】
本発明の特定の実施形態では、ＰＲＮ生成には、１２８ビットＡＥＳブロック暗号６２０及びモジュロ２加算機能の使用、ブロック暗号をバッファリングする３つの１２８ビットレジスタ、リアルタイムクロック又は別のノンス６２５のソースへのアクセス、並びに２つの１２８ビットの数Ｒｉ７１０及びＫＲ６１０のストレージ空間が割り当てられる。これらのうち、Ｒｉ及びＫＲのストレージ空間は、本発明の他の態様及び機能には利用可能でない場合がある。好ましくは、２つの１２８ビット乱数は、たとえば製造の際に、本発明のモジュールの実施態様に「インストール」することができる。これらの乱数のうちの一方（ＫＲ６１０）は、永久的なものとすることができ、他方Ｒ０７１０は、好ましくは、新しい疑似乱数が生成されるごとに、更新することができる。
【００６８】
本発明によるセキュアテレメトリーセッションは、好ましくは、１つ又は複数の通信デバイスがセキュアセッションを要求するといつでも開始される。セキュア通信セッションのセットアップは、２ステップのプロセスである。この２ステップのプロセスによって、すべての通信デバイスには、同じセッションキーＫｓｅｓが提供される。ステップ１において、すべての通信デバイスは、Ｒｘと呼ばれる事前に生成された疑似乱数、たとえば６４ビット乱数、を交代でアナウンスする。ここで、「ｘ」は、異なるデバイスをインデックスする。上述し且つ図６〜図９に示したように、特定の実施形態では、疑似乱数が次のセキュアセッションに直ちに利用可能であるように、疑似乱数は、前のセキュア通信セッションの終了時に生成される。これらの疑似乱数の生成は、好ましくは、本明細書の開示に従って行うことができるが、疑似乱数又はハードウェア生成された乱数を生成する他の方法を本発明に従って代用することもできる。
【００６９】
事前に生成された乱数のアナウンスに続いて、次のステップは、セキュアセッションの確立を提供し、すべての通信デバイスが共通のセッションキー（Ｋｓｅｓ）を計算することを必要とする。この共通のセッションキーは、その後、セキュアセッションの継続時間の間、データトラフィックをセキュアにするのに使用される。Ｋｓｅｓは、独立に計算されるが、ブロック暗号等の暗号を使用して各デバイスによって全く同一に計算される。１２８ビットＡＥＳブロック暗号は、本発明の典型的な実施形態に適している。
【００７０】
図１０は、本発明の実施形態によるセッションキーの生成のデータフロー図である。共通セッションキーは、事前に確立されたＢＡＮキーＫＢＡＮ及び通信ノードの乱数のすべて｛Ｒ１，Ｒ２，Ｒ３…｝から導出することができる。特定の実施形態では、Ｋｓｅｓは、ブロック暗号６２０への「キー入力」６１５内にＫＢＡＮをロードし且つブロック暗号６２０の「データイン」６３０内にデバイスの乱数１０１０をロードすることによって計算することができる。これは、本発明の特定の実施形態では、ファームウェア制御によって成し遂げることができる。具体的には、最初の２つのデバイスの６４ビット乱数が連結されて１２８ビットの数にされる。次に、この１２８ビットの数が、ブロック暗号６２０の「データイン」６３０にロードされる。セキュアセッションを確立することを望むデバイスが２つしか存在しない場合、ブロック暗号６２０の１２８ビット出力６３５が、セッションキーＫｓｅｓとなる。単一のセッション内でセキュアに通信することを望むデバイスが３つ以上存在する場合、再びブロック暗号６２０の「データイン」６３０を入力して上述したように処理される前に、ブロック暗号６２０の出力６３５が、続いて、次の２つのデバイス１０２０の連結された１２８ビット（２×６４ビット）乱数にＸＯＲされる（すなわち、モジュロ２加算される）。暗号（ここでは、１２８ビットＡＥＳ）のＸＯＲ導出値６３５への適用は、好ましくは、デバイスの乱数のすべてを通過するのに必要な回数だけ繰り返される。ここで、ブロック暗号６２０の最終出力６３５は、Ｋｓｅｓ１０３０である。セキュアセッションに含まれるデバイスが奇数個存在する場合、１２８ビット連結の「空」のスロットを６４個の０で満たすことができる。セキュア通信セッションの終了時に、エフェメラル（ephemeral）Ｋｓｅｓ１０３０を「削除」することができ、新しい各セキュアテレメトリーセッションが提供されると、その開始時に、新しいセッションキー１０３０が計算される。
【００７１】
説明したように、特定の実施形態で情報をセキュアにすることは、たとえばカウンタ（ＣＴＲ）モードで使用されるブロック暗号が使用されることを含めて、暗号に基づくことができる。このように、ブロック暗号は、キー付き疑似乱数キーストリームを生成するという点で、ストリームに適用することができる（又は、受信側ノードにおいて、平文を生成して解読を行うために暗号文に対して適用することができる）。このキー付き疑似乱数キーストリームは、その後、暗号化文を生成するために平文に対してＸＯＲされる。図１１は、本発明の実施形態によるメッセージのＣＴＲモードの暗号及び解読のデータフローを示している。図示するように、共有セッションキー１０３０は、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされ、セッションキー１０３０は、（上述したように、セキュアセッションの開始時に計算された後）メモリ又はストレージからレジスタにロードすることができる。１２８ビットノンス（すなわち、１回だけ使用される数）１１１０は、別の１２８ビットレジスタを経由して、ブロック暗号６２０のｄａｔａ＿ｉ入力６３０にロードされる。
【００７２】
図１２は、本発明の実施形態によるノンスレジスタのデータ構造を示している。この実施形態では、図１２に示すように、１２８ビットノンス１１１０の最上位８バイト１２１０が、実際には、８バイトのアップカウンタ１２１０である一方、そのカウンタの下位側の６バイト１２１５は、インスティゲーティングデバイス（instigating device）の乱数Ｒｘ１２２０の最下位６バイト［すなわち、ビット４７〜ビット０］で開始される。乱数Ｒｘ１２２０は、図１０のセッションキー１０３０の生成に貢献されたものであることが理解されよう。本発明によるテレメトリーパケットが、セキュアセッションで受信又は送信されるごとに、カウンタ１２１０の値がインクリメントされる。（８バイトカウンタ１２２０のすぐ下の）次のノンスバイト１２２５は、図１２のビット「ｍ」１２３０であるモードビット１２３０を含む。本明細書で説明するように、このビットは、ノンスがＣＴＲモード暗号化／解読に使用されているときは、論理０に設定することができ、ノンスがメッセージの完全性に使用されているときは、モードビットは論理１に設定される。モードビットの下の７ビットフィールドであるブロック番号フィールド１２４０は、あらゆるパケットの開始時に論理０００００００にリセットされ、そのパケット内の暗号化／解読に使用されるキーストリームマテリアルの各１２８ビットブロックの生成時にインクリメントされる。たとえば、各テレメトリーパケットが、暗号化／解読に３００ビットのキーストリームマテリアルを必要とした場合、キーストリームの最初の１２８ビットは、０００００００を使用して生成され、２番目の１２８ビットは、００００００１を使用して生成され、３番目の１２８ビットは、０００００１０を使用して生成される（１つずつインクリメントされる。キーストリームマテリアルの３００ビットがパケットごとに必要とされる例では、キーストリームマテリアルの最後の１２８ビットのうちの４４ビットのみが必要とされることに留意する）。１２８ビットノンス１１１０の残りの７バイト（最下位７バイト１２４０）は、好ましくは、永久的に論理０に設定することができる。
【００７３】
反射攻撃を防止することを助ける同期されたタイムスタンプではなく、又は、このタイムスタンプに加えて、本発明の特定の実施形態では、あらゆるセキュアテレメトリックセッションの開始時に新しいセッションキーＫｓｅｓ１０３０を計算することによって、メッセージの新しさ及びユーザ認証が提供される。この新しいセッションキー１０３０は、セキュアセッションの参加者のそれぞれによって生成された乱数の貢献度（contribution）の関数である。しかしながら、セッション内の反射攻撃について、さらなる新しさのメカニズムを提供することができる。この場合、セキュアセッションのデバイスは、セッションノンスの自身のローカルコピーにおけるカウンタを、その現在の値よりも小さな値にリセットすることを決して可能にすべきでない。テレメトリー通信セッションが中断されるか、又は、他の或る理由から、基礎となる通信プロトコル内で「リセット」若しくは再同期する必要がある場合、セキュアセッションのデバイスが再同期するために、現在のセッションノンスはアナウンスされることが必要な場合がある。攻撃者は、おそらく、他のセッション参加者のノンスを前の値にリセットし、それによって、攻撃者が、前のノンス値を使用した古いメッセージを反射できるように試みることによって、このような状況の悪用を企てている可能性がある。このように、セッションノンスは、かなりのネットワークトークンとして機能する。ノンスカウンタが増加のみ行う場合、２６４個を超えるパケットが単一のセキュアセッションで通信されることはないという条件で、過去のセッション内メッセージは、以前のノンスを有するので、古いメッセージは、決して正当なノンスを有しない。なお、２６４個を超えるパケットが単一のセキュアセッションで通信されることは、起こりそうもないことである。
【００７４】
図１１に示すように、本発明の実施形態では、暗号化及び解読は、好ましくは、ブロック暗号６２０の１２８ビット出力バスｄａｔａ＿ｏ６３５と、暗号化用のペイロード平文から取られた１２８ビットデータブロック１１１５、及び、解読用のペイロード暗号文から取られた１２８ビットデータブロック１１１５との間でビット単位のモジュロ２加算（ＸＯＲ）を実行することによって行われる。本発明の特定の実施形態では、パケットヘッダは暗号化されない。
【００７５】
図１３は、本発明の一実施形態によるテレメトリーパケット１３００のデータ構造を示している。１２８ビットメッセージブロック１１１５のそれぞれは、ブロック暗号６２０の異なる出力６３５とＸＯＲ１１２０を行うことができる。たとえば、図１３のメッセージブロックｍ１１３１０は、キーストリームブロック（すなわち、ブロック暗号６２０のｄａｔａ＿ｏバス６３５を残した１２８ビットブロック）ｓ１とＸＯＲされ、メッセージブロックｍ２（パケットの次の１２８ビット１３２０）は、ｓ２とＸＯＲされる。他のメッセージブロックについても同様にＸＯＲされる。前述したように、異なるノンス１１１０は、各キーストリームブロック６３５の生成で使用される。特定の実施形態では、同じノンス１１１０が、同じセッション内で２回使用されることは決してない。したがって、８バイトノンスカウンタ１２１０が、その最大値（０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ）に達すると、セキュアセッションを終了することができ、新しいセッションキーが一括して計算される。この実施形態では、単一のセッションキーを使用して通信できるテレメトリーパケットの個数は、２６４個（インスティゲータ（instigator）の乱数の最下位６バイトが０ｘｈ００００００００００００である場合に対応する）から２６４−２４８個（インスティゲータの乱数の最下位６バイトが０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦの場合に対応する）である。１０進数では、これらの数は、それぞれ１．８４４６７×１０１９及び１．８４４６４×１０１９であり、したがって、実際にこれらのパケット数に決して達する可能性がないことが理解されよう。
【００７６】
たとえばＴＤＭＡ構造といったセキュアにされたネットワークでは、好ましくは、デバイスは、非送信の期間中にセキュアな通信を維持するために、そのデバイスが、自身に割り当てられた窓の期間中に実際にブロードキャストするか否かにかかわらず、自身のノンスカウンタをインクリメントする。この非送信の時間の間、デバイスは、エネルギーを保存するために自身の無線の電源を切ることができる。電源投入時に、デバイスは、セッションノンスの経過を追跡してきており、依然として、後に電源投入することができ、セキュアに通信することができる。代替的に、テレメトリーネットワークセッションの「マスタ」又は「ビーコン」は、ネットワークセッション内で新しい「ラウンド」を開始するごとに、現在のノンスカウンタをセキュアにせずにブロードキャストすることができる。
【００７７】
本発明の特定の実施形態では、ＭＡＣは、各テレメトリーパケットについて計算され、各テレメトリーパケットにアペンドされる。また、本発明の特定の実施形態では、１つのパケットサイズ及びパケット構造が使用される。このようなパケット構造の１つの可能な実施形態が、図１３に示されている。図示するように、本発明によるパケット１３００は、４２ビット（５．２５バイト）ヘッダ１３１０、３０バイトペイロード１３１５、及び３バイトＭＡＣ１３２０から構成することができる。
【００７８】
本発明の特定の実施形態では、ブロック暗号（たとえば、１２８ビットＡＥＳ）をＣＢＣ−ＭＡＣモードで使用して、メッセージの平文のキー付きハッシュ値（メッセージ認証コード、すなわちＭＡＣ）を生成することができる。このキー付きハッシュ値は、図１３に示すように、１３２０において、送信時にそのメッセージ１３１５の暗号化された形態にアペンドされる。これらのパケット１３００及びそれにアペンドされたＭＡＣ１３２０を受信すると、受信機は、パケットペイロード１３１５を解読し、それらの解読されたパケットに関するＭＡＣを計算し、受信機は受信されたペイロード１３１５から導出した、計算されたＭＡＣ値を、本パケット１３００にアペンドされて受信されたＭＡＣ値１３２０と比較する。これらのＭＡＣが一致した場合、パケット１３００は受理される。当然、ＭＡＣが矛盾した場合、パケット１３００は廃棄又は再要求される。ＭＡＣ１３２０が、本発明に従って計算され、各パケット１３１５にアペンドされる場合、従来技術のテレメトリーシステムにおけるパケットごとのＣＲＣの代わりにＭＡＣ１３２０を使用することができる。本明細書でさまざまに詳述したように、特定のパケットがセキュアにされずに送信される限りにおいて、付加的に、（ＣＲＣのような）キー付きでない（unkeyed）完全性チェックメカニズムを適用することができる。この完全性チェックは、ハードウェアＣＲＣの使用を通じて実現することもできるし、代替的に、公に知られたキー及びノンスを有するＣＢＣ−ＭＡＣを使用することによって（たとえば、双方について０ｘ００００００００００００００００００００００００００００００００を使用することによって）実現することもできる。
【００７９】
ＭＡＣ１３２０を使用するこの実施形態では、パケットペイロード１３１５（すなわち、暗号化されるパケットの部分）の長さは３０バイトである（したがって、１ビットのみのノンスレジスタブロック番号フィールド１２３５を必要とする）が、ノンスレジスタブロック番号フィールド１２３５は、同じノンスレジスタ構造１１１０を使用して、４０９６バイトと同じ長さのより長いパケットペイロードの使用を可能にすることができる将来のテレメトリー方式に備えて７ビットに固定することができる。
【００８０】
図１４に示す本発明の代表的な一実施形態によるＣＢＣ−ＭＡＣ生成／検証アルゴリズムでは、最初に、共有セッションキー１０３０（ＣＴＲモード暗号化／解読に使用されるものと同じもの）が、１２８ビットレジスタ１４３０を経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされる。ブロック暗号６２０のｄａｔａ＿ｉ入力６１５には、ノンスの９７ビットの最上位ビット（必要に応じて、ブロック番号フィールドをトランケートする）と最大で最初の３１ビットまでの平文パケットのビット（通常はヘッダ情報から成る）とを連結したもの１４３５をロードすることができる。ノンスレジスタ１１１０のモードビット１２３０は、論理１に設定することができる。典型的な実施形態では、ＣＢＣ−ＭＡＣアルゴリズムがＭＡＣ生成に使用されているのかＭＡＣ検証に使用されているのかにかかわらず、ＣＢＣ−ＭＡＣ処理は、各パケットの解読された形態（すなわち、メッセージ平文）に対して行われる。この実施形態では、したがって、受信されたパケットは、それらのパケットのＭＡＣが検証可能になる前に、解読されなければならない。
【００８１】
図１４の最初のブロック暗号６２０の出力（ｄａｔａ＿ｏ）６３５は、１４３５における９７ビットノンスに連結された平文に続く次の１２８ビットとビット単位でＸＯＲすることができる。次に、このＸＯＲの結果は、第２のブロック暗号１４４０の入力６３０にロードされる。次に、第２のブロック暗号１４４０の出力６３５は、パケット１３００の１３１５からのパケット平文の最後の１２８ビット（必要に応じて０がパッディングされる）とＸＯＲされ、次いで、第３のブロック暗号１４４５によって処理される。この実施形態では、パケットヘッダ及びパケットペイロードのビット合計が２８７ビット以下であるので、ＭＡＣが、第３のブロックの１２８ビット出力（ｄａｔａ＿ｏ）であることから、ＣＢＣ−ＭＡＣのラウンドはそれ以上必要とされない。ＭＡＣが、本発明の代替的な一実施形態に従って、より長いパケットに対して必要とされる場合、出力をＸＯＲしてさらなるブロック暗号６２０に通すことによって、さらなる平文ブロックを処理することができる。一般に、ｍ個のブロックの平文について、ｍ回のＸＯＲ／ブロック暗号ラウンド６３０が必要とされる。ここで、最後のブロック暗号のｄａｔａ＿ｏ出力６３５がＭＡＣ１４５０となる。図１４には、３つのブロック暗号コア６２０、１４４０、１４４５が示されているが、特定の実施形態では、１つのコアしか実際にハードウェアで実施されず、実際には、ＸＯＲ出力は、第１のブロック暗号６２０のｄａｔａ＿ｉ入力６３０へ送られることに留意されたい。図１４に示す３つのコア６２０、１４４０、１４４５は、ＣＢＣ−ＭＡＣアルゴリズムを例示するようにのみ意図されている。
【００８２】
図１４に示すように、本発明の特定の実施形態では、ＣＢＣ−ＭＡＣ出力１４５０の最下位２４ビット（ビット２３〜ビット０）のみが、処理されたパケット１３００の最後にＭＡＣ１３２０としてアペンドされる。これによって、ＣＢＣ−ＭＡＣ関数（この場合、１２８ビット）の基礎となる暗号強度は危険にさらされない。
【００８３】
セキュアにされたセッションに参加する各デバイスは、好ましくは、あらゆるパケット１３３０の送信時及び受信時に自身の各セッションノンスカウンタ１２１０をインクリメントする。このように、一時にセキュアセッションの１つのデバイスしか送信していないので、ノンスインクリメントは、プロキシトークンとして機能し、したがって、複数のデバイスを同時に送信できないことが確実にされる。特定の実施形態では、テレメトリーパケットは比較的長いので、ノードは、特定の状況で、ＢＡＮグループの中でノンス同期を場合によっては喪失する可能性がある。基礎となる通信プロトコルによってサポートされる場合、本発明の特定の実施形態では、デバイスは、自身の現在の平文ノンスをフレームヘッダに定期的に含めて、ノンス同期チェックを提供することができる。典型的な実施形態では、ノンス同期は、一般に、現在のノンス１１１０をＮＡＣＫパケットに常に含めることによって回復することもできるし、基礎となる通信プロトコルに存在するネイティブ回復技法が何であってもそれを通じて回復することもできる。好ましくは、本明細書でさらに説明するように、すべてのデバイスは、ａ）セッションノンスのデバイスのコピー内のカウンタが、デバイスがメンテナンスメッセージで受信するあらゆるノンスと少なくとも同程度の大きさであるべきであるというルール、及び、ｂ）ノンスカウンタが０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦに達すると、新しいセッションキーを計算しなければならないというルール、に従い、ノンスは、２回使用されることはなく、したがって、メッセージの新しさが保証される。
【００８４】
好ましくは、暗号化／解読は、ヘッダ１３１０ではなく、テレメトリーパケットペイロード１３１５に適用されるべきである。本発明のこの実施形態は、攻撃者に利用可能な既知の平文及び必要とされるキーストリームの長さの双方を最小にする傾向がある。さらに、これによって、パケットヘッダ１３１０が物理レイヤハードウェアを通じて伝播している間に、キーストリームマテリアルを計算してバッファリングするブロック暗号時間が与えられる。本発明の特定の実施形態では、単一のブロック暗号コア６２０（たとえば、ＡＥＳブロック暗号）は、暗号化関数及びＭＡＣ関数の双方を実施するのに使用されるが、これは、好ましくは、ランタイムにブロックごとにＣＴＲモードをＣＢＣ−ＭＡＣモードと交互に用いるのではなく、最初に、パケット全体のペイロードデータ１３１５の分量について、ＣＲＴモードを使用して十分なキーストリームマテリアルを生成して記憶することによって行われる。暗号化／解読された１２８ビットブロックが利用可能になると、ＣＢＣ−ＭＡＣモードを使用して、引き続きＭＡＣが生成／検証される。図１５は、本発明の一実施形態によるパケット（３２バイト以下のペイロード）のＣＴＲモード及びＣＢＣ−ＭＡＣモードのＡＥＳベースの混合使用について提案されたハードウェアレイアウトを示している。
【００８５】
一般に、本発明によるノードの一ハードウェア実施態様は、１２８ビットＡＥＳブロック暗号の１つのインスタンス（及び対応する専用の１２８ビットレジスタ）と、１２８ビットＢＡＮキー用のキープアライブストレージ又は不揮発性ストレージとを必要とする。セッションノンスは、セッションキー（Ｒｘ）へのインスティゲーティングデバイスの乱数の貢献のみから成るので、セキュアにされたネットワークのすべてのデバイスは、さらなる送信を行う必要なく、セッションノンスを知っている。図１５に示すように、単一のブロック暗号６２０を使用して、ｄａｔａ＿ｉ入力６３０に対する（入力１５１０を介した）キーストリーム又は（入力１５１５を介した）ＣＢＣ−ＭＡＣ入力のいずれかが処理される。ブロック暗号６２０の出力６３５であるレジスタ１５１５は、平文１５２５とＸＯＲされて、平文データ１５２５が暗号化される。
【００８６】
本発明の特定の実施形態では、（セッションをオープンし、乱数を共有するのに使用されるパケットのように）パケットをセキュアにせずに通信する必要がある限りにおいて、キー付きでない完全性チェックが依然として使用される。この完全性チェックは、たとえば、ハードウェアＣＲＣの使用を通じて実施することもできるし、（双方について０ｘ００００００００００００００００００００００００００００００００のような）おそらく、公に知られた秘密キー及びノンスを有するＣＢＣ−ＭＡＣを使用することによって実施することもできる。
【００８７】
キーストリームマテリアルが生成され、第１のキーストリームレジスタ１５１０及び第２のキーストリームレジスタ１５１５にそれぞれ記憶される。第２のキーストリーム１５１５レジスタのキーストリームマテリアルが使い切られると、第１のキーストリームレジスタ１５１０が、キーストリームレジスタ１５１５に並行してロードされる。第１の平文ブロックは、レジスタ１５２０に記憶され、（第１のキーストリームレジスタ１５１０のキーストリームマテリアルが、第２のキーストリームレジスタ１５１５に移されると）ブロック暗号処理６２０に続く結果の第１のＭＡＣブロックが、第１のキーストリームレジスタ１５１０に記憶される。第１のＭＡＣブロックは、１５２５からの平文の第２のブロックとＸＯＲされ、ブロック暗号６２０に通される。次に、最後のＭＡＣ１５３０の最下位２４ビットが、図１３の暗号化されたデータ１３１５にアペンドされる。
【００８８】
本発明による無線テレメトリーシステムでは、本明細書で開示したように、通常、体内デバイスと体外デバイスとの間の通信セッションを完全に無線で開始、実行、及びクローズすることができる。したがって、論述したように、認可されていない且つ／又は悪意のある関係者が、埋め込まれたデバイス又はＢＡＮの他のノードと通信することを防止することが重要である。しかしながら、実際には、認可されていない体外デバイス（医師プログラマ器具、緊急対応機器等）及びそのユーザ（これらのユーザは、埋め込み物の秘密キーにアクセスできないという意味で認可されていないが、患者のＢＡＮにアクセスする患者の明白な又は暗黙の同意又は指示を有する）が、それにもかかわらず、埋め込まれたデバイスと通信することが必要な状況が発生し得ることが理解されよう。このような状況は、たとえば、埋め込み物自体によって引き起こされていようがいまいが、患者が危機的な事象、さらには、命に関わる生理学的事象を受けている緊急の状況で発生し得る。たとえば、患者は、おそらく意識不明であり、識別マテリアルを有しない場合がある。また、上記プロトコルによる認証が禁止されているか又は実現不可能である過度の不便さのために、上述したような本発明の態様におけるフル認証が実現可能でない状況も発生し得る。たとえば、患者は、医師と会うための予約で大きな距離を移動してきた場合があるが、到着した時に、自身のスマートカード、又は、体外ノードが埋め込み物と通信できるようにするのに必要な他のマテリアルを忘れてきた又は置き忘れてきたことに気付く場合もあるし、患者は、自身の認証パスワードを忘れてしまっている場合もある。これらの状況では、「バックドア」、すなわち、ＩＭＤ ＢＡＮノードとインターフェースする方法（しかし、代表的な実施形態では、ノードの秘密デバイスキーＫｄｅｖを導出することなく）が、限られた原則で、本発明によるシステムのセキュリティプロトコルを迂回する方法でノードへの正当なアクセスを可能にすることができる。したがって、患者の予約を再スケジューリングする不便さが回避され、又は、真の緊急の状況では、患者への重要なケアが可能になる。
【００８９】
本発明の一実施形態では、たとえば或る距離にわたって、たとえば無線プロトコルとして、無線で動作する便利なバックドアメカニズムを提供することができる。一方、本発明の特定の実施形態では、バックドアは、無線ではなく、バックドアをオープンできる機器は、幅広く利用可能な場合がある（したがって、攻撃者が獲得することが容易である）。したがって、特定の実施形態におけるバックドアは、キーを共有するすべてのノードデバイスのセキュリティが、理由が何であれ、バックドアキーの相対的な機密性を危険にさらす動機を有する攻撃者によってノードデバイスの獲得時に取り返しのつかないほど危険にさらされるような方法では実施されない。したがって、無線バックドアが実施される本発明の特定の実施形態では、好ましくは、埋め込み物又はノード（たとえば、アリス１１５）全体の限られた量の機能しか、バックドアキーの通信時に動作可能ではない。たとえば、無線バックドアが利用可能である特定の実施態様では、無線バックドアを使用して、埋め込み物をそれぞれの静止（すなわち「スタンバイ」）モードにのみすることができる。より具体的には、たとえば、ペースメーカは、６０ｂｐｍモードに入ることができる一方、埋め込み可能な除細動器又はニューラルシミュレータ又は薬ポンプは、無線バックドアによって療法一時停止モードにすることができる。
【００９０】
図１６を参照して、本発明の特定の実施形態では、「物理的」バックドア１６１０、すなわち、無線通信チャネル１２０を使用しないアクセス方法、が提供される。これらの実施形態では、バックドアアクセスを求めるデバイス１１０と、アクセスされるノード１１５及び／又はその患者（埋め込められたデバイスの場合）との間の物理的な接触（又は近接近）によってのみ、認証なしのＢＡＮノード１１５へのアクセスが行われる。これは、特定のＢＡＮノード１１５では、ホール効果センサ又は磁気リードスイッチ等の近接場磁気センサの使用によって実施することができる。好ましくは、このセンサ１６１０は、通信チャネルそれ自体をもたらさず、（上記で説明したように）本発明の実施形態によって必要とされる認証要件なしで、モジュールを、機器が埋め込み物（複数可）又は他のノードと通信できるオープンモードにすることのみのために使用される。代替的に、バックドアは、磁気テレメトリー等の近い範囲のテレメトリーの手段を開始することができ、このテレメトリーでは、接近することによって、通信チャネルの使用が実際に可能になる。
【００９１】
また、特定の実施形態では、緊急機器１１０が通信セッションをクローズすると、バックドア１６１０はクローズする。すなわち、オープン通信チャネルがクローズされ、デバイス１１５へさらに通信するには、たとえば本明細書で提供したような適用可能な認証情報が必要とされるか、又は代替的に、別のバックドア通信セッションの確立が必要とされる。このバックドアの使用の効果は、無線ルータ等の無線ネットワーク器具の埋め込まれたリセットボタンと比較することができる。リセットによって、リモートの第三者が無線ルータの態様を変更することが可能になるが、この状態は、デバイスにおける物理的な動作なしでは提供されない。デバイスへのこの物理的なアクセスは、デバイス又はノードに対する変更を管理する管理認証の代理として行われる。
【００９２】
バックドアは、ＫＢＡＮをＢＡＮの他のデバイスへ配信する目的で、ＩＭＤからそのＫＢＡＮを抽出する好ましい手段としても使用することができる。また、バックドアは、ＩＭＤがエフェメラルＫＢＡＮ（ＫＢＡＮとして一時的に使用されるローカルに生成された乱数）を送信することを要求するのにも使用することができる。このエフェメラルＫＢＡＮは、そのテレメトリーセッションの継続時間の間にのみ有効である。バックドアアクセスの結果、ＫＢＡＮ又はエフェメラルＫＢＡＮの無線送信が可能になる実施態様では、エフェメラルＫＢＡＮを回復するのに必要なクレデンシャルに関して、ＩＭＤがＫＢＡＮを送信するために、追加されたクレデンシャルが必要とされる場合がある。このようなクレデンシャルは、たとえば１０秒といった延長された時間期間の間近接スイッチを起動することを含むことができる。ここで、エフェメラルＫＢＡＮの回復は、同じ近接スイッチの起動の時に３秒間だけ認可することができる。
【００９３】
ＩＭＤ１１５に対するバックドア１６１０は、次のように具現化することができる。最初に、アリス１１５及びボブ１１０は、メッセージ１６１５及び１６２０を介してＩＤ（ＩＤＡ、ＩＤＢ）を交換することによって非セキュアチャネル１２０による通信セッションをオープンする。次に、ボブ１１０は、非セキュアチャネル１２０を介して、アリス１１５のバックドア回路部１６１０に電源を投入するようにアリス１１５に依頼する。このバックドア回路部１６１０は、通常ならば電源オフされ、たとえば磁石を接近させることのような、いずれの外部事象にも応答しない。たとえば、オフの時、バックドアは、「ロックされている」と言われる場合がある。バックドア回路部１６１０がオンになり、したがって、バックドア１６１０が「ロック解除」されると、ボブ１１０は、上述したように、磁気スイッチ又はホール効果センサ等の手段によってアリスのバックドアを物理的にオープンすることができる。好ましくは、バックドア１６１０が、所定のタイムアウト前に物理的にオープンされない場合、アリス１１５は、自身のバックドア回路部１６１０の電源を自動的に切り、バックドア１６１０を再ロックして、ホスト患者に接近することが攻撃者に可能である場合に攻撃を回避する。
【００９４】
バックドア１６１０のオープンに続いて、アリス１１５は、自身のＲＦ送信電力を削減し（それによって、信号の有効な送信範囲を削減し）、次いで、メッセージ１６３０によってボブ１１０へＫＢＡＮ１６２５を送信する。アリス１１５は、この送信を行うと直ちに、自身のバックドア回路部１６１０の電源を切る。代表的な実施形態では、ＢＡＮキーの要求は、バックドアプロトコルの開始に暗に示されているので、ボブ１１０によるＢＡＮキーの要求は必要ではない。
【００９５】
図１７は、図１６の実施形態による緊急事態アクセスプロトコルの疑似プロトコル及びデータフローを示している。図１７に示すように、ブリッジデバイス１１０は、バックドアセッション要求１７１０によってＢＡＮキーを取得することができる。バックドアセッション要求１７１０に続いて、２つのノードは、２１５において、セキュアにされていないテレメトリーセッションを確立する。次に、ブリッジデバイス１１０は、バックドア回路部１６１０に電源が投入されることを要求することができる（１７１５）。これに応答して、ＩＭＤ１１５は、１７２０において、自身のバックドア回路部１６１０に電源を投入し、１７２５において、バックドア回路部１６１０に電源が投入されたことをブリッジデバイス１１０に確認する。次に、ブリッジデバイス１１０は、磁気スイッチ、ホール効果センサ、又は、バックドア１６１０を備える他の接近に基づくスイッチを接近させることによって、電源が投入されたバックドア１６１０を起動することができる。これは、１７３０によって示されている。
【００９６】
バックドア１６１０がオープンすると（１７３０）、ＩＭＤ１１５は、１７３５に示すように、バックドアが接近ノード１１０によってオープンされたことに気付き、その後、１６２５において、非セキュアテレメトリーチャネル１２０によってＢＡＮキーを送信する。特定の実施形態では、ブリッジデバイス１１０は、１７３０において、ＢＡＮキーの受信の確認を送信することができるが、典型的な実施形態では、ＩＭＤ１１５は、ＢＡＮキーを送信するとバックドア１６１０の電源を直ちに切り、バックドアのオープンの別の要求１７１５が要求される。
【００９７】
ＢＡＮ内の所与のデバイス又はノードが、上記セキュリティパラメータに従って十分にセキュアなテレメトリーセッションを開始することなく別のノードへデータを送信することが好都合であるさまざまな状況が存在する。たとえば、ＢＡＮは、セキュアな双方向リンクを確立できない送信のみのタイプのセンサである１つ又は複数のノードを含む場合がある。患者アクティベータ（patient activator）のような他のデバイスは、直ちに効果を与えることができるデータを送信することができる。したがって、本発明の実施形態は、データを含むウェイクアップパケットをセキュアにすること、及び、限られた量のセキュアなその後の通信を提供する。この文脈において、十分にセキュアなプロトコルは、一般的なセキュリティの確立と呼ばれ、あまり煩わしくないプロトコルは、ウェイクアップセキュリティ等と呼ばれる。
【００９８】
図１８は、ＢＡＮ内の認可されたデバイス（たとえば、アリス１１５）によって生成されたようなセキュアにされたウェイクアップパケット２０００をブロックの形態で示す図である。ウェイクアップパケット２０００は、特にアリス１１５のＩＤ、パケットを受信するノードのＩＤ等のような、図示しない他のデータも含むことができる。簡潔に言えば、ウェイクアップパケットは、４バイトの暗号化されていないデータ２０１０、３バイトのＭＡＣ２０２０、及び３バイトのＭＣＴＲ２０３０を含む。ＭＣＴＲは、特定のデバイスに関連付けられた３バイトのメッセージカウンタ値である。このメッセージカウンタ値は、ＢＡＮの各デバイス内に記憶され、その特定のデバイスが新しいセキュアなウェイクアップパケットを作成するごとにインクリメントされる。ＢＡＮ内の各デバイスは、ネットワーク内のあらゆるデバイスのオンメモリに常にＭＣＴＲの値を維持する。新しいデバイスがＢＡＮに追加された場合、ＭＣＴＲのすべての値がリセットされる。ＭＣＴＲ値は、ウェイクアップパケット２０００では暗号化されない。ＢＡＮの各デバイスは、ＭＣＴＲ値を維持することに加えて、目的とする受信者（複数可）として各デバイスを識別するのに使用される１バイト値であるレセプタビットマップも含む。
【００９９】
ＭＣＴＲの値の追跡と共にＭＡＣ２０２０の生成によって、セキュリティがプロトコルに提供される。認可された受信デバイス（たとえば、ボブ１１０）は、受信時に、ＭＣＲ値２０３０を評価する。メッセージは、適切でない場合には無視される。適切である場合には、ＭＣＡは次に復号される。データ２０１０は、認証された場合には利用され、認証されない場合には、データは無視される。一実施形態では、ＡＣＫ／ＮＡＣＫメッセージ以外のそれ以上の交換は可能ではない。別の実施形態では、ウェイクアップパケットが認証されると、各ノードは、一般的なセキュリティの開始を必要とすることなく、限られた量のデータ（たとえば、１フレーム）の送信を可能にされる。
【０１００】
図１９は、ＡＥＳブロック暗号２０９０を実行することによる（及び、先に図示して説明したような）ＭＡＣ２０２０の生成を示している。ＡＥＳブロック暗号２０９０の「ノンス」レジスタには、データセット２０４５がロードされる。データセット２０４５は、送信者のＩＤ（ＩＤｓｅｎｄｅｒ）を最上位６バイトとして含み、送信者の現在のＭＣＴＲ値（ＭＣＴＲｓｅｎｄｅｒ）を次の３バイトとして含む。次の４バイトは、送信されるデータであり、最後のバイトは、目的とする受信者（複数可）を示すレセプタビットマップである。ＢＡＮキー２１００も、ＡＥＳブロック暗号２０９０に入力される。ＡＥＳブロック暗号２０９０の結果の出力２１１０から、最下位３バイトのデータが、ＭＣＡ２０２０として指定される。
【０１０１】
図２０は、セキュアウェイクアップパケットを生成及び送信するためのプロセスのフローチャートである。この例では、「アリス」１１５は、「ボブ」１１０へデータパケットを通信することを意図している。アリス１１５は、４バイトのデータ（たとえば、アリスのセンサデータ、患者アクティベータのコマンド等）を生成又は獲得する（２２００）。アリス１１５は、ＭＣＴＲの現在の値をメモリから読み出し（２２１０）、図１９に関して説明したようにＡＥＳブロック暗号２０９０をポピュレートする（２２２０）。ＭＡＣが取得され、アリス１１５は、４バイトのデータ、ＭＡＣ、及びＭＣＴＲ値を含むウェイクアップパケット２０００を構成する（２２４０）。好ましくは、ＢＡＮ内の各デバイスは、許容可能な送信時間を指定している。アリス１１５は、適切な時間窓の期間中、構成されたメッセージを送信する（２２５０）。新しいセキュアウェイクアップメッセージが構成された時、アリス１１５は、ＭＣＴＲをインクリメントする（２２６０）。
【０１０２】
メッセージが適切に受信されたと仮定すると、アリス１１５は、受信者からＡＣＫメッセージを受信することができる（２２７０）。ＡＣＫメッセージが、予測されるが受信されない場合、又は、他のエラーが発生した場合、アリス１１５は、新しいＭＡＣを生成せず、且つ、ＭＣＴＲをインクリメントせずに同じメッセージを再送することができる（２２５０）。ＡＣＫがアリス１１５によって受信されると、ネイティブモードセッションが確立される（２２８０）。一実施形態では、これは、単に、アリスがデータの送信及び（適切な場合に）ＡＣＫメッセージの受信に成功したという点で、セッションが終了される（２２９０）ことを意味する。代替的な一構成では、ネイティブモードセッションを確立する（２２８０）ことによって、セッションに携わるＢＡＮの各デバイスは、たとえば１フレームといった限られた量のデータを送信することが可能になる。したがって、破線で示すように、アリス１１５は、さらなるフレームデータを送信する（２３００）。ネイティブセッションの各デバイスは、送信することが可能になり、したがって、アリス１１５は、ＢＡＮの別のデバイスからデータのフレームを受信することができる（２３１０）。ＡＣＫ／ＮＡＣＫメッセージが可能になり（２３２０）、セッションは、その後、終了される。
【０１０３】
このように、ウェイクアップパケットがセキュアにされ、少量のデータが、一般的なセキュリティを確立せずに送信可能である。大量のデータを送信する必要がある場合、前述したように、一般的なセキュリティプロトコルが実施される。
【０１０４】
図２１は、たとえばボブ１１０といった受信ノードが、可能性のあるセキュアにされたウェイクアップメッセージの受信時に用いるプロセスのフローチャートである。ボブ１１０は、メッセージを受信し（２４００）、送信者を識別する（２４１０）。これは、たとえばアリス１１５への送信用に割り当てられたネットワークタイムスロットに基づいて行うこともできるし、他の識別手段に基づいて行うこともできる。いずれの場合も、ボブ１１０は、それが、その称するところ、メッセージを送信したアリス１１５であること、及び、ボブ１１０が目的とする受信者であることを識別する。ボブ１１０は、送信されたメッセージからＭＣＴＲ値を抽出し（２４２０）、ボブ１１０がアリス１１５についてメモリに記憶しているＭＣＴＲ値と比較する（２４３０）。ステップ２４４０において、受信されたＭＣＴＲ値が、ボブ１１０がアリスについて記憶している値よりも小さい場合、メッセージは無視される（２４５０）。ＭＣＴＲ値が、記憶されている値よりも大きい場合、ボブ１１０は、受信されたＭＣＴＲが正しいと一時的に仮定し（２４６０）、受信された値の利用に進む。同様に、受信されたＭＣＴＲ値が、記憶されている値に等しい場合、ボブ１１０は次のステップに進む。
【０１０５】
いずれの場合も、受信されたＭＣＴＲを利用して、アリス１１５と同じ方法で、ＡＥＳブロック暗号２０９０によってＭＡＣが計算される。ボブ１１０によって計算されたＭＡＣ値は、ボブ１１０によって受信されたＭＡＣ値と比較される（２４８０）。これらのＭＡＣ値が一致しない場合、メッセージは無視される（２４９０）。これらのＭＡＣ値が一致する場合、ボブ１１０は、ネイティブモードに入り（２５００）、それに従ってデータを受理する（２５１０）。ボブ１１０は、アリス１１５に関連したＭＣＴＲ値を更新する（２５１５）。この結果、増分値が、アリス１１５によって送信されたＭＣＴＲ値の有効に加えられる。オプションとして、ボブ１１０は、ＡＣＫ／ＮＡＣＫメッセージをセキュアにして送信することができる（２５２０）。セッションは、その後、終了される（２５３０）。
【０１０６】
代替的な一実施形態では、ネイティブモードに入った（２５００）各ノードは、さらなるデータのフレームを送信することができる。したがって、ボブ１１０は、さらなる量のデータをアリス１１５へ送信することができ（２５４０）、同様に、アリス１１５は、さらなるデータのフレームを送信することができる（２５５０）。セッションキーは、セッション間の新しさを保証するために、ＭＡＣ出力の一部によって定められる。各ノードは、適切なＡＣＫ／ＮＡＣＫメッセージ２５２０を送信することが可能になり、セッションは、その後、終了される（２５３０）。ＡＥＳ＿ｏｕｔ２１１０、ＢＡＮキー２１００がＫｓｅｓの代わりに利用され、ノンスカウンタの最下位３バイトがＭＣＴＲ値で開始され、次に最上位２バイトがＭＣＴＲ値の最下位２バイトを利用し、最上位バイトが０で開始される点を除いて、パケット及びフレームは、一般的なセキュリティに関して、前述したようにセキュアにされる。
【０１０７】
送信前に、オプションとして、ユーザデータの４バイトにデータプライバシー（暗号化）を適用することができる。暗号化及びその後の解読は、（ちょうどネイティブモード通信について行われるように）これらの４バイトのユーザバイトを４バイトのキーストリームとＸＯＲすることによって実現することができる。４バイトのキーストリームは、２１１０の未使用バイトから得ることもできるし、アリス及びボブの双方に知られている異なるノンス値を使用したブロック暗号の別の実行から得ることもできる。
【０１０８】
本発明のさまざまな実施形態を説明してきたが、これらのさまざまな実施形態は、例示であって限定することを意図するものではない。開示された主題の複数の部分は、本発明の精神及び範囲内にあり、明示的に述べられていない実施形態において組み合わせることができる。
【特許請求の範囲】
【請求項１】
少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、前記第１のノードから前記第２のノードへセキュアにされている(secured)テレメトリーウェイクアップパケット(wake-up packet)で使用可能データを送信する方法であって、該方法は、
前記第１のノード内で所定のプロトコルを使用してメッセージ認証コードを生成するステップと、
前記第１のノードによって作成された（authored）ウェイクアップ送信の数を示す現在のカウンタ値を前記第１のノードのメモリから取得するステップと、
前記第２のノードの識別情報(identification)を求める(determining)ステップと、
前記メッセージ認証コード、前記現在のカウンタ値、及び所定の量の使用可能データを含む、前記第２のノード用の送信可能なウェイクアップメッセージを構成(composing)するステップと、
前記ウェイクアップメッセージを送信するステップと、
を含む、方法。
【請求項２】
前記メッセージ認証コードは、１２８ビットブロック暗号で生成される、請求項１に記載の方法。
【請求項３】
前記方法認証コードを生成することは、
前記第１のノードを示す識別子(identifier)を、前記ブロック暗号(block cipher)の入力レジスタに入力すること、
前記現在のカウンタ値を前記入力レジスタに入力すること、
前記使用可能データ(actionable data)を前記入力レジスタに入力すること、
前記第２のノードを示すレセプタ識別情報値(receptor identification value)を前記入力レジスタに入力すること、
前記ブロック暗号にネットワークキーを証明する(proving)こと、及び
少なくとも一部が前記方法認証コードを形成する、出力値を前記ブロック暗号から生成すること、
をさらに含む、請求項２に記載の方法。
【請求項４】
前記第２のノードから肯定応答(acknowledgement)メッセージを受信することをさらに含む、請求項１に記載の方法。
【請求項５】
使用可能データを含む前記ウェイクアップメッセージの送信の成功によって、ネイティブモードテレメトリーセッションが開始し、それによって、前記ネイティブモードにあるいずれのノードも、前記ウェイクアップパケットを受信するとＡＣＫ／ＮＡＣＫメッセージを送信することができる、請求項１に記載の方法。
【請求項６】
さらなるデータ交換を一切許可することなく(without permitting)、前記ネイティブモードセッションを終了することをさらに含む、請求項５に記載の方法。
【請求項７】
前記ネイティブモードセッションに携わる(engaged in)各ノードが、所定の、及び、各ノードがＡＣＫ／ＮＡＣＫメッセージを送信できる、単一のデータパケットを送信することを可能にすること、及び
さらなるデータ交換を可能にすることなく、前記ネイティブモードセッションを終了すること、
をさらに含む、請求項５に記載の方法。
【請求項８】
前記第２のノードにおいて前記ウェイクメッセージを受信すること、
前記ウェイクアップメッセージの送信者を識別すること、
前記ウェイクアップメッセージから前記現在のカウンタ値を抽出すること、
前記現在のカウンタ値を、前記第２のノードのメモリ内に記憶されている第１のノードのカウンタ値と比較すること、
メッセージの有効性を評価する第１のメカニズムとして前記比較を利用すること、
前記ウェイクアップメッセージから前記メッセージ認証コードを抽出すること、
前記第２のノードによってアクセス可能な第１のノードのデータをブロック暗号で利用して、第１のノードのメッセージ認証コードを計算すること、
メッセージの有効性を評価する第２のメカニズムとして、前記第１のノードのメッセージ認証コードを、前記ウェイクアップメッセージから抽出された前記メッセージ認証コードと比較すること、及び
前記第１のメカニズム及び前記第２のメカニズムの双方がメッセージの有効性を示している場合に、前記ウェイクアップメッセージから前記使用可能データを受け入れること、
をさらに含む、請求項１に記載の方法。
【請求項９】
メッセージの有効性を評価する前記第１のメカニズムは、
前記現在のカウンタ値が、前記第２のノードの前記メモリに記憶されている前記第１のノードのカウンタ値よりも小さい場合には、前記ウェイクアップメッセージを無視すること、
前記第１のノードのカウンタ値が前記現在のカウンタ値に等しい場合には、前記第２のメカニズムに進む(advancing)と共に、前記第１のノードのカウンタ値を利用(utilizing)すること、及び
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きい場合には、前記第２のメカニズムに進むと共に、前記現在のカウンタ値を利用すること、
をさらに含む、請求項８に記載の方法。
【請求項１０】
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きく、且つ、前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のノードの前記メモリにおいて、前記第１のノードのカウンタ値を前記現在のカウンタ値に置き換えることをさらに含む、請求項９に記載の方法。
【請求項１１】
前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のデバイスの前記メモリにおいて、前記第１のノードのカウンタ値をインクリメントすることをさらに含む、請求項９に記載の方法。
【請求項１２】
前記第２のメカニズムがメッセージの有効性を示している場合には、ネイティブモードテレメトリーセッションに入ることをさらに含み、前記第２のノードは、ＡＣＫメッセージの送信を許可される、請求項９に記載の方法。
【請求項１３】
さらなるデータ交換を許可することなく、前記テレメトリーセッションを終了することをさらに含む、請求項１２に記載の方法。
【請求項１４】
前記ネイティブテレメトリーモードにおいて各ノードからの単一のさらなるデータ送信の受信を可能にすること、前記第２のノードからの単一のデータ送信の送信を許可すること、及び、前記ネイティブテレメトリーモードの終了よりも前にＡＣＫ／ＮＡＣＫメッセージを送受信することをさらに含む、請求項１２に記載の方法。
【請求項１５】
少なくとも第１のノード及び第２のノードを有する電気通信ネットワークであって、前記第１のノードから前記第２のノードへセキュアにされているテレメトリーウェイクアップパケットで使用可能データを送信することを含み、
前記第１のノード内で所定のプロトコルを使用してメッセージ認証コードを生成する手段と、
前記第１のノードによって作成されたウェイクアップ送信の数を示す現在のカウンタ値を前記第１のノードのメモリから取得する手段と、
前記第２のノードの識別情報を求める手段と、
前記メッセージ認証コード、前記現在のカウンタ値、及び所定の量の使用可能データを含む、前記第２のノード用の送信可能なウェイクアップメッセージを構成する手段と、
前記ウェイクアップメッセージを送信する手段と、
を備える、ネットワーク。
【請求項１６】
前記方法認証コードを生成することは、
前記第１のノードを示す識別子を、前記ブロック暗号の入力レジスタに入力する手段と、
前記現在のカウンタ値を前記入力レジスタに入力する手段と、
前記使用可能データを前記入力レジスタに入力する手段と、
前記第２のノードを示すレセプタ識別情報値を前記入力レジスタに入力する手段と、
前記ブロック暗号にネットワークキーを証明する手段と、
少なくとも一部が前記方法認証コードを形成する、出力値を前記ブロック暗号から生成する手段と、
をさらに備える、請求項１５に記載のネットワーク。
【請求項１７】
前記ウェイクアップメッセージの受信に成功するとネイティブモードテレメトリーセッションを開始する手段と、
前記ネイティブモードセッションに携わる各ノードが、所定の、及び、各ノードがＡＣＫ／ＮＡＣＫメッセージを送信できる、単一のデータパケットを送信することを許可する手段と、
さらなるデータ交換を一切許可することなく、前記ネイティブモードセッションを終了する手段と、
をさらに備える、請求項１６に記載のネットワーク。
【請求項１８】
前記第２のノードにおいて前記ウェイクメッセージを受信する手段と、
前記ウェイクアップメッセージの送信者を識別する手段と、
前記ウェイクアップメッセージから前記現在のカウンタ値を抽出する手段と、
前記現在のカウンタ値を、前記第２のノードのメモリ内に記憶されている第１のノードのカウンタ値と比較する手段と、
メッセージの有効性を評価する第１のメカニズムとして前記比較を利用する手段と、
前記ウェイクアップメッセージから前記メッセージ認証コードを抽出する手段と、
前記第２のノードによってアクセス可能な第１のノードのデータをブロック暗号で利用して、第１のノードのメッセージ認証コードを計算する手段と、
メッセージの有効性を評価する第２のメカニズムとして、前記第１のノードのメッセージ認証コードを、前記ウェイクアップメッセージから抽出された前記メッセージ認証コードと比較する手段と、
前記第１のメカニズム及び前記第２のメカニズムの双方がメッセージの有効性を示している場合に、前記ウェイクアップメッセージから前記使用可能データを受け入れる手段と、
をさらに備える、請求項１５に記載のネットワーク。
【請求項１９】
メッセージの有効性を評価する前記第１のメカニズムは、
前記現在のカウンタ値が、前記第２のノードの前記メモリに記憶されている前記第１のノードのカウンタ値よりも小さい場合には、前記ウェイクアップメッセージを無視する手段と、
前記第１のノードのカウンタ値が前記現在のカウンタ値に等しい場合には、前記第２のメカニズムに進むと共に、前記第１のノードのカウンタ値を利用する手段と、
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きい場合には、前記第２のメカニズムに進むと共に、前記現在のカウンタ値を利用する手段と、
をさらに備える、請求項１８に記載のネットワーク。
【請求項２０】
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きく、且つ、前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のノードの前記メモリにおいて、前記第１のノードのカウンタ値を前記現在のカウンタ値に置き換える手段をさらに含む、請求項１９に記載のネットワーク。
【請求項２１】
相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意の識別子を各ノードに割り当てるステップと、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記ネットワークキーを少なくとも前記第２のノードに提供するステップと、
前記第２のノードの識別子を前記第１のノードに提供するステップと、
認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップと、
前記第１のノードの識別子及び前記第２のノードの識別子を含む第１の通信を準備するステップと、
前記第２のノードのデバイスキーで前記第１の通信をセキュアにするステップと、
前記第１の通信を前記第２のノードへ送信するステップと、
前記第２のノードにおいて、前記第２のノードのデバイスキーを使用して前記第１の通信を解読するステップと、
前記第２のノードのデバイスキーが前記第１の通信をセキュアにするのに使用されたことの検証を条件として、前記第１のノードに前記ネットワークキーを提供するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノードと第２のノードとの間の第２の通信をセキュアにするステップと、
を含む、方法。
【請求項２２】
認可されていない発見を受けにくい方法による前記第２のノードのデバイスキーの前記第１のノードへの提供は、物理トークンからの前記デバイスキーの入力によって行われる、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２３】
前記認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップは、
前記第２のノードのデバイスキーを物理トークン上に配置するステップと、
前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを転送するステップと、
を含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２４】
前記認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップにおいて、前記第２のノードのデバイスキーは、前記物理トークン上に記憶され、前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを転送するステップは、電子的に行われる、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２５】
前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを電子的に転送する前記ステップは、前記第１のノードが前記デバイスキーを暗号化された形態で提供される方法で行われる、請求項２４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２６】
前記物理トークンは、少なくとも１つのプロセッサを含むキーフォブである、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２７】
前記第１の通信をセキュアにするステップは、前記キーフォブの前記少なくとも１つのプロセッサによって実行される、請求項２６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２８】
前記物理トークンはスマートカードである、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２９】
前記第１の通信をセキュアにするステップは、前記スマートカードによって実行される、請求項２８に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３０】
前記第２のノードのデバイスキーは、認証情報によって暗号化されて、前記スマートカード上に記憶される、請求項２９に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３１】
前記認証情報は、パスワード文字の文字列を含む、請求項３０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３２】
前記認証情報は、バイオメトリックパラメータを含む、請求項３０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３３】
前記ネットワークは、医療データサービスネットワークを含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３４】
前記少なくとも第１のノード及び第２のノードのうちの少なくとも１つは、埋め込み可能医療デバイスを含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３５】
相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意の識別子を各ノードに割り当てるステップと、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記ネットワークキーを少なくとも前記第１のノードに提供するステップと、
前記第２のノードの識別子を前記第１のノードに提供するステップと、
前記第２のノードのデバイスキーを前記第１のノードにセキュアに提供するステップと、
前記第１のノードの識別子、前記第２のノードの識別子、及び前記ネットワークキーを含む第１の通信を前記第２のノードから前記第１のノードへ送信するステップであって、該第１の通信は、前記第２のノードのデバイスキーでセキュアにされる、送信するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の第２の通信をセキュアにするステップと、
を含む、方法。
【請求項３６】
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにするステップは、
前記第１のノードにおいて、前記ネットワークキーと第１の任意の数との関数としてセッションキーを生成するステップと、
前記第２のノードにおいて、前記ネットワークキーと前記第１の任意の数との関数として前記セッションキーを独立に生成するステップと、
前記セッションキーを使用するステップであって、前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにする、使用するステップと、
を含む、請求項３５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３７】
前記第１の任意の数は疑似乱数である、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３８】
前記第１の任意の数は、
前記第１のノードにおいて第２の任意の数を生成するステップと、
前記第２の任意の数を前記第２のノードに提供するステップと、
前記第２のノードにおいて第３の任意の数を生成するステップと、
前記第３の任意の数を前記第１のノードに提供するステップと、
前記第２の任意の数と前記第３の任意の数との双方の関数として前記第１の任意の数を生成するステップと、
を含む、任意の数を生成する方法によって生成される、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３９】
前記第２の任意の数及び前記第３の任意の数のうちの少なくとも一方は、疑似乱数である、請求項３８に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４０】
前記セッションキーで前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにするステップは、暗号の出力と平文を含むメッセージとの間のビット単位のモジュロ２加算を実行するステップを含み、前記暗号の前記出力は、前記セッションキーと、前記通信セッション内において一意の第１のノンスとの双方の関数である、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４１】
前記第１のノンスは、前記通信セッション中に前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数と、該個々の通信のサイズとの関数である、請求項４０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４２】
前記個々の通信はパケットである、請求項４１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４３】
前記個々の通信の前記サイズは、ブロック単位で測定される、請求項４２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４４】
前記暗号はブロック暗号である、請求項４３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４５】
アペンドされる個々の通信から導出される認証タグを各個々の通信にアペンドするステップをさらに含む、請求項４４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４６】
前記認証タグは、前記セッションキーと、通信されている前記メッセージの前記平文との関数である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４７】
前記認証タグは、第２のノンスの関数でもあり、該第２のノンスは、前記通信セッション中に前記ネットワークの前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数の関数である、請求項４６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４８】
前記認証タグは、前記セッションキーと、通信されている前記メッセージの前記平文と、前記通信セッション中に前記ネットワークの前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数との関数である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４９】
前記認証タグは、該認証タグがアペンドされる前記個々の通信に対して行われたハッシュ関数の結果である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５０】
相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記第１のノードに任意の数を提供するステップと、
認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップと、
前記第２のノードのデバイスキー及び前記任意の数で第１の通信をセキュアにするステップと、
前記第１の通信を前記第２のノードへ送信するステップと、
前記第２のノードにおいて、前記第２のノードのデバイスキー及び前記任意の数を使用して前記第１の通信を解読するステップと、
前記第１の通信が前記第２のノードのデバイスキー及び前記任意の数でセキュアにされたことが前記第２のノードにおいて検証されると、前記第１のノードに前記ネットワークキーを提供するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の第２の通信をセキュアにするステップと、
を含む、方法。
【請求項５１】
前記任意の数は疑似乱数である、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５２】
前記任意の数は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として前記任意の数を生成するステップと、
を含む、コンピュータによって実施される、任意の数を生成する、方法によって生成される、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５３】
前記参照キー及び前記初期化数のうちの少なくとも一方は任意である、請求項５２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５４】
前記参照キー及び前記初期化数のうちの少なくとも一方は疑似乱数である、請求項５３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５５】
前記任意の数は疑似乱数である、請求項５４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５６】
前記任意の数は、前記参照キーと、前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果との関数である、請求項５５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５７】
前記任意の数は、前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果を前記参照キーで暗号化することによって生成される、請求項５６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５８】
前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果を前記参照キーで暗号化することは、ブロック暗号を使用して実施される、請求項５７に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５９】
前記任意の数を生成する方法は、前記初期化数を前記任意の数で更新するステップをさらに含む、請求項５２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項６０】
前記任意の数は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として第２の中間数を生成するステップと、
前記第１の中間値と前記第２の中間値と前記参照キーとの関数として前記任意の数を生成するステップと、
を含む、コンピュータによって実施される、任意の数を生成する方法によって生成される、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項６１】
少なくとも２つのノードを備えるセキュア無線ネットワークであって、該少なくとも２つのノードのうちの少なくとも一方は、プログラマブルプロセッサ及びコンピュータ可読ストレージ素子を備え、前記コンピュータ可読ストレージ素子は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として第２の中間数を生成するステップと、
前記第１の中間値と前記第２の中間値と前記参照キーとの関数として任意の数を生成するステップと、
前記少なくとも２つのノードの間で送信される通信を前記任意の数でセキュアにするステップと、
を含む、任意の数を生成する方法を前記プログラマブルプロセッサに遂行させるための命令を含む、セキュア無線ネットワーク。
【請求項６２】
物理トークンをさらに備え、前記物理トークン及び前記少なくとも２つのノードのうちの少なくとも１つは、前記プログラマブルプロセッサ及び前記コンピュータ可読ストレージ素子を備える、請求項６１に記載のセキュア無線ネットワーク。
【請求項６３】
生物に埋め込むようになっている医療デバイスであって、
療法管理ユニットと、
電源と、
送信機と、
受信機と、
一意のデバイスキーと、
皮下動作可能な物理スイッチと、
該医療デバイスとネットワーク接続されたデバイスからの要求にのみ応答して、前記物理スイッチを起動可能にするようになっているスイッチ制御モジュールと、
を備える医療デバイス。
【請求項６４】
無線ネットワーク内の通信をセキュアにするようになっているネットワークキーと、
前記ネットワークキーを記憶するようになっている電子メモリと、
をさらに備え、
該医療デバイスは、前記物理スイッチの起動に応答して前記ネットワークキーを無線で送信するようになっている、請求項６３に記載の医療デバイス。
【請求項６５】
セッションキーと、
前記セッションキーを記憶するようになっている電子メモリと、
をさらに備え、
該医療デバイスは、前記物理スイッチの起動に応答して前記セッションキーを無線で送信するようになっている、請求項６３に記載の医療デバイス。
【請求項６６】
前記物理スイッチは、磁気リードセンサを備える、請求項６３に記載の医療デバイス。
【請求項６７】
前記物理スイッチは、ホール効果センサを備える、請求項６３に記載の医療デバイス。
【請求項６８】
前記物理スイッチは、加速度計を備える、請求項６３に記載の医療デバイス。
【請求項６９】
前記物理スイッチは、超音波センサを備える、請求項６３に記載の医療デバイス。
【請求項７０】
前記物理スイッチは、光検出器を備える、請求項６３に記載の医療デバイス。
【請求項７１】
少なくとも２つのノードを備えるセキュア無線ネットワークであって、少なくとも１つのノードは、物理スイッチを有し、該物理スイッチは、該セキュア無線ネットワークに物理的に極めて接近しているときにのみ起動するようになっており、前記物理スイッチを有する前記少なくとも１つノードは、前記物理スイッチが起動すると、さらに、該セキュア無線ネットワーク上の少なくとも１つの他のノードへ秘密キーを送信するようにさらになっている、セキュア無線ネットワーク。
【請求項７２】
要求側デバイスをさらに備え、前記物理スイッチは、前記要求側デバイスが、該セキュア無線ネットワークのエリアに対して相対的に、前記物理スイッチを有する前記少なくとも１つのノードに物理的に極めて接近することによってのみ起動され、前記秘密キーは、ネットワークキー又はセッションキーである、請求項７１に記載のセキュア無線ネットワーク。
【請求項７３】
前記物理スイッチを有する前記少なくとも１つのノードは、前記セキュア無線ネットワークにおける別のノードから送信された要求があった時にのみ、前記物理スイッチを起動できる状態を該物理スイッチにおいて達成するようになっている、請求項７１に記載のセキュア無線ネットワーク。
【請求項７４】
テレメトリーセキュリティシステムによってセキュアにされ、第１の送信範囲を有する無線ネットワークにおいて、該無線ネットワークに対して自身を認証する認証情報を有しない非メンバーノードに、該無線ネットワークの少なくとも１つのメンバーノードへのアクセスを提供する方法であって、
前記少なくとも１つのメンバーノードに、要求側デバイスが物理的に接近することによって起動されるようになっている物理スイッチを提供するステップと、
要求側デバイスを、前記少なくとも１つのメンバーノードの前記物理スイッチに物理的に接近して配置することによって、該少なくとも１つのメンバーノードの該物理スイッチを起動するステップと、
前記物理スイッチを起動することに応答して、前記物理スイッチを有する前記少なくとも１つのメンバーノードの送信電力を削減するステップであって、前記第１の送信範囲よりも小さな第２の送信範囲を達成する、削減するステップと、
前記非メンバーノードを前記第２の送信範囲内に配置するステップと、
前記物理スイッチを有する前記少なくとも１つのメンバーノードから前記非メンバーノードへ認証情報を送信するステップと、
前記非メンバーノードによって、前記無線ネットワークの前記少なくとも１つのメンバーノードへ前記認証情報を提供することによって、前記無線ネットワークに対して前記非メンバーノードを認証するステップと、
を含む方法。
【請求項７５】
前記物理スイッチは、加速度計を備える、請求項１２に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７６】
前記物理スイッチは、超音波センサを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７７】
前記物理スイッチは、磁気リードスイッチを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７８】
前記物理スイッチは、ホール効果センサを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７９】
前記要求側デバイスは、磁石を備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項８０】
前記磁石は、前記非メンバーノード内に統合されている、請求項７９に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項８１】
前記無線ネットワークは、医療データサービスネットワークである、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項８２】
前記要求側デバイスが物理的に接近することによって起動されるようになっている物理スイッチを有する前記少なくとも１つのメンバーノードは、埋め込み可能医療デバイスである、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項１】
少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、前記第１のノードから前記第２のノードへセキュアにされている(secured)テレメトリーウェイクアップパケット(wake-up packet)で使用可能データを送信する方法であって、該方法は、
前記第１のノード内で所定のプロトコルを使用してメッセージ認証コードを生成するステップと、
前記第１のノードによって作成された（authored）ウェイクアップ送信の数を示す現在のカウンタ値を前記第１のノードのメモリから取得するステップと、
前記第２のノードの識別情報(identification)を求める(determining)ステップと、
前記メッセージ認証コード、前記現在のカウンタ値、及び所定の量の使用可能データを含む、前記第２のノード用の送信可能なウェイクアップメッセージを構成(composing)するステップと、
前記ウェイクアップメッセージを送信するステップと、
を含む、方法。
【請求項２】
前記メッセージ認証コードは、１２８ビットブロック暗号で生成される、請求項１に記載の方法。
【請求項３】
前記方法認証コードを生成することは、
前記第１のノードを示す識別子(identifier)を、前記ブロック暗号(block cipher)の入力レジスタに入力すること、
前記現在のカウンタ値を前記入力レジスタに入力すること、
前記使用可能データ(actionable data)を前記入力レジスタに入力すること、
前記第２のノードを示すレセプタ識別情報値(receptor identification value)を前記入力レジスタに入力すること、
前記ブロック暗号にネットワークキーを証明する(proving)こと、及び
少なくとも一部が前記方法認証コードを形成する、出力値を前記ブロック暗号から生成すること、
をさらに含む、請求項２に記載の方法。
【請求項４】
前記第２のノードから肯定応答(acknowledgement)メッセージを受信することをさらに含む、請求項１に記載の方法。
【請求項５】
使用可能データを含む前記ウェイクアップメッセージの送信の成功によって、ネイティブモードテレメトリーセッションが開始し、それによって、前記ネイティブモードにあるいずれのノードも、前記ウェイクアップパケットを受信するとＡＣＫ／ＮＡＣＫメッセージを送信することができる、請求項１に記載の方法。
【請求項６】
さらなるデータ交換を一切許可することなく(without permitting)、前記ネイティブモードセッションを終了することをさらに含む、請求項５に記載の方法。
【請求項７】
前記ネイティブモードセッションに携わる(engaged in)各ノードが、所定の、及び、各ノードがＡＣＫ／ＮＡＣＫメッセージを送信できる、単一のデータパケットを送信することを可能にすること、及び
さらなるデータ交換を可能にすることなく、前記ネイティブモードセッションを終了すること、
をさらに含む、請求項５に記載の方法。
【請求項８】
前記第２のノードにおいて前記ウェイクメッセージを受信すること、
前記ウェイクアップメッセージの送信者を識別すること、
前記ウェイクアップメッセージから前記現在のカウンタ値を抽出すること、
前記現在のカウンタ値を、前記第２のノードのメモリ内に記憶されている第１のノードのカウンタ値と比較すること、
メッセージの有効性を評価する第１のメカニズムとして前記比較を利用すること、
前記ウェイクアップメッセージから前記メッセージ認証コードを抽出すること、
前記第２のノードによってアクセス可能な第１のノードのデータをブロック暗号で利用して、第１のノードのメッセージ認証コードを計算すること、
メッセージの有効性を評価する第２のメカニズムとして、前記第１のノードのメッセージ認証コードを、前記ウェイクアップメッセージから抽出された前記メッセージ認証コードと比較すること、及び
前記第１のメカニズム及び前記第２のメカニズムの双方がメッセージの有効性を示している場合に、前記ウェイクアップメッセージから前記使用可能データを受け入れること、
をさらに含む、請求項１に記載の方法。
【請求項９】
メッセージの有効性を評価する前記第１のメカニズムは、
前記現在のカウンタ値が、前記第２のノードの前記メモリに記憶されている前記第１のノードのカウンタ値よりも小さい場合には、前記ウェイクアップメッセージを無視すること、
前記第１のノードのカウンタ値が前記現在のカウンタ値に等しい場合には、前記第２のメカニズムに進む(advancing)と共に、前記第１のノードのカウンタ値を利用(utilizing)すること、及び
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きい場合には、前記第２のメカニズムに進むと共に、前記現在のカウンタ値を利用すること、
をさらに含む、請求項８に記載の方法。
【請求項１０】
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きく、且つ、前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のノードの前記メモリにおいて、前記第１のノードのカウンタ値を前記現在のカウンタ値に置き換えることをさらに含む、請求項９に記載の方法。
【請求項１１】
前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のデバイスの前記メモリにおいて、前記第１のノードのカウンタ値をインクリメントすることをさらに含む、請求項９に記載の方法。
【請求項１２】
前記第２のメカニズムがメッセージの有効性を示している場合には、ネイティブモードテレメトリーセッションに入ることをさらに含み、前記第２のノードは、ＡＣＫメッセージの送信を許可される、請求項９に記載の方法。
【請求項１３】
さらなるデータ交換を許可することなく、前記テレメトリーセッションを終了することをさらに含む、請求項１２に記載の方法。
【請求項１４】
前記ネイティブテレメトリーモードにおいて各ノードからの単一のさらなるデータ送信の受信を可能にすること、前記第２のノードからの単一のデータ送信の送信を許可すること、及び、前記ネイティブテレメトリーモードの終了よりも前にＡＣＫ／ＮＡＣＫメッセージを送受信することをさらに含む、請求項１２に記載の方法。
【請求項１５】
少なくとも第１のノード及び第２のノードを有する電気通信ネットワークであって、前記第１のノードから前記第２のノードへセキュアにされているテレメトリーウェイクアップパケットで使用可能データを送信することを含み、
前記第１のノード内で所定のプロトコルを使用してメッセージ認証コードを生成する手段と、
前記第１のノードによって作成されたウェイクアップ送信の数を示す現在のカウンタ値を前記第１のノードのメモリから取得する手段と、
前記第２のノードの識別情報を求める手段と、
前記メッセージ認証コード、前記現在のカウンタ値、及び所定の量の使用可能データを含む、前記第２のノード用の送信可能なウェイクアップメッセージを構成する手段と、
前記ウェイクアップメッセージを送信する手段と、
を備える、ネットワーク。
【請求項１６】
前記方法認証コードを生成することは、
前記第１のノードを示す識別子を、前記ブロック暗号の入力レジスタに入力する手段と、
前記現在のカウンタ値を前記入力レジスタに入力する手段と、
前記使用可能データを前記入力レジスタに入力する手段と、
前記第２のノードを示すレセプタ識別情報値を前記入力レジスタに入力する手段と、
前記ブロック暗号にネットワークキーを証明する手段と、
少なくとも一部が前記方法認証コードを形成する、出力値を前記ブロック暗号から生成する手段と、
をさらに備える、請求項１５に記載のネットワーク。
【請求項１７】
前記ウェイクアップメッセージの受信に成功するとネイティブモードテレメトリーセッションを開始する手段と、
前記ネイティブモードセッションに携わる各ノードが、所定の、及び、各ノードがＡＣＫ／ＮＡＣＫメッセージを送信できる、単一のデータパケットを送信することを許可する手段と、
さらなるデータ交換を一切許可することなく、前記ネイティブモードセッションを終了する手段と、
をさらに備える、請求項１６に記載のネットワーク。
【請求項１８】
前記第２のノードにおいて前記ウェイクメッセージを受信する手段と、
前記ウェイクアップメッセージの送信者を識別する手段と、
前記ウェイクアップメッセージから前記現在のカウンタ値を抽出する手段と、
前記現在のカウンタ値を、前記第２のノードのメモリ内に記憶されている第１のノードのカウンタ値と比較する手段と、
メッセージの有効性を評価する第１のメカニズムとして前記比較を利用する手段と、
前記ウェイクアップメッセージから前記メッセージ認証コードを抽出する手段と、
前記第２のノードによってアクセス可能な第１のノードのデータをブロック暗号で利用して、第１のノードのメッセージ認証コードを計算する手段と、
メッセージの有効性を評価する第２のメカニズムとして、前記第１のノードのメッセージ認証コードを、前記ウェイクアップメッセージから抽出された前記メッセージ認証コードと比較する手段と、
前記第１のメカニズム及び前記第２のメカニズムの双方がメッセージの有効性を示している場合に、前記ウェイクアップメッセージから前記使用可能データを受け入れる手段と、
をさらに備える、請求項１５に記載のネットワーク。
【請求項１９】
メッセージの有効性を評価する前記第１のメカニズムは、
前記現在のカウンタ値が、前記第２のノードの前記メモリに記憶されている前記第１のノードのカウンタ値よりも小さい場合には、前記ウェイクアップメッセージを無視する手段と、
前記第１のノードのカウンタ値が前記現在のカウンタ値に等しい場合には、前記第２のメカニズムに進むと共に、前記第１のノードのカウンタ値を利用する手段と、
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きい場合には、前記第２のメカニズムに進むと共に、前記現在のカウンタ値を利用する手段と、
をさらに備える、請求項１８に記載のネットワーク。
【請求項２０】
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きく、且つ、前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のノードの前記メモリにおいて、前記第１のノードのカウンタ値を前記現在のカウンタ値に置き換える手段をさらに含む、請求項１９に記載のネットワーク。
【請求項２１】
相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意の識別子を各ノードに割り当てるステップと、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記ネットワークキーを少なくとも前記第２のノードに提供するステップと、
前記第２のノードの識別子を前記第１のノードに提供するステップと、
認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップと、
前記第１のノードの識別子及び前記第２のノードの識別子を含む第１の通信を準備するステップと、
前記第２のノードのデバイスキーで前記第１の通信をセキュアにするステップと、
前記第１の通信を前記第２のノードへ送信するステップと、
前記第２のノードにおいて、前記第２のノードのデバイスキーを使用して前記第１の通信を解読するステップと、
前記第２のノードのデバイスキーが前記第１の通信をセキュアにするのに使用されたことの検証を条件として、前記第１のノードに前記ネットワークキーを提供するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノードと第２のノードとの間の第２の通信をセキュアにするステップと、
を含む、方法。
【請求項２２】
認可されていない発見を受けにくい方法による前記第２のノードのデバイスキーの前記第１のノードへの提供は、物理トークンからの前記デバイスキーの入力によって行われる、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２３】
前記認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップは、
前記第２のノードのデバイスキーを物理トークン上に配置するステップと、
前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを転送するステップと、
を含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２４】
前記認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップにおいて、前記第２のノードのデバイスキーは、前記物理トークン上に記憶され、前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを転送するステップは、電子的に行われる、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２５】
前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを電子的に転送する前記ステップは、前記第１のノードが前記デバイスキーを暗号化された形態で提供される方法で行われる、請求項２４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２６】
前記物理トークンは、少なくとも１つのプロセッサを含むキーフォブである、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２７】
前記第１の通信をセキュアにするステップは、前記キーフォブの前記少なくとも１つのプロセッサによって実行される、請求項２６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２８】
前記物理トークンはスマートカードである、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項２９】
前記第１の通信をセキュアにするステップは、前記スマートカードによって実行される、請求項２８に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３０】
前記第２のノードのデバイスキーは、認証情報によって暗号化されて、前記スマートカード上に記憶される、請求項２９に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３１】
前記認証情報は、パスワード文字の文字列を含む、請求項３０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３２】
前記認証情報は、バイオメトリックパラメータを含む、請求項３０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３３】
前記ネットワークは、医療データサービスネットワークを含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３４】
前記少なくとも第１のノード及び第２のノードのうちの少なくとも１つは、埋め込み可能医療デバイスを含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３５】
相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意の識別子を各ノードに割り当てるステップと、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記ネットワークキーを少なくとも前記第１のノードに提供するステップと、
前記第２のノードの識別子を前記第１のノードに提供するステップと、
前記第２のノードのデバイスキーを前記第１のノードにセキュアに提供するステップと、
前記第１のノードの識別子、前記第２のノードの識別子、及び前記ネットワークキーを含む第１の通信を前記第２のノードから前記第１のノードへ送信するステップであって、該第１の通信は、前記第２のノードのデバイスキーでセキュアにされる、送信するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の第２の通信をセキュアにするステップと、
を含む、方法。
【請求項３６】
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにするステップは、
前記第１のノードにおいて、前記ネットワークキーと第１の任意の数との関数としてセッションキーを生成するステップと、
前記第２のノードにおいて、前記ネットワークキーと前記第１の任意の数との関数として前記セッションキーを独立に生成するステップと、
前記セッションキーを使用するステップであって、前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにする、使用するステップと、
を含む、請求項３５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３７】
前記第１の任意の数は疑似乱数である、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３８】
前記第１の任意の数は、
前記第１のノードにおいて第２の任意の数を生成するステップと、
前記第２の任意の数を前記第２のノードに提供するステップと、
前記第２のノードにおいて第３の任意の数を生成するステップと、
前記第３の任意の数を前記第１のノードに提供するステップと、
前記第２の任意の数と前記第３の任意の数との双方の関数として前記第１の任意の数を生成するステップと、
を含む、任意の数を生成する方法によって生成される、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項３９】
前記第２の任意の数及び前記第３の任意の数のうちの少なくとも一方は、疑似乱数である、請求項３８に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４０】
前記セッションキーで前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにするステップは、暗号の出力と平文を含むメッセージとの間のビット単位のモジュロ２加算を実行するステップを含み、前記暗号の前記出力は、前記セッションキーと、前記通信セッション内において一意の第１のノンスとの双方の関数である、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４１】
前記第１のノンスは、前記通信セッション中に前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数と、該個々の通信のサイズとの関数である、請求項４０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４２】
前記個々の通信はパケットである、請求項４１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４３】
前記個々の通信の前記サイズは、ブロック単位で測定される、請求項４２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４４】
前記暗号はブロック暗号である、請求項４３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４５】
アペンドされる個々の通信から導出される認証タグを各個々の通信にアペンドするステップをさらに含む、請求項４４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４６】
前記認証タグは、前記セッションキーと、通信されている前記メッセージの前記平文との関数である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４７】
前記認証タグは、第２のノンスの関数でもあり、該第２のノンスは、前記通信セッション中に前記ネットワークの前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数の関数である、請求項４６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４８】
前記認証タグは、前記セッションキーと、通信されている前記メッセージの前記平文と、前記通信セッション中に前記ネットワークの前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数との関数である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項４９】
前記認証タグは、該認証タグがアペンドされる前記個々の通信に対して行われたハッシュ関数の結果である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５０】
相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記第１のノードに任意の数を提供するステップと、
認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップと、
前記第２のノードのデバイスキー及び前記任意の数で第１の通信をセキュアにするステップと、
前記第１の通信を前記第２のノードへ送信するステップと、
前記第２のノードにおいて、前記第２のノードのデバイスキー及び前記任意の数を使用して前記第１の通信を解読するステップと、
前記第１の通信が前記第２のノードのデバイスキー及び前記任意の数でセキュアにされたことが前記第２のノードにおいて検証されると、前記第１のノードに前記ネットワークキーを提供するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の第２の通信をセキュアにするステップと、
を含む、方法。
【請求項５１】
前記任意の数は疑似乱数である、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５２】
前記任意の数は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として前記任意の数を生成するステップと、
を含む、コンピュータによって実施される、任意の数を生成する、方法によって生成される、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５３】
前記参照キー及び前記初期化数のうちの少なくとも一方は任意である、請求項５２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５４】
前記参照キー及び前記初期化数のうちの少なくとも一方は疑似乱数である、請求項５３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５５】
前記任意の数は疑似乱数である、請求項５４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５６】
前記任意の数は、前記参照キーと、前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果との関数である、請求項５５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５７】
前記任意の数は、前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果を前記参照キーで暗号化することによって生成される、請求項５６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５８】
前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果を前記参照キーで暗号化することは、ブロック暗号を使用して実施される、請求項５７に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項５９】
前記任意の数を生成する方法は、前記初期化数を前記任意の数で更新するステップをさらに含む、請求項５２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項６０】
前記任意の数は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として第２の中間数を生成するステップと、
前記第１の中間値と前記第２の中間値と前記参照キーとの関数として前記任意の数を生成するステップと、
を含む、コンピュータによって実施される、任意の数を生成する方法によって生成される、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。
【請求項６１】
少なくとも２つのノードを備えるセキュア無線ネットワークであって、該少なくとも２つのノードのうちの少なくとも一方は、プログラマブルプロセッサ及びコンピュータ可読ストレージ素子を備え、前記コンピュータ可読ストレージ素子は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として第２の中間数を生成するステップと、
前記第１の中間値と前記第２の中間値と前記参照キーとの関数として任意の数を生成するステップと、
前記少なくとも２つのノードの間で送信される通信を前記任意の数でセキュアにするステップと、
を含む、任意の数を生成する方法を前記プログラマブルプロセッサに遂行させるための命令を含む、セキュア無線ネットワーク。
【請求項６２】
物理トークンをさらに備え、前記物理トークン及び前記少なくとも２つのノードのうちの少なくとも１つは、前記プログラマブルプロセッサ及び前記コンピュータ可読ストレージ素子を備える、請求項６１に記載のセキュア無線ネットワーク。
【請求項６３】
生物に埋め込むようになっている医療デバイスであって、
療法管理ユニットと、
電源と、
送信機と、
受信機と、
一意のデバイスキーと、
皮下動作可能な物理スイッチと、
該医療デバイスとネットワーク接続されたデバイスからの要求にのみ応答して、前記物理スイッチを起動可能にするようになっているスイッチ制御モジュールと、
を備える医療デバイス。
【請求項６４】
無線ネットワーク内の通信をセキュアにするようになっているネットワークキーと、
前記ネットワークキーを記憶するようになっている電子メモリと、
をさらに備え、
該医療デバイスは、前記物理スイッチの起動に応答して前記ネットワークキーを無線で送信するようになっている、請求項６３に記載の医療デバイス。
【請求項６５】
セッションキーと、
前記セッションキーを記憶するようになっている電子メモリと、
をさらに備え、
該医療デバイスは、前記物理スイッチの起動に応答して前記セッションキーを無線で送信するようになっている、請求項６３に記載の医療デバイス。
【請求項６６】
前記物理スイッチは、磁気リードセンサを備える、請求項６３に記載の医療デバイス。
【請求項６７】
前記物理スイッチは、ホール効果センサを備える、請求項６３に記載の医療デバイス。
【請求項６８】
前記物理スイッチは、加速度計を備える、請求項６３に記載の医療デバイス。
【請求項６９】
前記物理スイッチは、超音波センサを備える、請求項６３に記載の医療デバイス。
【請求項７０】
前記物理スイッチは、光検出器を備える、請求項６３に記載の医療デバイス。
【請求項７１】
少なくとも２つのノードを備えるセキュア無線ネットワークであって、少なくとも１つのノードは、物理スイッチを有し、該物理スイッチは、該セキュア無線ネットワークに物理的に極めて接近しているときにのみ起動するようになっており、前記物理スイッチを有する前記少なくとも１つノードは、前記物理スイッチが起動すると、さらに、該セキュア無線ネットワーク上の少なくとも１つの他のノードへ秘密キーを送信するようにさらになっている、セキュア無線ネットワーク。
【請求項７２】
要求側デバイスをさらに備え、前記物理スイッチは、前記要求側デバイスが、該セキュア無線ネットワークのエリアに対して相対的に、前記物理スイッチを有する前記少なくとも１つのノードに物理的に極めて接近することによってのみ起動され、前記秘密キーは、ネットワークキー又はセッションキーである、請求項７１に記載のセキュア無線ネットワーク。
【請求項７３】
前記物理スイッチを有する前記少なくとも１つのノードは、前記セキュア無線ネットワークにおける別のノードから送信された要求があった時にのみ、前記物理スイッチを起動できる状態を該物理スイッチにおいて達成するようになっている、請求項７１に記載のセキュア無線ネットワーク。
【請求項７４】
テレメトリーセキュリティシステムによってセキュアにされ、第１の送信範囲を有する無線ネットワークにおいて、該無線ネットワークに対して自身を認証する認証情報を有しない非メンバーノードに、該無線ネットワークの少なくとも１つのメンバーノードへのアクセスを提供する方法であって、
前記少なくとも１つのメンバーノードに、要求側デバイスが物理的に接近することによって起動されるようになっている物理スイッチを提供するステップと、
要求側デバイスを、前記少なくとも１つのメンバーノードの前記物理スイッチに物理的に接近して配置することによって、該少なくとも１つのメンバーノードの該物理スイッチを起動するステップと、
前記物理スイッチを起動することに応答して、前記物理スイッチを有する前記少なくとも１つのメンバーノードの送信電力を削減するステップであって、前記第１の送信範囲よりも小さな第２の送信範囲を達成する、削減するステップと、
前記非メンバーノードを前記第２の送信範囲内に配置するステップと、
前記物理スイッチを有する前記少なくとも１つのメンバーノードから前記非メンバーノードへ認証情報を送信するステップと、
前記非メンバーノードによって、前記無線ネットワークの前記少なくとも１つのメンバーノードへ前記認証情報を提供することによって、前記無線ネットワークに対して前記非メンバーノードを認証するステップと、
を含む方法。
【請求項７５】
前記物理スイッチは、加速度計を備える、請求項１２に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７６】
前記物理スイッチは、超音波センサを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７７】
前記物理スイッチは、磁気リードスイッチを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７８】
前記物理スイッチは、ホール効果センサを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項７９】
前記要求側デバイスは、磁石を備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項８０】
前記磁石は、前記非メンバーノード内に統合されている、請求項７９に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項８１】
前記無線ネットワークは、医療データサービスネットワークである、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【請求項８２】
前記要求側デバイスが物理的に接近することによって起動されるようになっている物理スイッチを有する前記少なくとも１つのメンバーノードは、埋め込み可能医療デバイスである、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公表番号】特表２０１０−５０７９２８（Ｐ２０１０−５０７９２８Ａ）
【公表日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願番号】特願２００９−５２５６８９（Ｐ２００９−５２５６８９）
【出願日】平成１９年８月９日（２００７．８．９）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０７５５３７
【国際公開番号】ＷＯ２００８／０２１９２０
【国際公開日】平成２０年２月２１日（２００８．２．２１）
【出願人】（５９１００７８０４）メドトロニック，インコーポレイテッド (243)
【住所又は居所原語表記】７１０Ｍｅｄｔｒｏｎｉｃ Ｐａｒｋｗａｙ，Ｍｉｎｎｅａｐｏｌｉｓ，Ｍｉｎｎｅｓｏｔａ ５５４３２，Ｕ．Ｓ．Ａ
【Ｆターム（参考）】
【公表日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願日】平成１９年８月９日（２００７．８．９）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０７５５３７
【国際公開番号】ＷＯ２００８／０２１９２０
【国際公開日】平成２０年２月２１日（２００８．２．２１）
【出願人】（５９１００７８０４）メドトロニック，インコーポレイテッド (243)
【住所又は居所原語表記】７１０Ｍｅｄｔｒｏｎｉｃ Ｐａｒｋｗａｙ，Ｍｉｎｎｅａｐｏｌｉｓ，Ｍｉｎｎｅｓｏｔａ ５５４３２，Ｕ．Ｓ．Ａ
【Ｆターム（参考）】
[ Back to top ]