JP7452600B2 - 通信端末装置及びその方法 - Google Patents

Description

本開示は、通信システムにおける装置及び方法に関する。

５Ｇモバイルネットワークでは、攻撃者がエアインターフェイス上の永続的なＩＤを盗聴することを防ぐ新しい保護メカニズムが導入されている。この機能を使用するモバイルデバイス（ＵＥとも呼ばれる）は、公開キーを使用して永続的なＩＤ（ＳＵＰＩとして知られている）を暗号化し、暗号化されたＩＤ（ＳＵＣＩとして知られている）をネットワークに送信する。モバイルネットワークは一般に相互接続されており、モバイルデバイスが、サブスクリプションが保持されていない第２のモバイルネットワークに接続することはよくあることである。このような場合、モバイルデバイスは、訪問したネットワーク、訪問したＰＬＭＮ、ＶＰＬＭＮをローミングしていると呼ばれる。したがって、ＳＵＣＩを復号化するために、ＳＵＣＩを、モバイルデバイスがサブスクリプションを保持するホームネットワーク、又はホームＰＬＭＮ、ＨＰＬＭＮに送信する必要がある。

暗号化されたＩＤを、正しいネットワーク、及び第２のネットワーク内の加入者データベース（ＵＤＭと呼ばれる）にルーティングできるようにするために、モバイルデバイスは、ＭＣＣ（mobile country code）、ＭＮＣ（mobile network code）、ルーティングＩＤ（ＲｏｕｔｉｎｇＩＤ）、及びホームネットワーク公開鍵識別子などのルーティングデータをＳＵＣＩに不可又は追加する。ＭＣＣ及びＭＮＣは、共に、ＳＵＣＩを受信した訪問ネットワークがＳＵＣＩをホームネットワークにルーティングすることを可能にし、ＲｏｕｔｉｎｇＩＤは、ホームネットワークにより、ホームネットワーク内のＵＤＭインスタンスを特定するために使用される。最後に、ホームネットワーク公開鍵識別子は、ＳＵＣＩの復号化に使用される対応する秘密鍵を検索するために使用される。最後のアクションは、通常、ＳＵＣＩの秘匿解除機能、又はＳＩＤＦによって実行される。

3GPP TR 21.905: "Vocabulary for 3GPP Specifications" V15.0.0 (2018-03) 3GPP TS 33.501: "Security architecture and procedures for 5G system"V15.2.0 (2018-09) S3-183074 - Reply LS on RoutingID S2-1810060, Update of Routing ID in the UE, 2018/10/15 S2-1811541, Update of Default Configured NSSAI and other UE parameters via Control Plane Solution from UDM to AMF with Direct NAS Transport to UE, 2018/10/15

ＭＮＣ／ＭＣＣ及びＲｏｕｔｉｎｇＩＤが正しくないと、ＳＵＣＩは、間違ったネットワーク、又はホームネットワーク内の間違ったエンティティにそれぞれルーティングされ、その後復号化されなくなる。ホームネットワーク公開鍵識別子にエラーがあると、ＳＩＤＦが対応する秘密キーを見つけられないか、或いは、間違ったキーを見つけるため、ＳＩＤＦがＳＵＣＩを復号できなくなる。同様に、ホームネットワーク公開鍵にエラーがあると、ＵＥは、ＳＵＰＩを暗号化するために誤った公開鍵を使用し、保護スキームにエラーがあると、ＵＥは、誤った保護スキームを使用する。どちらの場合も、受信ＳＩＤＦは、復号できない。

前の段落で説明したエラーケースは、ネットワークへのアクセスを取得するために必要なため、回復できない。これらのパラメータがない場合、又は破損したパラメータがある場合、ＳＵＣＩを正しいエンティティにルーティングできないか、復号化できないため、ネットワークへのアクセスができない。これらのパラメータの破壊を防止するために、これらのパラメータは、一般に、ＵＩＣＣ（Universal Integrated Circuit Card）又はｅＵＩＣＣ（Embedded UICC）と呼ばれるセキュアな読取り専用記憶装置に格納され、上述のエラーを防止することができる。

しかしながら、近年、３ＧＰＰ ＳＡ２ワーキンググループは、サブスクリプションデータがあるＵＤＭインスタンスから別のＵＤＭインスタンスに移行される場合（非特許文献４及び非特許文献５を参照）、ＲｏｕｔｉｎｇＩＤを更新する必要があると考えた。この新たに導入されたニーズは、ＲｏｕｔｉｎｇＩＤが読み取り／書き込みメモリに格納される必要があり、そのため攻撃者による攻撃に対して脆弱になることを意味する。さらに、将来的には、ホームネットワーク公開鍵、ホームネットワーク公開鍵識別子、保護スキーム、及びＵＳＩＭ（universal subscriber identity module）に格納される他のアタッチクリティカルデータを更新する必要が生じる可能性がある。これらパラメータは、ネットワークにアタッチするために重要であるため、堅牢なセキュリティメカニズムを導入する必要がある。

本開示は、上記課題に鑑み、様々な課題の少なくとも１つを解決する解決策を提供することを目的とする。

第１の態様において、本開示は、装置を提供する。装置は、１つ以上の命令を格納するメモリと、前記１つ以上の命令を実行することで、ネットワーク通信に対応する更新情報を外部機器から受信し、前記更新情報に基づいてＳＵＣＩ（Subscription Concealed Identifier）を取得し、前記ＳＵＣＩを前記外部装置に送信するように構成されるプロセッサとを含む。

第２の態様において、本開示は、装置を提供する。装置は、１つ以上の命令を格納するメモリと、前記１つ以上の命令を実行することで、ネットワーク通信に対応する更新情報を外部機器に送信し、前記更新情報に基づいて取得されるＳＵＣＩ（Subscription Concealed Identifier）を前記外部装置から受信し、前記受信したＳＵＣＩに基づいてＳＵＰＩ（Subscription Permanent Identifier）を取得し、前記ＳＵＰＩが前記更新情報に対応しているかを検証するように構成されるプロセッサとを含む。

第３の態様において、本開示は、方法を提供する。方法は、外部機器から、ネットワーク通信に対応する更新情報を受信し、前記更新情報に基づいてＳＵＣＩ（Subscription Concealed Identifier）を取得し、前記ＳＵＣＩを前記外部装置に送信することを含む。

第４の態様において、本開示は、方法を提供する。方法は、ネットワーク通信に対応する更新情報を外部機器に送信し、前記更新情報に基づいて取得されるＳＵＣＩ（Subscription Concealed Identifier）を前記外部装置から受信し、前記受信したＳＵＣＩに基づいてＳＵＰＩ（Subscription Permanent Identifier）を取得し、前記ＳＵＰＩが前記更新情報に対応しているかを検証することを含む。

図１は、本開示の第１実施形態に従ってパラメータが更新された後に、パラメータの正確性を確認するための方法を示すシーケンス図である。 図２Ａは、ＳＵＣＩが確認される第１のシナリオを示すシーケンス図である。 図２Ｂは、ＳＵＣＩが確認される第２のシナリオを示すシーケンス図である。 図２Ｃは、ＳＵＣＩが確認される第３のシナリオを示すシーケンス図である。 図３に障害発生時の対処方法を示すシーケンス図を示す。 図４は、別の障害処理を示すシーケンス図である。 図５は、他の障害の対処方法を示すシーケンス図である。 図６は、新しいアタッチを用いる回復手順を示すシーケンス図である。 図７は、本開示の第２実施形態に従ってパラメータが更新された後にパラメータの正当性を確認する方法を示すシーケンス図である。 図８は、パラメータの正当性を確認する方法の一部を示すシーケンス図である。 図９は、ＵＳＩＭの内容の一例を示す図である。 図１０は、本開示の第３実施形態に従ってパラメータが更新された後に、パラメータの正確性を確認するための方法を示すシーケンス図である。 図１１は、パラメータの優先度を変更するための手順を示すシーケンス図である。 図１２は、優先度変更後のＵＳＩＭのテーブルを示す。 図１３は、ＵＥの主要な構成要素を示すブロック図である。 図１４は、例示的な（Ｒ）ＡＮノードの主要な構成要素を示すブロック図である。 図１５は、例示的なコアネットワークノードの主要な構成要素を示すブロック図である。 図１６Ａは、第１の更新シナリオを示すシーケンス図である。 図１６Ｂは、第２の更新シナリオを示すシーケンス図である。 図１６Ｃは、第３の更新シナリオを示すシーケンス図である。 図１７は、パラメータを更新するためのメカニズムを示すシーケンス図である。 図１８は、本開示の第２実施形態によるパラメータの正確性を確認するための別の方法を示すフローチャートである。

