JP2023535474A - アソシエーション制御方法及び関連装置 - Google Patents

Abstract

アソシエーション法及び装置が提供され、近距離通信に適用される。この方法は、第２のノードのアイデンティティが信頼されていると決定することと（Ｓ３０３）、第１の認証要求を第２のノードに送信することであって、第１の認証要求は、共有鍵に基づいて生成される第１のアイデンティティ認証情報を含む、ことと（Ｓ３０４）、第２のノードから第１の認証応答を受信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含む、ことと、共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行することと（Ｓ３０７）、検証が失敗した場合、第１の認証失敗カウンタを更新することとと（Ｓ３０８）、を含む。これは、ノードが認証されていない攻撃者とのアソシエーションを確立することを防止し、ノードのデータ・セキュリティを保護することができる。

Description

本発明は、通信技術の分野に関連し、特に、近距離通信技術の分野、例えば、コックピット・ドメイン通信に関連する。具体的には、通信セキュリティ管理のためのアソシエーション制御方法及び関連装置が提供される。

情報化の急速な発展に伴い、携帯電話、タブレット端末、その他のポータブル・インテリジェント端末に関わらず、携帯端末は不可欠なパーソナル・インテリジェント・ツールとなっている。情報化によりもたらされる利便性を享受する一方で、人々は、セキュリティの脆弱性やプライバシーの流出といった脅威にも直面している。インテリジェント車両が一例として使用される。車両通信が広く適用されているため、車両通信は車両に対する一連のセキュリティ・リスクももたらす。例えば、既存の近距離通信技術（ワイヤレス・フィデリティＷｉ－Ｆｉ、ブルートゥースなど）では、ハッカーは車載情報システムに侵入して、車両情報を取得したり、車両を遠隔操作させることさえあり得る。これは、ユーザのプライバシー及び車両のセキュリティに非常に大きな脅威をもたらす。世界中で数百万台の車両が影響を受ける。別の例として、サービス拒否（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ、ＤｏＳ）は、車両通信プロセスにおいて最も一般的で、容易に受信される攻撃行動である。サービス拒否の攻撃者は、ネットワーク・プロトコル実装の欠陥を故意に攻撃するか、又は攻撃されたオブジェクト（例えば、車両の制御センタ）のリソースを乱暴に消費する攻撃的な手段を直接使用し、その結果、攻撃されたオブジェクトは、正常なサービスを提供できず、応答を停止したり、機能停止することさえある。認証フラッド（Ａｕｔｈ Ｆｌｏｏｄ）攻撃は、ＤｏＳ攻撃の１タイプである。攻撃者は、アソシエーションされるノードに多数の要求フレームを送信する。ノードが多数の要求フレームを受信し、ノードが負うことができる処理能力を超えるときに、ノードは機能停止し、正常なサービスを提供し続けることができなくなり、これは、別のノードとノードとの間の通信に影響を与える。したがって、通信のセキュリティを保証するために、ノードのアソシエーション制御が非常に重要である。

従来技術では、アソシエーションを要求するノードは、ホワイトリスト又はブラックリスト技術を使用して制限されることがある。具体的には、ノードＡの識別子がノードＢのホワイトリストにある場合、ノードＢはノードＡからアソシエーション要求を受け取り、アソシエーションを実行する。これに対応して、ノードＣの識別子がノードＢのブラックリストにある場合、ノードＢは、ノードＣからアソシエーション要求を受信しなくてもよいか、又はアソシエーションの実行を拒否してもよい。具体的には、例えば、ブルートゥース通信処理において、ブルートゥース・デバイスがホワイトリストを確立し、その結果、ブルートゥース・デバイスは、特定のブルートゥース・デバイス（すなわち、ホワイトリストにリストされたブルートゥース・デバイス）とのアソシエーションを確立することができる。しかしながら、ホワイトリスト又はブラックリストは、通常、識別子（デバイス・アドレスなど）を使用してフィルタリングを実行する。攻撃者は、攻撃者の識別子を信頼されている識別子に変更することがあり、その結果、認証されていない攻撃者をノードは識別することができない。結果として、ノードは攻撃者とアソシエーションを確立し、ノードのデータ・セキュリティを脅かすことがある。

したがって、認証されていない攻撃者とアソシエーションをノードが確立することをどのように防止するかは、当業者が研究しているホットな問題である。

この出願の実施形態は、認証されていない攻撃者とアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを保護するためのアソシエーション制御方法及び関連装置を開示する。

第１の態様によれば、この出願の実施形態は、アソシエーション制御方法を提供する。方法は、
第１のアソシエーション要求を第２のノードから受信することと、
第２のノードのアイデンティティが信頼されていることを決定し、第１の認証要求を第２のノードに送信することであって、第１の認証要求は、第１のアイデンティティ認証情報を含み、第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて生成され、共有鍵は、第１のノードと第２のノードとの間で共有される第１の秘密値とみなされ得る、ことと、
第２のノードから第１の認証応答を受信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含む、ことと、
共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行することと、
第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新することであって、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す、こととを、含む。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定された後に、第２のノードのアイデンティティは、第１のノードと第２のノードとの間で共有される共有鍵に基づいてさらに検証される必要がある。このように、攻撃者が、識別子を修正することにより、「アイデンティティが信頼されていると決定する」ステップを避ける場合でも、アイデンティティ認証情報を偽造することが難しいため、攻撃者に対する第１のノードによって実行されるアイデンティ認証は依然として成功することができない。したがって、認証されていない攻撃者とのアソシエーションをノードが確立することが防止され、ノードのデータ・セキュリティが向上する。

さらに、検証が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、（例えば、認証要求を送信する）ノードのアソシエーション要求はもはや処理されなくてもよく、ノードが多数の要求を処理することで動作停止することを防止し、ノードによって提供されるサービスの正常な動作を保証する。

第１の態様の可能な実装では、第２のノードのアイデンティティが信頼されていると決定することは、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを含む。

前述の方法では、ブラックリスト又はホワイトリストに基づいてアソシエーションを要求するノードが制御されてもよく、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これにより、多数の要求の処理による機能停止を防止し、サービスの正常な動作を保証することができる。追加的に、ノードは、アイデンティティ認証を受けないノードとのアソシエーションを確立しないため、ノードが認証されていない攻撃者とのアソシエーションを確立することが防止され、ノードのデータ・セキュリティが向上する。

第１の態様の別の可能な実装では、第２のノードのアイデンティティが信頼されていると決定することは、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを含む。

第１の態様のさらに別の可能な実装では、第１の認証応答は、第２の完全性検査データをさらに含み、第２の完全性検査データは、第１の認証応答に対してメッセージ完全性検査を実行するために使用される。方法は、
第１の認証応答に対するメッセージ完全性検査が成功したと決定することをさらに含む。

第２のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第２のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、ノードによって提供されるサービスの安定した動作を保証する。

第１の態様のさらに別の可能な実装では、第２のノードから第１のアソシエーション要求を受信する前に、方法は、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定することであって、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す、ことをさらに含む。

前述の方法では、第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信され得る。第１のアソシエーション閾値は、ノードによって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、ノードは、アソシエーション要求をもはや受信又は処理しなくてもよく、ノードとノードにアソシエーションされた別のノードとの間の通信に影響を与えず、ノードによって提供されるサービスの安定した動作を保証する。

第１の態様のさらに別の可能な実装では、方法は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション応答を第２のノードに送信することであって、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される、ことをさらに含む。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

第１の態様のさらに別の可能な実装では、方法は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション失敗カウンタをリセットすることをさらに含む。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、ノードによって提供されるサービスの安定した動作を保証することが分かる。

第１の態様のさらに別の可能な実装では、共有鍵に基づいた第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新した後に、方法は、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加することをさらに含む。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第１の態様のさらに別の可能な実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続期間は１週間であってもよく、ブラックリストに追加された１週間後に、ブラックリストから第２のノードの識別子が削除されてもよい。

第１の態様のさらに別の可能な実装では、方法は、
第１のブラックリストに第２のノードの識別子が追加されている持続期間が第１の持続期間を超える場合、第１のブラックリストから第２のノードの識別子を削除することであって、第１の持続期間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する、ことをさらに含む。

前述の実装は、第１のブラックリストの有効期間に関連する要因を説明する。第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続期間が長くなることを示す。さらに、任意選択で、第１のブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードが第１のブラックリストに永久的に追加されてもよい。

追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。第１の態様のさらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、ノードのリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

第２の態様によれば、この出願の実施形態は、アソシエーション方法をさらに提供する。方法は、
第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を第１のノードに送信することと、
第１の認証要求を第１のノードから受信することであって、第１の認証要求は、第１のアイデンティティ認証情報を含む、ことと、
第２のノードと第１のノードとの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行することであって、共有鍵は、第１のノードと第２のノードとの間で共有される秘密の値である、ことと、
第１のアイデンティティ認証情報に対する検証が成功した場合、第１のノードに第１の認証応答を送信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含み、第２のアイデンティティ認証情報は、共有鍵に基づいて生成される、こととを含む。

この出願のこの実施形態では、第１のノードのアイデンティティが信頼されていると決定された後、第１のアソシエーション要求が第１のノードに送信される。次いで、共有鍵を使用して、第１の認証要求における第１のアイデンティティ認証情報に基づいて、第１のノードのアイデンティティ認証情報に対する検証が実行される。検証が成功した後に、第２のアイデンティティ認証情報が第１のノードに送信される。第２のアイデンティティ認証情報は、第１のノードが第２のノードのアイデンティティを検証するために使用されてもよい。アイデンティティが信頼されていると決定された後に、アソシエーションは、両者のアイデンティティ認証が成功した後にのみ実行され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第２のノードによって実行されるアイデンティティ認証を避けることが難しく、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第２の態様の可能な実装では、第１のノードのアイデンティティが信頼されていると決定することは、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを含む。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、ノードは、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第２の態様の別の可能な実装では、第１のノードのアイデンティティが信頼されていると決定することは、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを含む。

第２の態様のさらに別の可能な実装では、第１の認証要求は、第１の完全性検査データをさらに含み、第１の完全性検査データは、第１の認証要求に対してメッセージ完全性検査を実行するために使用される。

方法は、
第１の認証要求に対するメッセージ完全性検査が成功したと決定することをさらに含む。

第１のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第１のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、ノードによって提供されるサービスの安定した動作を保証する。

第２の態様のさらに別の可能な実装では、第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を第１のノードに送信する前に、方法は、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定することであって、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す、ことをさらに含む。

前述の方法では、アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、ノードにアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、ノードは、別のノードにアソシエーションされることができず、ノードとノードにアソシエーションされた別のノードとの間の通信に影響を与えず、ノードによって提供されるサービスの安定した動作を保証する。

第２の態様のさらに別の可能な実装では、方法は、
第１のノードから第１のアソシエーション応答を受信することであって、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される、ことをさらに含む。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、第２のノードは、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを第２のノードに通知してもよい。

第２の態様のさらに別の可能な実装では、方法は、
第２の認証失敗カウンタをリセットすることであって、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す、ことをさらに含む。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、ノードによって提供されるサービスの安定した動作を保証することが分かる。

第２の態様のさらに別の可能な実装では、方法は、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新することであって、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す、ことをさらに含む。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、第１のノードのアイデンティティ検証失敗の数が更新され、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第２の態様のさらに別の可能な実装では、第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新した後に、方法は、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定することと、
第１のノードの識別子を第２のブラックリストに追加することと、をさらに含む。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードが認証要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第２の態様のさらに別の可能な実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、第２の持続期間は１０日であってもよく、ブラックリストに追加されてから１０日後に、ブラックリストから第１のノードの識別子が削除されてもよい。

第２の態様のさらに別の可能な実装では、第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新した後に、方法は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第１のノードに第２のアソシエーション要求を送信することと、をさらに含む。

アイデンティティ認証情報を検証する処理において、いくつかのパラメータは伝送プロセスにおいて失われるか又は誤って伝送されるため、アイデンティティ認証情報に対する検証も失敗する可能性があることが理解されよう。したがって、第１のノードの検証失敗の数が事前セットされた第２の閾値を超えない場合、アソシエーション要求は、第１のノードに再送されて、ノードとアソシエーションを確立することを要求してもよい。このようにして、システムの頑健性が向上し、ノードによって提供されるサービスの安定した動作が保証される。

第２の態様のさらに別の可能な実装では、第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新した後に、方法は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、をさらに含む。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

第２の態様のさらに別の可能な実装では、方法は、
第２のブラックリストに第１のノードの識別子が追加されている持続期間が第２の持続期間を超える場合、第２のブラックリストから第１のノードの識別子を削除することであって、第２の持続期間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する、ことをさらに含む。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続期間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

第２の態様のさらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

第３の態様によれば、この出願の実施形態は、アソシエーション制御方法をさらに提供する。装置は、
第２のノードから第１のアソシエーション要求を受信するように構成されている通信ユニットと、
第２のノードのアイデンティティが信頼されていると決定し、通信ユニットを使用して、第１の認証要求を第２のノードに送信するように構成されている処理ユニットであって、第１の認証要求は、第１のアイデンティティ認証情報を含み、第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて生成される、処理ユニットと、を含む。

通信ユニットは、第２のノードから第１の認証応答を受信するようにさらに構成されている。第１の認証応答は、第２のアイデンティティ認証情報を含む。

処理ユニットは、共有鍵に基づいて、第２のアイデンティティ認証情報に対して検証を実行するようにさらに構成される。

処理ユニットは、第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新するようにさらに構成されている。第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す。

この出願のこの実施形態では、装置は、第２のノードのアイデンティティが信頼されていると決定した後に、第２のノードと共有される共有鍵に基づいて第２のノードのアイデンティティを検証する。このように、攻撃者が、識別子を修正することにより、アイデンティティが装置から信頼されていると決定するステップを避ける場合でも、アイデンティティ認証情報を偽造することが難しいため、攻撃者に対する装置によって実行されるアイデンティ認証は依然として成功することができない。したがって、認証されていない攻撃者とのアソシエーションを装置が確立することが防止され、ノードのデータ・セキュリティが向上する。

さらに、検証が失敗した場合、装置は、検証失敗の数を更新する。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、装置は、（例えば、認証要求を送信する）ノードのアソシエーション要求をもはや処理しなくてもよく、装置が多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

第３の態様の可能な実装では、処理ユニットは、具体的には、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている。

装置は、ブラックリスト又はホワイトリストに基づいてアソシエーションを要求するノードを制御し、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これにより、多数の要求の処理による機能停止を防止し、サービスの正常な動作を保証することができる。追加的に、装置は、アイデンティティ認証を受けないノードとのアソシエーションを確立しないため、装置が認証されていない攻撃者とのアソシエーションを確立することが防止され、装置のデータ・セキュリティが向上する。

第３の態様の別の可能な実装では、処理ユニット７０２は、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

第３の態様のさらに別の可能な実装では、第１の認証応答は、第２の完全性検査データをさらに含み、第２の完全性検査データは、第１の認証応答に対してメッセージ完全性検査を実行するために使用される。

処理ユニットは、具体的には、
第１の認証応答に対するメッセージ完全性検査が成功したと決定するように構成されている。
第２のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第２のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証する。

第３の態様のさらに別の可能な実装では、処理ユニットは、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第１のアソシエーション閾値が装置に事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、装置によって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、装置は、アソシエーション要求をもはや受信又は処理しなくてもよく、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

第３の態様のさらに別の可能な実装では、通信ユニットは、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション応答を第２のノードに送信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

第３の態様のさらに別の可能な実装では、処理ユニットは、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１の認証失敗カウンタをリセットするようにさらに構成されている。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

第３の態様のさらに別の可能な実装では、処理ユニットは、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加するようにさらに構成されている。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第３の態様のさらに別の可能な実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続期間は１週間であってもよく、ブラックリストに追加された１週間後に、ブラックリストから第２のノードの識別子が削除されてもよい。

第３の態様のさらに別の可能な実装では、処理ユニットは、
第１のブラックリストに第２のノードの識別子が追加されている持続期間が第１の持続期間を超える場合、第１のブラックリストから第２のノードの識別子を削除するようにさらに構成されており、第１の持続期間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第１のブラックリストの有効期間に関連する要因を説明する。第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続期間が長くなることを示す。さらに、任意選択で、第１のブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードが第１のブラックリストに永久的に追加されてもよい。

追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。デバイス・タイプの数は、この出願では具体的には限定されず、特定のシナリオに基づいて設計されてもよい。

第３の態様のさらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、装置のリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

第４の態様によれば、この出願の実施形態は、アソシエーション装置をさらに提供する。装置は、
第１のノードのアイデンティティが信頼されていると決定し、通信ユニットを使用して、第１のアソシエーション要求を前記第１のノードに送信するように構成されている処理ユニットを含む。

通信ユニットは、第１のノードから第１の認証要求を受信するようにさらに構成されている。第１の認証要求には、第１のアイデンティティ認証情報を含む。

処理ユニットは、第２のノードと第１のノードとの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行するようにさらに構成されている。

通信ユニットは、第１のアイデンティティ認証情報に対する検証が成功した場合、第１の認証応答を第１のノードに送信するようにさらに構成されている。第１の認証応答は、第２のアイデンティティ認証情報を含み、第２のアイデンティティ認証情報は、共有鍵に基づいて生成される。

この出願のこの実施形態では、第１のノードのアイデンティティが信頼されていると決定した後に、装置は、第１のアソシエーション要求を第１のノードに送信する。次いで、共有鍵を使用して、第１の認証要求における第１のアイデンティティ認証情報に基づいて、第１のノードのアイデンティティ認証情報に対する検証が実行される。検証が成功した後に、第２のアイデンティティ認証情報が第１のノードに送信される。第２のアイデンティティ認証情報は、第１のノードが装置のアイデンティティを検証するために使用されてもよい。アイデンティティが信頼されていると決定された後に、アソシエーションは、両者のアイデンティティ認証が成功した後にのみ実行され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第２のノードによって実行されるアイデンティティ認証を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第４の態様の可能な実装では、処理ユニットは、具体的には、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うようにさらに構成されている。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、装置は、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第４の態様の別の可能な実装では、処理ユニットは、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うようにさらに構成されている。

第４の態様のさらに別の可能な実装では、第１の認証要求は、第１の完全性検査データをさらに含み、第１の完全性検査データは、第１の認証要求に対してメッセージ完全性検査を実行するために使用される。

処理ユニットは、
第１の認証要求に対するメッセージ完全性検査が成功したと決定するようにさらに構成されている。

第１のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第１のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証する。

第４の態様のさらに別の可能な実装では、処理ユニットは、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第２のアソシエーション閾値が装置に事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、装置にアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、装置は、別のノードにアソシエーションされることができず、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

第４の態様のさらに別の可能な実装では、通信ユニットは、
第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、装置は、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを装置に通知してもよい。

第４の態様のさらに別の可能な実装では、処理ユニットは、
第２の認証失敗カウンタをリセットするようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

第４の態様のさらに別の可能な実装では、処理ユニットは、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第４の態様のさらに別の可能な実装では、処理ユニットは、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、
第１のノードの識別子を第２のブラックリストに追加するようにさらに構成されている。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第４の態様のさらに別の可能な実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続期間は１０日であってもよく、ブラックリストに追加されてから１０日後に、ブラックリストから第１のノードの識別子が削除されてもよい。

第４の態様のさらに別の可能な実装では、処理ユニットは、第２の認証失敗カウンタの値が第２の閾値未満であることを決定するようにさらに構成されている。

通信ユニットは、第１のノードに第２のアソシエーション要求を送信するようにさらに構成されている。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第４の態様のさらに別の可能な実装では、プロセッサは、
第２の認証失敗カウンタの値が第２の閾値より小さいことを決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

第４の態様のさらに別の可能な実装では、プロセッサは、
第２のブラックリストに第１のノードの識別子が追加されている持続期間が第２の持続期間を超える場合、第２のブラックリストから第１のノードの識別子を削除するようにさらに構成されており、第２の持続期間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続期間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

第４の態様のさらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

第５の態様によれば、この出願の実施形態は、通信装置をさらに提供する。装置は、少なくとも１つのプロセッサと、通信インターフェースと、を含み、少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、その結果、装置が、第１の態様又は第１の態様の可能な実装のいずれか１つによる方法を実装する。

第５の態様の可能な実施において、少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、
通信インターフェースを介して第２のノードから第１のアソシエーション要求を受信することと、
第２のノードのアイデンティティが信頼されていると決定し、通信インターフェースを介して第１の認証要求を第２のノードに送信することであって、第１の認証要求は、第１のアイデンティティ認証情報を含み、第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて生成され、共有鍵は、第１のノードと第２のノードとの間で共有される第１の秘密値とみなされ得る、ことと、
通信インターフェースを介して第２のノードから第１の認証応答を受信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含む、ことと、
共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行することと、
第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新することであって、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す、こととを行う動作を実行するように構成されている。

この出願のこの実施形態では、装置は、第２のノードのアイデンティティが信頼されていると決定した後に、第２のノードと共有される共有鍵に基づいて第２のノードのアイデンティティを検証する。このように、攻撃者が、識別子を修正することにより、アイデンティティが装置から信頼されていると決定するステップを避ける場合でも、アイデンティティ認証情報を偽造することが難しいため、攻撃者に対する装置によって実行されるアイデンティ認証は依然としてことができない。したがって、認証されていない攻撃者とのアソシエーションを装置が確立することが防止され、装置のデータ・セキュリティが向上する。

さらに、検証が失敗した場合、装置は、検証失敗の数を更新する。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、装置は、（例えば、認証要求を送信する）ノードのアソシエーション要求をもはや処理しなくてもよく、装置が多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

第５の態様の別の可能な実装では、プロセッサは、具体的には、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている。

装置は、ブラックリスト又はホワイトリストに基づいてアソシエーションを要求するノードを制御し、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これにより、多数の要求の処理による機能停止を防止し、サービスの正常な動作を保証することができる。追加的に、装置は、アイデンティティ認証を受けないノードとのアソシエーションを確立しないため、装置が認証されていない攻撃者とのアソシエーションを確立することが防止され、装置のデータ・セキュリティが向上する。

第５の態様のさらに別の可能な実装では、プロセッサは、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

第５の態様のさらに別の可能な実装では、第１の認証応答は、第２の完全性検査データをさらに含み、第２の完全性検査データは、第１の認証応答に対してメッセージ完全性検査を実行するために使用される。

