特表 2024-507751 通信のためのセキュリティ・レベルを提供するための方法及びデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-02-21

(54)【発明の名称】通信のためのセキュリティ・レベルを提供するための方法及びデバイス

(51)【国際特許分類】

   G06F 21/60 20130101AFI20240214BHJP

   H04L 9/08 20060101ALI20240214BHJP

   H04L 9/32 20060101ALI20240214BHJP

【ＦＩ】

G06F21/60 360

H04L9/08 C

H04L9/08 E

H04L9/32 200B

H04L9/32 200F

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023548226

(86)(22)【出願日】2022-02-09

(85)【翻訳文提出日】2023-08-09

(86)【国際出願番号】 EP2022053096

(87)【国際公開番号】W WO2022171657

(87)【国際公開日】2022-08-18

(31)【優先権主張番号】21157226.8

(32)【優先日】2021-02-15

(33)【優先権主張国・地域又は機関】EP

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

２．ＶＥＲＩＬＯＧ

３．ＦＩＲＥＦＯＸ

(71)【出願人】

【識別番号】590000248

【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ

【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】110001690

【氏名又は名称】弁理士法人Ｍ＆Ｓパートナーズ

(72)【発明者】

【氏名】バーンセン ヨハネス アーノルダス コーネリス

(57)【要約】

セキュリティ・プロトコルによる物理チャネルを介した第１のデバイスと第２のデバイスとの間のセキュアな通信を確立するためのデバイス１１０，１２０及び方法が説明される。プロトコルは、第１のデバイスにおける第１の整合性データ、及び第２のデバイスにおける第２の整合性データを確立する。プロトコルは、少なくとも２つのセキュリティ・レベルを有する。適用されるセキュリティ・レベルは、物理チャネルを介して移送されたグレーディング情報に基づいて選択可能である。有利には、第１のデバイス１１０及び第２のデバイス１２０のうちの少なくとも１つにおいて最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標は、物理チャネルを介して移送され、その一方で、グレーディング指標の整合性保護は、整合性データに基づいて提供される。これにより、セキュリティ・レベルをダウングレードさせるためのさらなるデバイス（１３０）による中間者攻撃が阻止される。

【特許請求の範囲】

【請求項1】

セキュリティ・プロトコルによる物理チャネルを介した第１のデバイスと第２のデバイスとの間の通信のためのセキュリティ・レベルを確立するための方法であって、前記セキュリティ・プロトコルが、
前記第１のデバイスにおける第１の整合性データ、及び前記第２のデバイスにおける第２の整合性データを確立することと、
少なくとも２つのセキュリティ・レベルであって、前記セキュリティ・レベルが、前記物理チャネルを介して移送されたグレーディング情報に基づいて選択可能であり、第１のセキュリティ・レベルによる前記セキュリティ・プロトコルが、前記第１のデバイスのメッセージにおける繰り返されるデータに基づいて前記ネットワークにおける複数の通信セッションにわたる前記第１のデバイスのトラッキングを阻止しない、少なくとも２つのセキュリティ・レベルと
を提供し、
第２のセキュリティ・レベルによる前記セキュリティ・プロトコルが、トラッキングを阻止するために前記繰り返されるデータを回避又は修正することを要求し、
前記方法が、
前記第１のデバイス及び前記第２のデバイスのうちの少なくとも１つで最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標を、前記物理チャネルを介して移送するステップと、
前記整合性データに基づく前記グレーディング指標の整合性保護を提供するステップと、
前記グレーディング指標によって前記トラッキング阻止を指示されたとき、前記トラッキング阻止を適用するステップと
を有する、方法。

【請求項2】

デバイスであって、前記デバイスが、セキュリティ・プロトコルによる物理チャネルを介した第１のデバイスと第２のデバイスとの間の通信のためのセキュリティ・レベルを確立するように適合された前記第１のデバイスであり、前記セキュリティ・プロトコルが、
前記第１のデバイスにおける第１の整合性データ、及び前記第２のデバイスにおける第２の整合性データを確立することと、
少なくとも２つのセキュリティ・レベルであって、前記セキュリティ・レベルが、前記物理チャネルを介して移送されたグレーディング情報に基づいて選択可能であり、第１のセキュリティ・レベルによる前記セキュリティ・プロトコルが、前記第１のデバイスのメッセージにおける繰り返されるデータに基づいて前記ネットワークにおける複数の通信セッションにわたる前記第１のデバイスのトラッキングを阻止しない、少なくとも２つのセキュリティ・レベルと
を提供し、
第２のセキュリティ・レベルによる前記セキュリティ・プロトコルが、トラッキングを阻止するために前記繰り返されるデータを回避又は修正することを要求し、
前記デバイスが、
前記第１のデバイス及び前記第２のデバイスのうちの少なくとも１つで最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標を、前記物理チャネルを介して送ること又は受け取ることと、
送るとき、前記整合性データに基づく前記グレーディング指標の保護データを含めることと、
受け取るとき、前記整合性データに基づいて前記保護データを検証することと、
前記第１のデバイスと前記第２のデバイスとの間の前記通信のための少なくとも前記最低限のセキュリティ・レベルを適用することと、
前記グレーディング指標によって前記トラッキング阻止を指示されたとき、前記トラッキング阻止を適用することと
を行うプロセッサを備える、デバイス。

【請求項3】

前記セキュリティ・プロトコルが、ワイヤレス・ネットワークにおける前記第１のデバイスと前記第２のデバイスとの間の通信を確立するように適合されたコンフィギュレータをさらに要求するデバイス・プロビジョニング・プロトコルに基づき、
前記コンフィギュレータが、
コネクタ・メッセージ内に前記グレーディング指標を挿入することと、
前記コネクタ・メッセージを前記第１のデバイスに送ることと
を行い、
前記第１のデバイスのプロセッサが、
前記コネクタ・メッセージを受け取ることと、
前記コネクタ・メッセージから前記グレーディング指標を取り出すことと
を行う、請求項２に記載のデバイス。

【請求項4】

前記第１のセキュリティ・レベルによる前記セキュリティ・プロトコルが、秘密鍵及び公開鍵材料に基づいて前記第１のデバイス及び前記第２のデバイス両方におけるペアのマスタ鍵を決定することを要求し、前記ペアのマスタ鍵が、前記第１のデバイスと前記第２のデバイスとの間の暗号化通信のためのセッション鍵を決定するために使用され、
前記第２のセキュリティ・レベルによる前記セキュリティ・プロトコルが、一過性のＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵ペアを伴う前記ペアのマスタ鍵を決定することを要求し、
前記プロセッサが、前記グレーディング指標によって前記第２のセキュリティ・レベルを指示されたとき、前記第２のセキュリティ・レベルを適用する、請求項３に記載のデバイス。

【請求項5】

前記セキュリティ・プロトコルにおいて、前記グレーディング情報の少なくとも一部に整合性保護がない、請求項２から４のいずれか一項に記載のデバイス。

【請求項6】

前記セキュリティ・プロトコルが、
証明機関から証明書を取得すること、
前記証明書を使用してセキュリティ・パラメータを提供すること、
セットアップ・メッセージを介して前記セキュリティ・パラメータを前記デバイスに移送すること、
を備えるセットアップ・プロトコルを備え、
前記証明書が、前記グレーディング指標を含み、前記グレーディング指標が、前記セキュリティ・パラメータの制約を指示するものであり、
前記プロセッサが、
前記証明書から前記グレーディング指標を取り出すことと、
前記セットアップ・メッセージを受け取ることと、
前記セットアップ・メッセージ、及び前記セキュリティ・パラメータの前記制約に基づいて前記セキュリティ・レベルを決定することと
を行う、請求項２に記載のデバイス。

【請求項7】

前記セキュリティ・プロトコルが、暗号セキュリティ・パラメータのセットアップを提供し、前記暗号セキュリティ・パラメータが、
使用することになる暗号法アルゴリズム、
使用することになる鍵サイズ、
使用することになる暗号学的ハッシュ・アルゴリズム、
使用することになる前記セキュリティ・プロトコルの最低バージョン、
前記使用することになるセキュリティ・プロトコルのオプション
のうちの１つ又は複数を含む、請求項６に記載のデバイス。

【請求項8】

前記第１のデバイスが、クライアント・デバイスであり、前記第２のデバイスが、サーバ・デバイスであり、前記グレーディング指標が、証明書を使用したクライアント側認証が要求されるクライアント制約を指示するものであり、
前記プロセッサが、
前記証明書から前記クライアント制約を取り出すことと、
前記セットアップ・メッセージを受け取ることと、
前記クライアント制約に基づいてクライアント側認証を適用することと
を行う、請求項６又は７に記載のデバイス。

【請求項9】

前記セキュリティ・プロトコルが、［ＤＰＰ］で定義されたＷｉ－Ｆｉデバイスを構成するための前記デバイス・プロビジョニング・プロトコルに基づいていて、前記コネクタ・メッセージが、前記グレーディング指標を挿入することによって修正された前記デバイス・プロビジョニング・プロトコルで定義された前記コネクタに基づいていて、
前記プロセッサが、修正された前記コネクタを受け取る、請求項３に記載のデバイス。

【請求項10】

前記セキュリティ・プロトコルが、［ＤＰＰ］で定義されたＷｉ－Ｆｉデバイスを構成するための前記デバイス・プロビジョニング・プロトコルに基づいていて、前記コネクタ・メッセージが、前記デバイス・プロビジョニング・プロトコルで定義された再構成認証リクエスト・メッセージで使用するために生成された前記コネクタに基づく再構成コネクタであり、
前記コンフィギュレータが、前記グレーディング指標を前記再構成コネクタに挿入し、前記グレーディング指標が、再構成されることを望むデバイスによってデバイス・トラッキング阻止が使用されることが可能であるか使用されるべきであること指示する阻止制約を指示するものであり、
前記プロセッサが、
前記修正されたコネクタから前記阻止制約を取り出すこと、
前記阻止制約に基づいて再構成中のトラッキング阻止を適用すること
を行う、請求項２から４のいずれか一項に記載のデバイス。

【請求項11】

前記物理チャネルが、ワイヤレス通信チャネルである、請求項２から１０のいずれか一項に記載のデバイス。

【請求項12】

前記整合性データが、前記物理チャネルを介して移送されるメッセージの整合性保護を提供するために適用される、請求項２から１１のいずれか一項に記載のデバイス。

【請求項13】

デバイスで使用するための方法であって、前記方法が、セキュリティ・プロトコルによる物理チャネルを介した前記デバイスとさらなるデバイスとの間の通信のためのセキュリティ・レベルを確立し、前記セキュリティ・プロトコルが、
前記デバイスにおける第１の整合性データ、及び前記さらなるデバイスにおける第２の整合性データを確立することと、
少なくとも２つのセキュリティ・レベルであって、前記セキュリティ・レベルが、前記物理チャネルを介して移送されたグレーディング情報に基づいて選択可能であり、第１のセキュリティ・レベルによる前記セキュリティ・プロトコルが、第１のデバイスのメッセージにおける繰り返されるデータに基づいて前記ネットワークにおける複数の通信セッションにわたる前記第１のデバイスのトラッキングを阻止しない、少なくとも２つのセキュリティ・レベルと
を提供し、
第２のセキュリティ・レベルによる前記セキュリティ・プロトコルが、トラッキングを阻止するために前記繰り返されるデータを回避又は修正することを要求し、
前記方法が、
前記デバイス及びさらなるデバイスのうちの少なくとも１つにおいて最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標を、前記物理チャネルを介して送ること又は受け取るステップと、
送るとき、前記整合性データに基づく前記グレーディング指標の保護データを含めるステップと、
受け取るとき、前記整合性データに基づく前記保護データを検証するステップと、
前記デバイスと前記さらなるデバイスとの間の前記通信のための少なくとも前記最低限のセキュリティ・レベルを適用するステップと、
前記グレーディング指標によって前記トラッキング阻止を指示されたとき、前記トラッキング阻止を適用するステップと
を有する、方法。

【請求項14】

ネットワークからダウンロード可能な、並びに／又はコンピュータ可読媒体及び／若しくはマイクロプロセッサ実行可能媒体に格納された、プログラムであって、前記プログラムが、コンピュータで実行されると、請求項１又は１３のいずれか一項に記載の方法を実行するためのプログラム・コード命令を備える、プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、セキュリティ・プロトコルによる物理チャネルを介した第１のデバイスと第２のデバイスとの間の通信のためのセキュリティ・レベルを確立するための方法及びデバイスに関する。

【0002】

本発明は、ワイヤレス又は有線データ通信のセキュリティの分野に関し、より詳細には、セキュリティ・プロトコルを適用したデバイス及び方法を提供する。セキュリティ・プロトコルは、第１のデバイスにおける第１の整合性データ、及び第２のデバイスにおける第２の整合性データを確立する。整合性データは、物理チャネルを介して移送されるメッセージの整合性保護を提供する。セキュリティ・プロトコルは、様々なセキュリティ・レベルを提供し、セキュリティ・レベルは、例えば、少なくとも１つの固有のセキュリティ措置、暗号アルゴリズム、セキュリティ・オプション又は鍵長を定義する。

【背景技術】

【0003】

