特許 7538342 リモートサーバから端末にメッセージを送信する方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-13

(45)【発行日】2024-08-21

(54)【発明の名称】リモートサーバから端末にメッセージを送信する方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240814BHJP

   H04W 12/72 20210101ALI20240814BHJP

   H04W 12/03 20210101ALI20240814BHJP

   H04W 12/106 20210101ALI20240814BHJP

【ＦＩ】

H04L9/32 200A

H04L9/32 200F

H04W12/72

H04W12/03

H04W12/106

【請求項の数】 12

(21)【出願番号】P 2023517662

(86)(22)【出願日】2021-08-31

(65)【公表番号】

(43)【公表日】2023-09-29

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

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

(87)【国際公開日】2022-03-24

【審査請求日】2023-04-18

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

(32)【優先日】2020-09-17

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

(73)【特許権者】

【識別番号】522230381

【氏名又は名称】タレス ディアイエス フランス エスアーエス

(74)【代理人】

【識別番号】100086368

【弁理士】

【氏名又は名称】萩原 誠

(72)【発明者】

【氏名】リ タン ファン

(72)【発明者】

【氏名】ジャン－フランソワ グロス

(72)【発明者】

【氏名】ヴァンサン ダニー

【審査官】平井 誠

(56)【参考文献】

【文献】国際公開第２００７／０３２４９９（ＷＯ，Ａ１）

【文献】特表２０１４－５０４３８９（ＪＰ，Ａ）

【文献】特表２０１９－５２７５１８（ＪＰ，Ａ）

【文献】特開２０２０－０１４１２０（ＪＰ，Ａ）

【文献】国際公開第２０２０／０７９２８７（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／００－４０

Ｇ０９Ｃ １／００

Ｈ０４Ｗ １２／００－８０

(57)【特許請求の範囲】

【請求項1】

秘密鍵（Ｋ１）を共有するリモートサーバ（１１）から端末（１０）にメッセージ（ＭＳＧ）を送信する方法であって、
ｉ－前記端末（１０）から前記リモートサーバ（１１）に第１のアイデンティティ（ＵＩＤ１）を送信すること、
ｉｉ－前記リモートサーバ（１１）において前記第１のアイデンティティ（ＵＩＤ１）を取得し、前記第１のアイデンティティ（ＵＩＤ１）に基づいた前記秘密鍵（Ｋ１）を取得すること、
ｉｉｉ－前記リモートサーバ（１１）において、乱数（ＵＩＤ＿ＲＡＮＤ）を選択し、前記第１のアイデンティティ（ＵＩＤ１）、前記乱数（ＵＩＤ＿ＲＡＮＤ）及び前記秘密鍵（Ｋ１）によって第２のアイデンティティ（ＵＩＤ２）を生成すること、
ｉｖ－前記リモートサーバ（１１）において、前記第１のアイデンティティ（ＵＩＤ１）、前記メッセージ（ＭＳＧ）、カウンタ値（Ｓｅｎｔ）、前記乱数（ＵＩＤ＿ＲＡＮＤ）及び前記秘密鍵（Ｋ１）から署名（ＳＩＧ）を生成すること、
ｖ－前記リモートサーバ（１１）において、前記端末（１０）に対する第１のレスポンス（Ｒｅｓｐ１）であって、前記メッセージ（ＭＳＧ）、カウンタ値（Ｓｅｎｔ）、前記署名（ＳＩＧ）及び前記乱数（ＵＩＤ＿ＲＡＮＤ）の連結である第１のレスポンス（Ｒｅｓｐ１）を生成し、前記第１のレスポンス（Ｒｅｓｐ１）を前記秘密鍵（Ｋ１）で暗号化し、暗号化した前記第１のレスポンス（Ｒｅｓｐ１^＊）を前記端末（１０）に送信すること、
ｖｉ－前記端末（１０）において、前記第１のレスポンス（Ｒｅｓｐ１）を得るために前記暗号化した第１のレスポンス（Ｒｅｓｐ１^＊）を前記秘密鍵（Ｋ１）で解読し、前記メッセージ（ＭＳＧ）、前記カウンタ値（Ｓｅｎｔ）、前記署名（ＳＩＧ）及び前記乱数（ＵＩＤ＿ＲＡＮＤ）を取得し、前記第１のレスポンス（Ｒｅｓｐ１）の予想される署名（ＸＳＩＧ）を導出し、前記署名（ＳＩＧ）が前記予想される署名（ＸＳＩＧ）と等しいかどうかを検証し、前記カウンタ値（Ｓｅｎｔ）が正しいかどうかを検証し、前記カウンタ値（Ｓｅｎｔ）が正しい場合に、前記第１のアイデンティティ（ＵＩＤ１）、前記秘密鍵（Ｋ１）及び前記乱数（ＵＩＤ＿ＲＡＮＤ）から前記第２のアイデンティティ（ＵＩＤ２）を導出することを含む方法。