プロセッサは、第１の認証応答に対するメッセージ完全性検査が成功したと決定するようにさらに構成されている。

第２のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第２のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証する。

第５の態様のさらに別の可能な実装では、プロセッサは、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第１のアソシエーション閾値が装置に事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、ノードによって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、装置は、アソシエーション要求をもはや受信又は処理しなくてもよく、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

第５の態様のさらに別の可能な実装では、プロセッサは、
第２のアイデンティティ認証情報に対する検証が成功した場合、通信インターフェースを介して第１のアソシエーション応答を第２のノードに送信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

第５の態様のさらに別の可能な実装では、プロセッサは、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１の認証失敗カウンタをリセットするようにさらに構成されている。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

第５の態様のさらに別の可能な実装では、プロセッサは、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加するようにさらに構成されている。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第５の態様のさらに別の可能な実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続期間は１週間であってもよく、ブラックリストに追加された１週間後に、ブラックリストから第２のノードの識別子が削除されてもよい。

第５の態様のさらに別の可能な実装では、プロセッサは、
第１のブラックリストに第２のノードの識別子が追加されている持続期間が第１の持続期間を超える場合、第１のブラックリストから第２のノードの識別子を削除するようにさらに構成されており、第１の持続期間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、ブラックリストの有効期間に関連する要因を説明する。ブラックリストの有効期間は、第２のノードがブラックリストに追加された回数に関連してもよい。第２のノードがブラックリストに追加された回数が多いほど、ブラックリストにある第２のノードの持続期間が長くなることを示す。さらに、任意選択で、ブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードがブラックリストに永久的に追加されてもよい。

追加的に、ブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、装置は、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

第５の態様のさらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、装置のリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

第６の態様によれば、この出願の実施形態は、通信装置をさらに提供する。装置は、少なくとも１つのプロセッサと、通信インターフェースと、を含み、少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、その結果、装置が、第１の態様又は第１の態様の可能な実装のいずれか１つによる方法を実装する。

第６の態様の可能な実施において、少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、
第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を第１のノードに送信することと、
第１の認証要求を第１のノードから受信することであって、第１の認証要求は、第１のアイデンティティ認証情報を含む、ことと、
第２のノードと第１のノードとの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行することであって、共有鍵は、第１のノードと第２のノードとの間で共有される秘密の値である、ことと、
第１のアイデンティティ認証情報に対する検証が成功した場合、第１のノードに第１の認証応答を送信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含み、第２のアイデンティティ認証情報は、共有鍵に基づいて生成される、こととを行う動作を実行するように構成されている。

この出願のこの実施形態では、第１のノードのアイデンティティが信頼されていると決定した後に、装置は、第１のアソシエーション要求を第１のノードに送信する。次いで、共有鍵を使用して、第１の認証要求における第１のアイデンティティ認証情報に基づいて、第１のノードのアイデンティティ認証情報に対する検証が実行される。検証が成功した後に、第２のアイデンティティ認証情報が第１のノードに送信される。第２のアイデンティティ認証情報は、第１のノードが装置のアイデンティティを検証するために使用されてもよい。アイデンティティが信頼されていると決定された後に、アソシエーションは、両者のアイデンティティ認証が成功した後にのみ実行され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の装置によって実行されるアイデンティティ認証を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第６の態様の別の可能な実装では、プロセッサは、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うようにさらに構成されている。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、装置は、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第６の態様のさらに別の可能な実装では、プロセッサは、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うようにさらに構成されている。

第６の態様のさらに別の可能な実装では、第１の認証要求は、第１の完全性検査データをさらに含み、第１の完全性検査データは、第１の認証要求に対してメッセージ完全性検査を実行するために使用される。

プロセッサは、第１の認証要求に対するメッセージ完全性検査が成功したと決定するようにさらに構成されている。

第１のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第１のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証する。

第６の態様のさらに別の可能な実装では、プロセッサは、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第２のアソシエーション閾値が装置に事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、装置にアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、装置は、別のノードにアソシエーションされることができず、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

第６の態様のさらに別の可能な実装では、プロセッサは、
第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、装置は、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを装置に通知してもよい。

第６の態様のさらに別の可能な実装では、プロセッサは、
第２の認証失敗カウンタをリセットするようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

第６の態様のさらに別の可能な実装では、プロセッサは、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の装置によって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第６の態様のさらに別の可能な実装では、プロセッサは、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、
第１のノードの識別子を第２のブラックリストに追加するようにさらに構成されている。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードが認証要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第６の態様のさらに別の可能な実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続期間は１０日であってもよく、ブラックリストに追加されてから１０日後に、ブラックリストから第１のノードの識別子が削除されてもよい。

第６の態様のさらに別の可能な実装では、プロセッサは、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

アイデンティティ認証情報を検証する処理において、いくつかのパラメータは伝送プロセスにおいて失われるか又は誤って伝送されるため、アイデンティティ認証情報に対する検証も失敗する可能性があることが理解されよう。したがって、第１のノードの検証失敗の数が事前セットされた第２の閾値を超えない場合、アソシエーション要求は、第１のノードに再送されて、第１のノードとアソシエーションを確立することを要求してもよい。このようにして、システムの頑健性が向上し、装置によって提供されるサービスの安定した動作が保証される。

第６の態様のさらに別の可能な実装では、プロセッサは、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

第６の態様のさらに別の可能な実装では、プロセッサは、
第２のブラックリストに第１のノードの識別子が追加されている持続期間が第２の持続期間を超える場合、第２のブラックリストから第１のノードの識別子を削除するようにさらに構成されており、第２の持続期間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続期間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、装置は、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

第６の態様のさらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

第７の態様によれば、この出願の実施形態は、アソシエーション制御方法をさらに提供する。方法は、
第１のアソシエーション要求を第２のノードから受信することと、
第２のノードのアイデンティティが信頼されていると決定し、第１の認証要求を第２のノードに送信することであって、第１の認証要求は、第１の完全性検査データを含む、ことと、
第２のノードから第１の認証応答を受信することであって、第１の認証応答は、第２の完全性検査データを含む、ことと、
第２の完全性検査データに基づいて、第１の認証応答に対してメッセージ完全性検査を実行することと、
第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１の認証失敗カウンタを更新することであって、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す、ことと、を含む。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定された後に、アソシエーションが実行される前に、第２のノードからの認証応答メッセージに対して、メッセージ完全性検査がさらに実行される必要がある。メッセージ完全性検査が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよく、その結果、攻撃者が認証処理においてデータ（例えば、アイデンティティ認証情報）を改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第７の態様の可能な実装では、第２のノードのアイデンティティが信頼されていると決定することは、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを含む。

前述の方法では、ブラックリスト又はホワイトリストによってアソシエーションを要求するノードが制御されてもよく、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第７の態様の可能な実装では、第２のノードのアイデンティティが信頼されていると決定することは、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを含む。

第７の態様の別の可能な実装では、第２のノードから第１のアソシエーション要求を受信する前に、方法は、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定することであって、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す、ことをさらに含む。

第１のアソシエーション閾値がノードに事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、ノードによって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、ノードは、アソシエーション要求をもはや受信又は処理しなくてもよく、ノードとノードにアソシエーションされた別のノードとの間の通信に影響を与えず、ノードによって提供されるサービスの安定した動作を保証する。

第７の態様のさらに別の可能な実装では、第１の認証応答は、第２のアイデンティティ認証情報をさらに含む。方法は、
第１の認証応答に対する完全性検査が成功した場合、第２のノードと共有される共有鍵に基づいて、第２のアイデンティティ認証情報に対して検証を実行することと、
第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新することであって、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す、こととを含む。

第２のノードのアイデンティティが信頼されていると決定された後、完全性検査が成功した場合、第２のノードと共有される共有鍵に基づいて、第２のノードのアイデンティティに対する検証が実行されることが分かる。検証が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、（例えば、認証要求を送信する）ノードのアソシエーション要求はもはや処理されなくてもよく、ノードが多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

第７の態様のさらに別の可能な実装では、方法は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション応答を第２のノードに送信することであって、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される、ことをさらに含む。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

第７の態様のさらに別の可能な実装では、方法は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１の認証失敗カウンタをリセットすることをさらに含む。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、ノードによって提供されるサービスの安定した動作を保証することが分かる。

第７の態様のさらに別の可能な実装では、方法は、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加することをさらに含む。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第７の態様のさらに別の可能な実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続期間は１週間であってもよく、ブラックリストに追加された１週間後に、ブラックリストから第２のノードの識別子が削除されてもよい。

第７の態様のさらに別の可能な実装では、方法は、
第１のブラックリストに第２のノードの識別子が追加されている持続期間が第１の持続期間を超える場合、第１のブラックリストから第２のノードの識別子を削除することであって、第１の持続期間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する、ことをさらに含む。

前述の実装は、第１のブラックリストの有効期間に関連する要因を説明する。第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続期間が長くなることを示す。さらに、任意選択で、ブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードがブラックリストに永久的に追加されてもよい。

追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。第７の態様のさらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、ノードのリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

第８の態様によれば、この出願の実施形態は、アソシエーション方法をさらに提供する。方法は、
第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を第１のノードに送信することと、
第１の認証要求を前記第１のノードから受信することであって、前記第１の認証要求は、第１の完全性検査データを含む、ことと、
第１の完全性検査データに基づいて、第１の認証要求に対してメッセージ完全性検査を実行することと、
通信ユニット１２０２は、第１の認証要求に対するメッセージ完全性検査が成功した場合、第１の認証応答を第１のノードに送信することと、第１の認証応答は、第２の完全性検査データを含む、ことと、を含む。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定された後に、通信が実行される前に、認証（例えば、アイデンティティ認証情報を使用した検証）が第１のノードに対してさらに実行される必要がある。攻撃者が認証処理においてデータを改ざんすることを防止するために、第１の認証要求に対してメッセージ完全性検査が最初に実行される必要がある。第１のノードとのアソシエーションは、メッセージ完全性検査が成功したときにのみ許可され、その結果、攻撃者がメッセージ・コンテンツを改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第８の態様の可能な実装では、第１のノードのアイデンティティが信頼されていると決定することは、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを含む。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、ノードは、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第８の態様の可能な実装では、第１のノードのアイデンティティが信頼されていると決定することは、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを含む。

第８の態様の別の可能な実装では、第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を第１のノードに送信する前に、方法は、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定することであって、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す、ことをさらに含む。

第２のアソシエーション閾値がノードに事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、ノードにアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、ノードは、別のノードにアソシエーションされることができず、ノードとノードにアソシエーションされた別のノードとの間の通信に影響を与えず、ノードによって提供されるサービスの安定した動作を保証する。

第８の態様のさらに別の可能な実装では、方法は、
第１のノードから第１のアソシエーション応答を受信することであって、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される、ことをさらに含む。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、第２のノードは、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを第２のノードに通知してもよい。

第８の態様のさらに別の可能な実装では、方法は、
第２の認証失敗カウンタをリセットすることであって、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す、ことをさらに含む。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、ノードによって提供されるサービスの安定した動作を保証することが分かる。

第８の態様のさらに別の可能な実装では、方法は、
第１の認証応答に対するメッセージ完全性検査が失敗した場合、第２の認証失敗カウンタを更新することであって、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す、ことをさらに含む。

通常、第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１の認証応答メッセージがもはや完全でないか、攻撃者によって修正されていることを示す。したがって、第１のノードのアイデンティティ検証失敗の数が更新され、検証失敗の数は、第１のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよい。

第８の態様のさらに別の可能な実装では、第１の認証要求メッセージはは、第１のアイデンティティ認証情報をさらに含む。第１の認証応答に対するメッセージ完全性検査が成功した場合、第１の認証応答を送信することは、
第１の認証応答に対するメッセージ完全性検査が成功した場合、第１のノードと共有される共有鍵に基づいて、第１のアイデンティティ認証情報に対して検証を実行することと、
第１のアイデンティティ認証情報に対する検証が成功した場合、第１の認証応答を第１のノードに送信することと、を含む。

第１のノードのアイデンティティが信頼されていると決定された後、完全性検査が成功した場合、第１のノードと共有される共有鍵に基づいて、第１のノードのアイデンティティに対する検証が実行されることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者に対するアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第８の態様のさらに別の可能な実装では、方法は、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新することであって、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す、ことをさらに含む。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、第１のノードのアイデンティティ検証失敗の数が更新され、検証失敗の数は、ノードのアイデンティティ確認が信頼されているかどうかをその後に決定するために使用されてもよく、その結果、複数回検証されなかったノードが、信頼されているともはや決定されなくてもよいことが分かる。信頼されていると決定されないノードに対しては、アソシエーション要求がノードにもはや送信されなくてもよく、ノードによって提供されるサービスの正常な動作を保証する。

第８の態様のさらに別の可能な実装では、方法は、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定することと、
第１のノードの識別子を第２のブラックリストに追加することと、をさらに含む。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードが認証要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第８の態様のさらに別の可能な実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続期間は１０日であってもよく、ブラックリストに追加されてから１０日後に、ブラックリストから第１のノードの識別子が削除されてもよい。

第８の態様のさらに別の可能な実装では、第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新した後に、方法は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第１のノードに第２のアソシエーション要求を送信することと、をさらに含む。

アイデンティティ認証情報を検証する処理において、いくつかのパラメータは伝送プロセスにおいて失われるか又は誤って伝送されるため、アイデンティティ認証情報に対する検証も失敗する可能性があることが理解されよう。したがって、第１のノードの検証失敗の数が事前セットされた第２の閾値を超えない場合、アソシエーション要求は、第１のノードに再送されて、ノードとアソシエーションを確立することを要求してもよい。このようにして、システムの頑健性が向上し、ノードによって提供されるサービスの安定した動作が保証される。

第８の態様のさらに別の可能な実装では、第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新した後に、方法は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、をさらに含む。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

第８の態様のさらに別の可能な実装では、方法は、
第２のブラックリストに第１のノードの識別子が追加されている持続期間が第２の持続期間を超える場合、第２のブラックリストから第１のノードの識別子を削除することであって、第２の持続期間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する、ことをさらに含む。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続期間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。第８の態様のさらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

第９の態様によれば、この出願の実施形態は、アソシエーション制御方法をさらに提供する。装置は、
第２のノードから第１のアソシエーション要求を受信するように構成されている通信ユニットと、
第２のノードのアイデンティティが信頼されていると決定し、通信ユニットを使用して、第１の認証要求を第２のノードに送信するように構成されている処理ユニットであって、第１の認証要求は、第１の完全性検査データを含む、処理ユニットと、を含む。

通信ユニットは、第２のノードから第１の認証応答を受信するようにさらに構成されており、第１の認証応答は、第２の完全性検査データを含む。

処理ユニットは、第２の完全性検査データに基づいて、第１の認証応答に対してメッセージ完全性検査を実行するようにさらに構成されている。

処理ユニットは、第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１の認証失敗カウンタを更新するようにさらに構成されている。第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定した後に、装置は、アソシエーションが実行される前に、第２のノードからの認証応答メッセージに対してメッセージ完全性検査を実行することがさらに必要である。メッセージ完全性検査が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよく、その結果、攻撃者が認証処理においてデータ（例えば、アイデンティティ認証情報）を改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第９の態様の可能な実装では、処理ユニットは、具体的には、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている。

装置は、ブラックリスト又はホワイトリストを使用して、アソシエーションを要求するノードを制御し、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第９の態様の可能な実装では、処理ユニットは、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

第９の態様の別の可能な実装では、処理ユニットは、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第１のアソシエーション閾値が装置に事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、装置によって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、装置は、アソシエーション要求をもはや受信又は処理しなくてもよく、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

第９の態様のさらに別の可能な実装では、処理ユニットは、
第１の認証応答に対する完全性検査が成功した場合、第２のノードと共有される共有鍵に基づいて、第２のアイデンティティ認証情報に対して検証を実行することと、
第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新することであって、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す、こととを行うようにさらに構成されている。

装置は、第２のノードのアイデンティティが信頼されていると決定した後に、完全性検査が成功した場合、第２のノードと共有される共有鍵に基づいて、第２のノードのアイデンティティに対して検証を実行することが分かる。検証が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、（例えば、認証要求を送信する）ノードのアソシエーション要求はもはや処理されなくてもよく、ノードが多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

第９の態様のさらに別の可能な実装では、通信ユニットは、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション応答を第２のノードに送信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

第９の態様のさらに別の可能な実装では、処理ユニットは、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１の認証失敗カウンタをリセットするようにさらに構成されている。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

第９の態様のさらに別の可能な実装では、処理ユニットは、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加するようにさらに構成されている。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第９の態様のさらに別の可能な実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続期間は１週間であってもよく、ブラックリストに追加された１週間後に、ブラックリストから第２のノードの識別子が削除されてもよい。

第９の態様のさらに別の可能な実装では、処理ユニットは、
第１のブラックリストに第２のノードの識別子が追加されている持続期間が第１の持続期間を超える場合、第１のブラックリストから第２のノードの識別子を削除するようにさらに構成されており、第１の持続期間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第１のブラックリストの有効期間に関連する要因を説明する。第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続期間が長くなることを示す。さらに、任意選択で、第１のブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードが第１のブラックリストに永久的に追加されてもよい。

追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

第９の態様のさらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、装置のリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

第１０の態様によれば、この出願の実施形態は、アソシエーション装置をさらに提供する。装置は、
第１のノードのアイデンティティが信頼されていると決定し、通信ユニットを使用して、第１のアソシエーション要求を前記第１のノードに送信するように構成されている処理ユニットを含む。

通信ユニットは、第１のノードから第１の認証要求を受信するようにさらに構成されている。第１の認証要求は、第１のアイデンティティ認証情報及び第１の完全性検査データを含む。

処理ユニットは、第１の完全性検査データに基づいて、第１の認証要求に対してメッセージ完全性検査を実行するようにさらに構成されている。

通信ユニットは、第１の認証要求に対するメッセージ完全性検査が成功した場合、第１の認証応答を第１のノードに送信するようにさらに構成されており、第１の認証応答は、第２の完全性検査データを含む。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定した後、装置は、通信が実行される前に、第１のノードに対する認証（例えば、アイデンティティ認証情報を使用した検証）を実行することがさらに必要である。攻撃者が認証処理においてデータを改ざんすることを防止するために、第１の認証要求に対してメッセージ完全性検査が最初に実行される必要がある。第１のノードとのアソシエーションは、メッセージ完全性検査が成功したときにのみ許可され、その結果、攻撃者がメッセージ・コンテンツを改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第１０の態様の可能な実装では、処理ユニットは、具体的には、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うようにさらに構成されている。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、装置は、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

第１０の態様の可能な実装では、処理ユニットは、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

第９の態様のさらに別の可能な実装では、処理ユニットは、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第２のアソシエーション閾値が装置に事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、装置にアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、装置は、別のノードにアソシエーションされることができず、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

第１０の態様のさらに別の可能な実装では、通信ユニットは、
第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、装置は、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを装置に通知してもよい。

第１０の態様のさらに別の可能な実装では、処理ユニットは、
第２の認証失敗カウンタをリセットするようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

第１０の態様のさらに別の可能な実装では、処理ユニットは、
第１の認証応答に対するメッセージ完全性検査が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

通常、第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１の認証応答メッセージがもはや完全でないか、攻撃者によって修正されていることを示す。したがって、第１のノードの検証失敗の数が更新され、検証失敗の数は、第１のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよい。

第１０の態様のさらに別の可能な実装では、第１の認証要求メッセージはは、第１のアイデンティティ認証情報をさらに含む。処理ユニットは、第１の認証応答に対するメッセージ完全性検査が成功した場合、第１のノードと共有される共有鍵に基づいて、第１のアイデンティティ認証情報に対して検証を実行するようにさらに構成されている。

通信ユニットは、第１のアイデンティティ認証情報に対する検証が成功した場合、第１の認証応答を第１のノードに送信するようにさらに構成されている。

第１のノードのアイデンティティが信頼されていると決定された後、完全性検査が成功した場合、第１のノードと共有される共有鍵に基づいて、第１のノードのアイデンティティに対する検証が実行されることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の装置によって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

第１０の態様のさらに別の可能な実装では、処理ユニットは、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティ確認が信頼されているかどうかをその後に決定するために使用されてもよく、その結果、複数回検証されなかったノードが、信頼されているともはや決定されなくてもよいことが分かる。信頼されていると決定されないノードに対しては、アソシエーション要求がノードにもはや送信されなくてもよく、ノードによって提供されるサービスの正常な動作を保証する。第１０の態様のさらに別の可能な実装では、処理ユニットは、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、
第１のノードの識別子を第２のブラックリストに追加するようにさらに構成されている。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードが認証要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第１０の態様のさらに別の可能な実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続期間は１０日であってもよく、ブラックリストに追加されてから１０日後に、ブラックリストから第１のノードの識別子が削除されてもよい。

第１０の態様のさらに別の可能な実装では、処理ユニットは、第２の認証失敗カウンタの値が第２の閾値未満であることを決定するようにさらに構成されている。

通信ユニットは、第１のノードに第２のアソシエーション要求を送信するようにさらに構成されている。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

第１０の態様のさらに別の可能な実装では、処理ユニットは、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

第１０の態様のさらに別の可能な実装では、処理ユニットは、
第２のブラックリストに第１のノードの識別子が追加されている持続期間が第２の持続期間を超える場合、第２のブラックリストから第１のノードの識別子を削除するようにさらに構成されており、第２の持続期間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプに関連する。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続期間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。第１０の態様のさらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

第１１の態様によれば、この出願の実施形態は、通信装置をさらに提供する。通信装置は、少なくとも１つのプロセッサと、通信インターフェースと、を含み、少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、その結果、装置が、第７の態様又は第７の態様の可能な実装のいずれか１つによる方法を実装する。

第１２の態様によれば、この出願の実施形態は、通信装置をさらに提供する。装置は、少なくとも１つのプロセッサと、通信インターフェースと、を含み、少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、その結果、装置が、第８の態様又は第８の態様の可能な実装のいずれか１つによる方法を実装する。

