3gpp ts 33.102 v3.6

3GPP TS 33.102 V3.6.0 (2000-10)技術仕様書

3rd Generation Partnership Project;Technical Specification Group Services and System Aspects;

3G Security;Security Architecture

(Release 1999)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification.Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)2Release 1999

Keywords Security, Architecture

3GPP

Postal address

3GPP support office address 650 Route des Lucioles - Sophia Antipolis

Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorised by written permission. The copyright and the foregoing restrictions extend to reproduction in all media.

© 3GPP 2000

All rights reserved.

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)3Release 1999

Contents Foreword............................................................................................................................................................ 6

1 Scope ....................................................................................................................................................... 3

2 References ............................................................................................................................................... 7

3 Definitions, symbols and abbreviations................................................................................................... 8 3.1 Definitions..........................................................................................................................................................8 3.2 Symbols..............................................................................................................................................................9 3.3 Abbreviations ...................................................................................................................................................10

4 Overview of the security architecture.................................................................................................... 11

5 Security features .................................................................................................................................... 12 5.1 Network access security ...................................................................................................................................12 5.1.1 User identity confidentiality .......................................................................................................................12 5.1.2 Entity authentication...................................................................................................................................13 5.1.3 Confidentiality ............................................................................................................................................13 5.1.4 Data integrity ..............................................................................................................................................13 5.1.5 Mobile equipment identification.................................................................................................................14 5.2 Network domain security .................................................................................................................................14 5.2.1 Void ............................................................................................................................................................14 5.2.2 Void ............................................................................................................................................................14 5.2.3 Void ............................................................................................................................................................14 5.2.4 Fraud information gathering system...........................................................................................................14 5.3 User domain security........................................................................................................................................14 5.3.1 User-to-USIM authentication .....................................................................................................................14 5.3.2 USIM-Terminal Link..................................................................................................................................15 5.4 Application security .........................................................................................................................................15 5.4.1 Secure messaging between the USIM and the network..............................................................................15 5.4.2 Void ............................................................................................................................................................15 5.4.3 Void ............................................................................................................................................................15 5.4.4 Void ............................................................................................................................................................15 5.5 Security visibility and configurability..............................................................................................................15 5.5.1 Visibility .....................................................................................................................................................15 5.5.2 Configurability ...........................................................................................................................................16

6 Network access security mechanisms.................................................................................................... 16 6.1 Identification by temporary identities ..............................................................................................................16 6.1.1 General .......................................................................................................................................................16 6.1.2 TMSI reallocation procedure......................................................................................................................16 6.1.3 Unacknowledged allocation of a temporary identity ..................................................................................17 6.1.4 Location update ..........................................................................................................................................17 6.2 Identification by a permanent identity..............................................................................................................18 6.3 Authentication and key agreement ...................................................................................................................18 6.3.1 General .......................................................................................................................................................18 6.3.2 Distribution of authentication data from HE to SN ....................................................................................20 6.3.3 Authentication and key agreement .............................................................................................................22 6.3.4 Distribution of IMSI and temporary authentication data within one serving network domain...................25 6.3.5 Re-synchronisation procedure ....................................................................................................................26 6.3.6 Reporting authentication failures from the SGSN/VLR to the HLR ..........................................................27 6.3.7 Length of authentication parameters...........................................................................................................27 6.4 Local authentication and connection establishment .........................................................................................27 6.4.1 Cipher key and integrity key setting ...........................................................................................................27 6.4.2 Ciphering and integrity mode negotiation ..................................................................................................28 6.4.3 Cipher key and integrity key lifetime .........................................................................................................28 6.4.4 Cipher key and integrity key identification ................................................................................................29 6.4.5 Security mode set-up procedure .................................................................................................................29 6.4.6 Signalling procedures in the case of an unsuccessful integrity check.........................................................31

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)4Release 1999

6.4.7 Signalling procedure for periodic local authentication ...............................................................................32 6.4.8 Initialisation of synchronisation for ciphering and integrity protection......................................................32 6.4.9 Emergency call handling ............................................................................................................................33 6.4.9.1 Security procedures applied ..................................................................................................................33 6.4.9.2 Security procedures not applied............................................................................................................33 6.5 Access link data integrity .................................................................................................................................34 6.5.1 General .......................................................................................................................................................34 6.5.2 Layer of integrity protection.......................................................................................................................34 6.5.3 Data integrity protection method ................................................................................................................34 6.5.4 Input parameters to the integrity algorithm ................................................................................................35 6.5.4.1 COUNT-I ..............................................................................................................................................35 6.5.4.2 IK ..........................................................................................................................................................35 6.5.4.3 FRESH..................................................................................................................................................35 6.5.4.4 DIRECTION.........................................................................................................................................36 6.5.4.5 MESSAGE............................................................................................................................................36 6.5.5 Integrity key selection ................................................................................................................................36 6.5.6 UIA identification......................................................................................................................................36 6.6 Access link data confidentiality .......................................................................................................................37 6.6.1 General .......................................................................................................................................................37 6.6.2 Layer of ciphering ......................................................................................................................................37 6.6.3 Ciphering method .......................................................................................................................................37 6.6.4 Input parameters to the cipher algorithm....................................................................................................38 6.6.4.1 COUNT-C.............................................................................................................................................38 6.6.4.2 CK.........................................................................................................................................................39 6.6.4.3 BEARER...............................................................................................................................................39 6.6.4.4 DIRECTION.........................................................................................................................................39 6.6.4.5 LENGTH ..............................................................................................................................................39 6.6.5 Cipher key selection ...................................................................................................................................40 6.6.6 UEA identification......................................................................................................................................40 6.7 Void..................................................................................................................................................................40 6.8 Interoperation and handover between UMTS and GSM ..................................................................................40 6.8.1 Authentication and key agreement of UMTS subscribers ..........................................................................40 6.8.1.1 General..................................................................................................................................................40 6.8.1.2 R99+ HLR/AuC....................................................................................................................................42 6.8.1.3 R99+ VLR/SGSN .................................................................................................................................42 6.8.1.4 R99+ ME ..............................................................................................................................................43 6.8.1.5 USIM ....................................................................................................................................................43 6.8.2 Authentication and key agreement for GSM subscribers ...........................................................................44 6.8.2.1 General..................................................................................................................................................44 6.8.2.2 R99+ HLR/AuC....................................................................................................................................45 6.8.2.3 VLR/SGSN ...........................................................................................................................................45 6.8.2.4 R99+ ME ..............................................................................................................................................45 6.8.3 Distribution and use of authentication data between VLRs/SGSNs...........................................................45 6.8.4 Intersystem handover for CS Services – from UTRAN to GSM BSS........................................................47 6.8.4.1 UMTS security context .........................................................................................................................47 6.8.4.2 GSM security context ...........................................................................................................................47 6.8.5 Intersystem handover for CS Services – from GSM BSS to UTRAN........................................................48 6.8.5.1 UMTS security context .........................................................................................................................48 6.8.5.2 GSM security context ...........................................................................................................................48 6.8.6 Intersystem change for PS Services – from UTRAN to GSM BSS............................................................49 6.8.6.1 UMTS security context .........................................................................................................................49 6.8.6.2 GSM security context ...........................................................................................................................49 6.8.7 Intersystem change for PS services – from GSM BSS to UTRAN ............................................................49 6.8.7.1 UMTS security context .........................................................................................................................49 6.8.7.2 GSM security context ...........................................................................................................................50

7 Void ....................................................................................................................................................... 50

8 Application security mechanisms .......................................................................................................... 51 8.1 Void..................................................................................................................................................................51 8.2 Void..................................................................................................................................................................51 8.3 Mobile IP security ............................................................................................................................................51

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)5Release 1999

Annex A (informative): Requirements analysis .................................................................................. 52

Annex B: Void ....................................................................................................................................... 53

Annex C (informative): Management of sequence numbers.............................................................. 54

C.1 Generation of sequence numbers in the Authentication Centre ............................................................ 54 C.1.1 Sequence number generation schemes .............................................................................................................54 C.1.1.1 General scheme ..........................................................................................................................................54 C.1.1.2 Generation of sequence numbers which are not time-based.......................................................................55 C1.1.3 Time-based sequence number generation...................................................................................................55 C1.2 Support for the array mechanism .....................................................................................................................55

C.2 Handling of sequence numbers in the USIM......................................................................................... 56 C.2.1 Protection against wrap around of counter in the USIM ..................................................................................56 C.2.2 Verification of sequence number freshness in the USIM.................................................................................56 C.2.3 Notes ................................................................................................................................................................56

C.3 Sequence number management profiles ................................................................................................ 57 C.3.1 Profile 1: management of sequence numbers which are partly time-based......................................................57 C.3.2 Profile 2: management of sequence numbers which are not time-based..........................................................58 C.3.3 Profile 3: management of sequence numbers which are entirely time-based...................................................59 C.3.4 Guidelines for the allocation of the index values in the array scheme .............................................................60

C.4 Guidelines for interoperability in a multi-vendor environment............................................................. 60

Annex D: Void ....................................................................................................................................... 62

Annex E: Void ....................................................................................................................................... 63

Annex F (informative): Example uses of AMF ................................................................................... 64 F.1 Support multiple authentication algorithms and keys ........................................................................... 64

F.2 Changing list parameters ....................................................................................................................... 64

F.3 Setting threshold values to restrict the lifetime of cipher and integrity keys......................................... 64

Annex G (informative): Change history............................................................................................... 65

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)6Release 1999

Foreword This Technical Specification has been produced by the 3GPP.

The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:

Version 3.y.z

where:

3 the first digit:

3 Indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the specification.

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)7Release 1999

1 本書の範囲（Scope）本仕様書は、セキュリティアーキテクチャについて規定するものである。つまり、第三世代移動通信システムのセキ

ュリティフィーチャとセキュリティメカニズムについて述べる。

セキュリティフィーチャとは、1 つもしくは複数のセキュリティ要求条件を満たすサービスケーパビリティである。セキュ

リティフィーチャの完全なセットは、"3G Security: Threats and Requirements" (TS 21.133 [1]) として定義されるセキュリ

ティ要求条件を処理し、TS 33.120 [2] 中で説明されるセキュリティ対象と原則を実装する。セキュリティメカニズムと

は、セキュリティフィーチャを実現するためのエレメントである。全てのセキュリティフィーチャとセキュリティメカニズム

を総称して、セキュリティアーキテクチャと呼ぶ。

セキュリティフィーチャの例として、ユーザデータの機密保持がある。本フィーチャを実装するために使用されるセキ

ュリティメカニズムとして、誘導された（derived）暗号鍵を使用したストリーム暗号化方式がある。

本仕様書は、3G ケーパビリティを持つネットワーク(R99+)で実行される 3G セキュリティ処理について定義する。すな

わち UMTS 内で実行されるセキュリティ処理と、UMTS～GSM 内で実行されるセキュリティ処理について定義する。

例えば UMTS の認証は、UMTS の RAN と同様に、UMTS ケーパビリティを持つ GSM の RAN のサービスネットワ

ークノードと MS に対しても適用される。UMTS と互換性を持たないネットワーク(R98-) とのインターオペラビリティに

ついてもカバーする。

2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies.

[1] 3GPP TS 21.133: "3rd Generation Partnership Project (3GPP); Technical Specification Group (TSG) SA; 3G Security; Security Threats and Requirements".

[2] 3GPP TS 33.120: "3rd Generation Partnership Project (3GPP); Technical Specification Group (TSG) SA; 3G Security; Security Principles and Objectives".

[3] 3GPP TR 21.905: "3rd Generation Partnership Project (3GPP); Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications (Release 1999)".

[4] 3GPP TS 23.121: "3rd Generation Partnership Project (3GPP); Technical Specification Group Services and System Aspects; Architecture Requirements for Release 99".

[5] 3GPP TS 31.101: "3rd Generation Partnership Project (3GPP); Technical Specification Group Terminals; UICC-terminal interface; Physical and logical characteristics".

[6] 3GPP TS 22.022: "3rd Generation Partnership Project (3GPP); Technical Specification Group Services and System Aspects; Personalisation of UMTS Mobile Equipment (ME); Mobile functionality specification".

[7] 3GPP TS 23.048: "3rd Generation Partnership Project (3GPP); Technical Specification Group Services and System Aspects; Security Mechanisms for the USIM application toolkit; Stage 2".

[8] ETSI GSM 03.20: "Digital cellular telecommunications system (Phase 2+); Security related network functions".

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)8Release 1999

[9] 3GPP TS 23.060: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2".

[10] ISO/IEC 9798-4: "Information technology - Security techniques - Entity authentication - Part 4: Mechanisms using a cryptographic check function".

[11] 3GPP TS 35.201: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document 1: f8 and f9 specifications".

[12] 3GPP TS 35.202: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document 2: Kasumi algorithm specification".

[13] 3GPP TS 35.203: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document 3: Implementers' test data".

[14] 3GPP TS 35.204: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document 4: Design conformance test data".

[15] 3GPP TS 31.111: "3rd Generation Partnership Project; Technical Specification Group Terminals; USIM Application Toolkit (USAT)".

[16] 3GPP TS 02.48: "Security Mechanisms for the SIM Application Toolkit; Stage 1".

[17] 3GPP TS 25.331: "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RRC Protocol Specification".

[18] 3GPP TS 25.321: "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; MAC protocol specification".

[19] 3GPP TS 25.322: "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification".

3 定義、シンボル、略語（Definitions, symbols and abbreviations）

3.1 定義（Definitions） TR 21.905 [3]中で定義される定義に加えて、本ドキュメントでは以下の略語が使用される。

Confidentiality（機密性）（機密性）（機密性）（機密性）: 特定の情報にアクセスできない、あるいは権限のない個人ユーザ、エンティティ、またはプ

ロセスに対して非開示にするというプロパティ

Data integrity（データの完全性）（データの完全性）（データの完全性）（データの完全性）: データが不正な方法で改竄されていないというプロパティ

Data origin authentication（データ発信元の認証）（データ発信元の認証）（データ発信元の認証）（データ発信元の認証）: 受信したデータの発信元（ソース）が正当な資格を有しているこ

との確証

Entity authentication（エンティティ認証）（エンティティ認証）（エンティティ認証）（エンティティ認証）: エンティティが主張するアイデンティティの保証の提供

Key freshness（鍵の新鮮度）（鍵の新鮮度）（鍵の新鮮度）（鍵の新鮮度）: 相手方当事者または認証される当事者のいずれかのアクションを通じて古い鍵が再

使用されるのではなく、鍵が新しいものであると保証されるならば、鍵は新鮮（fresh）であると見なされる。

USIM （（（（User Services Identity Module）：）：）：）：セキュリティコンテキスト中では、USIM は UMTS の加入者とネットワーク

の認証、そして鍵合意を実行する。加入者が GSM の RAN に容易にローミングできるように、GSM の認証と鍵合意

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)9Release 1999

を実行する能力を持つことも必要。

SIM（（（（GSM Subscriber Identity Module）：）：）：）：セキュリティコンテキスト中では、SIM は GSM の加入者の認証、そして

鍵合意を実行する。SIM は UMTS の認証処理と UMTS の鍵を保存する能力を持つ必要はないないないない。

UMTS Entity authentication and key agreement（（（（UMTS のエンティティ認証と鍵合意）のエンティティ認証と鍵合意）のエンティティ認証と鍵合意）のエンティティ認証と鍵合意）: 本仕様書に基づいたエン

ティティの認証

GSM Entity authentication and key agreement（（（（GSM のエンティティ認証と鍵合意）のエンティティ認証と鍵合意）のエンティティ認証と鍵合意）のエンティティ認証と鍵合意）: TS ETSI GSM 03.20 に基づ

いたエンティティの認証

User access module（ユーザアクセスモジュール）（ユーザアクセスモジュール）（ユーザアクセスモジュール）（ユーザアクセスモジュール）: USIM または SIM のいずれか

Mobile station, user（移動局、ユーザ）（移動局、ユーザ）（移動局、ユーザ）（移動局、ユーザ）: ユーザ装置とユーザアクセスモジュールの組み合わせ

UMTS subscriber（（（（UMTS 加入者）加入者）加入者）加入者）: 移動局のこと。ユーザ装置とそれに挿入された USIM の組み合わせ

GSM subscriber（（（（GSM 加入者）加入者）加入者）加入者）: 移動局のこと。ユーザ装置とそれに挿入された SIM の組み合わせ

UMTS security context（（（（UMTS セキュリティコンテキスト）セキュリティコンテキスト）セキュリティコンテキスト）セキュリティコンテキスト）: UMTS の AKA が実行された結果、ユーザとサービス

ネットワークドメイン間で確立されるステートを指す。ユーザ側、サービスネットワークドメイン側双方で、「UMTS セキ

ュリティコンテキストデータ」（"UMTS security context data"）が保存される。それには低限、UMTS の暗号鍵／完

全鍵 CK と IK、および KSI（key set identifier ）が含まれる。

GSM security context（（（（GSM セキュリティコンテキスト）セキュリティコンテキスト）セキュリティコンテキスト）セキュリティコンテキスト）: GSM の AKA が実行された結果、ユーザとサービスネット

ワークドメイン間で確立されるステートを指す。ユーザ側、サービスネットワークドメイン側双方で、「GSM セキュリティ

コンテキストデータ」（" GSM security context data"）が保存される。それには低限、GSM の暗号鍵 Kc と暗号鍵シ

ーケンス番号 CKSN が含まれる。

Quintet, UMTS authentication vector（クインテット、（クインテット、（クインテット、（クインテット、UMTS 認証ベクトル）認証ベクトル）認証ベクトル）認証ベクトル）: VLR/SGSN が、特定のユーザの UMTS AKA を行うことができるようにするための、一時的な認証データ。クインテットは、以下の 5 つのエレメントから構成さ

れる。すなわち、 a) ネットワークのチャレンジ RAND、 b) 予想されるユーザの応答 XRES、 c) 暗号鍵 CK、 d) 完全

鍵 IK 、そして e) ネットワーク認証トークン AUTN。

Triplet, GSM authentication vector（トリプレット、（トリプレット、（トリプレット、（トリプレット、GSM 認証ベクトル）認証ベクトル）認証ベクトル）認証ベクトル）: VLR/SGSN が、特定のユーザの GSM AKA を行うことができるようにするための、一時的な認証データ。トリプレットは、以下の 3 つのエレメントから構成さ

れる。すなわち、a) ネットワークのチャレンジ RAND、 b) 予想されるユーザの応答 SRES、そして c) 暗号鍵 Kc。

authentication vector（認証ベクトル）（認証ベクトル）（認証ベクトル）（認証ベクトル）: クインテットまたはトリプレットのいずれか

Temporary authentication data（一時的な認証データ）（一時的な認証データ）（一時的な認証データ）（一時的な認証データ）: UMTS または GSM のセキュリティコンテキストデータ、あ

るいは UMTS または GSM の認証ベクトルのいずれか

3.2 シンボル（Symbols）本ドキュメントでは、以下のシンボルが適用される。

|| 連結（Concatenation） ⊕ 排他的論理和（XOR） f1 MAC を算出するためのメッセージ認証関数 f1* MAC-S を算出するためのメッセージ認証関数 f2 RES と XRES を算出するために使用されるメッセージ認証関数 f3 CK を算出するために使用される鍵生成関数 f4 IK を算出するために使用される鍵生成関数 f5 通常の処理手順で AK を算出するために使用される鍵生成関数 f5* 再同期手順で AK を算出するために使用される鍵生成関数 K USIM と AuC の間で長期間共有される秘密鍵

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)10Release 1999

3.3 略語（Abbreviations） TR 21.905 [3]中で定義される略語に加えて、本ドキュメントでは以下の略語が使用される。

AK Anonymity Key（匿名鍵） AKA Authentication and key agreement（認証と鍵合意） AMF Authentication management field（認証管理フィールド） AUTN Authentication Token（認証トークン） AV Authentication Vector（認証ベクトル） CK Cipher Key（暗号鍵） CKSN Cipher key sequence number（暗号鍵シーケンス番号） CS Circuit Switched（回線交換） HE Home Environment HLR Home Location Register IK Integrity Key（完全鍵） IMSI International Mobile Subscriber Identity（国際移動加入者識別子） KSI Key Set Identifier KSS Key Stream Segment（鍵ストリームセグメント） LAI Location Area Identity（ロケーションエリア識別子） MAC The message authentication code included in AUTN, computed using f1

（f1 を使用して算出される、AUTN 中に含まれるメッセージ認証コード） MAC The message authentication code included in AUTN, computed using f1*

（f1*を使用して算出される、AUTN 中に含まれるメッセージ認証コード） ME Mobile Equipment MS Mobile Station（移動局） MSC Mobile Services Switching Centre（移動サービス交換センタ） PS Packet Switched（パケット交換） P-TMSI Packet-TMSI Q Quintet, UMTS authentication vector（クインテット、UMTS 認証ベクトル） RAI Routing Area Identifier（ルーチングエリア識別子） RAND Random challenge（ランダムチャレンジ） SQN Sequence number（シーケンス番号） SQNHE Individual sequence number for each user maintained in the HLR/AuC （HLR/AuC 内でユーザ毎に維持される独立シーケンス番号） SQNMS The highest sequence number the USIM has accepted（USIM が受け付けた上位シーケンス番

号） SGSN Serving GPRS Support Node SIM (GSM) Subscriber Identity Module（GSM の加入者識別モジュール） SN Serving Network（サービスネットワーク） T Triplet, GSM authentication vector（トリプレット、GSM の認証ベクトル） TMSI Temporary Mobile Subscriber Identity（テンポラリ移動加入者識別子） UEA UMTS Encryption Algorithm（UMTS 暗号化アルゴリズム） UIA UMTS Integrity Algorithm（UMTS 完全化アルゴリズム） UICC UMTS IC Card（UMTS IC カード） USIM User Services Identity Module VLR Visitor Location Register XRES Expected Response（予想応答）

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)11Release 1999

4 セキュリティアーキテクチャの概要（Overview of the security architecture）

図 1 に、3G セキュリティアーキテクチャの全体像を示す。

Homestratum/ServingStratum

USIM HE

TransportstratumME

SN

AN

Applicationstratum

User Application Provider Application(IV)

(III)

(II)

(I)

(I)

(I)

(I)

(I)

図図図図 1: セキュリティアーキテクチャセキュリティアーキテクチャセキュリティアーキテクチャセキュリティアーキテクチャの概要の概要の概要の概要

以下の 5 つのセキュリティフィーチャグループが定義される。各フィーチャグループは、特定の脅威にさらされており、

特定のセキュリティオブジェクトを獲得する。

- Network access security （ネットワークアクセスのセキュリティ）（ネットワークアクセスのセキュリティ）（ネットワークアクセスのセキュリティ）（ネットワークアクセスのセキュリティ）(I): ユーザに 3G のサービスへのセキュアな

アクセスを提供する、セキュリティフィーチャの組み合わせ。一般的には、（無線）アクセスリンク上のアタック

からネットワークを守る。

