JP7485788B2 - 安全な通信方法と関連する装置及びシステム - Google Patents

Description

[関連出願への相互参照]
この出願は、2020年5月11日付で中国国家知的所有権管理局に出願された"安全な通信方法と関連する装置及びシステム"と題する中国特許出願番号第202010394218.5号に基づく優先権を主張し、その内容は、その全体が参照により本明細書に組み込まれる。

[技術分野]
この出願は、通信技術の分野に関し、特に、安全な通信方法、関連する通信装置及びシステム、及び関連するコンピュータ読み取り可能な記憶媒体に関する。

現時点では、第3世代パートナーシッププロジェクト(3rd Generation Partnership Project, 3GPP)は、5Gコアネットワーク(5G Core, 5GC)のエッジセキュリティゲートウェイとして、セキュリティ及びエッジ保護プロキシ(Security and Edge Protection Proxy, SEPP)デバイスを定義している。そのSEPPデバイスは、複数の異なるオペレータネットワークの間での相互作用のためのプロキシデバイスである。そのSEPPデバイスは、5Gコアネットワークの内部ネットワーク機能(Network Function, NF)デバイスとローミングネットワークとの間のシグナリング交換を転送する。

従来の技術は、複数の異なるオペレータネットワークの中での複数のSEPPデバイスの間での安全な通信を実装するための具体的な解決方法をいまだ提供してはいない。この場合には、認可されることなく、それらの複数のSEPPデバイスの間で伝送されるシグナリングメッセージを取得することが可能である。

この出願の複数の実施形態は、通信方法及びシステム、関連する装置、及びコンピュータ読み取り可能な記憶媒体を提供する。

第1の態様によれば、この出願のある1つの実施形態は、安全な通信方法であって、
第1のセキュリティ及びエッジ保護プロキシSEPPデバイスが、セキュリティサーバからの第1のメッセージを受信するステップであって、前記第1のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送する、ステップと、その次に、前記第1のSEPPデバイスが、前記第2のSEPPデバイスが送信するデバイス証明書を受信し、そして、前記第2のSEPPデバイスに対応する前記安全性証明書を使用することによって、前記第2のSEPPデバイスの前記デバイス証明書に対して検証を実行するステップと、前記検証に成功している場合に、前記第1のSEPPデバイスが、前記第2のSEPPデバイスへのセキュリティ接続を確立するステップと、を含む、安全な通信方法を提供する。

この実施形態によって提供される技術的解決方法において、第1のSEPPデバイスは、第2のSEPPデバイスに対応する安全性証明書を使用することによって、第2のSEPPデバイスのデバイス証明書の有効性に関する検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間の通信の安全性を改善する。第2のSEPPデバイスは、また、同様の安全な通信方法を使用することによって、第1のSEPPデバイスのデバイス証明書に対して検証を実行してもよい。第2のSEPPデバイスが送信するデバイス証明書と比較して、セキュリティサーバが送信する安全性証明書は、信頼性がより高い。従来の技術と比較して、この実施形態は、2つのSEPPデバイスが互いのデバイス証明書に対して検証を実行し、それにより、それらの2つのSEPPデバイスの間での通信の安全性を改善する解決方法を提供する。

ある1つの可能な実施形態において、前記第2のSEPPデバイスに対応する前記安全性証明書は、前記第2のSEPPデバイスの証明書サーバのルート証明書である。この場合には、第1のSEPPデバイスは、セキュリティサーバが送信する第2のSEPPデバイスの証明書サーバのルート証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書の安全性に関する検証を実行してもよい。

ある1つの可能な実施形態において、第2のSEPPデバイスに対応する安全性証明書は、第2のSEPPデバイスのデバイス証明書である。この場合には、第1のSEPPデバイスは、セキュリティサーバが送信する第2のSEPPデバイスのデバイス証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書の安全性に関する検証を実行してもよい。ルート証明書を使用してデバイス証明書に対して検証を実行する場合と比較して、セキュリティサーバから取得するデバイス証明書を直接的に使用して、第2のSEPPデバイスが送信するデバイス証明書に対して検証を実行すると、より効率的となる。

ある1つの可能な実施形態において、第1のSEPPデバイスが受信する第2のSEPPデバイスの安全性証明書は、第2のSEPPデバイスの公開鍵である。この場合には、第1のSEPPデバイスは、セキュリティサーバが送信する第2のSEPPデバイスのデバイス証明書を使用することによって、第2のSEPPデバイスが送信する公開鍵の安全性に関する検証を実行してもよい。

ある1つの可能な実施形態において、第1のSEPPデバイスが、セキュリティサーバからの第1のメッセージを受信する前に、前記第1のSEPPデバイスは、前記セキュリティサーバに証明書要求メッセージを送信し、前記証明書要求メッセージは、前記第2のSEPPデバイスの識別子を搬送し、前記証明書要求メッセージは、前記第2のSEPPデバイスに対応する前記安全性証明書を要求するのに使用される。

ある1つの可能な実施形態において、前記セキュリティサーバは、ドメインネームシステムDNSサーバであり、前記第1のSEPPデバイスが送信する前記証明書要求メッセージは、DNSクエリ要求である。この場合には、セキュリティサーバは、DNSクエリ応答を使用することによって、第1のSEPPデバイスに、第2のSEPPデバイスに対応する安全性証明書を送信してもよい。この実施形態において、第2のSEPPデバイスに対応する安全性証明書の取得をDNSクエリプロセスと組み合わせ、それによって、DNSクエリの際に安全性証明書を取得することが可能であり、その結果、メッセージリソースを節約するとともに通信効率を改善する。

ある1つの可能な実施形態において、DNSサーバに、第1のSEPPデバイスのホスト名と第1のSEPPデバイスの証明書サーバのルート証明書との間の対応関係及び第2のSEPPデバイスのホスト名と第2のSEPPデバイスの証明書サーバのルート証明書との間の対応関係を構成してもよい。

ある1つの可能な実施形態において、第1のSEPPデバイスが、セキュリティサーバからの第1のメッセージを受信する前に、前記第1のSEPPデバイスは、さらに、前記セキュリティサーバに第2のメッセージを送信し、前記第2のメッセージは、前記第1のSEPPデバイスに対応する安全性証明書を搬送する。加えて、前記第2のメッセージは、さらに、前記第1のSEPPデバイスの識別子を搬送する。この実施形態において、第1のSEPPデバイスは、第2のメッセージを使用することによって、セキュリティサーバに、第1のSEPPデバイスに対応する安全性証明書をアップロードし、それによって、セキュリティサーバは、安全性証明書を格納する。

ある1つの可能な実施形態において、第2のメッセージは、ハイパーテキスト転送プロトコルメッセージであってもよく又はハイパーテキスト転送プロトコルのセキュアメッセージであってもよい。

ある1つの可能な実施形態において、前記第1のSEPPデバイスが前記安全性証明書を使用することによって前記第2のSEPPデバイスの前記デバイス証明書の検証に成功しているときに、前記第1のSEPPデバイスは、前記第2のSEPPデバイスに、検証成功メッセージを送信する。したがって、第2のSEPPデバイスは、その検証成功メッセージに応答して、第1のSEPPデバイスとの通信のために使用されるセッション鍵を生成してもよい。

ある1つの可能な実施形態において、前記第1のSEPPデバイスが、前記第2のSEPPデバイスへのセキュリティ接続を確立するステップは、前記第1のSEPPデバイスが、前記第2のSEPPデバイスとの安全な通信のために使用されるセッション鍵を計算するステップと、その次に、前記第1のSEPPデバイスが、前記セッション鍵を使用することによって、前記第2のSEPPデバイスへのセキュリティ接続を確立するステップと、を含む。この実施形態において、各々のSEPPデバイスは、セッション鍵を計算し、そして、その次に、そのセッション鍵を使用することによって、セキュリティ接続を確立し、それによって、第1 SEPPデバイスと第2 SEPPデバイスとの間の通信の安全性を強化することが可能である。

第2の態様によれば、この出願のある1つの実施形態は、他の安全な通信方法を提供する。その方法は、主として、セキュリティサーバが、第2のセキュリティ及びエッジ保護プロキシSEPPデバイスに対応する安全性証明書を取得するステップと、その次に、前記セキュリティサーバが、第1のSEPPデバイスに第1のメッセージを送信するステップであって、前記第1のメッセージは、前記第2のSEPPデバイスに対応する前記安全性証明書を搬送する、ステップと、を含む。

この実施形態によって提供される解決方法において、セキュリティサーバが第1のSEPPデバイスに送信する安全性証明書は、第2のSEPPデバイスが第1のSEPPデバイスに送信するデバイス証明書よりもより高い信頼性を有する。したがって、第1のSEPPデバイスは、セキュリティサーバが送信する安全性証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書に対して検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間の通信の安全性を改善する。

ある1つの可能な実施形態において、前記セキュリティサーバが、前記第2のSEPPデバイスの証明書サーバのルート証明書を取得する前に、前記セキュリティサーバは、前記第1のSEPPデバイスが送信する証明書要求メッセージを受信し、前記証明書要求メッセージは、前記第2のSEPPデバイスの識別子を搬送する。前記証明書要求メッセージは、前記第2のSEPPデバイスに対応する前記安全性証明書を要求するのに使用される。

ある1つの可能な実施形態において、前記セキュリティサーバが、前記第2のSEPPデバイスに対応する前記安全性証明書を取得する前に、前記セキュリティサーバは、前記第2のSEPPデバイスが送信する第2のメッセージを受信し、前記第2のメッセージは、前記第2のSEPPデバイスに対応する前記安全性証明書を搬送する。

ある1つの可能な実施形態において、前記第2のメッセージは、さらに、前記第2のSEPPデバイスの前記識別子を搬送する。

ある1つの可能な実施形態において、前記セキュリティサーバが前記第2のSEPPデバイスに対応する前記安全性証明書を取得する前に、前記セキュリティサーバは、前記第1のSEPPデバイスが送信する第2のメッセージを受信し、前記第2のメッセージは、前記第1のSEPPデバイスに対応する安全性証明書を搬送する。

第3の態様によれば、この出願のある1つの実施形態は、コンピュータが読み取り可能な記憶媒体を提供する。そのコンピュータ読み取り可能な記憶媒体は、コンピュータプログラムを格納する。コンピュータプログラムがプロセッサによって実行されるときに、第1の態様又は第2の態様のうちのいずれかにしたがった方法を実行することが可能である。

第4の態様によれば、この出願のある1つの実施形態は、セキュリティ及びエッジ保護プロキシSEPPデバイスを提供する。そのデバイスは、少なくとも1つのプロセッサ及びそのプロセッサに結合されるメモリを含む。メモリは、コンピュータプログラムコードを格納する。プロセッサは、メモリの中のコンピュータプログラムコードを呼び出しそして実行して、SEPPデバイスが第1の態様にしたがった方法を実行することを可能とする。