本文書の目的のために、非特許文献１及び以下に示す略語を適用する。この文書で定義された省略形は、もしあれば、非特許文献１の同じ省略形の定義より優先される。
5GC 5G Core Network
5GS 5G System
5G-AN 5G Access Network
5G-GUTI 5G Globally Unique Temporary Identifier
5G S-TMSI 5G S-Temporary Mobile Subscription Identifier
5G (Home)BSF 5G (Home) Boot Strapping Function
AMF Access and Mobility Management Function
AN Access Node
AKMA Authentication and Key Management for Applications
AS Access Stratum
AUSF Authentication Server Function
CP Control Plane
CM Connection Management
DL Downlink
DN Data Network
DNAI DN Access Identifier
DNN Data Network Name
EPS Evolved Packet System
EPC Evolved Packet Core
FQDN Fully Qualified Domain Name
GPSI Generic Public Subscription Identifier
GUAMI Globally Unique AMF Identifier
HR Home Routed (roaming)
I-RNTI I-Radio Network Temporary Identifier
KDF Key Derivation Function
LADN Local Area Data Network
LBO Local Break Out (roaming)
LMF Location Management Function
LRF Location Retrieval Function
MAC Medium Access Control
ME Mobile Equipment
MFBR Maximum Flow Bit Rate
MICO Mobile Initiated Connection Only
MME Mobility Management Entity
N3IWF Non-3GPP Inter Working Function
NAI Network Access Identifier
NAS Non-Access Stratum
NEF Network Exposure Function
NF Network Function
NG-RAN Next Generation Radio Access Network
NR New Radio
NRF Network Repository Function
NSI ID Network Slice Instance Identifier
NSSAI Network Slice Selection Assistance Information
NSSF Network Slice Selection Function
NSSP Network Slice Selection Policy
PCF Policy Control Function
PEI Permanent Equipment Identifier
PER Packet Error Rate
PFD Packet Flow Description
PLMN Public land mobile network
PPD Paging Policy Differentiation
PPI Paging Policy Indicator
PSA PDU Session Anchor
QFI QoS Flow Identifier
QoE Quality of Experience
(R)AN (Radio) Access Network
RLC Radio Link Control
RM Registration Management
RQA Reflective QoS Attribute
RQI Reflective QoS Indication
RRC Radio Resource Control
SA NR Standalone New Radio
SBA Service Based Architecture
SBI Service Based Interface
SD Slice Differentiator
SDAP Service Data Adaptation Protocol
SEAF Security Anchor Functionality
SEPP Security Edge Protection Proxy
SMF Session Management Function
S-NSSAI Single Network Slice Selection Assistance Information
SSC Session and Service Continuity
SST Slice/Service Type
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
UDSF Unstructured Data Storage Function
UL Uplink
UL CL Uplink Classifier
UPF User Plane Function
UDR Unified Data Repository
URSP UE Route Selection Policy
USIM Universal Subscriber Identity Module
SMS Short Message Service
SMSF SMS Function
SQN Sequence number
MT Mobile Terminated

本開示の目的のために、非特許文献１及び以下に示す用語及び定義が適用される。本開示で定義されている用語は、もしあれば、非特許文献１の同じ用語の定義よりも優先される。

上述のように、３ＧＰＰ ＳＡ２は、移動通信事業者があるＵＤＭから別のＵＤＭにサブスクリプションを移動させることができるようにするために、ＵＳＩＭ内のＲｏｕｔｉｎｇＩＤを更新する必要性を議論した。本開示は、加えて、ホームネットワーク公開鍵などの他のパラメータの更新も考える。メカニズムは似ているように見えるかもしれないが、わずかな違いがある。

図１６Ａ～１６Ｃは、３つの更新シナリオを示す。図１６Ａに示すように、第１の更新シナリオは、サブスクリプションを移動するターゲットＵＤＭ（ＵＤＭ２）が、新たなサブスクリプション情報を受信した後、ＵＥにＲｏｕｔｉｎｇＩＤを更新する指令を送信することにより、ＵＥと更新手順を開始するシナリオである。図１６Ｂに示すように、第２の更新シナリオは、サブスクリプションデータが削除されるソースＵＤＭ（ＵＤＭ１）が、更新手順を開始するシナリオである。観察されたように、サブスクリプション情報を２つのＵＤＭ間で移動することは、ＲｏｕｔｉｎｇＩＤを更新する理由であり、したがって、更新手順を実行しなければならない。

図１６Ｃに示すように、最後のシナリオは、サブスクリプション情報が１つのＵＤＭから別のＵＤＭに移動されないという点でわずかに異なる。このようなシナリオは、ホームネットワーク公開鍵と、ホームネットワーク公開鍵識別子及び保護スキームのような他のパラメータを更新するために使用することができる。このような手順が実行される他のシナリオは、例えば、ローミングのステアリングが使用される場合である。ローミングのステアリングは、ＵＥをある訪問ネットワークから別の訪問ネットワークに移動させるために、ホームオペレータによって適用される。このような場合、ＵＤＭは、ＵＥを所望のネットワークに誘導する目的で、ローミングパートナーのリストを送信する。

ローミングのステアリングのために、非特許文献２に記述されているようなセキュリティソリューションがある。このソリューションは、非特許文献３に記述され、図１７に示されるように、ＲｏｕｔｉｎｇＩＤの更新、又はキー更新に適合され得る。このソリューションは、ＡＵＳＦ、ホームネットワーク内のエンティティ、及びモバイル機器（ＭＥ：mobile equipment）の間で、ＡＵＳＦ及びＭＥに格納されている秘密鍵に基づいて、データを安全に送信するメカニズムを提供する。ＫＡＵＳＦに格納されている秘密鍵は、モバイルデバイスがネットワークへのアクセスを要求した後に、モバイルデバイスとホームネットワークとによって正常に実行される認証と鍵合意の成功の結果である。したがって、このキーは、ＵＥが認証に成功した場合にのみ使用でき、ＵＥがサービスネットワークから切断された後は使用できない。

より詳細には、このようなソリューションは次のように機能する。ＵＤＭは、アタッチ関連パラメータ更新（図１７では、キー更新が例として示されている）のメッセージを準備し、ＡＵＳＦに送信する。ＡＵＳＦは、キー導出関数（ＫＤＦ：key derivation function）を使用してＭＡＣを作成し、ＭＡＣを次のように計算する。ＭＡＣ＝ＫＤＦ（Ｋ_ＡＵＳＦ，「Attach Parameter Update」、カウンタ、メッセージ）ＫＡＵＳＦは、キー導出関数への入力キーであり、「Attach Parameter Update」は、このＭＡＣがアタッチパラメータ更新手順に対して計算されることを示すテキストフィールドである。テキストフィールドには異なる値を指定できるが、後続の手順に対しては常に固定される。テキストフィールドは、メソッドの固定値である。カウンタは、キーの繰り返しを避けるために使用され、全てのアタッチ関連パラメータ更新メッセージで拡張される。メッセージは、ＵＤＭからのプレーンテキストメッセージである。追加的に、他の値もＫＤＦに追加できる。

次のステップで、ＡＵＳＦは、ＭＡＣとカウンタを返す。ＵＤＭは、ＭＡＣ、カウンタ、及びメッセージをＡＭＦに送信し、ＡＭＦは、ＮＡＳ ＤＬ転送メッセージを使用してメッセージをＵＥに転送する。ＵＥがメッセージを受信すると、ＵＥは、プレーンテキストメッセージ、カウンタ、テキストフィールド、及びＫ_ＡＵＳＦ（ＸＭＡＣ＝ＫＤＦ（Ｋ_ＡＵＳＦ，「Attach Parameter Update」、カウンタ、メッセージ））からＭＡＣを計算し、ＸＭＡＣがＭＡＣと一致する場合、キーを保存する。

次に、ネットワークが確認を要求した場合、ＵＥは、ＵＥがキーを受信したことを示す確認メッセージを送信する。保護するために、ＵＥは同様の計算、すなわちＭＡＣ＝ＫＤＦ（Ｋ_ＡＵＳＦ，「Attach Parameter Update」、カウンタ、メッセージ）を使用する。カウンタは、ＵＥが受信したカウンタと比較して１つ増加し、メッセージは、ＵＥがネットワークに送信するプレーンテキストメッセージである。ＵＥは、確認、ＭＡＣ、及びカウンタをＡＭＦに送信し、ＡＭＦは、これをＵＤＭに転送する。受信すると、ＵＤＭはメッセージ、ＭＡＣ、及びカウンタをＡＵＳＦに転送し、ＡＵＳＦがＭＡＣを確認できるようにする。

上記の変更が可能である。例えば、この方法のためにＫ_ＡＵＳＦから特定の鍵を導出し、異なる完全性保護メカニズムを使用することができる。しかしながら、このようなＫ_ＡＵＳＦベースのソリューションは、ＭＥとＡＵＳＦと間のメッセージ交換を保護するだけであることに注意されたい。非特許文献３においてコメントされているように、このような、ＭＥがファイルの更新を許可されるメカニズムを使用すると、ファイルは攻撃に対して脆弱になる。したがって、秘密鍵を使用してＵＤＭとＭＥとの間を保護することに基づくメカニズムは、通信を保護するだけであり、正しいデータが安全な記憶装置に書き込まれ、正しいデータを取り出すことができるという確実性を提供しないため、この問題に対処するには不十分である。

非特許文献３では、さらに２つのソリューションが記述されている。特に、ＵＳＩＭが、ＵＳＩＭ内にあらかじめ記憶される複数の値の間で切り替えることができる解決策が記述される。このメカニズムは、次のアタッチのためにＵＳＩＭによって使用されるデータセットを切り替えるＡＵＴＨＥＮＴＩＣＡＴＥコマンドに依存する。その代わり、ＵＳＩＭは、ＵＤＭがメッセージがＵＳＩＭによって受信されたことを知ることができるように、ＳＵＣＩに暗号化された部分を追加することができる。しかしながら、このソリューションは、ＵＳＩＭからＵＤＭへの確認が欠けているため、ＵＳＩＭに切り替えコマンドを発行する前に、ＵＤＭがアタッチクリティカルパラメータが正しく格納されているかどうかを知る方法がない。このように、ＵＥは、アタッチクリティカルパラメータセットを切り替えた後でも、サービスなしのままでいることができた。

以上を考慮すると、本発明者らは、パラメータを更新した後、セキュアストレージに正しいパラメータが格納されていること、及び、モバイルデバイスがネットワークから切り離された後、ネットワークにアタッチできることを確認する必要性を認識した。