【請求項2】

ステップｉｉにおいて前記リモートサーバ（１１）が前記第１のアイデンティティ（ＵＩＤ１）に基づいた前記秘密鍵（Ｋ１）を取得することができない場合、前記リモートサーバ（１１）が、ＤｏＳ攻撃が行われたと判断する、請求項１に記載の方法。

【請求項3】

前記端末（１０）に送信された暗号化された前記第１のレスポンス（Ｒｅｓｐ１^＊）が、ステップｉを実行した後の所定の時間枠内に前記端末（１０）によって受信されない場合、前記端末がカウンタの値（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）を１増加させ、ステップｉを再び実行する、請求項１又は２に記載の方法。

【請求項4】

ステップｖにおいて送信された前記第１のレスポンス（Ｒｅｓｐ１ ^＊ ）が前記端末（１０）によって受信されず、前記端末（１０）が前記第２のアイデンティティ（ＵＩＤ２）を前記リモートサーバ（１１）に送信しない場合、前記リモートサーバ（１１）が前記カウンタ値（Ｓｅｎｔ）の値を１増加させ、ステップｖｉを繰り返す、請求項３に記載の方法。

【請求項5】

ステップｉにおいて送信された前記第１のアイデンティティ（ＵＩＤ１）に対して所定の時間枠内に前記リモートサーバ（１１）から回答を受信していない場合、前記端末（１０）がカウンタの値（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）を１増加させ、ステップｉを増加させたカウンタの値（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）で繰り返す、請求項３に記載の方法。

【請求項6】

前記第１のアイデンティティ（ＵＩＤ１）及び前記第２のアイデンティティ（ＵＩＤ２）は、前記リモートサーバ（１１）により前記端末（１０）に送信されたルールに基づいて、前記端末（１０）によって前記リモートサーバ（１１）に定期的に送信される、請求項１乃至５のいずれかに記載の方法。

【請求項7】

前記リモートサーバ（１１）がＯＴＡサーバに組み込まれている、請求項１乃至６のいずれかに記載の方法。

【請求項8】

前記端末（１０）と前記リモートサーバ（１１）との間の転送プロトコルがＵＤＰである、請求項１に記載の方法。

【請求項9】

ステップｖにおける返信メッセージ（ＭＳＧ）が、前記端末（１０）に前記リモートサーバ（１１）への要求の頻度を低下させるように通知するためのものである、請求項１に記載の方法。

【請求項10】

ステップｖにおける返信メッセージ（ＭＳＧ）が、前記端末（１０）に前記リモートサーバ（１１）への要求の頻度を上昇させるように通知するためのものである、請求項１に記載の方法。

【請求項11】

ステップｖにおける返信メッセージが、オンボード鍵生成を要求するためのものである、請求項１に記載の方法。

【請求項12】

ステップｖにおける返信メッセージが、前記端末（１０）にＯＴＡサーバとのＨＴＴＰ通信を開くように通知するためのものである、請求項１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は３Ｇ、４Ｇ又は５Ｇネットワークにおける電気通信に関する。本発明は、より正確には秘密鍵を共有するリモートサーバから端末にメッセージを送信する方法に関する。