第5の態様によれば、この出願のある1つの実施形態は、安全な通信システムを提供する。そのシステムは、
コアネットワークネットワーク機能デバイス及び第1のSEPPデバイスを含み、コアネットワークネットワーク機能デバイスは、第1のSEPPデバイスにシグナリングメッセージを送信するように構成され、
第1のSEPPデバイスは、第1の態様における方法を実行し、そして、セキュリティ接続を介して、第2のSEPPデバイスに、受信したシグナリングメッセージを送信する、ように構成される。

ある1つの可能な実施形態において、シグナリングメッセージは、ローミングシグナリングメッセージである。

第6の態様によれば、この出願のある1つの実施形態は、第1のSEPPデバイスを提供する。その第1のSEPPデバイスは、主として、
セキュリティサーバからの第1のメッセージを受信するように構成される通信ユニットであって、第1のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送し、通信ユニットは、さらに、第2のSEPPデバイスが送信するデバイス証明書を受信するように構成される、通信ユニットを含む。

第1のSEPPデバイスは、さらに、検証ユニット及び接続確立ユニットを含み、検証ユニットは、受信した安全性証明書を使用することによって、第2のSEPPデバイスのデバイス証明書に対して検証を実行するように構成され、接続確立ユニットは、検証の成功の後に、第2のSEPPデバイスへのセキュリティ接続を確立するように構成される。

第1の態様及び第2の態様によって提供される安全な通信方法において、この実施形態によって提供される第1のSEPPデバイスを使用してもよい。具体的な詳細及び有益な効果については、上記の複数の実施形態を参照するべきである。

ある1つの可能な実施形態において、通信ユニットは、さらに、セキュリティサーバに証明書要求メッセージを送信するように構成され、その証明書要求メッセージは、第2のSEPPデバイスの識別子を搬送する。

ある1つの可能な実施形態において、第2のSEPPデバイスに対応する安全性証明書は、第2のSEPPデバイスの証明書サーバのルート証明書であってもよく、又は、第2のSEPPデバイスのデバイス証明書であってもよい。

ある1つの可能な実施形態において、通信ユニットは、さらに、セキュリティサーバに第2のメッセージを送信するように構成され、第2のメッセージは、第1のSEPPデバイスに対応する安全性証明書を搬送する。したがって、第2のSEPPデバイスは、セキュリティサーバから第1のSEPPデバイスに対応する安全性証明書を取得し、そして、第1のSEPPデバイスのデバイス証明書に対して検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間での通信の安全性を強化する。

ある1つの可能な実施形態において、通信ユニットは、さらに、検証ユニットが安全性証明書を使用することによって第2のSEPPデバイスのデバイス証明書の検証に成功しているときに、第2のSEPPデバイスに検証成功メッセージを送信して、証明書検証の成功を第2のSEPPデバイスに通知する、ように構成される。

ある1つの可能な実施形態において、接続確立ユニットが第2のSEPPデバイスへのセキュリティ接続を確立することは、具体的には、
接続確立ユニットが、第2のSEPPデバイスとの安全な通信のために使用されるセッション鍵を計算し、そして、その次に、接続確立ユニットが、そのセッション鍵を使用することによって、第2のSEPPデバイスへのセキュリティ接続を確立することを含んでもよい。

第7の態様によれば、この出願のある1つの実施形態は、セキュリティサーバを提供する。そのセキュリティサーバは、主として、取得ユニット及び通信ユニットを含む。

取得ユニットは、第2のセキュリティ及びエッジ保護プロキシSEPPデバイスに対応する安全性証明書を取得するように構成される。通信ユニットは、第1のSEPPデバイスに第1のメッセージを送信するように構成され、第1のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送する。

この実施形態によって提供されるセキュリティサーバは、上記のように提供される安全な通信方法の中で使用されてもよい。具体的な詳細及び有益な効果については、上記の複数の実施形態を参照するべきである。

ある1つの可能な実施形態において、通信ユニットは、さらに、第1のSEPPデバイスが送信する証明書要求メッセージを受信するように構成され、証明書要求メッセージは、第2のSEPPデバイスの識別子を搬送する。

ある1つの可能な実施形態において、取得ユニットが第2のSEPPデバイスに対応する安全性証明書を取得する前に、通信ユニットは、さらに、第2のSEPPデバイスが送信する第2のメッセージを受信し、その第2のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送する。

第8の態様によれば、この出願のある1つの実施形態は、互いに結合されているプロセッサ及びメモリを含むSEPPデバイスを提供する。プロセッサは、メモリの中に格納されているコンピュータプログラムを呼び出して、この出願の複数の実施形態においてSEPPデバイスが実行するいずれかの方法の複数のステップのうちの一部又はすべてを実行するように構成される。

第9の態様によれば、この出願のある1つの実施形態は、互いに結合されているプロセッサ及びメモリを含むセキュリティサーバを提供する。そのプロセッサは、メモリの中に格納されているコンピュータプログラムを呼び出して、この出願の複数の実施形態においてセキュリティサーバが実行するいずれかの方法の複数のステップのうちの一部又はすべてを実行するように構成される。

第10の態様によれば、この出願のある1つの実施形態は、コンピュータが読み取り可能な記憶媒体を提供する。そのコンピュータ読み取り可能な記憶媒体は、コンピュータプログラムを格納する。そのコンピュータプログラムがプロセッサによって実行されるときに、この出願の複数の実施形態においてSEPPデバイス又はセキュリティサーバが実行するいずれかの方法の複数のステップのうちの一部又はすべてを完了することが可能である。

第11の態様によれば、この出願のある1つの実施形態は、少なくとも1つの入力端子、信号プロセッサ、及び少なくとも1つの出力端子を含む通信装置を提供する。その信号プロセッサは、この出願の複数の実施形態においてSEPPデバイス又はセキュリティサーバが実行するいずれかの方法の複数のステップのうちの一部又はすべてを実行するように構成される。

第12の態様によれば、この出願のある1つの実施形態は、入力インターフェイス回路、論理回路、及び出力インターフェイス回路を含む通信装置を提供する。論理回路は、この出願の複数の実施形態においてSEPPデバイス又はセキュリティサーバが実行するいずれかの方法の複数のステップのうちの一部又はすべてを実行するように構成される。

第13の態様によれば、この出願のある1つの実施形態は、命令を含むコンピュータプログラム製品を提供する。そのコンピュータプログラム製品がコンピュータデバイスによって実行されるときに、そのコンピュータデバイスが、SEPPデバイス又はセキュリティサーバが実行することが可能であるいずれかの方法の複数のステップのうちの一部又はすべてを実行することを可能とする。

上記の複数の態様うちのいずれか1つによって提供される実施形態において、セキュリティサーバは、DNSサーバであってもよく、第1のSEPPデバイスが受信する第1のメッセージは、DNS応答メッセージであってもよい。

上記の複数の態様うちのいずれか1つによって提供される実施形態において、第1のSEPPデバイスと第2のSEPPデバイスとの間で確立されるセキュリティ接続は、トランスポート層セキュリティ接続である。

以下の記載は、この出願の複数の実施形態のための複数の添付の図面を簡潔に説明する。

この出願のある1つの実施形態にしたがった5Gネットワークアーキテクチャの概略的な図である。 この出願のある1つの実施形態にしたがったローミングシナリオにおけるネットワークアーキテクチャの概略的な図である。 この出願のある1つの実施形態にしたがった他のローミングシナリオにおけるネットワークアーキテクチャの概略的な図である。 この出願のある1つの実施形態にしたがった他のローミングシナリオにおけるネットワークアーキテクチャの概略的な図である。 この出願のある1つの実施形態にしたがった他のローミングシナリオにおけるネットワークアーキテクチャの概略的な図である。 この出願のある1つの実施形態にしたがった通信方法の概略的なフローチャートである。 この出願のある1つの実施形態にしたがった他の通信方法の概略的なフローチャートである。 この出願のある1つの実施形態にしたがった他の通信方法の概略的なフローチャートである。 この出願のある1つの実施形態にしたがったSEPPデバイスの複数の機能の概略的な図である。 この出願のある1つの実施形態にしたがったセキュリティサーバの複数の機能の概略的な図である。 この出願のある1つの実施形態にしたがった通信装置の構成の概略的な図である。 この出願のある1つの実施形態にしたがった通信装置の中の回路基板のインターフェイスの概略的な図である。 この出願のある1つの実施形態にしたがったSEPPデバイス及びセキュリティサーバのハードウェア構成の図である。

以下の記載は、この出願の複数の実施形態における複数の添付の図面を参照して、この出願の複数の実施形態における複数の技術的解決方法を説明する。

この出願の明細書、特許請求の範囲、及び添付の図面において、"第1の"及び"第2の"等の語は、複数の異なる対象を判別することを意図しているが、ある特定の順序を示すことを意図してはいない。

図1-Aは、この出願のある1つの実施形態にしたがった5Gネットワークアーキテクチャの概略的な図である。5Gネットワークにおいては、4Gネットワークの(例えば、モビリティ管理エンティティ(Mobility Management Entity, MME)等の)複数の機能デバイスのうちのいくつかを分割し、そして、サービスベースのアーキテクチャに基づくアーキテクチャを定義する。図1-Aに示されているネットワークアーキテクチャにおいては、4Gネットワークの中のMMEと同様の機能を分割して、アクセス及びモビリティ管理機能(Access and Mobility Management Function, AMF)及びセッション管理機能(Session Management Function, SMF)等とする。

以下の記載は、その他の関連するデバイス、ネットワーク要素、又はエンティティのうちのいくつかを説明する。

ユーザ端末(User Equipment, UE)は、オペレータネットワークにアクセスして、データネットワーク等にアクセスし、そして、DNの中のオペレータ又は第3者が提供するサービスを利用する。

説明を容易にするために、この出願の複数の実施形態において、ユーザ端末、ユーザ機器、端末デバイス、モバイル端末、又は端末等は、集合的にUEと称されてもよい。言い換えると、特に明記されていない場合には、この出願の以下の複数の実施形態の中で説明されているUEは、ユーザ端末、ユーザ機器、端末デバイス、モバイル端末、又は端末に置き換えられてもよく、また、もちろん、それらと交換可能である。

アクセス及びモビリティ管理機能(AMF)は、3GPPネットワークにおける制御プレーン機能であり、主として、オペレータネットワークにアクセスするUEのためのアクセス制御及びモビリティ管理の役割を担う。セキュリティアンカー機能(Security Anchor Function, SEAF)は、AMFの中に配置されてもよく、又は、SEAFは、AMFとは異なる他のデバイスの中に配置されてもよい。図1-Aにおいて、例えば、SEAFは、AMFの中に配置される。SEAFがAMFの中に配置されるときに、SEAF及びAMFは、集合的にAMFと称されてもよい。

セッション管理機能(SMF)は、3GPPネットワークにおける制御プレーン機能である。SMFは、主として、UEのパケットデータユニット(Packet Data Unit, PDU)セッションを管理する役割を担うように構成される。PDUセッションは、PDUを伝送するためのチャネルである。UE及びDNは、そのPDUセッションによって互いにPDUを送信してもよい。SMFは、例えば、PDUセッションの確立、保守管理、及び削除等の管理の役割を担う。