- Network domain security （ネットワークドメインのセキュリティ）（ネットワークドメインのセキュリティ）（ネットワークドメインのセキュリティ）（ネットワークドメインのセキュリティ）(II): プロバイダのドメイン内のノード間で、シ

グナリングデータをセキュリティで守りつつ交換できるようにする、セキュリティフィーチャの組み合わせ。有線

ネットワーク上のアタックからネットワークを守る。

- User domain security （ユーザドメインのセキュリティ）（ユーザドメインのセキュリティ）（ユーザドメインのセキュリティ）（ユーザドメインのセキュリティ）(III): MS へのアクセスにセキュリティを提供するセキュ

リティフィーチャの組み合わせ。

- Application domain security（アプリケーションドメインのセキュリティ）（アプリケーションドメインのセキュリティ）（アプリケーションドメインのセキュリティ）（アプリケーションドメインのセキュリティ） (IV): ユーザおよびプロバイダドメイン

内のアプリケーションが、メッセージをセキュアに交換できるようにする、セキュリティフィーチャの組み合わせ。

- Visibility and configurability of security （可視的で構成可能なセキュリティ）（可視的で構成可能なセキュリティ）（可視的で構成可能なセキュリティ）（可視的で構成可能なセキュリティ）(V): ユーザが自分自身に対し

て、セキュリティフィーチャが運用中であるか否か、サービスの利用と提供がセキュリティフィーチャに依存す

べきか否かを通知することを可能にする、フィーチャーの組み合わせ。

図 2 に、UMTS の CS サービスドメインと PS サービスドメインにおける、ME の認証とコネクションの原則の概要を示

す。GSM/GPRS における認証と同様に、各サービスドメインでそれぞれ独立して、ユーザの（テンポラリ）識別子、認

証、および鍵合意が実行される。ユーザプレーンのトラフィックは、対応するサービスドメインにおいて合意された暗

号鍵を使用して暗号化され、一方コントロールプレーンのデータは、いずれか１つのサービスドメインから取られた暗

号鍵と完全鍵を使用して暗号化され完全性が保証される。詳細な処理手順については第 6 章で定義されるが、特に

規定されない限り、いずれのサービスドメイン内でも使用される。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)12Release 1999

Two Iu signalling connections (“two RANAP instances”)

UTRAN

3G SGSN

HLR

3G MSC/VLR

UE

CS servicedomain

Two CN service domains

One RRC connection

UTRAN withdistributionfunctionality

PS servicedomain

Common subscription data base

CS state PS state

PS state CS state

CS location PS location

図図図図 2: CN がががが CS サービスドメインサービスドメインサービスドメインサービスドメイン（（（（evolved MSC/VLR とととと 3G_MSC/VLR が主なサービスノード）とが主なサービスノード）とが主なサービスノード）とが主なサービスノード）と PS サービスドメサービスドメサービスドメサービスドメ

インインインイン（（（（evolved SGSN/GGSN、、、、3G_SGSN、、、、3G GGSN が主なサービスノード）から構成される、分離が主なサービスノード）から構成される、分離が主なサービスノード）から構成される、分離が主なサービスノード）から構成される、分離 CN アーキテクアーキテクアーキテクアーキテク

チャの場合の、チャの場合の、チャの場合の、チャの場合の、UMTS 内の内の内の内の ME の認証とコネクション原則の概要（の認証とコネクション原則の概要（の認証とコネクション原則の概要（の認証とコネクション原則の概要（TS 23.121 [4] – 図図図図 4-8 より抜粋）より抜粋）より抜粋）より抜粋）

5 セキュリティフィーチャ（Security features）

5.1 ネットワークアクセスのセキュリティ（Network access security）

5.1.1 ユーザアイデンティティの機密保持（User identity confidentiality）ユーザアイデンティティの機密保持に関連するセキュリティフィーチャとして、以下のようなものがある。

- user identity confidentiality（ユーザアイデンティティの機密保持）（ユーザアイデンティティの機密保持）（ユーザアイデンティティの機密保持）（ユーザアイデンティティの機密保持）: サービスを提供するユーザの恒久的なユ

ーザ識別子（IMSI）が、無線アクセスリンク上で盗聴されないこと。

- user location confidentiality（ユーザ位置の機密保持）（ユーザ位置の機密保持）（ユーザ位置の機密保持）（ユーザ位置の機密保持）: ユーザが特定のエリアに存在すること、あるいは到

着したことが、無線アクセスリンク上で盗聴して特定されないこと。

- user untraceability（ユーザのトレース不可能性）（ユーザのトレース不可能性）（ユーザのトレース不可能性）（ユーザのトレース不可能性）: 同一ユーザに対して複数の異なるサービスが提供されて

いるかどうか、侵入者が無線アクセスリンク上で盗聴して推測できないこと。

これらの特性を満たすために、通常はユーザに対して一時的なアイデンティティが割当てられ、訪問先サービスネッ

トワークはそれを使用してユーザを識別する。ユーザのトレースが可能になると、ユーザのアイデンティティの機密性

が脅かされる恐れがあるので、ユーザを長期間、同一の一時的なアイデンティティで識別してはならない。これらの

セキュリティフィーチャを実現するために、無線アクセスリンク上ではユーザのアイデンティティを露見させる可能性が

ある全てのシグナリングデータまたはユーザデータを暗号化することが要求される。

6.1 節では、一時的なアイデンティティ（これによってユーザを訪問先サービスネットワーク内で特定する）を使用して、

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)13Release 1999

無線パス上でユーザを識別するためのメカニズムについて説明する。このメカニズムは通常、位置登録更新要求、

デタッチ要求、コネクション再確立要求などがあった場合に、無線パス上でユーザを識別するために使用すること。

5.1.2 エンティティの認証（Entity authentication）エンティティの認証に関係するセキュリティフィーチャとしては、以下のようなものがある。

- user authentication（ユーザの（ユーザの（ユーザの（ユーザの認証認証認証認証））））: サービスネットワークがユーザのアイデンティティを確認すること。

- network authentication（ネットワークの（ネットワークの（ネットワークの（ネットワークの認証認証認証認証））））: ユーザの HE によって彼に対してサービスを提供することを

認定されたサービスネットワークに、ユーザが接続されていることを確認すること。この認証には、この認証が

新のものであることの保証も含まれる。

これらの特性を満たすためには、ユーザとネットワークの間でコネクションがセットアップされるたびに、エンティティの

認証が行われることが求められる。これには 2 つのメカニズムが含まれている。すなわち、ユーザの HE がサービス

ネットワークに対して配信する認証ベクトルを使用したメカニズムと、それに先立って実行される認証と鍵確立処理の

中で、ユーザとサービスネットワーク間で確立された完全鍵を使用したローカルな認証メカニズムである。

6.3 節では、上の２つのセキュリティフィーチャを実現するための認証と鍵確立手順について説明し、あわせてユー

ザとサービスネットワーク間で秘密暗号化鍵（5.1.3 参照）と完全鍵（5.1.4 参照）を確立するための手順について説明

する。サービスネットワークにおけるユーザの初の認証後、およびサービス要求、位置登録更新要求、アタッチ要

求、デタッチ要求、またはコネクション再確立要求があった後に、誘導された完全鍵を使用したローカル認証が大

数処理された時に、サービスネットワークよって本メカニズムが起動されること。

6.5 節では、ローカルな認証メカニズムについて説明する。ローカルな認証メカニズムは、セキュリティフィーチャであ

るユーザの認証とネットワークの認証を行い、それに先立って実行される認証と鍵確立処理の中で、ユーザとサービ

スネットワーク間で確立された完全鍵を使用する。サービス要求、位置登録更新要求、アタッチ要求、デタッチ要求ま

たはコネクションの再確立要求の後に、同一の誘導された完全鍵を使用したローカル認証の大数には達しないと

いう条件下で、サービスネットワークによって本メカニズムが起動されること。

5.1.3 機密性（Confidentiality）ネットワークアクセスリンク上のデータの機密性という観点から、以下のセキュリティフィーチャが提供される。

- cipher algorithm agreement（暗号化アルゴリズムの合意）（暗号化アルゴリズムの合意）（暗号化アルゴリズムの合意）（暗号化アルゴリズムの合意）: MS ならびに SN（サービスネットワーク）が、それ

以降使用すべきアルゴリズムを、機密性を保ちながらネゴシエーションできること。

- cipher key agreement（暗号鍵の合意）（暗号鍵の合意）（暗号鍵の合意）（暗号鍵の合意）: MS ならびに SN（サービスネットワーク）が、それ以降使用できる暗

号鍵について合意すること。

- confidentiality of user data（ユーザデータの機密性）（ユーザデータの機密性）（ユーザデータの機密性）（ユーザデータの機密性）: ユーザのデータが無線アクセスリンク上で盗聴されな

いこと。

- confidentiality of signalling data（シグナリングデータの機密性）（シグナリングデータの機密性）（シグナリングデータの機密性）（シグナリングデータの機密性）: シグナリングデータが無線アクセスリンク上

で盗聴できないこと。

暗号鍵の合意は、認証と鍵合意のためのメカニズム（6.3 節参照）を実行する過程で実現される。暗号化アルゴリズ

ムの合意は、ユーザとネットワーク間のセキュリティモードネゴシエーションのメカニズム（6.6.9 節参照）を使用して実

現される。本メカニズムによって、選択された暗号化アルゴリズムと、合意された暗号鍵を 6.6 節で説明された方法で

適用することが可能になる。

5.1.4 データの完全性（Data integrity）無線アクセスリンク上のデータ完全性の観点から、以下のセキュリティフィーチャが提供される。

- integrity algorithm agreement（完全性アルゴリズムの合意）（完全性アルゴリズムの合意）（完全性アルゴリズムの合意）（完全性アルゴリズムの合意）: MS ならびに SN が、それ以降使用すべき完全

性アルゴリズムについて、機密性を保ちながらネゴシエーションできること。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)14Release 1999

- integrity key agreement（完全鍵の合意）（完全鍵の合意）（完全鍵の合意）（完全鍵の合意）: MS ならびに SN が、それ以降使用できる完全鍵について合意す

ること。

- data integrity and origin authentication of signalling data（データの完全性とシグナリングデータの発（データの完全性とシグナリングデータの発（データの完全性とシグナリングデータの発（データの完全性とシグナリングデータの発信元信元信元信元

認証）認証）認証）認証）:送信エンティティ（SN または MS）が送信したシグナリングデータが途中で不正に改竄されていないこと

を、受信エンティティ（MS または SN）側で検証できること。また受信したシグナリングデータの発信元が、本当

に資格を有するものであるかを検証できること。

完全鍵の合意は、認証と鍵合意（6.3 節参照）用メカニズムの実行過程で行われる。完全性アルゴリズムの合意は、

ユーザとネットワーク間のセキュリティモードネゴシエーション用メカニズム（6.6.9 節参照）を使用して実現される。本

メカニズムによって、選択された完全性アルゴリズムと合意された完全鍵を、6.4 節で述べた方法で適用することが

可能になる。

5.1.5 モバイル装置識別子（Mobile equipment identification）特定の条件下では、SN が MS に対して、端末のモバイル装置のアイデンティティを送信するように要求することもで

きる。モバイル装置のアイデンティティの送信は、必ず SN の認証終了後に行うこと。ただし、緊急呼を除く。IMEI は、

端末内に機密性を保ちつつ保存すること。ただし、ネットワークに対する IMEI の存在は、セキュリティフィーチャでは

ないし、IMEI の送信は保護されない。IMEI の存在はセキュリティフィーチャではないが、これ以外の目的に対して

有効なので、UMTS から削除してはならない。

5.2 ネットワークドメインのセキュリティ（Network domain security）

5.2.1 Void

5.2.2 Void

5.2.3 Void

5.2.4 不正情報の収集システム（Fraud information gathering system）注: 3G の MS プロバイダ間で不正情報の交換を迅速に行うためのフィーチャがいくつか提供される。ただ

しそれらは未定義である。

5.3 ユーザドメインのセキュリティ（User domain security）

5.3.1 USIM による User の認証（User-to-USIM authentication）本フィーチャは、USIM によるユーザの認証が終了するまで、USIM へのアクセスを制限するものである。本フィーチ

ャにより、アクセス権限をもったユーザ、あるいは認定された数のユーザだけが USIM にアクセスできるよう、制限す

ることが可能になる。本フィーチャを実現するために、ユーザと USIM は、秘密（例えば PIN など）を共有する必要が

ある。秘密は USIM 内に機密性を保つ方法で保存される。ユーザは、この秘密に関する知識を証明できたときに限

り、USIM へアクセスすることができる。

本セキュリティフィーチャは、TS 31.101 [5]内で説明されるメカニズムを用いて実装される。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)15Release 1999

5.3.2 USIM と端末間のリンク（USIM-Terminal Link）本フィーチャは、端末またはその他のユーザ端末に対するアクセスを、権限のある USIM だけに制限するものである。

本制限を解除するためには、USIM と端末が、USIM および端末内に機密性を保つ方法で保存された秘密を共有し

なくてはならない。 USIM がその秘密に関する知識の証明に失敗した場合には、USIM の端末へのアクセスは拒否

される。

本セキュリティフィーチャは、TS 22.022 [6]で説明されたメカニズムを使用して実装される。

5.4 アプリケーションのセキュリティ（Application security）

5.4.1 USIM とネットワーク間の安全なメッセージ交換（Secure messaging between the USIM and the network）

オペレータまたはサードパーティが、USIM 上で実行されるアプリケーションを作成できるよう、SIM アプリケーション

ツールキットが提供される（GSM における SIM アプリケーションツールキットと類似）。これらは TS 31.111 [15]に規

定される。ネットワークオペレータまたはアプリケーションプロバイダが選択したセキュリティのレベルに応じて、ネット

ワークを経由して USIM 上のアプリケーションに対して送信されるメッセージの機密を保護する必要がある。

USIM アプリケーションツールキットのためのセキュリティフィーチャは、TS 23.048 [7]で説明されるメカニズムを使用

して実装される。これらのメカニズムは、GSM 02.48 [16]で識別されるセキュリティ要求条件に対応する。

5.4.2 Void

5.4.3 Void

5.4.4 Void

5.5 セキュリティの可視性とコンフィギュアビリティ（Security visibility and configurability）

5.5.1 可視性（Visibility）一般的には、セキュリティフィーチャはユーザに対して透過的にすべきであるが、特定のイベントに関しては、ユーザ

の関心度に応じて、ユーザがセキュリティフィーチャの運用をより明確に見えるようにすること。ユーザに対して通知

される、セキュリティ関連のイベントとしては以下のようなものがある。

- アクセスネットワーク暗号化の通知：ユーザに対して、無線アクセスリンク上でユーザデータの機密性が保護

されているか否かを通知すること。典型的な例として、非暗号化呼がセットアップされるときなどがある。

- セキュリティレベルの通知: ユーザに対して、visited ネットワークが提供するセキュリティレベルを通知すること。

典型的な例として、ユーザがセキュリティレベルの低いネットワーク (3G � 2G)にハンドオーバまたはローミン

グした場合が挙げられる。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)16Release 1999

5.5.2 コンフィギュアビリティ（Configurability）コンフィギュアビリティ（Configurability）とは、サービスの使用もしくは監視を、セキュリティフィーチャの運用に依存

するか否かを設定できるようにすることである。全てのセキュリティフィーチャ（セキュリティフィーチャがサービスに関

連し、かつユーザのコンフィギュレーションによる要求があった場合）が運用されている場合に限り、サービスが利用

できる。以下のようなコンフィギュアビリティフィーチャが提唱されている。

- ユーザ～USIM 間認証の有効／無効:ユーザ～USIM 間認証の運用をユーザが制御できること。例えば、いく

つかのイベントについて、サービスまたは使用など

- 非暗号化着信呼の受容／拒否:暗号化されていない着信呼を受け付けるか拒否するか、ユーザが選択でき

ること。

- 非暗号化呼のセットアップ／非セットアップ：ネットワークが暗号化できない場合に、ユーザがコネクションをセ

ットアップするか否かを、ユーザが制御できること。

- 特定の暗号化アルゴリズムの使用の受容／拒否:どの暗号化アルゴリズムを使用するか、ユーザが制御でき

ること。

6 ネットワークアクセスのセキュリティメカニズム（Network access security mechanisms）

6.1 テンポラリ識別子による識別（Identification by temporary identities）

6.1.1 概説（General）本メカニズムは、TMSI/P-TMSI（temporary mobile subscriber identity）を使用した、無線アクセスリンク上のユーザ識

別を可能にするものである。TMSI /P-TMSI は、ユーザが登録されているローカルエリアまたはルーチングエリア内

でのみ有効である。それ以外のエリアにおいては、曖昧さを避けるために、適切な LAI（Location Area Identification ）または RAI（Routing Area Identification ）を併用すること。パーマネントユーザ識別子とテンポラリユ

ーザ識別子との関係は、該当ユーザが登録されている VLR/SGSN （Visited Location Register ）に保管すること。

TMSI/P-TMSI が利用可能な場合には、通常はページング要求、位置登録更新要求、アタッチ要求、サービス要求、

コネクション再確立要求、およびデタッチ要求などに際して、無線アクセスパス上でユーザを識別するために使用さ

れる。

詳細な処理手順とメカニズムについては、GSM 03.20 [8] および TS 23.060 [9]中で説明される。以下の節では、本フ

ィーチャの概要について述べる。

6.1.2 TMSI 再割当処理（TMSI reallocation procedure）本節で説明されるメカニズムの目的は、新しい TMSI/LAI のペアをユーザに対して割当てることによって、無線アク

セスリンク上でユーザを識別できるようにすることにある。

処理は暗号化が開始された後に実行すること。無線パス上の通信の暗号化については、6.6 節で仕様化される。テ

ンポラリ識別子の割当手順を図 3 に示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)17Release 1999

MS VLR/SGSN

TMUI Allocation Complete

TMUI Allocation CommandTMUIn, LAIn

図図図図 3: TMSI の割当の割当の割当の割当

テンポラリ識別子の割当は、VLR が開始する。

VLR は新しいテンポラリ識別子 (TMSIn)を生成し、TMSIn とパーマネント識別子 IMSI との関係を自身のデータベ

ース内に格納する。そして VLR は、TMSIn と（必要に応じて）新しい LAI（location area identity）をユーザに送信する。

ユーザは TMSIn を受信したら、前回自分に割当てられた TMSI との関連を全て自動的に解除する。ユーザは VLRに送達確認（acknowledgement）を送信する。

VLR は送達確認（acknowledgement）を受信したならば、（もしあれば）古いテンポラリ識別子 TMSIo と IMSI との関

係を自身のデータベースから削除する。

6.1.3 テンポラリ識別子の非送達確認割当 (Unacknowledged allocation of a temporary identity)

サービスネットワークがユーザから、テンポラリ識別子が正しく割当てられたことの送達確認を受信しなかった場合

には、ネットワークは新しいテンポラリ識別子 TMSIn と IMSI の関係、（そしてもしあれば）古いテンポラリ識別子 TMSIo と IMSI との関係を維持すること。

ユーザ発信のトランザクションに関しては、ネットワークはユーザに対して、ユーザが自分自身を古いテンポラリ識別

子 TMSIo でも、新しいテンポラリ識別子 TMSIn でも識別できるように許可すること。そうすることによって、ネットワ

ークは MS に保存されているテンポラリ識別子を決定することができる。続いてネットワークは、他のテンポラリ識別

子と IMSI との関係を削除し、テンポラリ識別子を別のユーザに割当てることができるようにすること。

ネットワーク発信のトランザクションに関しては、ネットワークはユーザをそのパーマネント識別子 (IMSI)を使って識

別すること。無線コンタクトが確立されたならば、ネットワークはユーザに対して、保存されている全ての TMSI を削

除するように指示すること。ネットワークがユーザから送達確認を受信したならば、ネットワークは IMSI と全ての

TMSI との関係を削除し、テンポラリ識別子を開放して他のユーザに割当てられるようにすること。

ユーザ発信、ネットワーク発信いずれの場合でも、その後ネットワークは通常の TMSI 割当処理を開始することがで

きるようになる。

TMSI 割当処理のエラーが（オペレータの設定された回数以上）繰り返し起きた場合には、O&M アクションにレポー

トすることができる。

6.1.4 位置更新（Location update）ユーザが自分自身を visited VLRn によって割当てられた TMSIo/LAIo のペアを使用して識別する場合には、通常

は IMSI をデータベースから抽出できる。それ以外の場合には､visited VLRn はユーザに対して、自分自身をパーマ

ネントユーザ識別子を使って識別するよう、要求すること。本メカニズムについては、6.2 節で説明する。

ユーザが自分自身を visited VLRn によって割当てられたものではない TMSIo/LAIo のペアを使用して識別する場

合には、visited VLRn と以前の visited VLRo は認証データを交換し、visited VLRn は前の visited VLRo に対してパ

ーマネントユーザ識別子を送信するよう要求すること。本メカニズムについては、6.3.4 節で説明されるが、このメカニ

ズムは複数 VLR 間の認証データの配布メカニズムに統合される。以前の visited VLRo にコンタクトできない場合、

もしくはユーザ識別子を抽出できない場合には、visited VLRn はユーザに対して、自分自身をそのパーマネント識別

子を使用して識別するよう、要求すること。本メカニズムについては、6.2 節で説明する。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)18Release 1999

6.2 パーマネント識別子による識別（Identification by a permanent identity）

ここで説明するメカニズムによって、無線パス上で IMSI を使用してユーザを識別することが可能になる。

テンポラリ識別子を使用してユーザを識別できない場合にはいつでも、サービスネットワークはこのメカニズムを起動

すること。このメカニズムが使用される典型的な例として、サービスネットワーク内でユーザが初めて登録される場合、

あるいはサービスネットワークが、無線パス上でユーザが自分自身を識別するために使用する IMSI を抽出できな

い場合などがある。

図 4 にそのメカニズムを示す。

ME/USIM VLR/SGSN

User identity responseIMSI

User identity request

図図図図 4: パーマネント識別子パーマネント識別子パーマネント識別子パーマネント識別子による識別による識別による識別による識別

visited VLR/SGSN がユーザに対してそのパーマネント識別子を送信するよう要求した場合に、本メカニズムが開始

される。ユーザの応答中の平文内には IMSI が含まれる。本処理はユーザ ID の機密保持という観点から見ると規

約違反である。

6.3 認証と鍵の合意（Authentication and key agreement）

6.3.1 概要（General）ここで説明するメカニズムによって、ユーザとネットワークが、互いに共有する秘密鍵 K に関する知識を互いに示す

ことによって相互認証を行うことが可能になる。秘密鍵 K は、USIM とユーザの HE 内の AuC に対してのみ有効で

ある。さらに、 USIM と HE は、カウンタ SQNMS と SQNHE をそれぞれ記録し、ネットワーク認証をサポートする。シー

ケンス番号 SQNHE はユーザ毎に独立したカウンタであり、シーケンス番号 SQNMS は USIM が受け付けた上位シ

ーケンス番号を表す。