デバイスは、Ｗｉ－Ｆｉアクセス・ポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）へのアクセス権を得るために、例えば、デバイス・プロビジョニング・プロトコル（ＤＰＰ：Ｄｅｖｉｃｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ、［ＤＰＰ］参照）に従ってワイヤレス・ネットワークにセキュアに接続し、ＤＰＰは、ＤＰＰコンフィギュレータ・デバイスを使用してＷｉ－Ｆｉデバイスを構成するためのプロトコルである。アクセス権を得ようとするデバイスは、ＤＰＰエンローリと呼ばれる。デバイスがＤＰＰによって構成されているとき、デバイスは、ＤＰＰコンフィギュレータからＤＰＰ構成オブジェクトを受け取っている。ＤＰＰ構成オブジェクトは、いわゆるコネクタ又はＤＰＰコネクタを含む。コネクタは、ＤＰＰコンフィギュレータによって署名される。コネクタは、デバイスに属する公開鍵、ネットワーク・アクセス鍵、ｎｅｔＡｃｃｅｓｓＫｅｙすなわちＮＡＫを含む。ＮＡＫは、プレーンテキストでコネクタ内に存在する。例えば満了タイムスタンプといった、他の情報がプレーンテキストでコネクタ内に存在する。ＤＰＰ構成オブジェクトは署名されないので、ＤＰＰ構成オブジェクトには、整合性保護がない。それでも、ＤＰＰエンローリに送られるメッセージである、ＤＰＰ構成応答メッセージは、前のＤＰＰ認証プロトコルにおいてＤＰＰコンフィギュレータとＤＰＰエンローリとの間でネゴシエートされた対称鍵によって整合性保護される（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）。本出願では、ＤＰＰという頭字語は、例えば、ＤＰＰ Ｒ１、ＤＰＰ Ｒ２、及び任意の後継リリースといった、ＤＰＰの任意のバージョンを意味することが指摘される。

【0004】

接続デバイス数の増加を考えると、例えばサード・パーティによるトラッキングに対するプライバシ及び保護のための、セキュリティへの関心が大きくなっている。トラッキングは、例えばデバイスのメッセージ内の繰り返されるデータに基づいて、ネットワーク内の複数の通信セッションにわたってデバイスのロケーションを追うことを意味する。文書ＷＯ２０２００４３６３４Ａ１［２０１８ＰＦ００５０８］は、前記トラッキングからの保護を提供するセキュリティ・オプションが追加された、アップグレードされたセキュリティ・プロトコルを説明している。

【0005】

したがって、既存のセキュリティ・プロトコルは、少なくとも１つの強化されたセキュリティ・レベルでアップグレードされる。既存デバイスとの対話のために、このようなプロトコルの前のバージョンも通常、サポートされる。例えば、使用されることになるセキュリティ・プロトコルのバージョン又はオプションなど、適用されるセキュリティ・レベルは、通信のセットアップ中にデバイス間で、物理チャネルを介して移送されたグレーディング情報を使用してネゴシエートされる。グレーディング情報は、例えば、プロトコルの固有のバージョン又はセキュリティ・オプションがデバイスによってサポートされるという明示的な指示である。グレーディング情報はまた、例えば、複数の鍵長がサポートされる場合、固有の長さの鍵を含めることによって、他のプロトコル・データによって暗黙的である。前記グレーディング情報を交換することによって、適用されるセキュリティ・レベルが決定される。それでも、このようなメッセージは、物理チャネル上でも動作するデバイスによって傍受及び修正され、これは、「中間者」攻撃（ＭｉｔＭ：ｍａｎ－ｉｎ－ｔｈｅ－ｍｉｄｄｌｅ）と呼ばれる。グレーディング情報の前記操作により、セキュリティ・レベルは、意図されるより低く確立されることがあり、これは、セキュリティ・レベルの「ダウングレーディング」と呼ばれる。

【発明の概要】

【0006】

上述のセキュリティ問題のうちの少なくとも１つを軽減するために、例えば前記ＭｉｔＭを介した、セキュリティ・レベルのダウングレーディングから保護するための方法及びデバイスを提供することが本発明の目的である。このために、添付の特許請求の範囲で規定されたようなデバイス及び方法が提供される。本発明の１つの態様によれば、請求項１で定義されたような、セキュリティ・プロトコルによる物理チャネルを介した第１のデバイスと第２のデバイスとの間の通信のためのセキュリティ・レベルを確立するための方法が提供される。本発明のさらなる態様によれば、独立請求項で定義されたようなデバイス及び方法が提供される。

【0007】

セキュリティ・プロトコルは、第１のデバイスにおける第１の整合性データ、及び第２のデバイスにおける第２の整合性データを確立することを提供する。整合性データは、物理チャネルを介して移送されるメッセージの整合性保護を提供するために適用される。例えば、第１の整合性データは、第１のデバイスに格納された第２のデバイスの公開鍵であり、その一方で、第２の整合性データは、対応する秘密鍵を使用して第２のデバイスによってセットされた署名である。第１の整合性データはまた、サード・パーティによって第１のデバイスに供給されたコネクタの署名又は証明書である。

【0008】

セキュリティ・プロトコルは、少なくとも２つのセキュリティ・レベルを提供し、セキュリティ・レベルは、例えば、基本的なセキュリティ・レベル及び少なくとも１つのアップグレードされたセキュリティ・レベルといった、グレーディング情報に基づいて選択可能である。適用されることになる実際のセキュリティ・レベルは、物理チャネルを介してグレーディング情報に基づいて決定される。グレーディング情報は、物理チャネルを介して移送され、明示的若しくは暗黙的な１つ若しくは複数のプロトコル・メッセージの一部であるか、又は、交換される別個のメッセージの中で具体化される。明示的又は暗黙的なグレーディング情報を含む任意のメッセージが、本書類ではグレーディング・メッセージと呼ばれる。グレーディング・メッセージは、物理チャネルを介して移送される。したがって、グレーディング情報は、デバイスが提供可能な、及び通信、プライバシ保護、整合性保護、認証、ネットワーク・アクセス等のためにデバイス間で使用されることになるグレードをネゴシエートするための、セキュリティの１つ又は複数のグレードを確立するのに適切な任意のデータを意味する。例えば、グレーディング情報は、デバイスによってサポートされるセキュリティ・プロトコルのバージョン指標を含む。固有のバージョン番号が、このバージョンのプロトコル仕様によって指定されるような、他のデバイスが選択するセキュリティ・オプションの範囲を指示する。

【0009】

方法及びデバイスは、第１のデバイス及び第２のデバイスのうちの少なくとも１つで最低限要求される最低限のセキュリティ・レベルを指示するグレーディング指標を、物理チャネルを介して移送するように構成される。さらに、デバイス及び方法は、整合性データに基づくグレーディング指標の整合性保護を提供する。グレーディング指標は、物理チャネルを介して、若しくは異なるチャネルを介して、又はグレーディング・メッセージの一部として、別々に移送される。

【0010】

グレーディング情報は、完全に又は部分的に整合性保護されるか、全く整合性保護されない。対照的に、グレーディング指標は、常に完全に整合性保護される。したがって、グレーディング指標は、グレーディング・メッセージの整合性保護されない部分に対するＭｉｔＭ攻撃が、特定のレベルを下回るネゴシエートされたセキュリティの原因になるのを阻止するか、又は新しい証明書をリクエストすることなくサーバ若しくはクライアントのセットアップを変更する場合に特定の最低限のセキュリティを維持するのに役立つ。

【0011】

事実上、デバイスがグレーディング指標を送り、デバイス自体又は受け手は、その後、グレーディング指標によって指示されるような最低限のセキュリティ・レベルを適用する。また、２つのデバイスが協働するとき、２つのデバイスは、少なくとも、グレーディング指標によって指示されるようなセキュリティのレベルを適用する。その上、グレーディング指標によって要求されるものよりグレードが高い、高いセキュリティ・グレードが双方でサポートされることを示すグレーディング・メッセージを２つのデバイスが交換するとき、このようなより高いセキュリティ・レベルもまた、選択される。それでも、グレーディング指標で指示されたものより低いセキュリティ・レベルへのダウングレーディングはブロックされる。したがって、グレーディング・メッセージが、通信リンクの両側でサポートされるセキュリティのより低いグレードでの旧式の通信を可能にする場合、通信リンクが、グレーディング指標で指示されたセキュリティ・レベルより低いセキュリティ・レベルを適用するとき、このようなリンクはここで阻止されることが可能である。同様に、グレーディング指標を含むメッセージを受け取ったとき、及びその整合性を検証する際、デバイスは、グレーディング指標で指示されたセキュリティ・レベルより低いセキュリティ・レベルを有する任意の通信をブロック又はアボートさせることができる。

【0012】

有利には、前記グレーディング情報は、提案とみなされることが可能な少なくとも１つのセキュリティ・レベルを指示し、その一方で、グレーディング指標は、実際に使用されるセキュリティ・レベルの制約を指示する。したがって、共通言語では、「グレーディング・メッセージで何が言及されていたとしても、少なくともレベルＸを使用しなければならない」、又は「グレーディング・メッセージで何が言及されていたとしても、レベルＸをサポートする場合、少なくともレベルＸを使用しなければならないが、その他の場合、少なくともレベルＹが使用されなければならない（レベルＹは、レベルＸよりセキュアではない）。

【0013】

整合性保護を提供することは、送る側のアクション及び受け取る側のアクション両方をカバーする。例えば、整合性データに基づくグレーディング指標の整合性保護を提供することは、デバイスによってグレーディング指標メッセージに署名すること、及びメッセージを受け取ったとき、署名をチェックすることを伴う。また、整合性保護を提供することは、第１のデバイスによって、グレーディング指標を含むオブジェクトを送る行為であり、オブジェクト（したがって、例えばコネクタ）は、さらに第３のデバイスによって署名される。レシーバ側は、次いで、第３のデバイスに関するそれぞれの鍵材料を使用して署名を検証する。例えば、これは、後で説明されるようなネットワーク導入プロトコル中のＰＦＳ及びトラッキング阻止の使用のネゴシエート中に発生する。

【0014】

本発明のさらなる態様によれば、セキュリティ・プロトコルは、例えばＤＰＰといった、ワイヤレス・ネットワークにおける第１のデバイスと第２のデバイスとの間の通信を確立するように適合されたコンフィギュレータをさらに要求するデバイス・プロビジョニング・プロトコルに基づく。コンフィギュレータは、コネクタ・メッセージ内にグレーディング指標を挿入することと、コネクタ・メッセージを第１のデバイスに送ることとを行うように配置される。第１のデバイスのプロセッサは、コネクタ・メッセージを受け取ることと、コネクタ・メッセージからグレーディング指標を取り出すこととを行うように構成される。

【0015】

本発明によるデバイス及び方法のさらに好ましい実施形態が、添付の従属請求項に示され、その開示が、参照により本明細書に組み込まれる。

【0016】

本発明のこれら及び他の態様は、以下の説明で例として説明される実施形態をさらに参照すれば、及び添付の図面を参照すれば、明らかであり、明瞭になるであろう。

【図面の簡単な説明】

【0017】

【図1】本発明が実践されるシステムの図である。

【図2a】コンピュータ可読媒体の図である。

【図2b】プロセッサ・システムの概略図である。

【発明を実施するための形態】

【0018】

図は、純粋に図式であり、拡大縮小するように描かれていない。図において、既に説明された要素に対応する要素は、同じ参照番号を有する。

【0019】

図１は、第１のデバイス１１０、第２のデバイス１２０、及び第３のデバイス１３０を備えるシステム１００を示している。これらのデバイスのそれぞれは、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、又は有線ネットワークなど、物理チャネル１６０を介した通信に適切なトランスミッタ／レシーバを備える通信モジュール１１１、１２１、１３１を有する。デバイスは、有線物理チャネルを介して通信するための入出力ユニットを有し、及び／又は、ワイヤレス物理チャネルのための入出力として機能する少なくとも１つのアンテナ１１３、１２３、１３３を備える。デバイスのそれぞれは、プロセッサ１１２、１２２、１３２の制御下で動作する。通信モジュール、プロセッサ、及びデバイスのさらなる要素は、チップ上の単一のシステムに統合される。デバイスのそれぞれは、少なくとも１つのユーザ制御要素を有するユーザ・インターフェース１５１、１５２、１５３を有する。例えば、ユーザ制御要素は、タッチ・スクリーン、様々なボタン、マウス又はタッチ・パッド等を備える。ボタンは、伝統的な物理ボタン、タッチ・センサ、若しくは、例えばタッチ・スクリーン上の仮想ボタン、又は、マウスを介してアクティブにされることになるアイコンである。ユーザ・インターフェースはまた、リモート・ユーザ・インターフェースである。

【0020】

実際には、第１のデバイスは、エンド・ユーザを有するモバイル・フォン、ラップトップ、又はタブレットなどのポータブル・デバイスに対応し得る。第１のデバイスは、ＩｏＴ（モノのインターネット）タイプのデバイスでもよい。第２のデバイスは、サーバ、アクセス・ポイント、ルータ、さらなるポータブル・デバイス、又はＩｏＴデバイス等に対応し得る。第１のデバイスのユーザは、第２のデバイスを介して提供された１つ又は複数のリソースにアクセスするために、第２のデバイス（アクセス・ポイント）に接続されることに関心がある。第３のデバイスは、実際には、本発明の一部ではないが、いわゆる中間者、すなわち、第１のデバイスとの間のメッセージを傍受する、修正する、又は入れ替えるために悪意のあるサード・パーティによって使用されるデバイスに対応する。