第１３の態様によれば、この出願の実施形態は、通信システムをさらに提供する。通信システムは、第１のノード及び第２のノードを含む。第１のノードは、第３の態様若しくは第３の態様の可能な実装のうちのいずれか１つ、又は第５の態様若しくは第５の態様の可能な実装のうちのいずれか１つに記載の装置である。第２のノードは、第４の態様若しくは第４の態様の可能な実装のうちのいずれか１つ、又は第６の態様若しくは第６の態様の可能な実装のうちのいずれか１つに記載の装置である。

第１４の態様によれば、この出願の実施形態は、通信システムをさらに提供する。通信システムは、第１のノード及び第２のノードを含む。第１のノードは、第９の態様若しくは第９の態様の可能な実装、又は第１１の態様のうちのいずれか１つに記載の装置である。第１のノードは、第１０の態様若しくは第１０の態様の可能な実装、又は第１２の態様のうちのいずれか１つに記載の装置である。

第１５の態様によれば、この出願の一実施形態は、コンピュータ可読記憶媒体を開示する。コンピュータ可読記憶媒体は、コンピュータ・プログラムを記憶する。コンピュータ・プログラムが１つ以上のプロセッサ上で動作するときに、第１の態様若しくは第１の態様の可能な実装のいずれか１つによる方法、第２の態様若しくは第２の態様の可能な実装のいずれか１つによる方法、第７の態様若しくは第７の態様の可能な実装のいずれか１つによる方法、又は第８の態様若しくは第８の態様の可能な実装のいずれか１つによる方法が実行される。

第１６の態様によれば、この出願の一実施形態は、チップ・システムを開示する。チップ・システムは、少なくとも１つのプロセッサ、メモリ、及びインターフェース回路を含む。インターフェース回路は、少なくとも１つのプロセッサに情報の入力／出力を提供するように構成されており、メモリは、コンピュータ・プログラムを記憶し、コンピュータ・プログラムが１つ以上のプロセッサ上で動作するときに、第１の態様若しくは第１の態様の可能な実装のいずれか１つによる方法、第２の態様若しくは第２の態様の可能な実装のいずれか１つによる方法、第７の態様若しくは第７の態様の可能な実装のいずれか１つによる方法、又は第８の態様若しくは第８の態様の可能な実装のいずれか１つによる方法が実行される。

第１７の態様によれば、この出願の一実施形態は、車両を開示する。車両は、第１のノード（例えば、車両コックピット・ドメイン・コントローラＣＤＣ）を含む。第１のノードは、第３の態様若しくは第３の態様の可能な実装のうちのいずれか１つ、又は第５の態様若しくは第５の態様の可能な実装のうちのいずれか１つに記載の装置である。さらに、車両は、第２のノード（例えば、カメラ、スクリーン、マイクロホン、スピーカ、レーダ、電子キー、受動入力受動スタート・システム・コントローラなどのモジュールのうちの少なくとも１つ）を含む。第２のノードは、第４の態様若しくは第４の態様の可能な実装のうちのいずれか１つ、又は第６の態様若しくは第６の態様の可能な実装のうちのいずれか１つに記載の装置である。

第１８の態様によれば、この出願の一実施形態は、車両を開示する。車両は、第１のノード（例えば、車両コックピット・ドメイン・コントローラＣＤＣ）を含む。第１のノードは、第９の態様若しくは第９の態様の可能な実装、又は第１１の態様のうちのいずれか１つに記載の装置である。さらに、車両は、第２のノード（例えば、カメラ、スクリーン、マイクロホン、スピーカ、レーダ、電子キー、受動入力受動スタート・システム・コントローラなどのモジュールのうちの少なくとも１つ）を含む。第１のノードは、第１０の態様若しくは第１０の態様の可能な実装、又は第１２の態様のうちのいずれか１つに記載の装置である。

以下、この出願の実施形態で使用される添付の図面を記載する。

この出願の一実施形態による、通信システムのアーキテクチャの概略図である。

この出願の一実施形態による、アソシエーション制御方法のアプリケーション・シナリオの概略図である。

この出願の一実施形態による、アソシエーション制御方法の概略フローチャートである。

この出願の一実施形態によるブラックリスト及びホワイトリストの概略図である。

この出願の一実施形態による別のアソシエーション制御方法の概略フローチャートである。 この出願の一実施形態による別のアソシエーション制御方法の概略フローチャートである。 この出願の一実施形態による別のアソシエーション制御方法の概略フローチャートである。

この出願の一実施形態による、さらに別のアソシエーション制御方法の概略フローチャートである。 この出願の一実施形態による、さらに別のアソシエーション制御方法の概略フローチャートである。 この出願の一実施形態による、さらに別のアソシエーション制御方法の概略フローチャートである。

この出願の一実施形態による、さらに別のアソシエーション制御装置の構造の概略図である。

この出願の一実施形態による、さらに別のアソシエーション装置の構造の概略図である。

この出願の一実施形態による、通信装置の構造の概略図である。

この出願の一実施形態による、他の通信装置の構造の概略図である。

この出願の一実施形態による、アソシエーション制御装置の構造の概略図である。

この出願の一実施形態による、別のアソシエーション装置の構造の概略図である。

この出願の一実施形態による、さらに別の通信装置の構造の概略図である。

この出願の一実施形態による、さらに別の通信装置の構造の概略図である。

以下、この出願の実施態様における添付図面を参照して、この出願の実施形態を記載する。本出願において、「例」、「例えば」などの語は、例、例示又は説明を与えることを表すために使用されることに留意されたい。この出願において「例」又は「例えば」を使用して記載される実施形態又は設計解決策は、他の実施形態又は設計解決策よりも好ましいか、又はより有利であると解釈されないものとする。「例」、「例えば」のような語の使用は、関連概念を特定の方式で提示することを意図している。

以下、最初に理解を容易にするためにこの出願の関連技術及び技術用語を簡単に記載する。

１．ノード（ｎｏｄｅ）

ノードは、データの受信及び送信能力を有する電子デバイスである。例えば、ノードは、車両コックピット・ドメイン（Ｃｏｃｋｐｉｔ Ｄｏｍａｉｎ）デバイス、又は車両コックピット・ドメイン・デバイス内のモジュール（例えば、コックピット・ドメイン・コントローラ、（ｃｏｃｋｐｉｔ ｄｏｍａｉｎ ｃｏｎｔｒｏｌｌｅｒ、ＣＤＣ）、カメラ、スクリーン、マイクロホン、サウンダ、電子キー、受動エントリ受動スタート・システム・コントローラなどのモジュールのうちの１つ以上）であってもよい。特定の実装プロセスでは、ノードは、ルータ、中継器、ブリッジ、スイッチなどのデータ・トランジット・デバイスであってもよいし、様々なタイプのユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ、ＵＥ）、携帯電話（ｍｏｂｉｌｅ ｐｈｏｎｅ）、タブレット・コンピュータ（ｐａｄ）、デスクトップ・コンピュータ、ヘッドセット、スピーカなどの端末デバイスであってもよいし、自走（ｓｅｌｆ－ｄｒｉｖｉｎｇ）デバイス、輸送安全（ｔｒａｎｓｐｏｒｔａｔｉｏｎ ｓａｆｅｔｙ）デバイス、仮想現実（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ、ＶＲ）端末デバイス、拡張現実（ａｕｇｍｅｎｔｅｄ ｒｅａｌｉｔｙ、ＡＲ）端末デバイス、機械タイプ通信（ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＭＴＣ）デバイス、工業制御（ｉｎｄｕｓｔｒｉａｌ ｃｏｎｔｒｏｌ）デバイス、遠隔医療（ｒｅｍｏｔｅ ｍｅｄｉｃａｌ）デバイス、スマートグリッド（ｓｍａｒｔ ｇｒｉｄ）デバイス、スマートシティ（ｓｍａｒｔ ｃｉｔｙ）デバイスなどの機械インテリジェントを含んでもよいし、ウェアラブル・デバイス（スマートウォッチ、スマート・バンド、歩数計など）などを含んでもよい。いくつかの技術的シナリオでは、同様のデータ受信及び送信能力を有するデバイスの名前は「ノード」でなくてもよい。しかしながら、説明を容易にするために、データ受信及び送信能力を有する電子デバイスは、この出願の実施形態においてまとめてノードと呼ばれる。

２．共有鍵（ｓｈａｒｅｄ ｋｅｙ、ＳＫ）

通信プロセスでは、データは、通信ノード間で伝送される。データを秘密に保持する必要がある場合、鍵を使用してデータが暗号化される必要がある。共有鍵は、両方の通信パーティのノードに記憶された同じ秘密値である。共有鍵は、両方の通信パーティのノードにおいて事前定義又は事前設定されていてもよいし、同じ鍵取得方法を使用して両方の通信パーティによって生成されてもよいし、信頼されているデバイス（ＫＤＣなど）によって第１のノード及び第２のノードに送信されてもよい。

例えば、車両のコックピット・ドメイン・コントローラ（ｃｏｃｋｐｉｔ ｄｏｍａｉｎ ｃｏｎｔｒｏｌｌｅｒ、ＣＤＣ）及び車両搭載レーダ・デバイスは、互いに通信できる２つのノードである。ＣＤＣ及び車両搭載レーダを展開するときに、自動車工場の作業員は、ＣＤＣと車両搭載レーダの間に共有鍵を事前設定している。共有鍵を使用して、車両のＣＤＣと車両搭載レーダとの間の通信のセキュリティが保証され得る。

例えば、車両のコックピット・ドメイン・コントローラ（ｃｏｃｋｐｉｔ ｄｏｍａｉｎ ｃｏｎｔｒｏｌｌｅｒ、ＣＤＣ）及び車両の所有者の携帯電話は、互いに通信できる２つのノードである。車両所有者が携帯電話を使用して車両のＣＤＣにアソシエーションされる必要があるときに、車両所有者は、鍵取得方法を使用して共有鍵を取得してもよい。例えば、鍵は、鍵合意アルゴリズムを使用して、携帯電話と車両のＣＤＣとの間で鍵合意アルゴリズム・パラメータを交換することによって生成される。その後、携帯電話が再び車両のＣＤＣにアソシエーションされることを要求するときに、共有鍵が、２つのノードのアイデンティティを検証するために使用されてもよい。

３．鍵導出

鍵導出は、１つの秘密値から１つ以上の秘密値を導出するプロセスである。鍵を導出するために使用されるアルゴリズムは、鍵導出関数（ｋｅｙ ｄｅｒｉｖａｔｉｏｎ ｆｕｎｃｔｉｏｎ、ＫＤＦ）と呼ばれ、鍵導出アルゴリズムとも呼ばれる。例えば、秘密値Ｋｅｙから導出された新しい秘密値ＤＫは、ＤＫ＝ＫＤＦ（Ｋｅｙ）のように表されてもよい。

共通鍵導出アルゴリズムは、パスワードベースの鍵導出機関数（ｐａｓｓｗｏｒｄ－ｂａｓｅｄ ｋｅｙ ｄｅｒｉｖａｔｉｏｎ ｆｕｎｃｔｉｏｎ、ＰＢＫＤＦ）、スクリプト（ｓｃｒｙｐｔ）アルゴリズムなどを含む。ＰＢＫＤＦアルゴリズムはさらに、第一世代ＰＢＫＤＦ１及び第二世代ＰＢＫＤＦ２を含む。任意選択で、いくつかのＫＤＦアルゴリズムの場合、鍵導出プロセスにおいて、入力された秘密値に対してハッシュ変更を実行するためにハッシュアルゴリズムが使用される。したがって、ＫＤＦ関数において、アルゴリズム識別子は、使用されるべき特定のハッシュアルゴリズムを示すために、入力としてさらに受信されてもよい。

追加的に、この出願の実施形態において言及される「認証」、「検査」及び「検証」は、検査が正確であるかどうか、又は合理的であるかどうかを意味し得ることに留意されたい。この出願の実施形態では、「アソシエーション」は、第１のノードが第２のノードへの接続を確立するプロセスを示す。特定の技術的シナリオでは、「アソシエーション」は、代替的に「アクセス」と記載されることがある。

以下に、この出願の実施形態におけるシステム・アーキテクチャ及びサービス・シナリオを記載する。この出願に記載のシステム・アーキテクチャ及びサービス・シナリオは、この出願の技術的解決策をより明確に記載することを意図しており、この出願に提供される技術的解決策に対する制限を構成しないことに留意されたい。当業者は、システム・アーキテクチャの進化及び新しいサービス・シナリオの出現に伴い、この出願に提供される技術的解決策が同様の技術的課題にも適用可能であると知っていてもよい。

図１は、この出願の一実施形態による、通信システムのアーキテクチャの概略図である。通信システムは、第１のノード１０１及び第２のノード１０２を含む。第２のノード２０２は、第１のノード１０１とアソシエーションされることを要求してもよい。アソシエーションが成功した後に、第１のノード１０１は、データ・リンクを介して第２のノード１０２と通信してもよい。任意選択で、第１のノード１０１と第２のノード１０２との間の通信に使用されるデータ・リンクは、様々なタイプの接続媒体、例えば、無線フィデリティ（ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ、Ｗｉ－Ｆｉ）技術、ブルートゥース、ジグビー（ｚｉｇｂｅｅ）技術、別の無線リンク（例えば、ユニバーサル無線近距離伝送技術）などを含んでもよい。別の例として、データ・リンクは、ファイバ・リンクのような有線リンクである。

任意選択で、第１のノード１０１は、通信イニシエータであってもよく、プライマリ・ノード又はアクセス・ポイント（ａｃｃｅｓｓ ｐｏｉｎｔ、ＡＰ）と呼ばれることがある。これに対応して、第２のノード１０２は、通信受信機であり、セカンダリ・ノードと呼ばれることがある。

第１のノード１０１及び第２のノード１０２は、同じタイプのデバイスであってもよいし、異なるタイプのデバイスであってもよい。図２は、この出願の一実施形態による、アソシエーション制御方法のアプリケーション・シナリオの概略図である。コックピット・ドメイン・コントローラ（コックピット・ドメイン・コントローラ、ＣＤＣ）２０１は、スマート・コックピット・デバイス内の制御センタであり、第１のノード１０１とみなされてもよい。スマートフォン２０２は、データの送信及び受信能力を有するデバイスであり、第２のノード１０２とみなされてもよい。ＣＤＣ２０１は、ブルートゥースを介して別のブルートゥース・デバイスとアソシエーションされてもよい。スマートフォン２０２は、ブルートゥース機能をサポートするため、ＣＤＣ２０１にアソシエーションされることを要求してもよい。

既存の通信プロセスでは、ノードは攻撃者からの攻撃に対して脆弱である。例えば、攻撃者は、第２のノードのアイデンティティを偽造し、第１のノードにアソシエーションされることを要求することがある。攻撃者が第１のノードにアソシエーションされることに成功した場合、第１のノードのデータ・セキュリティが脅かされる。特に、車両通信プロセスでは、ＣＤＣ２０１が攻撃者のアソシエーションを受信する場合、車両データが容易に漏洩し、攻撃者によって攻撃されることさえあり、運転の安全性を危うくする。別の例では、攻撃者は、ノードに多数の要求フレームを送信する。ノードが多数の要求フレームを受信し、ノードが負うことができる処理能力を超えるときに、ノードは機能停止し、正常なサービスを提供し続けることができなくなり、これは、別のノードとノードとの間の通信に影響を与える。この問題を解決するために、この出願の実施形態は、以下のアソシエーション制御方法を提供する。

図３は、この出願の一実施形態による、アソシエーション制御方法の概略フローチャートである。アソシエーション制御方法は、図１に示す通信システムに基づいて実装されてもよい。方法は、少なくとも以下のステップを含む。

ステップＳ３０１：第２のノードは、第１のノードのアイデンティティが信頼されていると決定する。

具体的には、第２ノードは、少なくとも以下の３つの方法を使用して、第１ノードのアイデンティティが信頼されることを決定してもよい。

方法１：ブラックリスト及び／又はホワイトリストを使用して、第１のノードのアイデンティティが信頼されていると決定する。

図４は、この出願の一実施形態によるブラックリスト及びホワイトリストの概略図である。ブラックリスト４０１及びホワイトリスト４０２は、複数のノードの識別子を記憶する。ノードの識別子は、識別情報（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ、ＩＤ）、メディア・アクセス制御（ｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ、ＭＡＣ）アドレス、ドメイン名、ドメイン・アドレス、又はノードの別のユーザ定義識別子であってもよい。例えば、ブラックリスト４０１にある識別子「００－００－００－ＡＡ－ＡＡ－ＡＡ」はノードの識別子である。任意選択で、ブラックリストは、ノードの識別子の追加時刻、満了時刻、ブラックリストに追加された時間などのうちの１つ以上をさらに含んでもよい。これに対応して、ホワイトリストは、ノードの識別子の追加時刻、満了時刻、キー設定タイプなどのうちの１つ以上を含んでもよい。説明を容易にするために、この出願の実施形態では、第２のノードにおけるブラックリストは、第２のブラックリストと呼ばれ、第２のノードにおけるホワイトリストは、第２のホワイトリストと呼ばれる。ノードの識別子は、第２のホワイトリスト及び第２のブラックリストの両方にあることはできないことが理解されよう。

第２のノードは、第１のノードの識別子が第２のホワイトリストにあるか、第２のブラックリストにあるかを決定することによって、第１のノードのアイデンティティが信頼されているかどうかを決定してもよい。具体的には、以下の３つの実装があってもよい。

実装１：第１のノードの識別子が第２のホワイトリストにあると第２のノードが決定する場合、第１のノードのアイデンティティが信頼されていることを示してもよい。

実装２：第１のノードの識別子が第２のブラックリストにないと第２のノードが決定する場合、第１のノードのアイデンティティが信頼されていることを示してもよい。

任意選択で、第２のノードは、入力情報を取得することによって第１のノードの識別子を取得するか、又は第１のノードによってブロードキャストされたメッセージを受信することによって第１のノードの識別子を取得してもよい。例えば、第１のノードはメッセージをブロードキャストしてもよく、ブロードキャスト・メッセージは第１のノードの識別子を含んでもよい。第２のノードは、ブロードキャスト・メッセージを受信した後に、第１のノードの識別子、第２のブラックリスト又は第２のホワイトリストに基づいて、第１のノードのアイデンティティが信頼されているかどうかを決定してもよい。任意選択で、第２のノードは、１つ以上の他のノードの識別子と鍵設定タイプとの間の対応を記憶し、鍵設定タイプは、事前設定タイプ及びパスワード生成タイプであってもよい。事前設定タイプは、第１のノードと第２のノードとの間の共有鍵が事前設定又は事前定義されていることを示す。例えば、車両を組み立てるときに、ホスト工場の作業者が、ＣＤＣとマイクロホンとの間の共有鍵を事前設定する。パスワード生成タイプは、「パスワード・アクセス・タイプ」とも呼ばれ、アソシエーションがパスワード・アクセス方式で確立されたときに、第１のノードと第２のノードとの間の共有鍵がパスワードに基づいて生成された共有鍵であることを示す。さらに、異なる鍵設定タイプのノードは、アイデンティティが信頼されていることを決定する異なる方式を有してもよい。具体的には、以下の２つの実装がさらに含まれる。

実装３：鍵設定タイプが事前設定である第１のノードの場合、第１のノードの識別子が第２のホワイトリストにあると決定される場合、ノードのアイデンティティが信頼されていることを示す。任意選択で、第１のノードの識別子が第２のブラックリストにある場合、第１のノードのアイデンティティが信頼されていないことを示す。例えば、表１は、この出願の実施形態によるノード識別子と鍵設定タイプとの間の可能な対応を示す。識別子が「６６－６６－６６－ＦＦ－ＦＦ－ＦＦ」であるノードＡ１がアソシエーションを要求する場合、ノードＡ１の鍵設定タイプが事前設定タイプであり、ノードＡ１の識別子がホワイトリスト４０２にあることがホワイトリスト４０２を参照することによって分かるため、ノードＡ１のアイデンティティが信頼されていると決定され得る。

実装４：鍵設定タイプがパスワード生成である第１のノードの場合、第１のノードの識別子が第２ブラックリストにないと確認される場合、第１のノードのアイデンティティが信頼されていることを示す。例えば、図１を参照のこと。識別子が「７７－７７－７７－ＧＧ－ＧＧ－ＧＧ」であるノードＡ２がアソシエーションを要求する場合、ノードＡ２の鍵設定タイプがパスワード生成タイプであり、ノードＡ２の識別子がブラックリスト４０１にないことが図４を参照することによって分かるため、ノードＡ２のアイデンティティが信頼されていると決定され得る。

方法２：第２の確認応答表示情報を取得することにより、第１のノードのアイデンティティが信頼されていると決定する。

第２のノードは、第２の確認応答表示情報を取得する。第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されていることを示す。第２の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、以下のような実装がある。

実装５：第２のノードは、第２のプロンプト情報を出力して、第２のノードが第１のノードにアソシエーションされることを要求する必要があることをユーザにリマインドする。第２のノードは、ユーザの確認応答動作を受信し、第２の確認応答表示情報を取得した後に、第１のノードのアイデンティティが信頼されていると決定してもよい。さらに、任意選択で、第２のプロンプト情報を出力した後に第２のノードがユーザの拒否動作を受信した場合、第２のノードは、第１のノードのアイデンティティが信頼されていないと決定してもよい。

方法３：ブラックリスト及び／又はホワイトリスト及び確認応答表示情報を使用して、第１のノードのアイデンティティが信頼されていると決定する。

ブラックリスト及びホワイトリストを使用して、第１のノードのアイデンティティが信頼されているかどうかを決定することができないときに、第２のノードは、確認応答表示情報を使用して、第１のノードのアイデンティティが信頼されていると決定してもよい。具体的には、第１のノードの識別子が第２のブラックリストにないとき、又は第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないときに、第２の確認応答表示情報が取得される。第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されていることを示す。任意選択で、特定の実装プロセスでは、異なる鍵設定タイプが、異なる処理にさらに対応してもよい。例えば、以下のような実装がある。

実装６：鍵設定タイプがパスワード生成である第１のノードの場合、第１のノードの識別子が第２のブラックリスト又は第２のホワイトリストにない場合、第２の確認応答表示情報が取得される。確認応答表示情報は、第１のノードのアイデンティティが信頼されていることを示す。任意選択で、第２の確認応答表示情報が取得されない場合、第２のノードのアイデンティティが信頼されていないと決定されてもよい。