現行の GSM セキュリティアーキテクチャと、GSM から UMTS への装置マイグレーションを考慮し､も互換性の高

い手段で実現するために、この方法が選択された。この方法は、GSM の加入者認証方法と同じ challenge/response プロトコルと、ISO/IEC 9798-4 [10] (5.1.1 節)で規定されるネットワーク認証用のシーケンス番号ベースの one-pass プロトコルと組み合わされた鍵確立プロトコルから構成される。

メカニズムの概要を、図 5 に示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)19Release 1999

MS VLR/SGSN HE/HLR

Generate authenticationvectors AV(1..n)

Store authentication vectors

Select authentication vector AV(i)

Authentication data request

Authentication data responseAV(1..n)

User authentication requestRAND(i) || AUTN(i)

User authentication responseRES(i)

Compare RES(i) and XRES(i)

Verify AUTN(i)Compute RES(i)

Compute CK(i) and IK(i) Select CK(i) and IK(i)

Authentication andkey establishment

Distribution ofauthenticationvectors from HEto SN

図図図図 5: 認証認証認証認証と鍵の合意と鍵の合意と鍵の合意と鍵の合意

VLR/SGSN から要求を受信すると、HE/AuC は n 個の順列の認証ベクトル (GSM のトリプレットに相当)をVLR/SGSN に送信する。認証ベクトルはシーケンス番号順に並べられる。それぞれの認証ベクトルは、以下のコン

ポーネントから構成される。すなわち、乱数 RAND、予想応答 XRES、暗号鍵 CK、完全鍵 IK、そして認証トークン AUTN である。それぞれの認証ベクトルは、1 回の認証と VLR/SGSN ～USIM 間の鍵合意についてのみ有効であ

る。

VLR/SGSN は、認証と鍵合意を開始すると、順列から次の認証ベクトルを選択し、ユーザにパラメータ RAND と

AUTN を送信する。特定のノード内では、認証ベクトルは first-in / first-out ベースで使用される。USIM は、AUTN が

受入れ可能か否かをチェックし、受入れ可能であれば応答 RES を生成して VLR/SGSN に送り返す。USIM はまた、

CK と IK を計算する。 VLR/SGSN 側では、受信した RES を XRES と比較する。両者が一致したならば、VLR/SGSN は認証と鍵合意合意が正常に完了したものとみなす。確立された鍵 CK および IK は、続いて USIM と VLR/SGSNによって、暗号化と完全性機能を実行するエンティティに対して送信される。

VLR/SGSN は、たとえ HE/AuC リンクが利用不可能であっても、それらのリンクに前回誘導された該当ユーザ用の

暗号鍵と完全鍵の使用を許可することによって、認証と鍵合意の必要なしに機密保護されたコネクションをセットアッ

プすることができるので、ユーザに機密保護されたサービスを提供することができる。この場合の認証は、シグナリン

グメッセージのデータ完全性を保護することによって、共有された完全鍵に基づいて行われる（6.4 節参照）。

認証機関は、ユーザの HE の AuC(HE/AuC) 、かつユーザの移動端末内に入れられる USIM の AuC であること。メ

カニズムは以下の処理手順から構成される。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)20Release 1999

認証情報を HE/AuC から VLR/SGSN に配布するための処理手順。本処理手順は、6.3.2 節で説明される。

VLR/SGSN は、ユーザの HE から、認証情報をセキュリティ保ちつつ処理できると信頼されているものと仮定する。システム内の VLR/SGSN ～HE/AuC 間のリンクもまた、十分にセキュリティ保護されているものと仮定する。さらに、

ユーザが HE を信頼しているものと仮定する。

VLR/SGSN と MS が、相互に認証し、新しい暗号・完全鍵を確立するための処理手順。本処理手順については、 6.3.3 節で説明される。

前の visited VLR から新しい visited VLR に認証データを配布するための処理手順。本処理手順については、 6.3.4節で説明される。VLR/SGSN 間のリンクもまた、十分にセキュリティ保護されているものと仮定する。

6.3.2 HE から SN に対する認証データの配布（Distribution of authentication data from HE to SN）

本処理手順の目的は、ユーザの HE から新しい認証ベクトルの行列を VLR/SGSN に提供し、複数のユーザ認証を

実行することにある。

VLR/SGSN HE

Authentication data requestIMSI

Authentication data responseAV(1..n)

図図図図 6: HE からからからから VLR/SGSN への認証データの配布への認証データの配布への認証データの配布への認証データの配布

VLR/SGSN が HE/AuC に対して認証ベクトルを要求して、処理手順を起動する。

authentication data request には、IMSI が含まれること。

VLR/SGSN から authentication data request を受信すると、HE は予め要求された認証ベクトルの数を計算し、それ

らを HLR データベースから抽出することもできるし、あるいは要求に応じて計算することもできる。HE/AuC は

VLR/SGSN に認証応答を送信する。その中には、順番に並んだ n 個の配列の認証ベクトル AV(1～n)が含まれる。

認証ベクトルはシーケンス番号順に並べられる。

図 7 に、HE/AuC における認証ベクトル AV の生成ダイヤグラムを示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)21Release 1999

K

SQNRAND

f1 f2 f3 f4 f5

MAC XRES CK IK AK

AUTN := SQN ⊕ AK || AMF || MAC

AV := RAND || XRES || CK || IK || AUTN

Generate SQN

Generate RAND

AMF

図図図図 7: 認証ベクトル認証ベクトル認証ベクトル認証ベクトルの生成の生成の生成の生成

HE/AuC は、フレッシュなシーケンス番号 SQN と、予測不可能なランダムチャレンジ RAND の生成を開始する。

HE/AuC は、ユーザ毎にカウンタ SQNHEを記録する。

HE は、シーケンス番号の管理において若干フレキシブルであるが、いくつかの要求条件は使用されるメカニズムに

よって決まる条件を満たす必要がある。すなわち、

a) 生成メカニズムは、HE 内の再同期処理（6.3.5 節で説明）を許容すること。

b) SQN からユーザの識別子および位置が漏れる可能性がある場合には、匿名鍵として AK を使用し、その中

に SQN を秘匿することもできる。

c) 生成メカニズムは、 USIM 内のカウンタの周回に対する保護ができること。これを実現する方法については、informative Annex C.2 で述べる。

USIM 内のシーケンス番号の新鮮度を検証するためのメカニズムには、順序が外れたシーケンス番号の使用につい

て若干の自由度を許容すること。そうすることによって、同期エラーによる認証失敗率を十分低く抑えることが可能に

なる。そのためには、USIM が過去の成功した認証イベント（例えば、シーケンス番号やそれに関する部分など）に関

する情報を保存する能力を備える必要がある。メカニズムは、シーケンス番号が後の x = 32 の生成されたシーケ

ンス番号として受け入れることができるか否かを保証すること。これは、シーケンス番号を、シーケンス番号のための

時間ベースの age に関する制約などのその他の理由によって拒否することを排除するものではない。さまざまな使用シナリオ下で、同期失敗率を十分低く抑えるために、システム内で同じような小数 x が必要になる。

その典型的な例が、CS サービスドメインと PS サービスドメイン内で同時に認証を行う際に、認証情報を交換しない

複数の VLR/SGSN 間、スーパー課金ネットワーク間をユーザが移動する場合である。

SQNHE の用途は、シーケンス番号生成方法によって異なる。新鮮なシーケンス番号を生成する方法については、 Annex C.1 で規定する。シーケンス番号の新鮮度を検証するための方法については、Annex C.2 で規定する。

認証および鍵管理フィールドである AMF は、各認証ベクトルの認証トークン内に含まれる。本フィールドの使用例を

Annex F に示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)22Release 1999

続いて以下の値が算出される。

- メッセージ認証コード MAC = f1K(SQN || RAND || AMF)、ここで f1 はメッセージ認証関数;

- 予想応答 XRES = f2K (RAND) 、ここで f2 はメッセージ認証関数（省略も可能）;

- 暗号鍵 CK = f3K (RAND)、ここで f3 は鍵生成関数;

- 完全鍵 IK = f4K (RAND)、ここで f4 は鍵生成関数;

- 匿名鍵 AK = f5K (RAND)、ここで f5 は鍵生成関数または f5 ≡ 0

終的に、認証トークン AUTN が、AUTN = SQN ⊕ AK || AMF || MAC で算出される。

ここで、AK はシーケンス番号を秘匿するために使用される匿名鍵である。匿名鍵を使用する理由は、文字列だとユ

ーザのアイデンティティまたは位置を推測される可能性があるからである。シーケンス番号の秘匿は、受動的なアタ

ックからの保護にのみ有効である。秘匿の必要がない場合には、f5 ≡ 0 (AK = 0)とする。

6.3.3 認証と鍵の合意（Authentication and key agreement）本処理の目的は、ユーザを認証し、新しい暗号鍵と完全鍵のペアを、VLR/SGSN と USIM 間で確立することにある。

認証の間、USIM は使用された認証ベクトルの新鮮度を検証する。

USIM VLR/SGSN

User authentication requestRAND || AUTN

User authentication responseRES

User authentication rejectCAUSE

図図図図 8: 認証認証認証認証と鍵の確立と鍵の確立と鍵の確立と鍵の確立

VLR/SGSN は、VLR/SGSN のデータベース内の認証ベクトルの順番の配列から、未使用の次の認証ベクトルを選

択し、処理を起動する。特定ノード内の認証ベクトルは、first-in / first-out ベースで使用される。VLR/SGSN は、選択

した認証ベクトルから、ランダムチャレンジ RAND と、ネットワーク認証 AUTN 用の認証トークンを送信する。

ユーザの受け付けに関する処理を、図 9 に示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)23Release 1999

KSQN

RAND

f1 f2 f3 f4

f5

XMAC RES CK IK

AK

SQN ⊕ AK AMF MAC

AUTN

Verify MAC = XMAC

Verify that SQN is in the correct range

⊕

図図図図 9: USIM 内のユーザ内のユーザ内のユーザ内のユーザ認証認証認証認証機能機能機能機能

RAND と AUTN を受信すると、USIM はまず匿名鍵 AK = f5K (RAND) を算出し、シーケンス番号 SQN = (SQN ⊕ AK) ⊕ AK を抽出する。

次に USIM は、XMAC = f1K (SQN || RAND || AMF) を計算し、それを AUTN 内の MAC と比較する。両者が異なる

場合には、ユーザは user authentication reject を理由の通知とともに VLR/SGSN に返し、ユーザは処理を中断する。

この場合には、VLR/SGSN は 6.3.6 節に規定されているように、HLR に対して Authentication Failure Report 処理を

開始する。VLR/SGSN はまた、新たな識別認証処理をユーザに対して開始するか否か決定することもできる。

次に、USIM は受信したシーケンス番号 SQN が正しい範囲内にあることを検証する。

USIM がシーケンス番号が正しい範囲内にないと判断した場合には、USIM は適切なパラメータを含む

synchronisation failure を VLR/SGSN に返し、処理を中断する。

同期失敗メッセージには、パラメータ AUTS が含まれる。ここで、 AUTS = Conc(SQNMS ) || MAC-S である。 Conc(SQNMS) = SQNMS ⊕ f5*K(RAND) は MS 内のカウンタ SQNMS の秘匿値であり、 MAC-S = f1*K(SQNMS || RAND || AMF) ここで RAND は現行のユーザ認証要求において受信した乱数値である。 f1* はメッセージ認証コード (MAC)の関

数であり、 f1, ～ , f5, f5* の関数 f1* の関数値から数値情報を推測できないという特性を持つ。逆もまた真である。

f5* は、再同期処理における AK 値の算出に使用される鍵生成関数であり、f1, f1*, f2, ～, f5 に関する f5* の関数

値から数値情報を推測できないという特性を持つ。逆もまた真である。

MAC-S を算出するために使用される AMF は、全て 0 のダミー値であると仮定されるので、再同期メッセージ中で明

示して送信される必要がない。

パラメータ AUTS の構成を、下図 10 に示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)24Release 1999

RAND

SQNMS

K

AUTS = SQNMS ⊕ AK || MA C-S

AMF

f1* f5*

MAC-S AK SQNMS ⊕ AK

xor

図図図図 10: パラメータパラメータパラメータパラメータ AUTS の構成の構成の構成の構成

シーケンス番号が正しい値の範囲内にあると判断されたならば、USIM は RES = f2K (RAND) を計算し、user authentication response 中に本パラメータを入れて VLR/SGSN に送り返す。後に USIM は、暗号鍵 CK = f3K (RAND) と完全鍵 IK = f4K (RAND)を計算する。どんな場合でも、RAND 値を受信したらすぐに RES, CK および IKを計算したほうが効果的であることに注意。USIM が変換関数 c3 もサポートしている場合には、USIM は UMTS の

暗号／完全鍵 CK と IK から GSM の暗号鍵 Kc を抽出すること。UMTS と GSM をインターオペレーションするため

に、UMTS の鍵は抽出された GSM 鍵といっしょに MS に送信される。USIM は元の CK, IK を、次回 AKA の実行

が成功するまで保持すること。

user authentication response を受信すると、VLR/SGSN は選択された認証ベクトルから想定される予想応答 XRESと RES を比較する。XRES＝RES の場合には、ユーザの認証は合格とされる。VLR/SGSN もまた、選択された認証

ベクトルから、適切な暗号鍵 CK と完全鍵 IK を選択する。XRES≠RES の場合には、VLR/SGSN は 6.3.6 節に規定

されるように、HLR に対する Authentication Failure Report 処理を開始すること。VLR/SGSN もまた、ユーザに対する

新しい識別と認証処理の開始を決定することができる。

(RAND, AUTN)の再利用と再送（の再利用と再送（の再利用と再送（の再利用と再送（Re-use and re-transmission of (RAND, AUTN)））））

USIM による SQN の検証は、VLR/SGSN が特定の UMTS セキュリティコンテキストを複数回確立するためにクイン

テットを再利用しようとするのを、MS が拒否する原因となりうる。であるから、一般的に VLR/SGSN はクインテットを

1 回だけ使用すること。

ただし、1 つだけ例外がある。すなわち、VLR/SGSN が特定のクインテットを使用して authentication request を送信

したのにもかかわらず、MS から応答メッセージ(authentication response または authentication reject)を受信しなかっ

た場合には、VLR/SGSN は同一クインテットを使用して authentication request を再送することができる。しかし、応

答メッセージが到達したならば、それ以上再送することは許可されない。初の送信要求後、または複数回の再送

要求の後、何も応答がなかったならば、再送を中断できる。再送が中止された場合には、VLR/SGSN はクインテット

を削除すること。MS 側では、追加の再同期処理なしで再送できるように、USIM は関連する RES といっしょにも新

しい(RAND, AUTN)のペアを保存すること。USIM が authentication request を受信し、(RAND, AUTN)のペアの値

が前回の値と同じであり、かつ関連する START パラメータが 0 であった場合には、USIM は応答を再送すること。

ME によって START パラメータが更新されたならば、USIM は直ちに保存されている (RAND, AUTN) のペアと関連

する RES を削除すること（6.4.8 節参照）。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)25Release 1999

6.3.4 同一サービスネットワークドメイン内の IMSI とテンポラリ認証データの配

布（Distribution of IMSI and temporary authentication data within one serving network domain）

本処理の目的は、visited VLR/SGSN が同一サービスネットワークドメインに属する場合に、前の visited VLR/SGSNから新しい visited VLR/SGSN にテンポラリ認証データを提供することにある。

処理手順を図 11 に示す。

VLRn/SGSNn VLRo/SGSNo

(TMSIo || LAIo)or (P-TMSIo || RAIo)

IMSI || ({Qi} or {Ti}) ||((CK || IK || KSI) or (Kc || CKSN))

図 11: 同一サービスネットワークドメイン内の IMSI とテンポラリ認証データの配布

新しい visited VLRn/SGSNn が、ユーザから位置登録更新要求 (ルーチングエリア更新要求に対応) を受信すると、

処理が起動される。新しい visited VLRn/SGSNn におけるユーザの識別は、TMSIo(P-TMSIo に対応) および LAIo (ルーチングエリア識別子 RAIo に対応)を使用して行われ、新しい visited VLRn/SGSNn と同じサービスネットワーク

ドメインに属する前の visited VLRo/SGSNo の支配下にある。

プロトコルステップは以下の通り。

a) VLRn/SGSNn が VLRo/SGSNo に user identity request を送信。本メッセージには TMSIo および LAIo (P-TMSIo および RAIo に対応)が含まれる。

b) VLRo/SGSNo はデータベース内のユーザデータをサーチする。

ユーザが見つかった場合には、VLRo/SGSNo は user identity response を返送すること。これは、

i) IMSI が含まれること

ii) first-in / first-out ベースで順番付けされた未使用の認証ベクトル（クインテットまたはトリプレット）の数が

含まれることもある

iii) 現行のセキュリティコンテキストデータ：CK, IK と KSI (UMTS) または Kc と CKSN (GSM)が含まれること

もある

続いて VLRo/SGSNo は、送信された認証ベクトルと、現行のセキュリティコンテキスト上のデータエレメントを

削除する。

ユーザを識別できなかった場合、VLRo/SGSNo は user identity response を送信し、ユーザアイデンティティ

が抽出できなかったことを通知する。

c)VLRn/SGSNn が IMSI といっしょに user identity response を受信した場合、VLRn/SGSNn はエントリを作成し、

現行のセキュリティコンテキストデータ上に含まれている可能性のある任意の認証ベクトルと任意のデータを

保存する。

VLRn/SGSNn が、ユーザ識別不能を通知する user identity response を受信した場合、6.2 節で述べた手順

に従ってユーザ識別処理を開始すること。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)26Release 1999

6.3.5 再同期処理（Re-synchronisation procedure） VLR/SGSN は、HE/AuC に対して 2 タイプの authentication data request を送信することができる。つまり、6.3.2 で説

明された（レギュラー、regular）タイプと、本節で説明される同期が失敗した場合に使用されるタイプである。

ユーザから synchronisation failure メッセージを受信した場合、VLR/SGSN は HE/AuC に対して "synchronisation failure indication" といっしょに authentication data request を以下のパラメータとともに送信する。

- RAND 、ユーザ認証要求処理の前に MS に送信される

- AUTS 、その要求に対する応答内で VLR/SGSN が受信。6.3.3 節で説明

MS からの余分なメッセージ "synchronisation failure indication" に対しては、VLR/SGSN は応答しない。

VLR/SGSN は、自身の認証データ要求に対する応答を HE/AuC から受信するまで（または要求がタイムアウトする

まで）は、新たにユーザ認証要求を送信しない。

HE/AuC が"synchronisation failure indication" といっしょに authentication data request を受信した場合、以下のアク

ションをとる。

1. HE/AuC は f5K(RAND)を算出し、Conc(SQNMS) から SQNMS を抽出する

2. HE/AuC は SQNHE が正しい範囲内にあることをチェックする。つまり SQNHE を使用して生成した次のシーケ

ンス番号が、USIM が受理できるか否かをチェックする。

3. SQNHE が正しい範囲内にある場合には、HE/AuC はステップ (6)に進み、正しい範囲内にない場合にはステッ

プ(4)に進む。

4. HE/AuC は AUTS 値を検証する（6.3.3 節参照）。

5. 検証が成功したならば、HE/AuC はカウンタ SQNHE の値を SQNMS. にリセットする

6.HE/AuC は、VLR/SGSN に認証ベクトルの新しいバッチといっしょに authentication data response を送信する。

カウンタ SQNHE がリセットされていない場合には、これらの認証ベクトルをストレージから取り出すか、あるい

は SQNHE をリセット後に新たに生成することができる。HE/AuC の負荷となるリアルタイムの計算を削減する

ために、後のケースでは HE/AuC もまた単一の認証ベクトルだけを送信することもできる。

認証データ要求に対する認証データ応答中で、VLR/SGSN が同期失敗の通知と共に HE/AuC から認証ベクトルの新しいバッチを受信した場合にはいつでも、VLR/SGSN は VLR/SGSN 中の該当ユーザ用の古いデータを削除する。

この場合、HE/AuC から受信した新しい認証ベクトルに基づいてユーザを認証することはできない。図 12 に、

synchronisation failure メッセージによって応答される user authentication 要求（6.3.3 節で説明）と、authentication data response によって応答される synchronisation failure 通知（本節で説明）を組み合わせて、再同期を行う方法を

示す。

UE/USIM VLR/SGSN HLR/AuC

RAND, AUTN

AUTS

RAND, AUTS

{Qi}

図図図図 12: 再同期のメカニズム再同期のメカニズム再同期のメカニズム再同期のメカニズム

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)27Release 1999

6.3.6 SGSN/VLR から HLR に対する認証失敗のレポート（Reporting authentication failures from the SGSN/VLR to the HLR）

本処理の目的は、サービス環境からホーム環境に戻る際の認証の失敗をレポートするメカニズムを提供することに

ある。

処理手順を図 13 に示す。

VLR/SGSN HLR

Authentication failure report(IMSI and FailureCause)

図図図図 13: VLR/SGSN からからからから HLR に対する認証失敗のレポートに対する認証失敗のレポートに対する認証失敗のレポートに対する認証失敗のレポート

認証処理が失敗した場合に、サービスネットワークの VLR/SGSN が本処理を起動する。Authentication Failure Report 中には、加入者識別子と失敗理由のコードが含まれること。考えられる認証の失敗理由としては、ネットワー

クの署名が間違っていた場合、あるいはユーザの応答が間違っていた場合、などが考えられる。

HE は、Authentication Failure Report を受信した後、ユーザの割当て（location）をキャンセルするか否か、決定する

ことができる。

6.3.7 認証パラメータの長さ（Length of authentication parameters）認証 key (K)は 128 ビット長とする。

ランダムチャレンジ(RAND) は 128 ビット長とする。

シーケンス番号(SQN) は 48 ビット長とする。

匿名鍵 (AK) は 48 ビット長とする。

認証管理フィールド(AMF) は 16 ビット長とする。

AUTN 中のメッセージ認証コード MAC と、AUTS 中の MAC-S は 64 ビット長とする。

暗号鍵 (CK) は 128 ビット長とする。

完全鍵 (IK) は 128 ビット長とする。

認証応答 (RES) は可変長であり、32～128 ビット長とする。

6.4 ローカルな認証とコネクションの確立（Local authentication and connection establishment）

ローカルな認証は、完全性保護機能によって可能になる。

6.4.1 暗号鍵と完全鍵の設定（Cipher key and integrity key setting）認証と鍵の設定は、6.3 節に説明されるように、認証処理によってトリガされる。認証と鍵の設定開始条件は、ネット

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)28Release 1999

ワークオペレータが設定できる。VLR/SGSN がモバイル加入者（つまり P-TMSI, TMSI または IMSI）を識別したら直

ちに、鍵の設定を行うことができる。CK と IK は、VLR/SGSN 内に保存され、必要に応じて RNC に送信される。CSドメイン用の CK と IK は、USIM 上に保存され、CS ドメイン内で次回認証が行われた時に更新される。PS ドメイン用