【0021】

本出願では、「証明書」という単語は、少なくとも、証明書の所有者の公開鍵を含むデータの小さな塊を表すことが意図される。本出願で意図されるような証明書の例は、Ｘ５０９ ｖ３［ＲＦＣ５２８０］証明書である。所有者は、「サブジェクト」と呼ばれ、公開鍵は、「サブジェクト公開鍵」と呼ばれる。前記小さな塊は、「発行者」と呼ばれる証明機関（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）によってデジタル署名される。いわゆるルート証明書を除いて、証明書は、証明書の公開鍵（「サブジェクト公開鍵」）の所有者（「サブジェクト」）とは別のエンティティ（「発行者」）によって署名される。ルート証明書は、所有者自身によって署名され、すなわち、要素「発行者名」及び「サブジェクト名」は同じである。

【0022】

証明書の署名を検証するために使用することになる公開鍵は、別の証明書の「サブジェクト公開鍵」として見つけられることが可能であり、その「サブジェクト名」は、検証されることになる証明書の「発行者名」と同じである。この他の証明書がルート証明書である場合、ルート証明書の「サブジェクト公開鍵」は、ルート証明書の署名を検証するために使用可能である。この他の証明書がルート証明書でなく、したがってさらに別の発行者である発行者２によって発行された場合、ルート証明書の署名は、ルート証明書の「サブジェクト名」要素にリスト化された発行者２を有するさらに別の証明書の「サブジェクト公開鍵」と照合されることが可能である。証明書の署名照合は、したがって、いわゆる証明書ツリーのルート証明書まで（ルート証明書を含む）、この証明書ツリーにおけるいくつかの証明書の署名の照合を伴う。

【0023】

ＤＰＰコネクタも、証明書のように、ＤＰＰコネクタ（すなわちＤＰＰコンフィギュレータによって構成されたデバイス）の所有者の公開鍵を少なくとも含む、データの小さな塊である。この小さな塊は、ＣＡによってではなく、ＤＰＰコンフィギュレータによってデジタル署名される。後者の２つの間の１つ違いは、ＣＡが公的に知られており、ＣＡの発行者名又はＣＡのルート証明書など、ＣＡのいくつかのプロパティが公知であり、インターネット上で見つけられることが可能であるが、ＤＰＰコンフィギュレータが公的に知られていないことである。例えば、ＤｉｇｉｃｅｒｔがＣＡを提供する（ｗｗｗ．ｄｉｇｉｃｅｒｔ．ｃｏｍ）。ルート証明書のリストは、ｈｔｔｐｓ：／／ｗｗｗ．ｄｉｇｉｃｅｒｔ．ｃｏｍ／ｋｂ／ｄｉｇｉｃｅｒｔ－ｒｏｏｔ－ｃｅｒｔｉｆｉｃａｔｅｓ．ｈｔｍで提供され、「ＤｉｇｉＣｅｒｔ Ａｓｓｕｒｅｄ ＩＤ Ｒｏｏｔ ＣＡ」が、ｈｔｔｐｓ：／／ｃａｃｅｒｔｓ．ｄｉｇｉｃｅｒｔ．ｃｏｍ／ＤｉｇｉＣｅｒｔＡｓｓｕｒｅｄＩＤＲｏｏｔＣＡ．ｃｒｔで利用可能である。例えば、ウェブサイトｈｔｔｐｓ：／／ｌａｐｏ．ｉｔ／ａｓｎ１ｊｓ／といった適切なツールを使用してこのルート証明書を検査するとき、例えば、「発行者名」及び「サブジェクト名」が、「ｃｏｕｎｔｒｙＮａｍｅ ＵＳ；ｏｒｇａｎｉｚａｔｉｏｎＮａｍｅ ＤｉｇｉＣｅｒｔ Ｉｎｃ；ｏｒｇａｎｉｚａｔｉｏｎａｌＵｎｉｔＮａｍｅ ｗｗｗ．ｄｉｇｉｃｅｒｔ．ｃｏｍ；ｃｏｍｍｏｎＮａｍｅ ＤｉｇｉＣｅｒｔ Ａｓｓｕｒｅｄ ＩＤ Ｒｏｏｔ ＣＡ」であることが分かる。

【0024】

証明書とコネクタとの間のもう一つの違いは、署名を検証するためにデバイスが公開鍵でどのように構成されるかということである。証明書署名検証の場合、これを行うための公開鍵は、証明書ツリーのルート証明書まで（ルート証明書を含む）の、証明書ツリーのすべての証明書と一緒に、証明書自体の形式で提供される。証明書ツリーは、特殊でセキュアなメカニズムでデバイスにインストールされる。これは、例えば製造時に行われる。また、これは、例えば、セキュアなインターネット接続を使用することによって行われる。例えば、Ｍｉｃｒｏｓｏｆｔは、Ｗｉｎｄｏｗｓデバイスとそのサーバとの間の専用のセキュアな接続を使用して、Ｗｉｎｄｏｗｓデバイスに最新の証明書ツリーを提供する。Ｆｉｒｅｆｏｘというウェブ・ブラウザは、Ｗｉｎｄｏｗｓオペレーティング・システムの下で動いているときでも、Ｆｉｒｅｆｏｘインスタレーションに最新の証明書ツリーを提供するために、Ｆｉｒｅｆｏｘインスタレーションと、Ｍｏｚｉｌｌａからのサーバとの間の独自の専用のセキュアなチャネルを使用する。必要なセキュリティは、証明書を秘密に保つためのものではなく、有効な証明書ツリーだけが提供されることを保証するためのものである。例えばハッカーによって、悪意のあるルート証明書を提供されたデバイスは、このルート証明書（で署名された証明書）の公開鍵で署名された証明書を提供するウェブサイトを信頼し始めることになる。対照的に、ＤＰＰコンフィギュレータ公開鍵は、証明書の形式のエンローリで提供されるのではなく、対称鍵によって（整合性）保護されたメッセージで提供される。以下では、ＤＰＰにおけるグレーディング情報の様々な例が論じられる。

【0025】

ＤＰＰ再構成認証プロトコルでは、第１のメッセージは、ＤＰＰ再構成アナウンスメント・メッセージである。第１のメッセージは、整合性保護されない。

【0026】

エンローリ－＞コンフィギュレータ：ＳＨＡ２５６（Ｃ－ｓｉｇｎ－ｋｅｙ）、グループ、Ａ－ＮＯＮＣＥ、Ｅ’－ｉｄ
属性「ＳＨＡ２５６（Ｃ－ｓｉｇｎ－ｋｅｙ）」は、コンフィギュレータ署名鍵を指示する。コンフィギュレータは、複数の署名鍵を有する。これらは、同じ楕円曲線グループ（例えば、ＮＩＳＴ Ｐ－２５６）に属するか、異なる楕円曲線グループ（例えば、ＮＩＳＴ Ｐ－２５６及びＮＩＳＴ Ｐ－３８４）に属する。したがって、この属性は、コンフィギュレータ署名アルゴリズム及び署名アルゴリズム・セキュリティ・レベルを指示し、したがって、グレーディング情報として機能する。属性「グループ」は、エンローリのＮＡＫの楕円曲線グループを指示する。したがって、この属性は、ＰＭＫを計算するために使用するためのアルゴリズムを指示し、この属性は、ＰＭＫのセキュリティ・レベル（ここでより詳細には、ビット数）を指示し、したがって、グレーディング情報にも寄与する。

【0027】

属性「Ａ－ＮＯＮＣＥ」及び「Ｅ’－ｉｄ」は、コンフィギュレータ署名鍵と同じ楕円曲線上の楕円点であり、したがって、セキュリティ・レベルについてより多くの情報を追加しない。

【0028】

エンローリが、例えば必須のＮＩＳＴ Ｐ－２５６曲線といった、１つの曲線しかサポートしない場合、デバイスは、これを第１のレベルとしてサポートするだけである。第２のセキュリティ・レベルは、したがって、Ｐ－２５６とトラッキング阻止であり、これらは、パラメータ又はバージョン指示で指示される。したがって、トラッキング阻止という機能は、この時点でコンフィギュレータに知られているが、そのようなものとして要求されない。

【0029】

ＤＰＰ再構成認証プロトコルにおける第２のメッセージは、ＤＰＰ再構成認証リクエスト・メッセージである。第２のメッセージは、属性「Ｃ－Ｃｏｎｎｅｃｔｏｒ」を除いて、整合性保護されない。

【0030】

コンフィギュレータ－＞エンローリ：ＴｒａｎｓＩｄ、プロトコル・バージョン、Ｃ－Ｃｏｎｎｅｃｔｏｒ、Ｃ－ｎｏｎｃｅ
属性「ＴｒａｎｓＩｄ」は、次の２つのプロトコル・メッセージ内でコピーされることになる乱数である。属性「プロトコル・バージョン」は、コンフィギュレータがサポートするＤＰＰプロトコル・バージョンを表す。異なるバージョンが他のセキュリティ・レベルを提供又は規定する場合、この属性は、セキュリティ・レベルを指示する。この属性は、整合性保護されない。ＤＰＰ Ｒ３仕様がトラッキング阻止の使用をサポートするとき、この属性は、「アップグレードされたセキュリティ・レベル」を選択するために使用可能であり、すなわち、再構成中にトラッキング阻止を使用する。代替として、ＤＰＰ Ｒ３では、属性「プロトコル・バージョン」の値３（ＤＰＰリリース３を表す）は、次のメッセージ内のエンローリ・コネクタのＮＡＫのためのトラッキング阻止をエンローリが使用可能であることをコンフィギュレータがサポートすることを指定する。属性「プロトコル・バージョン」は、グレーディング情報として機能し、したがって、このメッセージがグレーディング・メッセージであるとみなされ、この場合、コンフィギュレータは、トラッキング阻止を使用するかしないかという２つのオプションを、エンローリが有することを指示する。属性「Ｃ－Ｃｏｎｎｅｃｔｏｒ」は、コンフィギュレータ署名鍵についての指示、すなわち、コネクタのＪＳＯＮ Ｗｅｂ Ｓｉｇｎａｔｕｒｅ（ＪＷＳ）保護ヘッダ内の「ｋｉｄ」という識別子を含む（［ＷＦＥＣ＿２］のセクション４．２参照）。コンフィギュレータは、複数の署名鍵を有する。複数の署名鍵は、同じ楕円曲線グループ（例えば、ＮＩＳＴ Ｐ－２５６）に属するか、異なる楕円曲線グループ（例えば、ＮＩＳＴ Ｐ－２５６及びＮＩＳＴ Ｐ－３８４）に属する。コンフィギュレータ署名鍵は、「グループ」という属性を有するエンローリによって指示されたものであるべきである。したがって、この属性は、コンフィギュレータ署名アルゴリズム及び署名アルゴリズム・セキュリティ・レベルを指示する。この属性は、ＮＡＫも含む。この属性は、エンローリのＮＡＫと同じ曲線上にあるべきである。したがって、この属性は、ＰＭＫを計算するために使用するためのアルゴリズムも指示し、この属性は、ＰＭＫのセキュリティ・レベル（例えば、具体的には、ビット数）を指示する。

【0031】

属性「Ｃ－Ｃｏｎｎｅｃｔｏｒ」は、エンローリが、エンローリのＮＡＫのためにトラッキング阻止を使用できるか使用しなければならないことを指示するためのグレーディング指標を含む。コンフィギュレータと通信するときに、エンローリのＮＡＫのためにトラッキング阻止をエンローリが使用しなければならないことを指示するグレーディング指標も、このメッセージ内のコネクタのうちの１つの内部の、又はこのメッセージの別の部分における、ＤＰＰ構成応答メッセージの一部としてコンフィギュレータによって送られる。

【0032】

さらなる例は、ネットワーク導入プロトコルに関する。以下のメッセージは、ＤＰＰピア発見リクエスト・メッセージである。

【0033】

デバイスＢ→デバイスＡ：ＴｒａｎｓＩＤ、ＣｏｎｎｅｃｔｏｒＢ、［プロトコル・バージョン］
デバイスＢは、非ＡＰ Ｗｉ－Ｆｉデバイスであり、デバイスＡは、Ｗｉ－Ｆｉ ＡＰデバイスである。

【0034】

属性「ＴｒａｎｓＩＤ」は、次のプロトコル・メッセージ内でコピーされることになる乱数である。属性「ＣｏｎｎｅｃｔｏｒＢ」は、情報がグレーディング情報であるとみなされる、コンフィギュレータ署名鍵及び非ＡＰデバイスのＮＡＫの指標を含む。非ＡＰデバイスが、例えばＰ－２５６といった、１つの曲線しかサポートしない場合、ただ１つのセキュリティ・レベルが、この情報と共に選択されることが可能である。属性「ＣｏｎｎｅｃｔｏｒＢ」は、ＡＰがこのコネクタのＮＡＫのためにトラッキング阻止を使用できるか使用しなければならないこと、又はＰＦＳを使用しなければならないことを指示するためのグレーディング指標を含む。オプションの属性「プロトコル・バージョン」は、非ＡＰデバイスがサポートするＤＰＰプロトコルのバージョンを指示する。ＰＦＳは、ＤＰＰ Ｒ２において定義されたものである。ＤＰＰ Ｒ２がこの属性の中で指示されたとき、ＡＰは、ＰＦＳを使用するか使用しないかを決める。したがって、この属性は、グレーディング情報にも寄与する。

