Institutionen för systemteknik

Transcription

1 Institutionen för systemteknik Department of Electrical Engineering Examensarbete Design and Implementation of SIM Functionality for TETRA-system on a Smart Card Examensarbete utfört i Elektroteknik vid Tekniska högskolan vid Linköpings universitet av Jonas Olofsson LiTH-ISY-EX--12/4559--SE Linköping 2012 Department of Electrical Engineering Linköpings universitet SE Linköping, Sweden Linköpings tekniska högskola Linköpings universitet Linköping

2

3 Design and Implementation of SIM Functionality for TETRA-system on a Smart Card Examensarbete utfört i Elektroteknik vid Tekniska högskolan vid Linköpings universitet av Jonas Olofsson LiTH-ISY-EX--12/4559--SE Handledare: Examinator: Jerry Falkcrona Sectra Communications Per Karlström isy, Linköpings University Ola Dahl isy, Linköpings University Linköping, 8 juni 2012

4

5 Avdelning, Institution Division, Department Division of Computer Engineering Department of Electrical Engineering SE Linköping Datum Date Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LiTH-ISY-EX--12/4559--SE Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version Titel Title Design och implementation av SIM-funktionalitet i ett smartcard för TETRA-systemet Design and Implementation of SIM Functionality for TETRA-system on a Smart Card Författare Author Jonas Olofsson Sammanfattning Abstract TETRA is an open radio standard developed by ETSI. It is specifically designed for use by government agencies, emergency services such as police forces, fire departments, and ambulance, public safety networks, train radios, transport services, and the military. The TETRA standard is used in the Swedish public safety net Rakel. Today the hand-held devices in Rakel do not use a SIM card to hold the user identity. Instead, the terminal is personalised by hard coding the user information in the terminal. As the users group grows a need for SIM cards will probably emerge since it simplifies the handling of the users for the network administrator, and allows the user to replace a broken terminal by simple moving his/her SIM card to another terminal. This master thesis examines the TSIM standard and extracts a specification of requirements, proposes a suitable software architecture, and partially implements TSIM functionality on a smart card. The conclusion is that a TSIM application can be integrated with an E2EE application but some modifications are needed compared to only having the TSIM functionality in the smart card. The design and architecture described in this master thesis can be used in systems that already use the SIM slot of the hand-held devices for a smart card that extends the functionality of the terminal. Nyckelord Keywords smart card, TETRA, sim

6

7 Abstract TETRA is an open radio standard developed by ETSI. It is specifically designed for use by government agencies, emergency services such as police forces, fire departments, and ambulance, public safety networks, train radios, transport services, and the military. The TETRA standard is used in the Swedish public safety net Rakel. Today the hand-held devices in Rakel do not use a SIM card to hold the user identity. Instead, the terminal is personalised by hard coding the user information in the terminal. As the users group grows a need for SIM cards will probably emerge since it simplifies the handling of the users for the network administrator, and allows the user to replace a broken terminal by simple moving his/her SIM card to another terminal. This master thesis examines the TSIM standard and extracts a specification of requirements, proposes a suitable software architecture, and partially implements TSIM functionality on a smart card. The conclusion is that a TSIM application can be integrated with an E2EE application but some modifications are needed compared to only having the TSIM functionality in the smart card. The design and architecture described in this master thesis can be used in systems that already use the SIM slot of the hand-held devices for a smart card that extends the functionality of the terminal. iii

8

9 Acknowledgments I would like to thank Sectra Communications AB for giving me the opportunity to carry out this master thesis. My supervisor at Sectra Jerry Falkcrona has been a great help with both the technical questions about smart cards, the ETSI specifications and the content and structure of the report. I would also like to thank my examiner and supervisor at Linköping University, Ola Dahl and Per Karlström, for the help with the content and technical details about the report. Last but not least, I would like to thank my opponent Mikael Rothin for good and constructive criticisms. Linköping, June 2012 Jonas Olofsson v

10

11 Contents 1 Introduction Background Goal Limitations Document Outline Abbreviations Background TETRA Terrestrial Trunked Radio Rakel Smart Card SIM Subscriber Identification Module Sectra TETRA E2EE Requirements SIM Characteristics Format Contacts Electronic Signals and Transmission Protocols States Baud Rate ATR - Answer To Reset PPS Procedure Error Handling File System DF Dedicated Files EF Elementary Files Transparent EF Linear Fixed EF Key EF Cyclic EF File Selection File IDs vii

12 viii CONTENTS 3.4 Security Authentication OTAR Cipher Key Distribution File Access Functions Mapping Contents of the EFs Procedures over the ME/SIM interface Architecture File System File Access Conditions System Commands Authentication Package Structure Design File System File Access Conditions File Commands SELECT READ BINARY UPDATE BINARY READ RECORD UPDATE RECORD SEEK INVALIDATE REHABILITATE Authentication GET RANDOM TA11/TA12 Algorithm TA21/TA22 Algorithm TB4/TE Algorithm GET RESPONSE Package Structure Verification Requirement Verification Unit Test File System Authentication Card Acceptance Test File System Authentication Use Cases Session Initialization

13 CONTENTS ix Authentication Between SIM and the SwMI Conclusions Results Conclusions Further Work Bibliography 67