データネットワーク(Data Network, DN)は、また、パケットデータネットワーク(Packet Data Network, PDN)と称され、3GPPネットワークの外部にあるネットワークである。3GPPネットワークは、複数のDNにアクセスすることが可能であり、DNに、オペレータ又は第3者が提供する複数のサービスを展開することが可能である。例えば、DNは、スマートファクトリーのプライベートネットワークであり、スマートファクトリーのワークショップの中に設置されるセンサは、UEの役割を果たし、そのセンサの制御サーバは、DNの中に配置される。UEは、その制御サーバとの間で通信する。制御サーバの指示を取得した後に、UEは、その指示に基づいて、制御サーバに収集したデータを伝送してもよい。他の例では、DNは、企業の内部オフィスネットワークであり、その企業の従業員が使用する端末は、UEの役割を果たしてもよく、UEは、その企業の内部情報及びその他のリソースにアクセスしてもよい。

統合データ管理エンティティ(Unified Data Management, UDM)は、また、3GPPネットワークの中の制御プレーン機能である。UDMは、主として、3GPPネットワークの中の加入者(UE)の加入データ、認証情報(credential)、及び加入者永久識別子(Subscriber Permanent Identifier, SUPI)等を格納する役割を担う。データは、UEがオペレータの3GPPネットワークにアクセスするための認証及び認可のために使用されてもよい。

認証サーバ機能(Authentication Server Function, AUSF)は、また、3GPPネットワークにおける制御プレーン機能であり、AUSFは、主として、第1のレベルの認証(具体的にいうと、3GPPネットワークが3GPPネットワークの加入者に対して実行する認証)のために使用される。

ネットワーク露出機能(Network Exposure Function, NEF)は、また、3GPPネットワークにおける制御プレーン機能である。NEFは、主として、3GPPネットワークの外部インターフェイスを安全な方式によって第3者に開放する役割を担う。例えば、SMF等の機能がサードパーティネットワーク要素との間で通信する必要があるときに、NEFは、通信のための中継器として役立つ場合がある。中継の際に、NEFは、内部識別子と外部識別子との間の変換を実行してもよい。例えば、UEのSUPIが3GPPネットワークから第3者に送信されるときに、NEFは、SUPIをそのSUPIに対応する外部識別情報(Identity, ID)へと変換してもよい。反対に、外部識別情報IDが3GPPネットワークに送信されるときに、NEFは、外部識別情報IDを対応するSUPIへと変換してもよい。

ネットワークリポジトリ機能(Network Repository Function, NRF)は、また、3GPPネットワークにおける制御プレーン機能であり、主として、アクセス可能なネットワーク機能(NF)の構成及びサービスプロファイル(profile)を格納し、他のネットワーク要素にネットワーク機能検出サービスを提供する役割を担う。

ユーザプレーン機能(User Plane Function, UPF)は、3GPPネットワークとDNとの間の通信のためのゲートウェイである。

ポリシー制御機能(Policy Control Function, PCF)は、3GPPネットワークにおける制御プレーン機能であり、SMFにPDUセッションポリシーを提供するように構成される。ポリシーは、課金、サービス品質(Quality of Service, QoS)、及び認可に関連するポリシー等を含む。

アクセスネットワーク(Access Network, AN)は、3GPPネットワークのサブネットワークである。3GPPネットワークにアクセスするために、UEは、最初に、ANにアクセスする必要がある。無線アクセスのシナリオにおいて、ANは、また、無線アクセスネットワーク(Radio Access Network, RAN)と称される。したがって、RAN及びANの語は、通常、判別することなく交換可能に使用される。

3GPPネットワークは、3GPP規格に準拠しているネットワークである。図1-Aにおいて、UE及びDN以外の部分は、3GPPネットワークと考えられてもよい。3GPPネットワークは、3GPPが定義する5Gネットワークには限定されず、むしろ、2G、3G、及び4Gネットワークをさらに含んでもよい。3GPPネットワークは、通常、オペレータによって実行される。加えて、図1-Aに示されているアーキテクチャにおいては、N1、N2、N3、N4、及びN6等は、複数の関連するエンティティ又は複数のネットワーク機能の間の基準点(Reference Point)を表す。Nausf及びNamf等は、複数の関連するネットワーク機能のサービスベースのインターフェイスを表す。

もちろん、3GPPネットワーク及び非3GPPネットワークは、共存してもよく、5Gネットワークの複数のネットワーク要素のうちのいくつかは、代替的に、複数の非5Gネットワークのうちのいくつかの中で使用されてもよい。

図1-Bに示されているように、SEPPデバイスは、5Gコアネットワーク(5GC)のエッジセキュリティゲートウェイとして機能する。ローミングのシナリオにおいて、SEPPデバイスは、複数のオペレータネットワークの間の相互作用のためのプロキシとして機能する。5Gコアネットワークの内部ネットワーク機能(NF)とローミングネットワークとの間のシグナリングメッセージは、SEPPデバイスによって転送される。SEPPデバイスは、伝送されるメッセージの完全性及び機密性の保護をサポートし、また、機密性の低い伝送されるメッセージのコンテンツを識別しそして変更するIPXデバイス(略称IPX)をサポートする。

上記のアーキテクチャは、セキュリティサーバをさらに含む。セキュリティサーバは、SEPPデバイスと通信してもよい。セキュリティサーバは、例えば、SEPPデバイスの安全性証明書又はSEPPデバイスの安全性証明書の発行機関のルート証明書等のセキュリティ情報を格納してもよい。

セキュリティサーバは、また、サードパーティサーバと称されてもよく、汎欧州ディジタル移動体通信システムアソシエーション(GSM Association, GSMA)又は政府機関等の業界組織によって展開されてもよく、IP交換サービス(IP exchange service, IPX)ネットワークの中のデバイスであってもよい、すなわち、IPXネットワークの中のデバイスは、この出願のこの実施形態におけるセキュリティサーバの機能を実装する。IPXネットワークの中のデバイスは、Diameterルーティングエージェント(Diameter routing agent, DRA)デバイス及びドメインネームサーバ(domain name server, DNS)を含んでもよい。

この出願の複数の実施形態において、SEPPデバイスは、(例えば、第1のSEPPデバイスは、第1のSEPPと称され、第2のSEPPデバイスは、第2のSEPPと称される等といったように)SEPPと称されてもよい、すなわち、SEPP及びSEPPデバイスは交換可能に使用されてもよい。IPXデバイスは、(例えば、第1のIPXデバイスは、第1のIPXと称され、第2のIPXデバイスは第2のIPXと称される等といったように)IPXと称される、すなわち、IPXデバイス及びIPXは、交換可能に使用されてもよい。

UEが複数の異なるオペレータネットワークの間でローミングするときに、SEPPデバイスは、訪問先SEPP(visited SEPP, vSEPP)デバイス及びホームSEPP(home SEPP, hSEPP)デバイスに分類されてもよい。

図1-C及び図1-Dに示されているように、複数の異なるオペレータネットワークの中のSEPPデバイスは、N32インターフェイスによって接続されてもよい。例えば、vSEPPデバイス及びhSEPPデバイスは、N32-Cインターフェイスによって直接的に接続されるか、又は、vSEPPデバイスは、N32-fインターフェイスによってIPXに接続されてもよく、そして、その次に、そのIPXは、N32-fインターフェイスによってhSEPPデバイスに接続されてもよい。複数のSEPPデバイスの間に、(例えば、図1-Dに示されているように)1つのIPXが存在してもよく又は(例えば、図1-Cに示されているように)複数のIPXが存在してもよい。

図1-Eに示されているように、サービスの提供及びサービスの消費の観点から、SEPPデバイスは、消費側SEPPデバイス(consumer SEPP, cSEPP)及び生産側SEPPデバイス(producer SEPP, pSEPP)に分類されてもよい。vSEPPデバイスは、pSEPPデバイスであってもよく、且つ、hSEPPデバイスは、cSEPPデバイスであってもよく、又は、vSEPPデバイスは、cSEPPデバイスであってもよく、且つ、hSEPPデバイスは、pSEPPデバイスであってもよい。

複数のSEPPデバイスの間に複数のIPXネットワークが存在するときに、pSEPPデバイスに直接的に接続されているIPXネットワークは、pIPXと称され、cSEPPデバイスに直接的に接続されているIPXネットワークは、cIPXと称される。

IPXネットワークは、DRAデバイス及びDNSを含んでもよい。IPXデバイスは、IPXネットワークの中のDRAデバイス又はDNSであってもよい。

上記のネットワークアーキテクチャに基づいて、以下の記載は、2つのSEPPデバイスの間での安全な通信のための実装解決方法を説明する。図2は、この出願のある1つの実施形態にしたがった安全な通信方法の概略的なフローチャートである。

この実施形態においては、説明のために、SEPPデバイスの安全性証明書が、SEPPデバイスの証明書サーバのルート証明書であるある1つの例を使用する。この実施形態における通信方法は、以下のステップを含んでもよい。

201: 第1のSEPPデバイスは、セキュリティサーバに、第1のSEPPデバイスの証明書サーバのルート証明書をアップロードする。

この実施形態において、第1のSEPPデバイスの証明書サーバは、第1のSEPPデバイスにデバイス証明書を割り当て、第1のSEPPデバイスは、また、証明書サーバのルート証明書を取得する。ルート証明書は、第1のSEPPデバイスのデバイス証明書の有効性に関する検証を実行するのに使用されてもよい。証明書サーバは、具体的には、信頼されている証明書発行サーバであってもよい。

この実施形態において、第1のSEPPデバイスがセキュリティサーバにアップロードする安全性証明書は、具体的には、第1のSEPPデバイスの証明書サーバのルート証明書(略して、第1のSEPPデバイスのルート証明書)である。

第1のSEPPデバイスは、ハイパーテキスト転送プロトコル(Hypertext Transfer Protocol, http)メッセージ又はハイパーテキスト転送プロトコルセキュア(Hypertext Transfer Protocol Secure, https)メッセージを使用することによって、セキュリティサーバにルート証明書をアップロードしてもよい。そのメッセージは、さらに、例えば、オペレータのドメインネーム、オペレータの識別子、及び公衆陸上モバイルネットワーク識別情報(public land mobile network identity, PLMN ID)のうちの1つ又は複数等の第1のSEPPデバイスのオペレータ情報を搬送してもよい。そのメッセージは、また、第1のSEPPデバイスの識別子を搬送してもよい。

セキュリティサーバは、メッセージを使用することによって、第1のSEPPデバイスがアップロードする安全性証明書を受信し、そして、安全性証明書を局所的に格納してもよい。

202: 第2のSEPPデバイスは、セキュリティサーバに、第2のSEPPデバイスの証明書サーバのルート証明書をアップロードする。

この実施形態において、第2のSEPPデバイスの証明書サーバは、第2のSEPPデバイスにデバイス証明書を割り当て、第2のSEPPデバイスは、また、証明書サーバのルート証明書を取得する。ルート証明書は、第2のSEPPデバイスのデバイス証明書の有効性に関する検証を実行するのに使用されてもよい。