の CK と IK は、USIM 上に保存され、PS ドメイン内で次回認証が行われた時に更新される。

（PS または CS モードの）コネクションの間に認証処理が実行された場合には、認証処理後のセキュリティモードの設

定処理（6.4.5 節参照）の一部として、RNC と ME 双方で新しい暗号鍵 CK と完全鍵 IK を使用すること。

6.4.2 暗号化と完全性モードのネゴシエーション（Ciphering and integrity mode negotiation）

MS がネットワークとコネクション確立を行う場合には、MS/USIM クラスマーク中でネットワークに対して、MS がどの

暗号化アルゴリズムと完全性アルゴリズムをサポートするか、通知すること。本処理自体も完全性の保護がされる必

要がある。RNC が完全鍵 IK を持たない場合があるので、MS/USIM クラスマーク受信時には本情報を RNC 内に

も保存する必要がある。セキュリティモードのセットアップ時には、も新しく生成された IK を使用することによって、

クラスマークのデータ完全性が実行される（6.4.5 節参照）。

ネットワークは、自身の完全性保護能力とパフォーマンス、そして MS 加入者の特別な要求条件の全てを、MS が通

知した要求条件と比較すること。そして、以下の原則に従ってアクションを取ること。すなわち、

1) MS とネットワークの UIA アルゴリズムのバージョンが異なる場合、コネクションを解放すること。

2) MS とネットワークが、少なくとも 1 つ、UIA アルゴリズムのバージョンを共有する場合、ネットワークは該当コ

ネクション上で使用される UIA アルゴリズムから、相互受け入れ可能なバージョンを選択すること。

ネットワークは、自身の暗号化能力とパフォーマンス、そして MS 加入者の特別な要求条件の全てを、MS が通知し

た要求条件と比較すること。そして、以下の原則に従ってアクションを取ること。すなわち、

1) MS とネットワークの UEA アルゴリズムのバージョンが異なり、かつネットワークが非暗号化コネクションを使

用する準備が整っていない場合、コネクションを解放すること。

2) MS とネットワークの UEA アルゴリズムのバージョンが異なり、かつユーザ (ユーザの HE ごとに)とネットワー

クが非暗号化コネクションを確立する準備が整っている場合には、非暗号化コネクションを使用すること。

3) MS とネットワークが、少なくとも 1 つ、UEA アルゴリズムのバージョンを共有する場合、ネットワークはそのコ

ネクションのために、UEA アルゴリズムから相互受け入れ可能なバージョンを 1 つ選択すること。

CS サービスと PS サービスとでは、モビリティ管理が分離されているので、1 つの CN ドメインは他の CN からは独立

して、全く同一の MS に対してコネクションを確立することができる。MS から CN への二番目のコネクションの確立に

際しては、暗号化と完全性のモード（アルゴリズム）の変更を許可してはならない。暗号化と完全性のモード設定のた

めの選択と特別な要求条件（例えばアルゴリズム選択の順序など）は、双方のドメインで共通とすること。

6.4.3 暗号鍵と完全鍵の寿命（Cipher key and integrity key lifetime）暗号／完全鍵を生成するための認証と鍵の合意は、呼のセットアップ時には必須ではないので、妥協した鍵を悪者

によって無制限に再利用される可能性がある。妥協した鍵を使ったアタックを防ぐために、特定の暗号／完全鍵の組み合わせを、一定の制限時間以上は使用できないようにするためのメカニズムが必要である。そのために、USIMは、アクセスリンクの鍵の組み合わせによって保護されるデータの量を制限するためのメカニズムを備えること。

RRC コネクションが解放されるたびに、その RRC コネクション内で保護されていたベアラの STARTCS と STARTPS の値は USIM 内に保存される。次回 RRC コネクション確立時には、それらの値が USIM から読み出される。

STARTCS または STARTPSの値がオペレータによって設定された大値に達した場合には、ME は新しいアクセスリ

ンクの鍵の組み合わせ（暗号鍵と完全鍵）の生成をトリガし、次回 RRC コネクション確立要求メッセージ送信に

USIM 内に保存すること。値が大値に達した場合には、USIM 上に保存された暗号鍵と完全鍵を削除すること。

本メカニズムによって、オペレータが設定した鍵の使用期間以上、暗号／完全鍵の組み合わせが再利用されること

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)29Release 1999

を防ぐことができる。

6.4.4 暗号鍵と完全鍵の識別（Cipher key and integrity key identification） KSI（key set identifier）は、認証期間中に引き出される暗号鍵と完全鍵に関連付けられた数である。KSI は、ネットワ

ークによって割当てられ、MS に対して認証要求メッセージといっしょに送信される。KSI は、MS 内では計算された暗

号鍵 CK と完全鍵 IK といっしょに保存される。UMTS における KSI は、GSM における CKSN に相当する。USIM は、

PS ドメインの鍵の組み合わせ用に 1 つの KSI/CKSN を、CS ドメインの鍵の組み合わせ用に 1 つの KSI/CKSN を保

存する。

KSI を使用する目的は、ネットワークが MS 内に保存されている暗号鍵 CK と完全鍵 IK を、認証処理を起動せずに

識別することを可能にすることにある。次回以降のコネクションのセットアップにおいて、暗号鍵 CK と完全鍵 IK を再

使用できるように、KSI を使用する。

KSI と CKSN のフォーマットは同一である。KSI は 3 ビット長である。鍵の組み合わせを識別するために、7 通りの値

が使用される。値 '111' は、有効な鍵が利用不可能であることを通知するために MS が使用する。暗号鍵と完全鍵を

削除する際には、KSI は値 '111'に設定される。ネットワークから MS に対する方向においては、値 '111'は予約済。

6.4.5 セキュリティモードのセットアップ手順（Security mode set-up procedure）

本節では、暗号化と完全性保護のセットアップ双方に共通の手順について説明する。MS と VLR/SGSN 間で新しく

シグナリングコネクションを確立する場合、本処理を使用したシグナリングメッセージの完全性保護は mandatoryである。ただし、以下の 4 つのケースについては、完全性保護の開始は mandatory ではない。

- シグナリングコネクションの確立の目的とその結果が、定期的な位置登録更新である場合。つまり、認証情報

に変更がない場合。

- MS から VLR/SGSN に L3 のシグナリングメッセージが送信された後、MS～VLR/SGSN 間のシグナリングが

ない場合。つまり、コネクション解放後、MS から deactivation 通知が送信された場合。

- MS から VLR/SGSN に初の L3 シグナリングメッセージが送信されて、（もしあれば）ユーザ識別要求と認

証（下記参照）が行われた後のシグナリングが、reject signalling メッセージだけでその後コネクションが解放さ

れる場合。

- 呼が TS 22.003 で規定される緊急呼テレサービスであった場合。6.4.9.2 節参照。

完全性保護を開始すべき場合には、初期コネクション要求（つまり VLR/SGSN に送信される初期 L3 メッセージ）の

後､セキュリティモードのセットアップが開始されるまで MS と VLR/SGSN 間で許容される処理は、以下の 2 つだけで

ある。

- パーマネント識別子 (つまり IMSI の要求)による識別

- 認証と鍵の合意

次のメッセージシーケンスフローは、初期コネクション確立時に送信される情報と、可能な認証、そして完全性保護

と可能な暗号化の開始について説明したものである。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)30Release 1999

MS

2. “Initial L3 message” with user identity, KSI etc.

VLR/SGSN

3. Authentication and key generation

1. Storage of HFNs START values and UE security capability

4 Decide allowed UIAs and UEAs

SRNC

1. RRC connection establishment includingtransfer of the HFNs START values and theUE security capability from MS to SRNC

5. Security mode command (UIAs, IK, UEAs, CK, etc.)

6. Select UIA and UEA, generate FRESHStart integrity

7. Security mode command (CN domain, UIA, FRESH,UE security capability, UEA, MAC-I, etc.)

10. Verify received message

9. Security mode complete (MAC-I, etc.)

11. Security mode complete (selected UEA and UIA)

8. Control of UE security capability, Verifymessage, Start of integrity

“UE security capability” indicates UIAs and UEAs supported by MS

Start ciphering/deciphering Start ciphering/deciphering

図図図図 14: ローカルローカルローカルローカル認証認証認証認証とコネクションのセットアップとコネクションのセットアップとコネクションのセットアップとコネクションのセットアップ

注 1: ネットワークは、完全性保護を開始する前に、ME セキュリティケーパビリティ（"ME security capability"）情報を持つ必要がある。つまり、ME セキュリティケーパビリティをネットワークに対して、保

護されていないメッセージ中に入れて送信する必要がある。その後、保護されたメッセージ中で ME に ME セキュリティケーパビリティを返すことによって、ME はネットワークに到達した ME セキュリティケー

パビリティが正しいか否かを検証することができるようになる。

上図フローを詳細に説明すると、

1. RRC コネクションが確立されると、MS から RNC に対して、ME セキュリティケーパビリティと CS サービスドメ

インと PS サービスドメイン用の START 値が送信される。UE のセキュリティケーパビリティ情報には、MS の

暗号化ケーパビリティ（UEA）と完全性ケーパビリティ（UIAs）が含まれる。START 値と UE セキュリティケーパ

ビリティ情報は、SRNC 内に保存される。

2.MS は初期 L3 メッセージ（位置登録更新要求、CM サービス要求、ルーチングエリア更新要求、アタッチ要求、

ページング応答など）を VLR/SGSN に送信する。本情報には、ユーザ識別子や KSI などが含まれる。情報に

含まれる KSI (Key Set Identifier) は、本 CN ドメイン用の新の認証時に、CS サービスドメインまたは PS サ

ービスドメインによって本 CN ドメイン用に割当てられた KSI である。

3. ユーザ識別要求を実行することができる（6.2 節参照）。ユーザの認証および新しい秘密鍵(IK と CK)の生成

を実行することができる（6.3.3 節参照）。そして新しい KSI が割当てられる。

4. VLR/SGSN は、どの UIA と UEA の使用を許可するか、決定する。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)31Release 1999

5. VLR/SGSN は、SRNC に対して RANAP メッセージ Security Mode Command を送信し、完全化と暗号化を開

始する。本メッセージには使用が許可された UIA と UEA のリストが含まれる。暗号化を開始すべき場合には、

本メッセージには使用が許可された UIA と CK のリストが含まれる。新たな認証と秘密鍵の生成が実行され

た場合には（上の第 3 項目参照）、このことをメッセージで SRNC に通知すること。新しい鍵の生成の通知は、

新しい鍵の使用を開始時に使用すべき START 値がリセットする（つまり 0 に設定される）必要があることを意

味する。一方、使用すべき START 値は、SRNC 内で既に利用可能である（項 1 参照）。

6. SRNC は、使用が許容されたアルゴリズムのリストと、MS がサポートするアルゴリズムのリストの中から、使

用すべきアルゴリズムを決定する（6.4.2 節参照）。SRNC は、乱数値 FRESH を生成し、下りリンクの完全性

保護を開始する。Security mode command 内で受信した要求条件が満たせない場合には、SRNC は要求元

の VLR/SGSN に SECURITY MODE REJECT メッセージを送信する。それ以上のアクションについては、

6.4.2 節で説明する。

7. SRNC は、RRC メッセージ Security mode command を生成する。本メッセージには、ME のセキュリティケーパ

ビリティ、UIA、そして使用すべき FRESH が含まれ、暗号化が開始された場合にさらに UEA も含まれる。追

加情報（暗号化の開始）も含まれることがある。MS は暗号鍵と完全鍵の組み合わせを（PS ドメイン用途 CS ド

メイン用に）2 通り持つことできるので、ネットワークはどちらの鍵の組み合わせを使用すべきか、通知する必

要がある。これは、Security mode command メッセージ中に CN type indicator を入れることによって実現される。

本情報を MS に送信する前に、SRNC は MAC-I (Message Authentication Code for Integrity)を生成してメッセ

ージに添付する。

8. Security mode command メッセージを受信した MS は、受信した ME セキュリティケーパビリティを、初期メッセ

ージ中で送信した ME セキュリティケーパビリティと等しくなるように調整する。MS は、通知された UIA、保存

された COUNT-I、そして受信した FRESH パラメータを使用して、受信したメッセージ上の XMAC-I を計算す

る。MS は、受信した MAC-I の値と、そのようにして計算した XMAC-I の値を比較して、メッセージの完全性

を検証する。

9. 全ての制御が成功したならば、MS は RRC メッセージ Security mode complete をコンパイルし、そのメッセー

ジ用の MAC-I を生成する。全ての制御が成功しなかった場合には､MS は処理を完了する。

10. 応答メッセージを受信した SRNC は、メッセージ上の XMAC-I を算出する。SRNC は受信した MAC-I の値と

生成した XMAC-I の値を比較することによって、データの完全性を検証する。

11. RANAP メッセージ Security Mode Complete response が SRNC から VLR/SGSN に送信されて処理は完了す

る。メッセージ内に選択されたアルゴリズムが含まれる。

MS に対する Security mode command から、下りリンクの完全性保護が開始される。つまり、本コマンドおよびこれ以

降 MS に送信される全ての下りリンクのメッセージは、新しい完全性コンフィギュレーションを使用して完全性保護さ

れる。MS から返される Security mode complete から、上りリンクの完全性保護が開始される。つまり、本メッセージ

およびこれ以降 MS から送信される全ての上りリンクのメッセージは、新しい完全性コンフィギュレーションを使用して

完全性保護される。暗号化を開始すべき場合には、セキュリティモードセットアップ処理の中で SRNS～MS 間で交換

される暗号化アクティブ化時間情報によって、RLC シーケンス番号／コネクションフレーム番号を設定し、下りリンク

で暗号化を開始すべき時刻と、上りリンクで新しい暗号化コンフィギュレーションを使用すべき時刻を設定する。

6.4.6 完全性チェックが失敗した場合のシグナリング処理（Signalling procedures in the case of an unsuccessful integrity check）

MS および SRNC の双方で、完全性チェックの失敗を監視すること。完全性保護開始後に完全性チェックの失敗が

検出された場合（fault または MAC の消失など）には、関連するメッセージを廃棄すること。完全性チェックの失敗は、

RNC サイドでも MS サイドでも起こりうる。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)32Release 1999

6.4.7 定期的ローカル認証のためのシグナリング処理（Signalling procedure for periodic local authentication）

定期的なローカル認証を実行するために、RNC は以下の処理を実行する。同時に、RRC コネクションで送信された

データ量も、RNC と ME 双方が定期的にチェックする。RNC は、各無線ベアラに関連する COUNT-C と COUNT-Iの値をモニタしている。これらの値がクリティカルな検証値に達した場合には、処理がトリガされる。これらの検証値

および値自体の精度は、visited ネットワークによって規定される。処理中で送信される全てのメッセージは、完全性

保護される。

UE RNC

1. Counter Check message

2. Counter OK or CounterCheck Response

3. (in the case of Counter CheckResponse:) Counter OK orrelease connection

図図図図 15a: RNC の定期的なローカルの定期的なローカルの定期的なローカルの定期的なローカル認証認証認証認証処理処理処理処理

1. 検証値に問題が発生した場合（例えばハイパーフレーム内のいくつかの固定ビットポジション内の値が変更さ

れた場合など）、RNC は Counter Check メッセージを送信する。Counter Check メッセージには、アクティブな各

無線ベアラから受信したカウンタ値（これは送受信されたデータ量の目安となる）の MSP（most significant part）が含まれる。

2. ME は Counter Check メッセージ内のカウンタ値を検証し、それが ME 内の現行ステータスと一致する場合に

は、 'Counter OK' メッセージを RNC に返す。ME 内のカウンタ値と Counter Check メッセージ内のカウンタ値

が異なる場合、ME は RNC に Counter Check 応答を返す。本メッセージのフォーマットは、Counter Check メッセージのフォーマットと同様である。

3. RNC が 'Counter OK'メッセージを受信して処理は完了する。RNC が Counter Check 応答を受信した場合、

RNC は応答中のカウンタ値と自分自身のカウンタ値を比較する。両者に違いがない場合、またはその差異が

許容範囲内であった場合には、RNC は'Counter OK' メッセージを送信して処理を完了する。さもなければ、コ

ネクションを解放する。

6.4.8 暗号化と完全性保護の同期の初期化（Initialisation of synchronisation for ciphering and integrity protection）

暗号化と完全性保護アルゴリズムは、カウンタ（COUNT-C と COUNT-I）によって起動される。コネクション確立時に

はこれらは初期化する必要がある。そのために、START 値を ME および USIM 内で保存する必要がある。ME と USIM は、 CS 暗号化／完全鍵のための STARTCS 値と、 PS 暗号化／完全鍵のための STARTPS を保存する。

START の長さは 20 ビット。

ME 電源投入時および USIM 挿入時には、ME は (有効な) START 値だけを格納する。 ME の電源断時、または

USIM が抜かれた時には、ME はその START 値を削除する。電源投入後または USIM 挿入後、USIM は自身の

START 値を ME に送り、ME はその値を保存する。アイドルモード時には、ME 内の START 値と USIM 内の

START 値は同一であり変化しない。

特定のサービスネットワークドメイン (CS または PS)のための無線コネクション確立時、 ME は RRC connection setup complete 内に STARTCS 値と STARTPS値を入れて RNC に送信する。ME は USIM 内の START 値を、STARTCS とSTARTPS の値を THRESHOLD に設定することによって、無効としてマークする。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)33Release 1999

ME と RNC は、RRC HFN (完全性保護用)、RLC HFN (暗号化用)、および MAC-d HFN (暗号化用)の MSB20（20 most significant bit）を、関連するサービスドメインの START の値に初期化し、それ以外のビットは 0 に初期化する。

また、RRC SN (完全性保護用) と RLC SN (暗号化用) も 0 に初期化される。

進行中の無線コネクションについては、ME 内と SRNC 内の STARTCS 値は、CKCS および／または IKCS を使用して

保護されている全てのシグナリング無線ベアラおよび CS ユーザデータの無線ベアラの現行の COUNT-C および

COUNT-I のうち、も大きい値の MSB20（20 most significant bit）に 1 を足した数として定義される。つまり、

STARTCS = MSB20 ( MAX {COUNT-C, COUNT-I | CKCS と IKCS で保護されている全ての無線ベアラ（シグナリン

グを含む）） + 1.

さらに、進行中の無線コネクションについては、ME 内と SRNC 内の STARTPS値は、CKPS および／または IKPSを使

用して保護されている全てのシグナリング無線ベアラおよび PS ユーザデータの無線ベアラの現行の COUNT-C および COUNT-I のうち、も大きい値の MSB20 （20 most significant bit）に 1 を足した数として定義される。つまり、

STARTPS = MSB20 ( MAX {COUNT-C, COUNT-I | CKPS と IKPS で保護されている全ての無線ベアラ（シグナリン

グを含む）} + 1.

無線コネクションが解放され、暗号化／完全鍵の組み合わせが使用されていない場合には、ME は USIM 内の

STARTCS と STARTPS を現行の値に更新する。

認証と鍵合意の間、現行のサービスドメインの新しい鍵の組み合わせと関連する START 値は、USIM 内でも ME内でも 0 に設定される。

6.4.9 緊急呼の処理（Emergency call handling） PLMNs は、TS 22.003 で定義される緊急呼のテレサービスをサポートすること。これらのテレサービスは、TS 22.101内で定義される付加サービス要求条件を満足する。

6.4.9.1 セキュリティ処理の適用（Security procedures applied）

セキュリティモードの処理は、TS 24.008 で定義される緊急呼の確立の一部として適用されること。であるから、完全

性保護 (とオプションとして暗号化) は、非緊急呼に対して適用すること。任意の理由で(U)SIM の認証が失敗した場

合でも、緊急呼は次の 6.4.9.2 d) で説明されるように継続されること。ただし、いったん呼に対して完全性保護（およ

びオプションとして暗号化）が適用されたならば、完全性検証または暗号化の failure は異常な環境であり、他の装置

の failure と同様な方法で扱う必要がある。つまり呼は切断される。

6.4.9.2 セキュリティ処理の非適用（Security procedures not applied）

TS 24.008 に定義されるように、サービスネットワークオプションの 1 つとして、ネットワークがセキュリティモード処理

を適用せずに緊急呼を確立することもできる。

"security procedure not applied（セキュリティ処理非適用）"オプションが使用されるケースは以下に示すものだけであ

る。

a) (U)SIM がないために認証が不可能な場合

b) ネットワークエラーにより、サービスネットワークが認証ベクトルを獲得できないために、認証が不可能な場合

c) サービスネットワークからの非認証緊急サービスの受信を(U)SIM が許可されていないために、認証が不可

能な場合（例えば、ローミングの合意がない場合や、IMSI がロックされている場合など）

d) 認証は可能だが、サービスネットワークが(U)SIM を正しく認証できなかった場合

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)34Release 1999

6.5 アクセスリンクのデータ完全性（Access link data integrity ）

6.5.1 概要（General） MS とネットワーク間で送信されるほとんどの制御シグナリング情報エレメントは、機密事項を含むと考えられるので、

完全性を保護する必要がある。ME とネットワーク間で送信されるこれらのシグナリング情報エレメントには、メッセー

ジ認証関数を適用すること。

RRC コネクションが確立され、セキュリティモードのセットアップが実行された後は、個々の MS ⇔ネットワーク間のネ

ットワーク制御シグナリングメッセージ（例： RRC, MM, CC, GMM, SM メッセージ）は全て、完全性を保護すること。 MS 内の Mobility Management レイヤが、完全性保護の開始を監督する（6.4.5 節参照）。

以下のシグナリングメッセージを除く全てのシグナリングメッセージの完全性を保護すること。

- Paging Type 1

- RRC Connection Request

- RRC Connection Setup

- RRC Connection Setup Complete

- RRC Connection Reject

- System Information (broadcasted information)

- Handover to UTRAN complete.

6.5.2 完全性保護のレイヤ(Layer of integrity protection) ME 内および RNC 内に UIA を実装すること。

RRC レイヤにおいて完全性保護を適用すること。

6.5.3 データの完全性保護の方法図 16 に、シグナリングメッセージのデータ完全性を認証するための完全性アルゴリズム f9 の使用をイラスト化する。

f 9

COUNT-I DIRECTION

MESSAGE FRESH

IK

MAC -I

f 9

COUNT-I DIRECTION

MESSAGE FRESH

IK

XMAC -I

SenderUE or RNC

ReceiverRNC or UE

図図図図 16: シグナリングメッセージシグナリングメッセージシグナリングメッセージシグナリングメッセージ上の上の上の上の MAC-I (またはまたはまたはまたは XMAC-I) の抽出の抽出の抽出の抽出

アルゴリズムの入力パラメータは、完全鍵 (IK)、完全性シーケンス番号 (COUNT-I)、ネットワーク側で生成された乱

数値 (FRESH)、方向ビット DIRECTION 、そしてシグナリングデータ MESSAGE である。これらの入力パラメータに