14 x CONTENTS

15 1 Introduction This master thesis evaluates the requirements for a Subscriber Identity Module (SIM) application for the Terrestrial Trunked Radio (TETRA) standard and proposes a design for implementing the SIM application on a smart card. This chapter gives a background to the master thesis, the goals are described, and a list of abbreviations used in the report is presented. 1.1 Background SIM is a method to establish the identity of a subscriber and allow the operator to set the appropriate user privileges in a mobile network. SIM cards are today used in most types of mobile telephones and are mandatory according to the Global System for Mobile Communications (GSM) standard. TETRA is an open radio standard developed by the European Telecommunications Standards Institute (ETSI). TETRA systems today support the use of a SIM card and most modern TETRA terminals have a SIM slot. The SIM card functionality is currently not supported by the terminals in the Swedish public safety net Rakel; Rakel is the name of the TETRA network used by the Swedish emergency services. As TETRA is spread to a larger user group in the community the SIM functionality can be used to ease the handling of the subscribers for the network administrators. Sectra Communications AB, from here on referred to as Sectra, has developed an End to End Encryption (E2EE) system for a TETRA network. Sectra s E2EE system consist of a set of encryption functions. These encryption functions are implemented on a smart card that is placed in the SIM slot of the hand-held device. If a SIM card shall be used to hold the subscriber identity, it requires that the smart card used for encryption can handle the SIM functionality. 1

16 2 1 Introduction 1.2 Goal The goal with this master thesis is to examine the TETRA SIM (TSIM) standard, extract a specification of requirements, propose a suitable software architecture, and partially implement TSIM functionality on a smart card. The following work packages have been identified: Analyse the standard for TSIM by ETSI and investigate unclear parts. Select the requirements and functions that shall be provided by a SIM card for TETRA when the TSIM application shall coexist with an E2EE application. Suggest a software architecture and a software design that are suitable for the TSIM functionality on a smart card. The TSIM application and the existing E2EE application shall coexist on one smart card. Implement the TSIM functionality on a smart card and develop tests to verify the functionality. No physical terminal supporting the use of a SIM card is available for verification, so the tests performed are the only verification that the system works as intended Limitations Due to licensing and the process of obtaining access to some algorithms used in TETRA (for example the authentication algorithms), dummy algorithms are used when the algorithm is not available. This simplification allows for testing of the functionality but not of the actual compliance with a live network. 1.3 Document Outline A brief description of the following chapters is given below. Background: Gives background information about TETRA, smart cards and Sectra s TETRA E2EE system. Requirements: Describes and selects the requirements that must be fulfilled to implement a TSIM application. Architecture: Describes the system architecture. Design: Describes the design of the system. Verification: Describes the test cases used to verify the system. Conclusions: The last chapter describes what was found during the master thesis, thoughts about the findings, and future work.

17 1.4 Abbreviations Abbreviations APDU ATR CCK CPU DCK DCK1 DCK2 DF DMO E2EE EEPROM EF ETSI FIPS GCK GSM HAL IC ICC IEC ISO ITSI K KE KEK KS KS ME MF Application Protocol Data Unit Answer To Reset Common Cipher Key Central Processing Unit Derived Cipher Key Component one of the DCK Component two of the DCK Dedicated File Direct-Mode Operation End to End Encryption Electrically Erasable Programmable Read Only Memory Elementary File European Telecommunications Standards Institute, Federal Information Processing Standard Group Cipher Key Global System for Mobile Communications Hardware Abstraction Layer Integrated Circuit Integrated Circuit Chip International Electrotechnical Commission International Organization for Standardization Individual TETRA Subscriber Identity Encryption Key, a key used by the authentication process for SwMI authentication Key Encryption Key Encryption Key Session Authentication Key Session Authentication Key Mobile Equipment Master File

18 4 1 Introduction MGCK MMU MS MSB OS OTAK OTAR PIN PMR PPS Rakel RAM Modified Group Cipher Key Memory Management Unit Mobile Station Swedish Civil Contingencies Agency (Myndigheten för Samhällsskydd och Beredskap) Operating System Over The Air Rekeying Over The Air Rekeying Personal Identification Number Private Mobile Radio Protocol and Parameters Selection Radio communication for effective leadership (Radiokommunikation för effektiv ledning) Random Access Memory RAND1 Random challenge 1 RAND2 Random challenge 2 RES1 Response 1 RES2 Response 2 RF RNG ROM RS SCK SDS SIM SMS Radio Frequency Random Number Generator Read Only Memory Random Seed Static Cipher Key Short Data Service Subscriber Identity Module Short Message Service SW1 Status word 1 SW2 Status word 2 SwMI TBS TDMA Switching and Management Infrastructure TETRA Base Stations Time Division Multiple Access

19 1.4 Abbreviations 5 TETRA Terrestrial Trunked Radio TMO Trunked-Mode Operation TSIM TETRA SIM XRES1 Expected Response 1 XRES2 Expected Response 2

20

