ETSI EN 300 175-7 V1.6.1 (2002-02)
Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 7: Security features
Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 7: Security features
REN/DECT-000194-7
Digitalne izboljšane brezvrvične telekomunikacije (DECT) - Skupni vmesnik (CI) - 7. del: Varnostne lastnosti
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-julij-2005
'LJLWDOQHL]EROMãDQHEUH]YUYLþQHWHOHNRPXQLNDFLMH '(&7 6NXSQLYPHVQLN &,
GHO 9DUQRVWQHODVWQRVWL
Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 7:
Security features
Ta slovenski standard je istoveten z: EN 300 175-7 Version 1.6.1
ICS:
33.070.30 'LJLWDOQHL]EROMãDQH Digital Enhanced Cordless
EUH]YUYLþQHWHOHNRPXQLNDFLMH Telecommunications (DECT)
'(&7
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
European Standard (Telecommunications series)
Digital Enhanced Cordless Telecommunications (DECT);
Common Interface (CI);
Part 7: Security features
2 ETSI EN 300 175-7 V1.6.1 (2002-02)
Reference
REN/DECT-000194-7
Keywords
DECT, radio, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.fr
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2002.
All rights reserved.
ETSI
3 ETSI EN 300 175-7 V1.6.1 (2002-02)
Contents
Intellectual Property Rights.7
Foreword.7
Introduction .8
1 Scope.11
2 References.11
3 Definitions and abbreviations.12
3.1 Definitions.12
3.2 Abbreviations.13
4 Security architecture.14
4.1 Background.14
4.2 Security services.14
4.2.1 Authentication of a PT.14
4.2.2 Authentication of an FT.15
4.2.3 Mutual authentication.15
4.2.4 Data confidentiality.15
4.2.5 User authentication.15
4.3 Security mechanisms.15
4.3.1 Authentication of a PT.15
4.3.2 Authentication of an FT.16
4.3.3 Mutual authentication.17
4.3.4 Data confidentiality.18
4.3.4.1 Derived Cipher Key (DCK) .18
4.3.4.2 Static Cipher Key (SCK).18
4.3.5 User authentication.18
4.4 Cryptographic parameters and keys .19
4.4.1 Overview.19
4.4.2 Cryptographic parameters.19
4.4.3 Cryptographic keys.20
4.4.3.1 Authentication key K.20
4.4.3.2 Authentication session keys KS and KS'.21
4.4.3.3 Cipher key CK .22
4.5 Security processes.22
4.5.1 Overview.22
4.5.2 Derivation of authentication key, K.22
4.5.2.1 K is derived from UAK.23
4.5.2.2 K is derived from AC.23
4.5.2.3 K is derived from UAK and UPI.23
4.5.3 Authentication processes.23
4.5.3.1 Processes for the derivation of KS and KS'.24
4.5.3.2 Processes for the derivation of DCK, RES1 and RES2.24
4.5.4 Key stream generation .25
4.6 Combinations of security services.25
5 Algorithms for security processes .26
5.1 Background.26
5.1.1 A algorithm.26
5.2 Derivation of session authentication key(s).26
5.2.1 A11 process.26
5.2.2 A21 process.27
5.3 Authentication and cipher key generation processes.27
5.3.1 A12 process.27
5.3.2 A22 process.27
6 Integration of security .28
ETSI
4 ETSI EN 300 175-7 V1.6.1 (2002-02)
6.1 Background.28
6.2 Association of keys and identities .28
6.2.1 Authentication key.28
6.2.1.1 K is derived from UAK.28
6.2.1.2 K derived from AC.28
6.2.1.3 K derived from UAK and UPI .29
6.2.2 Cipher keys.29
6.3 NWK layer procedures.29
6.3.1 Background.29
6.3.2 Authentication exchanges.30
6.3.3 Authentication procedures.31
6.3.3.1 Authentication of a PT .31
6.3.3.2 Authentication of an FT .31
6.3.4 Transfer of Cipher Key, CK.31
6.4 MAC layer procedures .32
6.4.1 Background.32
6.4.2 MAC layer field structure .32
6.4.3 Data to be encrypted .33
6.4.4 Encryption process.33
6.4.5 Initialization and synchronization of the encryption process.36
6.4.6 Encryption mode control.36
6.4.6.1 Background.36
6.4.6.2 MAC layer messages.37
6.4.6.3 Procedures for switching to encrypt mode .37
6.4.6.4 Procedures for switching to clear mode .40
6.4.7 Handover of the encryption process .41
6.4.7.1 Bearer handover, uninterrupted ciphering.41
6.4.7.2 Connection handover, uninterrupted ciphering .42
6.4.7.3 External handover - handover with ciphering .42
6.4.8 Modifications for half slot specifications.42
6.4.8.1 Background.42
6.4.8.2 MAC layer field structure .43
6.4.8.3 Data to be encrypted.43
6.4.8.4 Encryption process.43
6.4.8.5 Initialization and synchronization of the encryption process .43
6.4.8.6 Encryption mode control.44
6.4.8.7 Handover of the encryption process.44
6.4.9 Modifications for double slot specifications.44
6.4.9.1 Background.44
6.4.9.2 MAC layer field structure .44
6.4.9.3 Data to be encrypted.44
6.4.9.4 Encryption process.45
6.4.9.5 Initialization and synchronization of the encryption process .45
6.4.9.6 Encryption mode control.46
6.4.9.7 Handover of the encryption process.46
6.4.10 Modifications for multi-bearer specifications.46
6.4.11 Modifications for 4- and 8- level modulation formats. .46
6.4.11.1 Background.46
6.4.11.2 MAC layer field structure .47
6.4.11.3 Data to be encrypted.50
6.4.11.4 Encryption process.50
6.4.11.5 Initialization and synchronization of the encryption process .53
6.4.11.6 Encryption mode control.53
6.4.11.7 Handover of the encryption process.53
6.5 Security attributes.53
6.5.1 Background.53
6.5.2 Authentication protocols.54
6.5.2.1 Authentication of a PT .54
6.5.2.2 Authentication of an FT .55
6.5.3 Confidentiality protocols.56
6.5.4 Access-rights protocols.58
6.5.5 Key numbering and storage .59
ETSI
5 ETSI EN 300 175-7 V1.6.1 (2002-02)
6.5.5.1 Authentication keys.59
6.5.5.2 Cipher keys.59
6.5.6 Key allocation.60
6.5.6.1 Introduction.60
6.5.6.2 UAK allocation.60
7 Use of security features .61
7.1 Background.61
7.2 Key management options.62
7.2.1 Overview of security parameters relevant for key management.62
7.2.2 Generation of authentication keys .63
7.2.3 Initial distribution and installation of keys .64
7.2.4 Use of keys within the fixed network .64
7.3 Confidentiality service with a Cordless Radio Fixed Part (CRFP).68
7.3.1 General.68
7.3.2 CRFP initialization of PT cipher key.68
Annex A (informative): Security threats analysis.69
A.1 Introduction.69
A.2 Threat A - Impersonating a subscriber identity.70
A.3 Threat B - Illegal use of a handset (PP).70
A.4 Threat C - Illegal use of a base station (FP) .70
A.5 Threat D - Impersonation of a base station (FP) .71
A.6 Threat E - Illegally obtaining user data and user related signalling information .71
A.7 Conclusions and comments.72
Annex B (informative): Security features and operating environments .74
B.1 Introduction.74
B.2 Definitions.74
B.3 Enrolment options.75
Annex C (informative): Reasons for not adopting public key techniques.76
Annex D (informative): Overview of security features .77
D.1 Introduction.77
D.2 Authentication of a PT .77
D.3 Authentication of an FT .78
D.4 Mutual authentication of a PT and an FT.78
D.4.1 Direct method.78
D.4.2 Indirect method 1.78
D.4.3 Indirect method 2.78
D.5 Data confidentiality.78
D.5.1 Cipher key derivation as part of authentication.79
D.5.2 Static cipher key .79
D.6 User authentication.79
D.7 Key management in case of roaming .79
D.7.1 Introduction.79
D.7.2 Use of actual authentication key K.80
D.7.3 Use of session keys.81
D.7.4 Use of precalculated sets .82
Annex E (informative): Limitations of DECT security.83
ETSI
6 ETSI EN 300 175-7 V1.6.1 (2002-02)
E.1 Introduction.83
E.2 Protocol reflection attacks.83
E.3 Static cipher key and short Initial Vector (IV) .83
E.4 General considerations regarding key management.84
E.5 Use of a predictable challenge in FT authentication .84
Annex F (informative): Security features related to target networks .85
F.1 Introduction.85
F.1.1 Notation and DECT reference model .85
F.1.2 Significance of security features and intended usage within DECT.85
F.1.3 Mechanism/algorithm and process requirements .86
F.2 PSTN reference configurations .87
F.2.1 Domestic telephone.87
F.2.2 PBX.88
F.2.3 Local loop.90
F.3 ISDN reference configurations.91
F.3.1 Terminal equipment.91
F.3.2 Network termination 2.92
F.3.3 Local loop.92
F.4 X.25 reference configuration.92
F.4.1 Data Terminal Equipment (DTE).92
F.4.2 PAD equipment.93
F.5 GSM reference configuration.93
F.5.1 Base station substation .93
F.5.2 Mobile station.93
F.6 IEEE.802 reference configuration.93
F.6.1 Bridge.93
F.6.2 Gateway.93
F.7 Public access service reference configurations .94
F.7.1 Fixed public access service reference configuration .94
Annex G (informative): Compatibility of DECT and GSM authentication .95
G.1 Introduction.95
G.2 SIM and DAM functionality .95
G.3 Using an SIM for DECT authentication.96
G.4 Using a DAM for GSM authentication .96
Annex H (informative): DECT Standard Authentication Algorithm (DSAA).97
Annex I (informative): Void .98
Annex J (informative): DECT Standard Cipher (DSC).99
Annex K (normative): Clarifications, bit mappings and examples for DSAA and DSC .100
K.1 Ambiguities concerning the DSAA.100
K.2 Ambiguities concerning the DSC DECT-standard cipher.102
Annex L (informative): Bibliography.103
History .104
ETSI
7 ETSI EN 300 175-7 V1.6.1 (2002-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (Telecommunications series) has been produced by ETSI Project Digital Enhanced Cordless
Telecommunications (DECT).
The present document is part 7 of a multi-part deliverable covering the Common Interface (CI) for the Digital Enhanced
Cordless Telecommunications (DECT), as identified below:
Part 1: "Overview";
Part 2: "Physical Layer (PHL)";
Part 3: "Medium Access Control (MAC) layer";
Part 4: "Data Link Control (DLC) layer";
Part 5: "Network (NWK) layer";
Part 6: "Identities and addressing";
Part 7: "Security features";
Part 8: "Speech coding and transmission".
The following cryptographic algorithms are subject to controlled distribution:
a) DECT standard cryptographic algorithms;
b) DECT standard cipher.
These algorithms are distributed on an individual basis. Further information and details of the current distribution
procedures can be obtained from the ETSI Secretariat at the address on the first page of the present document.
Further details of the DECT system may be found in TR 101 178 [6] and ETR 043 [7].
National transposition dates
Date of adoption of this EN: 1 February 2002
Date of latest announcement of this EN (doa): 31 May 2002
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 November 2002
Date of withdrawal of any conflicting National Standard (dow): 30 November 2002
ETSI
8 ETSI EN 300 175-7 V1.6.1 (2002-02)
Introduction
The present document contains a detailed specification of the security features which may be provided by DECT
systems. An overview of the processes required to provide all the features detailed in the present document is presented
in figure 1.
AC Authentication Code
IV Initialization Value obtained from frame counter
CK Cipher Key
Static Cipher Key
SCK
Authentication
KS Session Authentication Key
UAK [128]
Key Selection
KS' Reverse Authentication Key
B2
UPI [e.g. 128]
RAND F Value generated and transmitted by FP
RAND P Value generated and transmitted by PP
RES 1 Value computed and transmitted by PP
RES 2 Value computed and transmitted by FP
RS Value transmitted by FP in authentication protocol
UAK [128]
B1
UAK User authentication Key
UPI User Personal Identity
DCK Derived Cipher Key
K Authentication Key
AC [e.g. 16-32] A11, A12 Authentication Processes
B1
A21, A22 Authentication Processes
B1, B2 Authentication Key Stream Processes
K [128]
KSG Key Stream Generator
Authentication of
PP processes
RES1 [32]
A11
KS [128]
RS [64]
A12
RAND F [64]
DCK
CK [64]
Key
SCK
SCK [64]
KSG
Stream
IV [35]
Key Stream generation
Authentication of
for encryption process
FP processes
A21
KS' [128]
A22
RES2 [32]
RAND P [64]
Figure 1: Overview of DECT security processes
The present document consists of four main clauses (clauses 4 to 7), together with a number of informative and
important annexes (A to K). The purpose of this introduction is to briefly preview the contents of each of the main
clauses and the supporting annexes.
Each of the main clauses starts with a description of its objectives and a summary of its contents. Clause 4 is concerned
with defining a security architecture for DECT. This architecture is defined in terms of the security services which may
be offered (see clause 4.2), the mechanisms which shall be used to provide these services (see clause 4.3), the security
parameters and keys required by the mechanisms (challenges, keys, etc.), and which shall be passed across the air
interface or held within DECT Portable Parts (PPs), Fixed Parts (FPs) or other network entities
(for example management centres) (see clause 4.4), the processes which are required to provide the security
mechanisms (see clause 4.5), and the recommended combinations of services (see clause 4.6).
Clause 5 is concerned with specifying how certain cryptographic algorithms are to be used for the security processes.
Two algorithms are required:
- a key stream generator; and
- an authentication algorithm.
ETSI
9 ETSI EN 300 175-7 V1.6.1 (2002-02)
The key stream generator is only used for the encryption process, and this process is specified in clause 4.4. The
authentication algorithm may be used to derive authentication session keys and cipher keys, and is the basis of the
authentication process itself. The way in which the authentication algorithm is to be used to derive authentication
session keys is specified in clause 5.2. The way in which the algorithm is to be used to provide the authentication
process and derive cipher keys is specified in clause 5.3.
Neither the key stream generator nor the authentication algorithm is specified in the present document. Only their input
and output parameters are defined. In principle, the security features may be provided by using appropriate proprietary
algorithms. The use of proprietary algorithms may, however, limit roaming in the public access service environment, as
well as the use of PPs in different environments.
For example, for performance reasons, the key stream generator will need to be implemented in hardware in PPs and
FPs. The use of proprietary generators will then limit the interoperability of systems provided by different
manufacturers.
Two standard algorithms have been specified. These are the DECT Standard Authentication Algorithm (DSAA, see
annex H) and the DECT Standard Cipher (DSC, see annex J).
Because of the confidential nature of the information contained in them, these annexes are not included in the present
document. However, the algorithms will be made available to DECT equipment manufacturers. The DSAA may also
need to be made available to public access service operators who, in turn, may need to make it available to
manufacturers of authentication modules.
Clause 6 is concerned with integrating the security features into the DECT system. Four aspects of integration are
considered. The first aspect is the association of user security parameters (in particular, authentication keys) with DECT
identities. This is the subject of clause 6.2. The second aspect of integration is the definition of the NWK layer protocol
elements and message types needed for the exchange of authentication parameters across the air interface. This is dealt
with in clause 6.3. The MAC layer procedures for the encryption of data passed over the air interface are the subject of
clause 6.4. Finally, clause 6.5 is concerned with security attributes which DECT systems may support, and the NWK
layer messages needed to enable PPs and FPs to identify which security algorithms and keys will be used to provide the
various security services.
Clause 7 is concerned with key management issues. Careful management of keys is fundamental to the effective
operation of a security system, and clause 7.2 is intended to provide guidance on this subject. The clause includes an
explanation of how the DECT security features may be supported by different key management options.
For example, schemes which allow authentication keys to be held in a central location within a public access service
network are described, as are schemes which allow authentication keys to be derived locally in public access service
base stations. The clause is very much less specific than the other clauses in the present document. This is because the
key management issues discussed are not an integral part of the CI. In the end it is up to network operators and service
providers to decide how they are going to manage their cryptographic keys. The present document can at best provide
some suggestions and guidelines.
The main text is supplemented by a set of informative annexes. There are two types of annex. Those of the first type
provide background information justifying the inclusion of a particular service, or the use of a particular type of
mechanism in the security features. Those of the second type provide guidance on the use and management of certain of
the security features. The content of each of the annexes is briefly reviewed below.
Annex A contains the results of a security threats analysis which was undertaken prior to designing the DECT security
features.
Annex B is concerned with the impact of the security features on roaming, in particular with the concurrent use of a PP
in public access service, wireless Private Branch eXchange (PBX) and residential environments.
Annex C is provided for background information. It contains a justification for some of the decisions taken by EG-1, for
example, why symmetric rather than public key (asymmetric) cryptographic mechanisms were selected.
Annex D provides an overview of the DECT security features specified in the present document.
No security system is perfect, and annex E discusses the limitations of the DECT security features.
ETSI
10 ETSI EN 300 175-7 V1.6.1 (2002-02)
Annex F relates the security features specified in the present document to the DECT environments identified in
TR 101 178 [6]. Each of the local networks identified in the reference model is considered in turn. For each of these
networks a security profile is suggested. The networks considered are Public Switched Telephone Network (PSTN),
Integrated Services Digital Network (ISDN), X.25 [9], Global System for Mobile communications (GSM), Local Area
Networks (LANs) and public access service.
Annex G consists of a brief discussion of the compatibility of DECT and GSM authentication. In particular, the concept
of a DECT Authentication Module (DAM) is considered and its functio
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...