【0002】

本発明はＩｏＴ製品及び関連サービスに適用される可能性がある。

【背景技術】

【0003】

セルラ電気通信ネットワークにおける端末が、ＳｉｍカードやＵＩＣＣ（汎用集積回路カード）や埋め込みＵＩＣＣ（ｅＵＩＣＣ）のようなセキュリティエレメントを備えることが知られている。

【0004】

このセキュリティエレメントは、ＯＴＡ（無線）サーバがセキュリティエレメントに転送すべきデータを有しているかどうかを知るためにＯＴＡサーバを定期的にポーリングする必要がある。これはセキュリティエレメントにインストールされているカードアプレットによって行われる。

【0005】

カードアプレットによるＯＴＡサーバへの又はＩｏＴアプレットによる既存のポーリングメカニズム及び更新があるかどうかをチェックするリモートサーバは、デバイスがＳＭＳのないネットワークに展開されている（例えばＩｏＴ展開の）場合に頻繁に用いられる方法である。

【0006】

かかる方法には多くの欠点及び関連する問題がある。主な問題は、方法の拡張性及びセキュリティ（ＰＫＩ）に関連する問題である：
－拡張性問題は以下を含む：
〇ポーリングサーバが、ポーリングを実行するリモートデバイスの数及びポーリングイベントの回数／頻度に圧倒され得ること、
〇ポーリングメカニズムのオーバーヘッドは、ポーリングシステムの両側のパフォーマンスに影響を及ぼす：デバイス側でオーバーヘッドが過剰なバッテリ電力を消費する可能性があり、サーバ側でオーバーヘッドが計算能力及び通信帯域幅を消費すること。
－セキュリティ問題は以下を含む：
〇ＰＫＩベースのメカニズムが使用され得るが、大抵の場合作用をもたらさないポーリングメカニズムにデバイス側で過剰な電力を消費することになること、
〇デバイスのアイデンティティプライバシーが保護されなければならず、デバイスのトレーサビリティが非公開鍵プロトコルで回避されるべきであること、
〇交換には機密性及び完全性保護が必要であること。

【発明の概要】

【0007】

本発明はこれらの問題に対する解決策を提案する。

【0008】

より正確には、本発明は、秘密鍵を共有するリモートサーバから端末にメッセージを送信する方法であって、
ｉ－端末からリモートサーバに第１のアイデンティティを送信すること、
ｉｉ－リモートサーバにおいて第１のアイデンティティを取得し、第１のアイデンティティに基づいた秘密鍵を取得すること、
ｉｉｉ－リモートサーバにおいて、乱数を選択し、第１のアイデンティティ、乱数及び秘密鍵によって第２のアイデンティティを生成すること、
ｉｖ－リモートサーバにおいて、第１のアイデンティティ、メッセージ、カウンタ値、乱数及び秘密鍵から署名を生成すること、
ｖ－リモートサーバにおいて、端末に対する第１のレスポンスであって、メッセージ、カウンタ値、署名及び乱数の連結である第１のレスポンスを生成し、第１のレスポンスを秘密鍵で暗号化し、暗号化した第１のレスポンスを端末に送信すること、
ｖｉ－端末において、第１のレスポンスを得るために暗号化した第１のレスポンスを秘密鍵で解読し、メッセージ、カウンタ値、署名及び乱数を取得し、第１のレスポンスの予想される署名を導出し、署名が予想される署名と等しいかどうかを検証し、カウンタ値が正しいかどうかを検証し、カウンタ値が正しい場合に、第１のアイデンティティ、秘密鍵及び乱数から第２のアイデンティティを導出することを含む方法を提案する。

【0009】

好ましくは、ステップｉｉにおいてリモートサーバが第１のアイデンティティに基づいた秘密鍵を取得することができない場合、リモートサーバはＤｏＳ攻撃が行われたと判断する。