21 2 Background This chapter gives background information about TETRA and smart cards. A short description of Sectra s E2EE smart card for TETRA is also presented. 2.1 TETRA Terrestrial Trunked Radio TETRA is an open radio standard developed by the ETSI. The mandate to develop the TETRA standard was given by the European Commission. The standard is a digital trunked Private Mobile Radio (PMR) communication system. TETRA was specially designed for use by government agencies, emergency services such as police forces, fire departments and ambulance, public safety networks, train radios, transport services and the military. [2, 18] Time Division Multiple Access (TDMA) is used in TETRA to get four user channels on one radio carrier. 25 khz spacing is used between the radio carriers. Both point-to-point and point-to-multipoint transmissions can be used, meaning that one transmitter can communicate with one or more receivers. In addition to voice communication, data transmission is included in the standard. [18] A TETRA Mobile Station (MS) can communicate using Direct-Mode Operation (DMO) or Trunked-Mode Operation (TMO) using Switching and Management Infrastructure (SwMI) built of TETRA Base Stations (TBS). The use of DMO allows the MS to communicate with other MS in range even if there is no network coverage. This is particularly useful for emergency services when working during a catastrophe or undergrounds. TETRA includes a feature where one or more TETRA terminals can work as relays, and by doing this the network coverage is extended, as seen in Figure 2.1. For 7

22 8 2 Background example, a police officer can use the TETRA terminal on the car as a gateway for his hand-held device. A car terminal can operate at a higher effect than a handheld device. So by using the car terminal as a relay, the operative can use his/her hand-held device to communicate with the network even when the hand-held device does not have network coverage. [18] If two operatives wants to talk to each other using DMO, but are not in range of each other or the network, a third terminal in between can be used as a repeater. The third terminal then repeats the transmission between the operatives who want to communicate with each other. In this way, a terminal can work as relay for terminals that needs to communicate with each other. [18] 1 2 Figure 2.1: The car is connected via TMO with the TBS (1) and DMO with the operative (2). In this configuration the car s TETRA terminal works as a gateway for the operative. Example of services provided by the TETRA standard are: [2] Voice Services Group Calls: A voice service in TETRA that allows several users to talk to each other. Due to the complexity in supporting this in an effective and efficient way the public cellular networks are unsuitable. Pre-Emptive Priority Call (Emergency Call): Makes sure that an emergency call always gets through in the network, even if it means that another call has to be interrupted. Call Retention: Allows selected terminals to be protected from being forced off the network, for example due to a pre-emptive priority call. For the network to work properly, the number of terminals provided with call retention should be limited to a minimum. Priority Call: TETRA supports 16 different priority levels.

23 2.2 Smart Card 9 Dynamic Group Number: Allows for dynamic creation of groups via the network. This can be used to set up a group at for example, a crash site. Ambience Listening: Allows a dispatcher to listen to the sounds from a radio terminal without notifying the user. This mode can be used to listen to the background noise even if a call is not in progress. Call Authorized by Dispatcher: Allows a dispatcher to verify calls before they are allowed in the network. This can be very useful when the network is overloaded. Area Selection: Defines the area of operation for the user. Late Entry: Allows a user to join a group call that is in progress. Data Services Short Data Service: Short data messages similar to SMS. The message can be sent to one or many receivers. Packet Data: Allows for bigger data packages to be sent over the network at a maximum throughput of 19.2 kbit/s. The services supported by the standard are continuously evolved by ETSI. [2] Rakel Rakel is a TETRA network and is Sweden s national communication system for collaboration and leadership. The Swedish government owns Rakel s infrastructure and the Swedish Civil Contingencies Agency (MSB) is responsible for the expansion, operation, management, and development of Rakel as well as the marketing and sales of subscriptions. Today Rakel covers 99,84 % of the Swedish population and 95 % of the land area, excluding the mountain areas. The system is built to work in the worst possible situation and all base stations have additional power supplies, either in form of batteries or diesel generators. [1] Rakel has been put in place to replace the earlier systems used by the emergency services in Sweden and unite them under one communication system. The use of a common communication system allows for easier collaboration between different emergency services as well as other public vital organizations, for example power suppliers. [1] 2.2 Smart Card "Smart cards", "chip cards" or "integrated circuit cards" are terms used for the same thing [12]. In this document the term "smart card" will be used. A smart card is often a credit card sized device but can exist in other form factors, for example the SIM card used in mobile phones. One common thing for all smart cards is that they contain one or more Integrated Circuits (ICs). There

24 10 2 Background are three different types of ICs used in smart cards: memory only, wired logic and microcontroller. A short description of the different card types can be found below: [12] Memory Only ICC cards: Memory only cards use an electronic magnetic stripe. Compared to a magnetic card this gives the memory only cards a higher bandwidth, bigger storage capacity and a faster read/write speed. In addition the reader for a memory only card is cheaper than a magnetic stripe card reader. One variant of the memory only card is the serial protected memory chip card. This card contains some hardwired data that cannot be overwritten. This makes the card safer than the ordinary memory only card. Wired Logic ICC cards: Wired logic cards contain a logic-based state machine to provide encryption and authenticated access to on-board memory. The encrypted access to the memory is optional and supported by a file system provided with the wired logic chip card. The file system and command set of a wired logic chip card can only be reconfigured by redesigning the logic of the IC. Wired logic chip cards can exist as both contact and contactless smart cards. Secure Microcontroller ICC cards: Microcontroller cards are the most complex of the three types of cards. They contain a microcontroller, an OS and a read/write memory. The microcontroller ICs have been designed to meet different security targets, for example the Common Access Card IC criteria by the American Department of Defence. The commonly used term "Smart Card" often refers to this type of card. A secure microcontroller smart card usually consists of: 8-bit to 32-bit CPU. ROM or flash memory that contains the chip s OS and, optionally, application software. RAM for temporary registers to store temporary data. Non-volatile memory used for storage of user data, for example EEPROM, ferroelectric RAM or flash memory. Countermeasures against known and foreseen security threats, to achieve Common Criteria or FIPS certifications. Environmental sensors. At least one serial port for communication with a card reader. A random number generator. Timers Optional cryptography accelerator(s). Optional dedicated peripherals.