【0035】

エンローリがこのコネクタのＮＡＫのためにトラッキング阻止を使用することを望む場合、エンローリは、例えば、ＡＰのビーコン又はプローブ応答内にＡＰが含むこれを表すさらなる情報要素から、別の方式でＡＰがこの機能をサポートするという情報を取得しなければならないことに留意されたい。このような要素は、グレーディング情報であるとみなされることが可能である。

【0036】

さらなる例では、ＤＰＰピア発見応答メッセージは、以下の通りである。

【0037】

デバイスＡ→デバイスＢ：トランザクションＩＤ、ＤＰＰステータス、ＣｏｎｎｅｃｔｏｒＡ、［プロトコル・バージョン］
属性「ＤＰＰステータス」は、この場合、値ＤＰＰ＿ＳＴＡＴＵＳ＿ＯＫを含む。この属性が別の値を有するとき、属性「ＣｏｎｎｅｃｔｏｒＡ」及び「プロトコル・バージョン」は省略される。他の属性の機能は、ＤＰＰピア発見リクエスト・メッセージのための上記で説明された機能と同じであるが、デバイスは取り替えられる。

【0038】

以下では、本発明の固有の実施形態が、上記の汎用システムに関連して説明される。

【0039】

第１の例示的な実施形態では、デバイスは、前述のように、セキュリティ・プロトコルによる物理チャネルを介した第１のデバイスと第２のデバイスとの間の通信のためのセキュリティ・レベルを確立するように適合された第１のデバイスとして機能する。デバイスは、第１のデバイス及び第２のデバイスのうちの少なくとも１つで最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標を、物理チャネルを介して送ること又は受け取ることを行うように配置されたプロセッサを有する。送るとき、プロセッサは、整合性データに基づくグレーディング指標の保護データを含める。受け取るとき、プロセッサは、整合性データに基づく保護データを検証する。その後、プロセッサは、第１のデバイスと第２のデバイスとの間の通信のための少なくとも最低限のセキュリティ・レベルを適用する。

【0040】

オプションとして、セキュリティ・プロトコルは、ワイヤレス・ネットワークにおける第１のデバイスと第２のデバイスとの間の通信を確立するように適合されたコンフィギュレータをさらに要求するデバイス・プロビジョニング・プロトコルに基づく。コンフィギュレータは、コネクタ・メッセージ内にグレーディング指標を挿入することと、コネクタ・メッセージを第１のデバイスに送ることとを行うように構成される。第１のデバイスのプロセッサは、コネクタ・メッセージを受け取ることと、コネクタ・メッセージからグレーディング指標を取り出すこととを行うように構成される。

【0041】

オプションとして、第１のセキュリティ・レベルによるセキュリティ・プロトコルは、秘密鍵及び公開鍵材料に基づいて第１のデバイス及び第２のデバイス両方におけるペアのマスタ鍵を決定することを要求し、ペアのマスタ鍵は、第１のデバイスと第２のデバイスとの間の暗号化通信のためのセッション鍵を決定するために使用される。さらに、第２のセキュリティ・レベルによるセキュリティ・プロトコルは、一過性のＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵ペアを伴うペアのマスタ鍵を決定することを要求し、デバイスのプロセッサは、グレーディング指標によってそのように指示されたとき、第２のセキュリティ・レベルを適用するように構成される。「一過性のＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵ペアを伴う」例として、ＰＦＳが下記で説明され、ＰＦＳは、アップグレードされたセキュリティ・レベルの例を提供する。

【0042】

通常、上記の実施形態では、セキュリティ・プロトコルにおいて、少なくとも１つのグレーディング・メッセージには整合性保護がない。したがって、このようなメッセージは、ＭｉｔＭ攻撃を受けやすい。オプションとして、このようなメッセージにおける様々なパラメータは、強化されたセキュリティ・プロトコルにおけるいくつかの時点で前記グレーディング指標を移送することによって保護される。グレーディング指標は、整合性保護のない前記グレーディング・メッセージを操作することによって影響を受ける様々な要素に対する制約、限界、又は要件を提供する。

【0043】

様々な実施形態では、通信チャネルはＷｉ－Ｆｉである。第２のデバイスは、アクセス・ポイント（ＡＰ）に対応し、第１のデバイスは、例えばＳＡＥプロトコルを介して、ＡＰに接続しようとする（［ＷＰＡ３］又は［８０２．１１］の節１２．４参照）。デバイスのそれぞれにおいて、本発明によるプロトコルは、モジュール・コントローラ（１１３，１２３）、プロセッサ（１１４、１２４）において、又は、プロトコルの実行時に両方が協働することによって、実行されている。実施形態は、パーフェクト・フォワード・セキュリティ（ＰＦＳ：Ｐｅｒｆｅｃｔ Ｆｏｒｗａｒｄ Ｓｅｃｕｒｉｔｙ）特徴をネゴシエートすることに関し、ＰＦＳは、ＤＰＰのバージョン２に追加されたものである（［ＷＦＥＣ＿２］のセクション６．６．３「ネットワーク・アクセス・プロトコル」参照）。したがって、グレーディング・メッセージは、デバイスによってサポートされるセキュリティ・プロトコルのバージョン指標を含む。例えば、バージョン指示は、デバイスがＶ３デバイスである場合、例えば「Ｖ３」といった、特定のセキュリティ・レベルをデバイスがサポートすることを指示する保護されていない「グレーディング情報」を具体化する一方で、Ｖ３は、ＰＦＳのようなセキュリティ・オプションが使用されることを示唆する。

【0044】

デバイスがＤＰＰを使用してＡＰに接続することを望むとき、デバイスは、いわゆるＤＰＰピア発見リクエスト・フレームにおいて、デバイスのコネクタをＡＰに送る。このフレームは暗号化されない。このフレームはまた、整合性保護されず、これは、このフレームが中間者（ＭｉｔＭ）攻撃者によって変更され得ることを意味する。ＤＰＰコンフィギュレータ・デバイスからの署名によってコネクタが整合性保護されるが、ＤＰＰピア発見リクエスト・フレームにおけるすべての他の属性には整合性保護がないので、受け手がこの変更に気づかずに、ＭｉｔＭによってコネクタが変更されることは不可能であることに留意されたい。

【0045】

ＤＰＰピア発見リクエスト・フレームを受け取るＡＰは、このフレームにおけるコネクタをチェックすることになる。コネクタが合法的であること、すなわち署名が正しく、コネクタが期限切れになっておらず、コネクタが、ＡＰが提供するネットワークについてのものであることをＡＰが知ると、ＡＰは、ＤＰＰピア発見応答フレームでリプライすることができる。このフレームは、ＡＰのコネクタを含み、ＡＰのコネクタは、デバイス・コネクタに署名した同じコンフィギュレータによって署名されなければならない。ＤＰＰピア発見応答フレームを受け取るデバイスは、ＡＰが行ったのと同じ方式でＡＰコネクタをチェックすることになる。ＡＰコネクタが正しく、独自のコネクタにマッチすることをデバイスが知ると（［ＤＰＰ］のセクション６．４．２「コネクタ・グループ比較」参照）、デバイスは、独自の秘密ＮＡＫと、ＡＰコネクタからの公開ＮＡＫとを使用して、Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ様式で（［ＤＨ］参照）、ペアのマスタ鍵（ＰＭＫ）を計算することができる（［ＤＰＰ］のセクション６．４「ネットワーク導入プロトコル」参照）。ＡＰは、独自の秘密ＮＡＫと、デバイス・コネクタにおける公開ＮＡＫとを使用して、ＰＭＫのための同じ値を計算することができる。ＰＭＫは、いわゆる４ウェイ・ハンドシェイクを使用して、デバイスとＡＰとの間のセッション鍵を計算するための基礎である（［８０２．１１］参照）。４ウェイ・ハンドシェイクが成功した後、デバイスはＡＰに関連付けられ、デバイスとＡＰとの間の伝送は、ＰＭＫから、及び４ウェイ・ハンドシェイク中に送られたプレーンテキスト情報から導出されたセッション鍵で暗号化され、整合性保護される。

【0046】

Ｗｉ－Ｆｉ Ｅａｓｙ Ｃｏｎｎｅｃｔ（ＴＭ）［ＷＦＥＣ＿２］と現在呼ばれているＤＰＰのバージョン２では、ＤＰＰ導入プロトコルは改善されたものである。リリース１に関する問題は、Ｗｉ－ＦｉデバイスとＡＰとの間のＰＭＫが常に同じであることである。デバイスとＡＰとの間のすべてのＷｉ－Ｆｉトラフィック、したがって、ＤＰＰネットワーク導入プロトコル交換、セッション鍵を計算するための４ウェイ・ハンドシェイク、及び関連付け後の暗号化された交換を、攻撃者がキャプチャしたとする。ハッカーは、コネクタがプレーンテキストで送られた、他のデバイスの接続者の他のデバイスから公開ＮＡＫを取得したことがあるので、攻撃者がデバイス又はＡＰをハッキングして秘密ＮＡＫのうちの１つを取得したとき、攻撃者は、デバイスとＡＰとの間のＰＭＫを計算することができる。キャプチャされた４ウェイ・ハンドシェイクにおけるＰＭＫ及びノンスを使用して、攻撃者はセッション鍵を計算し、２つのデバイス間のすべての暗号化された伝送を復号することができる。

【0047】

この攻撃から保護するために、ＤＰＰのバージョン２において、ＰＦＳ特徴が追加された。ＰＭＫの計算は現在、一過性のＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵ペア（公開／秘密ＥＣＣ鍵）も伴う。一過性のＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵ペアの秘密鍵は使用後、デバイスによって削除されなければならないので、２つのデバイスのいずれかをハッキングする攻撃者は、これらの一過性の秘密鍵を取得できることはなく、したがって、使用されるＰＭＫを計算できず、デバイスとＡＰとの間で過去に発生した暗号化された伝送を復号できない。

【0048】

［ＷＦＥＣ＿２］で指定されているようなＰＦＳに関する問題は、ＰＦＳの使用が、セキュアでない様式でネゴシエートされることである。デバイスがＰＦＳを使用することを望むとき、デバイスは、２以上の値を有するＤＰＰピア発見リクエスト・フレームにプロトコル・バージョン属性を追加する。２以上の値を有するプロトコル・バージョン属性を有するＤＰＰピア発見リクエスト・フレームをＡＰが受け取るとき、及びＡＰがＰＦＳをサポートする場合、ＡＰは、２以上の値を有するプロトコル・バージョン属性を有するＤＰＰピア発見応答フレームで応答することになる。この場合、［ＷＦＥＣ＿２］のセクション６．６．３「ネットワーク・アクセス・プロトコル」で指定されるように、両方のデバイスがＰＦＳを使用してＰＭＫを計算することになる。ＤＰＰピア発見リクエスト又は応答フレームにおけるコネクタ以外の属性は整合性保護されないので、ＭｉｔＭ攻撃者は、プロトコル・バージョン属性が、２未満の値を得るように、又はプロトコル・バージョン属性が、完全に除去されるように、２つのピア発見フレームのうちのどちらかを変更することができる。これが、ピア発見フレームのどちらか一方又は両方におけるケースの場合、デバイス及びＡＰがＰＦＳを使用することはない。このような攻撃は、阻止されるべきダウングレード攻撃の例である。

【0049】

１つの可能な明らかに簡単なオプションは、ＰＦＳが使用されず、ＰＦＳが柔軟でない場合、ＰＭＫを計算することがないように、デバイス又はＡＰがセットアップされることである。例えば、例えばパブリック・ネットワークといった、このＡＰを通じて取得可能な情報が、高度でないセキュリティを要求する場合、デバイスがＰＦＳを使用することなくＡＰに接続することが、完全にＯＫである。それでも、プライベート又は会社ネットワークへのアクセスを提供するＡＰのためにデバイスがＰＦＳを常に使用しなければならないことがある。

【0050】

この明らかに簡単なオプションに関する別の問題は、デバイス又はＡＰをセットアップするために、ユーザが現在、２つの別個の行為を行わなければならないことである。第１の行為は、ユーザがＤＰＰコンフィギュレータを使用して、デバイス又はＡＰを構成しなければならないことであり、第２の行為は、ユーザがデバイス又はＡＰセットアップ手順を踏んで、ＰＦＳを常に使用するようにデバイス又はＡＰを構成しなければならないことである。

【0051】

ＰＦＳのセットアップを、上述の明らかに簡単な解決策のものよりユーザにとって簡単なものにし、ＰＦＳの使用を、上記の簡単なオプションにおけるものより柔軟にする解決策が、ここで説明される。

【0052】