（第１実施形態）
図１は、本開示の第１実施形態に従ってＲｏｕｔｉｎｇＩＤなどのアタッチ関連パラメータが更新された後、それらパラメータの正確性を確認するための方法を示す。図１は、例としてＲｏｕｔｉｎｇＩＤを使用しているが、これらの方法は、ホームネットワーク公開鍵、ホームネットワーク公開鍵識別子、保護スキームなどの更新後に同様に適用することができる。以下の説明において、ＲｏｕｔｉｎｇＩＤは、それらパラメータの一例としてのみ理解される。

図１に示すように、ステップ１において、ＵＤＭは、ＭＥとＵＳＩＭを含むＵＥの新しいＲｏｕｔｉｎｇＩＤをサービングネットワークのＡＭＦに送信する。ＵＤＭが登録中にこの情報を送信する場合、ＵＤＭは、ＡＭＦのＮｕｄｍ＿ＳＤＭ＿Ｇｅｔ要求に応答してＳＤＭ＿Ｇｅｔ＿ＲｅｓｐｏｎｓｅメッセージでＲｏｕｔｉｎｇＩＤを送信できる。ＵＤＭがＵＥが接続されている間にこの情報を送信したい場合、ＵＤＭは、ＳＤＭ＿ＵｐｄａｔｅＮｏｔｉｆｉｃａｔｉｏｎを用いて、ＵＥにデータを転送する必要があることをＡＭＦに通知することができる。また、ローミングのステアリングのために、非特許文献２に記述されている方法、又は図１７に説明されている方法に従って、このメッセージを完全に保護することも可能である。その方法が使われる場合、ＲｏｕｔｉｎｇＩＤは、関連したセキュリティパラメータ、とりわけＭＥがＲｏｕｔｉｎｇＩＤの完全性を検証するために使うことができるＭＡＣ－Ｉを持つことができる。

ステップ２で、ＡＭＦは、ＤＬ ＮＡＳトランスポートメッセージを使用してＵＥに新しいＲｏｕｔｉｎｇＩＤ（及び、ＲｏｕｔｉｎｇＩＤが完全性保護されている場合はＭＡＣ－Ｉのような他の関連パラメータ）を転送する。ＵＥは、ＤＬ ＮＡＳ転送メッセージを受信した後、ＭＡＣ－Ｉが正しいかどうかを確認する（存在する場合）。その場合、ＵＥは、ステップ４において、ＵＳＩＭに新しいＲｏｕｔｉｎｇＩＤを格納する。

ステップ５において、ＵＳＩＭは、ホームネットワーク公開キー、ＭＣＣ／ＭＮＣ、及び新たに格納されたＲｏｕｔｉｎｇＩＤを使用して、新しいＳＵＣＩを作成する。ステップ６において、ＵＳＩＭは、ＭＥに新しいＳＵＣＩを送信し、ステップ７において、ＭＥは、ＵＬ ＮＡＳトランスポートメッセージで新しいＳＵＣＩをＡＭＦに送信する。ＭＥは、ＭＥとＡＵＳＦとの間のこのメッセージを、図１７に記載される方法を使用して、完全性保護することができる。その場合、ＵＬ ＮＡＳトランスポートメッセージは、メッセージが変更されずにＡＵＳＦに到着したことをＡＵＳＦが確認することを可能にするセキュリティ関連パラメータも含む。

ＵＬ ＮＡＳトランスポートメッセージを受信した後、ＡＭＦは、ステップ８において、Ｎｕｄｍ＿ＳＤＭ＿Ｉｎｆｏメッセージを使用して、ＳＵＣＩ、及び関連するセキュリティ・パラメータ（含まれる場合）をＵＤＭに転送する。セキュリティパラメータが含まれている場合、ＵＤＭは、非特許文献１に従った検証のためにメッセージをＡＵＳＦに送信する。メッセージが正しく検証されると、ＵＤＭは、ＲｏｕｔｉｎｇＩＤの値が正しいか否かをチェックする。

ＵＤＭが上記のチェックを実行する方法は、ＲｏｕｔｉｎｇＩＤの受信方法に依存して異なる。図２Ａ～２Ｃは、ＳＵＣＩが確認されるシナリオを示している。図２Ａは、第１のシナリオを示す。最初のシナリオでは、ＲｏｕｔｉｎｇＩＤの更新手順はサブスクリプションの移動先であるＵＤＭ２によって実行され、そのため、ＵＤＭ２は、ＲｏｕｔｉｎｇＩＤをローカルにチェックすることができる。図２Ａに示すように、ＵＤＭ２はＳＵＣＩ（一例として、ＵＤＭ２はＲｏｕｔｉｎｇＩＤを受信することもできる）を受信し、ＳＵＣＩはＳＩＤＦ２に転送され、ＳＵＰＩはＵＤＭ２に戻される。ＵＤＭ２は、ＳＵＰＩがＳＵＣＩを含む更新確認メッセージを受信したばかりのＳＵＰＩに対応していることを確認できるようになった。

図２Ｂは、第２のシナリオを示す。第２のシナリオの場合、アタッチアップデートパラメータ確認メッセージを受信するＵＤＭは、新しいサブスクリプションの移動先のＵＤＭと同じではない。このような場合、ＵＤＭ１は、アタッチアップデートパラメータ確認メッセージでＳＵＣＩを受信した後、ＳＵＣＩをＵＤＭ２に転送する。次いで、ＵＤＭ２は、ＵＤＭ２に属するＳＩＤＦ２にＳＵＣＩを転送する。図２Ｂに示すように、ＳＩＤＦ２は、ＳＵＰＩをＵＤＭ２に返す。ＵＤＭ２は、ＳＵＰＩを、ＵＤＭ１に転送し、第１のシナリオと同様の比較が実行される。

図２Ｃは、第３のシナリオを示す。第３のシナリオでは、サブスクリプションが格納される場所に変更はなく、図２Ｃから分かるように、第３のシナリオは第１のシナリオに似ている。ＵＤＭ１は、ＵＥからアタッチ更新パラメータ確認メッセージを受信し、ＳＵＣＩを抽出し、ＳＵＣＩをＳＩＤＦ１に転送する。ＳＩＤＦ１は、ＳＵＣＩの秘匿を解除し、比較のためにＳＵＰＩをＵＤＭ１に返す。

何れの場合も、アタッチパラメータ更新確認メッセージを受信したＵＤＭでの比較結果が成功すると、ＵＤＭは、ＲｏｕｔｉｎｇＩＤがＵＳＩＭに正しく格納されていることを確認する。ＳＩＤＦがＳＵＣＩを秘匿解除できない、ＲｏｕｔｉｎｇＩＤが誤ったＵＤＭ又は存在しないＵＤＭを指しているなどの理由でエラーが発生し、アタッチパラメータ更新確認メッセージを受信したＵＤＭは、更新が失敗したと判断できる。このような場合には、障害が発生したことがＵＥに報告され、及び／又は、復旧手順が開始される必要がある。失敗した場合の対処については後述する。

前述の例では、ＳＵＣＩは、ＳＩＤＦを使用して秘匿解除される。これは、ＲｏｕｔｉｎｇＩＤに代えてホームネットワークの公開鍵が更新される場合に特に有効である。ホームネットワーク公開鍵が更新され、ＳＩＤＦが新しいホームネットワークの公開鍵で暗号化されたＳＵＣＩからＳＵＰＩを秘匿解除できる場合、ＵＤＭは、新しくプロビジョニングされたホームネットワークの公開鍵がＵＳＩＭに正しく格納されていることを確認する。

ステップ５において、ＵＥは、ホームネットワーク公開鍵でＳＵＰＩを暗号化することにより非対称暗号化を実行する。ＳＵＰＩに代わり、ＵＥは、更新されたパラメータ（この場合はＲｏｕｔｉｎｇＩＤ）のみを暗号化し、或いは、同じメッセージ内でＲｏｕｔｉｎｇＩＤとＳＵＰＩとを連結することもできる。これは、特にＳＵＣＩがＭＥではなくＵＳＩＭで計算される場合に、ＲｏｕｔｉｎｇＩＤの正確性に対する追加の保証を提供する。そのような場合において、図２Ａから２Ｃの場合、ＳＵＰＩの全てのインスタンスはＲｏｕｔｉｎｇＩＤに置き換えられ、ＳＵＣＩの全てのインスタンスは「暗号化されたＲｏｕｔｉｎｇＩＤ」に置き換えられる。

図１のステップ１１～１３のメッセージは、ＵＤＭが正しい情報を受信したことを確認するための、ＵＤＭからＵＥへの確認メッセージのセットである。これらメッセージは、ステップ１～３のメッセージと同じ経路をたどる。ＵＤＭは、ＳＤＭ＿ＵｐｄａｔｅＮｏｔｉｆｉｃａｔｉｏｎを使用して確認メッセージをＡＭＦに送信し、ステップ１１においてデータをＵＥに転送する必要があることをＡＭＦに通知する。ステップ１のメッセージと同様に、ローミングのステアリングのために、非特許文献２に記述された方法に従って、確認メッセージを完全性保護することも可能である。その方法が使用される場合、追加のセキュリティパラメータが含まれる必要がある。ＡＭＦは、ステップ１２において、ＤＬ ＮＡＳトランスポートメッセージを使用してＵＥに確認メッセージを転送する。ＭＥは、ＤＬ ＮＡＳ転送メッセージを受信した後、ＭＡＣ－Ｉが正しいかどうかを確認する（存在する場合）。そうであれば、ＭＥは、ステップ１３においてＵＳＩＭに確認メッセージを転送する。

確認自体には、状況が正しいことを示す、単純なバイナリ値「正しい」又は「１」を含めることができる。加えて、ホームネットワークは、ＵＳＩＭに格納されているホームネットワーク公開鍵に対応するホームネットワーク秘密鍵を使用してメッセージを完全性保護できる。このように、ＵＳＩＭは、ネットワークが確認を送信したことを検証できる。