任意選択で、第２のノードは、第２のアソシエーション閾値を事前定義又は設定してもよい。第２のアソシエーション閾値は、現在アソシエーションされているノードの数を示すために使用される。第２のノードは、第１のノードのアイデンティティが信頼されていると決定する前又は後に、第２のノードのアソシエーション数を決定してもよいし、周期的又は非周期的に第２のノードのアソシエーション数を決定してもよい。すなわち、方法は、第２のノードに現在アソシエーションされているノードの数が第２のアソシエーション閾値以下（又は未満）であるかどうかを決定することか、又は第２のノードに現在アソシエーションされているノードの数が第２のアソシエーション閾値より大きい（又はそれ以上）であるかどうかを決定することを含む。現在アソシエーションされているノードの数が第２のアソシエーション閾値より大きい（又はそれ以上）場合、第２のノードは、第１のノードにアソシエーション要求を送信しなくてもよいし、又はその後、第１のノードとのアソシエーションをキャンセルして、第２のノードと別のノードとの間の通信に影響を与えず、第２のノードによって提供されるサービスの安定した動作を保証する。

ステップＳ３０２：第２のノードは、第１のアソシエーション要求を第１のノードに送信する。

具体的には、第２のノードは、第１のアソシエーション要求メッセージを、無線リンク（例えば、Ｗｉ－Ｆｉ、ブルートゥース、ジグビー、又は他の近距離無線リンクのうちの１つ）又は有線リンク（例えば、光ファイバ）を介して第１のノードに送信してもよい。

これに対応して、第１のノードは、第２のノードから第１のアソシエーション要求を受信する。任意選択で、第１のノードは、第１のアソシエーション閾値を事前定義又は設定してもよい。第１のアソシエーション閾値は、現在アソシエーションされているノードの数を示すために使用される。第１のノードは、第２のノードから第１のアソシエーション要求メッセージを受信する前又は後に第１のノードに現在アソシエーションされているノードの数を決定してもよいし、周期的又は非周期的に第１のノードに現在アソシエーションされているノードの数を決定してもよい。すなわち、方法は、第１のノードに現在アソシエーションされているノードの数が第１のアソシエーション閾値以下（又は未満）であるかどうかを決定することか、又は第１のノードに現在アソシエーションされているノードの数が第１のアソシエーション閾値より大きい（又はそれ以上）であるかどうかを決定することを含んでもよい。第１のアソシエーション閾値は、第１のノードによって提供され得るサービスの支持容量を制限してもよい。第１のノードにアソシエーションされているノードの数が第１のアソシエーション閾値より大きい（又はそれ以上）場合、第１のノードはもはやアソシエーション要求を受信又は処理しなくてもよく、したがって、第１のアソシエーション要求を受信又は処理せず、第１のノードと別のアソシエーションされているノードとの間の通信に影響を与えず、第１のノードによって提供されるサービスの安定した動作を保証する。

任意選択で、第１のアソシエーション要求メッセージは、第２のノードのアイデンティティ、第２のノードによって取得される（又は生成される）フレッシュ・パラメータなどのうちの少なくとも１つを含んでもよい。フレッシュ・パラメータは、ナンス（ｎｕｍｂｅｒ ｏｎｃｅ、ＮＯＮＣＥ）、カウンタ（ｃｏｕｎｔｅｒ）、シーケンス番号（ｎｕｍｂｅｒ）などのうちの少なくとも１つを含んでもよい。説明を容易にするために、第１のアソシエーション要求メッセージ内のフレッシュ・パラメータが、第１のフレッシュ・パラメータと呼ばれる。

ステップＳ３０３：第１のノードは、第２のノードのアイデンティティが信頼されていると決定する。

具体的には、第１のノードは、第２のノードのアイデンティティが少なくとも以下の３つの方式で信頼されていると決定してもよい。

方法１：ブラックリスト及び／又はホワイトリストを使用して、第２のノードのアイデンティティが信頼されていると決定する。

説明を容易にするために、この出願の実施形態では、第１のノードにおけるブラックリストは、第１のブラックリストと呼ばれ、第１のノードにおけるホワイトリストは、第１のホワイトリストと呼ばれる。第１のノードにおいて、ノードの識別子は、第１のホワイトリスト及び第１のブラックリストの両方にあることはできないことが理解されよう。

第１のノードは、第２のノードの識別子が第１のホワイトリストにあるか、第１のブラックリストにあるかを決定することによって、第２のノードのアイデンティティが信頼されているかどうかを決定してもよい。具体的には、以下の２つのケースがあってもよい。

ケース１：第２のノードの識別子が第１のホワイトリストにあると第１のノードが決定する場合、第２のノードのアイデンティティが信頼されていることを示してもよい。

ケース２：第２のノードの識別子が第１のブラックリストにないと第１のノードが決定する場合、第２のノードのアイデンティティが信頼されていることを示してもよい。任意選択で、第２のノードの識別子が第１のブラックリストにある場合、第２のノードのアイデンティティが信頼されていないことを示してもよく、第１のノードは第１のアソシエーション要求を破棄するか、又は要求を無視してその後のステップをスキップしてもよい。

任意選択で、第１のアソシエーション要求メッセージは、第２のノードの識別子を含み、第１のノードは、第１のアソシエーション要求メッセージを受信することによって、第２のノードの識別子を取得してもよい。

任意選択で、第１のノードは、１つ以上の他のノードの識別子と鍵設定タイプとの間の対応を記憶し、鍵設定タイプは、事前設定タイプ及びパスワード生成タイプであってもよい。事前設定タイプは、第１のノードと第２のノードとの間の共有鍵が事前設定又は事前定義されていることを示す。例えば、車両を組み立てるときに、ホスト工場の作業者が、ＣＤＣとマイクロホンとの間の共有鍵を事前設定する。パスワード生成タイプは、アソシエーションがパスワード・アクセス方式で確立された後に、第１のノードと第２のノードとの間の共有鍵がパスワードに基づいて生成された共有鍵であることを示す。さらに、異なる鍵設定タイプのノードは、アイデンティティが信頼されていることを決定する異なる方式を有してもよい。特定の実装の間、以下の２つのケースがあってもよい。

ケース３：鍵設定タイプが事前設定である第２のノードの場合、第２のノードの識別子が第１のホワイトリストにあると決定される場合、第２のノードのアイデンティティが信頼されていることを示す。

事例４：鍵設定タイプがパスワード生成である第２のノードの場合、第２のノードの識別子が第１のブラックリストにないと決定される場合、ノードのアイデンティティが信頼されていることを示す。任意選択で、ノードの識別子が第１のブラックリストにある場合、第２のノードのアイデンティティが信頼されておらず、第１のノードは第１のアソシエーション要求を破棄するか、又は要求を無視してその後のステップをスキップしてもよい。

方式２：第１の確認応答表示情報を取得することにより、第２のノードのアイデンティティが信頼されていると決定する。

第１のノードは、第１の確認応答表示情報を取得する。第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されていることを示す。具体的には、第１の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、以下のようなケースがある。

ケース５：第１のノードは、第１のプロンプト情報を出力して、第２のノードがアソシエーションされる必要があることユーザにリマインドする。第１のノードは、ユーザの確認応答動作を受信し、第１の確認応答表示情報を取得した後に、第２のノードのアイデンティティが信頼されていると決定してもよい。さらに、任意選択で、第１のプロンプト情報を出力した後に第１のノードがユーザの拒否動作を受信する場合、第１のノードは、第２のノードのアイデンティティが信頼されていないと決定してもよく、第１のノードは、第１のアソシエーション要求を破棄するか、又は要求を無視して、その後のステップをスキップしてもよい。

方式３：ブラックリスト及び／又はホワイトリスト及び確認応答表示情報を使用して、第２のノードのアイデンティティが信頼されていると決定する。

ブラックリスト及びホワイトリストを使用して、第２のノードのアイデンティティが信頼されているかどうかを決定することができないときに、第１のノードは、確認応答表示情報を使用して、第２のノードのアイデンティティが信頼されていると決定してもよい。具体的には、第２のノードの識別子が第１のブラックリストにないとき、又は第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないときに、第２の確認応答表示情報が取得される。第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されていることを示す。任意選択で、特定の実装プロセスにおいて、異なる鍵設定タイプが、異なる処理にさらに対応してもよい。例えば、以下のようなケースがある。

ケース６：鍵設定タイプがパスワード生成である第２のノードの場合、第２のノードの識別子が第１のブラックリスト又は第１のホワイトリストにない場合、第１の確認応答表示情報が取得される。確認応答表示情報は、第２のノードのアイデンティティが信頼されていることを示す。任意選択で、第１の確認応答表示情報が取得されない場合、第２のノードのアイデンティティが信頼されていないと決定されてもよく、第１のノードは第１のアソシエーション要求を破棄するか、又は要求を無視してその後のステップをスキップしてもよい。

ステップＳ３０４：第１のノードは、第１の認証要求を第２のノードに送信する。

具体的には、第１の認証要求は、第１のアイデンティティ認証情報を含んでもよい。第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて、第１のノードによって生成される。共有鍵は、第１のノードと第２のノードの間の事前共有鍵ＰＳＫであってもよい。

例えば、第１のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫに基づいて、第１のアイデンティティ認証情報ＡＵＴＨａを生成してもよい。例えば、ＡＵＴＨａ＝ＫＤＦ（ＰＳＫ）である。

任意選択で、第１のアソシエーション要求が第１のフレッシュ・パラメータを含むときに、第１のアイデンティティ認証情報は、共有鍵及び第１のフレッシュ・パラメータに基づいて第１のノードによって生成されてもよい。例えば、第１のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫ及び第１のフレッシュ・パラメータＮＯＮＣＥｅに基づいて、第１のアイデンティティ認証情報ＡＵＴＨａを生成する。例えば、ＡＵＴＨａ ＝ ＫＤＦ（ＰＳＫ，ＮＯＮＣＥｅ）である。

任意選択で、実際の処理の間、第１のアイデンティティ認証情報を生成するために第１のノードによって使用されるパラメータは、他の情報をさらに含んでもよい。例えば、生成された第１のアイデンティティ認証情報ＡＵＴＨａは、ＡＵＴＨａ＝ＫＤＦ（ＰＳＫ，第１のアソシエーション要求）を満たしてもよい。

任意選択で、第１の認証要求は、第２のフレッシュ・パラメータをさらに含む。第２のフレッシュ・パラメータは、第２のノードによって取得（又は生成）される乱数、ナンス（ｎｕｍｂｅｒ ｏｎｃｅ、ＮＯＮＣＥ）、カウンタ（ｃｏｕｎｔｅｒ）、シーケンス番号（ｎｕｍｂｅｒ）などのうちの少なくとも１つであってもよい。さらに、任意選択で、第１の認証要求が第２のフレッシュ・パラメータを含むときに、第１のノードによって生成される第１のアイデンティティ認証情報ＡＵＴＨａは、ＡＵＴＨａ＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥａ，第１のアソシエーション要求）をさらに満たしてもよく、ＮＯＮＣＥａは、第１の認証要求の第２のフレッシュ・パラメータである。

任意選択で、第１の認証要求は、第１の完全性検査データなどを含んでもよい。第１の完全性検査データは、対称鍵及び完全性保護アルゴリズムに従って生成される検査データであり、第２のノードが第１の認証要求に対してメッセージ完全性検査を実行するために使用される。特定の実装の間、検査データは、メッセージ認証コード（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉａｔｉｏｎ ｃｏｄｅ、ＭＡＣ）とも呼ばれてもよい。

ステップＳ３０５：第２のノードは、第２のノードと第１のノードとの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行する。

具体的には、第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて、第１のノードによって生成される。したがって、第２のノードも共有鍵を持ち、共有鍵に基づいて、第１のアイデンティティ認証情報が正しいかどうかを検証してもよい。

任意選択の解決策では、プロトコル仕様に従って、第１のノードが第１のアイデンティティ認証情報を生成するために特定のパラメータを使用する場合、第２のノードも検査情報を生成するために同じパラメータを使用するべきである。検査情報が第１のアイデンティティ認証情報と同じである場合、検証が成功したとみなされる。例えば、第１のアイデンティティ認証情報は、ＫＤＦを使用して生成される。したがって、第２のノードは、ＫＤＦを使用して、検査情報を生成してもよく、これは、検査値ｃｈｅｃｋ１とも呼ばれる。第２のノードは、検査情報を使用して、第１のアイデンティティ認証情報が正しいかどうかを検証する。以下、説明のために一例を使用する。

例えば、第１のアイデンティティ認証情報ＡＵＴＨａがＫＤＦ（ＰＳＫ，ＮＯＮＣＥｅ）である場合、第２のノードは、ＫＤＦを使用してＰＳＫ及び第１のフレッシュ・パラメータＮＯＮＣＥｅに基づいて、検査値ｃｈｅｃｋ１＝ＫＤＦ（ＰＳＫ、ＮＯＮＣＥｅ）を取得する。検査値ｃｈｅｃｋ１がＡＵＴＨａと同じである場合、検証が成功する。

任意選択で、第１のアイデンティティ認証情報を、第２のノードと第１のノードとの間の共有鍵に基づいて検証する前又は後に、第２のノードは、第１の認証要求に対してメッセージ完全性検査を実行して、第１の認証要求の内容が攻撃者によって改ざんされることを防止する。具体的には、第１の認証要求は、第１の完全性検査データを含み、第２のノードは、第１の完全性検査データに基づいて第１の認証要求に対してメッセージ完全性検査を実行してもよい。

任意選択で、第１の認証要求に対して実行されたメッセージ完全性検査が失敗した場合、第２のノードは、第１のノードの完全性検査失敗の数を更新してもよい。完全性検査失敗の数は、その後、第１のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。さらに、任意選択で、第２のノードが第１のノードの完全性検査失敗の数を更新する以下の２つのケースがあってもよい。

ケース１：第２のノードは、第１のノードの検証失敗の数を示すために第２の認証失敗カウンタを使用する。第１のノードに対する検証は、メッセージの完全性検査及びアイデンティティ認証を含み得る。したがって、第１の認証要求に対するメッセージ完全性検査が失敗したか、又は第２のノードに対するアイデンティティ認証が失敗した場合、第２のノードは、第２の認証失敗カウンタを１増加させてもよい。第２の認証失敗カウンタは、その後、第１のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

ケース２：第２のノードは、第１のノードの完全性検査失敗の数を示すために第２の完全性検査カウンタを使用する。第１の認証要求に対するメッセージ完全性検査が失敗した場合、第２のノードは、第２の完全性検査カウンタを１増加させてもよい。第２の完全性検査カウンタは、その後、第１のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

ステップＳ３０６：第２のノードによって実行される第１のアイデンティティ認証情報に対する検証が成功した場合、第２のノードは、第１の認証応答を第１のノードに送信する。

具体的には、第１の認証応答は、第２のアイデンティティ認証情報を含んでもよい。第２のアイデンティティ認証情報は、第２のノードと第１のノードとの間の共有鍵に基づいて、第２のノードによって生成される。共有鍵は、第１のノードと第２のノードの間の事前共有鍵ＰＳＫであってもよい。

例えば、第２のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫに基づいて、第２のアイデンティティ認証情報ＡＵＴＨｅを生成してもよい。例えば、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ）である。

任意選択で、第１の認証要求が第２のフレッシュ・パラメータを含むときに、第２のアイデンティティ認証情報は、共有鍵及び第２のフレッシュ・パラメータに基づいて第２のノードによって生成されてもよい。例えば、第２のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫ及び第２のフレッシュ・パラメータＮＯＮＣＥａに基づいて、第２のアイデンティティ認証情報ＡＵＴＨｅを生成する。例えば、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥａ）である。

任意選択で、実際の処理の間、第２のアイデンティティ認証情報を生成するために第２のノードによって使用されるパラメータは、他の情報をさらに含んでもよい。例えば、生成された第２のアイデンティティ認証情報ＡＵＴＨｅは、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ，第１の認証要求）を満たしてもよい。

任意選択で、第１のアソシエーション要求が第１のフレッシュ・パラメータをさらに含み得るときに、第２のノードによって生成される第２のアイデンティティ認証情報ＡＵＴＨｅは、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥｅ，第１の認証要求）をさらに満たしてもよく、ＮＯＮＣＥｅは、第１のアソシエーション要求の第１のフレッシュ・パラメータである。

任意選択で、第１のアソシエーション要求は、第２の完全性検査データなどをさらに含んでもよい。第２の完全性検査データは、対称鍵及び完全性保護アルゴリズムに従って生成される検査データであり、第１のノードが第１のアソシエーション要求に対してメッセージ完全性検査を実行するために使用される。特定の実装の間、検査データは、メッセージ認証コード（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ、ＭＡＣ）とも呼ばれてもよい。

ステップＳ３０７：第１のノードは、共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行する。

具体的には、第２のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて、生成される。したがって、第１のノードも共有鍵を持ち、共有鍵に基づいて、第２のアイデンティティ認証情報が正しいかどうかを検証してもよい。

任意選択の解決策では、プロトコル仕様に従って、第２のノードが第２のアイデンティティ認証情報を生成するために特定のパラメータを使用する場合、第１のノードも検査情報を生成するために同じパラメータを使用するべきである。検査情報が第１のアイデンティティ認証情報と同じである場合、検証が成功したとみなされる。例えば、第２のアイデンティティ認証情報は、ＫＤＦを使用して生成される。したがって、第１のノードは、ＫＤＦを使用して、検査情報を生成してもよく、これは、検査値ｃｈｅｃｋ２とも呼ばれる。次いで、第１のノードは、検査情報を使用して、第２のアイデンティティ認証情報が正しいかどうかを検証する。以下、説明のために一例を使用する。

例えば、第２のアイデンティティ認証情報ＡＵＴＨｅがＫＤＦ（ＰＳＫ，ＮＯＮＣＥａ）である場合、第１のノードは、ＫＤＦを使用してＰＳＫ及び第２のフレッシュ・パラメータＮＯＮＣＥａに基づいて、検査値ｃｈｅｃｋ２＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥａ）を取得する。検査値ｃｈｅｃｋ２がＡＵＴＨｅと同じである場合、検証が成功する。検査値ｃｈｅｃｋ２がＡＵＴＨｅと異なる場合、検証が失敗する。

任意選択で、共有鍵に基づいて第２のアイデンティティ認証情報を検証する前又は後に、第１のノードは、第１の認証応答に対してメッセージ完全性検査を実行して、第１の認証応答のコンテンツが攻撃者によって改ざんされることを防止する。具体的には、第１の認証応答は、第２の完全性検査データを含み、その結果、第１のノードは、第２の完全性検査データに基づいて第１の認証応答に対してメッセージ完全性検査を実行してもよい。

任意選択で、第１の認証応答に対して実行されたメッセージ完全性検査が失敗した場合、第１のノードは、第２のノードの完全性検査失敗の数を更新してもよい。完全性検査の失敗の数は、その後、第２のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。さらに、任意選択で、第１のノードが第２のノードの完全性検査失敗の数を更新する以下の２つのケースがあってもよい。

ケース１：第１のノードは、第２のノードの検証失敗の数を示すために第１の認証失敗カウンタを使用する。第２のノードに対する検証は、メッセージの完全性検査及びアイデンティティ認証を含む。したがって、第１の認証応答に対するメッセージ完全性検査が失敗したか、又は第２のノードに対するアイデンティティ認証が失敗した場合、第１のノードは、第１の認証失敗カウンタを１増加させてもよい。第１の認証失敗カウンタは、その後、第２のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

ケース２：第１のノードは、第２のノードの完全性検査失敗の数を示すために第１の完全性検査カウンタを使用する。第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１のノードは、第１の完全性検査カウンタを１増加させてもよい。第１の完全性検査カウンタは、その後、第２のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

ステップＳ３０８：第１のノードによって実行される第２のアイデンティティ認証情報に対する検証が失敗した場合、第１のノードは、第１の認証失敗カウンタを更新する。

具体的には、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す。例えば、第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタは１増加されてもよく、検証失敗の数は、その後、第２のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

任意選択で、この出願のこの実施形態のアソシエーション制御方法は、図５Ａ、図５Ｂ、及び図５Ｃに示すステップＳ５０１をさらに含んでもよい。ステップＳ５０１は、具体的には、以下のようである。

ステップＳ５０１：第１の認証失敗カウンタの値が第１の閾値を超える場合、第１のノードは、第２のノードの識別子を第１のブラックリストに追加する。

具体的には、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示すために使用され、第１の閾値を超える値は、第１の閾値以上であってもよい。第１の認証失敗カウンタの値が第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示す。したがって、第２のノードはアソシエーション要求を頻繁に送信する攻撃者であることがあり、第２のノードの識別子が第１のブラックリストに追加される。第２のノードの識別子が第１のブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。ノードの識別子は、第１のブラックリスト及び第１のホワイトリストの両方にあることはできないことが理解されよう。したがって、第２のノードの識別子が第１のブラックリストに追加されるときに、第２のノードの識別子が第１のホワイトリストにある場合、第１のホワイトリストから第１のノードの識別子が削除される必要がある。

任意選択で、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。例えば、ブラックリストの第１の持続期間は２０日であってもよく、第１のブラックリストに追加されてから２０日後に、ブラックリストから第２のノードの識別子が削除されてもよい。

任意選択で、第１のブラックリストに第２のノードの識別子が追加されている持続期間が第１の持続期間を超える場合、第１のブラックリストから第２のノードの識別子が削除される。第１の持続期間は、第２のノードの識別子が第１のブラックリストに追加された回数と第２のノードのデバイス・タイプに関連する。具体的には、第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続期間が長くなることを示す。さらに、任意選択で、第１のブラックリストに第２のノードが追加された回数が特定の値を超えた（例えば、１０回を超えた）後に、第２のノードが第１のブラックリストに永久的に追加されてもよく、削除することができない。追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

この出願では、特定のデバイス・タイプの数は制限されないことに留意されたい。実際の要件に基づいて、複数のタイプのデバイスが定義されてもよく、対応するブラックリスト及びブラックリストの有効期間がセットされてもよい。具体的には、第１のブラックリストは、代替的には、複数のグループのブラックリストを含んでもよく、これらのグループは、それぞれ、より具体的で洗練されたデバイス管理を実行するために使用される。