【0010】

有利には、端末に送信された暗号化した第１のレスポンス（Ｒｅｓｐ１^＊）が、ステップｉを実行した後の所定の時間枠内に端末によって受信されない場合、端末はカウンタの値（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）を１増加させ、ステップｉを再び実行する。

【0011】

好ましくは、ステップｖにおいて送信されたメッセージが端末によって受信されず、端末が第２の一意の識別子をリモートサーバに送信しない場合、リモートサーバはカウンタ値の値を１増加させ、ステップｖｉを繰り返す。

【0012】

有利には、ステップｉにおいて送信されたメッセージが所定の時間枠内にリモートサーバから回答を受信していない場合、端末はカウンタ値を１増加させ、ステップｉを新しいカウンタ値で繰り返す。

【0013】

好ましくは、一意の識別子は、リモートサーバにより端末に送信されたルールに基づいて、端末によってリモートサーバに定期的に送信される。

【0014】

リモートサーバは好ましくはＯＴＡサーバに組み込まれている。

【0015】

有利には、端末とリモートサーバとの間の転送プロトコルはＵＤＰである。

【0016】

一実施形態では、返信メッセージは、端末に要求の頻度を低下させるように通知するためのものである。

【0017】

別の実施形態では、ステップｖにおける返信メッセージは、端末に要求の頻度を上昇させるように通知するためのものである。

【0018】

代替的に、ステップｖにおける返信メッセージは、オンボード鍵生成を要求するためのものである。

【0019】

別の代替案では、ステップｖにおける返信メッセージは、端末にＯＴＡサーバとのＨＴＴＰ通信を開くように通知するためのものである。

【図面の簡単な説明】

【0020】

本発明は、添付の３つの図面の以下の説明によってより良く理解される。

【0021】

【図1】（端末とリモートサーバとの間の通信損失がない）最適なケースにおける本発明の一般概念を示す図。

【図2】ＧＴＳ１１からＳｅｃＡｐｐ１０に回答する際にメッセージが失われた場合に行われることを示す図。

【図3】ＵＩＤ１がＧＴＳ１１によって受信されない場合に行われることを示す図。

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

【0022】

図１は、本発明の一般概念（最適なケース）を説明する。

【0023】

２つのエンティティが示されている。すなわち、端末のレベルに、又はより正確に好ましくはこの端末に含まれるセキュリティエレメントのレベルにインストールされたセキュリティアプリケーション（ＳｅｃＡｐｐ１０）、及びページングサーバとも見なされ得るグローバルトリガリングサーバ（ＧＴＳ１１）。

【0024】

ＧＴＳ１１は、スタンドアロンサーバであるか又はＯＴＡプラットフォームに組み込まれている可能性がある。

【0025】

ＳｅｃＡｐｐ１０は、端末（例えばＩｏＴデバイス）又はこの端末と協働するセキュリティエレメント（ＵＩＣＣ、ｅＵＩＣＣ）にインストールされており、（最初の電源オンステップ１００において、定期的に、又はイベントの発生時に）ステップ１０１において一意の識別子（ＵＩＤ１）をＧＴＳ１１に送信することができる。このＵＩＤ１は、例えばＳｅｃＡＰＰがインストールされているセキュリティエレメントのＩＣＣＩＤであるか又はＳｅｃＡｐｐ１０のこのデバイスに一意の識別子である。ＳｅｃＡｐｐ１０は秘密鍵Ｋ１を含んでいる。Ｋ１は、ＧＴＳ１１に又はＯＴＡサーバに送信されるデータを暗号化するのにセキュリティエレメントにより使用される鍵である可能性もある。

【0026】

端末１０とリモートサーバ１１との間の転送プロトコルは好ましくはＵＤＰである。

【0027】