25 2.2 Smart Card 11 All of the above described cards exist in many different implementations on the market today. [12] To use a smart card, one must be able to communicate with them. There are two primary types of smart card interfaces: contact and contactless. The different card types are described below: [12] Contact Smart Cards: A contact smart card requires a direct connection to a conductive micromodule on the surface of the card. An example of how the IC of a contact smart card can be embedded into a plastic card can be seen in Figure 2.2. Contactless Smart Cards: The contactless smart card uses Radio Frequency (RF) waves to communicate with a reader. The smart card must often be close to the reader, generally within 10 centimetres. Chip Adhesive Hybrid Smart Cards: A hybridactive smartchip cardside Metal Contacts contains two microcontrollers; one supporting the contact interface andchip one supporting the contactless interface. Dual-Interface Smart Cards: A dual-interface smart card supports both the contact and contactless interface inside one microcontroller. Encapsulation Card Body Substrate Hotmelt Bond Wire Figure 2.2: An illustration showing how the IC and contacts of a smart card can be embedded into a plastic card. Source: The focus on the rest of this document will be on the contact version of the Secure Microcontroller Integrated Circuit Chip (ICC) card. The reason is that this is what a SIM usually is implemented as SIM Subscriber Identification Module SIM is typically an application implemented in a smart card. SIM cards replaces the need to personalize the mobile phone or TETRA terminal. Instead a SIM card can be used to hold the information about the subscriber and the subscription. A SIM card can vary in size, as seen in Figure 2.3. [6]

26 12 2 Background Figure 2.3: Micro SIM with mini SIM and full SIM brackets. Source: In TETRA, a special type of SIM standard called TSIM is used. It differs from the SIM used in GSM due to different needs in the networks. The TSIM standard has been developed by ETSI and can be found at Sectra TETRA E2EE Today Sectra has a smart card for E2EE in TETRA. The E2EE works on both voice and Short Data Service (SDS) and gives the user an encrypted connection from the transmitter to the receiver. The TETRA standard today only supports encryption over the air interface and not in the cables between the base stations. By using Sectra s E2EE solution, the transmissions are protected during the whole transmission. This is supported for both TMO and DMO transmissions. [16] Sectra s system consists of the smart card loaded into the SIM slot of the Mobile Equipment (ME), an Over The Air Rekeying (OTAK) server that handles the key distribution, a personalizer and the production of the smart cards. The system is shown in Figure 2.4 and the steps are described below: [16] 1. Production: During this step, the smart card is loaded with the software and is locked from future software changes. 2. Personalization: The smart card is loaded with a master key (KEK), the address to the OTAK server, and other user specific information. 3. End User: The smart card is handed over to the end user. 4. OTAK: A server sending encrypted messages with keys to the smart card.

27 2.3 Sectra TETRA E2EE 13 Empty smart card Log Printer Log Production Printer 1 SW Log KEK KEK Printer OTAK server Personalizer TETRA Network TETRA terminal End user smart card End user Figure 2.4: Sectra TETRA E2EE system overview. [15]

28

29 3 Requirements This chapter describes the requirements that shall be fulfilled according to the standard for TSIM from ETSI. The requirements for TSIM are analysed and the important requirements for this master thesis are extracted, and shown as seen in Table 3.1. In addition to each requirement, a short background on the requirement or where to read more about it is presented. Even if the standard shall be followed, not all requirements in the standard will be fulfilled during the master thesis. The reason for this is the limited time for the master thesis, so focus will be put on the mandatory software requirements. Some requirements regarding the physical characteristics of the smart card are out of scope of this thesis because they cannot be affected (for these requirements see Section 3.1 and Section 3.2). In addition to the TSIM requirements, the TSIM application must be able to coexist with the existing applications, in this case Sectras E2EE application. ID Description M/O A unique requirement id A requirement description Table 3.1: System requirement template. Mandatory (M) or optional (O) The requirements given as shown in Table 3.1 are the requirements to be evaluated during this master thesis. Requirements only described by the text are identified as important for a final product, but not important for a test implementation. Either because they handle non software requirements or because they depend on the implementation environment. 15