コンフィギュレータは、ネットワークを構成するＤＰＰにおける中央デバイスである。また、コンフィギュレータはここで、ＰＦＳがネットワークのために使用されなければならないか否かをセキュアな様式で制御するために使用され、したがって、ＰＦＳの使用に対するダウングレード攻撃を阻止し、ユーザがＰＦＳの使用をセットアップするのを簡単にし、これは、両方のデバイスが使用しなければならない技法である。ＰＦＳが特定のネットワークのために使用されなければならない場合、コンフィギュレータは、このネットワークのために、したがってデバイス及びＡＰ両方のために、コンフィギュレータが生成するあらゆるコネクタにおいて、グレーディング指標、すなわちＰＦＳが使用されなければならないことを指示する情報を、挿入する。この情報は、例えば、例えば｛…，”ｍｉｎＶｅｒｓｉｏｎ：３”，…｝といった、最低限使用されることになる最低バージョン番号の形式であること、又は、例えば｛…，”ｕｓｅＰＦＳ”：ｔｒｕｅ，…｝といった、より詳細な指示の形式であることが可能である。ＰＦＳを使用するための情報をコネクタが含むピア発見フレームにおいてコネクタを使用するデバイスは、ＰＦＳが使用されなければならないことを指定しないコネクタをこれらのデバイスが受け取った、１つのデバイスに接続することを拒絶することになる。

【0053】

したがって、ＭｉｔＭがピア発見フレームのバージョン情報を変更したとしても、コネクタが署名で整合性保護されており、コネクタが変更されていると照合が失敗するので、ＭｉｔＭは、ＰＦＳを使用することをデバイスに命令するコネクタにおける情報を変更することができない。

【0054】

ＰＦＳの使用を要求しないネットワークのために、コンフィギュレータは、このネットワークのために生成されたすべてのコネクタに、例えば｛…，”ｕｓｅＰＦＳ”：ｆａｌｓｅ，…｝を挿入することによって、ＰＦＳを使用する必要がないという情報を挿入することができるか、又は、コンフィギュレータは、例えば、ピア発見フレームにおけるプロトコル・バージョン属性値を適切にセッティングしたＤＰＰリリース１若しくはＤＰＰリリース２を使用することによって、すべてのコネクタにＰＦＳの使用についての情報を挿入せず、これにより、ＰＦＳを使用するべきか否かをデバイス及びＡＰ自体に任せる。

【0055】

オプションとして、コンフィギュレータは下位互換性のために、ＰＦＳが使用されるが、最低値より低いバージョンをサポートするデバイスにＰＦＳを使用することなく接続するのを許可される場合、この最低バージョン以降をサポートする他のデバイスにしかデバイスが接続することがないことを指示するコネクタで、例えばバージョン３といった仕様の特定の最低バージョンをサポートするデバイスを構成する。例として、コンフィギュレータは、コネクタにおける｛…，”ｍｕｓｔＵｓｅＰＦＳＩｆＶｅｒｓｉｏｎＡｔＬｅａｓｔ”：３，…｝を使用してこれを指示し、このようなＤＰＰコネクタで構成されたデバイスは、ＰＦＳを使用しなければならないか否かという指示が何もないコネクタを有するデバイスに、したがって、例えば、ＤＰＰリリース１［ＤＰＰ］又はリリース２［ＷＦＥＣ＿２］に適合するデバイスに、ＰＦＳの使用を強く要求することなく接続することになる。これは、ＤＰＰリリース１［ＤＰＰ］又はリリース２［ＷＦＥＣ＿２］のコネクタが、ＰＦＳ情報のバージョン又は使用を含まないからである。｛…，ＸＹＺ，…｝に関して、ＤＰＰコネクタのＪＳＯＮコードに「，ＸＹＺ」が挿入されることを意味することに留意されたい。

【0056】

ＤＰＰエンローリ及びＤＰＰコンフィギュレータは、バージョン情報用に使用される属性がＤＰＰ認証リクエスト及びＤＰＰ認証応答メッセージのそれぞれにおいて整合性保護されるので、ＤＰＰ認証リクエスト及びＤＰＰ認証応答メッセージにおいてＤＰＰエンローリ及びＤＰＰコンフィギュレータがサポートする最高バージョンのＤＰＰを、他のデバイスにセキュアに通告可能であることが指摘される。最高のサポートバージョンは、グレーディング指標で指示されるような、最低限要求されるバージョンと混乱されるべきではない。ＤＰＰリリース２［ＷＦＥＣ＿２］においてデバイス又はＡＰがＰＦＳをサポートすることが必須であることにさらに留意されたい。したがって、コンフィギュレータは、ＤＰＰエンローリがサポートするＤＰＰバージョンを確信しており、したがって、エンローリがＰＦＳをサポートするか否かを確信しており、したがって、エンローリ・コネクタにおいてＰＦＳを使用しなければならないという情報をエンローリが含むことができるか否かを確かに知っている。

【0057】

さらなる実施形態は、デバイス・トラッキング阻止のネゴシエーションに関し、この場合、第１のセキュリティ・レベルによるセキュリティ・プロトコルは、第１のデバイスのメッセージ内の繰り返されるデータに基づく、ネットワーク内の複数の通信セッションにわたる第１のデバイスのトラッキングを阻止せず、第２のセキュリティ・レベルによるセキュリティ・プロトコルは、トラッキングを阻止するために前記繰り返されるデータを回避又は修正することを要求する。デバイスにおいてプロセッサは、グレーディング指標によってそのように指示されたとき、前記トラッキング阻止を適用するように配置される。

【0058】

オプションとして、セキュリティ・プロトコルは、［ＤＰＰ］で定義されるように、Ｗｉ－Ｆｉデバイスを構成するためのデバイス・プロビジョニング・プロトコルに基づく。コネクタ・メッセージは、デバイス・プロビジョニング・プロトコルで定義されるような、再構成認証リクエスト・メッセージで使用するために生成されたコネクタに基づく再構成コネクタである。コンフィギュレータは、グレーディング指標を再構成コネクタに挿入するように配置され、グレーディング指標は、再構成されることを望むデバイスによってデバイス・トラッキング阻止が使用されるべきであることを指示する阻止制約を指示するものである。

【0059】

デバイスにおいてプロセッサは、再構成コネクタから阻止制約を取り出すため、及び阻止制約に基づく再構成中のトラッキング阻止を適用するように配置される。実践的な例では、コンフィギュレータ自体がトラッキング阻止をサポートすることをコンフィギュレータがエンローリに指示するエンローリへのコンフィギュレータのグレーディング指標に基づいて、エンローリは、エンローリがＤＰＰ再構成応答メッセージの中でコンフィギュレータに送るエンローリのコネクタのＮＡＫのために、トラッキング阻止を使用することができる。阻止制約は、
ＤＰＰ再構成リクエスト・メッセージにおけるエンローリのＣ－Ｃｏｎｎｅｃｔｏｒの一部として、
構成中にコンフィギュレータによってエンローリに送られたコネクタにおいて、したがって、ＤＰＰ構成応答メッセージの中で、又は
このメッセージにおけるどのコネクタにおいてでもなく、ＤＰＰ構成応答メッセージの一部として、
送られる。グレーディング指標は、これらの３つのケースのそれぞれにおいて整合性保護されることに留意されたい。

【0060】

前記「最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標」は、既に説明されたものに加えて、例えば、下位互換性のために、又は低コスト・デバイスのサポートを可能にするために、最低限のセキュリティ・レベルをサポートしないデバイスが、より低いレベルを使用するが、さらなる制約を条件とするのみであることを意味することが指摘される。例えば、グレーディング指標を受け取り、最低限のセキュリティ・レベルがサポートされないことを知ると、追加のリクエストが最初にセキュアに交換され、このリクエストの中で、旧式又は低コスト・デバイスが、より低いレベルの使用をリクエストする。又は、例えば、下位互換性のあるデバイスのための、より低い許容レベルを指示する追加のパラメータも、グレーディング指標の一部であることが可能である。それでも、デバイスが最低限のセキュリティ・レベルをサポートする場合、デバイスは、少なくともこの最低レベルを使用しなければならない。

【0061】

実践的例では、ＤＰＰリリース１［ＤＰＰ］及びリリース２［ＷＦＥＣ＿２］によるデバイスは、ＤＰＰピア発見リクエスト・フレームの中でデバイスのコネクタをＡＰにプレーンテキストで送り、ＡＰは、ＤＰＰピア発見応答フレームの中でＡＰのコネクタをＷｉ－Ｆｉデバイスにプレーンテキストで送る。デバイス又はＡＰのコネクタは、このデバイスの（一定の）公開鍵ＮＡＫを含むので、デバイス又はＡＰは、ＲＦ範囲内の任意のＷｉ－Ｆｉデバイスによってトラッキングされる可能性がある。公開ＮＡＫは、デバイスのアイデンティティとして機能することができる。これは、このデバイスのプライバシを侵害し、したがって問題である。

【0062】

ＤＰＰリリース２［ＷＦＥＣ＿２］における拡張のうちの１つは、ＤＰＰ再構成認証プロトコルである。ＤＰＰコンフィギュレータによって構成されたデバイスは、デバイスが構成されたネットワークへの接続に成功したものであるが、デバイスのコネクタを使用してＡＰに接続したとき、あとで問題に遭遇する。問題は、例えば、デバイスのコネクタが期限切れになること、又は第１のデバイス及び／若しくはＡＰが移動され、その結果、これらが偶然、互いのＲＦ範囲から外れた状態になることである。デバイスがＡＰとの接続問題を経験する場合、デバイスは、ＤＰＰ再構成認証プロトコル（［ＷＦＥＣ＿２］参照）を使用して、この問題をコンフィギュレータに指示し、再構成される。このプロトコルを使用して再構成されるデバイスは、ＤＰＰリリース２仕様［ＷＦＥＣ＿２］ではエンローリと呼ばれる。

【0063】

ＤＰＰリリース２［ＷＦＥＣ＿２］によるデバイスは、ＤＰＰ再構成認証応答メッセージの中でデバイスのコネクタをコンフィギュレータにプレーンテキストで送る。このメッセージにおけるコネクタは、デバイスがＡＰへのアクセス権を得るためにＤＰＰピア発見リクエスト・フレームの中で使用するものと同じコネクタである。したがって、デバイスのＤＰＰ再構成認証応答メッセージ又はＤＰＰピア発見リクエスト・フレームをキャプチャした他のデバイスによって、デバイスもトラッキングされる可能性がある。

【0064】

ＤＰＰリリース２［ＷＦＥＣ＿２］によるコンフィギュレータは、ＤＰＰ再構成認証リクエスト・メッセージの中でコンフィギュレータのコネクタをエンローリにプレーンテキストで送る。それでも、コンフィギュレータ・コネクタのＮＡＫは一過性であり、すなわち、ＮＡＫは、一度送るためだけにランダムに生成され、したがって、これらのメッセージを通じてコンフィギュレータがトラッキングされる可能性はない。

【0065】

上記に説明されたようにデバイス及びＡＰがトラッキングされるのを阻止することは、ＤＰＰリリース２［ＷＦＥＣ＿２］によってサポートされていない。それでも、ＤＰＰ再構成認証プロトコルにおける情報に基づくデバイス・トラッキングは、［２０１８ＰＦ００５０８］で説明されているように、コネクタのＮＡＫを暗号化することなど、プライバシ保護措置によって阻止される。追加として、プライバシ保護措置の使用は、デバイスとＡＰとの間でネゴシエートされなければならない。

【0066】

ＤＰＰピア発見リクエスト及び結果メッセージにおける情報に基づくデバイス・トラッキングの阻止をネゴシエートすることは、ＤＰＰリリース２［ＷＦＥＣ＿２］ではサポートされない。上記に説明されたようなＰＦＳの使用をネゴシエートすることに類似の簡単なオプションは、ＤＰＰピア発見リクエスト及び／又は応答フレームにおけるプロトコル・バージョン属性を使用することである。それでも、これらは整合性保護されず、ＭｉｔＭは、プロトコル・バージョン属性を変更又は除去することによってダウングレード攻撃を実施することができる。

【0067】

ＤＰＰ再構成認証メッセージにおける情報に基づくデバイス・トラッキングの阻止をネゴシエートすることは、ＤＰＰリリース２［ＷＦＥＣ＿２］ではサポートされない。さらなる簡単なオプションでは、コンフィギュレータは、コンフィギュレータがデバイス・トラッキング阻止をサポートする、再構成されることを望むデバイス、つまりエンローリにシグナリングするＤＰＰ再構成認証リクエスト・メッセージに属性を追加することができる。これは、コンフィギュレータへのデバイスのリプライ、つまりＤＰＰ再構成認証応答メッセージの中で、デバイスがそのデバイス・コネクタのＮＡＫを隠すことを可能にする。それでも、ＤＰＰ再構成認証リクエスト・メッセージは、整合性保護を何も提供せず（整合性保護を可能にするためにプロトコルにおいてこの時点で確立された共有鍵はない）、ＭｉｔＭは原則として、この属性を除去し、したがって、ダウングレード攻撃を実施することができる。

【0068】

以下の解決策は、ＤＰＰ再構成認証応答メッセージ及びＤＰＰピア発見応答フレームにおけるデバイス・トラッキング阻止の使用のネゴシエーションに対するダウングレード攻撃を阻止する。

【0069】