しかしながら、前段落で説明した確認メッセージは、他のＵＳＩＭに再生することができる。それを防止する場合、確認メッセージは、ＵＤＭによって受信されたＳＵＣＩをさらに含み、ＵＳＩＭによって作成されたＳＵＣＩとＵＤＭによって返された確認とが結合される。ただし、ステップ５において、ＵＳＩＭは、ＵＳＩＭが確認メッセージを受信するまで、ＵＳＩＭが構築したＳＵＣＩを格納する必要がある。ＵＳＩＭが確認メッセージを受信した場合、ＵＳＩＭは、メッセージの完全性が保護されているか否かを確認し、また、確認メッセージに含まれるＳＵＣＩがＵＳＩＭが格納したものと同一であることを確認する。

このような確認メッセージの利点は、ＵＳＩＭとＵＤＭの双方が、双方が保存したアタッチクリティカルパラメータが正しく、かつ検証済みであることを確認することである。ＵＳＩＭがメッセージを確認した後、ＵＳＩＭは、新しいアタッチパラメータを恒久的に格納し、これらのパラメータを後続のアタッチに使用することができる。

図２Ａ～２Ｃにおい説明されるように、障害が発生する可能性がある。例えば、ＵＥが正しいホームネットワークキーを格納していない、或いは誤ったＲｏｕｔｉｎｇＩＤを格納することがある。そのような場合、図２Ａから２Ｃに記載されるＵＤＭによる検証は、エラーを示す。ＵＤＭからＵＥへの確認メッセージ（図１のステップ１１～１３）が失われると、別の障害が発生する可能性がある。このような場合、ＵＥは、新しいアタッチクリティカルパラメータが正しいかどうかを見つけるために、回復手順を実行する必要がある。

図３に障害発生ケースの対処方法を示す。図３のステップ１及び２は、図１のステップ６～８に対応する。違いは、ＵＳＩＭとＭＥとを図３では１つのものとみなし、組み合わせに「ＵＥ」という用語を使用している点である。ステップ３において、図１の説明文に示すように、ＵＤＭにてアタッチパラメータ更新確認メッセージを処理し、その際にエラーとなる。例えば、ＲｏｕｔｉｎｇＩＤが正しくない場合、ＳＵＣＩを秘匿解除できないか、或いはＳＵＣＩの秘匿解除から誤った値が生じる。ステップ３の後、ＵＤＭは更新が失敗したことを認識し、正しい値を提供し、障害が発生したことを通知するために、ステップ４及び５において、メッセージを、ＡＭＦを介してＵＥに送信する。ステップ４及び５のメッセージは、図１のステップ１～３のメッセージに類似している。受信後、ＵＥは、再びメッセージを検証し、ステップ６で新しい値を格納する。図３のステップ６は、図１のステップ４及び５に対応する。ＵＥは、ステップ７及び８の検証のために、再び「アタッチパラメータ更新確認」メッセージを、ＡＭＦを介してＵＤＭに送信することができる。ＵＤＭは、全てが正しいかどうかを再度検証する。検証に失敗した場合は、ステップ４から処理を繰り返す。

図４に別の障害処理を示す。図４のステップ１～３は、図３のステップ１～３と同じである。ただし、ステップ４及び５において、ＵＤＭは、ＵＥに障害を示し、ＡＭＦを介してＵＥにこの障害を送信する。ＵＥは、受信すると、ステップ６において、新しいキーを削除して元の値に戻す。また、ＵＤＭは、ステップ６で古い値を復元する。ＵＤＭは、ＵＤＭとＵＤＭ２との間でサブスクリプションが転送される場合、ステップ７においてＵＥ側の更新が失敗し、サブスクリプションが転送できないことを、第２のＵＤＭ（ＵＤＭ２）に通知してもよい。この手順の結果、ＵＥ及びＵＤＭは共に元の状態に戻り、ＵＥは、次回、古い値を使用してアクセスできるようになる。

図５に別の故障事例を示す。別の障害ケースは、ＵＤＭからＵＥへの確認メッセージ又は障害メッセージが転送中に失われるケースである。図５のステップ１～３は、図３のステップ１～３とほぼ同じである。相違点は、ステップ１ａにおいて、ＵＥは、「アタッチパラメータ更新確認メッセージ」を送信した後、ＵＤＭの確認メッセージ又は失敗メッセージをどれだけ待機するかを示す待機タイマを設定することである。ステップ４において、ＵＤＭはＵＥに障害又は確認を通知し、ＵＥにこのメッセージを送信しようとし得る。ＵＤＭからＵＥへの途中に、エアインターフェイスなどでメッセージが消失することがある。ステップ５では、ＵＥ側のタイマが期限切れになり、そのため、ＵＥは、ステップ６及び７で、新しい「アタッチパラメータ更新確認」メッセージをＡＭＦを介してＵＤＭに送信する。この場合も、ＵＤＭは前述のように処理し、確認メッセージ又は失敗メッセージを送り返す。メッセージがＵＥによって正しく受信された場合、ＵＥは、新しいアタッチパラメータを永続的に保存し、ステップ１１で手順が完了したと考える。

図６は、新たなアタッチを用いた回復手順を示す。図６のステップ１－３は、図５のステップ１－３に対応する。ステップ４において、確認メッセージ又は失敗メッセージは失われ、ＵＥタイマはステップ５において期限切れになる。図６の場合、ＵＥは、アタッチ手順を用いて新たなＳＵＣＩを確認する。これを行うために、ＵＥは、ステップ６で新しいアタッチ手順を開始する。例えば、ＵＥは、同じネットワークに再びアタッチし、或いは別のネットワークにアタッチできる（ＵＥがローミング中の場合）。ステップ７において、通常のアタッチ手順が実行され、このアタッチ手順の一部として、ＵＥは、ＵＤＭにＳＵＣＩを送信する。成功すると、ステップ８において、アタッチは、ＡＭＦ２からＵＥに返される「アタッチ完了」メッセージをという結果になる。ＵＥがこのアタッチ完了を受信しない場合、又はエラーメッセージを受信する場合、ＵＥは、新しいアタッチ関連パラメータが不完全であると仮定し、元のパラメータに戻る。

ホームネットワーク側では、ＵＤＭ２は、ＳＵＣＩの秘匿を解除した後、ステップ９において、特定の加入者（ＳＵＰＩによって示される）に対して正しいＳＵＣＩを受信したことをＵＤＭ１に通知できる。これは、サブスクリプションの転送が成功したことをＵＤＭ１に示し、ＵＤＭ１は、ステップ１１において、対応するサブスクリプションをメモリから削除することができる。

ステップ１０において、ＵＥは、アタッチされていたネットワークからデタッチする。ステップ１０は、ネットワークへの二重登録を回避するために、ステップ６の前に実行することもできる。ステップ１０を先に行うことの欠点は、ＵＥがユーザエクスペリエンスを妨げるダウンタイムを経験する可能性があることである。ステップ１２において、ＵＥは、新しいマテリアルを使用に移し、それを永久的に保存する。ＵＥは、古いアタッチクリティカルパラメータを削除することもできる。

（第２実施形態）
図７は、本開示の第２実施形態に従って、ホームネットワーク公開鍵などのアタッチ関連パラメータが更新された後に、これらのパラメータの正当性を確認するための方法を示す。図７は、一例としてホームネットワーク公開鍵を用いているが、方法は、ＲｏｕｔｉｎｇＩＤ、保護スキームなどの更新後に同様に適用することができる。以下の説明において、ホームネットワーク公開鍵は、それらパラメータの一例としてのみ理解される。他のパラメータとの違いが発生する場合、違いは本文に示される。

図７に示す方法では、ＵＤＭは、ネットワーク内の鍵サーバ（ＫＳ）から新しいホームネットワーク公開鍵を取得する。ステップ１において、ＵＤＭは、ＫＳに新しい鍵マテリアルを要求する。ステップ２において、ＫＳは、ＵＤＭに新しい鍵マテリアルを提供する。オプションとして、ステップ１をスキップすることができ、ＵＤＭは、ＫＳから新しい鍵マテリアルのメッセージを受信することによってトリガされ、ＵＥに新しい鍵マテリアルを送信できる。あるいは、新しい鍵マテリアルはＵＤＭに直接提供されず、ＵＤＭに、新しい鍵マテリアルをダウンロードするためのＵＲＬ（Uniform Resource Locator）のみがＫＳにより提供される。説明の残りの部分では、ＫＳがＵＥに新しい鍵マテリアルをダウンロードするためのＵＲＬを提供したと仮定する。

ＫＳから新しい鍵マテリアル又は新しい鍵マテリアルのＵＲＬを受信した後、ＵＤＭは、サービングネットワーク内のＡＭＦを介して、ＭＥ及びＵＳＩＭを含むメッセージをＵＥに送信する。ＵＤＭがＵＥの登録中にこのメッセージを送信する場合、ＵＤＭは、ステップ３において、ＡＭＦのＮｕｄｍ＿ＳＤＭ＿Ｇｅｔ要求に応答して、ＳＤＭ＿Ｇｅｔ＿Ｒｅｓｐｏｎｓｅメッセージを使用してこのメッセージをＡＭＦに送信できる。ステップ３において、ＵＤＭがＵＥの手順の登録が完了した後にこのメッセージを送信する必要がある場合、ＵＤＭは、ＳＤＭ＿ＵｐｄａｔｅＮｏｔｉｆｉｃａｔｉｏｎを使用してこのメッセージをＡＭＦに送信できる。ＵＤＭが送信するメッセージは、鍵マテリアルを直接含んでいてもよいし、ダウンロード用のＵＲＬを含む、鍵マテリアルのダウンロードをＵＥに開始させる指示が含まれていてもよい。非特許文献２及び図１７に記述された方法を使用して、このメッセージは、ＡＵＳＦとＭＥの間で保護することができ、それによってＭＥはメッセージが正当な発信元（図示されない）から来たことを検証することができる。