30 16 3 Requirements 3.1 SIM Characteristics The standard for TSIM specifies two psychical types of smart cards, "ID-1 SIM" and "Plug-in SIM"). The dimensions and mechanical characteristics shall follow the ISO/IEC [17] standard for both card types. Both card types have the same functionality but the physical characteristics differ. [6] Format On the ID-1 card, the identification number defined by EF ICCID (described in Section 3.6) must be printed on the card. On the plug-in SIM card, only the individual account identifier and the check digit of the IC card identification must be printed. [6] Contacts The position of the contacts on the smart card can be seen in Figure 3.1. C1 VCC C2 RST C3 CLK C4 C5 GND C6 VPP C7 I/O C8 Figure 3.1: An example of the pin locations on a smart card. Note that smart cards may differ in the layout of the contacts. Source: The contacts in position C4 and C8 must not be supported by the smart card or the ME in a SIM application. C6 is not allowed to be connected to anything in the smart card if not used by another application. If these contacts are present and not used by another application inside the smart card the terminal shall present them to the smart card as ground or high impedance. [6] When the device is turned off normally, the SIM card shall be deactivated as specified in ISO/IEC [17]. However, if the clock to the SIM card is stopped the ME can deactivate the contacts in any order, but the supply voltage must always be switched off last. [6] The contact pressure must be large enough to guarantee contact. The contact shall be guaranteed even if vibrations occur. The contact pressure shall never be greater than 0.5 N per contact. If the contact pressure is larger then this value, the smart card can be damaged. [6]

31 3.2 Electronic Signals and Transmission Protocols Electronic Signals and Transmission Protocols A SIM-card can support both 3 V and 5 V technologies, or only 5 V. [6] More information about limits for current and voltage can be found in TS [7] and ETS [5] States The SIM card can be in two different states while the power supply is on. [6] Operating State: The SIM is in this state when executing a command. Transmissions to and from the ME are also included. Idle State: The SIM is in this state at any other time. In this state, the temporary memory shall be kept. The SIM may also support a clock stop mode. Clock stop means that the ME is allowed to switch off the clock to the smart card. If the clock stop mode shall be used, the ME has to wait 1860 clock cycles after receiving the last character of the last request before switching off the clock. Before the first command is issued after the clock has been started, the ME has to wait at least 744 clock cycles. [6] Baud Rate The baud rate shall initially be set to (clock frequency)/372. During the rest of the transmissions the baud rate shall be kept, unless the Protocol and Parameters Selection (PPS) procedure has been performed and has been negotiated another baud rate (see Section ). [7] ATR - Answer To Reset Answer To Reset (ATR) is information that the SIM card presents to the ME at the beginning of a session. The information is presented after the ME resets the SIM card. The characters that are sent with the ATR are given and explained in TS [7]. [6] ID Description M/O 1 An ATR shall be presented by the SIM card at the beginning of every session. M 2 The ATR shall contain the information given in TS [7]. M 3 The information inside the ATR shall match both the requirements for a TSIM application and the existing Sectra encryption functions. M Table 3.2: ATR requirements.

32 18 3 Requirements PPS Procedure The PPS procedures shall be performed as described in ISO/IEC [17] and TS [7] Error Handling If something is wrong with the received ATR, the ME shall reset the SIM card again to receive a new ATR. If a bad ATR is received three times or more the ME is allowed to reject the SIM card, but the ME must try at least three times. [7] 3.3 File System The file system can be seen in Figure 3.2. This figure shows the relationship and hierarchy between the different file types that are defined in Section and MF DF2 DF1 EF DF12 DF11 DF111 EF EF EF EF Figure 3.2: File system overview. [6] Each file consists of a header and an optional body part. Operations on files can be performed by commands sent from the ME to the smart card. The commands "GET RESPONSE" and "STATUS" can extract the information stored in the header. In the header, information about the structure and attributes of the file is stored. This information is fixed during the personalization phase. In the body part of a file the actual data is stored. [6] Each file has a unique file ID. The file ID consists of two bytes. The first byte identifies the file type and can be seen below: [6] "3F": MF "7F": First level DF "5F": Second level DF "2F": EF under the MF "6F": EF under the first level DF

33 3.3 File System 19 "4F": EF under the second level DF The second byte is subject to the following rules: [6] The file ID shall be assigned when the file is created No files under the same parent shall have the same ID A child and any parent shall never have the same file ID ID Description M/O 4 A file shall consist of a header and an optional body part. M 5 Each file under a DF shall have a unique file ID. M 6 The file ID shall consist of two bytes, following the rules above. M Table 3.3: File system requirements DF Dedicated Files A Dedicated File (DF) is a grouping of files. It consists of itself and all files in the complete subtree (all files that has the DF in the parental hierarchy). The DF has no body. DF TETRA and DF TELECOM are two examples of DFs. Both are children of the Master File (MF) and can coexist in a multi-application card. This document will focus on the DF TETRA, and if nothing else is mentioned all Elementary Files (EFs) and second level DFs are defined under the DF TETRA. ID Description M/O 7 A DF shall consist of a header but no body part. M Table 3.4: DF requirements EF Elementary Files The EF consists of both a header and a body part. In TETRA four structures are used and they are described in the following subsections.