基づいて、ユーザは完全性アルゴリズム f9 を使用して、データの完全性のメッセージ認証コード MAC-I を算出する。

MAC-I はメッセージが無線アクセスリンク上に送信されるときに追加される。受信側では受信したメッセージ上につ

いて、送信側がメッセージの送信時に MAC-I を算出したのと同様の方法で XMAC-I を算出し、それを受信した

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)35Release 1999

MAC-I と比較することによってメッセージのデータ完全性を検証する。

6.5.4 完全性アルゴリズムの入力パラメータ（Input parameters to the integrity algorithm）

6.5.4.1 COUNT-I

完全性シーケンス番号 COUNT-I は 32 ビット長である。

上りリンクのシグナリング無線ベアラ毎に 1 つの COUNT-I 値があり、RLC AM または RLC UM を使用する下りリン

クのシグナリング無線ベアラ毎に 1 つの COUNT-I がある。

COUNT-I は 2 つのパートから構成される。1 つは "short" シーケンス番号であり、もうひとつは"long"シーケンス番号

である。 "short" シーケンス番号は COUNT-I の LSB を構成し、一方"long" シーケンス番号は COUNT-I の MSB を

構成する。 "short" シーケンス番号は 4 ビットの RRC シーケンス番号（RRC SN）であり、各 RRC PDU ごとに適用可

能である。"long" シーケンス番号は 28 ビットの RRC ハイパーフレーム番号（RRC HFN）であり、各 RRC SN のサイ

クル毎に増加する。

RRC HFN(28 bits)

RRC SN(4 bits)

COUNT-I

図図図図 16a: COUNT-I の構造の構造の構造の構造

RRC HFN は、6.4.8 節に説明されるように、パラメータ START を使用して初期化される。続いて ME と RNC は RRC HFN の MSB20を START 値に設定する。RRC HFN の残りビットは 0 に初期化される。

6.5.4.2 IK

完全鍵 IK は 128 ビット長である。

CS サービスドメインとユーザの間に確立された CS コネクション毎に 1 つの IK（IKCS）が、PS サービスドメインとユー

ザの間に確立されたコネクション毎に 1 つの IK（IKPS）が存在する。特定のコネクションに対してどの完全鍵を使用

すべきかについては、6.5.5 節で説明する。

UMTS 加入者用の IK は、UMTS の AKA の過程で完全鍵誘導関数 f4 の出力として確立され、USIM および

HLR/AuC 内で有効である。UTRAN にアクセスする GSM 加入者に対しては、6.8.2 節で説明されるように、GSM AKA の後で、GSM の暗号鍵 Kc から IK が確立される。

IK は USIM 内に保存され、そのコピーは ME 内に保存される。ME の要求に基づいて、IK は USIM から ME に送

信される。USIM は有効な IK が利用可能な条件下で、IK を送信すること。USIM 内の STARTCS または STARTPS の現行値が新の値でない場合、またはそれらが THRESHOLD に達したならば、ME は新しい認証処理をトリガす

ること。ME は電源切断後に IK をメモリから削除すること。USIM が抜かれた場合も同様。

IK は HLR/AuC から VLR/SGSN に送信され、クインテットの一部として VLR/SGSN 内に保存される。IK は

VLR/SGSN から RNC に対して、 (RANAP) security mode command 内で送信される。

ハンドオ―バ時には、通信が続行できるようにネットワークインフラ内で IK が旧 RNC から新 RNC に送信され、同期

処理が再開される。ハンドオ―バ時には IK は変更されない。

6.5.4.3 FRESH

ネットワークサイドのノンスである FRESH は 32 ビット長である。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)36Release 1999

ユーザ毎に 1 つの FRESH パラメータが存在する。入力パラメータである FRESH は、ユーザによるシグナリングメッ

セージの反復攻撃からネットワークを守る。コネクションセットアップ時に、RNC は乱数値 FRESH を生成し、それをユ

ーザに(RRC) security mode command 中に入れて送信する。その後、1 回のコネクションの間を通じてネットワークと

ユーザ双方がその FRESH 値を使用する。このメカニズムによって、ユーザがネットワークに対して古い MAC-Is 値を反復使用できないようにする。

SRNC 再配置を伴うハンドオーバ時には、新しい SRNC が FRESH パラメータ用に自分の値を生成し、その値を、

SRNC 再配置による UTRAN 無線ネットワークテンポラリ識別子（TS 25.331 [17]参照）を通知するための RRC メッ

セージ内に入れて送信する。

6.5.4.4 DIRECTION

方向識別子 DIRECTION は 1 ビット長である。

メッセージ認証コードを算出するために使用される完全性アルゴリズムが、上りリンク、下りリンク双方のメッセージに

対して、同一の入力パラメータの組み合わせを使用することがないように方向識別子が使用される。UE から RNCに送信されるメッセージについては DIRECTION＝0、RNC から UE に送信されるメッセージについては DIRECTION＝1 である。

6.5.4.5 MESSAGE

無線ベアラ識別子とともに使用されるシグナリングメッセージそれ自体。無線ベアラ識別子はメッセージの前に添付

される。無線ベアラ識別子はメッセージといっしょに送信されないが、メッセージ認証コードの異なるインスタンスが同

一の入力パラメータの組み合わせを使用することがないように、無線ベアラ識別子が必要となることに注意。

6.5.5 完全鍵の選択（Integrity key selection） CS サービスドメインとユーザの間に確立された CS コネクションに対して 1 つの IK(IKCS)を、PS サービスドメインとユ

ーザの間に確立された PS コネクションに対して 1 つの IK(IKPS)を割当てることができる。

ユーザデータ用の無線ベアラのデータ完全性は、保護されない。

CS および PS サービスドメイン双方によって提供されるサービス用のシグナリングデータ送信には、シグナリング無

線ベアラが使用される。これらのシグナリング無線ベアラは、一番近セキュリティモードのネゴシエーションが実行

されたサービスドメインの IK によって、データの完全性が保護される。新しいコネクションが他のサービスドメインと

の間で確立された場合、またはコネクション進行中に再認証の後にセキュリティモードのネゴシエーションフローが続

いた場合には、進行中のシグナリングコネクション（既に完全性が保護されている）の完全鍵を変更することが望ま

しい。鍵の変更は、セキュリティモードのネゴシエーション後、5 秒以内に完了すること。

6.5.6 UIA 識別子（UIA identification）各 UIA(UMTS Integrity Algorithm)には、4 ビットの識別子が割当てられる。現時点では以下の値が定義されている。

"00012" : UIA1, Kasumi.

これ以外の値は未定義。

完全性保護関数 f9 のための Kasumi の使用は、TS 35.201 [11] および TS 35.202 [12]中で規定されている。実装メ

ーカの試験データと設計検討データは、TS 35.203 [13] および TS 35.202 [14]中で提供されている。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)37Release 1999

6.6 アクセスリンクのデータの機密保持（Access link data confidentiality）

6.6.1 概要（General）ユーザデータおよびいくつかのシグナリング情報エレメントには、機密事項が含まれると考えられるので、セキュリテ

ィ保護する必要がある。識別子のセキュリティを保証する（6.1 節参照）ために、シグナリング処理が許容する場合に

は、識別子割当て時またはその他の機会に、プロテクトモードで(P-)TMSI （temporary user identity）を送信する必要

がある。

伝送用プロテクトモードに求められるものは、ME と RNC 間の個別チャネルに適用される機密保持関数を満足する

こと。

6.6.2 暗号化のレイヤ（Layer of ciphering）暗号化機能は、RLC のサブレイヤ内、または MAC サブレイヤ内で実行される。それぞれ以下の規則に従う。

- 無線ベアラが非透過 RLC モード (AM または UM)を使用する場合には、暗号化は RLC サブレイヤ内で実行

される。

- 無線ベアラが透過 RLC モード使用する場合には、暗号化は MAC サブレイヤ (MAC-d エンティティ)内で実

行される。

S-RNC と ME で暗号化が適用される場合には、暗号化が必要なコンテキスト (CK, HFN など) は S-RNC と ME だけ

が知っている。

6.6.3 暗号化の方法（Ciphering method）図 16b に、暗号化アルゴリズム f8 の使用例を図示する。平文と鍵ストリームをビット単位で 2 進加算し、平文に鍵ス

トリームを適用する。受信側では、同一の入力パラメータを使用して鍵ストリームを生成し、暗号化されたテキストと

鍵ストリームをビット単位で 2 進加算して平文を取り出すことができる。

PLAINTEXTBLOCK

f8

COUNT-C DIRECTION

BEARER LENGTH

CK

KEYSTREAMBLOCK

CIPHERTEXTBLOCK

f8

COUNT-C DIRECTION

BEARER LENGTH

CK

KEYSTREAMBLOCK

PLAINTEXTBLOCK

SenderUE or RNC

ReceiverRNC or UE

図図図図 16b: 無線アクセスリンク無線アクセスリンク無線アクセスリンク無線アクセスリンク上で送信されるユーザデータとシグナリングデータの暗号化上で送信されるユーザデータとシグナリングデータの暗号化上で送信されるユーザデータとシグナリングデータの暗号化上で送信されるユーザデータとシグナリングデータの暗号化

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)38Release 1999

アルゴリズムへの入力パラメータは、暗号鍵 CK、時間に依存する入力 COUNT-C、ベアラ識別子 BEARER、送信

方向を示す DIRECTION、そして鍵ストリームに要求される長さ LENGTH である。アルゴリズムは、これらの入力パ

ラメータに基づいて、入力された平文ブロック PLAINTEXT から出力暗号化テキスト CIPHERTEXT を生成するため

に使用される鍵ストリームブロック KEYSTREAM を生成する。

入力パラメータ LENGTH は、KEYSTREAM BLOCK の長さにのみ関係し、その中の実質的なビットには影響を及

ぼさないこと。

6.6.4 暗号化アルゴリズムの入力パラメータ（Input parameters to the cipher algorithm）

6.6.4.1 COUNT-C

暗号化シーケンス番号 COUNT-C は、32 ビット長である。

RLC AM または RLC UM を使用する、上りリンクと下りリンクのベアラ毎に 1 つの COUNT-C 値がある。透過 RLCモードを使用する全ての無線ベアラについて、上りリンクの COUNT-C 値が 1 つ、下りリンクの COUNT-C 値が 1 つ

存在する（そして DCH 上にマッピングされる）。

COUNT-C は 2 つのパートから構成される。 "short" シーケンス番号と "long" シーケンス番号である。"short"シーケ

ンス番号は、COUNT-C の LSB（least significant bit）を構成し、一方 "long" シーケンス番号は COUNT-C の MSB（most significant bit）を構成する。COUNT-C の更新は、下記に説明するように送信モードに依存する（図 16c 参照）。

MAC-d HFN (24 bits) CFN (8 bits)MAC-d DCH

RLC HFN (25 bits) RLC SN (7 bits)RLC UM

RLC HFN (20 bits) RLC SN (12 bits)RLC AM

RLC TM

COUNT-C

図図図図 16c: 全送信モードに対する全送信モードに対する全送信モードに対する全送信モードに対する COUNT-C の構造の構造の構造の構造

- DCH 上の RLC TM の場合、 “short” シーケンス番号は、COUNT-C の 8 ビットのコネクションフレーム番号で

ある。その値は、ME の MAC-d エンティティと、SRNC の MAC-d エンティティでそれぞれ独立して維持される。 “long”シーケンス番号は 24 ビットの MAC-d HFN であり、CFN サイクルごとに増加する。

- RLC UM モードの場合、“short” シーケンス番号は 7 ビットの RLC シーケンス番号 (RLC SN)であり、これは

RLC UM PDU ヘッダの一部である。 “long”シーケンス番号は 24 ビットの RLC UM HFN であり、RLC SN サ

イクルごとに増加する。

- RLC AM モードの場合、“short” シーケンス番号は 12 ビットの RLC シーケンス番号(RLC SN)であり、これは RLC AM PDU ヘッダの一部である。“long”シーケンス番号は 20 ビットの RLC AM HFN であり、 RLC SN サイクルごとに増加する。

ハイパーフレーム番号 HFN は、6.4.8 節に説明されたように、パラメータ START を使用して初期化される。次に MEと RNC は、RLC AM HFN、RLC UM HFN、MAC-d の 20MSB を START に初期化する。RLC AM HFN、 RLC UM

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)39Release 1999

HFN 、MAC-d HFN の残りビットは 0 に初期化される。

RRC コネクションが暗号化モードにあるときに、新しい無線ベアラが生成されたならば、HFN は現行の START 値で

初期化される（6.4.8 節参照）。

平文ブロック、つまり暗号化すべきデータは、下記に説明されるように送信モードに依存する。

- RLC UM モードの場合、平文ブロックは、UMD PDU から初のオクテット、つまり RLC UM PDU ヘッダを除

いたものである（TS 25.322 [19]参照）。

- RLC AM モードの場合、平文ブロックは、AMD PDU から初の 2 オクテット、つまり RLC AM PDU ヘッダを

除いたものである（TS 25.322 [19]参照）。

- DCH 上の RLC TM の場合、平文ブロックは MAC SDU である（TS 25.321 [18]参照）。

6.6.4.2 CK

暗号鍵 CK は 128 ビット長である。

CS サービスドメインとユーザ間で確立された CS コネクション毎に 1 つの CK（CKCS）が、PS サービスドメインとユー

ザ間で確立されたコネクション毎に 1 つの CK（CKPS）が存在する。特定のコネクションに対してどちらの暗号鍵 CKを使用すべきかは、6.5.5 節で説明する。UMTS 加入者の場合、CK は暗号鍵誘導関数 f3 の出力として、UMTS AKA の間に確立され、USIM と HLR/AuC 内で有効となる。UMTS にアクセスする GSM 加入者の場合、8.2 節に説

明したように、CK は GSM AKA の後で GSM 暗号鍵 Kc から誘導される。

CK は USIM 内に、そのコピーは ME 内に保存される。CK は ME の要求に基づいて、 USIM から ME に送信される。

USIM は、有効な CK が利用可能な条件下で CK を送信すること。ME は、USIM 内の現行の STARTCS または STARTPSの値が THRESHOLD に達したならば、新しい認証処理をトリガすること。ME は、電源断時または USIMが抜かれた場合には、CK をメモリから削除すること。

CK は HLR/AuC から VLR/SGSN に送信され、クインテットの一部として VLR/SGSN 内に保存される。CK は

VLR/SGSN から RNC に対して、(RANAP) security mode command 内で送信される。

ハンドオーバ時には､CK はネットワークインフラ内で旧 RNC から新 RNC に送信され、通信が続行できるようにする。

ハンドオーバ時には暗号鍵 CK は変更されない。

6.6.4.3 ベアラ（BEARER）

無線ベアラ識別子 BEARER は、5 ビット長である。

同一ユーザに関連する無線ベアラ毎に 1 つの BEARER パラメータが存在し、10ms の物理レイヤの 1 フレーム上に

多重化される。全く同じ入力パラメータ値の組み合わせが、異なる鍵ストリームで使用されることを避けるために、無

線ベアラ識別子が入力される。

6.6.4.4 DIRECTION

方向識別子 DIRECTION は 1 ビット長である。

全く同じ入力パラメータ値の組み合わせが、上りリンクと下りリンクの鍵ストリームで使用されることを避けるために、

方向識別子が入力される。DIRECTION の値は、UE から RNC へのメッセージについては 0、RNC から UE へのメッ

セージについては 1 である。

6.6.4.5 LENGTH

長さ識別子 LENGTH は 16 ビット長である。

長さ識別子は、必要な鍵ストリームブロックの長さを定義する。LENGTH は、 KEYSTREAM BLOCK の長さのみに

影響し、その中の実質的なビットには影響しないこと。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)40Release 1999

6.6.5 暗号鍵の選択（Cipher key selection） CS サービスドメインとユーザの間に確立された CS コネクション毎に 1 つの CK（CKCS）が、PS サービスドメインとユ

ーザの間に確立されたコネクション毎に 1 つの CK（CKPS）が存在する。

CS ユーザデータ用の無線ベアラは、CKCSで暗号化される。

PS ユーザデータ用の無線ベアラは、CKPSで暗号化される。

シグナリング無線ベアラを使用してシグナリングデータを送信し、CS および PS サービスドメイン双方がサービスを提

供する。これらのシグナリング無線ベアラは、一番近セキュリティモードのネゴシエーションが実行されたサービス

ドメインの CK を使用して暗号化される。新しいコネクションが他のサービスドメインとの間で確立された場合、または

コネクション進行中に再認証の後にセキュリティモードのネゴシエーションフローが続いた場合には、進行中のシグナ

リングコネクション（既に完全性が保護されている）の暗号鍵を変更することが望ましい。鍵の変更は、セキュリティモ

ードのネゴシエーション後、5 秒以内に完了すること。

6.6.6 UEA 識別子（UEA identification）各 UEA は、4 ビットの識別子が割当てられる。現時点では以下の値が定義されている。

"00002" : UEA0, 非暗号化

"00012" : UEA1, Kasumi.

上記以外の値は未定義。

暗号化関数 f8 における Kasumi の使用については、TS 35.201 [11] および TS 35.202 [12]内で規定される。実装メ

ーカの試験データと設計検討データは、TS 35.203 [13] および TS 35.202 [14]で提供される。

6.7 Void

6.8 UMTS と GSM 間のインターオペレーションとハンドオーバ（Interoperation and handover between UMTS and GSM）

6.8.1 UMTS 加入者の認証と鍵の合意（Authentication and key agreement of UMTS subscribers）

6.8.1.1 概要（General）

UMTS 加入者に対しては、認証および鍵の合意は以下のように実行される。

- ユーザが UTRAN にアタッチしたとき、UMTS AKA が適用されること。

- ユーザの持っている ME が R99+で VLR/SGSN も R99+の場合には、ユーザが GSM BSS にアタッチしたとき、

UMTS の AKA が適用されること。この場合、ネットワーク側では VLR/SGSN が、ユーザ側では USIM が、

UMTS の暗号化／完全鍵 CK と IK から GSM 暗号鍵 Kc を誘導する。

- ユーザの持っている ME が R98-の場合には、ユーザが GSM BSS にアタッチしたとき、GSM の AKA が適用

されること。この場合、GSM のユーザは SRES を応答し、UMTS のユーザ応答 RES と UMTS の暗号化／完

全鍵 CK と IK から GSM 暗号鍵 Kc を誘導する。R98- の VLR/SGSN は、保存された Kc と RES を使用し、 R99+の VLR/SGSN は RES から SRES を、CK, IK から Kc を誘導する。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)41Release 1999

注: R98-の ME 内でオペレーションするために、USIM は GSM 11.11 で定義される SIM～ME インタフェー

スをサポートし、USIM 内に実装されている 3G の認証鍵 K と 3G の認証アルゴリズムに基づいて、

SRES と Kc を算出するための相応する GSM の機能を提供する GSM の AKA をサポートすることもで

きる。3G の認証では、CK/IK と RES を算出するだけなので、変換関数 c3 で CK/IK を Kc に、変換関

数 c2 で RES を SRES に変換する必要がある。

- VLR/SGSN が R98-の場合には、GSM の AKA は、ユーザが GSM BSS にアタッチしたときに適用すること。

この場合、 USIM は GSM のユーザ応答 SRES と GSM の暗号鍵 Kc を、UMTS のユーザ応答 RES と

UMTS の暗号化／完全鍵 CK, IK から誘導する。

UMTS (resp. GSM)の AKA が実行されると、ユーザと VLR/SGSN が属するサービスネットワークドメインの間で、

UMTS (resp. GSM)のセキュリティコンテキストが確立される。ユーザは各サービスネットワークドメインとの間で、セ

キュリティコンテキストを個々に確立する必要がある。

図 18 に、UMTS の加入者が R98- または R99+ の ME を、混合ネットワークアーキテクチャ内で使用した場合に起こ

りうるシナリオの差異について示す。

Release 99+ VLR/SGSN Release 98-VLR/SGSN

Release 99+HLR/AuC

USIM

RANDAUTN

RES

CKIK

CK, IKKc

UTRAN

R99+ ME

RANDAUTN

RES

[Kc]

CK, IKKc

GSM BSS

CK, IK � KcRES � SRES

CK, IK � Kc

R98- ME

CK, IK � Kc


RANDSRES

[Kc]

Kc

RANDSRES

[Kc]

Kc

R99+ MEor

R98- ME *


Quintets Triplets


UMTS security context GSM security context

CK, IK � Kc

(図 18 中の*部分の詳細な説明については、上記の注参照).

図図図図 18: UMTS 加入者の加入者の加入者の加入者の認証認証認証認証と鍵の合意と鍵の合意と鍵の合意と鍵の合意

UMTS のパラメータ RAND、AUTN 、RES は、UTRAN または GSM の BSS を介して透過的に送信され、また GSMのパラメータ RAND、SRES は GSM の BSS を介して透過的に送信されることに注意。

GSM BSS の場合、暗号化は GSM BSS 内で MSC/VLR を介して提供されるサービスに対して適用され、SGSN が提

供するサービスについては SGSN が提供する。後者の場合、GSM の暗号鍵 Kc は、GSM BSS には送信されない。

UTRAN の場合、暗号化と完全性（保護）は常に RNC 内で適用される。UMTS の暗号化／完全鍵 CK と IK は、常

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)42Release 1999

に RNC に対して送信される。

6.8.1.2 R99+ HLR/AuC

UMTS 加入者のための authentication data request を R99+ VLR/SGSN から受信したならば、R99+ HLR/AuC はク

インテットを送信すること。クインテットの生成については、6.3 節で規定される。

UMTS 加入者のための authentication data request を R98- VLR/SGSN から受信したならば、 R99+ HLR/AuC はト

リプレットを送信すること。トリプレットは以下の変換関数を使用してクインテットから引き出すことができる。

a) c1: RAND[GSM] = RAND

b) c2: SRES[GSM] = XRES*1 xor XRES*2 xor XRES*3 xor XRES*4

c) c3: Kc[GSM] = CK1 xor CK2 xor IK1 xor IK2

ここで XRES* は 128 ビット長であり、 XRES が 128 ビット長ならば XRES* = XRES また XRES が 128 ビットよりも短いならば、XRES* = XRES || 0...0 XRES*i は全て 32 ビット長であり、 XRES* = XRES*1 || XRES*2 || XRES*3 || XRES*4, CKi 、そして IKi は両方 64 ビット長であり CK = CK1 || CK2 かつ IK = IK1 || IK2

6.8.1.3 R99+ VLR/SGSN

AKA 処理は、以下のように端末のケーパビリティに依存する。

- R99+ のののの ME を持ったを持ったを持ったを持った UMTS 加入者加入者加入者加入者

ユーザが R99+ の ME を持っている場合には、UMTS の AKA は、以下のいずれかのクインテットを使用して

実行されること。

a) ローカルデータベースから抽出した値

b) HLR/AuC が提供した値

c) それまでに visited R99+ VLR/SGSN から提供された値

注: 全てのクインテットは HLR/AuC が提供したものに由来する