コンフィギュレータは、上述のＰＦＳの使用の制御と同様に、ＤＰＰにおけるデバイス・トラッキング阻止の使用をセキュアに制御する。ＰＦＳとは対照的に、デバイス・トラッキング阻止は、どちらかのデバイス又は両方が使用する技法である。例えば、ＡＰは、静止していてもそうでなくてもよい。静止ＡＰのロケーションは分かっており、変化することはない。したがって、ＤＰＰピア発見応答フレームにおける独自のコネクタに対して、静止ＡＰがデバイス・トラッキング阻止を使用しないことは受入れ可能であるが、静止ＡＰは、デバイスがＡＰに送るＤＰＰピア発見リクエスト・フレームにおけるデバイスのコネクタにデバイス・トラッキング阻止を適用するデバイスをサポートする。それでも、多くのスマート・フォンには、ホットスポットとして機能する能力があり、すなわち多くのスマート・フォンは、モバイルＷｉ－Ｆｉ ＡＰとして機能することができ、モバイルＷｉ－Ｆｉ ＡＰを通じて、このモバイルＡＰに関連付けられたＷｉ－Ｆｉデバイスは、スマート・フォンのモバイル・インターネット・サブスクリプションを通じたインターネット・アクセスを行うことができる。静止ＡＰとは対照的に、モバイル・フォンにおけるホットスポットのために、又はスマート・フォン以外のモバイルＷｉ－Ｆｉホットスポットにおいて、デバイス・トラッキング阻止を使用することが道理にかなう。

【0070】

ＡＰは、例えば、ＤＰＰピア発見リクエスト・フレームの中で、ＡＰのコネクタのためにデバイス・トラッキング阻止をデバイスが使用可能であるか使用しなければならないグレーディング・メッセージで、ＡＰに関連付けることを望むデバイスにシグナリングする。それでも、デバイスがＡＰのコネクタをまだ受け取っていないので、プロトコルのこの時点では、整合性保護がない。コネクタにおけるデバイス・トラッキング阻止を使用するべきかどうかを検出するための保護されていない方法が、［２０１８ＰＦ００５０８］で説明されている。

【0071】

ＡＰがそのコネクタにおいてデバイス・トラッキング阻止を使用できることをセキュアな様式でＡＰに知らせるための、ＡＰに関連付けることを望むデバイスのための解決策がここで説明される。ＡＰが前のＤＰＰピア発見リクエスト・フレームでデバイス・コネクタを受け取った後、ＡＰは、ＤＰＰピア発見応答フレームをデバイスに送る。コンフィギュレータはここで、コンフィギュレータがこのデバイスのために生成するあらゆるコネクタにグレーディング指標を挿入する。グレーディング指標は、ＤＰＰピア発見応答フレームの中でＡＰによってデバイス・トラッキング阻止が使用可能であるか使用されなければならないことを指示する。この情報は、例えば、｛…，”ｖｅｒｓｉｏｎ”：３，…｝といったバージョン番号のような汎用的な指示の形式、又は、例えば｛…，”ｍａｙＵｓｅＴｒａｃｋｉｎｇＰｒｅｖｅｎｔｉｏｎ”：ｔｒｕｅ，…｝若しくは｛…，”ｈａｓＴｏＵｓｅＴｒａｃｋｉｎｇＰｒｅｖｅｎｔｉｏｎ”：ｔｒｕｅ，…｝といった、より詳細な指示の形式であることが可能である。｛…，ＸＹＺ，…｝に関して、「，ＸＹＺ」は、ＤＰＰコネクタのＪＳＯＮコードに挿入されることを意味することに留意されたい。デバイスがこのようなコネクタをＤＰＰピア発見リクエスト・フレームの中でＡＰに送り、デバイス自体も、例えば、［２０１８ＰＦ００５０８］で説明された方法で、デバイスのコネクタのＮＡＫを暗号化することによって、デバイス・トラッキング阻止を使用する場合、ＡＰが、受け取ったコネクタの署名を照合できる前、及び、デバイス・トラッキング阻止を使用できるか使用しなければならないかに関わらず、成功した署名照合がセキュアに判定できた後、ＡＰは最初に、［２０１８ＰＦ００５０８］で説明されているように、受け取ったコネクタを復元しなければならない。

【0072】

ＤＰＰリリース２［ＷＦＥＣ＿２］によるデバイス（ＤＰＰエンローリ）は、ＤＰＰ再構成認証応答メッセージの中でデバイスのコネクタをコンフィギュレータにプレーンテキストで送る。このメッセージにおけるコネクタは、デバイスがＡＰへのアクセス権を得るためにＤＰＰピア発見リクエスト・フレームの中で使用するのと同じコネクタである。したがって、デバイスのＤＰＰピア発見リクエスト・フレームをキャプチャする他のデバイスによってデバイスがトラッキングされる可能性もある。

【0073】

実施形態では、ＤＰＰコンフィギュレータは、ＤＰＰ再構成認証リクエスト・メッセージを、再構成されることを望むデバイス（ＤＰＰエンローリ）に送っているとき、コネクタにおけるグレーディング指標を使用して、エンローリがＤＰＰ再構成認証応答メッセージでリプライするときに、エンローリがデバイス・トラッキング阻止を使用できるか使用しなければならないことを、エンローリにセキュアに知らせる。したがって、コンフィギュレータは、そのＤＰＰ再構成認証リクエスト・メッセージの中で使用するためにコンフィギュレータが生成するコンフィギュレータのコネクタに、グレーディング指標を挿入する。グレーディング指標は、再構成されることを望むエンローリによってデバイス・トラッキング阻止が使用可能であることを指示する。この情報は、例えば、例えば｛…，”ｖｅｒｓｉｏｎ”：３，…｝といったバージョン番号のような汎用的な指示の形式、又は、例えば｛…，”ｍａｙＵｓｅＴｒａｃｋｉｎｇＰｒｅｖｅｎｔｉｏｎ”：ｔｒｕｅ，…｝若しくは｛…，”ｕｓｅＴｒａｃｋｉｎｇＰｒｅｖｅｎｔｉｏｎ”：ｔｒｕｅ，…｝といった、より詳細な指示の形式であることが可能である。エンローリがデバイス・トラッキング阻止をサポートする場合、及びエンローリがデバイス・トラッキング阻止を使用できるというＤＰＰコンフィギュレータ・コネクタにおける情報をエンローリが見る場合、エンローリは、例えば、［２０１８ＰＦ００５０８］で説明されているように、エンローリのコネクタのＮＡＫを暗号化することによってデバイス・トラッキング阻止を使用する。

【0074】

さらなる実施形態では、セキュリティ・プロトコルは、以下のアクションを行うセットアップ・プロトコルを含む。最初に、証明書が証明機関から取得される。その後、例えば、生成された鍵、又は、証明書で指示されたセキュリティ・アルゴリズムを使用して、例えば、証明書に基づいて生成及び暗号化又は整合性保護された、証明書を使用するセキュリティ・パラメータが提供される。その後、セキュリティ・パラメータは、セットアップ・メッセージを介してデバイスに移送される。証明書は、グレーディング指標を含み、グレーディング指標は、セキュリティ・パラメータの制約を指示するものである。例えば、証明書は、構成されることになるデバイスからの、又はコンフィギュレータからの、証明リクエスト・メッセージに基づいて証明サーバによって提供される。リクエストは、グレーディング指標を含めたいというリクエスト、又は、グレーディング指標を介して保護されることになるパラメータ若しくはセッティングの指示を含む。

【0075】

上記のセキュリティ・プロトコルを適用するように配置されたデバイスのデバイス・プロセッサは、証明書からグレーディング指標を取り出すように構成される。その後、プロセッサは、セットアップ・メッセージを受け取る及び／又は伝送するように構成される。また、プロセッサは、セットアップ・メッセージ、及びセキュリティ・パラメータの制約に基づいて、セキュリティ・レベルを決定するように構成される。オプションとして、セキュリティ・プロトコルは、暗号セキュリティ・パラメータのセットアップを行う。暗号セキュリティ・パラメータは、使用することになる暗号法アルゴリズム、使用することになる鍵サイズ、使用することになる暗号学的ハッシュ・アルゴリズム、又は、使用することになるセキュリティ・プロトコル若しくは暗号プロセスのさらなるオプション若しくはパラメータのうちの１つ又は複数を含む。

【0076】

暗号パラメータの上記のネゴシエーション又はセットアップの例は、トランスポート・レイヤ・セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）である。多くの暗号プロトコルは、ＴＬＳ１．３［ＲＦＣ ８４４６］がそのうちの１つであり、例えば、前方秘匿性（ＰＦＳ：Ｐｅｒｆｅｃｔ Ｆｏｒｗａｒｄ Ｓｅｃｒｅｃｙ）を使用するためであってもそうでなくても、使用することになる暗号法アルゴリズム、使用することになる鍵サイズ、使用することになる暗号学的ハッシュ・アルゴリズム、又は、使用することになるプロトコルの変形形態などの、暗号プリミティブの使用に対する柔軟性を組み込んできた。上記の強化がどのように使用されるかを示すために、下記のＴＬＳ１．３［ＲＦＣ ８４４６］がさらに詳細に説明される。他の暗号プロトコルにおける使用は、この説明から容易に導出される。

【0077】

ＴＬＳネゴシエーション・フェーズでは、クライアントが送る第１のメッセージは、クライアントがサポートする最高のＴＬＳプロトコル・バージョン、乱数、提案される暗号法スイートのリスト、及び圧縮方法を指定するＣｌｉｅｎｔＨｅｌｌｏメッセージである。ＣｌｉｅｎｔＨｅｌｌｏメッセージに対するサーバのリプライは、特に、選択された暗号法スイートを含むＳｅｒｖｅｒＨｅｌｌｏメッセージである。ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏメッセージは、最初は整合性保護されない。それでも、（ＥＣ）ＤＨＥ（有限フィールド若しくは楕円曲線上のＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ）、事前共有鍵（ＰＳＫ：Ｐｒｅ－Ｓｈａｒｅｄ ｋｅｙ）のみ、又は（ＥＣ）ＤＨＥを伴うＰＳＫという、３つの可能なモードのいずれかを使用して、クライアントとサーバとの間で共有鍵が成功裏に確立されたとき、サーバがちょうど確立した共有鍵から導出された鍵に基づいて、セットアップ交換全体にわたる鍵付ハッシュを含む、したがって、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏメッセージを含む、クライアントへの「完成された」メッセージをサーバが送ることによって、ＴＬＳセットアップが完成される。その後、クライアントは、独自の「完成された」メッセージをサーバに送り、このメッセージも、セットアップ交換全体にわたる鍵付ハッシュを含む、したがって、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏメッセージを含む。鍵付ハッシュ関数は、鍵付ハッシュ関数の入力ベースのハッシュを作り出すハッシュ関数であり、ハッシュ値も（秘密）鍵の値に基づく。したがって、ＣｌｉｅｎｔＨｅｌｌｏ及び／又はＳｅｒｖｅｒＨｅｌｌｏメッセージは、ＴＬＳプロトコルにおいてあとで整合性保護される。

【0078】

ＴＬＳには多くの変形形態があり、ＴＬＳの暗号パラメータのためのいくつかの選択肢がある。ハッカーによって、ＴＬＳサーバ又はクライアントにおいてＴＬＳのセットアップを変更することが可能である。ＴＬＳサーバ又はクライアントのセットアップも、ＴＬＳサーバ又はクライアントの任意のアドミニストレータによって、元々意図していたセットアップから偶然又は故意に変更される。例えば、ブラウザＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒの「インターネット・オプション」メニューは、固有のＴＬＳバージョンの使用を許可する又は許可しないという選択肢をユーザに与える。

【0079】

したがって、通信ネゴシエーション・プロトコルのセットアップは、ダウングレード攻撃からの保護を必要とする。上記の構成パラメータはまた、サーバのアドミニストレータによって、例えば偶然に、変更される。これらの構成パラメータはまた、ハッカー又は悪意のあるインサイダによって故意に変更される。上記の強化は、ＴＬＳサーバ又はクライアントのアドミニストレータにとって、ＴＬＳのセットアップをよりセキュアなものにする。これは、パラメータの値をネゴシエートするためのメッセージが整合性保護されない他のプロトコルにおいても適用される。

【0080】

ＴＬＳのためにサーバをセットアップするとき、初期のアドミニストレータは、証明機関（ＣＡ）から証明書を取得しなければならない。作成されると、ＴＬＳクライアントがこの証明書をこれ以上受け入れないので、証明書が偶然又は故意に変更されることは不可能である。証明書を獲得することに加えて、（場合によっては異なる）アドミニストレータが、ＴＬＳの使用をセットアップしなければならない。このようなアドミニストレータは、例えば、以下をセットアップしなければならない。
・ サーバが使用を許可される、認証付き暗号（ＡＥＡＤ：Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｅｎｃｒｙｐｔｉｏｎ ｗｉｔｈ Ａｓｓｏｃｉａｔｅｄ Ｄａｔａ）アルゴリズム／ＨＭＡＣベースの抽出及び拡大鍵導出関数（ＨＫＤＦ：ＨＭＡＣ－ｂａｓｅｄ Ｅｘｔｒａｃｔ－ａｎｄ－Ｅｘｐａｎｄ Ｋｅｙ Ｄｅｒｉｖａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）ハッシュ・ペア、
・ サーバが使用を許可される（ＥＣ）ＤＨＥグループ、
・ サーバが使用を許可される署名アルゴリズム、並びに
・ 証明書の所有者デバイスが使用を許可されるＴＬＳの最低バージョン。