34 20 3 Requirements ID Description M/O 8 An EF shall consist of both a header and a body part. M 9 The transparent EF shall function as described in Section M 10 The linear fixed EF shall function as described in Section M 11 The key EF shall function as described in Section O 12 The cyclic EF shall function as described in Section M Table 3.5: EF requirements Transparent EF The Transparent EF body consists of a sequence of bytes. When one or more bytes shall be read or written, a relative start address and the number of bytes to operate on are indicated. The first byte in the body of a Transparent EF always has the relative address 0. The total length of the body can be found in the header. The EF structure can be seen in Figure 3.3. [6] Header Sequence of bytes Body Figure 3.3: Structure of a transparent EF Linear Fixed EF Linear Fixed EF consists of a sequence of records. All records have the same length and the records are numbered from 1 to n. The header stores the record length as well as the record length multiplied with the total number of records. Figure 3.4 shows the structure of a Linear Fixed EF. A Linear Fixed EF cannot keep more than 255 records and a record must not be greater than 255 bytes. [6] The following list describes the different ways of accessing a record inside the EF (if an action is aborted for some reason, the pointer shall keep the value that it had before the action was started): [6] Absolute by using the record number. When the record pointer is not set, the first and last record can be accessed.

35 3.3 File System 21 When the record pointer is set, one can perform actions on the current, next and previous record (unless the pointer is set to the last or first record). Identify a record using pattern seek starting: Forward from the start of the file. Forward from the next record of which the pointer is set (if not the pointer is set to the last record). Backwards from the end of the file. Backward from the previous record of which the pointer is set (if the pointer is not set to the first record). Header Record 1 Record 2 Body Record n Figure 3.4: Structure of a linear fixed EF Key EF A Key EF consists of a sequence of records of the same length. They are numbered from 1 to n. The header stores the length of a record as well as a multiple of the length and the number of records. The structure can be seen in Figure 3.5. To access a Key EF, only absolute addressing can be used and the address is the record number. One EF cannot store more than 255 records and the length of a record cannot exceed 255 bytes. This is the same limitations as for the Linear Fixed EF. [6] Header Record 1 Record 2 Body Record n Figure 3.5: Structure of a key EF.

36 22 3 Requirements Cyclic EF Cyclic EF is used to store records in chronological order. The records are numbered from 1 to n where n is the oldest record. The structure can be seen in Figure 3.6. The record numbers in a Cyclic EF are changing so that the newest records always is record 1. A cyclic EF consists of a fixed number of records with the same length. The last and the first records are linked together so that a cycle is formed. [6] Header Record 1 Record 2 Body Record n Figure 3.6: Structure of a cyclic EF. In Section , different modes are described for accessing the Cyclic EF. When updating a record the "PREVIOUS" mode shall be used, but when reading a record the modes "NEXT", "PREVIOUS", "CURRENT", or "RECORD NUMBER" can be used. The record pointer shall always point to the oldest record. If an action is aborted, the record pointer shall not be changed. The same limitation as for the above described EFs holds for the Cyclic EF as well, there can never be more than 255 records in the EF and a record cannot exceed 255 bytes. [6] File Selection After the ATR has been sent, the MF is selected as the "Current Directory". From here, other files can be selected. The TETRA system defines two levels of DFs under the MF. An example can be seen in Figure 3.7. [6] From the current file, the following files can be selected: [6] Any file that is an immediate child of the "Current Directory" Any DF that is an immediate child of the current DF The parent of the "Current Directory" The current DF The MF

37 3.3 File System 23 MF EF1 DF1 DF2 EF2 EF3 EF4 DF3 EF5 Figure 3.7: Example file structure. In order to select an EF, the DF for that EF must first be selected. An example of how files can be accessed can be seen in Table 3.6. The "Current Directory" is always set when the MF or a DF is selected, and the "Current EF" is cleared once a new "Current Directory" is set. The "Current EF" is set once an EF is selected. The "Current EF" is always a child of the "Current Directory". [6] Last Selected File MF DF1 DF2 DF3 EF1 EF2 EF3 or EF4 EF5 Valid Selections DF1, DF2, EF1 MF, DF2, DF3, EF2 MF, DF1, EF3, EF4 MF, DF1, DF2, EF5 MF, DF1, DF2 MF, DF1, DF2, DF3 MF, DF1, DF2 MF, DF1, DF3 Table 3.6: Allowed file selection for the example structure given in Figure 3.7. ID Description M/O 13 A file shall only be selected according to the rules given in EN [6]. M Table 3.7: File selection requirements.

38 24 3 Requirements File IDs The following identifiers are reserved for use by TETRA ("X" can be values from "0" to "F"): [6] DF: EFs: administrative use: "7F8X" operational use: "7F10" DF TELECOM "7F90" DF TETRA administrative use: "6FXX" in the DF "7F8X" "6FCX" in the DFs "7F90" and "7F10" "2FXX" in the MF "3F00" operational use: "6FXX" in the DFs "7F90" and "7F10" "2F1X" in the MF "3F00" The value "FFFF" shall never be used as a file identifier. [6] ID Description M/O 14 The reserved file IDs defined in EN [6] shall be used. M Table 3.8: File IDs requirements. 3.4 Security This section will only handle the security related TETRA features that are relevant to the SIM. For other security aspects of TETRA see EN [9] and EN [10]. The security of an MS is defined by a security class, see EN [9] for more information. Table 3.9 shows what the SIM needs to support in terms of functions and key storage for different security classes.