UMTS の AKA の結果、UMTS セキュリティコンテキストが確立される。UMTS の暗号化／完全鍵 CK と IK、

および KSI（key set identifier）は VLR/SGSN 内に保存される。

ユーザが UTRAN にアタッチすると、UMTS の暗号化／完全鍵が RNC に送信され、そこで暗号化／完全化

アルゴリズムが割当てられる。

ユーザが GSM の BSS にアタッチすると、UMTS の AKA の後、UMTS の暗号化／完全鍵から GSM の暗号

鍵が誘導される。ユーザが MSC/VLR からサービスを受信すると、そのようにして誘導された暗号鍵 Kc がBSC に送信され（そして BTS に転送され）る。ユーザが SGSN からサービスを受信した場合、そのようにして

誘導された暗号鍵 Kc は、SGSN 自体に適用される。

R99+ の ME を持った UMTS 加入者に対しては常に、UMTS の認証と鍵の新鮮度 RAN とは独立して提供さ

れる。

- R98- のののの ME を持ったを持ったを持ったを持った UMTS 加入者加入者加入者加入者

ユーザが R98-の ME を持っている場合、R99+ の VLR/SGSN は以下のいずれかの方法で生成したトリプレットを使

用して GSM の AKA を実行すること。

a) R99+ の VLR/SGSN 内で、以下のいずれかのクインテットから、変換関数 c2 と c3 を使用して誘導する。

i) ローカルデータベースから抽出した値

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)43Release 1999

ii) HLR/AuC が提供した値、または

iii) それまでに visited R99+ VLR/SGSN から提供された値、または

b) それまでに visited VLR/SGSN からトリプレットとして提供された値

注: R99+ の VLR/SGSN は、常に UMTS 加入者に対してクインテットを提供する。

注: UMTS 加入者のために、クインテットから誘導した全てのトリプレットは、HLR/AuC または VLR/SGSN内に置くこと。

GSM の AKA の結果、GSM のセキュリティコンテキストが確立される。GSM の暗号鍵 Kc と暗号鍵のシーケンス番

号 CKSN は、VLR/SGSN 内に保存される。

この場合には、ユーザは GSM の BSS にアタッチされる。ユーザが MSC/VLR からサービスを提供される場合、

GSM の暗号鍵が BSC に送信され（そして BTS に転送され）る。ユーザが SGSN からサービスを受信した場合、そ

のようにして誘導された暗号鍵 Kc は、SGSN 自体に適用される。

R98-の ME を持った UMTS 加入者に対しては、UMTS の認証と鍵の新鮮度は提供できない。

6.8.1.4 R99+ ME

USIM が挿入されて UTRAN にアタッチされた R99+ の ME に対しては、UMTS の AKA だけを適用し、GSM の

AKA を適用してはならない。

USIM が挿入されて GSM の BSS にアタッチされた R99+ の ME に対しては、 UMTS の AKA を適用するが、GSM の AKA を適用することもある。R98- の VLR/SGSN での認証を可能にするために、GSM の AKA の適用が必要と

なる。

UMTS の AKA を実行することにより、UMTS のセキュリティコンテキストが確立される。UMTS の暗号化／完全鍵 CK と IK、そして KSI（key set identifier）は ME に対してパスされる。USIM が変換関数 c3 および／または GSM の

AKA をサポートする場合、ME は誘導された GSM 暗号鍵 Kc も USIM で受信すること。

GSM の AKA を実行することにより、GSM のセキュリティコンテキストが確立される。GSM の暗号鍵 Kc と暗号鍵シ

ーケンス番号 CKSN は、ME 内に保存される。

6.8.1.5 USIM

USIM は UMTS の AKA をサポートすること。そして GSM システムとのバックワードコンパチビリティをサポートする

こともできる。バックワードコンパチビリティの例としては、以下のようなフィーチャがある

フィーチャ 1: デュアルモードの R99+ ME を使用して、R99+VLR/SGSN にアタッチされた GSM BSS にアクセ

スするための、GSM 暗号鍵の誘導 (変換関数 c3)

フィーチャ 2: R98- VLR/SGSN にアタッチされた GSM BSS にアクセスするための、または R98- ME を使用す

る場合の GSM の AKA

フィーチャ 3: R98- ME 内でオペレーションするための SIM～ME インタフェース (GSM 11.11)

ME が USIM に RAND と AUTN を提供する場合、UMTS の AKA を実行すること。AUTN の検証が成功したならば、

USIM は UMTS のユーザ応答 RES と UMTS の暗号化／完全鍵 CK と IK で応答すること。USIM は、CK と IK を

現行のセキュリティコンテキストデータとして保存すること。USIM が GSM の暗号鍵の誘導（フィーチャ 1）のアクセス

をサポートする場合には、USIM は変換関数 c3 を使用して UMTS の暗号化／完全鍵 CK と IK から GSM の暗号

鍵 Kc を誘導し、そのようにして誘導した Kc を R99+ ME に送信すること。AUTN の検証に失敗した場合には、

USIM は適切なエラー通知を R99+ ME に返すこと。

ME が USIM に RAND だけしか提供せず、かつ USIM が GSM の AKA (フィーチャ 2)をサポートする場合、GSM の AKA を実行すること。USIM は初に UMTS のユーザ応答 RES と UMTS 暗号化／完全鍵 CK と IK を算出す

る。続いて USIM は、変換関数 c2 と c3 を使用して GSM のユーザ応答 SRES と GSM の暗号鍵 Kc を算出する。そ

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)44Release 1999

して USIM は GSM の暗号鍵 Kc を現行のセキュリティコンテキストとして保存し、GSM のユーザ応答 SRES と GSMの暗号鍵 Kc を ME に送信する。

USIM が GSM の暗号鍵の誘導(フィーチャ 1) または GSM の AKA (フィーチャ 2)をサポートしない場合には、R99+ ME に対してそのことを通知すること。GSM の暗号鍵の誘導(フィーチャ 1) をサポートしない USIM は、GSM の BSS内ではオペレーションできない。GSM の AKA (フィーチャ 2)をサポートしな USIM は、 R98- VLR/SGSN 配下または R98- ME 内ではオペレーションできない。

6.8.2 ＧＳＭ加入者のための認証と鍵の合意（Authentication and key agreement for GSM subscribers）

6.8.2.1 概要（General）

GSM 加入者に対しては、GSM の AKA を常に使用すること。

GSM の AKA が実行されると、ユーザと VLR/SGSN が属するサービスネットワークドメイン間で GSM セキュリティ

コンテキストが確立される。ユーザは各サービスネットワークドメインとの間で、セキュリティコンテキストを個々に確

立する必要がある。

UTRAN 内にあるとき、R99+ のエンティティである ME と VLR/SGSN は、GSM の暗号鍵 Kc から UMTS の暗号化

／完全鍵 CK と IK を誘導する。

図 19 に、GSM の加入者が R98- または R99+ の ME を、混合ネットワークアーキテクチャ内で使用した場合に起こ

りうるシナリオの差異について示す。

GSM security context

Release 99+VLR/SGSN

Release 98-VLR/SGSN

Release 98- or Release 99+HLR/AuC

SIM

RANDSRES

CKIK

Kc

UTRAN

R99+ UE

RANDSRES

[Kc]

Kc

GSM BSS

Kc � CK, IK

R98- UE

Kc � CK, IK

RANDSRES

[Kc]

Kc

RANDSRES

[Kc]

Kc

R99+ UEor

R98- UE

Triplets Triplets

図図図図 19: GSM 加入者用の加入者用の加入者用の加入者用の認証認証認証認証と鍵の合意と鍵の合意と鍵の合意と鍵の合意

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)45Release 1999

GSM のパラメータ RAND と RES は、UTRAN または GSM の BSS を介して透過的に送信されることに注意すること。

GSM BSS の場合、暗号化は GSM BSS 内で MSC/VLR を介して提供されるサービスに対して適用され、SGSN が提

供するサービスについては SGSN が提供する。後者の場合、GSM の暗号鍵 Kc は、GSM BSS には送信されない。

UTRAN の場合、暗号化と完全性（保護）は常に RNC 内で適用される。UMTS の暗号化／完全鍵 CK と IK は、常

に RNC に対して送信される。

6.8.2.2 R99+ HLR/AuC

GSM 加入者のための authentication data request を受信した R99+ HLR/AuC は、トリプレットを送信する。トリプレッ

トの生成については、GSM 03.20 内で規定される。

6.8.2.3 VLR/SGSN

R99+ VLR/SGSN は、以下のいずれかのトリプレットを使用して GSM の AKA を行うこと。

a) ローカルデータベースから抽出した値

b) HLR/AuC が提供した値

c) それまでに visited R99+ VLR/SGSN から提供された値

注: これら全てのトリプレットは HLR/AuC が提供したものに由来する。

GSM の AKA の結果、GSM のセキュリティコンテキストが確立される。GSM の暗号鍵 Kc と暗号鍵のシーケンス番

号 CKSN は、VLR/SGSN 内に保存される。

ユーザが UTRAN にアタッチされた場合には、R99+ VLR/SGSN は、以下の変換関数を使用して GSM の暗号鍵か

ら UMTS の暗号化／完全鍵を誘導する。

a) c4: CK[UMTS] = Kc || Kc;

b) c5: IK[UMTS] = Kc1 xor Kc2 || Kc || Kc1 xor Kc2;

ここで、c5 における Kci は双方 32 ビット長であり、Kc = Kc1 || Kc2.

そして UMTS 暗号化／完全鍵は RNC に対して送信され、そこで暗号化／完全化アルゴリズムが割当てられる。

ユーザが GSM の BSS にアタッチされ、かつユーザが MSC/VLR からサービスを提供される場合には、暗号鍵 Kc が BSC に送信され（そして BTS に転送され）る。ユーザが SGSN からサービスを提供される場合には、暗号鍵はSGSN 自身の中で適用される。

6.8.2.4 R99+ ME

SIM が挿入された R99+ の ME に対しては、GSM の AKA だけを適用すること。

GSM の AKA の結果、GSM セキュリティコンテキストが確立される。GSM の暗号鍵 Kc と暗号鍵シーケンス番号

CKSN は、ME 内に保存される。

ユーザが UTRAN にアタッチされた場合には、 R99+の ME は、変換関数 c4 と c5 を使用して、GSM の暗号鍵 Kcから UMTS の暗号化／完全鍵 CK と IK を誘導すること。

6.8.3 VLRs/SGSN 間の認証データの分配と使用（Distribution and use of authentication data between VLRs/SGSNs）

同一サービスネットワークドメイン内の R99+ VLRs/SGSN 間の認証データ (未使用の認証ベクトルおよび／または

現行のセキュリティコンテキストデータ) の分配は、6.3.4 節の記載に従って実行される。（同一 release または異なる

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)46Release 1999

release の）VLRs/SGSN 間の認証データの分配に関しては、以下の 4 つのケースが主なものである。そのようなデー

タの分配の条件と、VLRn/SGSNn で受信時とデータの使用について、それぞれのケースについて示す。

a) R99+ VLR/SGSN → R99+ VLR/SGSN

UMTS と GSM の認証ベクトルは、 R99+ VLR/SGSN 間で分配できる。全ての認証ベクトル (UMTS 加入者向

けクインテットと GSM 加入者向けトリプレット)は、HLR/AuC から提供されたものに由来することに注意。

現行のセキュリティコンテキストデータは、R99+ VLR/SGSN 間で分配できる。ただし以下の場合には、

VLRn/SGSNn は、VLRo/SGSNo から受信した現行のセキュリティコンテキストデータを使用して、ローカル認

証を使用した加入者の認証を行ってはならない。

i) VLRn/SGSNn で確立されたセキュリティコンテキストが、VLRo/SGSNo で現在使用されている鍵の組み合

わせとは異なる組み合わせを要求した場合。ユーザが VLRn/SGSNn で認証される際に、ME の ME release が変更 (R’99 ME �� R’98 ME)された場合に本セキュリティコンテキストの変更が起きる。

ii) VLRo からの認証データ中に Kc+CKSN が含まれているものの、未使用の認証ベクトルが含まれておら

ず、かつ加入者が R’99 の ME を持っていた場合 (GSM BSS 配下または UTRAN 配下)。このような条件

下では、VLRn は加入者が GSM 加入者なのか UMTS 加入者なのかを特定することができず、（加入者

が GSM 加入者であった場合には）受信した Kc の使用の是非を決定することができない。

以上 2 つのケースでは、受信した現行のセキュリティコンテキストデータを破棄し、新しい AKA 処理を実行す

ること。

b) R98- VLR/SGSN → R98- VLR/SGSN

R98- VLR/SGSN 間では、トリプレットだけが分配可能である。GSM 加入者用トリプレットは HLR/AuC から提

供されたものに由来し、UMTS 加入者用トリプレットは R99+ HLR/AuC から提供された UMTS 認証ベクトル

に由来することに注意。R98- VLR/SGSN は、UMTS の AKA をサポートしないので、GSM セキュリティコンテ

キストだけしか確立できない。

R98- VLR には、現行のセキュリティコンテキストデータを分配できない。

R98- SGSN は GSM のセキュリティコンテキストだけしか確立できないので、セキュリティコンテキストデータは

R98- SGSN 間で確立して使用することができる。

c) R99+ VLR/SGSN to R98- VLR/SGSN

R99+ VLR/SGSN は、GSM 加入者に対しては HLR/AuC から提供されたものに由来する新しい R98- VLR/SGSN トリプレットを分配し、UMTS 加入者に対しては R99+ HLR/AuC から提供されたものに由来する

保存されたクインテットからトリプレットを誘導することができる。R98- VLR/SGSN は、GSM セキュリティコンテ

キストだけしか確立できないことに注意。

R99+ VLR は、R98- VLR に現行のセキュリティコンテキストデータを分配してはならない。

R98- SGSN は GSM セキュリティコンテキストデータしか処理することができないので、R99+ SGSN は R98- SGSN に対して、GSM セキュリティコンテキストデータだけを分配すること。

d) R98- VLR/SGSN → R99+ VLR/SGSN.

UMTS 加入者向けに GSM セキュリティコンテキストを確立してしまわないよう、R98- VLR/SGSN が提供する

トリプレットは、R99+ VLR/SGSN が GSM セキュリティコンテキストを GSM の BSS と R98 の ME 間で確立す

るためにだけ、使用することができる。

全てのケースで、R99+ VLR/SGSN は新鮮な認証ベクトル (トリプレットまたはクインテット) を HE に要求する

こと。終的に、R99+ VLR/SGSN はクインテットだけを受信し、R98- VLR/SGSN が提供したトリプレットは廃

棄すること。

R98- VLR には、現行のセキュリティコンテキストデータを分配できない。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)47Release 1999

R98- SGSN は、GSM のセキュリティコンテキストデータだけを分配することができる。R99+ SGSNn において

この情報を使用する際には、a)に記載した条件に従って実行すること。

6.8.4 CS サービス用のシステム間ハンドオーバ、UTRAN → GSM BSS （Intersystem handover for CS Services – from UTRAN to GSM BSS）

UTRAN から GSM BSS へのシステム間ハンドオーバ時に暗号化が開始された場合には、ハンドオーバが実際に行

われる前に、予め必要な情報(例えば Kc や、サポートされる／許可された GSM 暗号化アルゴリズムなど)をシステ

ムインフラストラクチャ間で送信しておいて、通信が旧 RNC から新 GSM BSS に継続され、かつ暗号化モードでの通

信を可能にする必要がある。RNC は MS に、MS Classmark の送信を要求する。 MS Classmar には、MS の GSM 暗

号化アルゴリズムケーパビリティに関する情報が含まれる。システム間ハンドオーバが行われるということは、暗号

化アルゴリズムが UEA から GSM A5 に変更されることを意味する。GSM BSS は、選択された GSM 暗号化モード

をハンドオーバコマンドメッセージ中に入れて、RNC 経由で MS に送信する。

GSM BSS へのハンドオーバ時には、シグナリングメッセージの完全性保護は停止する。

GSM BSS へのハンドオーバ時には、START 値 (6.4.8 参照)を ME/USIM 内に保存すること。

6.8.4.1 UMTS セキュリティコンテキスト（UMTS security context）

UTRAN 内の UMTS セキュリティコンテキストは、R99+ ME を持っている UMTS 加入者に対してのみ確立される。

ネットワーク側では、以下の 3 つのケースで確立される。

a) 同一の MSC/VLR によって制御されている GSM BSS へのハンドオーバの場合、MSC/VLR は自身が保存し

ている UMTS の暗号化／完全鍵 CK と IK から（変換関数 c3 を使用して）GSM の暗号鍵 Kc を誘導し、 Kc をターゲット BSC に送信する (さらに BTS に転送される)。

b) 他の R98- MSC/VLR によって制御されている GSM BSS へのハンドオーバの場合、初の MSC/VLR は、

保存されている UMTS の暗号化／完全鍵 CK と IK から、（変換関数 c3 を使用して）GSM の暗号鍵 Kc を誘導し、その値を BSC が制御する新しい MSC/VLR 経由でターゲット BSC に送信する。初の MSC/VLRは、サービスが提供されている間、アンカーポイントとしてとどまる。

c) 他の R99+ MSC/VLR によって制御されている GSM BSS へのハンドオーバの場合、初の MSC/VLR は、保存されている UMTS の暗号化／完全鍵 CK と IK を、新 MSC/VLR に送信する。初の MSC/VLR もま

た、Kc を誘導し、その値を新 MSC/VLR に送信する。新 MSC/VLR は鍵を保存し、受信した GSM の暗号鍵 Kc をターゲット BSC 送信する (さらに BTS に転送される)。初の MSC/VLR はサービスが提供されている

間、アンカーポイントとしてとどまる。

ユーザ側では、いずれのケースでも ME は、一番近の UMTS の AKA 処理の間に USIM から受信した、GSM 暗号鍵 Kc から誘導した値を適用する。

6.8.4.2 GSM セキュリティコンテキスト（GSM security context）

R99+ ME を持つ GSM 加入者のためにだけ、UTRAN 内で GSM セキュリティコンテキストが確立される。ネットワー

ク側では、2 つのケースが考えられる。

a) 同一の MSC/VLR によって制御されている GSM BSS へのハンドオーバの場合、MSC/VLR は保存されてい

る GSM の暗号鍵 Kc をターゲット BSC に送信する(さらに BTS に転送される)。

b) 他の MSC/VLR (R99+ or R98-)によって制御されている GSM BSS へのハンドオーバの場合、初の

MSC/VLR は、保存されている GSM の暗号鍵 Kc を、ターゲット BSC を制御している新 MSC/VLR を経由し

て BSC に送信する。初の MSC/VLR はサービスが提供されている間、アンカーポイントであり続ける。

非アンカー MSC/VLR が R99+であった場合には、アンカーMSC/VLR もまた、 UMTS の暗号化／完全鍵 CK と IK を誘導して非アンカー MSC/VLR に送信する。非アンカーMSC/VLR は、全ての鍵を保存する。こう

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)48Release 1999

することによって、非アンカーR99+ MSC/VLR 内での後続ハンドオーバが可能になる。

ユーザ側では、いずれのケースでも、ME は保存された GSM の暗号鍵 Kc を適用する。

6.8.5 CS サービスのためのシステム間ハンドオーバ、GSM BSS → UTRAN （Intersystem handover for CS Services – from GSM BSS to UTRAN）

GSM BSS から UTRAN へのシステム間ハンドオーバ時に暗号化が開始された場合には、ハンドオーバが実際に行

われる前に、予め必要な情報(例えば CK, IK, START 値の情報、サポートされる／許可された UMTS アルゴリズム

など)をシステムインフラストラクチャ間で送信しておいて、通信が旧 GSM BSS から新 RNC に継続されるようにして、

かつ暗号化モードでの通信を可能にする必要がある。GSM BSS は MS に対して、UMTS ケーパビリティ情報の送信

を要求する。 UMTS ケーパビリティ情報には、START 値や、MS の UMTS セキュリティケーパビリティに関する情報

が含まれる。システム間ハンドオーバが行われるということは、暗号化アルゴリズムが GSM A5 から UEA に変更さ

れることを意味する。ターゲット UMTS RNC は、UTRAN コマンドメッセージ内に選択された UMTS 暗号化モードを

入れて、GSM BSS 経由で MS に送信する。

GSM BSS から UTRAN へのシステム間ハンドオーバが完了したら直ちに、シグナリングメッセージの完全性保護を

開始すること。SRNC は、初の RRC メッセージ（つまり Handover to UTRAN complete メッセージ）が MS によって

受信されたならば、RRC セキュリティモードの制御処理を開始し、シグナリングメッセージの完全性保護を開始する。

UE のセキュリティケーパビリティ情報は、実際にハンドオーバが実行される前に、GSM の無線アクセスとシステムイ

ンフラストラクチャを経由して MS から RNC に送信され、それは RRC Security mode command メッセージ中に入れら

れて MS に送信され、MS はその値を検証する（つまりその値が MS 内に保存されている UE のセキュリティケーパ

ビリティ情報と等しいかどうかを検証）。


R99+ ME 端末を持つ UMTS 加入者が、R99+ VLR/SGSN によって制御される GSM BSS に在圏する場合にのみ、

GSM BSS 内で UMTS セキュリティコンテキストが確立される。ネットワーク側では、2 つのケースが考えられる。

a) 同一の MSC/VLR によって制御されている UTRAN へのハンドオーバの場合、MSC/VLR に保存されている

UMTS の暗号化／完全鍵 CK と IK は target RNC に送信される。

b) 他の MSC/VLR によって制御されている UTRAN へのハンドオーバの場合、初の MSC/VLR は、保存され

ている UMTS の暗号化／完全鍵 CK と IK を、target RNC を制御している新 MSC/VLR を経由して新 RNC に送信する。初の MSC/VLR はサービスが提供されている間、アンカーポイントであり続ける。

アンカーMSC/VLR もまた、GSM の暗号鍵 Kc を抽出してその値を非アンカーMSC/VLR に送信する。非アン

カーMSC/VLR は全ての鍵を保存する。そうすることによって、非アンカーR99+ MSC/VLR 内での後続ハンド

オーバが可能になる。

ユーザ側では、いずれのケースでも、ME は保存された UMTS の暗号化／完全鍵 CK と IK を適用する。


R99+ ME の端末を持つ GSM 加入者だけが、GSM セキュリティコンテキストを伴う GSM BSS から UTRAN へのハ

ンドオーバが可能である。ネットワークネットワーク側では、2 つのケースが考えられる。

a) 同一の MSC/VLR によって制御されている UTRAN へのハンドオーバの場合、MSC/VLR は保存されている

GSM の暗号鍵 Kc から（変換関数 c4 と c5 を使用して）UMTS の暗号化／完全鍵 CK と IK を誘導し、その

値を target RNC に送信する。

b) 他の MSC/VLR によって制御されている UTRAN へのハンドオーバの場合、初の MSC/VLR (R99+ また

は R98-)は、保存されている GSM の暗号鍵 Kc を、target RNC を制御している新 MSC/VLR に送信する。そ