任意選択で、この出願のこの実施形態のアソシエーション制御方法は、図５Ａ、図５Ｂ、及び図５Ｃに示すステップＳ５０２をさらに含んでもよい。ステップＳ５０２は、具体的には、以下のようである。

ステップＳ５０２：第１のアイデンティティ認証情報に対する検証が成功した場合、第１のノードは、第１のアソシエーション応答を第２のノードに送信する。

具体的には、第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードは、第１のアソシエーション応答を第２のノードに送信してもよい。第１のアソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

任意選択で、この出願のこの実施形態のアソシエーション制御方法は、図５Ａ、図５Ｂ、及び図５Ｃに示すステップＳ５０３、又はステップ５０３及びステップ５０４をさらに含んでもよい。ステップ５０３及びステップ５０４は、具体的には、以下のようである。

ステップＳ５０３：第１のアイデンティティ認証情報に対する検証が失敗した場合、第１のノードは、第２の認証失敗カウンタを更新する。

具体的には、第２認証失敗カウンタは、第１のノードの検証失敗の数を示す。第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタの値を１増加させてもよい。第２の認証失敗カウンタは、その後、第１のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

ステップＳ５０４：第２の認証失敗カウンタの値が第２の閾値を超える場合、第２のノードは、第１のノードの識別子を第２のブラックリストに追加する。

具体的には、第１のノードの検証失敗の数が事前セットされた第２の閾値を超える場合、第１のノードが複数回検証されなかったことを示す。したがって、第１のノードは、認証要求を頻繁に送信する攻撃者であることがあり、第１のノードの識別子が第２のブラックリストに追加される。第１のノードの識別子が第２のブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを第２のノードが確立することを防止し、第２のノードのデータ・セキュリティを向上させる。第１のノードの識別子は、第２のブラックリスト及び第２のホワイトリストの両方にあることはできないことが理解されよう。したがって、第１のノードの識別子が第２のブラックリストに追加されるときに、第１のノードの識別子が第２のホワイトリストにある場合、第１のホワイトリストから第１のノードの識別子が削除される必要がある。

任意選択で、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。第２の持続期間は、ブラックリストの有効期間とみなされてもよい。例えば、第２のブラックリストの第２の持続期間は１０日であってもよく、第２のブラックリストに追加されてから１０日後に、第２のブラックリストから第１のノードの識別子が削除されてもよい。

任意選択で、第２の持続期間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。ノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続期間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードの識別子が追加された回数が特定の値を超えた（例えば、１５回を超えた）後に、第１のノードが第１のブラックリストに永久的に追加されてもよく、削除することができない。追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

任意選択で、第２のノードは、第２の認証失敗カウンタの値が第２の閾値未満であると決定する場合、第２のアソシエーション要求を第１のノードに送信してもよい。具体的には、アイデンティティ認証情報を検証する処理において、いくつかのパラメータは伝送プロセスにおいて失われるか又は誤って伝送されるため、アイデンティティ認証情報の検証も失敗する可能性がある。したがって、第１のノードの検証失敗の数が事前セットされた第２の閾値を超えない場合、アソシエーション要求は、第１のノードに再送されて、第１のノードとアソシエーションを確立することを要求してもよい。このようにして、システムの頑健性が向上し、ノードによって提供されるサービスの安定した動作が保証される。

任意選択で、第２のノードは、第２のアソシエーション要求を送信する前に、第３の確認応答表示情報を取得してもよい。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、第２のノードは、プロンプト情報を出力して、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。第２のノードは、ユーザ確認応答動作を受信し、第３確認応答表示情報を取得した後に、第１のノードに第２アソシエーション要求を送信する。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態では、第２のノードのアイデンティティが信頼されていると決定された後に、第２のノードのアイデンティティは、第２のノードと共有されている共有鍵に基づいて検証される。このように、攻撃者が、識別子を修正することにより、「アイデンティティが信頼されていると決定する」ステップを避ける場合でも、アイデンティティ認証情報を偽造することが難しいため、攻撃者に対する第１のノードによって実行されるアイデンティ認証は依然として成功することができない。したがって、認証されていない攻撃者とのアソシエーションをノードが確立することが防止され、ノードのデータ・セキュリティが向上する。

さらに、検証が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、（例えば、認証要求を送信する）ノードのアソシエーション要求はもはや処理されなくてもよく、ノードが多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

図６Ａ、図６Ｂ、及び図６Ｃは、この出願の一実施形態によるアソシエーション制御方法の概略フローチャートである。アソシエーション制御方法は、図１に示すアーキテクチャに基づいて実装されてもよい。本方法は、以下のステップを含むが、これらに限定されない。

ステップＳ６０１：第２のノードは、第１のノードのアイデンティティが信頼されていると決定する。

詳細については、Ｓ３０１の関連説明を参照のこと。

ステップＳ６０２：第２のノードは、第１のアソシエーション要求を第１のノードに送信する。

詳細については、Ｓ３０２の関連説明を参照のこと。

ステップＳ６０３：第１のノードは、第２のノードのアイデンティティが信頼されていると決定する。

詳細については、Ｓ３０３の関連説明を参照のこと。

ステップＳ６０４：第１のノードは、第１の認証要求を第２のノードに送信する。

具体的には、第１の認証要求は、第１の完全性検査データなどを含む。第１の完全性検査データは、鍵及び完全性保護アルゴリズムに従って生成される検査データであり、第２のノードが第１認証要求に対してメッセージ完全性検査を実行するために使用される。特定の実装の間、検査データは、メッセージ認証コード（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ、ＭＡＣ）とも呼ばれてもよい。

例えば、第１の完全性検査データＭＡＣ１は、共有鍵Ｋ１と、第１の認証要求のＭＡＣ１ではないデータの一部又は全部ｄａｔａ１を使用して、暗号ベースのメッセージ認証コード（Ｃｉｐｈｅｒ－ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ、ＣＭＡＣ）アルゴリズムに従って、取得されてもよい。例えば、ＭＡＣ１＝ＣＭＡＣ（Ｋ１，ｄａｔａ１）である。

任意選択で、第１の認証要求は、第１のアイデンティティ認証情報を含んでもよい。第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて、第１のノードによって生成される。共有鍵は、第１のノードと第２のノードの間の事前共有鍵であってもよい。例えば、第１のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫに基づいて、第１のアイデンティティ認証情報ＡＵＴＨａを生成してもよい。すなわち、ＡＵＴＨａ＝ＫＤＦ（ＰＳＫ）である。

任意選択で、第１のアソシエーション要求が第１のフレッシュ・パラメータを含むときに、第１のアイデンティティ認証情報は、共有鍵及び第１のフレッシュ・パラメータに基づいて第１のノードによって生成されてもよい。例えば、第１のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫ及び第１のフレッシュ・パラメータＮＯＮＣＥｅに基づいて、第１のアイデンティティ認証情報ＡＵＴＨａを生成する。例えば、ＡＵＴＨａ ＝ ＫＤＦ（ＰＳＫ，ＮＯＮＣＥｅ）である。さらに、任意選択で、実際の処理の間、第１のアイデンティティ認証情報を生成するために第１のノードによって使用されるパラメータは、他の情報をさらに含んでもよい。例えば、生成された第１のアイデンティティ認証情報ＡＵＴＨａは、ＡＵＴＨａ＝ＫＤＦ（ＰＳＫ，第１のアソシエーション要求）を満たしてもよい。さらに、任意選択で、第１の認証要求が第２のフレッシュ・パラメータを含むときに、第１のノードによって生成される第１のアイデンティティ認証情報ＡＵＴＨａは、ＡＵＴＨａ＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥａ，第１のアソシエーション要求）をさらに満たしてもよく、ＮＯＮＣＥａは、第１の認証要求の第２のフレッシュ・パラメータである。

ステップＳ６０５：第２のノードは、第１の認証要求に対してメッセージ完全性検査を実行する。

具体的には、第１の認証要求は、第１の完全性検査データを含み、第２のノードは、第１の完全性検査データに基づいて第１の認証要求に対してメッセージ完全性検査を実行して、第１の認証要求の内容が攻撃者によって改ざんされることを防止してもよい。

可能な解決策では、第１のノードは特定の方法で第１の完全性検査データを生成するので、第２のノードも同じ方式で検査値を生成する。生成された検査値が第１の完全性検査データと同じである場合、メッセージ完全性検査が成功する。例えば、第１の完全性検査データＭＡＣ１が、共有鍵Ｋ１と、第１の認証要求のＭＡＣ１ではないデータの一部又は全部ｄａｔａ１を使用して、ＣＭＡＣアルゴリズムに従って第１のノードによって取得される場合、第２のノードは、同じ方式で検査値ｃｈｅｃｋ３を生成する。すなわち、ｃｈｅｃｋ３＝ＣＭＡＣ（Ｋ１，ｄａｔａ１）である。ｃｈｅｃｋ３がＭＡＣ１と同じである場合、第１の認証要求のｄａｔａ１が改ざんされていないことを示し、第１の認証要求に対する完全性検査が成功する。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６０６をさらに含み、これは、具体的には、以下のようである。

ステップＳ６０６：第１の認証要求に対するメッセージ完全性検査が失敗した場合、第２のノードは、第２の認証失敗カウンタを更新する。

具体的には、第２のノードは、第１のノードの検証失敗の数を示すために第２の認証失敗カウンタを使用してもよい。したがって、第１の認証要求に対するメッセージ完全性検査が失敗した場合、第２のノードは、第２の認証失敗カウンタの値を１増加させてもよい。第２の認証失敗カウンタは、その後、第１のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６０７をさらに含み、これは、具体的には、以下のようである。

ステップＳ６０７：第２の認証失敗カウンタの値が第２の閾値を超える場合、第２のノードは、第１のノードの識別子を第２のブラックリストに追加する。

具体的には、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示し、第２の閾値を超える値は、第２の閾値以上であってもよい。第１の認証要求に対するメッセージ完全性検査失敗の数が第２の閾値を超える場合、第１のノードからのメッセージが攻撃者によって複数回改ざんされた可能性があるか、又は元々正しくないデータである可能性があると示してもよい。したがって、第１のノードの識別子は、第２のブラックリストに追加されて、認証されていない攻撃者とのアソシエーションを第２のノードが確立することを防止し、第２のノードのデータ・セキュリティを向上させる。

任意選択で、第２のノードは、第２の認証失敗カウンタの値が第２の閾値以下であると決定する場合、第２のアソシエーション要求を第１のノードに送信してもよい。さらに、任意選択で、第２のノードは、第２のアソシエーション要求を送信する前に、第３の確認応答表示情報を取得してもよい。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、第２のノードは、プロンプト情報を出力して、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。第２のノードは、ユーザ確認応答動作を受信し、第３確認応答表示情報を取得した後に、第１のノードに第２アソシエーション要求を送信する。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６０８をさらに含み、これは、具体的には、以下のようである。

ステップＳ６０８：第２のノードは、第２のノードと第１のノードとの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行する。

詳細については、Ｓ３０５の関連説明を参照のこと。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６０９をさらに含み、これは、具体的には、以下のようである。

ステップＳ６０９：第１のアイデンティティ認証情報に対する検証が失敗した場合、第１のノードは、第２の認証失敗カウンタを更新する。

具体的には、第２認証失敗カウンタは、第１のノードの検証失敗の数を示す。第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタの値を１増加させてもよい。第２の認証失敗カウンタは、その後、第１のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６１０をさらに含み、これは、具体的には、以下のようである。

ステップＳ６１０：第２の認証失敗カウンタの値が第２の閾値を超える場合、第２のノードは、第１のノードの識別子を第２のブラックリストに追加する。

具体的には、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示し、第２の閾値を超える値は、第２の閾値以上であってもよい。第２の認証失敗カウンタの値が第２の閾値を超える場合、第１のノードが複数回検証されなかったことを示す。したがって、第１のノードは、認証要求を頻繁に送信する攻撃者であることがあり、第１のノードの識別子が第２のブラックリストに追加される。第１のノードの識別子が第２のブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを第２のノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

任意選択で、第２のノードは、第２の認証失敗カウンタの値が第２の閾値未満であると決定する場合、第２のアソシエーション要求を第１のノードに送信してもよい。さらに、任意選択で、第２のノードは、第２のアソシエーション要求を送信する前に、第３の確認応答表示情報を取得してもよい。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、第２のノードは、第３のプロンプト情報を出力して、第１のノードに対するアイデンティティ認証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。第２のノードは、ユーザ確認応答動作を受信し、第３確認応答表示情報を取得した後に、第１のノードに第２アソシエーション要求を送信する。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

任意選択的に、特定の実装プロセスでは、第２のノードは、最初に、Ｓ６０８の動作又はＳ６０８～Ｓ６１０の動作を実行し、次いで、Ｓ６０５の動作又はＳ６０５～Ｓ６０７の動作を実行してもよい。言い換えれば、第２のノードは、最初に、共有鍵に基づいて第１のアイデンティティ認証情報に対する検証を実行し、次いで、第１の認証要求に対してメッセージ完全性検査を実行してもよい。

ステップＳ６１１：第２のノードは、第１の認証応答を第１のノードに送信する。

具体的には、第１の認証応答は、第２の完全性検査データなどをさらに含んでもよい。第２の完全性検査データは、対称鍵及び完全性保護アルゴリズムに従って生成される検査データであり、第１のノードが第１のアソシエーション要求に対してメッセージ完全性検査を実行するために使用される。特定の実装の間、検査データは、メッセージ認証コード（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ、ＭＡＣ）とも呼ばれてもよい。例えば、第２の完全性検査データＭＡＣ２は、共有鍵Ｋ１と、第１の認証応答のＭＡＣ２ではないデータの一部又は全部ｄａｔａ２を使用して、ＣＭＡＣアルゴリズムに従って取得されてもよい。例えば、ＭＡＣ＝ＣＭＡＣＫ（Ｋ１，ｄａｔａ２）である。

任意選択で、第１の認証要求に対するメッセージ完全性検査が成功した場合、第２のノードは、第１の認証応答を第１のノードに送信する。さらに、任意選択で、第１の認証要求に対するメッセージ完全性検査が成功し、第２のノードによって実行される第１のアイデンティティ認証情報に対する検証が成功した場合、第１の認証応答が第１のノードに送信される。

任意選択で、第１の認証応答は、第２のアイデンティティ認証情報を含んでもよい。第２のアイデンティティ認証情報は、第２のノードと第１のノードとの間の共有鍵に基づいて、第２のノードによって生成される。共有鍵は、第１のノードと第２のノードの間の事前共有鍵ＰＳＫであってもよい。例えば、第２のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫに基づいて、第２のアイデンティティ認証情報ＡＵＴＨｅを生成してもよい。例えば、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ）である。

任意選択で、第１の認証要求が第２のフレッシュ・パラメータを含むときに、第２のアイデンティティ認証情報は、共有鍵及び第２のフレッシュ・パラメータに基づいて第２のノードによって生成されてもよい。例えば、第２のノードは、ＫＤＦを使用して、事前共有鍵ＰＳＫ及び第２のフレッシュ・パラメータＮＯＮＣＥａに基づいて、第２のアイデンティティ認証情報ＡＵＴＨｅを生成する。例えば、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥａ）である。さらに、任意選択で、実際の処理の間、第２のアイデンティティ認証情報を生成するために第２のノードによって使用されるパラメータは、他の情報をさらに含んでもよい。例えば、生成された第２のアイデンティティ認証情報ＡＵＴＨｅは、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ，第２のアソシエーション要求）を満たしてもよい。さらに、任意選択で、第１のアソシエーション要求が第１のフレッシュ・パラメータをさらに含み得るときに、第２のノードによって生成される第２のアイデンティティ認証情報ＡＵＴＨｅは、ＡＵＴＨｅ＝ＫＤＦ（ＰＳＫ，ＮＯＮＣＥｅ，第１の認証要求）をさらに満たしてもよく、ＮＯＮＣＥｅは、第１のアソシエーション要求の第１のフレッシュ・パラメータである。

ステップＳ６１２：第１のノードは、第１の認証応答に対してメッセージ完全性検査を実行する。

具体的には、第１の認証応答は、第２の完全性検査データを含み、第１のノードは、第２の完全性検査データに基づいて第１の認証応答に対してメッセージ完全性検査を実行して、第１の認証応答の内容が攻撃者によって改ざんされることを防止してもよい。

可能な解決策では、第２のノードは特定の方法で第２の完全性検査データを生成するので、第１のノードも同じ方式で検査値を生成する。生成された検査値が第２の完全性検査データと同じである場合、メッセージ完全性検査が成功する。例えば、第２の完全性検査データＭＡＣ２が、共有鍵Ｋ１と、第１の認証応答のＭＡＣ２ではないデータの一部又は全部ｄａｔａ２を使用して、ＣＭＡＣアルゴリズムに従って第２のノードによって取得される場合、第２のノードは、同じ方式で検査値ｃｈｅｃｋ４を生成する。すなわち、ｃｈｅｃｋ４＝ＣＭＡＣ（Ｋ１，ｄａｔａ２）である。ｃｈｅｃｋ４がＭＡＣ２と同じである場合、第１の認証応答のｄａｔａ２が改ざんされていないことを示し、第１の認証応答に対する完全性検査が成功する。

ステップＳ６１３：第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１のノードは、第１の認証失敗カウンタを更新する。

具体的には、第１のノードは、第２のノードの検証失敗の数を示すために、第１の認証失敗カウンタを使用してもよい。したがって、第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１のノードは、第１の認証失敗カウンタの値を１増加させてもよい。第１の認証失敗カウンタは、その後、第２のノードのアイデンティティが信頼されているかどうかを決定するために使用されてもよい。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６１４をさらに含み、これは、具体的には、以下のようである。

ステップＳ６１４：第１の認証失敗カウンタの値が第１の閾値を超える場合、第１のノードは、第２のノードの識別子を第１のブラックリストに追加する。

具体的には、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示し、第１の閾値を超える値は、第１の閾値以上であってもよい。第１の認証失敗カウンタの値が第１の閾値を超える場合、第２のノードからのメッセージが攻撃者によって複数回改ざん可能性があるか、又は元々正しくないデータである可能性があることを示してもよい。したがって、第２のノードの識別子が第１のブラックリストに追加されて、認証されていない攻撃者とのアソシエーションを第１のノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６１５をさらに含み、これは、具体的には、以下のようである。

ステップＳ６１５：第１のノードは、共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行する。

詳細については、Ｓ３０７の関連説明を参照のこと。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６１６又はステップＳ６１６及びステップＳ６１７をさらに含む。ステップＳ６１６及びＳ６１７は、具体的には、以下のようである。

ステップＳ６１６：第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１のノードは、第１の認証失敗カウンタを更新する。

詳細については、Ｓ３０８の関連説明を参照のこと。

ステップＳ６１７：第１の認証失敗カウンタの値が第１の閾値を超える場合、第１のノードは、第２のノードの識別子を第１のブラックリストに追加する。

詳細については、Ｓ５０１の関連説明を参照のこと。

任意選択的に、特定の実装プロセスでは、第１のノードは、最初に、Ｓ６１５の動作又はＳ６１５～Ｓ６１７の動作を実行し、次いで、Ｓ６１２の動作又はＳ６１２及びＳ６１３の動作を実行してもよい。言い換えれば、第１のノードは、最初に、共有鍵に基づいて第２のアイデンティティ認証情報に対する検証を実行し、次いで、第１の認証応答に対してメッセージ完全性検査を実行してもよい。

任意選択で、図６Ａ、図６Ｂ、及び図６Ｃに示すアソシエーション制御方法は、ステップＳ６１８をさらに含み、これは、具体的には、以下のようである。

ステップＳ６１８：第１のノードは、第１のアソシエーション応答を第２のノードに送信する。

具体的には、第１のアソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

任意選択で、第１の認証応答に対するメッセージ完全性検査が成功した場合、第１のノードは、第１のアソシエーション応答を第２のノードに送信する。さらに、任意選択で、第１の認証応答に対するメッセージ完全性検査が成功し、第１のノードによって実行される第１のアイデンティティ認証情報に対する検証が成功した場合、第１のノードは、第１のアソシエーション応答を第２のノードに送信する。

図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態では、第２のノードのアイデンティティが信頼されていると決定された後に、アソシエーションが実行される前に、第２のノードからの認証応答メッセージに対して、メッセージ完全性検査がさらに実行される必要がある。メッセージ完全性検査が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよく、その結果、攻撃者が認証処理においてデータを改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

以上、この出願の実施形態の方法を詳細に記載している。以下、この出願の実施形態の装置を提供する。

図７は、この出願の一実施形態による、アソシエーション制御装置７０の構造の概略図である。装置７０は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。装置７０は、通信ユニット７０１及び処理ユニット７０２を含んでもよい。ユニットの説明は以下のようである。

通信ユニット７０１は、第２のノードから第１のアソシエーション要求を受信するように構成されている。

処理ユニット７０２は、第２のノードのアイデンティティが信頼されていると決定し、通信ユニット７０１を使用して、第１の認証要求を第２のノードに送信するように構成されている。第１の認証要求は、第１のアイデンティティ認証情報を含み、第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて生成される。

通信ユニット７０１は、第２のノードから第１の認証応答を受信するようにさらに構成されている。第１の認証応答は、第２のアイデンティティ認証情報を含む。

処理ユニット７０２は、共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行するようにさらに構成されている。

処理ユニット７０２は、第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新するようにさらに構成されている。第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す。

この出願のこの実施形態では、装置７０は、第２のノードのアイデンティティが信頼されていると決定した後に、第２のノードと共有される共有鍵に基づいて第２のノードのアイデンティティを検証する。このように、攻撃者が、識別子を修正することにより、アイデンティティが装置７０から信頼されていると決定するステップを避ける場合でも、アイデンティティ認証情報を偽造することが難しいため、攻撃者に対する装置によって実行されるアイデンティ認証は依然として成功することができない。したがって、認証されていない攻撃者とのアソシエーションを装置が確立することが防止され、ノードのデータ・セキュリティが向上する。

さらに、検証が失敗した場合、装置７０は、検証失敗の数を更新する。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、装置７０は、（例えば、認証要求を送信する）ノードのアソシエーション要求をもはや処理しなくてもよく、装置７０が多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