第2のSEPPデバイスは、httpメッセージ又はhttpsメッセージを使用することによって、セキュリティサーバにルート証明書をしてもよい。セキュリティサーバは、安全性証明書を受信してもよく、その安全性証明書は、メッセージを使用することによって第2のSEPPデバイスがアップロードするとともに第2のSEPPデバイスに対応している。この実施形態において、安全性証明書は、第2のSEPPデバイスの証明書サーバのルート証明書(略して、第2のSEPPデバイスのルート証明書)である。

加えて、ステップ201及び202は、時間的な順序には依存しない、すなわち、ステップ202は、ステップ201の前に実行されてもよい。

203: 第1のSEPPデバイスは、セキュリティサーバから第1のメッセージを受信し、その第1のメッセージは、第2のSEPPデバイスの証明書サーバのルート証明書を搬送する。

この実施形態において、第1のSEPPデバイスは、セキュリティサーバに要求メッセージ(request message)を自発的に送信して、第2のSEPPデバイスの証明書サーバのルート証明書を取得してもよい。代替的に、セキュリティサーバは、第1のメッセージを使用することによって、第1のSEPPデバイスに、第2のSEPPデバイスの証明書サーバのルート証明書を自発的にプッシュ通知してもよい。

第1のメッセージは、通知(notification)メッセージであってもよい。第1のメッセージは、さらに、第2のSEPPデバイスの識別子及び/又はオペレータ情報を搬送してもよい。第2のSEPPデバイスの識別子は、第2のSEPPデバイスのアドレス又はホストネームであってもよい。

204: 第2のSEPPデバイスは、セキュリティサーバから第1のメッセージを受信し、その第1のメッセージは、第1のSEPPデバイスの証明書サーバのルート証明書を搬送する。

それに対応して、第2のSEPPデバイスは、セキュリティサーバから第1のSEPPデバイスの証明書サーバのルート証明書を自発的に取得してもよい。代替的に、セキュリティサーバは、第1のメッセージを使用することによって、第2のSEPPデバイスに、第1のSEPPデバイスの証明書サーバのルート証明書を自発的にプッシュ通知してもよい。

加えて、ステップ203と204は時間的な順序には依存しない、すなわち、ステップ204は、ステップ203の前に実行されてもよい。ステップ203及びステップ204における第1のメッセージは、同じタイプのメッセージであるが、異なるコンテンツを搬送する。

ステップ201乃至204を完了した後に、第2のSEPPデバイスの証明書サーバのルート証明書は、第1のSEPPデバイスにおいて格納され、第1のSEPPデバイスの証明書サーバのルート証明書は、また、第2のSEPPデバイスにおいて格納される。

205: 第1のSEPPデバイスは、第2のSEPPデバイスのデバイス証明書を受信し、第2のSEPPデバイスは、第1のSEPPデバイスが送信するデバイス証明書を受信する。

この実施形態において、第1のSEPPデバイスが第2のSEPPデバイスへのデータ伝送(転送)チャネルを確立するときに、第1のSEPPデバイス及び第2のSEPPデバイスは、それぞれの自身のデバイス証明書を交換する。

この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスは、代替的に、自身の公開鍵を交換してもよい。

206: 第1のSEPPデバイスは、第2のSEPPデバイスの証明書サーバのルート証明書を使用することによって、第2のSEPPデバイスのデバイス証明書に対して検証を実行する。

この実施形態において、第1のSEPPデバイスは、第2のSEPPデバイスの証明書サーバの以前に格納されているルート証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書に対して検証を実行する。検証プロセスは、第2のSEPPデバイスのデバイス証明書の発行機関がルート証明書における発行機関であるか否かの検証を含む。ルート証明書は、ユーザ情報をさらに含んでもよい。第1のSEPPデバイスは、第2のSEPPデバイスが認可されているユーザであるか否かを検証してもよい。

加えて、第1のSEPPデバイスは、さらに、第2のSEPPデバイスのデバイス証明書の有効期間に関する検証及びデバイス証明書が失効しているか否かに関する検証等を実行してもよい。

検証に成功している場合には、第1のSEPPデバイスは、第2のSEPPデバイスのデバイス証明書の中の公開鍵を使用することによって、第2のSEPPデバイスに、暗号化されているメッセージを送信し、第2のSEPPデバイスは、第2のSEPPデバイスの秘密鍵を使用することによって、その暗号化されているメッセージを復号化して、例えば、乱数RAND1等のその暗号化されているメッセージの中のパラメータを取得してもよい。検証に失敗している場合には、第1のSEPPデバイスは、第2のSEPPデバイスに失敗通知メッセージを送信する。

この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスがそれぞれの自身の公開鍵を交換する場合に、第1のSEPPデバイスは、第2のSEPPデバイスの証明書サーバの以前に格納されているルート証明書を使用することによって、第2のSEPPデバイスが送信する公開鍵に対して検証を実行する。この場合には、検証プロセスは、具体的には、第2のSEPPデバイスの公開鍵の発行機関がルート証明書の中の発行機関であるか否かの検証を含む。

207: 第2のSEPPデバイスは、第1のSEPPデバイスの証明書サーバのルート証明書を使用することによって、第1のSEPPデバイスのデバイス証明書に対して検証を実行する。

ステップ206に対応して、第2のSEPPデバイスは、第1のSEPPデバイスの証明書サーバの以前に格納されているルート証明書を使用することによって、第1のSEPPデバイスが送信するデバイス証明書に対して検証を実行する。検証プロセスは、第1のSEPPデバイスのデバイス証明書の発行機関がルート証明書に対応する発行機関であるか否かの検証を含む。

加えて、第2のSEPPデバイスは、さらに、デバイス証明書の有効期間に関する検証及びデバイス証明書が失効しているか否かに関する検証等を実行してもよい。具体的な実装の際に、第1のSEPPデバイスは、第2のSEPPデバイスの識別子を使用することによって、第2のSEPPデバイスの証明書サーバのルート証明書と第2のSEPPデバイスのデバイス証明書を関連させてもよい。

検証に成功している場合には、第2のSEPPデバイスは、第1のSEPPデバイスのデバイス証明書の中の公開鍵を使用することによって、第1のSEPPデバイスに、暗号化されているメッセージを送信し、第1のSEPPデバイスは、第1のSEPPデバイスの秘密鍵を使用することによって、その暗号化されているメッセージを復号化して、例えば、乱数RAND2等のその暗号化されているメッセージの中のパラメータを取得してもよい。検証に失敗している場合には、第2のSEPPデバイスは、第1のSEPPデバイスに失敗通知メッセージを送信する。

この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスがそれぞれの自身の公開鍵を交換する場合に、第2のSEPPデバイスは、第1のSEPPデバイスの証明書サーバの以前に格納されているルート証明書を使用することによって、第1のSEPPデバイスが送信する公開鍵に対して検証を実行する。この場合には、検証プロセスは、具体的には、第1のSEPPデバイスの公開鍵の発行機関がルート証明書の中の発行機関であるか否かの検証を含む。

208: 検証の成功の後に、第1のSEPPデバイス及び第2のSEPPデバイスは、セッション鍵を計算し、そして、そのセッション鍵を使用することによって安全な通信を実行する。

第1のSEPPデバイスが第2のSEPPデバイスに検証成功メッセージを送信した後に、第1のSEPPデバイスは、RAND1及びRAND2を使用することによって、安全な通信のために使用されるセッション鍵を計算する。それに対応して、第1のSEPPデバイスに検証成功メッセージを送信した後に、第2のSEPPデバイスは、また、RAND1及びRAND2を使用することによって、安全な通信のために使用されるセッション鍵を計算してもよい。

セッション鍵を計算するときに、第1のSEPPデバイス及び第2のSEPPデバイスは、さらに、他のパラメータ及び暗号化アルゴリズムを使用してもよい。このことは、この実施形態においては限定されない。

互いにシグナリングメッセージを転送するときに、第1のSEPPデバイス及び第2のSEPPデバイスは、セッション鍵を使用することによって暗号化を実行してもよい。そのシグナルメッセージを受信した後に、受信者は、また、そのセッション鍵を使用することによって復号化を実行してもよい。すなわち、第1のSEPPデバイスと第2のSEPPデバイスとの間にセキュリティ接続を確立する。

この実施形態によって提供される技術的解決方法において、第1のSEPPデバイスは、セキュリティサーバからピアSEPPデバイス(第2のSEPPデバイス)の証明書サーバのルート証明書を取得してもよく、以降に、第2のSEPPデバイスのデバイス証明書を受信した後に、証明書サーバのルート証明書を使用することによって、第2のSEPPデバイスのデバイス証明書の有効性に関する検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間での通信の安全性を改善する。第2のSEPPデバイスは、また、同様の安全な通信方法を使用することによって、第1のSEPPデバイスのデバイス証明書に対して検証を実行してもよい。従来技術と比較して、この実施形態は、2つのSEPPデバイスが互いのデバイス証明書に対して検証を実行し、それにより、それらの2つのSEPPデバイスの間での通信の安全性を改善する解決方法を提供する。

この出願のこの実施形態において、セッション鍵を計算した後に、第1のSEPPデバイス及び第2のSEPPデバイスは、そのセッション鍵を使用することによって安全な通信を実行することが可能である。この場合には、第1のSEPPデバイスと第2のSEPPデバイスとの間に、セキュリティ接続(又は、安全な伝送チャネル、安全なリンク、又は安全なデータ転送チャネル等と称される)を確立する。そのセキュリティ接続は、具体的には、トランスポート層セキュリティ(Transport Layer Security, TLS)接続、インターネットプロトコルセキュリティ(Internet Protocol Security, IPsec)接続、又は他の基礎となるセキュリティ接続等であってもよい。この出願の複数の実施形態における接続は、また、トンネル又はチャネル等と称されてもよい。例えば、TLS接続は、また、TLSトンネル又はTLSチャネルと称されてもよく、IPsec接続は、また、IPsecトンネル又はIPsecチャネルと称されてもよい。

上記の例示的な解決方法において、第1のSEPPデバイスは、その接続されているセキュリティサーバからピアSEPPデバイスの証明書サーバのルート証明書を直接的に取得してもよく、さらに、そのピアSEPPデバイスからデバイス証明書を受信するときに、第1のSEPPデバイスは、取得したルート証明書を使用することによって、ピアSEPPデバイスのデバイス証明書に対してセキュリティ検証を実行し、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間での通信の安全性を改善するということを知ることが可能である。加えて、上記の解決方法は、手動の操作を介在させることなく、SEPPデバイスの証明書サーバのルート証明書の自動的な配布を実装するのに役立ち、それにより、ルート証明書の配布プロセスでの人的な誤操作及び伝送プロセスの中で攻撃されるリスクを減少させるのに役立つ。加えて、上記のルート証明書の配布プロセスは簡素化され、それにより、コストを減少させるのに役立つ。

この出願のこの実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスの証明書サーバのルート証明書を更新した後に、第1のSEPPデバイス及び第2のSEPPデバイスは、セキュリティサーバに対するルート証明書を更新してもよい。この実施形態において、第1のSEPPデバイスは、ルート証明書の更新プロセスを説明するための例として使用される。