ＡＭＦがメッセージを受信すると、ＡＭＦは、ステップ４でＵＥにメッセージを配信するために、ＤＬ ＮＡＳトランスポートメッセージを使用して、受信したメッセージをＵＥに転送する。このメッセージを受信すると、ＭＥは、非特許文献２または図１７の説明に従って、メッセージの完全性を検証する。完全性が正しい場合、ＵＥは、ステップ５において、示されたＵＲＬから新しい鍵マテリアルのダウンロードを続行する。当業者が知るように、ＵＲＬは、非セキュアなプロトコルとして、ＨＴＴＰ（hypertext transfer protocol）、又はＦＴＰ（file transfer protocol）など、セキュアなプロトコルとしてＨＴＴＰＳ（hypertext transfer protocol secure）又はＳＦＴＰ（SSH (secure shell) file transfer protocol）などの使用されるプロトコルを含み得る。非セキュアなＷｅｂアドレスの例は、http://key-server.operator.3gpp/key_download/new_keyである。セキュアなＷｅｂアドレスの例は、https://key-server.operator.3gpp.org/key_download/new_keyである。

鍵マテリアルのダウンロードは、ＭＥ又はＵＳＩＭのいずれかによって実行できる。ＭＥがステップ５でダウンロードを実行すると、ＭＥはサーバに接続して新しい鍵をダウンロードし、メモリに一時的に保存する。以降、ステップ６において、ＭＥは、新しい鍵をＵＳＩＭに送信し、保管する。

図８は、アタッチ関連パラメータの正当性確認方法の一部を示す。図８のステップ１～４は、図７のステップ１～４と同じでよい。ＵＳＩＭがダウンロードを実行する場合、ＭＥは、ＵＳＩＭに、ステップ５においてＡＭＦから受信したメッセージに含まれるＵＲＬを送信する。ＵＳＩＭは、ＭＥからダウンロードトリガーを受信し、ステップ６においてダウンロードを開始する。図７と図８の違いは、ステップ５および６のみであり、したがって、図８のさらなる説明は省略される。ダウンロード後、ＵＳＩＭは、ステップ７において、例えば、新しい鍵ファイルに、又はキーを含むテーブルの新しいエントリとして、キーを直接格納する。

図９は、ＵＳＩＭの内容の一例を示す。ＵＳＩＭは、複数の鍵を、テーブルとして表される登録に格納する。ＵＳＩＭは、ホームネットワーク公開鍵（ＨＮキー）、ＨＮ公開キーＩＤ（ＨＮ ＫＩＤ）、ＲｏｕｔｉｎｇＩＤ、保護スキーム、及び優先度又は優先順位フィールドを格納する。これは、ＭＥがＳＵＣＩを計算する場合に有利である。なぜならば、ＭＥはＵＳＩＭ内で見つけた鍵マテリアルに基づいてＳＵＣＩを計算するからである。そのためには、ＭＥは、図８に示す登録を、優先度フィールドなしで取得するし、ＭＥがサポートする保護スキームを見つけるまで、それらが格納されているリストを順番に調べる。ＭＥが保護スキーム２をサポートし、リストが保護スキーム１、３、２、４、１、２のキーを（その順に）含む場合、ＭＥは、常にテーブルの３番目のエントリを選択し、テーブルの６番目のエントリに到達することはない。６番目のエントリに更新されたキーが含まれている場合、ＭＥは、そのキーを選択しない。同様に、３番目のエントリに障害のあるキー又は障害のあるＲｏｕｔｉｎｇＩＤが含まれている場合、ＭＥは、別のエントリを選択することはなく、ロックアウトされたままになる。

したがって、更新の場合、通常、古いキーの代わりにキーが上書きされる。しかしながら、新しいキーに何らかの障害があるか、或いは、ＲｏｕｔｉｎｇＩＤ、ＨＮ ＫＩＤ、若しくは保護スキームなどの関連パラメータに障害がある場合、ＵＥはサービスを取得できない。この問題を解決するために、ＵＳＩＭにエントリを追加することができるが、これはＭＥがこのキーを使用しないことを意味する。優先度パラメータを追加することで、この問題を次のように解決できる。

図７を再び参照すると、ステップ５及び７に従ってキーがダウンロードされ、格納されると、ステップ６において、同じ保護スキームを有する既存のキーの優先度パラメータよりも低い優先度パラメータがＵＳＩＭによって割り当てられる。

ステップ８において、キー検証、又はアタッチパラメータ確認プロセスが開始される。そのために、ＭＥは、ステップ８において、ＵＳＩＭに公開鍵のリストを要求する。ＵＳＩＭは、ステップ９において、修正されたリストを提示し、リストにおいて、最近更新された鍵がリストの先頭に来るように、ホームネットワーク公開鍵の高優先度エントリは、公開鍵の、新しい、低い優先度エントリで置き換えられる。あるいは、ＵＳＩＭは、ＭＥがＳＵＣＩ計算のために新しいキーを選択することを強制するために、ＭＥに新たに更新されたキーを提示するだけでよい。ＭＥは、ステップ１０においてＳＵＣＩを計算し、ステップ１１において、アタッチパラメータ確認メッセージを使用して、ＵＳＣＩをネットワーク（ＡＭＦ）に送信する。図７において、このメッセージは、例えば、ＭＥが新たに計算されたＳＵＣＩを含めるＮＡＳ ＵＬ転送メッセージである。ステップ１１で送信されるメッセージは、Ｎｕｄｍ＿ＳＤＭ＿Ｉｎｆｏメッセージ内で搬送され得る。ステップ１２において、ＡＭＦは、ＳＵＣＩをＵＤＭに転送する。ＳＵＣＩを受信したＵＤＭは、ステップ１３において、図１において説明したようにＳＵＣＩの検証を行い、ステップ１４～１６に従って、ＵＥにＳＵＣＩが正しいかどうかを通知する。ステップ１７において、ＵＳＩＭは、鍵マテリアルを確認する。

図１８に示される別の例において、鍵検証手順は、別の方法で起動される。図１８において、ＵＥは、アタッチパラメータの更新を行い、その後ネットワークからデタッチしている。このデタッチは、これらのパラメータの更新後に常にデタッチが必要なＵＥの設定の結果であるか、或いは、ネットワークからのデタッチメッセージの結果である可能性がある。しばらくして、ＵＥは、ステップ１でネットワークへのアタッチを試行し、ＡＭＦにアタッチメッセージを送信する。ＡＭＦは、ステップ２において、ＩＤ要求で応答する。ＭＥがＳＵＣＩを計算する場合、ＭＥは、ステップ３において、鍵マテリアルをＵＳＩＭに要求する。ＵＳＩＭは、ステップ４において、修正されたリストを提示し、リストにおいて、最近更新された鍵がリストの先頭に来るように、ホームネットワーク公開鍵の高優先度エントリが、公開鍵の新しい低優先度のエントリに置き換えられる。あるいは、ＵＳＩＭは、ＭＥがＳＵＣＩ計算のために新しいキーを選択することを強制するために、ＭＥに新たに更新されたキーを提示するだけでよい。ＭＥは、ステップ５においてＳＵＣＩを計算し、ステップ６においてＳＵＣＩをネットワークに送信する。

サービングネットワークのＡＭＦは、ステップ７において、ＳＵＣＩのＭＣＣ／ＭＮＣ部分に基づいて、認証要求メッセージ内のＳＵＣＩを正しいホームネットワークに送信し、その後、ホームネットワークはＲｏｕｔｉｎｇＩＤに基づいてＵＤＭを選択する。ＵＤＭは、ステップ８において、ＳＩＤＦにＳＵＣＩを転送し、ＳＩＤＦは、ＳＵＣＩを復号化し、ＵＤＭにＳＵＰＩを返送する。

このＳＵＰＩに基づいて、ＵＤＭは認証ベクトルを生成し、ＵＤＭは、ステップ９において、認証応答で認証ベクトルをＡＭＦに送り返す。ＡＭＦは、ステップ１０において、認証要求メッセージを用いてＲＡＮＤ及びＡＵＴＮをＵＥに転送する。ＵＥ内部において、ＭＥ部は、ステップ１１においてＲＡＮＤ及びＡＵＴＮを受信し、それらをＵＳＩＭに転送する。

ＵＳＩＭがＲＡＮＤ及びＡＵＴＮを受信すると、ＵＳＩＭは、まずＡＵＴＮが正しいか否かを確認する。ＡＵＴＮが正しい場合、ＵＳＩＭは、ＡＵＴＮが受信されたという事実から、新しい鍵マテリアルが正しいこと、及びそれがサブスクリプションを保持するＵＤＭにつながることを控除することができる。その後、ＵＳＩＭは、新しい鍵マテリアルをより高い優先度の場所に移動させ、古い鍵マテリアルを除去するか、又は潜在的なフォールバック位置のために古い鍵マテリアルを保持し、より低い優先度を割り当てるかを決定することができる。後者は、ＭＥが古い鍵マテリアルで暗号化されたＳＵＣＩをネットワークに送信した場合に、ＵＳＩＭが脅威を軽減することを可能にし、その後、ネットワークがＲＡＮＤ及びＡＵＴＮをＭＥに返すようにすることができる。ＵＳＩＭが古い鍵を保持するが、低い優先度で保持する場合、ＵＳＩＭは、新しい鍵材料が使用されており、古い鍵材料を除去することができることを示すＵＤＭからの明示的な信号を待機してもよい。