の MSC/VLR は、UMTS の暗号化／完全鍵 CK と IK を誘導し、そして target RNC に転送する。初の

MSC/VLR は、サービスが提供されている間、アンカーポイントであり続ける。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)49Release 1999

ユーザ側では、いずれのケースでも、ME は保存された GSM の暗号鍵 Kc から（変換関数 c4 と c5 を使用して）

UMTS の暗号化／完全鍵 CK と IK を誘導し、それらを適用する。

6.8.6 PS サービスのシステム間変更、UTRAN → GSM BSS （Intersystem change for PS Services – from UTRAN to GSM BSS）


UMTS 加入者に対してだけ、UTRAN 内で UMTS セキュリティコンテキストが確立される。ネットワーク側では、3 つ

のケースが考えられる。

a) 同一の SGSN によって制御されている GSM BSS へのシステム間変更の場合、SGSN は保存されている

UMTS の暗号化／完全鍵 CK と IK から (変換関数 c3 を使用して) GSM の暗号鍵 Kc を誘導し、それを適用

する。

b) 他の R99+ SGSN によって制御されている GSM BSS へのシステム間変更の場合、初の SGSN は、保存さ

れている UMTS の暗号化／完全鍵 CK と IK を SGSN に送信する。新 SGSN は鍵を保存し、GSM の暗号鍵 Kc を誘導してそれ以降適用する。新 SGSN は、サービスが提供されている間、新しいアンカーポイントとなる。

c) R98- SGSN によって制御されている GSM BSS へのシステム間変更が発生した場合、初の SGSN は GSMの暗号鍵 Kc を誘導して、GSM の暗号鍵 Kc を新 SGSN に送信する。新 SGSN は GSM の暗号鍵 Kc を穂存

してそれを適用する。新 SGSN は、サービスが提供されている間、新しいアンカーポイントとなる。

ユーザ側では、いずれのケースでも、ME は後の UMTS の AKA 処理の間に USIM から受信した GSM 暗号鍵 Kc から誘導した値を適用する。


GSM 加入者に対してだけ、 UTRAN 内で UMTS セキュリティコンテキストが確立される。ネットワーク側では、2 つの

ケースが考えられる。

a) 同一の SGSN によって制御されている GSM BSS へのシステム間変更があった場合、SGSN は保存されてい

る GSM 暗号鍵 Kc の適用を開始する。

b) 他の SGSN によって制御されている GSM BSS へのシステム間変更があった場合、初の SGSN は保存さ

れている GSM の暗号鍵 Kc を、BSM を制御している（新） SGSN に送信する。新 SGSN は鍵を保存し、それ

を適用する。新 SGSN は、サービスが提供されている間、新しいアンカーポイントとなる。

ユーザ側では、いずれのケースでも、ME は保存されていた GSM の暗号鍵 Kc を適用する。

6.8.7 PS サービスのシステム間変更、GSM BSS → UTRAN （Intersystem change for PS services – from GSM BSS to UTRAN）


R99+ VLR/SGSN に接続された R99+ ME を持つ UMTS 加入者に対してのみ、GSM BSS 内で UMTS セキュリティ

コンテキストが確立される。ネットワーク側では、2 つのケースが考えられる。

a) 同一の SGSN によって制御されている UTRAN へのシステム間変更があった場合、保存されている UMTSの暗号化／完全鍵 CK と IK が target RNC に送信される。

b) 他の SGSN によって制御されている UTRAN へのシステム間変更があった場合、初の SGSN は保存され

ている UMTS の暗号化／完全鍵 CK と IK を、target RNC を制御している（新） SGSN に送信する。新 SGSN は、サービスが提供されている間、新しいアンカーポイントとなる。そして新 SGSN は、UMTS の暗号化／完

全鍵 CK と IK を保存して、target RNC に送信する。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)50Release 1999

ユーザ側では、いずれのケースでも、ME は保存された UMTS の暗号化／完全鍵 CK と IK を適用する。


GSM BSS 内の GSM セキュリティコンテキストは、以下のいずれかである。

- UMTS 加入者加入者加入者加入者のためののためののためののためのセキュリティコンテキストセキュリティコンテキストセキュリティコンテキストセキュリティコンテキストのののの確立確立確立確立

ユーザの持つ端末が R98- ME で UTRAN へのシステム間変更が不可能である場合、またはユーザの持つ

端末は R99+ ME であるが SGSN が R98-の場合（この場合 UTRAN へのシステム間変更は R99+ SGSN へ

の変更を意味する）に、 UMTS 加入者用の GSM セキュリティコンテキストが確立される。

その結果、他の R99+ SGSN によって制御される UTRAN へのシステム間変更が発生すると、初の R98- SGSN は、保存されている GSM の暗号鍵 Kc を target RNC を制御する新 SGSN に送信する。

新 R99+ SGSN には加入者が GSM か UMTS であるかが通知されていないので、R99+ SGSN は R98- SGSN から Kc を受信したら新たな UMTS の AKA を実行する必要がある。そして、新鮮なクインテットを使用して、

R99+ SGSN と USIM の間で UMTS セキュリティコンテキストが確立される。新 SGSN は、サービスが提供さ

れている間、新しいアンカーポイントとなる。

ユーザ側では、R99+ SGSN によって開始される新たな UMTS の AKA の間に、新しい鍵について合意する

必要がある。

- GSM 加入者加入者加入者加入者のためののためののためののためのセキュリティコンテキストセキュリティコンテキストセキュリティコンテキストセキュリティコンテキストのののの確立確立確立確立

R99+ ME の端末を持つ GSM 加入者だけが、GSM BSS から UTRAN へのハンドオーバを行うことができる。

ネットワーク側では、以下の 3 つのケースが考えられる。

a) 同一の SGSN によって制御されている UTRAN へのシステム間変更の場合、SGSN は保存されている

GSM の暗号鍵 Kc から(変換関数 c4 と c5 を使用して) UMTS の暗号化／完全鍵 CK と IK を誘導し、そ

れらを target RNC に送信する。

b) 他の SGSN によって制御されている UTRAN へのシステム間変更の場合、初の SGSN は、保存されて

いる GSM の暗号鍵 Kc を target RNC を制御している（新）SGSN に送信する。新 SGSN は、サービスが提

供されている間、新しいアンカーポイントとなる。新 SGSN は GSM の暗号鍵 Kc を保存し、そこから

UMTS の暗号化／完全鍵 CK と IK を誘導し、さらに target RNC に転送する。

c) R98- SGSN から他の SGSN によって制御されている UTRAN へのシステム間変更が発生した場合、初

の SGSN は保存されている GSM の暗号鍵 Kc を target RNC を制御している（新）SGSN に送信する。新

SGSN は、サービスが提供されている間、新しいアンカーポイントとなる。想定される UMTS 加入者が

UMTS の鍵を使用することを確実にするために、（本ケースでは過剰ではあるが） R99+ ME が R98-SGSN から R99+ ME にシステム変更した時に、R99+ SGSN は新たな AKA を実行する。

ユーザ側では、いずれのケースでも、ME は保存されていた GSM の暗号鍵 Kc から(変換関数 c4 と c5 を使

用して) UMTS の暗号化／完全鍵 CK と IK を誘導し、それらを適用する。ケース c)では、新たな AKA が実

行されるので、これらの鍵は新しい CK と IK の組み合わせで上書きされる。

7 Void

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)51Release 1999

8 アプリケーションのセキュリティメカニズム（Application security mechanisms）

8.1 Void

8.2 Void

8.3 Mobile IP のセキュリティ（Mobile IP security） 3G 内のエンドユーザへの Mobile IP 機能の導入は、3G 用セキュリティアーキテクチャには何も影響を及ぼさない。

Mobile IP 端末は、3G ネットワークの範囲外のセキュリティ機能を可能にするために、3G のネットワークアクセスセ

キュリティとは独立してセキュリティ機能を実装することもできる。

Mobile IP サービスをサポートする 3G ネットワークは、3G 自体の本来のセキュリティ機能をサポートすること。

言い換えれば、Mobile IP のオプション機能の追加によって、3G ネットワークアクセスセキュリティアーキテクチャが

影響を受けたり損なわれることがあってはならない。

であるから、Mobile IP のセキュリティ機能については、3G ネットワークアクセスセキュリティとは切り離して、他のフ

ォーラム、IETF で議論すべきである。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)52Release 1999

Annex A (informative): Requirements analysis [ドキュメントの本パートでは、「フィーチャが要求条件に合致するか？」という疑問に答える]

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)53Release 1999

Annex B: Void

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)54Release 1999

Annex C (informative): Management of sequence numbers 本 annex では、認証と鍵合意プロトコル用のシーケンス番号の管理について述べる。

C.1 認証センタ内のシーケンス番号の生成（Generation of sequence numbers in the Authentication Centre）

C.1.1 シーケンス番号生成スキーム（Sequence number generation schemes）

C.1.1.1 一般的スキーム（General scheme）本仕様書の 6.3 節に従って、認証センタ（AuC）内でシーケンス番号を使用して認証ベクトルが生成される。本節で

は、これらのシーケンス番号の生成方法を規定する。AuC 内ではバッチ処理で認証ベクトルを生成し、送信すること

ができる。バッチ処理中の認証ベクトル用のシーケンス番号は、以下に説明するプロセスに従って、1 つずつ生成さ

れる。

(1) バイナリ表記すると、シーケンス番号は 2 つの部分から構成される。つまり、SQN = SEQ || IND IND はインデックスであり、C1.2 および C2.2 で説明される配列中で使用される。SEQ はさらに 2 つの連結パ

ートから構成され、 SEQ = SEQ1 || SEQ2 である。 SEQ1 は SEQ の MSB（most significant bit）を、SEQ2 は

SEQ の LSB（least significant bit）を表す。IND は SQN の LSB（least significant bit）を表す。

(2)HE 内にはカウンタ SQNHE が存在する。SQN はこのカウンタによって保存される。 SQNHE は独立したカウンタ、

すなわちユーザ毎に一意の値である。 SQNHE = SEQHE || INDHEとする。

(3) グローバルカウンタとして、例えばクロック生成ユニバーサル時刻などがある。簡略のために、このグローバ

ルカウンタを任意の時刻の GLC と呼ぶ。 GLC は、クロックから生成され、mod p で計算される。ここで、 p = 2n 、n は GLC の長さであり、ビット単位の SEQ2 である。

(4) GLC をクロックから生成する場合、 D > 0 となる数があり、以下の状態が適用される。 (i)並行的に増加する 2 つのクロック（クロックユニット）の時間間隔は、各ユーザに対して次のように選ばれる。

すなわち AuC において、任意の D クロックユニットの間に、ほとんどのバッチが生成される。 (ii)任意のユーザに対するバッチ生成平均レートと比較して、クロックレートが明らかに高いこと。 (iii) D << 2n.

(5) 認証ベクトルの新しいバッチを生成するために、HE が新しいシーケンス番号 SQN を必要とする場合には、

HE は（ユーザ固有の）値 SEQHE = SEQ1HE || SEQ2HE をデータベースから抽出する。 (i) SEQ2HE < GLC < SEQ2HE + p – D + 1 ならば、HE は SEQ= SEQ1HE || GLC とする (ii) GLC ≤ SEQ2HE ≤ GLC+D - 1 または SEQ2HE + p – D + 1 ≤ GLC ならば、HE は SEQ = SEQHE +1 とする (iii) GLC+D - 1 < SEQ2HE ならば、HE は SEQ = (SEQ1HE +1) || GLC とする。 (iv) 認証ベクトルの生成完了後、SEQHE は SEQ にリセットされる。 (v) IND の処理については、C.1.2 参照。

注

1. クロックユニットと値 D を選択する際には、任意の時刻において任意のユーザに対して条件 (4)(i)を満足する

ように充分注意して選択すること。一方、ユーザのアイデンティティのセキュリティは妥協してもよい。なぜなら

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)55Release 1999

ばパラメータさえ正しく選択されれば、特定のユーザに対するシーケンス番号からユーザのアイデンティティに

関する重要な情報が露見することはないからである。 CS ドメインと PS ドメインのための認証ベクトルをその他の手段で分離できない場合には、 2 つの異なるドメイ

ンからの要求が完全に独立して届くように、 D >1 とすることが推奨される。

2. 適切な方法で C.1.1.1 の (1)～(5)のパラメータを設定することによって、本節中で規定される一般的スキーム

は、以下のように、SEQ2 が空でかつ SEQ = SEQ1 の場合、また SEQ1 が空でかつ SEQ = SEQ2 の場合もカ

バーすることができる。 (a) SEQ2 が空の場合、シーケンス番号の生成は時間ベースではない。形式的に、SEQ2 ≡ GLC ≡ 0 (0 に等し

い) 、かつ D = 1 に設定する。条件 (4)(i)～(iii)は、クロックがないので適用されない。そして(5)(ii)は常に満た

され、SEQ は要求がある度に１ずつ増加する。読みやすくするために、このケースは C.1.1.2 で別に述べる。 (b) SEQ1 が空の場合、D = 1 に設定する。開始条件を SEQ2HE < GLC かつ AuC 内でエラーは発生しないも

のとすると、条件 (5)(i)は常に満足し、かつ要求がある度に SEQ = GLC となる。つまり、シーケンス番号の生

成は完全に時間ベースである。完全な時間ベースのシーケンス番号を生成する際に、AuC で発生する潜在

的なエラーを救済するための方法を、 Annex C1.1.3 で説明する。

C.1.1.2 時間ベースでないシーケンス番号の生成（Generation of sequence numbers which are not time-based）

HE/AuC は、ユーザ毎にカウンタの値を SQNHE = SEQHE || INDHE に維持すること。フレッシュなシーケンス番号を生

成するために、SEQHE は 1 ずつ増加され、新しいカウンタ値を使用して次の認証ベクトルを生成する。IND の処理に

ついては C.1.2 を参照。

C1.1.3 時間ベースのシーケンス番号の生成（Time-based sequence number generation）

バイナリ表記すると、シーケンス番号は 2 つのパートから構成される。すなわち、 SQN = SEQ || IND である。SEQ のパートは 2 つに分割されない。グローバルカウンタ GLC は SEQ と同様である。 HE 内の個別カウンタ SEQHE を保存

するかわりに、ユーザ毎に独立の値 DIF が HE 内に保存される。DIF の値は、該当ユーザのために生成された値

SEQ と GLC の現時点の差を表す。

HE が新しい認証ベクトルを生成するために新しいシーケンス番号が必要になる場合、HE はデータベースから（ユー

ザ固有の）値 DIF を抽出し、SEQ = GLC +DIF で SEQ の値を算出する。

HE 内の DIF の値を更新する必要があるのは、再同期処理の間だけである。この場合、DIF の値は次式に従って

設定される。すなわち、 DIF = SEQMS - GLC ここで SQNMS = SEQMS || INDMS は、USIM が再同期処理の中で送信する値である。

C1.2 配列メカニズムのサポート（Support for the array mechanism）本節は、C.1.1 節で説明した 3 つのスキーム全てに適用される。

認証ベクトルが生成されるたびに､AuC はストレージから INDHE の値を抽出し、適切な規則に従って該当ベクトルの

新しいインデックス値を割当てて、その値を SQN 内の適切なパートに入れる。インデックス値の範囲は 0 ～ a –1 で

あり、ここで a は配列のサイズである。

配列サイズ a の値の例を、Annex C.3 に示す。インデックス割当ての正確な規則については仕様化が完了していない。そのガイドラインを Annex C.3.4 に示す。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)56Release 1999

C.2 USIM 内のシーケンス番号の処理（Handling of sequence numbers in the USIM ）

本節では、シーケンス番号は Annex C.1 に従って生成されるものと仮定する。

USIM は、USIM が受け付けたシーケンス番号の値の配列を追跡し、配列中のも大きいシーケンス番号を、SQNMS

とすること。

C.2.1 USIM 内でのカウンタ値の周回の防止（Protection against wrap around of counter in the USIM）

USIM は、シーケンス番号の差分が大値 ∆よりも大きい場合には受け付けない。

(1) HE/AuC が正しく機能しているならば、MS が SEQ - SEQMS ≥ ∆ となるようなシーケンス番号を受信することが

ないよう、∆ の値は、充分大きな値とすること。

(2) USIM が寿命を迎えるまでに SEQMS の値が大バッチ番号値 SEQmax に達することがないよう、SEQmax に達するために必要な SEQmax /∆の小ステップ数は、充分大きな値とすること。

C.2.2 USIM 内のシーケンス番号の新鮮度検証（Verification of sequence number freshness in the USIM）

USIM は、これまでに受け付けたシーケンス番号コンポーネントの配列値 a を維持すること。：SEQMS (0), SEQMS (1),～SEQMS (a-1)。各配列エレメント内の初期シーケンス番号は 0 とすること。

受信したシーケンス番号の新鮮度を検証するために、USIM は受信した SQN の値を、SQN 内に含まれるインデック

ス値 IND を使用してインデックスされる配列エレメント内のシーケンス番号と比較する。つまり、配列エントリ SEQMS (i) 、ここで i = IND はインデックス値とする。

- SEQ > SEQMS (i) の場合、USIM はシーケンス番号の新鮮度が保証されたものとみなす。そして続いて SEQMS (i) を SEQ に設定すること。

- SEQ ≤ SEQMS (i) の場合、USIM は、配列内の任意の場所の、以前受け付けたシーケンス番号のうちも大き

な値、すなわち SQNMS を使用して、同期失敗メッセージを生成すること。

USIM は、SQNMS と受け付けたシーケンス番号 SQN の差分に、差分上限値 L を設定することができること。そのよう

な差分上限値が適用されたならば、上の条件に加えて、SQNMS - SQN < L が成立する場合に限り、USIM はシーケ

ンス番号を受け付けることができる。

C.2.3 注意（Notes） 1. 上述の配列メカニズムを使用すれば、ユーザがサービスネットワークから認証を外された場合に、前の

visited VLR/SGSN が未使用の認証ベクトルを削除する必要がなくなる(スーパー課金の概念)。（サービスネ

ットワークの）外にいるユーザが 2 つのサービスネットワークの間を頻繁に移動した場合に、シグナリングの観

点から、ユーザが戻った時にユーザ用の認証ベクトルを維持することによって、より効果的に使用することが

できる

2. 異なるモビリティ管理ドメイン（CS ドメインと PS ドメイン）から来た認証ベクトルが、2 つの VLR/SGSN 内でイン

ターリーブ方式で使用される場合、ユーザ認証要求が不当に拒否されるのを防ぐために、配列メカニズムを

使用することもできる。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)57Release 1999

3. VLR/SGSN が、ユーザの前の visit の間に獲得された新鮮な認証ベクトルを使用する場合、USIM はそれら

の値がたとえ未だ使用されていなくても、拒否することができる（なぜならば、配列サイズ a とその寿命 L は有

限値であるから）。であるから、シーケンス番号の拒否は通常のオペレーションでも起こりうる。つまり、（悪意

のある）リプレー攻撃やデータベース内でのエラーだけが原因ではない。

4. 本節で説明されるメカニズムによって、どの認証ベクトルが同一の VLR/SGSN に送信されたかを USIM が知

ることができる。ここでは、同一の VLR/SGSN に送信された認証ベクトルが常に正しい順序で使用されると

仮定することする。その結果、同一の VLR/SGSN に送信された認証ベクトルのうち、1 つのシーケンス番号だ

けを保存する必要がある。

5. SQNMS の例外を除き、SQNMSと受容されたシーケンス番号の差について、寿命 L (寿命限度)が適用される場

合には、配列のエントリを全長、保存する必要はない。

6. ∆に基づく条件(2)では、SQNmax /∆ の小値の認証が正常に行われてから、SQNMSがその大値に達する

ことができる。

7. Annex C.1.1.1 で説明したグローバルカウンタ GLC の∆ とサイズ n の選択に関しては制約がある。∆ は 2nよ

りも大きな値を選択すること。

C.3 シーケンス番号管理プロフィール（Sequence number management profiles）

本節では、C.1 および C.2 で定義されたパラメータの値を、理論的な方法で選択する方法の例を述べる。これらの例

は、実用的なシーケンス番号管理スキームを仕様化する際のリファレンスとして使われる。シーケンス番号生成スキ

ームの 3 つのタイプのそれぞれについて、値の組み合わせの例を 1 つ示す。

- 部分的な時間ベース、Annex C.1.1.1 に対応

- 非時間ベース、Annex C.1.1.2 に対応

- 完全な時間ベース、Annex C.1.1.3. に対応

C.3.1 プロフィール 1：部分的な時間ベースのシーケンス番号の管理（Profile 1: management of sequence numbers which are partly time-based）

シーケンス番号の生成（シーケンス番号の生成（シーケンス番号の生成（シーケンス番号の生成（Generation of sequence numbers））））

Annex C.1.1.1 で規定されるシーケンス番号の生成のための一般的スキームを以下に述べる。以下のパラメータ値

は、リファレンスとして提唱された値である。

クロックのタイムユニット（クロックのタイムユニット（クロックのタイムユニット（クロックのタイムユニット（Time unit of the clock））））: 1 秒

IND のビット長（のビット長（のビット長（のビット長（Length of IND in bits）））） = 5.

SQN2 のビット長（のビット長（のビット長（のビット長（ Length of SQN2 in bits）））） = n : 24 このことは、GLC が p = 2n = 224 秒 = 194 日後に周回することを意味する。この値を選択すれば、殆どのユーザは 1周期の間に低 1 回はアクティブになると考えられる。 SEQ1 のビット長 = 19 であることを示唆する。

開始条件（開始条件（開始条件（開始条件（Start conditions））））: 全てのユーザに対して SQNHE = 0 を選択し、GLC = 1 を選択すること。

到着率は一時的にクロックレートよりも高くする（到着率は一時的にクロックレートよりも高くする（到着率は一時的にクロックレートよりも高くする（到着率は一時的にクロックレートよりも高くする（Arrival rate temporarily higher than clock rate））））: D = 216を選択 D は C.1.1.1 中の条件(4)(ii)および (iii)を満たす限りにおいて、かなり大きな値を選択することができる。D の値とし

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)58Release 1999

て、 D = 216 = 65536 を選択するならば、18 時間以上の期間内で 65536 回以上のバッチ到着要求（これは実質的に

は不可能）がない限り、C.1.1.1 中の条件(4)(i)を満足する。

USIM 内のシーケンス番号の検証（内のシーケンス番号の検証（内のシーケンス番号の検証（内のシーケンス番号の検証（Verification of sequence numbers in the USIM））））

本処理は、Annex C.2 中で規定される USIM 内のシーケンス番号処理の後に行われる。

配列の長さ（配列の長さ（配列の長さ（配列の長さ（Length of the array））））: a = 32. この値は、6.3.2 節の要求条件、つまりシーケンス番号検証のためのメカニズムは、シーケンス番号が後から x 番

目に生成されたシーケンス番号の中にあるならば、それが受け入れられることを保証するものである。