例えば、第1のSEPPデバイスは、第2のメッセージを使用することによって、セキュリティサーバに、更新されているルート証明書を送信してもよく、セキュリティサーバは、第1のSEPPデバイスの証明書サーバの局所的に格納されているルート証明書を更新してもよい。その次に、セキュリティサーバは、第1のメッセージを使用することによって、第2のSEPPデバイスに、第1のSEPPデバイスのセキュリティサーバの更新されたルート証明書を送信してもよい。ステップ204乃至208のプロセスは、第2のSEPPデバイスと第1のSEPPデバイスとの間で再び実行されて、第1のSEPPデバイスと第2のSEPPデバイスとの間に新しいセキュリティ接続を確立し、シグナリングメッセージは、新しいセッション鍵を使用することによって暗号化される。

図3は、この出願のある1つの実施形態にしたがった他の安全な通信方法の概略的なフローチャートである。

この実施形態においては、説明のために、SEPPデバイスの安全性証明書が、SEPPデバイスの証明書サーバのルート証明書であるある1つの例を使用する。この実施形態のある1つの例示的な解決方法において、セキュリティサーバは、具体的にはDNSサーバであり、DNSサーバは、IPXネットワークの中に位置していてもよい。

具体的には、この実施形態における安全な通信方法は、以下のステップを含んでもよい。

301: 第1のSEPPデバイスは、DNSサーバにTLSA RRメッセージを送信し、そのTLSA RRメッセージは、第1のSEPPデバイスのホストネーム及び第1のSEPPデバイスの証明書サーバのルート証明書を搬送する。

この実施形態において、第1のSEPPデバイスは、TLS認証リソース記録(TLS Authentication resource record, TLSA RR)メッセージを使用することによって、DNSサーバに、第1のSEPPデバイスに対応する安全性証明書をアップロードする。この実施形態において、安全性証明書は、第1のSEPPデバイスの証明書サーバのルート証明書である。

加えて、TLSA RRメッセージは、第1のSEPPデバイスのホストネームをさらに含む。

TLS RRメッセージのコンテンツは、_443._tcp.www.example.com. IN TLSA (1 1 2 92003ba34942dc74152e2f2c408d29eca5a520e7f2e06bb944f4dca346baf63c1b177615d466f6c4b71c216a50292bd58c9ebdd2f74e38fe51ffd48c43326cbc)であってもよい。かっこ内のコンテンツは、第1のSEPPデバイスの証明書サーバのルート証明書を含む。

302: 第2のSEPPデバイスは、DNSサーバにTLSA RRメッセージを送信し、そのTLSA RRメッセージは、第2のSEPPデバイスのホストネーム及び第2のSEPPデバイスの証明書サーバのルート証明書を搬送する。

第2のSEPPデバイスによるDNSサーバへのTLSA RRメッセージの送信の詳細については、ステップ301の説明を参照するべきである。ステップ301及び302は、時間的な順序には依存しなくてもよい、すなわち、ステップ302は、ステップ301の前に実行されてもよい。

ある1つの可能な実施形態においては、DNSサーバにおいて、第1のSEPPデバイスのホストネーム、第1のSEPPデバイスの証明書サーバのルート証明書、第2のSEPPデバイスのホストネーム、及び第2のSEPPデバイスの証明書サーバのルート証明書を構成してもよい。したがって、この実施形態によって提供される安全な通信方法は、以下のステップ303から直接的に開始してもよい。

303: 第1のSEPPデバイスは、DNSサーバにDNS要求メッセージを送信し、そのDNS要求メッセージは、第2のSEPPデバイスのホストネームを搬送する。

この実施形態において、第1のSEPPデバイスは、DNS要求メッセージを使用することによって、DNSサーバから第2のSEPPデバイスの証明書サーバのルート証明書を自発的に取得する。DNS要求メッセージのメッセージ本体は、第2のSEPPデバイスの識別子を搬送する。この実施形態においては、第2のSEPPデバイスの識別子は、第2のSEPPデバイスのホストネームである。DNS要求メッセージは、具体的には、DNSクエリ要求であってもよい。

304: DNSサーバは、第1のSEPPデバイスにDNS応答メッセージを送信し、DNS応答メッセージは、第2のSEPPデバイスの証明書サーバのルート証明書及び有効期間(time to live, TTL)を搬送する。

第1のSEPPデバイスが送信するDNS要求メッセージを受信した後に、DNSサーバは、DNS要求メッセージの中で搬送されている第2のSEPPデバイスの識別子に対応するルート証明書を取得し、そして、その次に、第1のSEPPデバイスにDNS応答メッセージを返送する。

DNS応答メッセージは、第2のSEPPデバイスの証明書サーバのルート証明書及び有効期間を搬送する。加えて、DNS応答メッセージは、さらに、第2のSEPPデバイスのIPアドレスを搬送してもよい。DNS応答メッセージは、具体的には、DNSクエリ応答であってもよい。

DNS応答メッセージを受信した後に、第1のSEPPデバイスは、DNS応答メッセージの中の第2のSEPPデバイスの証明書サーバのルート証明書をキャッシュする。DNS応答メッセージは、具体的には、DNSクエリ応答であってもよい。

305: 第2のSEPPデバイスは、DNSサーバにDNS要求メッセージを送信し、そのDNS要求メッセージは、第1のSEPPデバイスのホストネームを搬送する。

306: DNSサーバは、第2のSEPPデバイスにDNS応答メッセージを送信し、そのDNS応答メッセージは、第1のSEPPデバイスの証明書サーバのルート証明書及び有効期間を搬送する。

それに対応して、第2のSEPPデバイスは、また、DNSサーバにDNS要求メッセージを送信し、DNSサーバは、第2のSEPPデバイスにDNS応答メッセージを返送する。ステップ305及び306の具体的な実行プロセスは、ステップ303及び304の実行プロセスと同様である。本明細書においては、詳細は繰り返しては説明されない。

加えて、第2のSEPPデバイスによるDNSサーバへのDNS要求メッセージの送信及び第1のSEPPデバイスによるDNSサーバへのDNS要求メッセージの送信は、時間的な順序には依存しない、すなわち、ステップ305は、代替的に、ステップ303の前に実行されてもよい。

307: 第1のSEPPデバイスは、第2のSEPPデバイスのデバイス証明書を受信し、第2のSEPPデバイスは、第1のSEPPデバイスが送信するデバイス証明書を受信する。

308: 第1のSEPPデバイスは、第2のSEPPデバイスの証明書サーバのルート証明書を使用することによって、第2のSEPPデバイスのデバイス証明書に対して検証を実行する。

309: 第2のSEPPデバイスは、第1のSEPPデバイスの証明書サーバのルート証明書を使用することによって、第1のSEPPデバイスのデバイス証明書に対して検証を実行する。

310: 検証の成功の後に、第1のSEPPデバイス及び第2のSEPPデバイスは、セッション鍵を計算し、そして、そのセッション鍵を使用することによって、安全な通信を実行する。

ステップ307乃至310の実行プロセスは、ステップ205乃至208の実行プロセスと同様である。詳細については、上記の実施形態の説明を参照するべきである。

311: TTLが終了した後に、第1のSEPPデバイスは、再びDNSサーバにDNS要求メッセージを送信し、そのDNS要求メッセージは、第2のSEPPデバイスのホストネームを搬送する。

この実施形態において、第1のSEPPデバイスが受信するDNS応答メッセージは、TTLを搬送し、TTLが終了しているということを決定した後に、第1のSEPPデバイスは、再びDNS要求メッセージを送信するステップを実行して、再び第2のSEPPデバイスに対応する安全性証明書(この実施形態においては、証明書サーバのルート証明書)を取得する。更新された安全性証明書を取得した後に、第1のSEPPデバイスは、再びステップ307乃至310のプロセスを実行して、第2のSEPPデバイスへの新たなセキュリティ接続を確立する。

TTLが終了しているということを決定した後に、第2のSEPPデバイスは、また、再び、DNS要求メッセージを送信するステップ、すなわち、ステップ305のプロセスを実行してもよい。

この実施形態によって提供される技術的解決方法において、DNSクエリを実行するときに、第1のSEPPデバイスは、DNSサーバから第2のSEPPデバイスの証明書サーバのルート証明書を取得し、その後、第2のSEPPデバイスのデバイス証明書を受信した後に、証明書サーバのルート証明書を使用することによって、第2のSEPPデバイスのデバイス証明書の有効性に関する検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間の通信の安全性を改善する。第2のSEPPデバイスは、また、同様の安全な通信方法を使用することによって、第1のSEPPデバイスのデバイス証明書に対して検証を実行してもよい。この実施形態の技術的解決方法において、また、DNSクエリプロセスを使用し、それにより、さらに、2つのSEPPデバイスが互いのデバイス証明書に対して検証を実行するプロセスを単純化して、検証効率を改善する。

図4は、この出願のある1つの実施形態にしたがった安全な通信方法の概略的なフローチャートである。

この実施形態においては、説明のために、SEPPデバイスの安全性証明書がそのSEPPデバイスのデバイス証明書であるある1つの例を使用する。この実施形態における通信方法は、以下のステップを含んでもよい。

401: 第1のSEPPデバイスは、セキュリティサーバにその第1のSEPPデバイスのデバイス証明書をアップロードする。

この実施形態において、第1のSEPPデバイスの証明書サーバは、第1のSEPPデバイスにデバイス証明書を割り当てる。デバイス証明書は、第1のSEPPデバイスの公開鍵及び秘密鍵を含んでもよく、証明書サーバの署名をさらに含んでもよい。

この実施形態において、第1のSEPPデバイスがセキュリティサーバにアップロードする安全性証明書は、第1のSEPPデバイスのデバイス証明書であり、第1のSEPPデバイスは、httpメッセージ又はhttpsメッセージを使用することによって、セキュリティサーバに第1のSEPPデバイスのデバイス証明書をアップロードしてもよい。

代替的に、第1のSEPPデバイスは、デバイス証明書から秘密鍵を削除し、そして、その次に、セキュリティサーバに、秘密鍵が削除されているデバイス証明書をアップロードして、秘密鍵の漏洩を回避してもよい。この場合には、セキュリティサーバが受信するデバイス証明書は、第1のSEPPデバイスの公開鍵を含み、第1のSEPPデバイスの秘密鍵を含まない。

402: 第2のSEPPデバイスは、セキュリティサーバに第2のSEPPデバイスのデバイス証明書をアップロードする。

この実施形態において、第2のSEPPデバイスは、同様の方法を使用することによって、セキュリティサーバに第2のSEPPデバイスのデバイス証明書をアップロードしてもよい。具体的なプロセスについては、ステップ401の説明を参照するべきである。

加えて、ステップ401及び402は、時間的な順序には依存しない、すなわち、ステップ402は、ステップ401の前に実行されてもよい。

403: 第1のSEPPデバイスは、セキュリティサーバから第1のメッセージを受信し、その第1のメッセージは、第2のSEPPデバイスのデバイス証明書を搬送する。

この実施形態において、第1のSEPPデバイスは、セキュリティサーバに要求メッセージを自発的に送信して、第2のSEPPデバイスのデバイス証明書を取得してもよい。代替的に、セキュリティサーバは、第1のメッセージを使用することによって、第1のSEPPデバイスに、第2のSEPPデバイスのデバイス証明書を自発的にプッシュ通知してもよい。