ＵＳＩＭがＲＡＮＤ及びＡＵＴＮを受信しなかった場合、或いは正しいＡＵＴＮを受信しなかった場合、ＵＳＩＭは、新しい鍵マテリアルが不正である可能性があると結論づけることができる。このように、ＵＳＩＭは、ＵＥが古いが正しい鍵マテリアルに基づいて再びアクセスできることを確実にするために、古い鍵マテリアルをより高い優先度で保持する。アクセスが取得されると、ＵＤＭは、古い鍵マテリアルが使用されていることを監視し、ＵＥと共にリカバリ手順を開始できる。

加えて、シーケンス番号、ＡＭＦビット、及びＭＡＣ（ＡＵＴＮ＝ＳＱＮ＊ＡＫ｜｜ＡＭＦ｜｜ＭＡＣ）を含むＡＵＴＮが、新しい鍵で暗号化されたＳＵＣＩ、又は新しいＲｏｕｔｉｎｇＩＤを持つＳＵＣＩが正しく受信されたことを信号で伝えるため、ＵＤＭにより使用され得る。ＵＤＭは、サブスクリプションが２つのＵＤＭ間で移動された場合、ＡＭＦビットを設定するか、又はＳＱＮを０に設定することによって、これを行うことができる。これは、ＵＳＩＭにとって、新しいアタッチクリティカルパラメータが正しいことの確認となる。そのため、ＵＳＩＭはメッセージを削除できる。

（第３実施形態）
図１０は、本開示の第３実施形態に従って、ホームネットワーク公開鍵などのアタッチ関連パラメータが更新された後に、これらのパラメータの正当性を確認するための方法を示す。図１０は、一例としてホームネットワーク公開鍵を使用するが、方法は、ＲｏｕｔｉｎｇＩＤ、保護スキーム等の更新後に等しく適用することができる。以下の説明において、ホームネットワーク公開鍵は、それらパラメータの一例としてのみ理解される。他のパラメータとの違いが発生した場合、本文に示されている。

図１０の方法は、重要なアタッチ関連パラメータが過去に更新されたと仮定している。ＵＤＭは、ＵＳＩＭ内の特定のパラメータ（パラメータ１）が正しいか否かを確認したい。そのために、ＵＤＭは、ステップ１において、チェックするパラメータを含む「チェックアタッチパラメータ」メッセージをＡＭＦに送信する。チェックアタッチパラメータのメッセージは、図１７に従ってオプションで保護される。ステップ２において、ＡＭＦは、チェックアタッチパラメータメッセージを、例えばＮＡＳ ＤＬトランスポートを使用してＭＥに転送する。ＭＥは、ステップ３において、チェックアタッチパラメータメッセージをＵＳＩＭに転送する。ＵＳＩＭは、受信すると、ステップ４において応答を計算し、ステップ５においてＭＥに応答を返す。ＭＥは、ステップ６において応答をＡＭＦに転送する。ＡＭＦは、ステップ７においてＵＤＭに応答を返し、ＵＤＭは検証を行うことができる。

ＵＳＩＭの応答は、複数の方法で計算できる。１．ＵＳＩＭがＳＵＣＩを計算するＭＥの一部である場合、応答は要求されたパラメータの暗号化された表現にすることができる。その後、ＨＮ公開鍵を使用して暗号化を行うことができる。ＵＤＭは、ＳＩＤＦに送信して値を復号化することにより値を検証し、プレーンテキスト値を比較する。２．応答は、パラメータ自体にすることもできる。この場合、ＭＥは、ＨＮ公開鍵でパラメータを暗号化し、ステップ６でパラメータの暗号化表現を含めることができる。ＵＤＭによる検証方法は同じである。３．ＵＤＭからのチェックパラメータメッセージは、認証ベクトルのＲＡＮＤ及びＡＵＴＮを含むことができる。ＵＳＩＭは、ＲＥＳを計算し、ＡＵＴＮを検証し、全てが正しければ、ＲＥＳとパラメータとの間、又はＡＫ（Anonymity key）と要求されたパラメータとの間にＸＯＲ演算を適用することにより、パラメータの暗号化表現を返すことができる。ＵＤＭ側では、同じＸＯＲが実行され、比較のためにプレーンテキストパラメータが再度取得される。

上記は、ＵＳＩＭが、図９に示されるように、異なる優先度を有するアタッチクリティカルパラメータの複数のセットを記憶するように構成される場合に特に有用である。そのような場合、ＵＤＭは、最初にパラメータを検証することができ、正しい場合、ＵＳＩＭに、以下に説明するように、新しいアタッチクリティカルパラメータが最初のパラメータになるように、パラメータの優先度を変更するように指示することができる。

図１１は、アタッチクリティカルパラメータの優先度を変更するための手順を示す。ステップ１において、ＵＤＭは、変更する優先度を含む「アタッチパラメータの優先度変更」メッセージをＡＭＦに送信する。例えば、アタッチパラメータの優先度変更メッセージは、優先度を変更するキーＩＤの優先度付きリストを含んでもよく、或いは、ＵＳＩＭにおいて最も高い優先度を取得するキーＩＤを含んでもよい。ステップ２において、ＡＭＦは、例えばＮＡＳ ＤＬトランスポートを使用して、アタッチパラメータの優先度変更メッセージをＭＥに転送する。ＭＥは、ステップ３において、アタッチパラメータの優先度変更メッセージをＵＳＩＭに転送する。ＵＳＩＭは受信すると、ステップ４において優先度を再編成する。ＵＳＩＭは、ステップ５においてＭＥに確認を返す。ＭＥは、ステップ６において確認をＡＭＦに転送する。ＡＭＦは、ステップ７においてＵＤＭに確認を返す。

図１２に優先度変更後のＵＳＩＭのテーブルを示す。ステップ３及びステップ４のメッセージの効果は、次のように説明できる。ここで、ＵＥ（ＭＥとＵＳＩＭを組み合わせたもの）は、図１１のステップ２に従って、優先度変更メッセージを受信する。ＭＥは、優先度変更メッセージを、図１２のテーブルに従ってキーを再編成するＵＳＩＭに転送する。前述したように、この再編成は永久的なものであっても一時的なものであってもよい。一時的な場合には、図１２のテーブルは、ＵＳＩＭが鍵マテリアルの次の要求時にＭＥに提示するであろうテーブルを表す。永久的な場合には、図１２のテーブルは、ＭＥの内部ストレージを表す。

優先度ベースのアプローチの利点は、ＵＤＭが最初にパラメータの正確性を検証し、次いで、計算のためにＭＥに提示される順序、又は計算のためにＵＳＩＭによって使用される順序を効果的に変更できることである。最初に検証することで、フォールバックが必要になる可能性は大幅に低くなる。

（他の実施形態）
本開示におけるユーザ機器（「ＵＥ」、「移動局」、「モバイルデバイス」、又は「ワイヤレスデバイス」）は、無線インタフェースを介してネットワークに接続されたエンティティである。

なお、本開示におけるＵＥは、専用の通信装置に限定されるものではなく、後述するように、本開示で説明するＵＥとしての通信機能を有する任意の装置に適用することができる。

「ユーザ機器」又は「ＵＥ」（この用語は３ＧＰＰで使用されている）、「移動局」、「モバイルデバイス」、及び「ワイヤレスデバイス」という用語は、一般に、互いに同義であることを意図しており、端末、携帯電話、スマートフォン、タブレット、携帯ＩｏＴデバイス、ＩｏＴデバイス、及び機械などのスタンドアロンの移動局を含む。

用語「ＵＥ」及び「ワイヤレスデバイス」は、長期間静止したままである装置も含むことが理解される。

ＵＥは、例えば、生産又は製造用の機器のアイテム、及び／又はエネルギー関連機械のアイテムであり得る（例えば、ボイラー、エンジン、タービン、ソーラーパネル、風力タービン、水力発電機、火力発電機、原子力発電機、バッテリ、原子力システム、及び／又は関連機器、重電機器、真空ポンプを含むポンプ、コンプレッサー、ファン、ブロワー、油圧機器、空気圧機器、金属加工機械、マニピュレータ、ロボットやその応用システム、ツール、金型、ロール、搬送装置、昇降装置、運搬設備、繊維機械、ミシン、印刷及び／又は関連機械、紙加工機械、化学機械、鉱山機械及び／又は建設機械、及び／又は関連設備、農林水産用機械器具、安全及び／又は環境保全設備、トラクタ、精密軸受、チェーン、歯車、動力伝達装置、潤滑装置、バルブ、配管継手、及び／又は、上記の装置又は機械などの何れかのためのアプリケーションシステムなどの設備又は機械）。

ＵＥは、例えば、搬送機器（例えば、車両、自動車、オートバイ、自転車、列車、バス、カート、人力車、船やその他の船舶、航空機、ロケット、衛星、ドローン、バルーンなどの運輸機器）のアイテムであってもよい。

ＵＥは、例えば、情報通信機器（例えば、電子計算機及び関連機器、通信及び関連機器、電子部品などの情報通信機器）のアイテムであってもよい。

ＵＥは、例えば、冷凍機、冷凍機応用製品、取引及び／又はサービス産業機器のアイテム、自動販売機、自動サービス機械、事務用機械や機器、消費者電子機器や家電製品（例えば、オーディオ機器、ビデオ機器、スピーカー、ラジオ、テレビ、電子レンジ、炊飯器、コーヒーメーカー、食器洗い機、洗濯機、乾燥機、電子扇風機又は関連する器具、掃除機などの電子製品）であってもよい。