39 3.4 Security 25 Class Authentication Key Storage OTAR SCK OTAR GCK OTAR CCK 1 O n/a n/a n/a n/a 2 O SCK O n/a n/a 3 M DCK, CCK, GCK, MGCK O O M Table 3.9: Security class and provided services. M = mandatory, O = optional and n/a = not applicable. [6] Authentication The authentication process is built around a symmetric key. To read more about symmetric keys see [4]. The key shall be shared between two parties that shall be able to authenticate each other. The key must be kept secret from everyone else. The two authentication parties shall prove to each other that they know the shared key through the authentication process. The parties are the authentication center of the SwMI and the MS. The MS is representing the user as defined by the assigned Individual TETRA Subscriber Identity (ITSI). The SwMI can use a base station for the authentication process. [9] In the MS, the authentication key must be protected. A common way to do this is to force the user of the MS to enter a Personal Identification Number (PIN) before the authentication key can be used. [9] The authentication process is described in EN [9]. The requirements on the authentication process are given in Table 3.10 ID Description M/O 15 A shared key shall be used for the authentication process. M 16 The authentication key shall be protected. M 17 The authentication key shall be protected by a PIN. O 18 The authentication process shall follow the behaviour described in EN [9]. M Table 3.10: Authentication requirements OTAR Cipher Key Distribution More about the Over The Air Rekeying (OTAR) can be read in EN [9], EN [10], and EN [6].

40 26 3 Requirements File Access All files have specific access conditions for each command that can be performed on them. The access condition shall always be fulfilled before a requested action is performed. The different levels of access conditions can be seen in Table [6] The different access levels are described below: [6] NEV The action can only be performed internally on the SIM and not over the SIM/ME interface. AUTI The action can be performed by the MS over the SIM/ME interface if the previous action over the SIM/ME interface was a successful authentication of the SwMI. PIN1 The action is only possible if one of the following conditions is fulfilled: A correct PIN1 value has been presented to the SIM during the current card session. The PIN1 enabled/disabled indicator is set to disabled. UNBLOCK PIN1 has been successfully performed during the card session. PIN2 The action shall only be possible if one of the following conditions is fulfilled: A correct PIN2 value has been presented to the SIM during the current card session. UNBLOCK PIN2 has been successfully performed during the current card session. ADM Allocation of these levels and the requirements that they demand are the responsibility of the appropriate administrative authority. ALW The command is always possible. Level Access Condition 0 ALW 1 PIN1 2 PIN2 3 AUTI 4 to 14 ADM 15 NEV Table 3.11: Access condition level coding. [6]

41 3.5 Functions 27 ID Description M/O 19 It shall only be possible to access a file if its access condition has been met. M Table 3.12: File access requirements. 3.5 Functions A function is an operation that consists of a command being sent to the smart card from the terminal. The command then triggers an operation inside the smart card. The smart card then returns a response consisting of two status words telling how the operation went and optional data. This section lists the available commands. The following functions are described in EN V2.3.1 [6]: SELECT STATUS READ BINARY UPDATE BINARY READ RECORD UPDATE RECORD READ KEY SEEK VERIFY PIN CHANGE PIN DISABLE PIN ENABLE PIN UNBLOCK PIN INVALIDATE REHABILITATE TETRA Authentication Algorithms GET RANDOM TA11/TA12 TA21/TA22 TB4/TE

42 28 3 Requirements OTAR Algorithms TA32 TA41/TA48 TA41/TA52 TA71/TE TB7/TA52 TA41/TA92 TB7/TA52 The requirements on the functions are shown in Table ID Description M/O 20 Functions handling files shall exist if the corresponding file type exist. M 21 All PIN functions shall exist. M 22 The invalidate and rehabilitate function shall exist. O 23 The authentication functions shall exist. M 24 The OTAR functions shall exist. O Table 3.13: Function requirements Mapping Functions are mapped onto Application Protocol Data Units (APDUs) and are then used by the transmission protocol. An APDU can be a command APDU or a response APDU. Figure 3.8 shows a command APDU and Figure 3.9 shows a response APDU. [6] More about the specific combinations and codes that shall be used can be found in Section 4.2 and ETSI EN [6]. CLA INS P1 P2 Lc DATA Le 1 byte 1 byte 1 byte 1 byte 0-1 byte Lc bytes 0-1 byte Figure 3.8: The format of a command APDU. [6]

43 3.6 Contents of the EFs 29 DATA SW1 SW2 Le-2 bytes 1 byte 1 byte Le bytes Figure 3.9: The format of a response APDU. [6] 3.6 Contents of the EFs Table 3.14 shows the different EFs that should be present and under which DF they are located. If an EF is unassigned or cleared, all its bytes should be set to "FF". [6] EF Description Structure M/O EFs at MF level EF ICCID Card identification T M EF DIR Application directory T O EF LP Language preference T M EFs at TETRA application level EF SST SIM service table T M EF ITSI Individual TETRA subscriber identity T M EF ITSIDIS ITSI disabled T M EF UNAME Username T O EF SCT Subscriber class table T M EF PHASE Phase identification T M EF CCK Common cipher key LF O EF CCKLOC CCK location areas T O EF SCK Static cipher Key LF O EF GSSIS Static GSSIs LF M EF GRDS Group related data for static GSSIs LF M EF GSSID Dynamic GSSIs LF M EF GRDD Group related data for dynamic GSSIs LF M EF GCK Group cipher keys LF O EF GINFO User s group information T M EF SEC Security settings T M EF FORBID Forbidden networks C M EF PREF Preferred networks LF O EF SPN Service provider name T O EF DNWRK Broadcast network information LF M