第1のメッセージは、さらに、第2のSEPPデバイスの識別子を搬送してもよい。第2のSEPPデバイスの識別子は、第2のSEPPデバイスのアドレス又はホストネームであってもよい。

404: 第2のSEPPデバイスは、セキュリティサーバから第1のメッセージを受信し、その第1のメッセージは、第1のSEPPデバイスのデバイス証明書を搬送する。

ステップ403及び404は、時間的な順序には依存しなくてもよい、すなわち、ステップ404は、ステップ403の前に実行されてもよい。

ステップ401乃至404を完了した後に、第2のSEPPデバイスのデバイス証明書は、第1のSEPPデバイスの中に格納され、第1のSEPPデバイスのデバイス証明書は、また、第2のSEPPデバイスにおいて格納される。

405: 第1のSEPPデバイスは、第2のSEPPデバイスが送信するデバイス証明書を受信し、第2のSEPPデバイスは、第1のSEPPデバイスが送信するデバイス証明書を受信する。

この実施形態において、第1のSEPPデバイスが第2のSEPPデバイスへのセキュリティ接続(データ伝送チャネル)を確立する前に、第1のSEPPデバイス及び第2のSEPPデバイスは、それぞれの自身のデバイス証明書を交換する。

この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスは、代替的に、自身の公開鍵を交換してもよい。

406: 第1のSEPPデバイスは、セキュリティサーバが送信する第2のSEPPデバイスのデバイス証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書に対して検証を実行する。

この実施形態において、第1のSEPPデバイスは、第2のSEPPデバイスの以前に格納されているデバイス証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書に対して検証を実行する。それらの2つのデバイス証明書が同じである場合には、検証は成功する。それらの2つのデバイス証明書が異なっている場合には、検証は失敗する。

検証に成功している場合には、第1のSEPPデバイスは、第2のSEPPデバイスのデバイス証明書の公開鍵を使用することによって、第2のSEPPデバイスに、暗号化されているメッセージを送信し、第2のSEPPデバイスは、第2のSEPPデバイスの秘密鍵を使用することによって、その暗号化されているメッセージを復号化して、例えば、その暗号化されているメッセージの中の乱数RAND1等のパラメータを取得してもよい。検証に失敗している場合には、第1のSEPPデバイスは、第2のSEPPデバイスに失敗通知メッセージを送信する。

この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスがそれぞれの自身の公開鍵を交換する場合には、第1のSEPPデバイスは、第2のSEPPデバイスの以前に格納されているデバイス証明書を使用することによって、第2のSEPPデバイスが送信する公開鍵に対して検証を実行する。この場合には、検証プロセスは、具体的には、第2のSEPPデバイスの公開鍵の発行機関がルート証明書の中の発行機関であるか否かの検証を含む。

407: 第2のSEPPデバイスは、セキュリティサーバが送信する第1のSEPPデバイスのデバイス証明書を使用することによって、第1のSEPPデバイスが送信するデバイス証明書に対して検証を実行する。

ステップ406に対応して、第2のSEPPデバイスは、第1のSEPPデバイスの以前に格納されているデバイス証明書を使用することによって、第1のSEPPデバイスが送信するデバイス証明書に対して検証を実行する。

検証に成功している場合には、第2のSEPPデバイスは、第1のSEPPデバイスのデバイス証明書の中の公開鍵を使用することによって、第1のSEPPデバイスに暗号化されているメッセージを送信し、第1のSEPPデバイスは、第1のSEPPデバイスの秘密鍵を使用することによって、その暗号化されているメッセージを復号化して、例えば、その暗号化されているメッセージの中の乱数RAND2等のパラメータを取得してもよい。検証に失敗している場合には、第2のSEPPデバイスは、第1のSEPPデバイスに失敗通知メッセージを送信する。

この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスがそれぞれの自身の公開鍵を交換する場合に、第2のSEPPデバイスは、第1のSEPPデバイスの以前に格納されているデバイス証明書を使用することによって、第1のSEPPデバイスが送信する公開鍵に対して検証を実行する。この場合には、検証プロセスは、具体的には、第1のSEPPデバイスの公開鍵の発行機関がルート証明書の中の発行機関であるか否かの検証を含む。

408: 検証の成功の後に、第1のSEPPデバイス及び第2のSEPPデバイスは、セッション鍵を計算し、そして、そのセッション鍵を使用することによって、安全な通信を実行する。

ステップ408の実装プロセスは、上記の実施形態におけるステップ208の実装プロセスと同様である。詳細については、上記の実施形態を参照するべきである。本明細書においては、詳細は繰り返しては説明されない。

この実施形態によって提供される技術的解決方法において、第1のSEPPデバイスは、セキュリティサーバからピアSEPPデバイス(第2のSEPPデバイス)のデバイス証明書を取得してもよく、以降に、その第2のSEPPデバイスのデバイス証明書を受信した後に、セキュリティサーバが送信する第2のSEPPデバイスのデバイス証明書を使用することによって、第2のSEPPデバイスが送信するデバイス証明書の有効性に関する検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間の通信の安全性を改善する。第2のSEPPデバイスは、また、同様の安全な通信方法を使用することによって、第1のSEPPデバイスの安全性証明書に対して検証を実行してもよい。加えて、上記の解決方法は、手動の操作を介在させることなく、SEPPデバイスのデバイス証明書の自動的な配布を実装するのに役立ち、それにより、デバイス証明書の配布プロセスにおける人的な誤操作及び送信プロセスの中で攻撃されるリスクを減少させるのに役立つ。

この出願のこの実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスは、それぞれ、ステップ409及びステップ410を実行してもよく、具体的にいうと、第1のSEPPデバイス及び第2のSEPPデバイスのデバイス証明書が更新された後に、セキュリティサーバに対するデバイス証明書を更新する。この実施形態において、ある1つの例として、第1のSEPPデバイスを使用して、デバイス証明書の更新プロセスを説明する。

例えば、第1のSEPPデバイスは、第2のメッセージを使用することによって、セキュリティサーバに、更新されているデバイス証明書を送信してもよく、セキュリティサーバは、第1のSEPPデバイスの局所的に格納されているデバイス証明書を更新してもよい。セキュリティサーバは、第1のメッセージを使用することによって、第2のSEPPデバイスに、第1のSEPPデバイスのその更新されているデバイス証明書を送信してもよい。ステップ404乃至408のプロセスは、再び第2のSEPPデバイスと第1のSEPPデバイスとの間で実行されて、第1のSEPPデバイスと第2のSEPPデバイスとの間で新たなセキュリティ接続を確立し、新たなセッション鍵を使用することによってシグナリングメッセージを暗号化する。

以下の記載は、複数の装置の実施形態のうちのいくつかのを説明する。

図5は、この出願のある1つの実施形態にしたがったSEPPデバイスの複数の機能の概略的な図である。この実施形態において、ある1つの例として、第1のSEPPデバイス500を使用して、SEPPデバイスの複数の機能を説明し、第2のSEPPデバイスは、また、同様の機能モジュールを含んでもよい。

図に示されているように、第1のSEPPデバイス500は、主として、通信ユニット510、検証ユニット520、及び接続確立ユニット530を含む。

通信ユニット510は、セキュリティサーバからの第1のメッセージを受信するように構成され、第1のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送し、通信ユニット510は、さらに、第2のSEPPデバイスが送信するデバイス証明書を受信するように構成される。

検証ユニット520は、受信した安全性証明書を使用することによって、第2のSEPPデバイスのデバイス証明書に対して検証を実行するように構成される。

接続確立ユニット530は、検証の成功の後に、第2のSEPPデバイスへのセキュリティ接続を確立するように構成される。

この実施形態によって提供される第1のSEPPデバイスは、上記の複数の方法の実施形態によって提供される安全な通信方法において使用されてもよい。具体的な詳細及び有益な効果については、上記の複数の実施形態を参照するべきである。この実施形態において、第1のSEPPデバイス及び第2のSEPPデバイスは、第1のSEPPデバイスの中の通信ユニット510、検証ユニット520、及び接続確立ユニット530の間の協調によってセキュリティ検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間の通信の安全性を改善する。

この実施形態によって提供される第1のSEPPデバイスにおいては、通信ユニット510は、さらに、セキュリティサーバに証明書要求メッセージを送信するように構成され、証明書要求メッセージは、第2のSEPPデバイスの識別子を搬送する。

この実施形態において、第2のSEPPデバイスに対応する安全性証明書は、第2のSEPPデバイスの証明書サーバのルート証明書であってもよく、又は、第2のSEPPデバイスのデバイス証明書であってもよい。

この実施形態によって提供される第1のSEPPデバイスにおいて、第1のSEPPデバイスと対話するセキュリティサーバは、DNSサーバであってもよい。この場合には、第1のSEPPデバイスが送信する証明書要求メッセージは、DNSクエリ要求である。それに対応して、第1のメッセージは、DNSクエリ応答である。

この実施形態によって提供される第1のSEPPデバイスにおいて、通信ユニット510は、さらに、セキュリティサーバに第2のメッセージを送信するように構成され、第2のメッセージは、第1のSEPPデバイスに対応する安全性証明書を搬送する。したがって、第2のSEPPデバイスは、セキュリティサーバから、第1のSEPPデバイスに対応する安全性証明書を取得し、そして、第1のSEPPデバイスのデバイス証明書に対して検証を実行してもよく、それにより、第1のSEPPデバイスと第2のSEPPデバイスとの間での通信の安全性を強化する。加えて、第2のメッセージは、さらに、第1のSEPPデバイスの識別子を搬送する。

この実施形態によって提供される第1のSEPPデバイスにおいて、通信ユニット510は、さらに、検証ユニット520が安全性証明書を使用することによって前記第2のSEPPデバイスの前記デバイス証明書の検証に成功しているときに、第1のSEPPデバイスによって前記第2のSEPPデバイスに、検証成功メッセージを送信して、証明書の検証に成功しているということを第2のSEPPデバイスに通知するように構成される。

この実施形態によって提供される第1のSEPPデバイスにおいて、接続確立ユニット530が、第2のSEPPデバイスへのセキュリティ接続を確立することは、特に、
接続確立ユニット530が、第2のSEPPデバイスとの安全な通信のために使用されるセッション鍵を計算し、そして、その次に、接続確立ユニット530が、セッション鍵を使用することによって、第2のSEPPデバイスへのセキュリティ接続を確立する、ことを含む。

上記の記載は、ある1つの例として、第1のSEPPデバイス500を使用することによって、SEPPデバイスの複数の機能モジュールを説明している。第2のSEPPデバイスは、また、対応する機能モジュールを含んでもよい。この場合には、第2のSEPPデバイスの中の通信ユニットは、セキュリティサーバからの第1のメッセージを受信するように構成され、第1のメッセージは、第1のSEPPデバイスに対応する安全性証明書を搬送し、通信ユニットは、さらに、第1のSEPPデバイスが送信するデバイス証明書を受信するように構成される。第2のSEPPデバイスの中の検証ユニットは、受信した安全性証明書を使用することによって、第1のSEPPデバイスのデバイス証明書に対して検証を実行するように構成される。第2のSEPPデバイスの中の接続確立ユニットは、検証の成功の後に、第1のSEPPデバイスへのセキュリティ接続を確立するように構成される。