ＵＥは、例えば、電気アプリケーションシステム又は機器（例えば、Ｘ線システム、粒子加速器、ラジオアイソトープ装置、音響装置、電磁応用装置、電力応用機器などの電気アプリケーションシステム又は機器）であってもよい。

ＵＥは、例えば、電子ランプ、照明器具、測定器具、分析器、テスタ、又は測量又はセンシング器具（例えば、煙警報器、人間の警報センサ、モーションセンサー、無線タグなどの測量又はセンシング機器）、時計又は置き時計、実験器具、光学装置、医療機器及び／又はシステム、武器、刃物のアイテム、ハンドツールなどであり得る。

ＵＥは、例えば、無線を備えた携帯情報端末又は関連機器（他の電子機器（例えばパソコン、電気測定機）に取り付けたり、挿入したりするように設計されたワイヤレスカードやモジュールなど）であってもよい。

ＵＥは、様々な有線及び／又は無線通信技術を使用して、ＩｏＴ（internet of things）に関して以下に記載されるアプリケーション、サービス、及び解決策を提供する装置又はシステムの一部であり得る。

ＩｏＴデバイス（又はthings）は、これらの装置が互いに、及び他の通信装置とデータを収集及び交換することを可能にする、適切な電子機器、ソフトウェア、センサ、ネットワーク接続などを備えることができる。ＩｏＴデバイスは、内部メモリに記憶されたソフトウェア命令に従う自動化された機器を含むことができる。ＩｏＴデバイスは、人間の監視や対話を必要とせずに動作することができる。ＩｏＴデバイスはまた、長期間にわたって静止及び／又は非アクティブのままであり得る。ＩｏＴデバイスは、（一般的に）固定装置の一部として実装されてもよい。ＩｏＴデバイスはまた、非固定装置（例えば車両）に組み込まれてもよく、又は監視／追跡される動物若しくは人に取り付けられてもよい。

ＩｏＴ技術は、通信デバイスが人間の入力によって制御されているか、又はメモリに記憶されたソフトウェア命令によって制御されているかどうかにかかわらず、データを送受信するために通信ネットワークに接続することができる任意の通信デバイス上に実装することができることが理解される。

ＩｏＴデバイスは、ＭＴＣ（Machine-Type Communication）デバイス、Ｍ２Ｍ（Machine-to-Machine）通信デバイス、或いはＮＢ－ＩｏＴ ＵＥ（Narrow Band-IoT UE）と呼ばれることもあることが理解される。ＵＥは、１つ又は複数のＩｏＴ又はＭＴＣアプリケーションをサポートすることができることが理解される。ＭＴＣアプリケーションのいくつかの例が下記表（供給源：３ＧＰＰ ＴＳ ２２．３６８ Ｖ１３．１．０、附則Ｂ、その内容は参照によりここに組み込まれる）にリストされる。このリストは、完全なものではなく、マシンタイプ通信アプリケーションのいくつかの例を示すことを意図している。

アプリケーション、サービス、及びソリューションは、ＭＶＮＯ（Mobile Virtual Network Operator)）サービス、緊急無線通信システム、ＰＢＸ（Private Branch eXchange）システム、ＰＨＳ（Personal Handy-phone System）／デジタルコードレス通信システム、ＰＯＳ（Point of sale）システム、広告呼出システム、ＭＢＭＳ（Multimedia Broadcast and Multicast Service）、Ｖ２Ｘ（Vehicle to Everything）システム、列車無線システム、位置関連サービス、災害／緊急無線通信サービス、コミュニティサービス、ビデオストリーミングサービス、フェムトセルアプリケーションサービス、ＶｏＬＴＥ（Voice over LTE）サービス、課金サービス、無線オンデマンドサービス、ローミングサービス、活動監視サービス、電気通信キャリア／通信ＮＷ選択サービス、機能制限サービス、ＰｏＣ（Proof of Concept）サービス、個人情報管理サービス、アドホックネットワーク／ＤＴＮ（Delay Tolerant Networking）サービスなどであり得る。

また、上述したＵＥカテゴリは、本開示に記載された技術的思想及び例示的実施形態の適用例に過ぎない。いうまでもなく、これらの技術思想及び実施形態は、上記ＵＥに限定されるものではなく、種々の変形が可能である。

ユーザ機器（ＵＥ）
図１３は、本開示の実施形態に係るＵＥの主要な構成要素を示すブロック図である。図示のように、ＵＥ１０は、一つ以上のアンテナ１１を介して、接続されたノードに信号を送信し、接続されたノードから信号を受信するように動作可能な送受信回路１２を含む。図１３に必ずしも示されているわけではないが、ＵＥは、当然ながら、通常のモバイルデバイスの通常の機能の全て（ユーザインタフェース１３など）を有し、これは、必要に応じて、任意のハードウェア、ソフトウェア、及びファームウェアの任意の組み合わせによって提供され得る。ソフトウェアは、メモリ１５にあらかじめインストールされてもよく、及び／又は、例えば、電気通信ネットワークを介して、又は取り外し可能なデータ記憶装置（ＲＭＤ：removable data storage device）からダウンロードされてもよい。

コントローラ１４は、メモリ１５に記憶されたソフトウェアに従って、ＵＥ１０の動作を制御する。例えば、コントローラ１４は、ＣＰＵ（Central Processing Unit）によって実現されてもよい。ソフトウェアは、とりわけ、オペレーティングシステム１６、及び少なくともトランシーバ制御モジュール１８を有する通信制御モジュール１７を含む。通信制御モジュール１８（そのトランシーバ制御サブモジュールを使用する）は、ＵＥ１０と、基地局／（Ｒ）ＡＮノード、ＭＭＥ、ＡＭＦ（及び他のコアネットワークノード）などの他のノードとの間のシグナリング及びアップリンク／ダウンリンクのデータパケットの処理を担当（生成／送信／受信）する。そのようなシグナリングは、例えば、接続の確立及び維持に関する適切にフォーマットされたシグナリングメッセージ（例えばＲＲＣメッセージ）、周期的な位置更新に関連するメッセージ（例えば、トラッキングエリアの更新、ページングエリアの更新、ロケーションエリアの更新）などのＮＡＳメッセージなどが含まれる。

（Ｒ）ＡＮノード
図１４ａは、本開示の実施の形態に係る例示的な（Ｒ）ＡＮノード、例えば基地局（ＬＴＥでは「ｅＮＢ」、５Ｇでは「ｇＮＢ」）の主要な構成要素を示すブロック図である。図示のように、（Ｒ）ＡＮノード３０は、１以上のアンテナ３１を介して、接続されたＵＥとの間で信号を送受信し、他のネットワークノードとの間で、ネットワークインタフェース３３を介して信号を（直接的又は間接的に）送受信するように動作可能な送受信回路３２を含む。コントローラ３４は、メモリ３５に記憶されたソフトウェアに従って、ＡＮノード３０の動作を制御する。例えば、コントローラ３４は、ＣＰＵ（Central Processing Unit）によって実現されてもよい。ソフトウェアは、メモリ３５にあらかじめインストールされてもよく、及び／又は、例えば、電気通信ネットワークを介して、又は取り外し可能なデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム３６、及び少なくともトランシーバ制御モジュール３８を有する通信制御モジュール３７を含む。

通信制御モジュール３７（そのトランシーバ制御サブモジュールを使用する）は、（Ｒ）ＡＮノード３０と他のノード、例えばＵＥ、ＭＭＥ、ＡＭＦとの間のシグナリング（例えば直接的又は間接的に）の処理を担当（生成／送信／受信）する。シグナリングは、例えば、無線接続及びロケーション手順（特定のＵＥに対して）に関連する適切にフォーマットされたシグナリングメッセージを含むことができ、特に、接続の確立及び保守（例えばＲＲＣ接続の確立及び他のＲＲＣメッセージ）、定期的なロケーション更新（例えば、トラッキングエリアの更新、ページングエリアの更新、ロケーションエリアの更新）、Ｓ１ ＡＰメッセージ、及びＮＧ ＡＰメッセージ（すなわちＮ２基準点によるメッセージ）などに関連する適切にフォーマットされたシグナリングメッセージを含むことができる。そのようなシグナリングは、例えば、送信ケースにおけるブロードキャスト情報（マスタ情報やシステム情報など）も含み得る。

コントローラ３４は、また、実行時にＵＥ移動度推定及び／又は移動軌跡推定などの関連タスクを担当するように（ソフトウェア又はハードウェアによって）構成される。

コアネットワークノード
図１５ａは、本開示の実施形態に係る例示的なコアネットワークノード、例えば、ＡＭＦ、ＳＥＡＦ、ＡＵＳＦ、ＫＳ、ＵＤＭ、又は他の任意のコアネットワークノードの主要構成要素を示す。ＡＭＦは、ＳＥＡＦの代替となり得る。ＡＵＳＦは、ＵＤＭの代替となり得る。コアネットワークノード５０は、５ＧＣに含まれる。図に示すように、コアネットワークノード５０は、ネットワークインタフェース５２を介して他のノード（ＵＥを含む）と信号を送受信するように動作可能な送受信回路５１を含む。コントローラ５３は、メモリ５４に記憶されたソフトウェアに従ってコアネットワークノード５０の動作を制御する。例えば、コントローラ５３は、ＣＰＵ（Central Processing Unit）によって実現されてもよい。ソフトウェアは、メモリ５４にあらかじめインストールされてもよく、及び／又は、例えば、電気通信ネットワークを介して、又は取り外し可能なデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム５５、及び少なくともトランシーバ制御モジュール５７を有する通信制御モジュール５６を含む。