周回に対する保護（周回に対する保護（周回に対する保護（周回に対する保護（Protection against wrap around））））: ∆ = 228とすること。 ∆の値として、∆ = 228 を選択することによって、悪者が USIM 内のカウンタを強制的に周回させようとアタックした場

合には、低限 SEQmax/∆ = 215 > 32,000 回、認証を成功させる必要がある（C.2.4 の注 6 参照）。ここでは、C.2.3 の

注 7 の要求条件により、 ∆ > p とする。

シーケンス番号の寿命（シーケンス番号の寿命（シーケンス番号の寿命（シーケンス番号の寿命（Age limit for sequence numbers））））このような上限値の使用はオプションである。パラメータ L の値の選択は、USIM にのみ影響を与える。パラメータ L の値は、その他のパラメータの選択には何のインパクトも与えず、完全にオペレータに裁量権があり、オペレータの

セキュリティポリシに依存する。それゆえに、ここでは特定の値を提示することはしない。例えばセキュリティポリシで、

x よりも古い認証ベクトルを拒絶するように規定したならば、クロックの時間単位は 1 秒であるから、L の値を x に設

定する必要がある。

ユーザの匿名性（ユーザの匿名性（ユーザの匿名性（ユーザの匿名性（User anonymity））））: SQN の値によって、ユーザが長時間トレースされることが防止される。であるか

ら、SQN の値を 6.3 節内で規定される匿名鍵で秘匿する必要はない。

C.3.2 プロフィール 2：非時間ベースのシーケンス番号の管理（Profile 2: management of sequence numbers which are not time-based）

シーケンス番号の生成（シーケンス番号の生成（シーケンス番号の生成（シーケンス番号の生成（Generation of sequence numbers））））




開始条件（開始条件（開始条件（開始条件（Start conditions））））: 全ユーザに対して SQNHE = 0 とする

USIM 内のシーケンス番号の検証（内のシーケンス番号の検証（内のシーケンス番号の検証（内のシーケンス番号の検証（Verification of sequence numbers in the USIM））））

配列の長さ（配列の長さ（配列の長さ（配列の長さ（Length of the array））））: a = 32

周回に対する保護（周回に対する保護（周回に対する保護（周回に対する保護（Protection against wrap around））））: ∆ = 228とする。 ∆の値として、∆ = 228 を選択することによって、悪者が USIM 内のカウンタを強制的に周回させようとアタックした場

合には、低限 SEQmax/∆ = 215 > 32,000 回、認証を成功させる必要がある（C.2.4 の注 6 参照）。C.2.3 の注 7 は適

用されない。

シーケンス番号の寿命（シーケンス番号の寿命（シーケンス番号の寿命（シーケンス番号の寿命（Age limit for sequence numbers））））: このケースではクロックは存在しない。であるから、「寿命」（“age”）限度は、SQNMS (6.3 節参照) と受信したシーケン

ス番号の差として許容される大値として解釈される。このような上限値の使用はオプションである。パラメータ L の

値の選択は、USIM にのみ影響を与える。パラメータ L の値は、その他のパラメータの選択には何のインパクトも与

えず、完全にオペレータに裁量権があり、オペレータのセキュリティポリシに依存する。それゆえに、ここでは特定の

値を提示することはしない。

ユーザの匿名性（ユーザの匿名性（ユーザの匿名性（ユーザの匿名性（User anonymity））））: : SQN の値によって、ユーザが長時間トレースすることが可能になる。であるか

ら、それを懸念する場合には、SQN の値を 6.3 節内で規定される匿名鍵で秘匿する必要がある。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)59Release 1999

C.3.3 プロフィール 2：完全な時間ベースのシーケンス番号の管理（Profile 3: management of sequence numbers which are entirely time-based）

シーケンス番号シーケンス番号シーケンス番号シーケンス番号の生成（の生成（の生成（の生成（Generation of sequence numbers））））



クロックのタイムユニット（クロックのタイムユニット（クロックのタイムユニット（クロックのタイムユニット（Time unit of the clock））））: 1 タイムユニット内に、認証ベクトルのバッチに対する要求が 2 つ

到着することがないように、クロックのタイムユニット値を選択する必要がある。値 = 0.1 秒


開始条件（開始条件（開始条件（開始条件（Start conditions））））: GLC = 1 かつ、全ユーザに対して、 DIF = 0.

USIM 内のシーケンス番号の検証（内のシーケンス番号の検証（内のシーケンス番号の検証（内のシーケンス番号の検証（Verification of sequence numbers in the USIM））））:

Annex C.2 内で規定される USIM 内のシーケンス番号の処理に従って行われる。

配列の長さ（配列の長さ（配列の長さ（配列の長さ（Length of the array））））: a = 32. この値は、6.3.2 節の要求条件、つまりシーケンス番号検証のためのメカニズムは、シーケンス番号が後から x 番

目に生成されたシーケンス番号の中にあるならば、それが受け入れられることを保証するものである。

周回に対する保護（周回に対する保護（周回に対する保護（周回に対する保護（Protection against wrap around））））: ∆ = 228とする。 ∆の値として、∆ = 228 を選択することによって、悪者が USIM 内のカウンタを強制的に周回させようとアタックした場

合には、低限 SEQmax/∆ = 215 > 32.000 回、認証を成功させる必要がある（C.2.4 の注 6 参照）。C.2.3 の注 7 の要

求条件は適用されない。

シーケシーケシーケシーケンス番号の寿命（ンス番号の寿命（ンス番号の寿命（ンス番号の寿命（Age limit for sequence numbers））））: このような上限値の使用はオプションである。パラメータ L の値の選択は、USIM にのみ影響を与える。パラメータ L の値は、その他のパラメータの選択には何のインパクトも与えず、完全にオペレータに裁量権があり、オペレータの

セキュリティポリシに依存する。それゆえに、ここでは特定の値を提示することはしない。例として、セキュリティポリシ

で、x よりも古い認証ベクトルを拒絶するように規定したならば、L の値を x に設定する必要がある。

ユーザのユーザのユーザのユーザの匿名性（匿名性（匿名性（匿名性（User anonymity））））: SQN の値によって、ユーザが長時間トレースされることが防止される。であるか

ら、SQN の値を 6.3 節内で規定される匿名鍵で秘匿する必要はない。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)60Release 1999

C.3.4 配列スキーム内のインデックス値の割当てガイドライン

（Guidelines for the allocation of the index values in the array scheme）

- 一般的規則一般的規則一般的規則一般的規則: 配列スキーム内で使用されるインデックス値 IND は、Annex C.1.2 に従い、値の範囲 0 ～ a-1内で定期的に割当てること。つまり、前に生成された認証ベクトルといっしょに使用されたインデックス値 INDは SQNHE内に保存され、次の認証ベクトルはインデックス値 IND +1 mod a を使用することを意味する。

追加情報が利用可能になった場合には、この一般的規則に対して例外を設けることが望ましい。それには以下のよ

うなものがある。

- 同一バッチ内で分配される認証ベクトルは、同一インデックス値を使用すること。

将来の release では、認証データ要求 MAP メッセージ内に、要求しているサービスノードとドメイン（CS または

PS）に関する情報と、認証発信元に関する情報が含まれる可能性もある。HLR と HLR/AuC のインタフェース

の実装に応じて、本情報を他のリソースから利用可能できるようにすることに注意。本情報が利用可能な場

合には、その情報を以下の方法で使用することが推奨される。しかし、本情報使用のサポートは、Annex C に対するクレームコンプライアンスに対する実装のために要求されることはない。

- 異なるサービスドメインに分配される認証ベクトルは、異なる値とすること（つまり、PS オペレーションと CS オ

ペレーション用に、それぞれ別のインデックス値の範囲を用意する）

- 前回の要求と同じ要求が同一サービスノードからあがってきた場合には、新しい要求に割当てるインデックス

値は前回要求時の値と同一とすること。

C.4 マルチベンダ環境下におけるインターオペラビリティのガ

イドライン（Guidelines for interoperability in a multi-vendor environment）

シーケンス番号の管理スキームの仕様は、同一のオペレータの制御下にある USIM と AuC にのみ影響を与える。

であるから、そのようなスキームの仕様の裁量権は、完全にオペレータにある。しかしながら、オペレータによっては

自身のスキームを特別に定義することを希望せず、その代わりにベンダに C.3 で説明したプロフィールに従ったスキ

ームのうちのどれか 1 つ、またはそれ以外のスキームを実装させてそれを継承することを希望することもありうる。そ

のようなオペレータが複数のベンダから USIM および／または AuC を調達し、かつある 1 つのベンダの AuC に収

容されている加入者を、異なるスキームを採用している他ベンダの AuC にスムーズに移行させることをオペレータが

希望する場合には、オペレータのドメイン内に実装されている全てのシーケンス番号管理スキームが、以下のガイド

ラインを忠実に守ることが必要である。

- USIM で SQN を検証する際には、C.1.2 および C.2 で規定された配列メカニズムを使用すること。

- Annex F との関係:シーケンス番号管理に関するより多くのパラメータ（寿命 L など）をシグナリングするために

AMF フィールドを使用する場合には、AMF のフォーマットと USIM によるその解釈が、オペレータのドメイン

内の全実装について同一であること。

- ∆ が規定された小値よりも大きいこと。 C.3.2 内で説明したスキームを C.2.3 の注 7 に適合させるために必要。 ∆ ≥ 228 を推奨。

- 時間ベースのスキームについては、異なる AuC のクロック同期に関して何も要求条件がない。完全時間ベー

スのスキームについては、ある AuC から他の AuC にユーザを移行させる場合に、以下の要求条件が満たさ

れていることが推奨される。つまり、

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)61Release 1999

ある AuC から他の AuC にユーザが移行した場合、DIF の値を適切な方法で更新すること。さらに具体的に

言えば、ユーザが AuC1 から AuC2 に移行した場合、AuC1 がプロフィール 3 を、AuC2 が任意のプロフィールを採用しているならば、AuC1 は SEQ_HE として GLC+DIF を AuC2 に送信する。受信側では、AuC2 がプロフ

ィール 3 を採用し、AuC1 が任意のプロフィールを採用しているならば、AuC2 は該当ユーザ用の DIF の値を DIF = SEQ_HE – GLC に設定すること。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)62Release 1999

Annex D: Void

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)63Release 1999

Annex E: Void

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)64Release 1999

Annex F (informative): AMF の使用例（Example uses of AMF）

F.1 複数の認証アルゴリズムと鍵のサポート（Support multiple Authentication algorithms and keys）

複数の認証と鍵合意のアルゴリズムの使用をサポートするためのメカニズムは、障害からの復旧について有効であ

る。AMF を使用して、特定の認証ベクトルを生成するために使用されるアルゴリズムと鍵を通知することもできる。

USIM は認証アルゴリズムのトラックと鍵識別子を保持し、受容されたネットワーク認証トークン内で受信した値に従

って更新する。

F.2 変更リストのパラメータ（Changing list parameters）本メカニズムは、C.2 で説明されたウインドウとリストのメカニズムと組み合わせて使用される。

リストを管理するために使用できるパラメータは、リスト内のエントリの数（リストサイズ）と、リスト内の上位バッチ

番号 SEQMと、受け付けられたバッチ番号 SEQ 内の差、受付可能 SEQMS – SEQ に基づく上位のリストである。これら

のパラメータのための適なメカニズムは時間経過と共に変化するので、メカニズムを動的に変更することは有効で

ある。AMF を使用して、ユーザが認証トークンを検証してどれを受け付けるか決定する際に使用される、大受容

可能なリストサイズまたは大許容差 SEQMS – SEQ を通知してもよい。

USIM は大受容可能リストサイズと大許容差 SEQMS – SEQ のトラックを保持し、それらの値を SEQ > SEQMS を満たす条件下で受信した値に従って更新する。

F.3 暗号鍵と完全鍵の寿命を制限するための閾値の設定（Setting threshold values to restrict the lifetime of cipher and integrity keys）

6.4.3 節によれば、USIM は受信したデータの量を制限するためのメカニズムを持ち、それらはアクセスリンク鍵の組

合わせによって保護される。オペレータは、AMF フィールドを使用して、USIM 内のこの限度を設定したり調整するこ

とができる。例えば、2 つの閾値を設定しておいて、AMF フィールドが USIM に対してそれらの値の切替を指示する

ことも可能である。

USIM は、鍵の組合せの寿命に対する限度を把握し、その値を受け付けられたネットワーク認証トークン内で受信し

た値に従って更新する。

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)65Release 1999

Annex G (informative): 改版履歴（Change history）

Change history TSG SA

# Version CR Tdoc SA New

VersionSubject/Comment

S_03 2.0.0 - - 3.0.0 Approved at SA#3 and placed under TSG SA Change Control S_04 3.0.0 001 SP-99308 3.1.0 Mechanism for data integrity of signalling messages S_04 3.0.0 002 SP-99308 3.1.0 Description of layer on which ciphering takes place S_04 3.0.0 003 SP-99308 3.1.0 Conditions on use of authentication information S_04 3.0.0 004 SP-99308 3.1.0 Modified re-synchronisation procedure for AKA protocol S_04 3.0.0 005 SP-99308 3.1.0 Sequence number management scheme protecting against USIM

lockout S_04 3.0.0 006 SP-99308 3.1.0 Criteria for Replacing the Authentication "Working Assumption" S_04 3.0.0 007 SP-99308 3.1.0 Functional modification of Network domain security mechanisms S_04 3.0.0 008 SP-99308 3.1.0 Cipher key lifetime S_04 3.0.0 009 SP-99308 3.1.0 Mechanism for user domain security S_04 3.0.0 010 SP-99308 3.1.0 Replacement of incorrect diagrams S_04 3.0.0 011 SP-99308 3.1.0 Precision of the status of annex B S_05 3.1.0 012 SP-99417 3.2.0 Re-organisation of clause 6 S_05 3.1.0 013 SP-99417 3.2.0 Integrity protection procedures S_05 3.1.0 014 SP-99417 3.2.0 Security of MAP-Based Transmissions S_05 3.1.0 015 SP-99417 3.2.0 Secure UMTS-GSM Interoperation S_05 3.1.0 016 SP-99417 3.2.0 Network-wide confidentiality S_05 3.1.0 017 SP-99417 3.2.0 Authentication management field S_05 3.1.0 018 SP-99417 3.2.0 Support for window and list mechanisms for sequence number

management in authentication scheme S_05 3.1.0 019 SP-99417 3.2.0 Modification of text for window and list mechanisms S_05 3.1.0 020 SP-99485 3.2.0 Cipher/integrity key setting S_05 3.1.0 021 SP99-496 3.2.0 A generalised scheme for sequence number management S_06 3.2.0 022r1 SP-99584 3.3.0 Refinement of Enhanced User Identity Confidentiality S_06 3.2.0 025 SP-99584 3.3.0 Length of KSI S_06 3.2.0 026r1 SP-99584 3.3.0 Mobile IP security S_06 3.2.0 027r1 SP-99584 3.3.0 Clarification of re-authentication during PS connections S_06 3.2.0 030 SP-99584 3.3.0 Handling of the MS UEA and UIA capability information S_06 3.2.0 031 SP-99585 3.3.0 Removal of alternative authentication mechanism described in annex

D S_06 3.2.0 032 SP-99584 3.3.0 Removal of network-wide encryption mechanism form application

security section S_06 3.2.0 033 SP-99584 3.3.0 Interoperation and intersystem handover/change between UTRAN

and GSM BSS S_06 3.2.0 034 SP-99584 3.3.0 Distribution of authentication data within one serving network domainS_06 3.2.0 035 SP-99584 3.3.0 Authentication and key agreement S_06 3.2.0 036 SP-99584 3.3.0 Sequence number management S_06 3.2.0 037r1 SP-99584 3.3.0 Authentication and key agreement S_06 3.2.0 038 SP-99584 3.3.0 Clarification on system architecture S_06 3.2.0 039 SP-99584 3.3.0 Updated definitions and abbreviations S_06 3.2.0 040 SP-99584 3.3.0 An authentication failure report mechanism from SN to HE - 3.3.0 - - 3.3.1 Editorial clean-up by MCC S_07 3.3.1 043 SP-000112 3.4.0 Clarification on cipher key and integrity key lifetime lifetime S_07 3.3.1 044 SP-000112 3.4.0 local Authentication and connection establishment S_07 3.3.1 045r3 SP-000075 3.4.0 Refinement EUIC S_07 3.3.1 047r2 SP-000077 3.4.0 Interoperation and intersystem handover/change between UTRAN

and GSM BSS S_07 3.3.1 048 SP-000112 3.4.0 Clarification on the reuse of Avs S_07 3.3.1 049 SP-000112 3.4.0 Authentication failure reporting S_07 3.3.1 050 SP-000112 3.4.0 Refinement of Cipher key and integrity key lifetime S_07 3.3.1 051r1 SP-000112 3.4.0 Conversion function c3 at USIM S_07 3.3.1 052r1 SP-000112 3.4.0 Trigger points of AFR during AKA S_07 3.3.1 053r1 SP-000112 3.4.0 Removal of EUIC from ‘Authentication Data Request’ procedure S_07 3.3.1 054r1 SP-000112 3.4.0 Clarification of the scope S_07 3.3.1 055 SP-000112 3.4.0 SQN Generation Requirements S_07 3.3.1 056r1 SP-000112 3.4.0 Identification of temporary identities S_07 3.3.1 057 SP-000112 3.4.0 Cipher key and integrity key selection S_07 3.3.1 058r1 SP-000112 3.4.0 Clarification on ciphering and integrity mode setting S_07 3.3.1 059 SP-000112 3.4.0 Clarification on when integrity protection is started S_07 3.3.1 061r1 SP-000112 3.4.0 Unsuccessful integrity check

3GPP

3GPP TS 33.102 V3.6.0 (2000-10)66Release 1999

Change history TSG SA

# Version CR Tdoc SA New

VersionSubject/Comment

S_07 3.3.1 062r1 SP-000112 3.4.0 Clarification on signalling messages to be integrity protected S_07 3.3.1 063r1 SP-000112 3.4.0 Clarification of the HFN handling S_07 3.3.1 064r2 SP-000077 3.4.0 Distribution and Use of Authentication Data between VLRs/SGSNs S_07 3.3.1 066r1 SP-000077 3.4.0 Ciphering S_07 3.3.1 067r1 SP-000077 3.4.0 Data integrity S_07 3.3.1 072 SP-000112 3.4.0 Clarification on ciphering and integrity protection at intersystem

handover S_07 3.3.1 073r1 SP-000044 3.4.0 MAP Security S_07 3.3.1 074 SP-000112 3.4.0 Clarification about CK and IK which are transmitted in clear over the

Iu-interface S_07 3.3.1 076 SP-000112 3.4.0 Cipher key and integrity key lifetime S_07 3.3.1 077 SP-000112 3.4.0 Cipher key and integrity key setting S_07 3.3.1 079r1 SP-000112 3.4.0 Local Authentication and connection establishment S_08 3.4.0 080 SP-000272 3.5.0 Clarification on ciphering and integrity protection at intersystem

handover S_08 3.4.0 083 SP-000272 3.5.0 Authentication and key agreement (minimal) S_08 3.4.0 084 SP-000272 3.5.0 Conversion functions for GSM-UMTS interoperation S_08 3.4.0 088r2 SP-000272 3.5.0 Initialisation of synchronisation for ciphering and integrity protection S_08 3.4.0 089 SP-000274 3.5.0 Addition of another variant of sequence number generation S_08 3.4.0 090 SP-000272 3.5.0 Clarification of BEARER and DIRECTION parameters S_08 3.4.0 091 SP-000274 3.5.0 Inclusion of the radio bearer identity to the integrity mechanism S_08 3.4.0 092 SP-000273 3.5.0 Removal of enhanced user identity confidentiality S_08 3.4.0 093 SP-000272 3.5.0 Removal of network domain security S_08 3.4.0 094 SP-000272 3.5.0 Cipher and integrity key update once every 24 hours S_08 3.4.0 096 SP-000272 3.5.0 Clarification on the HFN handling S_08 3.4.0 097r1 SP-000271 3.5.0 Align of note and star in figure 18 S_08 3.4.0 098 SP-000272 3.5.0 Security mode set-up procedure S_08 3.4.0 100 SP-000272 3.5.0 Replace COUNT by STARTCS and STARTPS S_08 3.4.0 102 SP-000273 3.5.0 Removal of NW Wide Encryption S_08 3.4.0 103r2 SP-000271 3.5.0 Clarification on terminology in user domain S_09 3.5.0 095R2 SP-000442 3.6.0 Handling of emergency call S_09 3.5.0 104r1 SP-000411 3.6.0 Re-transmission of authentication request using the same quintet S_09 3.5.0 105 SP-000442 3.6.0 Length of CFN S_09 3.5.0 106 SP-000442 3.6.0 Clarification on Sequence Numbers (SQN - SEQ) S_09 3.5.0 107 SP-000442 3.6.0 Replace IMUI and TMUI with IMSI and TMSI S_09 3.5.0 108 SP-000442 3.6.0 Replace Quintuplet by Quintet S_09 3.5.0 109 SP-000442 3.6.0 Conversion function c2 S_09 3.5.0 110 SP-000442 3.6.0 Update terminology regarding VLR/SGSN S_09 3.5.0 111 SP-000442 3.6.0 Start of ciphering S_09 3.5.0 112 SP-000442 3.6.0 Removal of ME triggered authentication during RRC connection S_09 3.5.0 113 SP-000442 3.6.0 Removal of EUIC S_09 3.5.0 114 SP-000442 3.6.0 Removal of duplicate text on USIM toolkit secure messaging and

addition of a reference to 02.48 and 03.48 instead. S_09 3.5.0 115 SP-000442 3.6.0 Removal of secure authentication mechanism negotiation. S_09 3.5.0 116 SP-000442 3.6.0 Removal of HE control of some aspects of security configuration S_09 3.5.0 117 SP-000442 3.6.0 Specification of authentication vector handling in serving network

nodes. S_09 3.5.0 118 SP-000442 3.6.0 Update of References S_09 3.5.0 119 SP-000412 3.6.0 Profiles for sequence number management S_09 3.5.0 120 SP-000442 3.6.0 Change of parameter value x regarding the capability of the USIM to

store information on past successful authentication events S_09 3.5.0 121 SP-000446 3.6.0 Clarifications on integrity and ciphering of radio bearers. S_09 3.5.0 122 SP-000445 3.6.0 Change of computation of the anonymity key in the re-

synchronisation procedure S_09 3.5.0 123 SP-000442 3.6.0 Clarification on condition on rejecting keys CK and IK S_09 3.5.0 124 SP-000442 3.6.0 Clarifications on the START parameter handling S_09 3.5.0 125 SP-000442 3.6.0 New FRESH at SRNC relocation S_09 3.5.0 126 SP-000442 3.6.0 Addition of authentication parameter lengths S_09 3.5.0 127 SP-000442 3.6.0 Clarifications on the COUNT parameters S_09 3.5.0 128 SP-000442 3.6.0 Minor editorial changes

3gpp ts 33.102 v3.6

Documents