ＵＩＤ１を受信すると、（ＯＴＡサーバとして機能するか又はＯＴＡサーバに組み込まれている）ＧＴＳ１１は、ステップ１０２において、このＵＩＤ１に関連付けられた鍵Ｋ１（Ｋ１はまた３Ｇ及び４Ｇ電気通信ネットワークでは一般にＫｉと呼ばれる）を取得する。次いでＧＴＳ１１は、ＵＩＤ＿Ｒａｎｄと呼ばれる乱数を選択するか又は発生させ、ＵＩＤ１、ＵＩＤ＿ＲＡＮＤ及びＫ１から一意の識別子ＵＩＤ２を導出する。

【0028】

図において、｜はデータの連結に相当する。

【0029】

ＵＩＤ＿ＲＡＮＤは、オペレータのシステムに一意のＵＩＤ２を生成できるように発生及び選択される。

【0030】

次いでＧＴＳ１１は、端末１０に送信されるメッセージＭＳＧ、送信されたメッセージの発生を表す数字（Ｓｅｎｔ＝１）（ＧＴＳ１１からＳｅｃＡｐｐ１０への最初の回答である場合、通常は＃１）、受信済みのＵＩＤ１及びＵＩＤ＿Ｒａｎｄの連結の署名ＳＩＧを生成する。この署名ＳＩＧは鍵Ｋ１によって署名される。

【0031】

攻撃者が平文及び暗号文を知っている場合があるため、レスポンスで暗号化されたＵＩＤ１を送信することは安全ではない。そこで、後に暗号化されて送信されるＲｅｓｐ１でＵＩＤ１を送信するのではなく、秘密鍵（Ｋ１）に基づいたレスポンス、ＵＩＤ１、メッセージＭＳＧ、カウンタ及び乱数の署名（ＳＩＧ）が送信される。

【0032】

次いでＧＴＳ１１は、このＲｅｓｐ１を鍵Ｋ１で暗号化し（Ｒｅｓｐ１^＊を生成し）、それをＳｅｃＡｐｐ１０に返信する（ステップ１０３）。

【0033】

次いで（ステップ１０４において）ＳｅｃＡｐｐ１０は、第１のレスポンス（Ｒｅｓｐ１）を得るためにレスポンス（Ｒｅｓｐ１^＊）を秘密鍵Ｋ１で解読する。次いでＳｅｃＡｐｐ１０は、ＭＳＧ｜ｓｅｎｔ＝１｜ＵＩＤ１｜ＵＩＤ＿Ｒａｎｄの署名であるＸＳＩＧをそのローカルに保存された秘密鍵Ｋ１を使用して計算することができる。

【0034】

次いでＳｅｃＡｐｐ１０は、ＳＩＧがＸＳＩＧに等しいかどうかを検証することができる。それらが等しい場合、ＳｅｃＡｐｐ１０は、Ｒｅｓｐ１からメッセージＭＳＧを取り出す。

【0035】

このメッセージＭＳＧは、（現在、又は所定の時間に）ＯＴＡサーバに接続することの要求、何もしないことの要求、又はＳｅｃＡｐｐ１０に送信される任意の他の情報である可能性がある。メッセージＭＳＧはまた、「更新はありません」、「ＯＴＡで利用可能な更新があります」、「ポーリング頻度を上げて下さい」、「ポーリング頻度を下げて下さい」、「新しい鍵を生成して下さい」など、通信レベル及びアプリケーションレベルのメッセージ及びコマンドである可能性があり、トランスポートアイデンティティの更新情報も含む。

【0036】

一意の識別子は、リモートサーバにより端末に送信されたルールに基づいて、端末によってリモートサーバに定期的に送信される可能性がある。

【0037】

ステップ１０５において、ＳｅｃＡｐｐ１０は（ＳＩＧがＸＳＩＧに一致する場合に）、ＵＩＤ１、Ｋ１及び受信したＵＩＤ＿ＲＡＮＤからＵＩＤ２を導出することができる。ＵＩＤ２は、ＳｅｃＡｐｐ１０がＧＴＳ１１に再び接続することを希望する場合の後のステージ（ステップ１０６）において使用され得るアイデンティティである。