44 30 3 Requirements EF Description Structure M/O EF NWT Network table LF M EF GWT Gateway table LF M EF CMT Call modifier table LF O EF ADNGWT Abbreviated dialling number with gateways LF O EF GWTEXT1 Gateway extension 1 LF O EF ADNTETRA Abbreviated dialling numbers for TETRA LF O networks EF EXTA Extension A LF O EF FDNGWT Fixed dialling numbers with gateways LF O EF GWTEXT2 Gateway extension 2 LF O EF FDNTETRA Fixed dialling numbers for TETRA network LF O EF EXTB Extension B LF O EF LNDGWT Last number dialled with gateways C O EF LNDTETRA Last numbers dialled for TETRA network C O EF SDNGWT Service dialling number with gateway LF O EF GWTEXT3 Getaways extension 3 LF O EF SDNTETRA Service dialling numbers for TETRA network LF O EF STXT Status message texts LF O EF MSGTXT SDS-1 message texts LF O Status and SDS type 1, 2 EF SDS123 and 3 message storage LF O EF SDS4 SDS type 4 message storage LF O EF MSGEXT Message extension LF O EF EADDR Emergence addresses LF M EF EINFO Emergency call information T M EF DMOCh DMO radio channel information LF O EF MSCh MS allocation of DMO channels T O EF KH List of key holders T O EF REPGATE DMO repeater and gateway list LF O EF AD Administrative data T M EF PREF_LA Preferred location areas T O

45 3.6 Contents of the EFs 31 EF Description Structure M/O EF LNDComp Composite LND file C O EF DFLSTSGT Status default target T O EF SDSMEM_STATUS SDS memory status T O EF WELCOME Welcome message T O EF SDSR SDS delivery report LF O EF SDSP SDS parameters LF O EF DIALSC Dialling schemes for TETRA network T M EF APN APN table LF O EF PNI Private number information LF O EF SCAN Scan list files LF O EF SCAND Scan list data LF O EF DMO_GSSIS DMO pre-programmed group numbers LF O EF DMO_GRDS Grouped related data for DMO static GSSISs LF O EF GTMO_GDMO TMO-DMO selected group association LF O EF GDMO_GTMO DMO-TMO selected group association LF O EF DMO_DEP Default encryption parameters T O EF GSKO Group session key LF O EFs at TELECOM level EF ADN Abbreviated dialling numbers LF O EF FDN Fixed dialling numbers LF O EF MSISDN Mobile Station ISDN Number LF O EF LND Last number dilled C O EF SDN Service dialling numbers LF O EF EXT1 Extension 1 LF O EF EXT2 Extension 2 LF O EF EXT3 Extension 3 LF O Table 3.14: Content of the EFs. [6] M/O = Mandatory/Optional according to [6], T = Transparent, LF = Linear fixed, C = Cyclic More information about file types and what the EFs contain can be found in ETSI EN [6].

46 32 3 Requirements ID Description M/O 25 The mandatory EFs given in Table 3.14 shall exist. M 26 The optional EFs given in Table 3.14 shall exist. O Table 3.15: Content of the EFs requirements. 3.7 Procedures over the ME/SIM interface During a TETRA network operation the SIM and ME exchange messages via the SIM/ME interface. This can be any of the following: [6] A command/response pair that consists of a command and its response. A procedure that consists of one or more command/response pairs. In ETSI EN [6] the procedures in Table 3.16 are described. Procedure Mode General Procedures Reading an EF ME Updating an EF ME Invalidating an EF ME SIM Management Procedures SIM initialization ME TETRA session initialization ME TETRA session termination ME Language preference request ME Administrative information request ME SIM service table request ME SIM phase request ME SIM presence detection ME PIN Related Procedures PIN verification MMI PIN value substitution MMI PIN disabling MMI PIN enabling MMI PIN unblocking MMI TETRA Security Related Procedures TETRA algorithms computation NET TETRA key computation NET ITSI request NET ITSI disabling NET Location Information NET Broadcast network information NET

47 3.7 Procedures over the ME/SIM interface 33 Forbidden networks information NET Subscription Related Procedures Username MMI Subscriber class request ME Group information MMI/NET User s group information ME/NET Call modifiers NET/ME Network information ME Dialling numbers MMI/ME SDS messages MMI Preferred networks MMI Service provider name ME ICCID ME Emergency addresses ME/MMI Table 3.16: List of procedures at the SIM/ME interface in TETRA network operation described in ETSI EN [6]. ME = Procedures automatically initiated by the ME. MMI = Procedures that requires human interactions. NET = Procedures initiated due to interactions between the MS and the TETRA infrastructure.