通信制御モジュール５６（そのトランシーバ制御サブモジュールを使用）は、コアネットワークノード５０とＵＥ、基地局／（Ｒ）ＡＮノードなどの他のノード（例えば「ｇＮＢ」又は「ｅＮＢ」）との間のシグナリングの処理を担当（生成／送信／受信）する（直接的又は間接的に）。そのようなシグナリングは、例えば、本明細書に記載する手順に関連する適切にフォーマットされたシグナリングメッセージ、例えば、ＵＥとの間でＮＡＳメッセージを伝達するためのＮＧ ＡＰメッセージ（すなわちＮ２基準点によるメッセージ）などが含まれる。

開示された例の前述の説明は、当業者が本開示を作成又は使用することを可能にするために提供される。これらの実施例に対する種々の修正は、当業者には容易に明らかであり、本明細書に定義される一般原理は、本開示の精神又は範囲から逸脱することなく、他の実施例に適用することができる。したがって、本開示は、本明細書に示される例に限定されることを意図するものではなく、本明細書に開示される原理及び新規の特徴と一致する最も広い範囲を与えるものである。

例えば、上記の実施形態の全部又はいくつかは、以下の付記のようにも記載され得るが、以下には限られない。

［付記１］
１つ以上の命令を格納するメモリと、
前記１つ以上の命令を実行することで、
ネットワーク通信に対応する更新情報を外部装置から受信し、
前記更新情報に基づいてＳＵＣＩ（Subscription Concealed Identifier）を取得し、
前記ＳＵＣＩを前記外部装置に送信する
ように構成されるプロセッサとを備える装置。

［付記２］
前記プロセッサは、ＳＵＰＩ（Subscription Permanent Identifier）を前記更新情報に基づいて暗号化することにより前記ＳＵＣＩを取得するように更に構成される付記１に記載の装置。

［付記３］
前記プロセッサは、ＳＵＰＩ（Subscription Permanent Identifier）と前記更新情報とを連結することによって前記ＳＵＣＩを取得するように更に構成される付記１に記載の装置。

［付記４］
前記プロセッサは、前記ＳＵＣＩに対応する前記ＳＵＰＩと、前記更新情報に対応付けて格納される他のＳＵＰＩとの一致に基づく確認メッセージを前記外部装置から受信するように更に構成される付記２又は３に記載の装置。

［付記５］
前記更新情報は、ホームネットワーク公開鍵、ルーティングＩＤ、ホームネットワーク公開鍵識別子と、及び前記装置における保護スキームの少なくとも１つを含む付記１から４の何れか１項に記載の装置。

［付記６］
１つ以上の命令を格納するメモリと、
前記１つ以上の命令を実行することで、
ネットワーク通信に対応する更新情報を外部装置に送信し、
前記更新情報に基づいて取得されるＳＵＣＩ（Subscription Concealed Identifier）を前記外部装置から受信し、
前記受信したＳＵＣＩに基づいてＳＵＰＩ（Subscription Permanent Identifier）を取得し、
前記ＳＵＰＩが前記更新情報に対応しているかを検証する
ように構成されるプロセッサとを備える装置。

［付記７］
前記ＳＵＰＩは、前記ＳＵＣＩに対してＳＩＤＦ（Subscription Identifier De-concealing function）を実行することによって取得される付記６に記載の装置。

［付記８］
前記プロセッサは、前記ＳＩＤＦから取得された前記ＳＵＰＩと、前記更新情報に関連付けて記憶された別のＳＵＰＩと比較することによって、前記ＳＵＰＩを検証するように更に構成される付記７に記載の装置。

［付記９］
前記プロセッサは、前記ＳＩＤＦから取得されたＳＵＰＩと、前記更新情報に対応付けて記憶されている他のＳＵＰＩとの一致に基づいて、前記外部装置に確認を送信するように更に構成される付記８に記載の装置。

［付記１０］
前記更新情報は、ホームネットワーク公開鍵、ルーティングＩＤ、ホームネットワーク公開鍵識別子、及び前記装置内の保護スキームの少なくとも１つを含む付記６から９の何れか１項に記載の装置。

［付記１１］
外部装置から、ネットワーク通信に対応する更新情報を受信し、
前記更新情報に基づいてＳＵＣＩ（Subscription Concealed Identifier）を取得し、
前記ＳＵＣＩを前記外部装置に送信する方法。

［付記１２］
前記ＳＵＣＩは、前記更新情報に基づいてＳＵＰＩ（Subscription Permanent Identifier）を暗号化することによって取得される付記１１に記載の方法。

［付記１３］
前記ＳＵＣＩは、ＳＵＰＩ（Subscription Permanent Identifier）サブスクリプションと前記更新情報とを連結することによって取得される付記１１に記載の方法。

［付記１４］
更に、前記ＳＵＣＩに対応する前記ＳＵＰＩと、前記更新情報に関連付けて記憶される他のＳＵＰＩとの一致に基づく確認メッセージを前記外部装置から受信する付記１２又は１３に記載の方法。

［付記１５］
前記更新情報は、ホームネットワーク公開鍵、ルーティングＩＤ、ホームネットワーク公開鍵識別子、及び装置における保護スキームのうちの少なくとも一つを含む付記１１から１４の何れか１項に記載の方法。

［付記１６］
ネットワーク通信に対応する更新情報を外部装置に送信し、
前記更新情報に基づいて取得されるＳＵＣＩ（Subscription Concealed Identifier）を前記外部装置から受信し、
前記受信したＳＵＣＩに基づいてＳＵＰＩ（Subscription Permanent Identifier）を取得し、
前記ＳＵＰＩが前記更新情報に対応しているかを検証する方法。

［付記１７］
前記ＳＵＰＩは、前記ＳＵＣＩに対してＳＩＤＦ（Subscription Identifier De-concealing function）を実行することによって取得される付記１６に記載の方法。

［付記１８］
前記ＳＩＤＦから取得された前記ＳＵＰＩと、前記更新情報に関連付けて記憶される他のＳＵＰＩとを比較することにより、前記ＳＵＰＩを検証する付記１７に記載の方法。

［付記１９］
更に、前記ＳＩＤＦから取得された前記ＳＵＰＩと、前記更新情報に関連付けて記憶されるＳＵＰＩとの一致に基づいて、前記外部装置に確認を送信する付記１８に記載の方法。

［付記２０］
前記更新情報は、ホームネットワーク公開鍵、ルーティングＩＤ、ホームネットワーク公開鍵識別子、及び装置における保護スキームの少なくとも１つを含む付記１６から１９の何れか１項に記載の方法。

本出願は、２０１８年１１月６日に出願されたインド特許出願第２０１８１１０４１９６４号に基づく優先権の利益を主張するものであり、その開示は、その全体が参照により本明細書に組み込まれる。

１０ ＵＥ
１１ アンテナ
１２ 送受信回路
１３ ユーザインタフェース
１４ コントローラ
１５ メモリ
１６ オペレーティングシステム
１７ 通信制御モジュール
１８ トランシーバ制御モジュール
３０ （Ｒ）ＡＮノード
３１ アンテナ
３２ 送受信回路
３３ ネットワークインタフェース
３４ コントローラ
３５ メモリ
３６ オペレーティングシステム
３７ 通信制御モジュール
３８ トランシーバ制御モジュール
５０ コアネットワークノード
５１ 送受信回路
５２ ネットワークインタフェース
５３ コントローラ
５４ メモリ
５５ オペレーティングシステム
５６ 通信制御モジュール
５７ トランシーバ制御モジュール

Claims (4)

1. 更新されたＲｏｕｔｉｎｇ ＩＤを、コアネットワーク装置から受信する受信手段と、
   前記更新されたＲｏｕｔｉｎｇ ＩＤに関連するＭＡＣ－Ｉ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ ｆｏｒ Ｉｎｔｅｇｒｉｔｙ）を確認する確認手段と、
   前記ＭＡＣ－Ｉが有効な場合には、前記更新されたＲｏｕｔｉｎｇ ＩＤをＵＳＩＭに格納する格納手段と、
   前記更新されたＲｏｕｔｉｎｇ ＩＤと、暗号化されたＳｕｂｓｃｒｉｐｔｉｏｎ Ｐｅｒｍａｎｅｎｔ Ｉｄｅｎｔｉｆｉｅｒ（ＳＵＰＩ）と、を連結することにより、Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｃｏｎｃｅａｌｅｄ Ｉｄｅｎｔｉｆｉｅｒ（ＳＵＣＩ）を取得する取得手段と、
   前記ＳＵＣＩを、前記コアネットワーク装置へ送信する送信手段と、
   を備える通信端末装置。
2. 前記受信手段は、確認メッセージを前記コアネットワーク装置から受信する請求項１に記載の通信端末装置。
3. 更新されたＲｏｕｔｉｎｇ ＩＤを、コアネットワーク装置から受信し、
   前記更新されたＲｏｕｔｉｎｇ ＩＤに関連するＭＡＣ－Ｉを確認し、
   前記ＭＡＣ－Ｉが有効な場合には、前記更新されたＲｏｕｔｉｎｇ ＩＤをＵＳＩＭに格納し、
   前記更新されたＲｏｕｔｉｎｇ ＩＤと、暗号化されたＳｕｂｓｃｒｉｐｔｉｏｎ Ｐｅｒｍａｎｅｎｔ Ｉｄｅｎｔｉｆｉｅｒ（ＳＵＰＩ）と、を連結することにより、Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｃｏｎｃｅａｌｅｄ Ｉｄｅｎｔｉｆｉｅｒ（ＳＵＣＩ）を取得し、
   前記ＳＵＣＩを、前記コアネットワーク装置へ送信する、
   通信端末装置の方法。
4. さらに、確認メッセージを前記コアネットワーク装置から受信する請求項３に記載の通信端末装置の方法。

Images