前述の複数のユニットの分割は、機能に基づく論理分割にすぎず、装置７０の特定の構造に対する限定として使用されないと留意されたい。特定の実装では、いくつかの機能モジュールは、より小さな機能モジュールに細分化されてもよいし、いくつかの機能モジュールは、１つの機能モジュールに組み合わされてもよい。しかしながら、これらの機能モジュールが細分化されているか、組み合わされているかにかかわらず、アソシエーション制御処理において装置７０によって実行される手順は、ほぼ同じである。例えば、通信ユニット７０１は、代替的には、受信ユニット及び送信ユニットに変換されてもよい。受信ユニットは、通信ユニット７０１のメッセージ受信機能を実装するように構成されており、送信ユニットは、通信ユニット７０１のメッセージ送信機能を実装するように構成されている。通常、各ユニットは、ユニットのプログラム・コード（又はプログラム命令）に対応する。ユニットに対応するプログラム・コードがプロセッサ上で動作するときに、ユニットは、対応する手順を実行して、対応する機能を実装することが可能となる。

いくつかの実装では、処理モジュール７０２は、具体的には、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている。

装置７０は、ブラックリスト又はホワイトリストに基づいてアソシエーションを要求するノードを制御し、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これにより、多数の要求の処理による機能停止を防止し、サービスの正常な動作を保証することができる。追加的に、装置は、アイデンティティ認証を受けないノードとのアソシエーションを確立しないため、装置７０が認証されていない攻撃者とのアソシエーションを確立することが防止され、装置７０のデータ・セキュリティが向上する。

いくつかの実装では、処理ユニットは、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

さらに別の可能な実装では、第１の認証応答は、第２の完全性検査データをさらに含み、第２の完全性検査データは、第１の認証応答に対してメッセージ完全性検査を実行するために使用される。

前記処理ユニット７０２は、具体的には、
第１の認証応答に対するメッセージ完全性検査が成功したと決定するように構成されている。

第２のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第２のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、処理ユニット７０２は、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第１のアソシエーション閾値が装置に事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、装置によって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、装置は、アソシエーション要求をもはや受信又は処理しなくてもよく、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、通信ユニット７０１は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション応答を第２のノードに送信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

さらに別の可能な実装では、処理ユニット７０２は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション失敗カウンタをリセットするようにさらに構成されている。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

さらに別の可能な実装では、処理ユニット７０２は、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加するようにさらに構成されている。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証を受けていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続時間は１週間であってもよく、ブラックリストに追加された１週間後に、第２のノードの識別子がブラックリストから削除されてもよい。

さらに別の可能な実装では、処理ユニット７０２は、
第１のブラックリストに第２のノードの識別子が追加されている持続時間が第１の持続時間を超える場合、第１のブラックリストから第２のノードの識別子を削除することであって、第１の持続時間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第１のブラックリストの有効期間に関連する要因を説明する。第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続時間が長くなることを示す。さらに、任意選択で、第１のブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードが第１のブラックリストに永久的に追加されてもよい。

追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。デバイス・タイプの数は、この出願では具体的には限定されず、特定のシナリオに基づいて設計されてもよい。

さらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、装置のリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

各ユニットの実装については、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の対応する説明を参照することに留意されたい。装置７０は、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の第１のノードであってもよい。

図８は、この出願の一実施形態によるアソシエーション装置８０の構造の概略図である。装置８０は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。装置８０は、処理ユニット８０１及び通信ユニット８０２を含んでもよい。ユニットの説明は以下のようである。

処理ユニット８０１は、第１のノードのアイデンティティが信頼されていると決定し、通信ユニット８０２を使用して、第１のアソシエーション要求を前記第１のノードに送信するように構成されている。

通信ユニット８０２は、第１のノードから第１の認証要求を受信するようにさらに構成されている。第１の認証要求には、第１のアイデンティティ認証情報を含む。

処理ユニット８０１は、第２のノードと第１のノードの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行するようにさらに構成されている。

通信ユニット８０２は、第１のアイデンティティ認証情報に対する検証が成功した場合、第１の認証応答を第１のノードに送信するようにさらに構成されている。第１の認証応答は、第２のアイデンティティ認証情報を含み、第２のアイデンティティ認証情報は、共有鍵に基づいて生成される。

この出願のこの実施形態では、第１のノードのアイデンティティが信頼されていると決定した後に、装置は、第１のアソシエーション要求を第１のノードに送信する。次いで、共有鍵を使用して、第１の認証要求における第１のアイデンティティ認証情報に基づいて、第１のノードのアイデンティティ認証情報に対する検証が実行される。検証が成功した後に、第２のアイデンティティ認証情報が第１のノードに送信される。第２のアイデンティティ認証情報は、第１のノードが装置のアイデンティティを検証するために使用されてもよい。アイデンティティが信頼されていると決定された後に、アソシエーションは、両者のアイデンティティ認証が成功した後にのみ実行され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第２のノードによって実行されるアイデンティティ認証を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

前述の複数のユニットの分割は、機能に基づく論理分割にすぎず、装置８０の特定の構造に対する限定として使用されないと留意されたい。特定の実装では、いくつかの機能モジュールは、より小さな機能モジュールに細分化されてもよいし、いくつかの機能モジュールは、１つの機能モジュールに組み合わされてもよい。しかしながら、これらの機能モジュールが細分化されているか、組み合わされているかにかかわらず、アソシエーション制御処理において装置８０によって実行される手順は、ほぼ同じである。例えば、通信ユニット８０２は、代替的には、受信ユニット及び送信ユニットに変換されてもよい。受信ユニットは、通信ユニット８０２のメッセージ受信機能を実装するように構成されており、送信ユニットは、通信ユニット８０２のメッセージ送信機能を実装するように構成されている。通常、各ユニットは、ユニットのプログラム・コード（又はプログラム命令）に対応する。ユニットに対応するプログラム・コードがプロセッサ上で動作するときに、ユニットは、対応する手順を実行して、対応する機能を実装することが可能となる。

いくつかの実装では、処理モジュール８０１は、具体的には、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うように構成されている。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、装置は、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

いくつかの実装では、処理モジュール８０１は、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

さらに別の可能な実装では、第１の認証要求は、第１の完全性検査データをさらに含み、第１の完全性検査データは、第１の認証要求に対してメッセージ完全性検査を実行するために使用される。

処理ユニット８０１は、
第１の認証要求に対するメッセージ完全性検査が成功したと決定するようにさらに構成されている。

第１のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第１のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、処理ユニット８０１は、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第２のアソシエーション閾値が装置に事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、装置にアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、装置は、別のノードにアソシエーションされることができず、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、通信ユニット８０２は、
第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、装置は、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを装置に通知してもよい。

さらに別の可能な実装では、処理ユニット８０１は、
第２の認証失敗カウンタをリセットするようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

さらに別の可能な実装では、処理ユニット８０１は、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

さらに別の可能な実装では、処理ユニット８０１は、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、
前記第１のノードの前記識別子を前記第２のブラックリストに追加するようにさらに構成されている。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証を受けていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続時間は１０日であってもよく、ブラックリストに追加されてから１０日後に、第１のノードの識別子がブラックリストから削除されてもよい。

さらに別の可能な実装では、処理ユニット８０１は、第２の認証失敗カウンタの値が第２の閾値未満であることを決定するようにさらに構成されている。

通信ユニット８０２は、第１のノードに第２のアソシエーション要求を送信するようにさらに構成されている。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の可能な実装では、プロセッサは、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

さらに別の可能な実装では、プロセッサは、
第２のブラックリストに第１のノードの識別子が追加されている持続時間が第２の持続時間を超える場合、第２のブラックリストから第１のノードの識別子を削除するようにさらに構成されており、第２の持続時間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続時間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。さらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

各ユニットの実装については、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の対応する説明を参照することに留意されたい。装置８０は、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の第２のノードであってもよい。

図９は、この出願の一実施形態による通信装置の構造の概略図である。通信装置９０は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。装置９０は、少なくとも１つのメモリ９０１及び少なくとも１つのプロセッサ９０２を含んでもよい。任意選択で、装置は、バス９０３をさらに含んでもよい。任意選択で、装置は、通信インターフェース９０４をさらに含んでもよい。メモリ９０１、プロセッサ９０２、及び通信インターフェース９０４は、バス９０３を介して接続される。

メモリ９０１は記憶空間を提供するように構成され、記憶空間はオペレーティング・システム及びコンピュータ・プログラムのようなデータを記憶してもよい。メモリ９０１は、ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＥＰＲＯＭ）、又はコンパクト・ディスク読み出し専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＣＤ－ＲＯＭ）のうちの１つ又はそれらの組み合わせであってもよい。

プロセッサ９０２は、算術演算及び／又は論理演算を実行するモジュールであり、具体的には、中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、グラフィック処理ユニット（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）、マイクロプロセッサ・ユニット（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ ｕｎｉｔ、ＭＰＵ）、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ－Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、ＦＰＧＡ）、及び複雑なプログラマブル論理デバイス（Ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＣＰＬＤ）などの処理モジュールのうちの１つ又はそれらの組み合わせであってもよい。

通信インターフェース９０４は、外部から送信されたデータを受信し、及び／又は外部へデータを送信するように構成されており、イーサネット・ケーブルのような有線リンクのインターフェースであってもよいし、無線リンク（Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、ユニバーサル無線伝送など）インターフェースであってもよい。任意選択で、通信インターフェース１１０４は、インターフェースに結合された送信機（例えば、無線周波数送信機又はアンテナ）、受信機などを含んでもよい。

装置９０内のプロセッサ９０２は、メモリ９０１に記憶されたコンピュータ・プログラムを読み出して、前述のアソシエーション制御方法、例えば、図３又は図５Ａ、図５Ｂ、及び図５Ｃに記載のアソシエーション制御方法を実行するように構成されている。

例えば、装置９０内のプロセッサ９０２は、メモリ９０１に記憶されたコンピュータ・プログラムを読み出して、
通信インターフェース９０４を介して第２のノードから第１のアソシエーション要求を受信することと、
第２のノードのアイデンティティが信頼されていると決定し、通信インターフェース９０４を介して第１の認証要求を第２のノードに送信することであって、第１の認証要求は、第１のアイデンティティ認証情報を含み、第１のアイデンティティ認証情報は、第１のノードと第２のノードとの間の共有鍵に基づいて生成され、共有鍵は、第１のノードと第２のノードとの間で共有される第１の秘密値とみなされ得る、ことと、
通信インターフェース９０４を介して第２のノードから第１の認証応答を受信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含む、ことと、
共有鍵に基づいて第２のアイデンティティ認証情報に対して検証を実行することと、
第２のアイデンティティ認証情報に対する前記検証が失敗した場合、第１の認証失敗カウンタを更新することであって、前記第１の認証失敗カウンタは、前記第２のノードの検証失敗の数を示す、こととを行う動作を実行するように構成されている。

この出願のこの実施形態では、装置９０は、第２のノードのアイデンティティが信頼されていると決定した後に、第２のノードと共有される共有鍵に基づいて第２のノードのアイデンティティを検証する。このように、攻撃者が、識別子を修正することにより、アイデンティティが装置９０から信頼されていると決定するステップを避ける場合でも、アイデンティティ認証情報を偽造することが難しいため、攻撃者に対する装置９０によって実行されるアイデンティ認証は依然として成功することができない。したがって、認証されていない攻撃者とのアソシエーションを装置９０が確立することが防止され、装置９０のデータ・セキュリティが向上する。

さらに、検証が失敗した場合、装置９０は、検証失敗の数を更新する。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、装置９０は、（例えば、認証要求を送信する）ノードのアソシエーション要求をもはや処理しなくてもよく、装置９０が多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

いくつかの実装では、処理モジュール９０２は、具体的には、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている。

装置９０は、ブラックリスト又はホワイトリストに基づいてアソシエーションを要求するノードを制御し、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これにより、多数の要求の処理による機能停止を防止し、サービスの正常な動作を保証することができる。追加的に、装置は、アイデンティティ認証を受けないノードとのアソシエーションを確立しないため、装置９０が認証されていない攻撃者とのアソシエーションを確立することが防止され、装置９０のデータ・セキュリティが向上する。

いくつかの実装では、プロセッサ９０２は、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

さらに別の可能な実装では、第１の認証応答は、第２の完全性検査データをさらに含み、第２の完全性検査データは、第１の認証応答に対してメッセージ完全性検査を実行するために使用される。

プロセッサ９０２は、第１の認証応答に対するメッセージ完全性検査が成功したと決定するようにさらに構成されている。

第２のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第２のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置９０によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、プロセッサ９０２は、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第１のアソシエーション閾値が装置９０に事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、ノードによって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、装置９０は、アソシエーション要求をもはや受信又は処理しなくてもよく、装置９０と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置９０によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、プロセッサ９０２は、
第２のアイデンティティ認証情報に対する検証が成功した場合、通信インターフェース９０４を介して第１のアソシエーション応答を第２のノードに送信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置９０に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

さらに別の可能な実装では、プロセッサ９０２は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション失敗カウンタをリセットするようにさらに構成されている。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、装置９０によって提供されるサービスの安定した動作を保証することが分かる。

さらに別の可能な実装では、プロセッサ９０２は、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加するようにさらに構成されている。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、装置９０が認証を受けていない攻撃者とのアソシエーションを確立することを防止し、装置９０のデータ・セキュリティを向上させる。

さらに別の実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続時間は１週間であってもよく、ブラックリストに追加された１週間後に、第２のノードの識別子がブラックリストから削除されてもよい。

さらに別の可能な実装では、プロセッサ９０２は、
第１のブラックリストに第２のノードの識別子が追加されている持続時間が第１の持続時間を超える場合、第１のブラックリストから第２のノードの識別子を削除することであって、第１の持続時間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、ブラックリストの有効期間に関連する要因を説明する。ブラックリストの有効期間は、第２のノードがブラックリストに追加された回数に関連してもよい。第２のノードがブラックリストに追加された回数が多いほど、ブラックリストにある第２のノードの持続時間が長くなることを示す。さらに、任意選択で、ブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードがブラックリストに永久的に追加されてもよい。

追加的に、ブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、装置９０は、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

さらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、装置９０のリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

各ユニットの特定の実装については、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の対応する説明を参照することに留意されたい。通信装置９０は、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の第１のノードであってもよい。

図１０は、この出願の一実施形態による通信装置１００の構造の概略図である。通信装置１００は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。装置１００は、少なくとも１つのメモリ１００１及び少なくとも１つのプロセッサ１００２を含んでもよい。任意選択で、装置は、バス１００３をさらに含んでもよい。任意選択で、装置は、通信インターフェース１００４をさらに含んでもよい。メモリ１００１、プロセッサ１００２、及び通信インターフェース１００４は、バス１００３を介して接続される。

メモリ１００１は記憶空間を提供するように構成され、記憶空間はオペレーティング・システム及びコンピュータ・プログラムのようなデータを記憶してもよい。メモリ１００１は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＣＤ－ＲＯＭなどのうちの１つ又はそれらの組み合わせであってもよい。

プロセッサ１００２は、算術演算及び／又は論理演算を実行するモジュールであり、具体的には、ＣＰＵ、ＧＰＵ、ＭＰＵ、ＡＳＩＣ、ＦＰＧＡ、及びＣＰＬＤなどの処理モジュールのうちの１つ又はそれらの組み合わせであってもよい。

通信インターフェース１００４は、外部から送信されたデータを受信し、及び／又は外部へデータを送信するように構成されており、イーサネット・ケーブルのような有線リンクのインターフェースであってもよいし、無線リンク（Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈなど）インターフェースであってもよい。任意選択で、通信インターフェース１１０４は、インターフェースに結合された送信機（例えば、無線周波数送信機又はアンテナ）、受信機などを含んでもよい。

装置１００内のプロセッサ１００２は、メモリ１００１に記憶されたコンピュータ・プログラムを読み出して、前述のアソシエーション制御方法、例えば、図３又は図５Ａ、図５Ｂ、及び図５Ｃに記載のアソシエーション制御方法を実行するように構成されている。

例えば、装置１００内のプロセッサ１００２は、メモリ１００１に記憶されたコンピュータ・プログラムを読み出して、
第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を前記第１のノードに送信することと、
第１の認証要求を第１のノードから受信することであって、第１の認証要求は、第１のアイデンティティ認証情報を含む、ことと、
第２のノードと第１のノードとの間の共有鍵に基づいて第１のアイデンティティ認証情報に対して検証を実行することであって、共有鍵は、第１のノードと第２のノードとの間で共有される秘密の値である、ことと、
第１のアイデンティティ認証情報に対する検証が成功した場合、第１のノードに第１の認証応答を送信することであって、第１の認証応答は、第２のアイデンティティ認証情報を含み、第２のアイデンティティ認証情報は、共有鍵に基づいて生成される、こととを行う動作を実行するように構成されている。

この出願のこの実施形態では、第１のノードのアイデンティティが信頼されていると決定した後に、装置１００は、第１のアソシエーション要求を第１のノードに送信する。次いで、共有鍵を使用して、第１の認証要求における第１のアイデンティティ認証情報に基づいて、第１のノードのアイデンティティ認証情報に対する検証が実行される。検証が成功した後に、第２のアイデンティティ認証情報が第１のノードに送信される。第２のアイデンティティ認証情報は、第１のノードが装置１００のアイデンティティを検証するために使用されてもよい。アイデンティティが信頼されていると決定された後に、アソシエーションは、両者のアイデンティティ認証が成功した後にのみ実行され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の装置１００によって実行されるアイデンティティ認証を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置１００が確立することを防止し、装置１００のデータ・セキュリティを向上させる。

いくつかの実装では、処理モジュール１００２は、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うようにさらに構成されている。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、装置１００は、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションを装置１００が確立することを防止し、装置１００のデータ・セキュリティを向上させる。

別の可能な実装では、処理モジュール１００２は、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うようにさらに構成されている。

さらに別の可能な実装では、第１の認証要求は、第１の完全性検査データをさらに含み、第１の完全性検査データは、第１の認証要求に対してメッセージ完全性検査を実行するために使用される。

プロセッサは、第１の認証要求に対するメッセージ完全性検査が成功したと決定するようにさらに構成されている。

第１のノードのアイデンティが信頼されていると決定された後に、アイデンティティ認証に加えて、アイデンティティ認証情報を搬送するメッセージに対して完全性検査が実行される必要があり、第１の認証応答が攻撃者によって改ざんされることを防止することが分かる。これは、第２のノードのアイデンティティ認証情報に対する検証に影響を与えることを回避し、装置１００によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、プロセッサ１００２は、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第２のアソシエーション閾値が装置１００に事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、装置１００にアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、装置１００は、別のノードにアソシエーションされることができず、装置１００と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置１００によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、プロセッサ１００２は、
第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、装置１００は、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第１のノードが第２のノードとのアソシエーションを確立することを示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを装置１００に通知してもよい。

さらに別の可能な実装では、プロセッサ１００２は、
第２の認証失敗カウンタをリセットするようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、装置１００によって提供されるサービスの安定した動作を保証することが分かる。

さらに別の可能な実装では、プロセッサ１００２は、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置１００は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の装置１００によって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置１００が確立することを防止し、装置１００のデータ・セキュリティを向上させる。

さらに別の可能な実装では、プロセッサ１００２は、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、
第１のノードの識別子を第２のブラックリストに追加するようにさらに構成されている。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、装置１００が認証を受けていない攻撃者とのアソシエーションを確立することを防止し、装置１００のデータ・セキュリティを向上させる。

さらに別の実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続時間は１０日であってもよく、ブラックリストに追加されてから１０日後に、第１のノードの識別子がブラックリストから削除されてもよい。

さらに別の可能な実装では、プロセッサ１００２は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

アイデンティティ認証情報を検証する処理において、いくつかのパラメータは伝送プロセスにおいて失われるか又は誤って伝送されるため、アイデンティティ認証情報に対する検証も失敗する可能性があることが理解されよう。したがって、第１のノードの検証失敗の数が事前セットされた第２の閾値を超えない場合、アソシエーション要求は、第１のノードに再送されて、第１のノードとアソシエーションを確立することを要求してもよい。このようにして、システムの頑健性が向上し、装置１００によって提供されるサービスの安定した動作が保証される。さらに別の可能な実装では、プロセッサ１００２は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

さらに別の可能な実装では、プロセッサ１００２は、
第２のブラックリストに第１のノードの識別子が追加されている持続時間が第２の持続時間を超える場合、第２のブラックリストから第１のノードの識別子を削除するようにさらに構成されており、第２の持続時間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続時間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、装置１００は、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。

さらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

各モジュールの特定の実装については、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の対応する説明を参照することに留意されたい。通信装置１００は、図３又は図５Ａ、図５Ｂ、及び図５Ｃに示す実施形態の第２のノードであってもよい。

図１１は、この出願の一実施形態による、アソシエーション制御装置１１０の構造の概略図である。装置１１０は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。装置１１０は、通信ユニット１１０１及び処理ユニット１１０２を含んでもよい。ユニットの説明は以下のようである。

通信ユニット１１０１は、第２のノードから第１のアソシエーション要求を受信するように構成されている。

処理ユニット１１０２は、第２のノードのアイデンティティが信頼されていると決定し、通信ユニット１１０１を使用して、第１の認証要求を第２のノードに送信するように構成されており、第１の認証要求は、第１の完全性検査データを含む。

通信ユニット１１０１は、第２のノードから第１の認証応答を受信するようにさらに構成されており、第１の認証応答は、第２の完全性検査データを含む。

処理ユニット１１０２は、第２の完全性検査データに基づいて、第１の認証応答に対してメッセージ完全性検査を実行するようにさらに構成されている。

処理ユニット１１０２は、第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１の認証失敗カウンタを更新するようにさらに構成されている。第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定した後に、装置は、アソシエーションが実行される前に、第２のノードからの認証応答メッセージに対してメッセージ完全性検査を実行することがさらに必要である。メッセージ完全性検査が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよく、その結果、攻撃者が認証処理においてデータ（例えば、アイデンティティ認証情報）を改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

いくつかの実装では、処理モジュール１１０２は、具体的には、
第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第２のノードの識別子が第１のブラックリストにないことを決定することか、
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティティが信頼されており、かつ第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている。

装置は、ブラックリスト又はホワイトリストを使用して、アソシエーションを要求するノードを制御し、その結果、アイデンティ認証が信頼されていない第２のノードに対して実行される必要がない。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