【0081】

使用されることが許可されるＴＬＳプロトコルの最低バージョンは、証明書自体のＴＬＳバージョンとは機能的に異なることに留意されたい。例えば、ＴＬＳ証明書は、ＴＬＳ Ｖ１．４に従ってフォーマットされた指標を有するが、このＴＬＳ Ｖ１．４証明書におけるグレーディング指標は、例えば、ＴＬＳ Ｖ１．４からのＴＬＳバージョンだけが許可されること、又はＴＬＳ Ｖ１．２以降が使用されなければならないことを指示する。

【0082】

証明機関からのサーバの証明書をリクエストするとき、、初期のアドミニストレータは、例えば、制約、セキュリティ・オプション、上述の許容値若しくは不許容値、又は他のＴＬＳ構成パラメータ等を指示する、グレーディング指標を証明書が含むことをリクエストするために、専用のグレーディング・データをリクエストに含める。

【0083】

証明書の現在の構文は、仕様言語として抽象構文記法１（ＡＳＮ．１：Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ Ｎｏｔａｔｉｏｎ Ｏｎｅ）、［Ｘ．６８０］を使用したＸ５０９ ｖ３［ＲＦＣ５２８０］において指定されている。証明書は、多くのもののための指標としてオブジェクト識別子（ＯＩＤ：Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）を使用する。例えば、ｏｒｇａｎｉｚａｔｉｏｎＮａｍｅの指示のために使用することになるＯＩＤは、２．５．４．１０であるが、ＲＳＡ暗号化、つまり特定の非対称暗号化アルゴリズムを指示するためのＯＩＤは、１．２．８４０．１１３５４９．１．１．１である。証明書の「拡張」構成要素における特定の拡張を指示するためのＯＩＤは、２．５．２９で始まり、Ｘ５０９ ｖ３［ＲＦＣ５２８０］のセクション４．２．１．９の基本制約拡張を指示するためのＯＩＤは、２．５．２９．１９である。

【0084】

ＴＬＳのＴＬＳパラメータの可能な値は、ＴＬＳ１．３［ＲＦＣ８４４６］において指定された数字でＴＬＳメッセージにおいて指示され、例えば、１６進数値（０ｘ０４０３）は、楕円曲線Ｐ－２５６（［ＦＩＰＳ１８６－４］参照）及びＳＨＡ２５６（［ＦＩＰＳ１８０－４］参照）をハッシュ・アルゴリズムとして使用して、「楕円曲線デジタル署名アルゴリズム」という署名アルゴリズム（［ＦＩＰＳ１８６－４］参照）を指示する。

【0085】

したがって、提案のように証明書を強化するために、Ｘ５０９は、ＯＩＤツリーのこの分野を維持する組織から適切な値が取得されたｘを伴う、新しいＯＩＤ２．５．２９．１９．ｘによって指示された、例えば「ａｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒｓ」と呼ばれる拡張で、拡張されることが可能であり、この新しい拡張は、ＴＬＳ１．３［ＲＦＣ８４４６］で指定されているような値で指示された、許容ＴＬＳパラメータの配列を含む。例として、この新しい拡張のために使用することになるタイプは、以下のようにＡＳＮ．１において表現される。
ＡｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒｓ：：＝ＳＥＱＵＥＮＣＥ｛ａｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒ 整数｝

【0086】

タイプ「ＡｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒｓ」のインスタンス化のエンコーディングのためのＡＳＮ．１は、タイプ「ＴＢＳＣｅｒｔｉｆｉｃａｔｅ」の「拡張」構成要素における「ｅｘｔｎＶａｌｕｅ」と呼ばれる構成要素に格納される（Ｘ５０９ ｖ３［ＲＦＣ５２８０］の節Ａ．１参照）。

【0087】

ＴＬＳ１．３［ＲＦＣ８４４６］で指定された１６進数値の代わりに、新しい拡張は、オブジェクト識別子（ＯＩＤ）を使用して、パラメータの許容値も指示する。ＯＩＤを使用する利点は、暗号パラメータを指示するために任意のプロトコルによるＯＩＤの使用が可能であることであり、ＴＬＳ１．３［ＲＦＣ８４４６］で指定された１６進数値は、ＴＬＳプロトコル用にこれを指示するために使用されることだけが可能である。例として、ＯＩＤを使用するこの新しい拡張用に使用することになるタイプは、以下のようにＡＳＮ．１において表現される。
AllowedTLSParameters ::= AllowedTLSParameterのセット
AllowedTLSParameter ::= SEQUENCE {
allowedTLSParameterType オブジェクト識別子,
allowedTLSParameterValues AllowedTLSParameterValues オプション
-- allowedTLSParameterValues は、オブジェクト識別子が単独では不十分な場合に必要とされる
}
AllowedTLSParameterValues::= AllowedTLSParameterValueのセット
AllowedTLSParameterValue ::= 整数

【0088】

上記のタイプＡｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒＶａｌｕｅｓは、例にすぎない。例えば、暗号アルゴリズムを指定するオブジェクト識別子、又はＡｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒタイプに類似のタイプ／値ペアといった、整数以外の他の情報がこの中にあってもよい。

【0089】

構成要素ａｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒＴｙｐｅのための可能なＯＩＤのうちの１つは、ＴＬＳを伴うこの証明書を使用するときに使用されなければならないＴＬＳプロトコルの最低限許容されるバージョン番号を指示するＯＩＤである。この場合、構成要素ａｌｌｏｗｅｄＴＬＳＰａｒａｍｅｔｅｒＶａｌｕｅｓは、例えば、ＴＬＳバージョン１．１を表す値１１を有する１つの整数構成要素を含むセットである。

【0090】

強化されたＴＬＳサーバが証明書を送るか、ＴＬＳクライアントが、使用することになる許容されるＴＬＳパラメータについての情報を有する証明書を受け取ったとき、及びネゴシエートされるＴＬＳパラメータが、証明書内の許容されるＴＬＳパラメータ・リストの中で言及されないとき、サーバ又はクライアントは、ＴＬＳプロトコルのセットアップを中止しなければならない。したがって、グレーディング指標は、このようなリストを指示するが、アルゴリズムのバージョン番号がＹ以上であるか、アルゴリズムの品質がＹ以上である場合に、例えば、２５６ビット以上の最盛期の長さを有するＥＣＣ曲線が使用される場合に、Ｘの使用が許可されるアルゴリズムのような構造も含む。グレーディング指標は、ブラックリスト、すなわち使用が許可されないＴＬＳパラメータのリストも指示する。ブラックリストは、アルゴリズムのバージョン番号がＹ以下か、アルゴリズムの品質がＹ以下の場合に、例えば、２５５ビット以下の最盛期の長さを有するＥＣＣ曲線が使用されない場合に、Ｘの使用が許可されないアルゴリズムのような構造も含む。

【0091】

ＴＬＳクライアントはまた、ＴＬＳクライアントを認証するためにＴＬＳサーバが使用可能な、並びに、ＴＬＳセットアップにおいて及びセッション鍵の導出のために使用される、証明書を有することができる。上述のＴＬＳサーバ証明書と同様に、ＴＬＳクライアント証明書も、ＴＬＳパラメータの、許容される若しくは許容されない値、又は許容される最低値を含むことができる。

【0092】

したがって、ＴＬＳのためにグレーディング指標を使用するとき、ＴＬＳサーバ又はクライアントのアドミニストレータは、ＴＬＳパラメータの許容される若しくは許容されない値、又は許容される最低値の指示を有するＴＬＳクライアント又はサーバのための証明書をリクエストすることができる。このようなＴＬＳクライアント又はサーバは、証明書によって許容されるＴＬＳパラメータの値しか使用することはない。ＴＬＳクライアント又はサーバの構成を変更することは、ＴＬＳクライアント又はサーバが許容されない値を使用することにはならず、したがって、ＴＬＳサーバ又はクライアントのセットアップは、そのアドミニストレータにとって、よりセキュアになる。

【0093】

さらなる実施形態では、証明書を使用したネットワークへのワイヤレス・アクセスのための暗号パラメータのネゴシエーションが、詳細な例としてＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅを使用して説明される。ＷＰＡ（Ｗｉ－Ｆｉプロテクテッド・アクセス：Ｗｉ－Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ａｃｃｅｓｓ）は、Ｗｉ－Ｆｉワイヤレス・ネットワーク・セキュリティのための仕様である。Ｗｉ－Ｆｉアライアンス（ＷＦＡ：Ｗｉ－Ｆｉ ａｌｌｉａｎｃｅ）は、ＷＦＡのためのＷＰＡ仕様及び証明プログラムを維持する。ＷＰＡは、ＷＰＡ－ＰＳＫ（事前共有鍵）、又は、一方ではＷＰＡ－Ｐｅｒｓｏｎａｌ及び他方ではＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅという、２つの種類になる。ＷＰＡの３つの主要リリース、すなわちＷＰＡ、ＷＰＡ２、及びＷＰＡ３［ＷＰＡ３］があり、３つのそれぞれが、２つの種類をサポートする。

【0094】

ＷＰＡ－ＰＳＫは、接続することになるネットワークのＰＳＫ（事前共有鍵）を有するように各Ｗｉ－Ｆｉデバイスに（ＡＰにも）要求する。ＰＳＫは通常、特定のネットワークのすべてのユーザにとって同じである。対照的に、ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅは、ネットワーク・ユーザ・アクセスを認証するタスクをハンドリングするＲＡＤＩＵＳサーバを要求する。実際の認証プロセスは、［８０２．１ｘ］において指定されており、８０２．１ｘポリシに基づき、ＥＡＰ（拡張可能認証プロトコル：Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）とラベル付けされたいくつかの異なるシステムになる。各デバイスが接続前に認証されるので、個人的な暗号化されたトンネルが、事実上、デバイスとネットワークとの間に作成される。

【0095】

ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅ ＡＰは、権限のないＷｉ－ＦｉデバイスがＲＡＤＩＵＳサーバと通信することしか可能にすることはない。ＲＡＤＩＵＳサーバがデバイスを認証すると、認証されたデバイス及びＡＰだけが、これら間のＷｉ－ＦｉセキュリティのためにＰＭＫ（ペアのマスタ鍵）を確立し、ＰＭＫは、認証プロセスにおいてＲＡＤＩＵＳサーバと交換される情報にも基づく。

【0096】

いくつかのＥＡＰプロトコルは、ＲＡＤＩＵＳサーバによって使用されることが可能であり、このプロトコルのうち、ＥＡＰ－ＴＬＳ［ＲＦＣ５２１６］及びＥＡＰ－ＴＴＬＳ／ＰＡＰ［ＲＦＣ５２８１］が、証明書を使用するＥＡＰバージョンである。

【0097】

ＥＡＰ－ＴＬＳは、すべてのＷｉ－Ｆｉデバイスがネットワーク・アクセスのための証明書を有することを要求するが、（ＲＡＤＩＵＳ）サーバ認証のためのサーバ証明書はオプションである。これは、ＥＡＰ－ＴＴＬＳ／ＰＡＰの逆であり、サーバ証明書は必須であり、クライアント証明書はオプションである。

【0098】

ＷＰＡ３－ＥｎｔｅｒｐｒｉｓｅとＷＰＡ２－Ｅｎｔｅｒｐｒｉｓｅとの間の違いは、デバイスが接続しているサーバのアイデンティティを確認するようにサーバ証明書承認が構成される要件をＷＰＡ３－Ｅｎｔｅｒｐｒｉｓｅが提供することである。

【0099】

この説明では、ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅは、ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅ、ＷＰＡ２－Ｅｎｔｅｒｐｒｉｓｅ、ＷＰＡ３－Ｅｎｔｅｒｐｒｉｓｅ、又はその将来の後続種のいずれかを意味する。

【0100】

上記の実施形態と同様に、ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅで使用するための証明書をリクエストするエンティティと、ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅの使用のためのＡＰ又はＷｉ－Ｆｉデバイスを形作るエンティティとは、異なる。提案される強化は、ＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅのセットアップを、ＴＬＳサーバ又はクライアントのアドミニストレータにとって、よりセキュアなものにする。

【0101】

