Design and Implementation of SIM Functionality for TETRA-system on a Smart Card

(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 tekniska högskola

Linköpings universitet Linköpings universitet

(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: Jerry Falkcrona

Sectra Communications

Per Karlström

isy_{, Linköpings University}

Examinator: Ola Dahl

isy, Linköpings University

(4)

(5)

Avdelning, Institution Division, Department

Division of Computer Engineering Department of Electrical Engineering SE-581 83 Linköping Datum Date 2012-06-08 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport

URL för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-78597

ISBN — ISRN

LiTH-ISY-EX--12/4559--SE Serietitel och serienummer Title of series, numbering

ISSN —

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 ambu-lance, 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 im-plements 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

(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 ser-vices, 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 ad-ministrator, 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 stan-dard 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 functional-ity 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.

(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 specifi-cations 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

(10)

(11)

3.2.3.1 PPS Procedure . . . 18 3.2.3.2 Error Handling . . . 18 3.3 File System . . . 18 3.3.1 DF – Dedicated Files . . . 19 3.3.2 EF – Elementary Files . . . 19 3.3.2.1 Transparent EF . . . 20 3.3.2.2 Linear Fixed EF . . . 20 3.3.2.3 Key EF . . . 21 3.3.2.4 Cyclic EF . . . 22 3.3.3 File Selection . . . 22 3.3.4 File IDs . . . 24 vii

(12)

viii CONTENTS

3.4 Security . . . 24

3.4.1 Authentication . . . 25

3.4.2 OTAR Cipher Key Distribution . . . 25

3.4.3 File Access . . . 26

3.5 Functions . . . 27

3.5.1 Mapping . . . 28

3.6 Contents of the EFs . . . 29

3.7 Procedures over the ME/SIM interface . . . 32

4 Architecture 35 4.1 File System . . . 35

4.1.1 File Access Conditions . . . 36

4.2 System Commands . . . 36

4.3 Authentication . . . 39

4.4 Package Structure . . . 40

5 Design 41 5.1 File System . . . 42

5.1.1 File Access Conditions . . . 43

5.1.2 File Commands . . . 44 5.1.2.1 SELECT . . . 44 5.1.2.2 READ BINARY . . . 45 5.1.2.3 UPDATE BINARY . . . 46 5.1.2.4 READ RECORD . . . 46 5.1.2.5 UPDATE RECORD . . . 48 5.1.2.6 SEEK . . . 48 5.1.2.7 INVALIDATE . . . 49 5.1.2.8 REHABILITATE . . . 50 5.2 Authentication . . . 50 5.2.1 GET RANDOM . . . 51 5.2.2 TA11/TA12 Algorithm . . . 52 5.2.3 TA21/TA22 Algorithm . . . 53 5.2.4 TB4/TE Algorithm . . . 54 5.2.5 GET RESPONSE . . . 55 5.3 Package Structure . . . 55 6 Verification 57 6.1 Requirement Verification . . . 57 6.2 Unit Test . . . 59 6.2.1 File System . . . 59 6.2.2 Authentication . . . 60

6.3 Card Acceptance Test . . . 62

6.3.1 File System . . . 62

6.3.2 Authentication . . . 62

6.4 Use Cases . . . 63

(13)

CONTENTS ix

6.4.2 Authentication Between SIM and the SwMI . . . 64

7 Conclusions 65

7.1 Results . . . 65 7.2 Conclusions . . . 66 7.3 Further Work . . . 66

(14)

(15)

1

Introduction

This master thesis evaluates the requirements for a Subscriber Identity Module (SIM) application for the Terrestrial Trunked Radio (TETRA) standard and pro-poses a design for implementing the SIM application on a smart card. This chap-ter gives a background to the maschap-ter 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 Insti-tute (ETSI). TETRA systems today support the use of a SIM card and most mod-ern 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.

(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 applica-tion.

• Suggest a software architecture and a software design that are suitable for the TSIM functionality on a smart card. The TSIM application and the ex-isting E2EE application shall coexist on one smart card.

• Implement the TSIM functionality on a smart card and develop tests to ver-ify 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.

1.2.1 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 ful-filled 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 3

1.4 Abbreviations

APDU Application Protocol Data Unit ATR Answer To Reset

CCK Common Cipher Key CPU Central Processing Unit DCK Derived Cipher Key

DCK1 Component one of the DCK DCK2 Component two of the DCK DF Dedicated File

DMO Direct-Mode Operation E2EE End to End Encryption

EEPROM Electrically Erasable Programmable Read Only Memory EF Elementary File

ETSI European Telecommunications Standards Institute, www.etsi.org FIPS Federal Information Processing Standard

GCK Group Cipher Key

GSM Global System for Mobile Communications HAL Hardware Abstraction Layer

IC Integrated Circuit ICC Integrated Circuit Chip

IEC International Electrotechnical Commission ISO International Organization for Standardization ITSI Individual TETRA Subscriber Identity

K Encryption Key, a key used by the authentication process for SwMI authentication

KE Key Encryption

KEK Key Encryption Key KS Session Authentication Key KS’ Session Authentication Key

ME Mobile Equipment

(18)

4 1 Introduction

MGCK Modified Group Cipher Key MMU Memory Management Unit MS Mobile Station

MSB Swedish Civil Contingencies Agency (Myndigheten för Samhällsskydd och Beredskap) www.msb.se

OS Operating System OTAK Over The Air Rekeying OTAR Over The Air Rekeying

PIN Personal Identification Number PMR Private Mobile Radio

PPS Protocol and Parameters Selection

Rakel Radio communication for effective leadership (Radiokommunikation för effektiv ledning) RAM Random Access Memory

RAND1 Random challenge 1 RAND2 Random challenge 2 RES1 Response 1

RES2 Response 2

RF Radio Frequency

RNG Random Number Generator

ROM Read Only Memory

RS Random Seed

SCK Static Cipher Key SDS Short Data Service

SIM Subscriber Identity Module SMS Short Message Service SW1 Status word 1

SW2 Status word 2

SwMI Switching and Management Infrastructure TBS TETRA Base Stations

(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 chan-nels 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 al-lows 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

(22)

8 2 Background

example, a police officer can use the TETRA terminal on the car as a gateway for his held device. A car terminal can operate at a higher effect than a hand-held 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

emer-gency 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.

(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 net-work at a maximum throughput of 19.2 kbit/s.

The services supported by the standard are continuously evolved by ETSI. [2]

2.1.1 Rakel

Rakel is a TETRA network and is Sweden’s national communication system for collaboration and leadership. The Swedish government owns Rakel’s infrastruc-ture and the Swedish Civil Contingencies Agency (MSB) is responsible for the expansion, operation, management, and development of Rakel as well as the mar-keting and sales of subscriptions. Today Rakel covers 99,84 % of the Swedish population and 95 % of the land area, excluding the mountain areas. The sys-tem 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 dif-ferent 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 pro-tected memory chip card. This card contains some hardwired data that can-not 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 ma-chine to provide encryption and authenticated access to on-board memory. The encrypted access to the memory is optional and supported by a file sys-tem provided with the wired logic chip card. The file syssys-tem 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 contact-less smart cards.

• Secure Microcontroller ICC cards: Microcontroller cards are the most com-plex 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, ap-plication 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 140-2 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.

• Hybrid Smart Cards: A hybrid smart card contains two microcontrollers; one supporting the contact interface and one supporting the contactless interface.

• Dual-Interface Smart Cards: A dual-interface smart card supports both the contact and contactless interface inside one microcontroller.

Active Chip Side

Chip Adhesive Chip

Metal Contacts

Card BodyEncapsulationSubstrate

Bond Wire Hotmelt

Figure 2.2: An illustration showing how the IC and contacts of a smart card can be embedded into a plastic card. Source: http://en.wikipedia.org/wiki/File:SIM_chip_structure_and_packaging.svg 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.

2.2.1 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: http://en.wikipedia.org/wiki/File:Telia_micro_SIM_with_brackets.jpg 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 http://www.etsi.org/.

2.3 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.

(27)

2.3 Sectra TETRA E2EE 13 OTAK server KEK End user Production TETRA Network End user smart card TETRA terminal Printer Log Log Printer SW

Empty smart card

1 4 3 Personalizer Printer Log 2 KEK

(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 require-ment 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 co-exist with the co-existing applications, in this case Sectras E2EE application.

ID Description M/O

A unique

requirement id A requirement description

Mandatory (M) or optional (O) Table 3.1:System requirement template.

The requirements given as shown in Table 3.1 are the requirements to be eval-uated during this master thesis. Requirements only described by the text are identified as important for a final product, but not important for a test imple-mentation. Either because they handle non software requirements or because they depend on the implementation environment.

(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 7816-1 [17] standard for both card types. Both card types have the same functionality but the physical characteristics differ. [6]

3.1.1 Format

On the ID-1 card, the identification number defined by EFI CCI D (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]

3.1.2 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: http://en.wikipedia.org/wiki/File:SmartCardPinout.svg

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 7816-3 [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 17

3.2 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 100 977 [7] and ETS 300 641 [5].

3.2.1 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.

Trans-missions 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]

3.2.2 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 3.2.3.1). [7]

3.2.3 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 100 977 [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 100 977 [7]. M

3

The information inside the ATR shall match both the requirements for a TSIM application and the existing Sectra

encryption functions.

M

(32)

18 3 Requirements

3.2.3.1 PPS Procedure

The PPS procedures shall be performed as described in ISO/IEC 7816-3 [17] and TS 100 977 [7].

3.2.3.2 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 3.3.1 and 3.3.2. MF DF2 DF1 DF12 DF11 DF111 EF 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

(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.

3.3.1 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. DFTETRAand DFTELECOMare 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 DFTETRA, and if nothing else is mentioned all Elementary Files (EFs) and second level DFs are defined under the DFTETRA.

ID Description M/O

7 A DF shall consist of a header but no body

part. M

Table 3.4:DF requirements.

3.3.2 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 3.3.2.1. M 10 The linear fixed EF shall function as

described in Section 3.3.2.2. M 11 The key EF shall function as described in

Section 3.3.2.3. O

12 The cyclic EF shall function as described in

Section 3.3.2.4. M

Table 3.5:EF requirements.

3.3.2.1 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

Body Sequence

of bytes

Figure 3.3:Structure of a transparent EF.

3.3.2.2 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.

(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

Body Record 1

Record n Record 2

Figure 3.4:Structure of a linear fixed EF.

3.3.2.3 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 Body Record 1 Record n Record 2

(36)

22 3 Requirements

3.3.2.4 Cyclic EF

Cyclic EF is used to store records in chronological order. The records are num-bered 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 Body Record 1 Record n Record 2

Figure 3.6:Structure of a cyclic EF.

In Section 5.1.2.4, 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]

3.3.3 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

(37)

3.3 File System 23 MF DF1 DF3 DF2 EF2 EF5 EF3 EF4 EF1

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 Valid Selections

MF DF1, DF2, EF1 DF1 MF, DF2, DF3, EF2 DF2 MF, DF1, EF3, EF4 DF3 MF, DF1, DF2, EF5 EF1 MF, DF1, DF2 EF2 MF, DF1, DF2, DF3 EF3 or EF4 MF, DF1, DF2 EF5 MF, DF1, DF3

Table 3.6: Allowed file selection for the example structure given in Fig-ure 3.7.

ID Description M/O

13 A file shall only be selected according to the rules given in EN 300 812-3 [6]. M Table 3.7:File selection requirements.

(38)

24 3 Requirements

3.3.4 File IDs

The following identifiers are reserved for use by TETRA ("X" can be values from "0" to "F"): [6] DF: – administrative use: "7F8X" – operational use: "7F10" DFTELECOM "7F90" DFTETRA EFs: – 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 300

812-3 [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 rele-vant to the SIM. For other security aspects of TETRA see EN 300 392-7 [9] and EN 300 396-6 [10].

The security of an MS is defined by a security class, see EN 300 392-7 [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]

3.4.1 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 300 392-7 [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 300 392-7 [9]. M Table 3.10:Authentication requirements.

3.4.2 OTAR Cipher Key Distribution

More about the Over The Air Rekeying (OTAR) can be read in EN 300 392-7 [9], EN 300 396-6 [10], and EN 300 812-3 [6].

(40)

26 3 Requirements

3.4.3 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 3.11. [6]

The different access levels are described below: [6]

NEVThe action can only be performed internally on the SIM and not over the SIM/ME interface.

AUTIThe 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.

PIN1The 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 ses-sion.

PIN2The action shall only be possible if one of the following conditions is ful-filled:

• 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.

ADMAllocation of these levels and the requirements that they demand are the responsibility of the appropriate administrative authority.

ALWThe command is always possible.

Level Access Condition

0 ALW 1 PIN1 2 PIN2 3 AUTI 4 to 14 ADM 15 NEV

(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 300 812-3 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 3.13.

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.

3.5.1 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 300 812-3 [6].

CLA INS P1 P2 Lc DATA Le

1 byte 1 byte 1 byte 1 byte 0-1 byte Lc bytes 0-1 byte

(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

EFICCID Card identification T M

EFDIR Application directory T O

EFLP Language preference T M

EFs at TETRA application level

EFSST SIM service table T M

EFITSI _{subscriber identity}Individual TETRA T M

EFITSIDIS ITSI disabled T M

EFUNAME Username T O

EFSCT Subscriber class table T M

EFPHASE Phase identification T M

EFCCK Common cipher key LF O

EFCCKLOC CCK location areas T O

EFSCK Static cipher Key LF O

EFGSSIS Static GSSIs LF M

EFGRDS Group related data for_{static GSSIs} LF M

EFGSSID Dynamic GSSIs LF M

EFGRDD Group related data for_{dynamic GSSIs} LF M

EFGCK Group cipher keys LF O

EFGINFO User’s group information T M

EFSEC Security settings T M

EFFORBID Forbidden networks C M

EFPREF Preferred networks LF O

EFSPN Service provider name T O

(44)

30 3 Requirements

EFNWT Network table LF M

EFGWT Gateway table LF M

EFCMT Call modifier table LF O

EFADNGWT _{number with gateways}Abbreviated dialling LF O

EFGWTEXT1 Gateway extension 1 LF O

EFADNTETRA

Abbreviated dialling numbers for TETRA

networks

LF O

EFEXTA Extension A LF O

EFFDNGWT Fixed dialling numbers_{with gateways} LF O

EFGWTEXT2 Gateway extension 2 LF O

EFFDNTETRA Fixed dialling numbers_{for TETRA network} LF O

EFEXTB Extension B LF O

EFLNDGWT Last number dialled with_gateways C O

EFLNDTETRA Last numbers dialled for

TETRA network C O

EFSDNGWT Service dialling number_{with gateway} LF O

EFGWTEXT3 Getaways extension 3 LF O

EFSDNTETRA Service dialling numbers_{for TETRA network} LF O

EFSTXT Status message texts LF O

EFMSGTXT SDS-1 message texts LF O

EFSDS123 Status and SDS type 1, 2_{and 3 message storage} LF O EFSDS4 SDS type 4 message

storage LF O

EFMSGEXT Message extension LF O

EFEADDR Emergence addresses LF M

EFEINFO Emergency call_information T M

EFDMOCh DMO radio channel_information LF O

EFMSCh MS allocation of DMO_channels T O

EFKH List of key holders T O

EFREPGATE DMO repeater and_{gateway list} LF O

EFAD Administrative data T M

(45)

3.6 Contents of the EFs 31

EFLNDComp Composite LND file C O

EFDFLSTSGT Status default target T O

EFSDSMEM_STATUS SDS memory status T O

EFWELCOME Welcome message T O

EFSDSR SDS delivery report LF O

EFSDSP SDS parameters LF O

EFDIALSC Dialling schemes for_{TETRA network} T M

EFAPN APN table LF O

EFPNI Private number_information LF O

EFSCAN Scan list files LF O

EFSCAND Scan list data LF O

EFDMO_GSSIS DMO pre-programmed_{group numbers} LF O

EFDMO_GRDS Grouped related data for_{DMO static GSSISs} LF O EFGTMO_GDMO TMO-DMO selected_{group association} LF O EFGDMO_GTMO DMO-TMO selected

group association LF O

EFDMO_DEP Default encryption_parameters T O

EFGSKO Group session key LF O

EFs at TELECOM level

EFADN Abbreviated dialling_numbers LF O

EFFDN Fixed dialling numbers LF O

EFMSISDN Mobile Station ISDN_Number LF O

EFLND Last number dilled C O

EFSDN Service dialling numbers LF O

EFEXT1 Extension 1 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 300 812-3 [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 300 812-3 [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 300 812-3 [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.

(48)

(49)

4

Architecture

This chapter describes the architecture of a TSIM application. The architecture is an extraction from the requirements described in Chapter 3. According to [3], software architecture is "the structure or structures of the system, which com-prises software elements, the externally visible properties of those elements, and the relations among them". Here, the architecture describes the general and struc-tural aspects of a TSIM application. To get more specific details about which files and functions that shall exist see Chapter 5.

4.1 File System

The file system is based on the file structure shown in Figure 4.1. The figure shows that the DFTETRA is located under the MF. All files that belong to the TSIM application shall reside under the DFTETRA.

MF

TETRA _APPLICATIONSOTHER

DF

Figure 4.1: The file structure showing the DF that is used by the TSIM ap-plication.

(50)

36 4 Architecture

4.1.1 File Access Conditions

In Section 3.4.3 all access conditions are given. Four of the access conditions are used to determine if a file can be read or updated. The four different access conditions and notations that are used are:

• NEV: The operation is never allowed on the file, the operation can be per-formed internally by the SIM.

• ALW: The operation is always allowed on the file.

• PIN1: The operation is allowed on the file if a valid user PIN has been entered.

• ADM: The operation is allowed on the file if a valid administrator PIN has been entered.

4.2 System Commands

In Section 3.5.1 the requirements for the mapping of commands are described. The command APDU is shown in Figure 4.2. The CLA, INS, P1 and P2 fields must be present. The Lc and DATA fields are only present if data is added to the command and the Le field is present if the terminal expects a response. The Le field specifies the amount of data that the terminal expects to be returned.

CLA INS P1 P2 Lc DATA Le

1 byte 1 byte 1 byte 1 byte 0-1 byte Lc bytes 0-1 byte

Figure 4.2:The format of a command APDU. [6]

The fields in the command APDU have the following meaning: [6] • CLA: The class of instruction, "A0" for the selected application. • INS: The instruction code for the specific command.

• P1, P2: Parameters for the instruction, specific use for each instruction. • Lc: The length of the data in the command APDU.

• DATA: The data that is sent together with the command.

(51)

4.2 System Commands 37

The response APDU is shown in Figure 4.3. The fields in the response APDU have the following meaning: [6]

• DATA: The response data.

• SW1, SW2: Status words to indicate a successful or unsuccessful command, see Table 4.1.

DATA SW1 SW2

Le-2 bytes 1 byte 1 byte

Le bytes

Figure 4.3:The format of a response APDU. [6]

Table 4.1 shows the coding of the status words SW1 and SW2 that are used with the response APDU.

SW1 SW2 Description

Correctly Executed Command

"90" "00" Normal ending of the command "9F" "XX" Length "XX" of the response data

Memory Management

"92" "0X" Command successful after using an internal update retry routine "X" times "92" "40" Memory problem

Referencing Management "94" "00" No EF selected "94" "02" Out of range (invalid address) "94" "04" File ID not found or pattern not found "94" "08" File is inconsistent with the command

Security Management "98" "02" No PIN initialized "98" "04"

Access condition not fulfilled unsuccessful due to PIN verification, at least one attempt

left or unsuccessful UNBLOCK PIN verification, at least one attempt left "98" "08" In contradiction with PIN status "98" "10" In contradiction with invalidation status "98" "40"

Unsuccessful PIN verification, no attempt left unsuccessful UNBLOCK PIN verification, no attempt left PIN blocked

UNBLOCK PIN blocked "98" "60" Manipulation flag set "98" "70" SwMI authentication unsuccessful

(52)

38 4 Architecture

SW1 SW2 Description

Application Independent Errors "67" "XX"

Incorrect parameter Lc ("XX" gives the correct length or states that no additional

information is given ("XX" = "00")) "69" "XX" Command not allowed (see Table 4.2 for the

coding of SW2)

"6A" "XX" Wrong parameter in P1 or P2 (see Table 4.3 for the coding of SW2)

"6B" "00"

Incorrect parameter P1 or P2 (When the error in P1 or P2 is caused by the addressed

record being out of range, "94 02" shall be used instead.)

"6D" "00" Unknown instruction code given in the command

"6E" "00" Wrong instruction class given in the command

"6F" "XX" Technical problem with no diagnostic given Table 4.1:The coding of the status words SW2 and SW1. [6]

SW2 Description

"00" No further information "82" Security status not satisfied "83" PIN blocked

"84" Referenced data invalidated "86" Command not allowed "89" Device driver inoperable

Table 4.2:The coding of the status word SW2 when SW1 = "69". [6]

SW2 Description

"80" Incorrect parameter in data field "81" Function code not supported "82" File not found "83" Record not found "86" Incorrect parameter in P1 of P2 "88" Referenced data not found

(53)

4.3 Authentication 39

4.3 Authentication

Figure 4.4 shows an overview of a mutual authentication between the SIM and the SwMI. In this process the algorithms TA11, TA12, TA21, TA22, and TB4 are performed in the SIM on the MS side.

The variables produced during the authentication process are specified in ETSI EN 300 392-7 [9] and the dimensions are shown in Table 4.4. These dimensions shall be kept to guarantee compatibility with the standard.

MS TA11 TA21 TA12 TA22 TB4 RS K RAND1 KS KS' RES1 _RAND2 XRES2 DCK1 DCK2 DCK Generate RAND2 Compare RES2 and XRES2 Authentication Centre BS SwMI TA11 TA21 K RS KS KS' RS, KS, KS' TA12 TA22 TB4 Generate RAND1 Compare RES1 and XRES1 KS RAND1 KS' RAND2 DCK1 DCK2 RES2 DCK XRES1 RAND1, RS RES1, RAND2 RES2, R1 R2

Figure 4.4:Mutual authentication between the SIM and SwMI. [9]

Parameter No. of bits

DCK 80 DCK1/DCK2 80 K 128 KS/KS’ 128 RAND1/RAND2 80 RES1/RES2 32 RS 80 XRES1/XRES2 32

(54)

40 4 Architecture

4.4 Package Structure

The software on the smart card is divided into packages. The package structure allows the smart card and its Memory Management Unit (MMU) to manage the internal security, to ensure that one package cannot access another package with-out permission. The packages used for the TSIM application can be seen in Fig-ure 4.5.

Crypto Package Authentication_Package Interpreter

Package

OS Package

Registry Package

HAL Package Security Layer_Package Card/Development Packages

Application Packages

Figure 4.5:The packages on the smart card.

The packages are divided into two groups, application packages and card/devel-opment packages.

The card/development packages include the Hardware Abstraction Layer (HAL) package and the Security Layer Package. These packages are parts of the smart card and the development environment. They handle the on chip security and the calls to the different parts of the smart card. These packages can only be accessed by the OS Package. To use any of the functions that are accessed through either the HAL packge or the Security Layer Package, the function call must pass through the OS Package.

The OS Package does not contain an OS, it is just a name for the package con-taining the functions to be used when using the functionality in the HAL and Security Layer Packages.

(55)

5

Design

This chapter presents the design of the system. The design shall comply with the architecture described in Chapter 4. The design shall be testable, to provide a way to verify the requirements given in Chapter 3. The verification is described in Chapter 6.

Requirements 1 to 3 are covered by the existing ATR in the smart card. For more information about how the ATR shall be built, see ETSI TS 100 977 [7] and ISO/IEC 7816-3 [17].

The same situation holds for requirement 21, since the smart card application has support for two levels of PIN, and the functions VERIFY PIN, CHANGE PIN, DISABLE PIN, ENABLE PIN and UNBLOCK PIN. For more information about the PIN see ETSI EN 300 812-3 [6].

One important change compared to if only a TSIM application is implemented is that no application is created for TSIM. Instead, the files and functions described below shall be accessible from the already existing E2EE application. This means that the terminal, instead of selecting the TSIM application prior to using the TSIM functions and files, selects the E2EE application and can from the E2EE application use the files and functions belonging to the TSIM application. The reason is that the E2EE application must be selected to get a TSIM application with E2EE functionality and only one application can be selected at a time in a smart card.

(56)

42 5 Design

5.1 File System

The implemented files are given in Table 5.1, the files listed are selected from Table 3.14 because they are listed as mandatory. The table shows the file hierar-chy, the file type, and the file identifier. All file types represented in Table 5.1 must be supported by the implementation. The functionality of each file type is described in Section 3.3.2 and the functions operating on the files are described in Section 5.1.2.

File Description Structure File ID

Files under MF

DFTETRA The DF that contains the_{TETRA specific files} DF "7F90" EFICCID Unique card identification_number T "2FE2" EFDIR A list of applications that are_{supported by the card} T "2F00" EFLP Language preference T "2F05"

Files under DFTETRA EFSST

SIM service table, indicates which of the optional services

and EFs that are available

T "6F01" EFITSI Individual TETRA subscriber_identity T "6F02" EFITSIDIS Indicates if ITSI is temporarily_disabled T "6F03"

EFSCT

Subscriber class table, holds the class membership of the ITSI

subscription

T "6F05" EFPHASE Phase identification T "6F06"

EFGSSIS

Static GSSIs, contains the pre-programmed group

identities

LF "6F0A" EFGRDS Group related data for static

GSSIs LF "6F0B"

EFGSSID Dynamic GSSIs, contains the_{dynamic group identities} LF "6F0C" EFGRDD Group related data for dynamic

GSSIs LF "6F0D"

EFGINFO

User’s group information, contains the user’s last active

group, preferred groups and information about using these

groups addresses

T "6F10"

(57)

5.1 File System 43

File Description Structure File ID

EFFORBID Forbidden networks C "6F12"

EFDNWRK Broadcast network information,_{see ETSI EN 300 392-2 [8]} LF "6F16" EFNWT

Network table, contains the network part of the TETRA

addresses

LF "6F17"

EFGWT

Gateway table, contains the names and addresses for gateways in the TETRA network

LF "6F18" EFEADDR Emergence addresses LF "6F2C"

EFEINFO Emergency call information T "6F2D"

EFAD

Administrative data, contains information about the mode of

operation

T "6F32" EFDIALSC Dialling schemes for TETRA_network T "6F46" Table 5.1: The file structure, shows the hierarchy and the file identifiers. More information about the content of the files and how the bytes are coded can be found in ETSI EN 300 812-3 [6]. T = Transparent EF, LF = Linear fixed EF, C = Cyclic EF. [6]

5.1.1 File Access Conditions

The files have different access conditions that must be met before the file can be read or updated. Table 5.2 shows the read and update access conditions for the files that shall be present in the system.

In addition to the access conditions given in Table 5.2, the INVALIDATE and REHABILITATE commands have their own access conditions for each file. For the files that shall be implemented, these two operations require the ADM access condition to be fulfilled.

File Read Access Conditions

Update Access Conditions Files under MF

EFICCID ALW NEV

EFDIR ALW ADM

EFLP ALW PIN1

Files under DFTETRA

EFSST PIN1 ADM

EFITSI PIN1 ADM

EFITSIDIS PIN1 ADM

EFSCT PIN1 ADM

(58)

44 5 Design

File Read Access Conditions

Update Access Conditions

EFGSSIS PIN1 ADM

EFGRDS PIN1 PIN1

EFGSSID PIN1 ADM

EFGRDD PIN1 PIN1

EFGINFO PIN1 PIN1

EFSEC PIN1 ADM

EFFORBID PIN1 PIN1

EFDNWRK PIN1 ADM

EFNWT PIN1 PIN1

EFGWT PIN1 ADM

EFEADDR ALW PIN1

EFEINFO ALW PIN1

EFAD ALW ADM

EFDIALSC PIN1 ADM

Table 5.2: The read and update conditions for the files that shall be imple-mented. [6]

5.1.2 File Commands

5.1.2.1 SELECT

The SELECT command is already implemented in Sectra’s E2EE application. The command is used to select a file according to the rules for file selection described in Section 3.3.3. The input and the output can be seen below: [6]

• Input from ME: File ID • Input from SIM: None • Output to ME:

– Selected file is a MF or a DF:

file ID, total memory space available, PIN enabled/disabled indica-tor, PIN status

– Selected file is an EF:

file ID, file size, access conditions, invalidate/not invalidate indica-tor, structure of the EF, and length of the records in case of linear fixed structure of cyclic structure

The command APDU can be seen in Table 5.3.

The response from the SELECT command depends on the file type selected. For an MF or DF Table 5.5 shows the response and for an EF Table 5.6 shows the response. More details about the SELECT command can be found in ETSI TS 102 221 [11].

(59)

5.1 File System 45

Class INS P1 P2 Lc Data Le

"A0" "A4" "XX" "XX" length Table 5.4 -/"00"

Table 5.3: The command APDU for SELECT, P1 and P2 values depends on how the SELECT command shall be used see ETSI TS 102 224 [11]. [11]

Byte(s) Description Length

1 to length

File ID, DF name or path to file

(depends on P1) length Table 5.4:SELECT command data. [6]

Description Tag

File descriptor "82" File identifier "83" Proprietary information (only for MF) "A5" Life cycle status integer "8A"

Security attribute "8B", "8C" or "AB" PIN status template DO "C6"

Table 5.5:The order of the response data when SELECT is used on an MF or a DF. [11]

Description Tag

File descriptor "82" File identifier "83" Proprietary information (only for MF) "8A" Life cycle status integer "8A"

Security attribute "8B", "8C" or "AB" File size "80"

Table 5.6: The order of the response data when SELECT is used on an EF. [11]

5.1.2.2 READ BINARY

The READ BINARY command is already implemented in Sectra’s E2EE applica-tion. The command is used to read a stream of bytes from the current transparent EF. The read operation shall only be performed if the read access is satisfied for the current EF (see Section 4.1.1). The input and the output: [6]

• Input from ME: Relative address and the length of the string • Input from SIM: None

(60)

46 5 Design

• Output to ME: String of bytes

The command APDU can be seen in Table 5.7. The response parameters can be seen in Table 5.8.

"A0" "B0" offset high offset low - - length Table 5.7:The command APDU for READ BINARY. [6]

1 to

length Data to be read length

Table 5.8:READ BINARY response data. [6]

5.1.2.3 UPDATE BINARY

The UPDATE BINARY command is already implemented in Sectra’s E2EE appli-cation. The command updates the current transparent EF with a string of bytes. This function shall only be performed if the UPDATE access condition for the EF is satisfied (see Section 4.1.1). The input and the output are given below: [6]

• Input from ME: Relative address and the length of the string, string of bytes

• Input from SIM: None • Output to ME: None

The command APDU can be seen in Table 5.9. The command parameters can be seen in Table 5.10.

"A0" "D6" offset high offset low length Table 5.10 -Table 5.9:The command APDU for UPDATE BINARY. [6]

1 to

length Data length

Table 5.10:UPDATE BINARY command data. [6]

5.1.2.4 READ RECORD

The READ RECORD command is partly implemented in Sectra’s E2EE applica-tion. The functionality already implemented does only support linear fixed EF.