図6は、この出願のある1つの実施形態にしたがったセキュリティサーバの複数の機能の概略的な図である。

図に示されているように、セキュリティサーバ600は、主として、取得ユニット610及び通信ユニット620を含む。

取得ユニット610は、第2のセキュリティ及びエッジ保護プロキシSEPPデバイスに対応する安全性証明書を取得するように構成される。通信ユニット620は、第1のSEPPデバイスに第1のメッセージを送信するように構成され、第1のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送する。

この実施形態によって提供されるセキュリティサーバは、上記の複数の方法の実施形態によって提供される安全な通信方法において使用されてもよい。具体的な詳細及び有益な効果については、上記の複数の実施形態を参照するべきである。この実施形態におけるセキュリティサーバは、取得ユニット610及び通信ユニット620の間の協調によって、第1のSEPPデバイスに、第2のSEPPデバイスに対応する安全性証明書を送信してもよく、それによって、第1のSEPPデバイスは、その安全性証明書を使用することによって、第2のSEPPデバイスに対して検証を実行し、その結果、通信の安全性を改善する。

加えて、取得ユニット610は、また、第1のSEPPデバイスに対応する安全性証明書を取得してもよく、そして、その次に、通信ユニット620は、第2のSEPPデバイスに第1のメッセージを送信し、第1のメッセージは、第1のSEPPデバイスに対応する安全性証明書を搬送する。したがって、第2のSEPPデバイスは、その安全性証明書を使用することによって、第1のSEPPデバイスに対して検証を実行し、それにより、通信の安全性を改善する。

この実施形態によって提供されるセキュリティサーバにおいて、通信ユニット620は、さらに、第1のSEPPデバイスが送信する証明書要求メッセージを受信するように構成され、証明書要求メッセージは、第2のSEPPデバイスの識別子を搬送する。

この実施形態によって提供されるセキュリティサーバにおいて、取得ユニット610が第2のSEPPデバイスに対応する安全性証明書を取得する前に、通信ユニット620は、さらに、第2のSEPPデバイスが送信する第2のメッセージを受信し、第2のメッセージは、第2のSEPPデバイスに対応する安全性証明書を搬送する。この場合には、取得ユニット610は、受信した第2のメッセージから、第2のSEPPデバイスに対応する安全性証明書を取得する。第2のメッセージは、さらに、第2のSEPPデバイスの識別子を搬送してもよく、その識別子は、第2のSEPPデバイスに対応する安全性証明書と第2のSEPPデバイスを関連させるのに使用される。

図7は、この出願のある1つの実施形態にしたがった通信装置700の構成の概略的な図であり、図8は、通信装置700の中の基板730のインターフェイスの概略的な図である。

図に示されているように、その通信装置は、主として、キャビネット720及びそのキャビネットの中に設置されている基板730を含む。その基板は、チップ及び電子構成要素を含み、通信サービスを提供してもよい。実際の要件にしたがって、基板730の数を増加させてもよく又は減少させてもよく、基板730の数は、この実施形態においては限定されない。加えて、キャビネット720は、さらに、キャビネット扉721を装備する。

基板730は、例えば、外部ディスプレイの接続のために使用されるディスプレイインターフェイス731、通信ネットワークに接続されるネットワークインターフェイス732、及びユニバーサルシリアルバス(Universal Serial Bus, USB)インターフェイス733等の複数の入力インターフェイス/出力インターフェイスを含む。

加えて、基板730は、電源に接続されている電力インターフェイス733及び熱放散のために使用される熱放散ベント734等をさらに含む。

通信装置は、複数の異なる基板730を装備するときの複数の異なる機能を実装し、例えば、この出願の複数の実施形態におけるSEPPデバイス又はセキュリティサーバの複数の機能を実装してもよい。基板730は、例えば、汎用プロセッサ、制御チップ、又は論理回路等の制御要素を装備する。基板730は、また、メモリを装備してもよい。プロセッサ及びメモリは、関連する通信インターフェイスと協働して、この出願の複数の実施形態においてSEPPデバイス又はセキュリティサーバが実行することが可能である任意の方法の複数のステップのうちの一部又はすべてを実行してもよい。

図9は、本発明のある1つの実施形態にしたがったSEPPデバイス及びセキュリティサーバのハードウェア構成の図である。

この実施形態によって提供されるSEPPデバイス及びセキュリティサーバの双方のために、プロセッサ901、メモリ902、バス903、入力デバイス904、出力デバイス905、及びネットワークインターフェイス906を含む汎用コンピュータハードウェアを使用してもよい。

具体的には、メモリ902は、例えば、読み取り専用メモリ及び/又はランダムアクセスメモリ等の揮発性メモリ及び/又は不揮発性メモリの形態のコンピュータ記憶媒体を含んでもよい。メモリ902は、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、実行可能コード、及びプログラムデータを格納してもよい。

入力デバイス904は、AMFデバイス又はMSCにコマンド及び情報を入力するように構成されてもよい。例えば、入力デバイス904は、例えば、マウス、トラックボール、タッチパッド、マイクロフォン、ジョイスティック、ゲームパッド、衛星テレビアンテナ、スキャナ、又は同様のデバイス等のキーボード又はポインティングデバイスである。これらの入力デバイスは、バス903によってプロセッサ901に接続されてもよい。

出力デバイス905は、AMFデバイス又はMSCから情報を出力するように構成されてもよい。モニタのほかに、出力デバイス905は、代替的に、例えば、スピーカ及び/又は印刷デバイス等の他の周辺機器出力デバイスであってもよい。これらの出力デバイスは、また、バス903によってプロセッサ901に接続されてもよい。

SEPPデバイス又はセキュリティサーバは、ネットワークインターフェイス906によって、例えば、ローカルエリアネットワーク(Local Area Network, LAN)等の通信ネットワークに接続されてもよい。あるネットワーク環境において、SEPPデバイス及びセキュリティサーバにおいて格納されているコンピュータ実行可能な命令は、リモートストレージデバイスに格納されてもよく、ローカルストレージには限定されない。

SEPPデバイスの中のプロセッサ901が、メモリ902の中に格納されている実行可能なコード又はアプリケーションプログラムを実行するときに、そのSEPPデバイスは、上記の複数の方法の実施形態において、SEPPデバイス側で、例えば、ステップ201、203、303、307、及び405等の方法のステップを実行してもよい。具体的な実行プロセスについては、上記の複数の方法の実施形態を参照するべきである。本明細書においては、詳細は繰り返しては説明されない。

セキュリティサーバの中のプロセッサ901は、メモリ902の中に格納されている実行コード又はアプリケーションプログラムを実行するときに、セキュリティサーバは、上記の複数の方法の実施形態において、セキュリティサーバ側で、例えば、ステップ203、204、及び403等の複数の方法ステップを実行してもよい。具体的な実行プロセスについては、上記の複数の方法の実施形態を参照するべきである。本明細書においては、詳細は繰り返しては説明されない。

この出願のある1つの実施形態は、さらに、コンピュータ読み取り可能な記憶媒体を提供する。そのコンピュータ読み取り可能な記憶媒体は、コンピュータプログラムを格納する。コンピュータプログラムが(例えば、プロセッサ等の)ハードウェアによって実行されるときに、この出願の複数の実施形態においてSEPPデバイス又はセキュリティサーバが実行することが可能である任意の方法の複数のステップのうちの一部又はすべてを完了することが可能である。

この出願のある1つの実施形態は、さらに、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータデバイスによって実行されるときに、そのコンピュータデバイスが、SEPPデバイス又はセキュリティサーバが実行することが可能である任意の方法の複数のステップのうちの一部又はすべてを実行することを可能とする。

ソフトウェア、ハードウェア、ファームウェア、又はそれらのいずれかの組み合わせを使用して、上記の複数の実施形態のうちのすべて又は一部を実装することが可能である。ソフトウェアを使用して、複数の実施形態を実装するときに、コンピュータプログラム製品の形態によって、複数の実施形態のうちのすべて又は一部を実装することが可能である。そのコンピュータプログラム製品は、1つ又は複数のコンピュータ命令を含む。コンピュータ命令がコンピュータによってロードされそして実行されるときに、この出願の複数の実施形態にしたがった手順又は機能を全体的に又は部分的に生成する。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、又は他のプログラム可能な装置であってもよい。コンピュータ命令は、あるコンピュータ読み取り可能な記憶媒体の中に格納されてもよく、又は、あるコンピュータ読み取り可能な記憶媒体から他のコンピュータ読み取り可能な記憶媒体へと伝送されてもよい。例えば、(例えば、同軸ケーブル、光ファイバ、又は、ディジタル加入者線等の)有線方式によって又は(例えば、赤外線、無線、及び、マイクロ波等の)無線方式によって、あるウェブサイト、コンピュータ、サーバ、又はデータセンターから他のウェブサイト、コンピュータ、サーバ、又はデータセンターへと、コンピュータ命令を伝送してもよい。コンピュータ読み取り可能な記憶媒体は、コンピュータがアクセス可能である任意の使用可能な媒体であってもよく、或いは、例えば、1つ又は複数の使用可能な媒体を一体化しているサーバ又はデータセンター等のデータ記憶デバイスであってもよい。使用可能な媒体は、(例えば、フロッピーディスク、ハードディスク、又は磁気テープ等の)磁気媒体、(例えば、光ディスク等の)光媒体、或いは、(例えば、ソリッドステートドライブ等の)半導体媒体等であってもよい。上記の複数の実施形態において、複数の実施形態の説明にそれぞれ焦点が当てられている。ある1つの実施形態の中で詳細には説明されていない部分については、他の実施形態の中の関連する説明を参照するべきである。

上記の複数の実施形態において、複数の実施形態の説明にそれぞれ焦点が当てられている。ある1つの実施形態の中で詳細には説明されていない部分については、他の実施形態の中の関連する説明を参照するべきである。

この出願によって提供される複数の実施形態において、他の方式によって、それらの開示されている装置を実装してもよいということを理解するべきである。例えば、説明されている装置の実施形態は、例であるにすぎない。例えば、ユニットへの分割は、論理的な機能の分割であるにすぎず、実際の実装においては、他の分割であってもよい。例えば、複数のユニット又は構成要素を組み合わせ又は一体化して、他のシステムとしてもよく、或いは、複数の機能のうちのいくつかを無視してもよく、又は、実行しなくてもよい。加えて、複数のインターフェイスのうちのいくつかを使用することによって、示され又は説明されている相互の非直接的な結合又は直接的な結合又は通信接続を実装してもよい。電気的な形態又はその他の形態によって、複数の装置又は複数のユニットの間の非直接的な結合又は通信接続を実装してもよい。