Ｗｉ－ＦｉデバイスとＡＰとの間のＷｉ－Ｆｉ接続のセキュリティのネゴシエーションは、デバイスがＡＰに関連付けることができる前にＷｉ－ＦｉデバイスとＡＰとの間で交換されるメッセージの中で、したがって、例えば、デバイスによって送られるプローブ・リクエスト、並びにＡＰによって送られるプローブ応答及びビーコンの中で、ロブスト・セキュリティ・ネットワーク要素（ＲＳＮＥ：Ｒｏｂｕｓｔ Ｓｅｃｕｒｉｔｙ Ｎｅｔｗｏｒｋ ｅｌｅｍｅｎｔ、［８０２．１１］の節９．４．２．２５）を使用して行われる。ＲＳＮＥは、ペアの暗号法スイート・リスト並びにＡＫＭ（認証及び鍵管理：ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ ｋｅｙ ｍａｎａｇｅｍｅｎｔ）スイート・リストを含む。ペアの暗号法スイート・リストは、暗号法スイート・セレクタによって指示された、デバイスがサポートする暗号法をリスト化し、例えば、暗号法スイート・セレクタ００－０Ｆ－ＡＣ：４は、ＣＣＭＰ－１２８アルゴリズムを指示する。ＡＫＭスイート・リストは、ＡＫＭスイート・セレクタによって指示された、デバイスがサポートするＡＫＭをリスト化する。ＡＫＭは、デバイス及び／又はＡＰを認証するためのプロトコルである。例えば、ＡＫＭスイート・セレクタ００－０Ｆ－ＡＣ：１は、ＩＥＥＥ Ｓｔｄ８０２．１Ｘを介してネゴシエートされた認証を指示し、これは、ＲＡＤＩＵＳサーバを使用した認証を意味する。

【0102】

プローブ・リクエスト、プローブ応答、及びビーコンは整合性保護されず、ＭｉｔＭ攻撃者によって変更される可能性がある。それでも、デバイスは、デバイスがサポートしないプロトコル又はアルゴリズムを決して使用することができない。デバイスは、デバイスが、要求された情報を有していないプロトコルを、成功裏に完成させることもできない。例えば、パスフレーズを知らないデバイスは、ＡＰに関連付けるためにＷＰＡ－Ｐｅｒｓｏｎａｌを使用することができない。同様に、ＥＡＰ－ＴＬＳ及びＥＡＰ－ＴＴＬＳ／ＰＡＰのような他のセキュリティ・プロセスも、いくつかのネゴシエーションを行う。

【0103】

デバイス、サーバ、又はＡＰが初期の証明書を提供された後、セキュリティのセットアップのために行われる、及び攻撃者又は不注意なアドミニストレータによって変更される可能性がある、いくつかの選択肢がまだある。例えば、ＥＡＰ－ＴＬＳのためにセットアップされたデバイスは、証明書を有さなければならない。それでも、この場合のＲＡＤＩＵＳサーバが、サーバ認証のための証明書も有することはオプションである。これは、ＲＡＤＩＵＳサーバがサーバ側認証に従事できるときにＲＡＤＩＵＳサーバだけを受け入れるようにデバイスが元々セットアップされていることである。他の不注意なアドミニストレータ又はハッカーは、あとでこれを変更することができ、これにより、セキュリティのレベルを低下させる。グレーディング指標に関する上記の強化を使用することによって、元のアドミニストレータは、サーバ証明書を使用したサーバ側認証が常に使用されなければならないという制約を含むデバイス証明書を申請することができる。次いで、デバイスは、あとで不注意なアドミニストレータ又はハッカーが、これを要求しないようにデバイスのセットアップを変更したとしても、サーバ側認証を実施しないＲＡＤＩＵＳサーバを認証することを拒絶する。証明書に追加される別の制約は、認証後に使用することになるＰＭＫのサイズであることが可能である。例えば、制約は、使用することになるＰＭＫが１２８ビットより大きくなければならないことである。制約は、例えば前の実施形態で論じられたような、グレーディング指標を介して証明書に含まれることが可能である。

【0104】

さらなる実施形態では、第１のデバイスは、クライアント・デバイスであり、第２のデバイスは、サーバ・デバイスであり、グレーディング指標は、証明書を使用したクライアント側認証が要求されるクライアント制約を指示するものである。クライアント・デバイスのプロセッサは、証明書からクライアント制約を取り出すように配置される。その後、プロセッサは、セットアップ・メッセージを受け取り、クライアント制約に基づいてクライアント側認証を適用するように配置される。実践的例では、ＥＡＰ－ＴＬＳのためにセットアップされるデバイスと同様に、ＥＡＰ－ＴＴＬＳ／ＰＡＰのためにセットアップされるＡＰは、証明書を有さなければならない。それでも、クライアント側認証はオプションである。ＡＰのための証明書をリクエストするアドミニストレータは本発明を使用して、証明書を使用したクライアント側認証が常に要求されるという制約を伴う証明書をリクエストする。次いでＡＰは、あとで不注意なアドミニストレータ又はハッカーが、クライアント証明書を要求しないようにＡＰのセットアップを変更したとしても、このプロトコル中に証明書を提示可能でないデバイスで、ＥＡＰ－ＴＴＬＳ／ＰＡＰを成功裏に完成させることを常に拒絶することになる。

【0105】

したがって、上記の強化は、ＥＡＰ－ＴＬＳ又はＥＡＰ－ＴＴＬＳ／ＰＡＰを使用したデバイス及びＡＰ上のＷＰＡ－Ｅｎｔｅｒｐｒｉｓｅのセットアップをよりセキュアなものにし、セキュリティ・ネゴシエーション・メッセージを変更するＭｉｔＭ攻撃者からの保護を提供する。

【0106】

上記の実施形態は、デバイスを使用して説明されてきた。それでも、様々なプロトコル、メッセージ、及びプロセッサ・アクションは、上記の説明から容易に導出されることが可能な対応する方法のステップによって実行される。方法は、例えば、プロセッサ又はＷｉ－Ｆｉコントローラにおける回路機器及びソフトウェアによって、実行される。適切な暗号化及び復号機能が上記で説明されてきた。当業者には明らかなように、方法を実行する多くの異なる方式が可能である。例えば、ステージ若しくはステップの順序は変えることができ、又はいくつかのステージは、平行に実行されてもよい。その上、ステップの間に他の方法のステップが挿入されてもよい。挿入されたステップは、本明細書で説明されるような方法の改良を表しても、方法に無関係でもよい。

【0107】

上記の方法、接続シーケンス、セキュリティ・プロセス、及び、コンピュータ・デバイスで実行されるときのさらなる動作を実行するための、プログラム・コード命令を備える、ネットワークからダウンロード可能な、並びに／又はコンピュータ可読媒体及び／若しくはマイクロプロセッサ実行可能媒体に格納された、コンピュータ・プログラム製品が提供される。したがって、本発明による方法は、それぞれの方法をプロセッサ・システムに実施させるための命令を備えるソフトウェア使用して実行される。

【0108】

図２ａは、コンピュータ・プログラム１０２０を備える書込み可能部分１０１０を有するコンピュータ可読媒体１０００を示しており、コンピュータ・プログラム１０２０は、図１を参照しながら説明されたようなシステムで上記の方法のうちの１つ又は複数をプロセッサ・システムに実施させるための命令を備える。コンピュータ・プログラム１０２０は、物理的なマークとして、又はコンピュータ可読媒体１０００の磁化によって、コンピュータ可読媒体１０００上で具体化される。それでも、任意の他の適切な実施形態が同様に考えられる。さらに、コンピュータ可読媒体１０００が光ディスクとしてここでは示されているが、コンピュータ可読媒体１０００は、ハードディスク、ソリッド・ステート・メモリ、フラッシュ・メモリなど、任意の適切なコンピュータ可読媒体でもよく、書込み不能でも書込み可能でもよいことが理解されよう。コンピュータ・プログラム１０２０は、前記方法をプロセッサ・システムに実施させるための命令を備える。

【0109】

典型的には、上記のプロセスを実行するデバイスは、デバイスに格納された適切なソフトウェア・コードを含むメモリに連結されたプロセッサをそれぞれが備え、例えば、このソフトウェアは、ダウンロードされたもの、及び／又は例えば、ＲＡＭなどの揮発性メモリ、若しくはフラッシュなどの不揮発性メモリ（図示せず）といった、対応するメモリに格納されたものである。デバイスには、例えば、マイクロプロセッサ及びメモリが装備される（図示せず）。代替として、デバイスは、全体的又は部分的に、例えばフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）として、プログラム可能ロジックに実装される。デバイス及びサーバは、全体的又は部分的に、いわゆる特定用途向け集積回路（ＡＳＩＣ）、すなわちデバイス及びサーバの特定の用途のためにカスタマイズされた集積回路（ＩＣ）として、実装される。例えば、回路は、例えば、Ｖｅｒｉｌｏｇ、ＶＨＤＬなどのハードウェア記述言語を使用して、ＣＭＯＳに実装される。

【0110】

図２ｂは、図１を参照しながら説明されたようなデバイス又はサーバの実施形態によるプロセッサ・システム１１００の概略図で示している。プロセッサ・システムは、例えば、それぞれが１つ又は複数の集積回路を備える、１つ又は複数の回路１１１０によって具体化される。回路１１１０は、実施形態による方法を実行するため、及び／又はそのモジュール若しくはユニットを実装するための、コンピュータ・プログラム構成要素を動かすための、例えばＣＰＵのような、処理ユニット１１２０を備える。回路１１１０は、プログラム・コード、データ等を格納するためのメモリ１１２２を備える。メモリ１１２２の一部は、読取り専用である。回路１１１０は、例えば、アンテナ、コネクタ、又は両方、及び同様のものを有するトランシーバといった、通信要素１１２６を備える。回路１１１０は、本方法で定義される処理の一部又はすべてを実施するための専用集積回路１１２４を備える。プロセッサ１１２０、メモリ１１２２、専用ＩＣ１１２４、及び通信要素１１２６は、例えばバスといった相互接続１１３０を介して互いに接続される。プロセッサ・システム１１１０は、アンテナ及び／又はコネクタを使用した、接触及び／又は非接触通信をそれぞれ行うように配置される。

【0111】

ソフトウェアは、システムの特定のサブエンティティによって行われるステップしか含まない。ソフトウェアは、ハードディスク、フロッピー、メモリなど、適切なストレージ媒体に格納される。ソフトウェアは、ワイヤに沿って信号として、又はワイヤレスで、又は例えばインターネットといったデータ・ネットワークを使用して、送られる。ソフトウェアは、ダウンロードするため、及び／又はサーバ上でのリモート使用のために、利用可能にされる。本発明による方法は、方法を実施するように、例えばフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）といった、プログラム可能ロジックを構成するように配置されたビット・ストリームを使用して実行される。ソフトウェアは、ソース・コード、オブジェクト・コード、部分的にコンパイルされた形式などのコード中間ソース及びオブジェクト・コードの形式、又は、本発明による方法の実装形態での使用に適切な任意の他の形式であることが理解されよう。コンピュータ・プログラム製品に関する実施形態は、説明された方法のうちの少なくとも１つの処理ステップのそれぞれに対応するコンピュータ実行可能命令を備える。これらの命令は、サブルーチンに再分割される、及び／又は、静的若しくは動的にリンクされた１つ若しくは複数のファイルに格納される。コンピュータ・プログラム製品に関する別の実施形態は、説明されたシステム及び／又は製品のうちの少なくとも１つの手段のそれぞれに対応するコンピュータ実行可能命令を備える。

【0112】

明瞭さのために、上記の説明は、異なる機能ユニット及びプロセッサを参照しながら本発明の実施形態を説明していることが理解されよう。それでも、異なる機能ユニット又はプロセッサの間の機能の任意の適切な分散が、本発明から逸脱することなく使用されることが明らかであろう。例えば、別個のユニット、プロセッサ、又はコントローラによって実施されるように示された機能は、同じプロセッサ又はコントローラによって実施されてもよい。したがって、固有の機能ユニットへの言及は、厳格な論理的又は物理的構造又は編成を指示するものではなく、説明された機能性を提供するのに適切な手段への言及とみなされるためのものにすぎない。本発明は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組合せを含む、任意の適切な形式で実行可能である。

【0113】

本書類では、「備える」という単語は、挙げられたもの以外の要素又はステップの存在を除外せず、単数形の要素は、複数のこのような要素の存在を除外しないということ、任意の参照符号は、特許請求の範囲の範囲を限定しないということ、本発明が、ハードウェア及びソフトウェア両方によって実行されるということ、並びに、いくつかの「手段」又は「ユニット」は、ハードウェア又はソフトウェアの同じアイテムによって表され、プロセッサが、場合によってはハードウェア要素と協力して、１つ又は複数のユニットの機能を果たすことが指摘される。さらに、本発明は、実施形態に限定されず、本発明は、それぞれの及びあらゆる斬新な特徴、又は上述の若しくは相互に異なる従属請求項で列挙された特徴の組合せにある。

【0114】

要約すると、本出願は、セキュリティ・プロトコルよる物理チャネルを介した第１のデバイスと第２のデバイスとの間のセキュアな通信を確立するためのデバイス及び方法に関する。プロトコルは、第１のデバイスにおける第１の整合性データ、及び第２のデバイスにおける第２の整合性データを確立する。プロトコルは、少なくとも２つのセキュリティ・レベルを有する。適用されるセキュリティ・レベルは、物理チャネルを介して移送されたグレーディング情報に基づいて選択可能である。有利には、第１のデバイス及び第２のデバイスのうちの少なくとも１つで最低限要求されるような最低限のセキュリティ・レベルを指示するグレーディング指標は、物理チャネルを介して移送され、その一方で、グレーディング指標の整合性保護は、整合性データに基づいて提供される。これにより、セキュリティ・レベルをダウングレードさせる中間者攻撃が阻止される。

【図1】

【図2a】

【図2b】

【国際調査報告】