【0038】

図１に示す例では、この後のステージのステップ１０６において、ＳｅｃＡｐｐ１０はＵＩＤ２をＧＴＳ１１に送信し（ステップ１０６）、ステップ１０７において、ＧＴＳ１１は、ＵＩＤ２に基づいたＫ１を取得し、ＳｅｃＡｐｐ１０に別のメッセージを送信するためにステップ１０２に示されたステップを繰り返すことができる。示されたケースでは、ＧＴＳ１１はＵＩＤ２に基づいた鍵Ｋ１を見出さず、このイベントをＤｏＳ攻撃（サービス妨害）として扱い、ランダムＵＩＤ２が例えばＧＴＳ１１に送信されている。

【0039】

図２は、ＧＴＳ１１からＳｅｃＡｐｐ１０に回答する際にＧＴＳ１１からの回答が失われた場合に行われることを示している。

【0040】

ステップ１００～１０３は、図１に示された同じステップと同一である。

【0041】

ただし、ステップ１０３（ＧＴＳ１１がＲｅｓｐ１^＊をＳｅｃＡｐｐ１０に送信する）の後、ＲＥＳＰ１^＊はＳｅｃＡｐｐ１０によって受信されない（ステップ１２０：Ｒｅｓｐ１^＊が失われる）。

【0042】

ＳｅｃＡｐｐ１０は、（ステップ１０１における）ＵＩＤ１の送信の瞬間とＧＴＳ１１のレスポンスを得る瞬間との間の期間をカウントするタイマーを含む。所定の時間枠内にレスポンスが受信されない場合、ＳｅｃＡｐｐ１０は、ＧＴＳ１１の回答の期間が長すぎたと判断し、カウンタ（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）を１増加させる。

【0043】

次いでＳｅｃＡｐｐ１０は、ＧＴＳ１１への接続を試みるために同じＵＩＤ１を使用する（ステップ１２２）。

【0044】

次いでＧＴＳ１１は、ＵＩＤ１（ＵＩＤ２は既に生成されている）に基づいたＫ１を取得し、（ＭＳＧ｜Ｓｅｎｔ＝２｜ＵＩＤ１｜ＵＩＤ＿Ｒａｎｄ）の署名である署名ＳＩＧ２をＫ１を使用して計算する。

【0045】

ＧＴＳ１１はまた、
－メッセージＭＳＧ；
－送信されたメッセージの数（ここでは、ステップ１０２において送信された第１のメッセージがＳｅｃＡｐｐ１０によって受信されなかったため２）；
－ＳＩＧ２；
－ＵＩＤ＿Ｒａｎｄ
の連結を含むメッセージＲｅｓｐ２を生成する。

【0046】

次いでＧＴＳ１１は、このＲｅｓｐ２を鍵Ｋ１で暗号化し（Ｒｅｓｐ２^＊を生成し）、これをＳｅｃＡｐｐ１０に返信する（ステップ１２４）。

【0047】

次いで（ステップ１２５）ＳｅｃＡｐｐ１０は、Ｒｅｓｐ２^＊を自身の鍵Ｋ１で解読してＲｅｓｐ２を得る。ＳｅｃＡｐｐ１０は次いでＲｅｓｐ２の有効性のチェックを行う（ＵＩＤ１及びＳｅｎｔ＝２を検証する）。Ｓｅｎｔ＝２は、ＱｏＳ（サービス品質）及びセキュリティ目的（ＤｏＳ攻撃）を推定することを可能にする。

【0048】

次いでＳｅｃＡｐｐ１０は、（図１のステップ１０５に説明されるように）ＧＴＳ１１への次のアクセスのためのＵＩＤ２を導出する。

【0049】

したがって、この図では、端末１０に送信された暗号化された第１のレスポンス（Ｒｅｓｐ１^＊）が、ステップ１０１を実行した後の所定の時間枠内に端末１０によって受信されない場合、端末はカウンタの値（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）を１増加させ、（ステップ１２２において）ステップ１０１を再び実行する。