個別の部分として説明されている上記のユニットは、物理的に分離していてもよく又は物理的に分離していなくてもよく、複数のユニットとして示されている複数の部分は、複数の物理的なユニットであってもよく又は複数の物理的なユニットでなくてもよく、言い換えると、1つの場所に位置していてもよく、或いは、複数のネットワークユニットにわたって分散していてもよい。実際の要求に基づいて、それらの複数のユニットのうちの一部又はすべてを選択して、複数の実施形態の複数の解決方法の目的を達成してもよい。

加えて、この出願の複数の実施形態における複数の機能的なユニットを一体化して、1つの処理ユニットとしてもよく、或いは、それらの複数のユニットの各々は、物理的に単独で存在していてもよく、或いは、2つ又はそれ以上のユニットを一体化して、1つのユニットとしてもよい。一体化されているユニットは、ハードウェアの形態で実装されてもよく、又は、ソフトウェアの機能ユニットの形態で実装されてもよい。

一体化されているユニットがソフトウェア機能ユニットの形態で実装され、且つ、独立した製品として販売され又は使用されるときに、コンピュータ読み取り可能な記憶媒体の中に一体化されているユニットを格納してもよい。そのような理解に基づいて、この出願のそれらの複数の技術的解決方法は、本質的に、或いは、従来の技術に寄与する部分又はそれらの複数の技術的解決方法のうちのすべて又は一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体の中に格納され、いくつかの命令を含み、それらのいくつかの命令は、この出願の複数の実施形態の中で説明されている複数の方法の複数のステップのうちのすべて又は一部を実行するように、(パーソナルコンピュータ、サーバ、又はネットワークデバイス等であってもよい)コンピュータデバイスに指示する。

Claims (23)

1. 安全な通信方法であって、
   第1のセキュリティ及びエッジ保護プロキシデバイスによって、セキュリティサーバからの第1のメッセージを受信するステップであって、前記第1のメッセージは、第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を搬送する、ステップと、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスからのデバイス証明書を受信するステップと、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記安全性証明書を使用することによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記デバイス証明書に対して検証を実行するステップと、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記検証の成功の後に、前記第2のセキュリティ及びエッジ保護プロキシデバイスへのセキュリティ接続を確立するステップとを含み、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、セキュリティサーバからの第1のメッセージを受信するステップの前に、当該方法は、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記セキュリティサーバに証明書要求メッセージを送信するステップであって、前記証明書要求メッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスの識別子を搬送する、ステップをさらに含み、
   前記セキュリティサーバは、ドメインネームシステム(DNS)サーバであり、前記証明書要求メッセージは、DNSクエリ要求である、方法。
   
2. 前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書は、前記第2のセキュリティ及びエッジ保護プロキシデバイスの証明書サーバのルート証明書である、請求項1に記載の方法。
3. 前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、セキュリティサーバからの第1のメッセージを受信するステップの前に、当該方法は、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記セキュリティサーバに第2のメッセージを送信するステップであって、前記第2のメッセージは、前記第1のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を搬送する、ステップをさらに含む、請求項1又は2に記載の方法。
4. 前記第2のメッセージは、さらに、前記第1のセキュリティ及びエッジ保護プロキシデバイスの識別子を搬送する、請求項3に記載の方法。
5. 前記安全性証明書を使用することによって前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記デバイス証明書の検証に成功しているときに、前記第1のセキュリティ及びエッジ保護プロキシデバイスによって前記第2のセキュリティ及びエッジ保護プロキシデバイスに、検証成功メッセージを送信するステップをさらに含む、請求項1乃至4のうちのいずれか1項に記載の方法。
6. 前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスへのセキュリティ接続を確立するステップは、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスとの安全な通信のために使用されるセッション鍵を計算するステップと、
   前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記セッション鍵を使用することによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスへのセキュリティ接続を確立するステップとを含む、請求項1乃至5のうちのいずれか1項に記載の方法。
7. 安全な通信方法であって、
   セキュリティサーバによって、第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を取得するステップと、
   前記セキュリティサーバによって、第1のセキュリティ及びエッジ保護プロキシデバイスに第1のメッセージを送信するステップであって、前記第1のメッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書を搬送する、ステップとを含み、
   前記セキュリティサーバによって、第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を取得するステップの前に、当該方法は、
   前記セキュリティサーバによって、前記第1のセキュリティ及びエッジ保護プロキシデバイスからの証明書要求メッセージを受信するステップであって、前記証明書要求メッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスの識別子を搬送する、ステップをさらに含み、
   前記セキュリティサーバは、ドメインネームシステム(DNS)サーバであり、前記証明書要求メッセージは、DNSクエリ要求である、方法。
8. 前記セキュリティサーバによって、第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を取得するステップの前に、当該方法は、
   前記セキュリティサーバによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスからの第2のメッセージを受信するステップであって、前記第2のメッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書を搬送する、ステップをさらに含む、請求項7に記載の方法。
9. 前記第2のメッセージは、さらに、前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記識別子を搬送する、請求項8に記載の方法。
10. コンピュータ読み取り可能な記憶媒体であって、
    当該コンピュータ読み取り可能な記憶媒体は、コンピュータプログラムを格納し、前記コンピュータプログラムがプロセッサによって実行されるときに、請求項1乃至9のうちのいずれか1項にしたがった方法を完了することが可能である、コンピュータ読み取り可能な記憶媒体。
11. セキュリティ及びエッジ保護プロキシデバイスであって、
    少なくとも1つのプロセッサと、
    前記少なくとも1つのプロセッサに結合されて、前記少なくとも1つのプロセッサによって実行するためのプログラミング命令を格納する少なくとも1つのメモリとを含み、前記少なくとも1つのプロセッサは、
    セキュリティサーバからの第1のメッセージであって第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を搬送する第１のメッセージを受信し、
    前記第2のセキュリティ及びエッジ保護プロキシデバイスからのデバイス証明書を受信し、
    前記安全性証明書を使用することによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記デバイス証明書に対して検証を実行し、
    前記検証の成功の後に、前記第2のセキュリティ及びエッジ保護プロキシデバイスへのセキュリティ接続を確立する、ように構成され、
    前記少なくとも1つのプロセッサは、前記セキュリティサーバに証明書要求メッセージを送信するようにさらに構成され、前記証明書要求メッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスの識別子を搬送し、
    前記セキュリティサーバは、ドメインネームシステム(DNS)サーバであり、前記証明書要求メッセージは、DNSクエリ要求である、デバイス。
12. 前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書は、前記第2のセキュリティ及びエッジ保護プロキシデバイスの証明書サーバのルート証明書である、請求項11に記載のデバイス。
13. 前記少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行するための前記プログラミング命令を格納し、前記少なくとも1つのプロセッサは、
    前記セキュリティサーバに第2のメッセージを送信するように構成され、前記第2のメッセージは、当該セキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を搬送する、請求項11又は12に記載のデバイス。
14. 前記第2のメッセージは、さらに、当該セキュリティ及びエッジ保護プロキシデバイスの識別子を搬送する、請求項13に記載のデバイス。
15. 前記少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行するための前記プログラミング命令を格納し、前記少なくとも1つのプロセッサは、
    前記安全性証明書を使用することによって前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記デバイス証明書の検証に成功しているときに、前記第2のセキュリティ及びエッジ保護プロキシデバイスに、検証成功メッセージを送信するように構成される、請求項11乃至14のうちのいずれか1項に記載のデバイス。
16. 前記少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行するための前記プログラミング命令を格納し、前記少なくとも1つのプロセッサは、
    前記第2のセキュリティ及びエッジ保護プロキシデバイスとの安全な通信のために使用されるセッション鍵を計算し、
    前記セッション鍵を使用することによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスへのセキュリティ接続を確立する、ように構成される、請求項11乃至15のうちのいずれか1項に記載のデバイス。
17. セキュリティサーバであって、
    少なくとも1つのプロセッサと、
    前記少なくとも1つのプロセッサに結合されて、前記少なくとも1つのプロセッサによって実行するためのプログラミング命令を格納する少なくとも1つのメモリとを含み、前記少なくとも1つのプロセッサは、
    第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を取得し、
    第1のセキュリティ及びエッジ保護プロキシデバイスに第1のメッセージを送信する、ように構成され、前記第1のメッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書を搬送するように構成され、
    前記少なくとも1つのプロセッサは、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスからの証明書要求メッセージを受信するようにさらに構成され、前記証明書要求メッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスの識別子を搬送する、
    サーバ。
18. 前記少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行するための前記プログラミング命令を格納し、前記少なくとも1つのプロセッサは、
    前記第2のセキュリティ及びエッジ保護プロキシデバイスからの第2のメッセージを受信するように構成され、前記第2のメッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書を搬送する、請求項17に記載のサーバ。
19. 前記第2のメッセージは、さらに、前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記識別子を搬送する、請求項18に記載のサーバ。
20. 安全な通信システムであって、
    コアネットワークネットワーク機能デバイスと第1のセキュリティ及びエッジ保護プロキシデバイスとを含み、前記コアネットワークネットワーク機能デバイスは、前記第1のセキュリティ及びエッジ保護プロキシデバイスにシグナリングメッセージを送信するように構成され、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスは、請求項1乃至6のうちのいずれか1項にしたがった方法を実行し、セキュリティ接続を介して、第2のセキュリティ及びエッジ保護プロキシデバイスに、受信したシグナリングメッセージを送信する、ように構成される、安全な通信システム。
21. 請求項7乃至9のうちのいずれか1項に記載の方法を実行するように構成されたセキュリティサーバをさらに含む、請求項20に記載のシステム。
22. 安全な通信方法であって、
    コアネットワークネットワーク機能デバイスによって、第1のセキュリティ及びエッジ保護プロキシデバイスにシグナリングメッセージを送信するステップと、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記シグナリングメッセージを受信するステップと、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、セキュリティサーバからの第1のメッセージを受信するステップであって、前記第1のメッセージは、第2のセキュリティ及びエッジ保護プロキシデバイスに対応する安全性証明書を搬送する、ステップと、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスからのデバイス証明書を受信するステップと、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記安全性証明書を使用することによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスの前記デバイス証明書に対して検証を実行するステップと、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記検証の成功の後に、前記第2のセキュリティ及びエッジ保護プロキシデバイスへのセキュリティ接続を確立するステップと、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスに前記シグナリングメッセージを送信するステップとを含み、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、セキュリティサーバからの第1のメッセージを受信するステップの前に、当該方法は、
    前記第1のセキュリティ及びエッジ保護プロキシデバイスによって、前記セキュリティサーバに証明書要求メッセージを送信するステップであって、前記証明書要求メッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスの識別子を搬送する、ステップをさらに含み、
    前記セキュリティサーバは、ドメインネームシステム(DNS)サーバであり、前記証明書要求メッセージは、DNSクエリ要求である、
    方法。
23. 前記セキュリティサーバによって、前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書を取得するステップと、
    前記セキュリティサーバによって、前記第1のセキュリティ及びエッジ保護プロキシデバイスに前記第1のメッセージを送信するステップであって、前記第1のメッセージは、前記第2のセキュリティ及びエッジ保護プロキシデバイスに対応する前記安全性証明書を搬送する、ステップと、をさらに含む、請求項22に記載の方法。

Images