いくつかの実装では、処理モジュール１１０２は、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第２のノードの識別子が第１のホワイトリストにあることを決定することか、又は
第２のノードの識別子が第１のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第２のノードの識別子が第１のホワイトリストにない場合、第１の確認応答表示情報を取得することであって、第１の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

さらに別の可能な実装では、処理ユニット１１０２は、
第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、第１のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第１のアソシエーション閾値が装置に事前セットされていることが分かる。第２のノードからのアソシエーション要求は、アソシエーションされたノードが事前セットされた第１のアソシエーション閾値以下であるときにのみ受信されてもよい。第１の閾値は、装置によって提供され得るサービスの支持容量を制限してもよい。第１のアソシエーション閾値を超えるときに、装置は、アソシエーション要求をもはや受信又は処理しなくてもよく、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、処理ユニット１１０２は、
第１の認証応答に対する完全性検査が成功した場合、第２のノードと共有される共有鍵に基づいて、第２のアイデンティティ認証情報に対して検証を実行することと、
第２のアイデンティティ認証情報に対する検証が失敗した場合、第１の認証失敗カウンタを更新することであって、第１の認証失敗カウンタは、第２のノードの検証失敗の数を示す、こととを行うようにさらに構成されている。

装置は、第２のノードのアイデンティティが信頼されていると決定した後に、完全性検査が成功した場合、第２のノードと共有される共有鍵に基づいて、第２のノードのアイデンティティに対して検証を実行することが分かる。検証が失敗した場合、検証失敗の数が更新される。検証失敗の数は、第２のノードのアイデンティティが信頼されているかどうかを後で決定するために使用されてもよく、その結果、複数回検証されなかったノードは、信頼されているともはや決定されなくてもよい。信頼されていると決定されないノードに対しては、（例えば、認証要求を送信する）ノードの認証要求はもはや処理されなくてもよく、ノードが多数の要求を処理することで動作停止することを防止し、サービスの正常な動作を保証する。

さらに別の可能な実装では、通信ユニット１１０１は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション応答を第２のノードに送信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第２のノードのアイデンティティが信頼されていることがされた決定された後に、アイデンティティ認証が成功した場合、第１のアソシエーション応答が第２のノードに送信されてもよいことが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、通信が実行され得ることを第２のノードに通知するために使用されてもよい。

さらに別の可能な実装では、処理ユニット１１０２は、
第２のアイデンティティ認証情報に対する検証が成功した場合、第１のアソシエーション失敗カウンタをリセットするようにさらに構成されている。

第２のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第２のノードの検証失敗の数がリセットされる必要があり、第２のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

さらに別の可能な実装では、処理ユニット１１０２は、
第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、第２のノードの識別子を第１のブラックリストに追加するようにさらに構成されている。

第２のノードの検証失敗の数が事前セットされた第１の閾値を超える場合、第２のノードが複数回検証されなかったことを示し、第２のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第２のノードの識別子がブラックリストに追加される。第２のノードの識別子がブラックリストに追加された後に、第２のノードのアイデンティティは、信頼されていると決定されず、認証を受けていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の実装では、第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である。

第１のブラックリストにおける事前定義又は事前設定された第１の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第１の持続時間は１週間であってもよく、ブラックリストに追加された１週間後に、第２のノードの識別子がブラックリストから削除されてもよい。

さらに別の可能な実装では、処理ユニット１１０２は、
第１のブラックリストに第２のノードの識別子が追加されている持続時間が第１の持続時間を超える場合、第１のブラックリストから第２のノードの識別子を削除することであって、第１の持続時間は、第２のノードの識別子が第１のブラックリストに追加された回数又は第２のノードのタイプのうちの少なくとも１つに関連する。

前述の実装は、第１のブラックリストの有効期間に関連する要因を説明する。第１のブラックリストの有効期間は、第２のノードが第１のブラックリストに追加された回数に関連してもよい。第２のノードが第１のブラックリストに追加された回数が多いほど、第１のブラックリストにある第２のノードの持続時間が長くなることを示す。さらに、任意選択で、第１のブラックリストに第２のノードが追加された回数が閾値を超えた後に、第２のノードが第１のブラックリストに永久的に追加されてもよい。

追加的に、第１のブラックリストの有効期間は、第２のノードのデバイス・タイプに関連してもよい。具体的には、第２のノードがあらかじめ第２のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて異なるブラックリスト有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第２のノードがマイクロホン、サウンダなどに属する場合、第２のノードは、低リスク・デバイスとみなされてもよい。第２のノードが携帯電話、コンピュータなどに属する場合、第２のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第１のノードは、第２のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。さらに別の可能な実装では、第２のノードのアイデンティティが信頼されていない場合、第１の認証要求を第２のノードに送信するステップは実行されない。

第２のノードのアイデンティティが信頼されていない場合、その後のアイデンティ認証ステップは実行されず、装置のリソースを浪費することを回避し、別のノードとの正常なアソシエーションに影響を与えることを回避することが分かる。

前述の複数のユニットの分割は、機能に基づく論理分割にすぎず、装置１１０の特定の構造に対する限定として使用されないと留意されたい。特定の実装では、いくつかの機能モジュールは、より小さな機能モジュールに細分化されてもよいし、いくつかの機能モジュールは、１つの機能モジュールに組み合わされてもよい。しかしながら、これらの機能モジュールが細分化されているか、組み合わされているかにかかわらず、アソシエーション制御処理において装置１１０によって実行される手順は、ほぼ同じである。例えば、通信ユニットは、代替的には、受信ユニット及び送信ユニットに変換されてもよい。受信ユニットは、通信ユニットのメッセージ受信機能を実装するように構成されており、送信ユニットは、通信ユニットのメッセージ送信機能を実装するように構成されている。通常、各ユニットは、ユニットのプログラム・コード（又はプログラム命令）に対応する。ユニットに対応するプログラム・コードがプロセッサ上で動作するときに、ユニットは、対応する手順を実行して、対応する機能を実装することが可能となる。

各ユニットの実装については、図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態の対応する説明を参照することに留意されたい。装置１１０は、図６Ａ、図６Ｂ及び図６Ｃに示す実施形態の第１のノードであってもよい。

図１２は、この出願の一実施形態による、アソシエーション制御装置１２０の構造の概略図である。装置１２０は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。装置１２０は、処理ユニット１２０１及び通信ユニット１２０２を含んでもよい。ユニットの説明は以下のようである。

処理ユニット１２０１は、第１のノードのアイデンティティが信頼されていると決定し、通信ユニット１２０２を使用して、第１のアソシエーション要求を前記第１のノードに送信するように構成されている。

通信ユニット１２０２は、第１のノードから第１の認証要求を受信するようにさらに構成されている。第１の認証要求は、第１のアイデンティティ認証情報及び第１の完全性検査データを含む。

処理ユニット１２０１は、第１の完全性検査データに基づいて、第１の認証要求に対してメッセージ完全性検査を実行するようにさらに構成されている。

通信ユニット１２０２は、第１の認証要求に対するメッセージ完全性検査が成功した場合、第１の認証応答を第１のノードに送信するようにさらに構成されており、第１の認証応答は、第２の完全性検査データを含む。

この出願のこの実施形態では、第２のノードのアイデンティティが信頼されていると決定した後、装置は、通信が実行される前に、第１のノードに対する認証（例えば、アイデンティティ認証情報を使用した検証）を実行することがさらに必要である。攻撃者が認証処理においてデータを改ざんすることを防止するために、第１の認証要求に対してメッセージ完全性検査が最初に実行される必要がある。第１のノードとのアソシエーションは、メッセージ完全性検査が成功したときにのみ許可され、その結果、攻撃者がメッセージ・コンテンツを改ざんすることが防止され得る。これは、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

いくつかの実装では、処理モジュール１２０１は、具体的には、
第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードの識別子が第２のブラックリストにないことを決定することか、
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第１のノードのアイデンティティが信頼されており、かつ第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うようにさらに構成されている。

前述の方法では、アソシエーションされたノードは、ブラックリスト又はホワイトリストを使用して、制御されてもよく、装置は、信頼されていない第１のノードにアソシエーション要求を送信しないように制御されてもよい。これは、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、装置のデータ・セキュリティを向上させる。

いくつかの実装では、処理モジュール１２０１は、具体的には、
第１のノードと第２のノードとの間の共有鍵のタイプが事前設定されたタイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、
第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプである場合、第１のノードの識別子が第２のホワイトリストにあることを決定することか、又は
第１のノードの識別子が第２のブラックリストになく、第１のノードと第２のノードとの間の共有鍵のタイプがパスワード生成タイプであり、第１のノードの識別子が第２のホワイトリストにない場合、第２の確認応答表示情報を取得することであって、第２の確認応答表示情報は、第２のノードのアイデンティが信頼されていることを示す、ことを行うように構成されている。

さらに別の可能な実装では、処理ユニット１２０１は、
第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、第２のアソシエーション数は、現在アソシエーションされているノードの数を示す。

第２のアソシエーション閾値が装置に事前セットされていることが分かる。アソシエーション要求は、アソシエーションされたノードが事前セットされた第２のアソシエーション閾値以下であるときにのみ第１のノードに送信されてもよい。第２の閾値は、装置にアソシエーションされ得るノードの数を制限してもよい。第２のアソシエーション閾値を超えるときに、装置は、別のノードにアソシエーションされることができず、装置と装置にアソシエーションされた別のノードとの間の通信に影響を与えず、装置によって提供されるサービスの安定した動作を保証する。

さらに別の可能な実装では、通信ユニット１２０２は、
第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、第１のアソシエーション応答は、第１のノードが第２のノードとアソシエーションを確立することを示すために使用される。

第１のノードのアイデンティティが信頼されていると決定された後、第２のノード上で第１のノードによって実行されたアイデンティティ認証が成功した場合、装置は、第１のノードから第１のアソシエーション応答を受信することが分かる。アソシエーション応答は、第２のノードとのアソシエーションを確立することを装置に示すために使用される。さらに、第１の応答メッセージは、アソシエーションが成功し、その後の通信が実行され得ることを装置に通知してもよい。

さらに別の可能な実装では、処理ユニット１２０１は、
第２の認証失敗カウンタをリセットするようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティが信頼されていると決定された後に、アイデンティティ認証が成功した場合、第１のノードの検証失敗の数がリセットされる必要があり、第１のノードのアイデンティのその後の決定に影響を与えることを回避し、装置によって提供されるサービスの安定した動作を保証することが分かる。

さらに別の可能な実装では、処理ユニット１２０１は、
第１の認証応答に対するメッセージ完全性検査が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

通常、第１の認証応答に対するメッセージ完全性検査が失敗した場合、第１の認証応答メッセージがもはや完全でないか、攻撃者によって修正されていることを示す。したがって、第１のノードの検証失敗の数が更新され、検証失敗の数は、第１のノードのアイデンティティが信頼されているかどうかをその後に決定するために使用されてもよい。

さらに別の可能な実装では、第１の認証要求メッセージは、第１のアイデンティティ認証情報をさらに含む。処理ユニット１２０１は、第１の認証応答に対するメッセージ完全性検査が成功した場合、第１のノードと共有される共有鍵に基づいて、第１のアイデンティティ認証情報に対して検証を実行するようにさらに構成されている。

通信ユニット１２０２は、第１のアイデンティティ認証情報に対する検証が成功した場合、第１の認証応答を第１のノードに送信するようにさらに構成されている。

第１のノードのアイデンティティが信頼されていると決定された後、完全性検査が成功した場合、第１のノードと共有される共有鍵に基づいて、第１のノードのアイデンティティに対する検証が実行されることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の装置によって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションをノードが確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の可能な実装では、処理ユニット１２０１は、
第１のアイデンティティ認証情報に対する検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、第２の認証失敗カウンタは、第１のノードの検証失敗の数を示す。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティ確認が信頼されているかどうかをその後に決定するために使用されてもよく、その結果、複数回検証されないノードが、信頼されているともはや決定されなくてもよいことが分かる。信頼されていると決定されないノードに対しては、アソシエーション要求がノードにもはや送信されなくてもよく、ノードによって提供されるサービスの正常な動作を保証する。さらに別の可能な実装では、処理ユニット１２０１は、
第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、
第１のノードの識別子を第２のブラックリストに追加するようにさらに構成されている。

第１のノードの検証失敗の数が事前設定された第１の閾値を超える場合、第１のノードが複数回検証されなかったことを示し、第１のノードがアソシエーション要求を頻繁に送信する攻撃者であり得ることが分かる。したがって、第１のノードの識別子がブラックリストに追加される。第１のノードの識別子がブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証を受けていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の実装では、第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である。

第２のブラックリストにおける事前定義又は事前設定された第２の持続期間が、ブラックリストの有効期間とみなされ得ることが分かる。例えば、ブラックリストの第２の持続時間は１０日であってもよく、ブラックリストに追加されてから１０日後に、第１のノードの識別子がブラックリストから削除されてもよい。

さらに別の可能な実装では、処理ユニット１２０１は、第２の認証失敗カウンタの値が第２の閾値未満であることを決定するようにさらに構成されている。

通信ユニットは、第１のノードに第２のアソシエーション要求を送信するようにさらに構成されている。

第１のノードのアイデンティティ認証情報に対する検証が失敗した場合、装置は、第１のノードのアイデンティティ検証失敗の数を更新し、検証失敗の数は、ノードのアイデンティティが信頼されているかどうかをその後に決定するために使用され得ることが分かる。したがって、攻撃者が識別子のようなアイデンティを修正することによって、攻撃者の第１のノードによって実行されるアソシエーション制御を避けることが難しく、認証されていない攻撃者とのアソシエーションを装置が確立することを防止し、ノードのデータ・セキュリティを向上させる。

さらに別の可能な実装では、処理ユニット１２０１は、
第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
第３の確認応答表示情報を取得することと、
第１のノードに第２のアソシエーション要求を送信することと、を行うようにさらに構成されている。

第２のアソシエーション要求が再送される前に、確認応答表示情報が取得される必要があることが分かる。第３の確認応答表示情報は、ユーザによって入力された確認応答動作に基づいて取得される表示情報であってもよく、確認応答動作は、出力されたプロンプト情報の確認応答であってもよい。例えば、プロンプト情報が出力されて、検証が失敗し、アソシエーション要求が再度開始される必要があることをユーザにリマインドしてもよい。ユーザ確認応答動作が受信され、第３の確認応答表示情報が取得された後に、第２のアソシエーション要求が第１のノードに送信される。このようにして、ユーザは、再度アソシエーションが必要である第１のノードのアイデンティティを検証し、その結果、信頼されていないノードとのアソシエーションが回避され、通信セキュリティが保証される。

さらに別の可能な実装では、処理ユニット１２０１は、
第２のブラックリストに第１のノードの識別子が追加されている持続時間が第２の持続時間を超える場合、第２のブラックリストから第１のノードの識別子を削除するようにさらに構成されており、第２の持続時間は、第１のノードの識別子が第２のブラックリストに追加された回数又は第１のノードのタイプに関連する。

前述の実装は、第２のブラックリストの有効期間に関連する要因を説明する。第２のブラックリストの有効期間は、第１のノードがブラックリストに追加された回数に関連してもよい。第１のノードが第２のブラックリストに追加された回数が多いほど、第２のブラックリストにある第１のノードの持続時間が長くなることを示す。さらに、任意選択で、第２のブラックリストに第１のノードが追加された回数が閾値を超えた後に、第１のノードが第２のブラックリストに永久的に追加されてもよい。

追加的に、第２のブラックリストの有効期間は、第１のノードのデバイス・タイプに関連してもよい。具体的には、第１のノードがあらかじめ第１のノードのデバイス・タイプを取得してもよく、異なるデバイス・タイプに基づいて第２ブラックリストの異なる有効期間が決定される。例えば、デバイス・タイプは、高リスク・デバイス又は低リスク・デバイスを含んでもよい。第１のノードがスマート・コックピット・ドメイン・コントローラＣＤＣ、バーチャル・リアリティ・デバイスＡＲなどに属する場合、第１のノードは、低リスク・デバイスとみなされてもよい。第１のノードがサーバ、コンピュータなどに属する場合、第１のノードは、高リスクデバイスとみなされてもよい。高リスク・デバイスのブラックリスト有効期間は、低リスク・デバイスのブラックリスト有効期間よりも長い。さらに、第２のノードは、第１のノードに対応するブラックリスト有効期間をさらに事前定義してもよい。詳細は、ここでは再度説明されない。さらに別の可能な実装では、第１のノードのアイデンティティが信頼されていない場合、第１のアソシエーション要求を第１のノードに送信するステップは実行されない。

第１のノードのアイデンティティが信頼されていない場合、アイデンティティ認証要求は第１のノードにもはや送信されず、ノードのリソースを浪費することを回避することが分かる。

前述の複数のユニットの分割は、機能に基づく論理分割にすぎず、装置１２０の特定の構造に対する限定として使用されないと留意されたい。特定の実装では、いくつかの機能モジュールは、より小さな機能モジュールに細分化されてもよいし、いくつかの機能モジュールは、１つの機能モジュールに組み合わされてもよい。しかしながら、これらの機能モジュールが細分化されているか、組み合わされているかにかかわらず、アソシエーション制御処理において装置１２０によって実行される手順は、ほぼ同じである。例えば、通信ユニットは、代替的には、受信ユニット及び送信ユニットに変換されてもよい。受信ユニットは、通信ユニットのメッセージ受信機能を実装するように構成されており、送信ユニットは、通信ユニットのメッセージ送信機能を実装するように構成されている。通常、各ユニットは、ユニットのプログラム・コード（又はプログラム命令）に対応する。ユニットに対応するプログラム・コードがプロセッサ上で動作するときに、ユニットは、対応する手順を実行して、対応する機能を実装することが可能となる。

各ユニットの実装については、図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態の対応する説明を参照することに留意されたい。装置１２０は、図６Ａ、図６Ｂ及び図６Ｃに示す実施形態の第２のノードであってもよい。

図１３は、この出願の一実施形態による通信装置１３０の構造の概略図である。装置１３０は、ノードであってもよいし、ノード内のチップ又は集積回路のようなコンポーネントであってもよい。通信装置１３０は、少なくとも１つのメモリ１３０１及び少なくとも１つのプロセッサ１３０２を含んでもよい。任意選択で、装置は、バス１３０３をさらに含む。任意選択で、装置は、通信インターフェース１３０４をさらに含んでもよい。メモリ１３０１、プロセッサ１３０２、及び通信インターフェース１３０４は、バス１３０３を介して接続される。

メモリ１３０１は記憶空間を提供するように構成され、記憶空間はオペレーティング・システム及びコンピュータ・プログラムのようなデータを記憶してもよい。メモリ１３０１は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＣＤ－ＲＯＭなどのうちの１つ又はそれらの組み合わせであってもよい。

プロセッサ１３０２は、算術演算及び／又は論理演算を実行するモジュールであり、具体的には、ＣＰＵ、ＧＰＵ、ＭＰＵ、ＡＳＩＣ、ＦＰＧＡ、及びＣＰＬＤなどの処理モジュールのうちの１つ又はそれらの組み合わせであってもよい。

通信インターフェース１３０４は、外部から送信されたデータを受信し、及び／又は外部へデータを送信するように構成されており、イーサネット・ケーブルのような有線リンクのインターフェースであってもよいし、無線リンク（Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈなど）インターフェースであってもよい。任意選択で、通信インターフェース１３０４は、インターフェースに結合された送信機（例えば、無線周波数送信機又はアンテナ）、受信機などを含んでもよい。

通信装置１３０内のプロセッサ１３０２は、メモリ１３０１に記憶されたコンピュータ・プログラムを読み出して、前述のアソシエーション制御方法、例えば、図６Ａ、図６Ｂ、及び図６Ｃに記載のアソシエーション制御方法を実行するように構成されている。具体的な実装については、図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態の対応する説明を参照のこと。通信装置１３０は、図６Ａ、図６Ｂ及び図６Ｃに示す実施形態の第１のノードであってもよい。

図１４は、この出願の一実施形態による通信装置１４０の構造の概略図である。通信装置１４０は、少なくとも１つのメモリ１４０１及び少なくとも１つのプロセッサ１４０２を含んでもよい。任意選択で、装置は、バス１４０３をさらに含む。任意選択で、装置は、通信インターフェース１４０４をさらに含んでもよい。メモリ１４０１、プロセッサ１４０２、及び通信インターフェース１４０４は、バス１４０３を介して接続される。

メモリ１４０１は記憶空間を提供するように構成され、記憶空間はオペレーティング・システム及びコンピュータ・プログラムのようなデータを記憶してもよい。メモリ１４０１は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＣＤ－ＲＯＭなどのうちの１つ又はそれらの組み合わせであってもよい。

プロセッサ１４０２は、算術演算及び／又は論理演算を実行するモジュールであり、具体的には、ＣＰＵ、ＧＰＵ、ＭＰＵ、ＡＳＩＣ、ＦＰＧＡ、及びＣＰＬＤなどの処理モジュールのうちの１つ又はそれらの組み合わせであってもよい。

通信インターフェース１４０４は、外部から送信されたデータを受信し、及び／又は外部へデータを送信するように構成されており、イーサネット・ケーブルのような有線リンクのインターフェースであってもよいし、無線リンク（Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈなど）インターフェースであってもよい。任意選択で、通信インターフェース１３０４は、インターフェースに結合された送信機（例えば、無線周波数送信機又はアンテナ）、受信機などを含んでもよい。

通信装置１４０内のプロセッサ１４０２は、メモリ１４０１に記憶されたコンピュータ・プログラムを読み出して、前述のアソシエーション制御方法、例えば、図６Ａ、図６Ｂ、及び図６Ｃに記載のアソシエーション制御方法を実行するように構成されている。具体的な実装については、図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態の対応する説明を参照のこと。通信装置１４０は、図６Ａ、図６Ｂ及び図６Ｃに示す実施形態の第２のノードであってもよい。

この出願の一実施形態は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、コンピュータ・プログラムを記憶する。コンピュータ・プログラムが１つ以上のプロセッサ上で動作するときに、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す任意の実施形態の方法が実行される。