【0050】

図３は、ＵＩＤ１がＧＴＳ１１によって受信されない場合に行われることを示している。

【0051】

ステップ１００及び１０１は、図１及び図２に示されたステップと同一である。

【0052】

ただし、ステップ１０１（ＳｅｃＡｐｐ１０がＵＩＤ１をＧＴＳ１１に送信した）の後、メッセージは失われ（ステップ１３０－ＵＩＤ１紛失）、ＧＴＳ１１によって受信されない。

【0053】

次いでＳｅｃＡｐｐ１０は、所定時間後にそのカウンタの値を増加させ（ステップ１３１）、ＵＩＤ１をＧＴＳ１１に再送信する（ステップ１３２）。

【0054】

ステップ１３３は図１及び図２のステップ１０２と同一である。

【0055】

ステップ１３４において、Ｒｅｓｐ１^＊は、メッセージ及びＳｅｎｔ＝１を取得する（ステップ１３５）ＳｅｃＡｐｐ１０に送信される。

【0056】

このカウンタ（Ｓｅｎｔ＝１）は、ＱｏＳを評価することを可能にし、システムのセキュリティを高める。

【0057】

次いでＳｅｃＡｐｐ１０は、ＧＴＳ１１にアクセスするためのＵＩＤ２を導出することができる。

【0058】

したがって、この図では、ステップ１０１において送信されたメッセージが、所定の時間枠内にリモートサーバ１１から回答を受信していない場合、端末１０はカウンタ値（Ｒｅｓｅｎｄ＿Ｃｏｕｎｔｅｒ）を１増加させ、（ステップ１３２において）ステップ１０１を繰り返す。

【0059】

任意選択的に、システムセキュリティは、暗号鍵Ｋ１が各新しい要求に対して変更される場合に改善される。かかる実施形態において：

【0060】

ＧＴＳ１１は、
－有効なＵＩＤ１要求を受信した後、Ｋ１、ＵＩＤ１及びＵＩＤ＿Ｒａｎｄに基づいた一意のＵＩＤ２を生成し、
－ＵＩＤ１及びＵＩＤ＿Ｒａｎｄに関連付けられたＫ１から新しい鍵Ｋ２を導出し、
－Ｋ２をＵＩＤ２に関連付け、
－ＵＩＤ２識別子を含む要求を受信するときに新しいＫ２のみを使用する。

【0061】

ＳｅｃＡｐｐ１０は、
－ＧＴＳから有効なレスポンスを受信し、解読したレスポンスからＵＩＤ＿Ｒａｎｄの抽出に成功した後、Ｋ１、ＵＩＤ１及びＵＩＤ＿Ｒａｎｄに基づいた一意のＵＩＤ２を生成し、
－ＵＩＤ１に関連付けられたＫ１及び抽出したＵＩＤ＿ＲａｎｄからＫ２を導出し、
－ＵＩＤ２要求に対するＧＴＳからのレスポンスを解読するためにＫ２を使用する。

【0062】

本発明の主な利点は、
－セッションベースのプロトコル（ｈｔｔｐ）と比較して通信オーバーヘッドを最小限に抑え、非対称鍵を使用するＨＴＴＰＳと対照して対称鍵ベースの暗号化を用いるために拡張性があること、
－以下によってデバイスの電力消費を最小限に抑えること、
〇対称鍵暗号化を用いること
〇セッションレスでステートレスなプロトコル（例えばＵＤＰ）上の非常に小さいパケット
〇ローカルトリガリングシステムが使用される場合に、拡張性を更に高めることができ、往復時間を短縮するためにデバイス側の電力消費を改善することができる。このようなケースでは、グローバルトリガリングシステムは、端末要求の処理を端末の近くに位置するローカルトリガリングシステムに委任し、例えばエッジコンピューティングアーキテクチャ展開で処理されるようにする。
－デバイスアイデンティティ保護及び通信の機密性を提供することである。

【図1】

【図2】

【図3】