この出願の一実施形態は、チップ・システムをさらに提供する。チップ・システムは、少なくとも１つのプロセッサ、メモリ、及びインターフェース回路を含む。インターフェース回路は、少なくとも１つのプロセッサに対する情報入出力を提供するように構成されており、少なくとも１つのメモリは、コンピュータ・プログラムを記憶し、コンピュータ・プログラムが１つ以上のプロセッサ上で動作するときに、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す任意の実施形態の方法が実行される。

この出願の一実施形態は、スマート・コックピット製品をさらに提供する。スマート・コックピット製品は、第１のノード（例えば、車両コックピット・ドメイン・コントローラＣＤＣ）を含む。第１のノードは、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す任意の実施形態の第１のノードである。さらに、スマート・コックピット製品は、第２のノード（例えば、カメラ、スクリーン、マイクロホン、スピーカ、レーダ、電子キー、受動入力受動スタート・システム・コントローラなどのモジュールのうちの少なくとも１つ）を含む。第２のノードは、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す任意の実施形態の第２のノードである。

この出願の一実施形態は、車両をさらに提供する。車両は、第１のノード（例えば、車両コックピット・ドメイン・コントローラＣＤＣ）を含む。さらに、車両は、第２のノード（例えば、カメラ、スクリーン、マイクロホン、スピーカ、レーダ、電子キー、受動入力受動スタート・システム・コントローラなどのモジュールのうちの少なくとも１つ）を含む。第１のノードは、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態の第１のノードであり、第２のノードは、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す実施形態の第２のノードである。

この出願の一実施形態は、コンピュータ・プログラム製品をさらに提供する。コンピュータ・プログラム製品が１つ以上のプロセッサ上で動作するときに、図３、図５Ａ、図５Ｂ、及び図５Ｃ、又は図６Ａ、図６Ｂ、及び図６Ｃに示す任意の実施形態におけるアソシエーション制御方法が実行されてもよい。代替的には、車両は、無人機、ロボット、又は輸送車両のようなインテリジェント端末で置き換えてもよい。

前述の実施形態の全部又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせを使用して実装されてもよい。ソフトウェアが前述の実施形態を実装するために使用されるときに、実施形態の全部又は一部は、コンピュータ・プログラム製品の形態で実装されてもよい。コンピュータ・プログラム製品は、１つ以上のコンピュータ命令を含む。コンピュータ・プログラム命令がロードされ、コンピュータ上で実行されるときに、この出願の実施形態による手順又は機能の全部又は部分的に実装される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータ・ネットワーク、又は他のプログラム可能な装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよいし、コンピュータ可読記憶媒体を使用して伝送されてもよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体、又は１つ以上の使用可能な媒体を一体化するサーバ若しくはデータ・センタなどのデータ記憶デバイスであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピー・ディスク、ハード・ディスク、又は磁気テープ）、光媒体（例えば、ＤＶＤ）、又は半導体媒体（例えば、ソリッド・ステート・ドライブ（ｓｏｌｉｄ－ｓｔａｔｅ ｄｒｉｖｅ、ＳＳＤ））などであってもよい。

順序調整、組み合わせ、又は削除は、実際の要件に基づいて、この出願の方法の実施形態のステップで実行されてもよい。

この出願の装置の実施形態のモジュールは、実際の要件に基づいて組み合わされ、分割され、又は削除されてもよい。

前述の説明は、この出願の単なる特定の実装であるが、この出願の保護範囲は、この出願に限定されない。この出願に開示された技術的範囲内で、当業者によって容易に理解することができる変形又は置換は、この出願の保護範囲に含まれるものとする。

任意選択で、この出願のこの実施形態のアソシエーション制御方法は、図５Ａ、図５Ｂ、及び図５Ｃに示すステップＳ５０３、又はステップＳ５０３及びステップＳ５０４をさらに含んでもよい。ステップＳ５０３及びステップＳ５０４は、具体的には、以下のようである。

具体的には、第１のノードの検証失敗の数が事前セットされた第２の閾値を超える場合、第１のノードが複数回検証されなかったことを示す。したがって、第１のノードは、認証要求を頻繁に送信する攻撃者であることがあり、第１のノードの識別子が第２のブラックリストに追加される。第１のノードの識別子が第２のブラックリストに追加された後に、第１のノードのアイデンティティは、信頼されていると決定されず、認証されていない攻撃者とのアソシエーションを第２のノードが確立することを防止し、第２のノードのデータ・セキュリティを向上させる。第１のノードの識別子は、第２のブラックリスト及び第２のホワイトリストの両方にあることはできないことが理解されよう。したがって、第１のノードの識別子が第２のブラックリストに追加されるときに、第１のノードの識別子が第２のホワイトリストにある場合、第２のホワイトリストから第１のノードの識別子が削除される必要がある。

Claims (44)

1. アソシエーション制御方法であって、
   第１のアソシエーション要求を第２のノードから受信することと、
   前記第２のノードのアイデンティティが信頼されていると決定し、第１の認証要求を前記第２のノードに送信することであって、前記第１の認証要求は、第１のアイデンティティ認証情報を含み、前記第１のアイデンティティ認証情報は、第１のノードと前記第２のノードとの間の共有鍵に基づいて生成される、ことと、
   前記第２のノードから第１の認証応答を受信することであって、前記第１の認証応答は、第２のアイデンティティ認証情報を含む、ことと、
   前記共有鍵に基づいて前記第２のアイデンティティ認証情報に対して検証を実行することと、
   前記第２のアイデンティティ認証情報に対する前記検証が失敗した場合、第１の認証失敗カウンタを更新することであって、前記第１の認証失敗カウンタは、前記第２のノードの検証失敗の数を示す、ことと、を含む、方法。
2. 前記第２のノードのアイデンティティが信頼されていると決定することは、
   前記第２のノードの識別子が第１のホワイトリストにあることを決定することか、
   前記第２のノードの識別子が第１のブラックリストにないことを決定することか、
   第１の確認応答表示情報を取得することであって、前記第１の確認応答表示情報は、前記第２のノードの前記アイデンティティが信頼されており、かつ前記第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
   第１の確認応答表示情報を取得することであって、前記第１の確認応答表示情報は、前記第２のノードの前記アイデンティティが信頼されており、かつ前記第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを含む、請求項１に記載の方法。
3. 前記第１の認証応答は、第２の完全性検査データをさらに含み、前記第２の完全性検査データは、前記第１の認証応答に対してメッセージ完全性検査を実行するために使用され、前記方法は、
   前記第１の認証応答に対する前記メッセージ完全性検査が成功したと決定することをさらに含む、請求項１又は２に記載の方法。
4. 前記方法は、第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定することであって、前記第１のアソシエーション数は、現在アソシエーションされているノードの数を示す、ことをさらに含む、請求項１～３のいずれか一項に記載の方法。
5. 前記方法は、前記第２のアイデンティティ認証情報に対する前記検証が成功した場合、第１のアソシエーション応答を前記第２のノードに送信することであって、前記第１のアソシエーション応答は、前記第１のノードが前記第２のノードとアソシエーションを確立することを示すために使用される、ことをさらに含む、請求項１～４のいずれか一項に記載の方法。
6. 前記方法は、前記第２のアイデンティティ認証情報に対する前記検証が成功した場合、第１のアソシエーション失敗カウンタをリセットすることをさらに含む、請求項１～５のいずれか一項に記載の方法。
7. 前記共有鍵に基づいた前記第２のアイデンティティ認証情報に対する前記検証が失敗した場合、第１の認証失敗カウンタを更新した後に、前記方法は、
   前記第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、前記第２のノードの前記識別子を前記第１のブラックリストに追加することをさらに含む、請求項１～４のいずれか一項に記載の方法。
8. 前記第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である、請求項７に記載の方法。
9. アソシエーション方法であって、
   第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を前記第１のノードに送信することと、
   第１の認証要求を前記第１のノードから受信することであって、前記第１の認証要求は、第１のアイデンティティ認証情報を含む、ことと、
   第２のノードと前記第１のノードの間の共有鍵に基づいて前記第１のアイデンティティ認証情報に対して検証を実行することと、
   前記第１のアイデンティティ認証情報に対する前記検証が成功した場合、前記第１のノードに第１の認証応答を送信することであって、前記第１の認証応答は、第２のアイデンティティ認証情報を含み、前記第２のアイデンティティ認証情報は、前記共有鍵に基づいて生成される、ことと、を含む、方法。
10. 第１のノードのアイデンティティが信頼されていると決定することは、
    前記第１のノードの識別子が第２のホワイトリストにあることを決定することか、
    前記第１のノードの識別子が第２のブラックリストにないことを決定することか、
    第２の確認応答表示情報を取得することであって、前記第２の確認応答表示情報は、前記第１のノードの前記アイデンティティが信頼されており、かつ前記第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
    第２の確認応答表示情報を取得することであって、前記第２の確認応答表示情報は、前記第１のノードの前記アイデンティティが信頼されており、かつ前記第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを含む、請求項９に記載の方法。
11. 前記第１の認証要求は、第１の完全性検査データをさらに含み、前記第１の完全性検査データは、前記第１の認証要求に対してメッセージ完全性検査を実行するために使用され、前記方法は、
    前記第１の認証要求に対する前記メッセージ完全性検査が成功したと決定することをさらに含む、請求項９又は１０に記載の方法。
12. 前記第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を前記第１のノードに送信する前に、前記方法は、
    第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定することであって、前記第２のアソシエーション数は、現在アソシエーションされているノードの数を示す、ことをさらに含む、請求項９～１１のいずれか一項に記載の方法。
13. 前記方法は、前記第１のノードから第１のアソシエーション応答を受信することであって、前記第１のアソシエーション応答は、前記第１のノードが前記第２のノードとアソシエーションを確立することを示すために使用される、ことをさらに含む、請求項９～１２のいずれか一項に記載の方法。
14. 前記方法は、第２の認証失敗カウンタをリセットすることであって、前記第２の認証失敗カウンタは、前記第１のノードの検証失敗の数を示す、ことをさらに含む、請求項９～１３のいずれか一項に記載の方法。
15. 前記方法は、前記第１のアイデンティティ認証情報に対する前記検証が失敗した場合、第２の認証失敗カウンタを更新することであって、前記第２の認証失敗カウンタは、前記第１のノードの検証失敗の数を示す、ことをさらに含む、請求項９～１１のいずれか一項に記載の方法。
16. 前記第１のアイデンティティ認証情報に対する前記検証が失敗した場合、第２の認証失敗カウンタを更新した後に、前記方法は、
    前記第２の認証失敗カウンタの値が第２の閾値以上であることを決定することと、
    前記第１のノードの前記識別子を前記第２のブラックリストに追加することと、をさらに含む、請求項１５に記載の方法。
17. 前記第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である、請求項１６に記載の方法。
18. 前記第１のアイデンティティ認証情報に対する前記検証が失敗した場合、第２の認証失敗カウンタを更新した後に、前記方法は、
    前記第２の認証失敗カウンタの値が第２の閾値未満であると決定することと、
    前記第１のノードに第２のアソシエーション要求を送信することと、をさらに含む、請求項１５に記載の方法。
19. アソシエーション制御装置であって、
    第２のノードから第１のアソシエーション要求を受信するように構成されている通信ユニットと、
    前記第２のノードのアイデンティティが信頼されていると決定し、前記通信ユニットを使用して、第１の認証要求を前記第２のノードに送信するように構成されている処理ユニットであって、前記第１の認証要求は、第１のアイデンティティ認証情報を含み、前記第１のアイデンティティ認証情報は、第１のノードと前記第２のノードとの間の共有鍵に基づいて生成される、処理ユニットと、を含み、
    前記通信ユニットは、前記第２のノードから第１の認証応答を受信するようにさらに構成されており、前記第１の認証応答は、第２のアイデンティティ認証情報を含み、
    前記処理ユニットは、前記共有鍵に基づいて前記第２のアイデンティティ認証情報に対して検証を実行するようにさらに構成されており、
    前記処理ユニットは、前記第２のアイデンティティ認証情報に対する前記検証が失敗した場合、第１の認証失敗カウンタを更新するようにさらに構成されており、前記第１の認証失敗カウンタは、前記第２のノードの検証失敗の数を示す、装置。
20. 前記処理ユニットは、具体的には、
    前記第２のノードの識別子が第１のホワイトリストにあることを決定することか、
    前記第２のノードの識別子が第１のブラックリストにないことを決定することか、
    第１の確認応答表示情報を取得することであって、前記第１の確認応答表示情報は、前記第２のノードの前記アイデンティティが信頼されており、かつ前記第２のノードの識別子が第１のブラックリストにないことを示す、ことか、又は
    第１の確認応答表示情報を取得することであって、前記第１の確認応答表示情報は、前記第２のノードの前記アイデンティティが信頼されており、かつ前記第２のノードの識別子が第１のブラックリストにも第１のホワイトリストにもないことを示す、ことを行うように構成されている、請求項１９に記載の装置。
21. 前記第１の認証応答は、第２の完全性検査データをさらに含み、前記第２の完全性検査データは、前記第１の認証応答に対してメッセージ完全性検査を実行するために使用され、
    前記処理ユニットは、具体的には、
    前記第１の認証応答に対する前記メッセージ完全性検査が成功したと決定するように構成されている、請求項１９又は２０に記載の装置。
22. 前記処理ユニットは、第１のアソシエーション数が事前セットされた第１のアソシエーション閾値以下であることを決定するようにさらに構成されており、前記第１のアソシエーション数は、現在アソシエーションされているノードの数を示す、請求項１９～２１のいずれか一項に記載の装置。
23. 前記通信ユニットは、前記第２のアイデンティティ認証情報に対する前記検証が成功した場合、第１のアソシエーション応答を前記第２のノードに送信するようにさらに構成されており、前記第１のアソシエーション応答は、前記第１のノードが前記第２のノードとアソシエーションを確立することを示すために使用される、請求項１９～２２のいずれか一項に記載の装置。
24. 前記処理ユニットは、前記第２のアイデンティティ認証情報に対する前記検証が成功した場合、第１のアソシエーション失敗カウンタをリセットするようにさらに構成されている、請求項１９～２３のいずれか一項に記載の装置。
25. 前記処理ユニットは、前記第１の認証失敗カウンタの値が第１の閾値以上であることを決定し、前記第２のノードの前記識別子を前記第１のブラックリストに追加するようにさらに構成されている、請求項１９～２２のいずれか一項に記載の装置。
26. 前記第１のブラックリストの有効期間は、事前定義又は事前設定された第１の持続期間である、請求項２５に記載の方法。
27. アソシエーション制御装置であって、
    第１のノードのアイデンティティが信頼されていると決定し、通信ユニットを使用して、第１のアソシエーション要求を前記第１のノードに送信するように構成されている処理ユニットと、
    前記第１のノードから第１の認証要求を受信するようにさらに構成されている前記通信ユニットと、を含み、前記第１の認証要求は、第１のアイデンティティ認証情報を含み、
    前記処理ユニットは、第２のノードと前記第１のノードの間の共有鍵に基づいて前記第１のアイデンティティ認証情報に対して検証を実行するようにさらに構成されており、
    前記通信ユニットは、前記第１のアイデンティティ認証情報に対する前記検証が成功した場合、前記第１のノードに第１の認証応答を送信するようにさらに構成されており、前記第１の認証応答は、第２のアイデンティティ認証情報を含み、前記第２のアイデンティティ認証情報は、前記共有鍵に基づいて生成される、装置。
28. 前記処理ユニットは、具体的には、
    前記第１のノードの識別子が第２のホワイトリストにあることを決定することか、
    前記第１のノードの識別子が第２のブラックリストにないことを決定することか、
    第２の確認応答表示情報を取得することであって、前記第２の確認応答表示情報は、前記第１のノードの前記アイデンティティが信頼されており、かつ前記第１のノードの識別子が第２のブラックリストにないことを示す、ことか、又は
    第２の確認応答表示情報を取得することであって、前記第２の確認応答表示情報は、前記第１のノードの前記アイデンティティが信頼されており、かつ前記第１のノードの識別子が第２のブラックリストにも第２のホワイトリストにもないことを示す、ことを行うように構成されている、請求項２７に記載の装置。
29. 前記第１の認証要求は、第１の完全性検査データをさらに含み、前記第１の完全性検査データは、前記第１の認証要求に対してメッセージ完全性検査を実行するために使用され、
    前記処理ユニットは、前記第１の認証要求に対する前記メッセージ完全性検査が成功したと決定するようにさらに構成されている、請求項２７又は２８に記載の装置。
30. 前記処理ユニットは、第２のアソシエーション数が事前セットされた第２のアソシエーション閾値以下であることを決定するようにさらに構成されており、前記第２のアソシエーション数は、現在アソシエーションされているノードの数を示す、請求項２７～２９のいずれか一項に記載の装置。
31. 前記通信ユニットは、前記第１のノードから第１のアソシエーション応答を受信するようにさらに構成されており、前記第１のアソシエーション応答は、前記第１のノードが前記第２のノードとアソシエーションを確立することを示すために使用される、請求項２７～３０のいずれか一項に記載の装置。
32. 前記処理ユニットは、第２の認証失敗カウンタをリセットするようにさらに構成されており、前記第２の認証失敗カウンタは、前記第１のノードの検証失敗の数を示す、ことをさらに含む、請求項２７～３１のいずれか一項に記載の装置。
33. 前記処理ユニットは、前記第１のアイデンティティ認証情報に対する前記検証が失敗した場合、第２の認証失敗カウンタを更新するようにさらに構成されており、前記第２の認証失敗カウンタは、前記第１のノードの検証失敗の数を示す、ことをさらに含む、請求項２７～２９のいずれか一項に記載の装置。
34. 前記処理ユニットは、前記第２の認証失敗カウンタの値が第２の閾値以上であることを決定し、前記第１のノードの前記識別子を前記第２のブラックリストに追加するようにさらに構成されている、請求項３３に記載の装置。
35. 前記第２のブラックリストの有効期間は、事前定義又は事前設定された第２の持続期間である、請求項３４に記載の装置。
36. 前記処理ユニットは、前記第２の認証失敗カウンタの値が第２の閾値未満であることを決定するようにさらに構成されており、
    前記通信ユニットは、前記第１のノードに第２のアソシエーション要求を送信するようにさらに構成されている、請求項３３に記載の装置。
37. アソシエーション制御方法であって、
    第１のアソシエーション要求を第２のノードから受信することと、
    前記第２のノードのアイデンティティが信頼されていると決定し、第１の認証要求を前記第２のノードに送信することであって、前記第１の認証要求は、第１の完全性検査データを含む、ことと、
    前記第２のノードから第１の認証応答を受信することであって、前記第１の認証応答は、第２の完全性検査データを含む、ことと、
    前記第２の完全性検査データに基づいて、前記第１の認証応答に対してメッセージ完全性検査を実行することと、
    前記第１の認証応答に対する前記メッセージ完全性検査が失敗した場合、第１の認証失敗カウンタを更新することであって、前記第１の認証失敗カウンタは、前記第２のノードの検証失敗の数を示す、ことと、を含む、方法。
38. アソシエーション方法であって、
    第１のノードのアイデンティティが信頼されていると決定し、第１のアソシエーション要求を前記第１のノードに送信することと、
    第１の認証要求を前記第１のノードから受信することであって、前記第１の認証要求は、第１の完全性検査データを含む、ことと、
    前記第１の完全性検査データに基づいて、前記第１の認証要求に対してメッセージ完全性検査を実行することと、
    前記第１の認証要求に対する前記メッセージ完全性検査が成功した場合、第１の認証応答を前記第１のノードに送信することと、を含む、方法。
39. アソシエーション制御装置であって、
    第２のノードから第１のアソシエーション要求を受信するように構成されている通信ユニットと、
    前記第２のノードのアイデンティティが信頼されていると決定し、前記通信ユニットを使用して、第１の認証要求を前記第２のノードに送信するように構成されている処理ユニットであって、前記第１の認証要求は、第１の完全性検査データを含む、処理ユニットと、を含み、
    前記通信ユニットは、前記第２のノードから第１の認証応答を受信するようにさらに構成されており、前記第１の認証応答は、第２の完全性検査データを含み、
    前記処理ユニットは、前記第２の完全性検査データに基づいて、前記第１の認証応答に対してメッセージ完全性検査を実行するようにさらに構成されており、
    前記処理ユニットは、前記第１の認証応答に対する前記メッセージ完全性検査が失敗した場合、第１の認証失敗カウンタを更新するようにさらに構成されており、前記第１の認証失敗カウンタは、前記第２のノードの検証失敗の数を示す、装置。
40. アソシエーション制御装置であって、
    第１のノードのアイデンティティが信頼されていると決定し、通信ユニットを使用して、第１のアソシエーション要求を前記第１のノードに送信するように構成されている処理ユニットと、
    前記第１のノードから第１の認証要求を受信するようにさらに構成されている前記通信ユニットと、を含み、前記第１の認証要求は、第１の完全性検査データを含み、
    前記処理ユニットは、前記第１の完全性検査データに基づいて、前記第１の認証要求に対してメッセージ完全性検査を実行するようにさらに構成されており、
    前記通信ユニットは、前記第１の認証要求に対する前記メッセージ完全性検査が成功した場合、第１の認証応答を前記第１のノードに送信するようにさらに構成されている、装置。
41. 通信装置であって、前記装置は、少なくとも１つのプロセッサと、通信インターフェースと、を含み、前記少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、その結果、前記装置が、請求項１～８のいずれか一項に記載の方法又は請求項９～１８のいずれか一項に記載の方法を実装するように構成されている、通信装置。
42. 通信装置であって、前記装置は、少なくとも１つのプロセッサと、通信インターフェースと、を含み、前記少なくとも１つのプロセッサは、少なくとも１つのメモリに記憶されたコンピュータ・プログラムを呼び出し、前記装置が、請求項３７又は３８に記載の方法を実装するように構成されている、通信装置。
43. 通信システムであって、
    請求項１９～２６のいずれか一項に記載の装置を含む第１のノードと、
    請求項２７～３６のいずれか一項に記載の装置を含む第２のノードと、を含む、通信システム。
44. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は、コンピュータ・プログラムを記憶し、前記コンピュータ・プログラムが１つ以上のプロセッサ上で動作するときに、請求項１～８及び３７のいずれか一項に記載の方法、又は請求項９～１８及び３８のいずれか一項に記載の方法が実行される、コンピュータ可読記憶媒体。
    

Images