Design and Implementation of SIM Functionality for TETRA ...535645/FULLTEXT01.pdf · Design och implementation av SIM-funktionalitet i ett smartcard för TETRA-systemet Design and

Institutionen för systemteknikDepartment of Electrical Engineering

Examensarbete

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

Examensarbete utfört i Elektroteknikvid 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ögskolaLinköpings universitet Linköpings universitetSE-581 83 Linköping, Sweden 581 83 Linköping

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

Examensarbete utfört i Elektroteknikvid Tekniska högskolan vid Linköpings universitet

av

Jonas Olofsson


Handledare: Jerry FalkcronaSectra Communications

Per Karlströmisy, Linköpings University

Examinator: Ola Dahlisy, Linköpings University

Linköping, 8 juni 2012

Avdelning, InstitutionDivision, Department

Division of Computer EngineeringDepartment of Electrical EngineeringSE-581 83 Linköping

DatumDate

2012-06-08

SpråkLanguage

� Svenska/Swedish

� Engelska/English

�

�

RapporttypReport 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


Serietitel och serienummerTitle of series, numbering

ISSN

—

TitelTitle

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örfattareAuthor

Jonas Olofsson

SammanfattningAbstract

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

NyckelordKeywords smart card, TETRA, sim

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

Abstract

TETRA is an open radio standard developed by ETSI. It is specifically designedfor use by government agencies, emergency services such as police forces, firedepartments, and ambulance, public safety networks, train radios, transport ser-vices, and the military. The TETRA standard is used in the Swedish public safetynet Rakel. Today the hand-held devices in Rakel do not use a SIM card to holdthe user identity. Instead, the terminal is personalised by hard coding the userinformation in the terminal. As the users group grows a need for SIM cards willprobably 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 movinghis/her SIM card to another terminal. This master thesis examines the TSIM stan-dard and extracts a specification of requirements, proposes a suitable softwarearchitecture, and partially implements TSIM functionality on a smart card. Theconclusion is that a TSIM application can be integrated with an E2EE applicationbut some modifications are needed compared to only having the TSIM functional-ity in the smart card. The design and architecture described in this master thesiscan be used in systems that already use the SIM slot of the hand-held devices fora smart card that extends the functionality of the terminal.

iii

Acknowledgments

I would like to thank Sectra Communications AB for giving me the opportunityto carry out this master thesis. My supervisor at Sectra Jerry Falkcrona has beena 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 myexaminer 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 notleast, I would like to thank my opponent Mikael Rothin for good and constructivecriticisms.

Linköping, June 2012Jonas Olofsson

v

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 72.1 TETRA – Terrestrial Trunked Radio . . . . . . . . . . . . . . . . . . 7

2.1.1 Rakel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 SIM – Subscriber Identification Module . . . . . . . . . . . 112.3 Sectra TETRA E2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Requirements 153.1 SIM Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Electronic Signals and Transmission Protocols . . . . . . . . . . . . 173.2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3 ATR - Answer To Reset . . . . . . . . . . . . . . . . . . . . . 17

3.2.3.1 PPS Procedure . . . . . . . . . . . . . . . . . . . . 183.2.3.2 Error Handling . . . . . . . . . . . . . . . . . . . . 18

3.3 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 DF – Dedicated Files . . . . . . . . . . . . . . . . . . . . . . 193.3.2 EF – Elementary Files . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2.1 Transparent EF . . . . . . . . . . . . . . . . . . . . 203.3.2.2 Linear Fixed EF . . . . . . . . . . . . . . . . . . . . 203.3.2.3 Key EF . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2.4 Cyclic EF . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.3 File Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.4 File IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

vii

viii CONTENTS

3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.2 OTAR Cipher Key Distribution . . . . . . . . . . . . . . . . 253.4.3 File Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Contents of the EFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7 Procedures over the ME/SIM interface . . . . . . . . . . . . . . . . 32

4 Architecture 354.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 File Access Conditions . . . . . . . . . . . . . . . . . . . . . 364.2 System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Design 415.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1 File Access Conditions . . . . . . . . . . . . . . . . . . . . . 435.1.2 File Commands . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.2.1 SELECT . . . . . . . . . . . . . . . . . . . . . . . . 445.1.2.2 READ BINARY . . . . . . . . . . . . . . . . . . . . 455.1.2.3 UPDATE BINARY . . . . . . . . . . . . . . . . . . 465.1.2.4 READ RECORD . . . . . . . . . . . . . . . . . . . 465.1.2.5 UPDATE RECORD . . . . . . . . . . . . . . . . . . 485.1.2.6 SEEK . . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.2.7 INVALIDATE . . . . . . . . . . . . . . . . . . . . . 495.1.2.8 REHABILITATE . . . . . . . . . . . . . . . . . . . 50

5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.1 GET RANDOM . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.2 TA11/TA12 Algorithm . . . . . . . . . . . . . . . . . . . . . 525.2.3 TA21/TA22 Algorithm . . . . . . . . . . . . . . . . . . . . . 535.2.4 TB4/TE Algorithm . . . . . . . . . . . . . . . . . . . . . . . 545.2.5 GET RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Verification 576.1 Requirement Verification . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.2.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3 Card Acceptance Test . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.4.1 Session Initialization . . . . . . . . . . . . . . . . . . . . . . 63

CONTENTS ix

6.4.2 Authentication Between SIM and the SwMI . . . . . . . . . 64

7 Conclusions 657.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.3 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Bibliography 67

x CONTENTS

1Introduction

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 master thesis, the goals are described, and a list ofabbreviations used in the report is presented.

1.1 Background

SIM is a method to establish the identity of a subscriber and allow the operatorto set the appropriate user privileges in a mobile network. SIM cards are todayused in most types of mobile telephones and are mandatory according to theGlobal System for Mobile Communications (GSM) standard. TETRA is an openradio 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 notsupported by the terminals in the Swedish public safety net Rakel; Rakel is thename of the TETRA network used by the Swedish emergency services. As TETRAis spread to a larger user group in the community the SIM functionality can beused to ease the handling of the subscribers for the network administrators.

Sectra Communications AB, from here on referred to as Sectra, has developedan End to End Encryption (E2EE) system for a TETRA network. Sectra’s E2EEsystem consist of a set of encryption functions. These encryption functions areimplemented on a smart card that is placed in the SIM slot of the hand-helddevice. If a SIM card shall be used to hold the subscriber identity, it requires thatthe smart card used for encryption can handle the SIM functionality.

1

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 workpackages 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 cardfor TETRA when the TSIM application shall coexist with an E2EE applica-tion.

• Suggest a software architecture and a software design that are suitable forthe 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 cardis available for verification, so the tests performed are the only verificationthat the system works as intended.

1.2.1 Limitations

Due to licensing and the process of obtaining access to some algorithms used inTETRA (for example the authentication algorithms), dummy algorithms are usedwhen the algorithm is not available. This simplification allows for testing of thefunctionality 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 cardsand 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 masterthesis, thoughts about the findings, and future work.

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 forSwMI authentication

KE Key Encryption

KEK Key Encryption Key

KS Session Authentication Key

KS’ Session Authentication Key

ME Mobile Equipment

MF Master File

4 1 Introduction

MGCK Modified Group Cipher Key

MMU Memory Management Unit

MS Mobile Station

MSB Swedish Civil Contingencies Agency (Myndigheten förSamhä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

TDMA Time Division Multiple Access

1.4 Abbreviations 5

TETRA Terrestrial Trunked Radio

TMO Trunked-Mode Operation

TSIM TETRA SIM

XRES1 Expected Response 1

XRES2 Expected Response 2

2Background

This chapter gives background information about TETRA and smart cards. Ashort 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 developthe TETRA standard was given by the European Commission. The standard isa digital trunked Private Mobile Radio (PMR) communication system. TETRAwas specially designed for use by government agencies, emergency services suchas police forces, fire departments and ambulance, public safety networks, trainradios, 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. Bothpoint-to-point and point-to-multipoint transmissions can be used, meaning thatone transmitter can communicate with one or more receivers. In addition to voicecommunication, 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 ManagementInfrastructure (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 networkcoverage. This is particularly useful for emergency services when working duringa 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

8 2 Background

example, a police officer can use the TETRA terminal on the car as a gateway forhis hand-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/herhand-held device to communicate with the network even when the hand-helddevice does not have network coverage. [18]

If two operatives wants to talk to each other using DMO, but are not in range ofeach 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 whowant to communicate with each other. In this way, a terminal can work as relayfor 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 withthe operative (2). In this configuration the car’s TETRA terminal works as agateway 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 totalk to each other. Due to the complexity in supporting this in aneffective 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 thatanother call has to be interrupted.

– Call Retention: Allows selected terminals to be protected from beingforced off the network, for example due to a pre-emptive priority call.For the network to work properly, the number of terminals providedwith call retention should be limited to a minimum.

– Priority Call: TETRA supports 16 different priority levels.

2.2 Smart Card 9

– Dynamic Group Number: Allows for dynamic creation of groups viathe network. This can be used to set up a group at for example, a crashsite.

– Ambience Listening: Allows a dispatcher to listen to the sounds froma radio terminal without notifying the user. This mode can be used tolisten to the background noise even if a call is not in progress.

– Call Authorized by Dispatcher: Allows a dispatcher to verify callsbefore they are allowed in the network. This can be very useful whenthe 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 messagecan 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 forcollaboration and leadership. The Swedish government owns Rakel’s infrastruc-ture and the Swedish Civil Contingencies Agency (MSB) is responsible for theexpansion, operation, management, and development of Rakel as well as the mar-keting and sales of subscriptions. Today Rakel covers 99,84 % of the Swedishpopulation 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 haveadditional 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 emergencyservices in Sweden and unite them under one communication system. The useof a common communication system allows for easier collaboration between dif-ferent emergency services as well as other public vital organizations, for examplepower suppliers. [1]

2.2 Smart Card

"Smart cards", "chip cards" or "integrated circuit cards" are terms used for thesame 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 allsmart cards is that they contain one or more Integrated Circuits (ICs). There

10 2 Background

are three different types of ICs used in smart cards: memory only, wired logicand microcontroller. A short description of the different card types can be foundbelow: [12]

• Memory Only ICC cards: Memory only cards use an electronic magneticstripe. Compared to a magnetic card this gives the memory only cards ahigher bandwidth, bigger storage capacity and a faster read/write speed.In addition the reader for a memory only card is cheaper than a magneticstripe 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 memoryonly 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 system and commandset of a wired logic chip card can only be reconfigured by redesigning thelogic 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 anda read/write memory. The microcontroller ICs have been designed to meetdifferent security targets, for example the Common Access Card IC criteriaby the American Department of Defence. The commonly used term "SmartCard" often refers to this type of card. A secure microcontroller smart cardusually 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 achieveCommon 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.

2.2 Smart Card 11

All of the above described cards exist in many different implementations on themarket today. [12]

To use a smart card, one must be able to communicate with them. There are twoprimary types of smart card interfaces: contact and contactless. The differentcard types are described below: [12]

• Contact Smart Cards: A contact smart card requires a direct connection toa conductive micromodule on the surface of the card. An example of howthe IC of a contact smart card can be embedded into a plastic card can beseen 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 beclose 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 contactlessinterface.

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

Figure 2.2: An illustration showing how the IC and contactsof 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 SecureMicrocontroller Integrated Circuit Chip (ICC) card. The reason is that this iswhat 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 replacesthe need to personalize the mobile phone or TETRA terminal. Instead a SIM cardcan be used to hold the information about the subscriber and the subscription. ASIM card can vary in size, as seen in Figure 2.3. [6]

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 theSIM used in GSM due to different needs in the networks. The TSIM standard hasbeen 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 bothvoice and Short Data Service (SDS) and gives the user an encrypted connectionfrom the transmitter to the receiver. The TETRA standard today only supportsencryption 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 wholetransmission. 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 MobileEquipment (ME), an Over The Air Rekeying (OTAK) server that handles the keydistribution, a personalizer and the production of the smart cards. The system isshown in Figure 2.4 and the steps are described below: [16]

1. Production: During this step, the smart card is loaded with the softwareand is locked from future software changes.

2. Personalization: The smart card is loaded with a master key (KEK), theaddress 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.

2.3 Sectra TETRA E2EE 13

OTAK server

KEK

End user

Production

TETRANetwork

End usersmart cardTETRA

terminal

Printer

Log

Log

Printer

SW

Empty smart card

1

43

Personalizer

Printer Log

2

KEK

Figure 2.4: Sectra TETRA E2EE system overview. [15]

3Requirements

This chapter describes the requirements that shall be fulfilled according to thestandard for TSIM from ETSI. The requirements for TSIM are analysed and theimportant requirements for this master thesis are extracted, and shown as seenin 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 willbe fulfilled during the master thesis. The reason for this is the limited time forthe master thesis, so focus will be put on the mandatory software requirements.Some requirements regarding the physical characteristics of the smart card areout of scope of this thesis because they cannot be affected (for these requirementssee Section 3.1 and Section 3.2).

In addition to the TSIM requirements, the TSIM application must be able to co-exist with the existing applications, in this case Sectras E2EE application.

ID Description M/OA unique

requirement id A requirement descriptionMandatory (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 areidentified as important for a final product, but not important for a test imple-mentation. Either because they handle non software requirements or becausethey depend on the implementation environment.

15

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

3.1.1 Format

On the ID-1 card, the identification number defined by EFICCID (described inSection 3.6) must be printed on the card. On the plug-in SIM card, only theindividual account identifier and the check digit of the IC card identificationmust 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. Notethat 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 orthe ME in a SIM application. C6 is not allowed to be connected to anything in thesmart card if not used by another application. If these contacts are present andnot used by another application inside the smart card the terminal shall presentthem to the smart card as ground or high impedance. [6]

When the device is turned off normally, the SIM card shall be deactivated asspecified in ISO/IEC 7816-3 [17]. However, if the clock to the SIM card is stoppedthe ME can deactivate the contacts in any order, but the supply voltage mustalways be switched off last. [6]

The contact pressure must be large enough to guarantee contact. The contactshall be guaranteed even if vibrations occur. The contact pressure shall never begreater than 0.5 N per contact. If the contact pressure is larger then this value,the smart card can be damaged. [6]

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 100977 [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, thetemporary memory shall be kept.

The SIM may also support a clock stop mode. Clock stop means that the ME isallowed to switch off the clock to the smart card. If the clock stop mode shall beused, the ME has to wait 1860 clock cycles after receiving the last character ofthe last request before switching off the clock. Before the first command is issuedafter 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 ofthe transmissions the baud rate shall be kept, unless the Protocol and ParametersSelection (PPS) procedure has been performed and has been negotiated anotherbaud 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 thebeginning of a session. The information is presented after the ME resets the SIMcard. The characters that are sent with the ATR are given and explained in TS100 977 [7]. [6]

ID Description M/O

1An ATR shall be presented by the SIM card

at the beginning of every session.M

2The ATR shall contain the information given

in TS 100 977 [7].M

3

The information inside the ATR shall matchboth the requirements for a TSIMapplication and the existing Sectra

encryption functions.

M

Table 3.2: ATR requirements.

18 3 Requirements

3.2.3.1 PPS Procedure

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

3.2.3.2 Error Handling

If something is wrong with the received ATR, the ME shall reset the SIM cardagain to receive a new ATR. If a bad ATR is received three times or more the MEis 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 andhierarchy between the different file types that are defined in Section 3.3.1 and3.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 canbe 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 afile the actual data is stored. [6]

Each file has a unique file ID. The file ID consists of two bytes. The first byteidentifies 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

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

4A file shall consist of a header and an

optional body part.M

5Each file under a DF shall have a unique file

ID.M

6The 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 thecomplete subtree (all files that has the DF in the parental hierarchy). The DF hasno body. DFTETRA and DFTELECOM are two examples of DFs. Both are children ofthe Master File (MF) and can coexist in a multi-application card.

This document will focus on the DFTETRA, and if nothing else is mentioned allElementary Files (EFs) and second level DFs are defined under the DFTETRA.

ID Description M/O

7A 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 areused and they are described in the following subsections.

20 3 Requirements

ID Description M/O

8An EF shall consist of both a header and a

body part.M

9The transparent EF shall function as

described in Section 3.3.2.1.M

10The linear fixed EF shall function as

described in Section 3.3.2.2.M

11The key EF shall function as described in

Section 3.3.2.3.O

12The 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 morebytes shall be read or written, a relative start address and the number of bytes tooperate on are indicated. The first byte in the body of a Transparent EF alwayshas 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

BodySequenceof 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 samelength and the records are numbered from 1 to n. The header stores the recordlength 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 cannotkeep 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 ithad 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.

3.3 File System 21

• When the record pointer is set, one can perform actions on the current, nextand 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 thepointer 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 thepointer 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 numberedfrom 1 to n. The header stores the length of a record as well as a multiple of thelength and the number of records. The structure can be seen in Figure 3.5. Toaccess a Key EF, only absolute addressing can be used and the address is therecord number. One EF cannot store more than 255 records and the length ofa record cannot exceed 255 bytes. This is the same limitations as for the LinearFixed EF. [6]

Header

Body

Record 1

Record n

Record 2

Figure 3.5: Structure of a key EF.

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 inFigure 3.6. The record numbers in a Cyclic EF are changing so that the newestrecords always is record 1. A cyclic EF consists of a fixed number of records withthe same length. The last and the first records are linked together so that a cycleis 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. Whenupdating a record the "PREVIOUS" mode shall be used, but when reading arecord the modes "NEXT", "PREVIOUS", "CURRENT", or "RECORD NUMBER"can be used. The record pointer shall always point to the oldest record. If anaction is aborted, the record pointer shall not be changed. The same limitationas for the above described EFs holds for the Cyclic EF as well, there can never bemore 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". Fromhere, other files can be selected. The TETRA system defines two levels of DFsunder 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

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 exampleof how files can be accessed can be seen in Table 3.6. The "Current Directory" isalways set when the MF or a DF is selected, and the "Current EF" is cleared oncea 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 SelectionsMF DF1, DF2, EF1DF1 MF, DF2, DF3, EF2DF2 MF, DF1, EF3, EF4DF3 MF, DF1, DF2, EF5EF1 MF, DF1, DF2EF2 MF, DF1, DF2, DF3

EF3 or EF4 MF, DF1, DF2EF5 MF, DF1, DF3

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

ID Description M/O

13A file shall only be selected according to the

rules given in EN 300 812-3 [6].M

Table 3.7: File selection requirements.

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

14The 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] andEN 300 396-6 [10].

The security of an MS is defined by a security class, see EN 300 392-7 [9] formore information. Table 3.9 shows what the SIM needs to support in terms offunctions and key storage for different security classes.

3.4 Security 25

Class Authentication Key Storage OTARSCK

OTARGCK

OTARCCK

1 O n/a n/a n/a n/a2 O SCK O n/a n/a

3 MDCK, CCK,

GCK,MGCK

O O M

Table 3.9: Security class and provided services. M = mandatory, O = optionaland n/a = not applicable. [6]

3.4.1 Authentication

The authentication process is built around a symmetric key. To read more aboutsymmetric keys see [4]. The key shall be shared between two parties that shallbe able to authenticate each other. The key must be kept secret from everyoneelse. The two authentication parties shall prove to each other that they know theshared key through the authentication process. The parties are the authenticationcenter of the SwMI and the MS. The MS is representing the user as defined bythe assigned Individual TETRA Subscriber Identity (ITSI). The SwMI can use abase station for the authentication process. [9]

In the MS, the authentication key must be protected. A common way to do this isto force the user of the MS to enter a Personal Identification Number (PIN) beforethe authentication key can be used. [9]

The authentication process is described in EN 300 392-7 [9]. The requirementson the authentication process are given in Table 3.10

ID Description M/O

15A shared key shall be used for the

authentication process.M

16 The authentication key shall be protected. M

17The authentication key shall be protected by

a PIN.O

18The authentication process shall follow thebehaviour 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].

26 3 Requirements

3.4.3 File Access

All files have specific access conditions for each command that can be performedon them. The access condition shall always be fulfilled before a requested actionis performed. The different levels of access conditions can be seen in Table 3.11.[6]

The different access levels are described below: [6]

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

AUTI The action can be performed by the MS over the SIM/ME interface if theprevious action over the SIM/ME interface was a successful authenticationof 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 currentcard session.

• The PIN1 enabled/disabled indicator is set to disabled.

• UNBLOCK PIN1 has been successfully performed during the card ses-sion.

PIN2 The 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 currentcard session.

• UNBLOCK PIN2 has been successfully performed during the currentcard session.

ADM Allocation of these levels and the requirements that they demand are theresponsibility of the appropriate administrative authority.

ALW The command is always possible.

Level Access Condition0 ALW1 PIN12 PIN23 AUTI

4 to 14 ADM15 NEV

Table 3.11: Access condition level coding. [6]

3.5 Functions 27

ID Description M/O

19It 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 cardfrom the terminal. The command then triggers an operation inside the smartcard. The smart card then returns a response consisting of two status wordstelling how the operation went and optional data. This section lists the availablecommands.

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

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

20Functions handling files shall exist if the

corresponding file type exist.M

21 All PIN functions shall exist. M

22The invalidate and rehabilitate function

shall exist.O

23 The authentication functions shall exist. M24 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 arethen used by the transmission protocol. An APDU can be a command APDU ora response APDU. Figure 3.8 shows a command APDU and Figure 3.9 shows aresponse APDU. [6]

More about the specific combinations and codes that shall be used can be foundin 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

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

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 DFthey are located. If an EF is unassigned or cleared, all its bytes should be set to"FF". [6]

EF Description Structure M/OEFs at MF level

EFICCID Card identification T MEFDIR Application directory T OEFLP Language preference T M

EFs at TETRA application levelEFSST SIM service table T M

EFITSIIndividual TETRAsubscriber identity T M

EFITSIDIS ITSI disabled T MEFUNAME Username T O

EFSCT Subscriber class table T MEFPHASE Phase identification T MEFCCK Common cipher key LF O

EFCCKLOC CCK location areas T OEFSCK Static cipher Key LF O

EFGSSIS Static GSSIs LF M

EFGRDSGroup related data for

static GSSIs LF M

EFGSSID Dynamic GSSIs LF M

EFGRDDGroup related data for

dynamic GSSIs LF M

EFGCK Group cipher keys LF OEFGINFO User’s group information T M

EFSEC Security settings T MEFFORBID Forbidden networks C MEFPREF Preferred networks LF OEFSPN Service provider name T O

EFDNWRKBroadcast network

information LF M

30 3 Requirements

EF Description Structure M/OEFNWT Network table LF MEFGWT Gateway table LF MEFCMT Call modifier table LF O

EFADNGWTAbbreviated dialling

number with gateways LF O

EFGWTEXT1 Gateway extension 1 LF O

EFADNTETRA

Abbreviated diallingnumbers for TETRA

networksLF O

EFEXTA Extension A LF O

EFFDNGWTFixed dialling numbers

with gateways LF O

EFGWTEXT2 Gateway extension 2 LF O

EFFDNTETRAFixed dialling numbers

for TETRA network LF O

EFEXTB Extension B LF O

EFLNDGWTLast number dialled with

gateways C O

EFLNDTETRALast numbers dialled for

TETRA network C O

EFSDNGWTService dialling number

with gateway LF O

EFGWTEXT3 Getaways extension 3 LF O

EFSDNTETRAService dialling numbers

for TETRA network LF O

EFSTXT Status message texts LF OEFMSGTXT SDS-1 message texts LF O

EFSDS123Status and SDS type 1, 2and 3 message storage LF O

EFSDS4SDS type 4 message

storage LF O

EFMSGEXT Message extension LF OEFEADDR Emergence addresses LF M

EFEINFOEmergency call

information T M

EFDMOChDMO radio channel

information LF O

EFMSChMS allocation of DMO

channels T O

EFKH List of key holders T O

EFREPGATEDMO repeater and

gateway list LF O

EFAD Administrative data T MEFPREF_LA Preferred location areas T O

3.6 Contents of the EFs 31

EF Description Structure M/OEFLNDComp Composite LND file C OEFDFLSTSGT Status default target T O

EFSDSMEM_STATUS SDS memory status T OEFWELCOME Welcome message T O

EFSDSR SDS delivery report LF OEFSDSP SDS parameters LF O

EFDIALSCDialling schemes for

TETRA network T M

EFAPN APN table LF O

EFPNIPrivate number

information LF O

EFSCAN Scan list files LF OEFSCAND Scan list data LF O

EFDMO_GSSISDMO pre-programmed

group numbers LF O

EFDMO_GRDSGrouped related data for

DMO static GSSISs LF O

EFGTMO_GDMOTMO-DMO selected

group association LF O

EFGDMO_GTMODMO-TMO selected

group association LF O

EFDMO_DEPDefault encryption

parameters T O

EFGSKO Group session key LF OEFs at TELECOM level

EFADNAbbreviated dialling

numbers LF O

EFFDN Fixed dialling numbers LF O

EFMSISDNMobile Station ISDN

Number LF O

EFLND Last number dilled C OEFSDN Service dialling numbers LF OEFEXT1 Extension 1 LF OEFEXT2 Extension 2 LF OEFEXT3 Extension 3 LF O

Table 3.14: Content of the EFs. [6] M/O = Mandatory/Optional accordingto [6], T = Transparent, LF = Linear fixed, C = Cyclic

More information about file types and what the EFs contain can be found in ETSIEN 300 812-3 [6].

32 3 Requirements

ID Description M/O

25The mandatory EFs given in Table 3.14 shall

exist.M

26The 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 theSIM/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 ModeGeneral Procedures

Reading an EF MEUpdating an EF ME

Invalidating an EF MESIM Management ProceduresSIM initialization ME

TETRA session initialization METETRA session termination ME

Language preference request MEAdministrative information request ME

SIM service table request MESIM phase request ME

SIM presence detection MEPIN Related Procedures

PIN verification MMIPIN value substitution MMI

PIN disabling MMIPIN enabling MMI

PIN unblocking MMITETRA Security Related Procedures

TETRA algorithms computation NETTETRA key computation NET

ITSI request NETITSI disabling NET

Location Information NETBroadcast network information NET

3.7 Procedures over the ME/SIM interface 33

Forbidden networks information NETSubscription Related Procedures

Username MMISubscriber class request ME

Group information MMI/NETUser’s group information ME/NET

Call modifiers NET/MENetwork information ME

Dialling numbers MMI/MESDS messages MMI

Preferred networks MMIService provider name ME

ICCID MEEmergency addresses ME/MMI

Table 3.16: List of procedures at the SIM/ME interface in TETRA networkoperation 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 theTETRA infrastructure.

4Architecture

This chapter describes the architecture of a TSIM application. The architectureis 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, andthe relations among them". Here, the architecture describes the general and struc-tural aspects of a TSIM application. To get more specific details about which filesand 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 figureshows that the DFTETRA is located under the MF. All files that belong to theTSIM application shall reside under the DFTETRA.

MF

TETRAOTHER

APPLICATIONSDF

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

35

36 4 Architecture

4.1.1 File Access Conditions

In Section 3.4.3 all access conditions are given. Four of the access conditionsare used to determine if a file can be read or updated. The four different accessconditions 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 beenentered.

• ADM: The operation is allowed on the file if a valid administrator PIN hasbeen 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 fieldsmust be present. The Lc and DATA fields are only present if data is added to thecommand and the Le field is present if the terminal expects a response. The Lefield 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.

• Le: The expected length of the response, if "00" 256 bytes can be received.

4.2 System Commands 37

The response APDU is shown in Figure 4.3. The fields in the response APDUhave 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 withthe response APDU.

SW1 SW2 DescriptionCorrectly 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 unsuccessfuldue to PIN verification, at least one attempt

left or unsuccessful UNBLOCK PINverification, 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 attemptleft unsuccessful UNBLOCK PIN

verification, no attempt left PIN blockedUNBLOCK PIN blocked

"98" "60" Manipulation flag set"98" "70" SwMI authentication unsuccessful

38 4 Architecture

SW1 SW2 DescriptionApplication Independent Errors

"67" "XX"Incorrect parameter Lc ("XX" gives the

correct length or states that no additionalinformation 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 theerror in P1 or P2 is caused by the addressedrecord 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

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

4.3 Authentication 39

4.3 Authentication

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

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

MS

TA11 TA21

TA12

TA22

TB4

RSK

RAND1KS

KS'

RES1 RAND2

XRES2

DCK1

DCK2

DCK

GenerateRAND2

CompareRES2 andXRES2

AuthenticationCentre

BS

SwMI

TA11 TA21

K

RS

KS KS'

RS, KS, KS'

TA12

TA22

TB4

Generate RAND1

CompareRES1 andXRES1

KS RAND1

KS' RAND2DCK1

DCK2RES2

DCK

XRES1

RAND1, RS

RES1, RAND2

RES2, R1

R2

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

Parameter No. of bitsDCK 80

DCK1/DCK2 80K 128

KS/KS’ 128RAND1/RAND2 80

RES1/RES2 32RS 80

XRES1/XRES2 32

Table 4.4: Dimensioning of authentication parameters. [9]

40 4 Architecture

4.4 Package Structure

The software on the smart card is divided into packages. The package structureallows the smart card and its Memory Management Unit (MMU) to manage theinternal 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 PackageAuthentication

PackageInterpreterPackage

OS Package

RegistryPackage

HAL PackageSecurity 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 smartcard and the development environment. They handle the on chip security andthe calls to the different parts of the smart card. These packages can only beaccessed by the OS Package. To use any of the functions that are accessed througheither the HAL packge or the Security Layer Package, the function call must passthrough 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 andSecurity Layer Packages.

The application packages are described in Section 5.3.

5Design

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

Requirements 1 to 3 are covered by the existing ATR in the smart card. Formore 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 applicationhas support for two levels of PIN, and the functions VERIFY PIN, CHANGE PIN,DISABLE PIN, ENABLE PIN and UNBLOCK PIN. For more information aboutthe PIN see ETSI EN 300 812-3 [6].

One important change compared to if only a TSIM application is implemented isthat no application is created for TSIM. Instead, the files and functions describedbelow shall be accessible from the already existing E2EE application. This meansthat the terminal, instead of selecting the TSIM application prior to using theTSIM functions and files, selects the E2EE application and can from the E2EEapplication use the files and functions belonging to the TSIM application. Thereason is that the E2EE application must be selected to get a TSIM applicationwith E2EE functionality and only one application can be selected at a time in asmart card.

41

42 5 Design

5.1 File System

The implemented files are given in Table 5.1, the files listed are selected fromTable 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.1must be supported by the implementation. The functionality of each file type isdescribed in Section 3.3.2 and the functions operating on the files are describedin Section 5.1.2.

File Description Structure File IDFiles under MF

DFTETRAThe DF that contains the

TETRA specific files DF "7F90"

EFICCIDUnique card identification

number T "2FE2"

EFDIRA list of applications that are

supported by the card T "2F00"

EFLP Language preference T "2F05"Files under DFTETRA

EFSST

SIM service table, indicateswhich of the optional services

and EFs that are availableT "6F01"

EFITSIIndividual TETRA subscriber

identity T "6F02"

EFITSIDISIndicates if ITSI is temporarily

disabled T "6F03"

EFSCT

Subscriber class table, holds theclass membership of the ITSI

subscriptionT "6F05"

EFPHASE Phase identification T "6F06"

EFGSSIS

Static GSSIs, contains thepre-programmed group

identitiesLF "6F0A"

EFGRDSGroup related data for static

GSSIs LF "6F0B"

EFGSSIDDynamic GSSIs, contains the

dynamic group identities LF "6F0C"

EFGRDDGroup related data for dynamic

GSSIs LF "6F0D"

EFGINFO

User’s group information,contains the user’s last activegroup, preferred groups and

information about using thesegroups addresses

T "6F10"

EFSEC Security settings T "6F11"

5.1 File System 43

File Description Structure File IDEFFORBID Forbidden networks C "6F12"

EFDNWRKBroadcast network information,

see ETSI EN 300 392-2 [8] LF "6F16"

EFNWT

Network table, contains thenetwork part of the TETRA

addressesLF "6F17"

EFGWT

Gateway table, contains thenames and addresses for

gateways in the TETRA networkLF "6F18"

EFEADDR Emergence addresses LF "6F2C"EFEINFO Emergency call information T "6F2D"

EFAD

Administrative data, containsinformation about the mode of

operationT "6F32"

EFDIALSCDialling 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 codedcan be found in ETSI EN 300 812-3 [6]. T = Transparent EF, LF = Linearfixed 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 beread or updated. Table 5.2 shows the read and update access conditions for thefiles that shall be present in the system.

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

FileRead AccessConditions

Update AccessConditions

Files under MFEFICCID ALW NEVEFDIR ALW ADMEFLP ALW PIN1

Files under DFTETRAEFSST PIN1 ADMEFITSI PIN1 ADM

EFITSIDIS PIN1 ADMEFSCT PIN1 ADM

EFPHASE ALW ADM

44 5 Design

FileRead AccessConditions

Update AccessConditions

EFGSSIS PIN1 ADMEFGRDS PIN1 PIN1EFGSSID PIN1 ADMEFGRDD PIN1 PIN1EFGINFO PIN1 PIN1

EFSEC PIN1 ADMEFFORBID PIN1 PIN1EFDNWRK PIN1 ADM

EFNWT PIN1 PIN1EFGWT PIN1 ADM

EFEADDR ALW PIN1EFEINFO ALW PIN1

EFAD ALW ADMEFDIALSC 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. Thecommand is used to select a file according to the rules for file selection describedin 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 linearfixed 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. Foran MF or DF Table 5.5 shows the response and for an EF Table 5.6 shows theresponse. More details about the SELECT command can be found in ETSI TS 102221 [11].

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 onhow the SELECT command shall be used see ETSI TS 102 224 [11]. [11]

Byte(s) Description Length1 to

lengthFile ID, DF name or path to file

(depends on P1)length

Table 5.4: SELECT command data. [6]

Description TagFile 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 ora DF. [11]

Description TagFile 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 transparentEF. The read operation shall only be performed if the read access is satisfied forthe current EF (see Section 4.1.1). The input and the output: [6]

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


46 5 Design

• Output to ME: String of bytes

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

Class INS P1 P2 Lc Data Le"A0" "B0" offset high offset low - - length

Table 5.7: The command APDU for READ BINARY. [6]


lengthData 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 EFis 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


• Output to ME: None

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

Class INS P1 P2 Lc Data Le"A0" "D6" offset high offset low length Table 5.10 -

Table 5.9: The command APDU for UPDATE BINARY. [6]


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

5.1 File System 47

The command reads one complete record in the current linear fixed or cyclic EF.The function shall only be performed if the read access conditions are satisfied(see Section 4.1.1). If the operation is unsuccessful, the record pointer shall notbe updated. The input and output are given below: [6]

• Input from ME:Mode, record number (for absolute mode) andthe length of the record


• Output to ME: The record

There are four different modes:

CURRENT: The current record is read and the record pointer is kept.

ABSOLUTE: The record given by the record number is read, the record pointeris not affected.

NEXT: The record pointer is incremented and then the record is read. If therecord pointer has not been set, the first record shall be read.

PREVIOUS: The record pointer is decremented before the record is read. If therecord pointer has not been set, the last record shall be read.

The command APDU can be seen in Table 5.11. The response parameters can beseen in Table 5.13.

Class INS P1 P2 Lc Data LeA0" "B2" Table 5.12 Table 5.12 - - length

Table 5.11: The command APDU for READ RECORD. [6]

Mode P1 P2CURRENT "00" "04" and P1 set to "00"ABSOLUTE "00" "02"

NEXT "00" "03"PREVIOUS Record number "04"

Table 5.12: The P1 and P2 parameters for READ RECORD and UPDATERECORD depending on the mode of operation. [6]


lengthThe data of the record length

Table 5.13: READ RECORD response data. [6]

48 5 Design

5.1.2.5 UPDATE RECORD

This command writes one record in the current linear fixed or cyclic EF. Thecommand shall only be performed if the update access condition is satisfied (seeSection 4.1.1). The same mode of operation is used as for the READ RECORD.For cyclic EFs only the mode PREVIOUS is allowed. It updates the oldest record,and the record pointer is set to this record. This record becomes record number1. The input and the output are given below: [6]

• Input from ME:Mode, record number (for absolute mode) andthe length of the record, the new data




Class INS P1 P2 Lc Data Le"A0" "DC" Table 5.12 Table 5.12 length Table 5.15 -

Table 5.14: The command APDU for UPDATE RECORD. [6]


lengthData length

Table 5.15: UPDATE RECORD command data. [6]

5.1.2.6 SEEK

This function searches through the current linear fixed EF to find a record start-ing with the given pattern and set the record pointer to point on that record.The SEEK command can only be used when the read access is satisfied (see Sec-tion 4.1.1). There are two types of SEEK: [6]

Type 1:

• Input from ME: Type and mode, pattern, length of the pattern



Type 2:

• Input from ME: Type and mode, pattern, length of the pattern


• Output to ME: Status/Record number

Four modes are defined for SEEK:

5.1 File System 49

• From the beginning and forward.

• From the end and backward.

• From the next location and forward.

• From the previous location and backward.

If the record pointer has not been set it should be set to the location of the firstrecord if forward search is used or the last record if backward search is used. [6]

The command APDU can be seen in Table 5.16. The response for Type 2 can beseen in 5.19

Class INS P1 P2 Lc Data Le"A0" "A2" "00" Table 5.17 length Table 5.18 -/"01"

Table 5.16: The command APDU for SEEK. [6]

Type/Mode P2Type 1, from the beginning forward "00"Type 1, from the end and backward "01"

Type 1, from the next location and forward "02"Type 1, from the previous record and backward "03"

Type 2, from the beginning forward "10"Type 2, from the end and backward "11"

Type 2, from the next location and forward "12"Type 2, from the previous record and backward "13"

Table 5.17: The P2 parameter for SEEK. [6]


lengthPattern length

Table 5.18: SEEK command data. [6]

Byte(s) Description Length1 Record number 1

Table 5.19: SEEK response data. [6]

5.1.2.7 INVALIDATE

This function is used to invalidate the current EF. The function shall only inval-idate files if the invalidate access condition is satisfied (see Section 5.1.1). Aninvalidated file shall not be available in the file system. The SELECT and REHA-BILITATE commands are the only ones that can be used on an invalidated file.The input and the output are: [6]

50 5 Design

• Input from ME: None




Class INS P1 P2 Lc Data Le"A0" "04" "00" "00" "00" - -

Table 5.20: The command APDU for INVALIDATE. [6]

5.1.2.8 REHABILITATE

This function rehabilitates the invalidated current EF. This function shall only beperformed if the rehabilitate access condition is satisfied (see Section 5.1.1). Theinput and the output are: [6]





Class INS P1 P2 Lc Data Le"A0" "44" "00" "00" "00" - -

Table 5.21: The command APDU for REHABILITATE. [6]

5.2 Authentication

The authentication procedure with the network can be divided into a set of com-mands that the MS send to the SIM. These commands are described in the follow-ing subsections. They shall only be accessible if a correct PIN has been presentedto the SIM. The APDUs for these commands are the same as described in Sec-tion 5.1.2.

The access to the algorithms TA11, TA12, TA21, TA22 and TB4 is restricted. Thealgorithms used in the functions below are therefore only dummy algorithms andthe only similarity with the real algorithms is the dimension of the variables. TheGET RANDOM function described in Section 5.2.1 is not a dummy algorithmand can be used with a live system in a real network.

The use of dummy functions, having the correct variable dimension and therebythe correct interface format, in test situations where the actual algorithm is nottested. In a live system, the dummy algorithms will be replaced by algorithms


according to the standard. To read more about dummy functions, or stubs, intesting purpose see [13].

As an example, a dummy algorithm for byte array addition is shown in Algo-rithm 5.1 in pseudo code.

/ / Add two b y t e a r r a y s o f l e n g t h lengthA and lengthB ./ / R e s u l t i s w r i t t e n t o sumvoid AddArray ( byte_array termA , byte_array termB , byte_array sum)

/ / C a l c u l a t e t h e maximum and minimum l e n g t hi n t e g e r minLength = min ( termA . Length , termB . Length )i n t e g e r maxLength = max( termA . Length , termB . Length )

i n t e g e r carry = 0

/ / Add t h e b y t e s c o v e r e d by both a r r a y sfor ( i = 0 ; ( i < minLength ) && ( i < sum . Length ) ; i ++)

sum[ i ] = termA [ i ] + termB [ i ] + carrycarry = CalculateCarry ( carry , termA [ i ] , termB [ i ] )

/ / Check i f A or B i s l o n g e s t . Then add t h e remaining numbers .i f ( termA . Length > termB . Length )

for ( i ; ( i < maxLength ) && ( i < length ) ; i ++)sum[ i ] = termA [ i ] + carrycarry = CalculateCarry ( carry , termA [ i ] )

e l s efor ( i ; ( i < maxLength ) && ( i < length ) ; i ++)

sum[ i ] = termB [ i ] + carrycarry = CalculateCarry ( carry , termB [ i ] )

Algorithm 5.1: "Add" two byte arrays

The dummy algorithm described by Algorithm 5.1 replaces the plus operator inthe equations in the subsections below. The only requirements on the dummyalgorithm described in Algorithm 5.1 was that it should somehow change thedata depending on the input.

5.2.1 GET RANDOM

This function shall produce a random number that shall be used in the authenti-cation algorithms. The input and the output are given below:



• Output to ME: RAND2

The RAND2 shall be stored internally in the SIM to be used in the TA21/TA22algorithm. [6]

The command APDU can be seen in Table 5.22. The response parameters can beseen in Table 5.23

The random number shall be generated using the Random Number Generator(RNG) on the smart card.

52 5 Design

Class INS P1 P2 Lc Data Le"A0" "CE" "00" "00" - - "0A"

Table 5.22: The command APDU for GET RANDOM. [6]

Byte(s) Description Length1 to 10 RAND2 10

Table 5.23: GET RANDOM response data. [6]

5.2.2 TA11/TA12 Algorithm

This function is initiated by the SwMI and is used to authenticate the SIM to theTETRA network. The input and the output are given below:

• Input from ME: RAND1, RS

• Input from SIM: K

• Output to ME: RES1

RES1 shall be obtained from the SIM by using the GET RESPONSE commanddescribed in Section 5.2.5. DCK1 shall be stored internally in the SIM. [6]

The command APDU can be seen in Table 5.24. The command and responseparameters can be seen in Table 5.25 and Table 5.26.

Class INS P1 P2 Lc Data Le"A0" "40" "00" "00" "14" Table 5.25 "04"

Table 5.24: The command APDU for TA11/TA12. [6]

Byte(s) Description Length1 to 10 RAND1 10

11 to 20 RS 10

Table 5.25: TA11/TA12 command data. [6]

Byte(s) Description Length1 to 4 RES1 4

Table 5.26: TA11/TA12 response data. [6]

As seen in Figure 4.4 the TA11 algorithm has K and RS as input and produces KS.Inside the TA11 block the dummy algorithm described in (5.1) is performed.

KS = (K + RS) truncate to 128 bits (5.1)


The TA12 algorithm takes KS and RAND1 as input and produces RES1 andDCK1. The dummy algorithm for producing RES1 can be seen in (5.2) and thedummy algorithm for DCK1 can be seen in (5.3).

RES1 = (KS + RAND1) truncate to 32 bits (5.2)

DCK1 = (KS + RAND1) truncate to 80 bits (5.3)

5.2.3 TA21/TA22 Algorithm

This function is initiated by the SIM and is used to authenticate the TETRA net-work to the SIM. The input and the output are given below:

• Input from ME: RES2, RS

• Input from SIM: K, RAND2

• Output to ME: XRES2

XRES2 shall be obtained from the SIM by using the GET RESPONSE commanddescribed in Section 5.2.5. DCK2 shall be stored internally in the SIM. [6]

The command APDU can be seen in Table 5.27. The command and responseparameters can be seen in Table 5.28 and 5.29.

Class INS P1 P2 Lc Data Le"A0" "42" "00" "00" "0E" Table 5.28 "04"

Table 5.27: The command APDU for TA21/TA22. [6]

Byte(s) Description Length1 to 4 RES2 4

5 to 14 RS 10

Table 5.28: TA21/TA22 command data. [6]

Byte(s) Description Length1 to 4 XRES2 4

Table 5.29: TA21/TA22 response data. [6]

As seen in Figure 4.4, the TA21 algorithm has K and RS as input and produces KS’.Inside the TA21 block, the dummy algorithm described in (5.4) is performed.

KS ′ = (K + RS) truncate to 128 bits (5.4)

54 5 Design

The TA22 algorithm takes KS’ and RAND2 as input and produces XRES2 andDCK2. The operation for producing XRES2 can be seen in (5.5) and the operationfor DCK2 can be seen in (5.6).

XRES2 = (KS ′ + RAND2) truncate to 32 bits (5.5)

DCK2 = (KS ′ + RAND2) truncate to 80 bits (5.6)

5.2.4 TB4/TE Algorithm

The TB4 function is used to obtain a DCK from the two parts generated by theTA11/TA12 and TA21/TA22 algorithms. In addition, the TE algorithm can berun if that service is enabled (indicated in EFSST). The TE algorithm will not beimplemented in this solution and only a dummy algorithm will be used insteadof the TB4 algorithm. The input and the output are given below:


• Input from SIM: DCK1, DCK2 (KE if TE shall be used)

• Output to ME: DCK

If not a mutual authentication has been performed but, an unilateral authenti-cation has been done either DCK1 or DCK2 is set to zero depending on whichalgorithms that have been performed. [6]

The command APDU can be seen in Table 5.30 and the response can be seen inTable 5.31.

Class INS P1 P2 Lc Data Le"A0" "46" "00" "00" - - "0A"

Table 5.30: The command APDU for TB4/TE. [6]

Byte(s) Description Length1 to 10 DCK 10

Table 5.31: TB4/TE response data. [6]

As seen in Figure 4.4, the TB4 algorithm has DCK1 and DCK2 as input and pro-duces DCK. Inside the TB4 block, the dummy algorithm described in (5.7) isperformed.

DCK = (DCK1 + DCK2) truncate to 80 bits (5.7)

5.3 Package Structure 55

5.2.5 GET RESPONSE

The command GET RESPONSE is used to get the response data from the preced-ing command. The GET RESPONSE command shall be executed immediatelyafter the command that produces the response. If this is not the case, the datais lost. GET RESPONSE is for example used together with the TA11/TA12 algo-rithm. [6]

The response data is defined under the corresponding commands. The lengthshall be set to the maximal number of bytes that the terminal expects to receive.If the length is set to "00" it means 256 bytes.


Class INS P1 P2 Lc Data Le"A0" "C0" "00" "00" - - length

Table 5.32: The command APDU for GET RESPONSE. [6]

5.3 Package Structure

The implementation on the smart card is divided into packages as described inSection 4.4. The contents of the application packages are described as follows.

The Crypto package contains the authentication functions described in Section 5.2.

The Authentication package already includes the implemented PIN functionsand handles everything concerning the PIN verification.

The Interpreter package contains the main loop of the smart card and parsesthe commands from the terminal. This package is updated to support all TSIMrelated operations. This package also holds the file system on the card. So all filesdescribed in Table 5.1 should be added here.

The OS package is used to communicate with the HAL, Security Layer and towrite and read from the EEPROM. The OS package is for example used by theauthentication function GET RANDOM (Section 5.2.1) to access the on chip RNG.

The Registry package contains the ATR.

6Verification

This chapter describes how the design in Chapter 5 and the architecture in Chap-ter 4 are verified to see that the requirements in Chapter 3 are fulfilled. As statedearlier, testing with a simulated terminal is the only way to verify that the systemworks because it cannot yet be tested in a device connected to a real network.

Two different test methods are used for testing of functionality; unit testing (seeSection 6.2) and card acceptance tests with a real smart card connected to a PC,simulating MEs from different manufacturers (see Section 6.3).

Unit testing is used to verify that the code works as expected before programmingthe smart card. This makes it easier to debug the code, since once the code iswritten to the smart card there is no way to step one line at a time. But theunit tests cannot simulate the memory handling on the smart card. The MMUbehavior can only be tested correctly by running the code on a smart card.

6.1 Requirement Verification

Table 6.1 shows the status of all requirements from Chapter 3. A description isgiven if the requirement has been tested and how. If the requirement has notbeen tested, a reason is given to why.

Req.no. Status Comment

1 to 3Already

implementedFulfilled by the existing ATR in the smart card. Ver-ified by analyzing the code and the existing tests

57

58 6 Verification

Req.no. Status Comment

4 to 6Code

analysis

By analyzing the code, all files were verified to con-sist of a header and a body when needed. Analysisshows that all files has a unique file ID if they areplaced under the same DF, the file ID consist of twobytes, and are specified according to the rules givenin Section 3.3

7Code

analysisCode analysis verifies that all DFs only consist of aheader

8Code

analysis

Code analysis verifies that all EFs consist of both aheader and a body. This is also verified by the testsfor each file type

9, 10and 12

TestedVerified by testing the functions operating on thefiles. The tests are described in Section 6.2.1 andSection 6.3.1

11Not

implementedThe key EF is not implemented because no manda-tory file is of the key type

13 Partly tested

Files are verified that they can be selected. Notenough tests are performed to verify that a file can-not be selected from the wrong location. Tests arenot performed to verify that a file cannot be selectedfrom all other DFs then the direct parent

14Code

analysis andtest

The file ID are verified by code analysis and the se-lection tests are described in Section 6.3.1

15 to18

Codeanalysis and

tests

Verified by code analysis and by running the testsdescribed in Section 6.2.2 and Section 6.3.2

19 Tested Verified by the tests described in Section 6.3.2

20Analysis and

tested

Verified by checking which file types that exists, andthen verifying that the corresponding functions areavailable. The functions are verified in Section 6.2.1and Section 6.3.1

21Already

implemented

This functionality already exists in the availablesmart card. The functionality is not explicitly testedbut the functions are used during other test cases

22 TestedVerified by the tests described in Section 6.2.1 andSection 6.3.1

23 TestedVerified by the tests described in Section 6.2.2 andSection 6.3.2

24Not

implementedThe OTAR functionality is not implemented

Table 6.1: The status of the requirements from Chapter 3.

6.2 Unit Test 59

6.2 Unit Test

The primary goal of unit testing is to test the smallest unit of the software. Theunit under test shall be separated from the rest of the software, to be able to testthe functionality of that specific unit without the influence of other units. Thegoal is to verify that each unit is correct before moving forward and integratingthem, and from there testing a bigger unit. [13, 14]

6.2.1 File System

To test that all necessary files exists, all files were selected by name and id. Moretesting was done during the card acceptance tests, described in Section 6.3.1.

To test the implemented functions operating on files, two files were selected. Thetest files were EFDNWRK and EFFORBID. EFDNWRK is a cyclic EF and EFFORBID is alinear fixed EF.

To test READ RECORD (Section 5.1.2.4), the following test cases were used:

• Read the first record, no record is selected

• Read the previous record, from the second record

• Read the next record, from the first record

• Read the previous record, from the first record

• Read the next record, from the last record

The result differs depending on the file type. For the linear fixed EF the com-mands when trying to read from the last to the first or from the first to the lastrecord shall fail but for the cyclic EF this is a correct operation.

To test UPDATE RECORD (Section 5.1.2.5), the following test cases were used:

• Update a record using absolute addressing

• Update the next record, from the first record

• Update the previous record, from the last record

• Try to write a record without the correct access condition (should fail)

When updating the EF the linear fixed EF can work in all modes, but the cyclicEF only allows the previous record to be updated.

For the cyclic EF, the READ and UPDATE are also tested to verify that only thePREVIOUS mode can be used.

To test SEEK (Section 5.1.2.6), the following test cases were used:

• From the beginning and forward

• From the end and backwards

• From the next record and forward when:

60 6 Verification

– The record is located after the next record

– The record is located before the current record

• From the previous record and backwards when:

– The record is located before the previous record

– The record is located after the current record

• Too long search term

When seeking a value in a linear fixed EF, the value must be found before the endor start of the file. When searching in a cyclic EF the search should only end ifthe value has not been found and the whole file has been searched.

To test INVALIDATE (Section 5.1.2.7) and REHABILITATE (Section 5.1.2.8), thefollowing test cases were used:

• Invalidate a file and try to access it

• Rehabilitate an invalidated file


To verify that the authentication algorithms work as intended the algorithmswere called upon and the result was compared to the expected results given foreach algorithm.

GET RANDOM (Section 5.2.1) is tested by calling the function and reading outthe result RAND2. The result is then tested by Algorithm 6.1. The algorithmtakes an array of bytes and views the data as a matrix, 8 bits wide and lengthhigh, and verifies that each column contains at least one ’0’ and one ’1’.

bool DataLooksRandom ( byte_array data , i n t e g e r length )

byte mask1 = " 00 " ;byte mask2 = " FF " ;

/ / Check t h e datafor ( i = 0 ; i < length ; i ++)

mask1 = mask1 | data [ i ] ;mask2 = mask2 & data [ i ] ;

/ / Does t h e data l o o k random ?i f ( mask1 != " FF " ) && ( mask2 != " 00 " )

return f a l s e ;e l s e

return t rue ;

Algorithm 6.1: Simple algorithm to check if data looks random

TA11/TA12 (Section 5.2.2) is tested with the data given in Table 6.2 to verify thatthe function works as expected. The result RES1 is returned from the commandand DCK1 is read from the internal storage.

6.2 Unit Test 61

Parameter ContentInput

RAND1 "11 22 33 44 55 66 77 88 99 AA"RS "FF EE DD CC BB AA 99 88 77 66"

OutputRES1 "10 22 33 44"DCK1 "10 22 33 44 55 66 77 88 99 AA"

Expected OutputRES1 "10 22 33 44"DCK1 "10 22 33 44 55 66 77 88 99 AA"

Table 6.2: TA11/TA12 test data, the expected output is generated by runningAlgorithm 5.1 by hand.

TA21/TA22 (Section 5.2.3) is tested with the data given in Table 6.3 to verify thatthe function works as expected. The result XRES2 is returned from the commandand DCK2 is read from the internal storage.


RES2 "10 22 33 44"RS "FF EE DD CC BB AA 99 88 77 66"

RAND2 "11 22 33 44 55 66 77 88 99 AA"Output

XRES2 "10 22 33 44"DCK2 "10 22 33 44 55 66 77 88 99 AA"

Expected OutputXRES2 "10 22 33 44"DCK2 "10 22 33 44 55 66 77 88 99 AA"

Table 6.3: TA21/TA22 test data, the expected output is generated by runningAlgorithm 5.1 by hand.

TB4/TE (Section 5.2.4) is tested with the data given in Table 6.4 to verify that thefunction works as expected. The result, DCK, is returned from the command.

62 6 Verification


DCK1 "11 22 33 44 55 66 77 88 99 AA"DCK2 "FF EE DD CC BB AA 99 88 77 66"

OutputDCK "10 22 33 44 55 66 77 88 99 AA"

Expected OutputDCK "10 22 33 44 55 66 77 88 99 AA"

Table 6.4: TB4/TE test data, the expected output is generated by runningAlgorithm 5.1 by hand.

6.3 Card Acceptance Test

Card acceptance tests are performed to verify that the functions work on a realsmart card and that all files only can be accessed with the correct permissions.When compared with the unit tests, the card acceptance tests are more aimedto test that the functions works as intended on a physical smart card instead ofdebugging and verifying the code on a PC. The biggest difference between theunit tests and the card acceptance tests is that the unit tests cannot test how theMMU limit the access to different memory areas.

6.3.1 File System

To test that all files exist, all files are tested to be selected by name and by file-ID.This verifies that all files have the correct name and ID and are placed under thecorrect DF.

To test the READ and UPDATE functions, as well as the access conditions forthe files an access test is used. For the READ operation, this means that the fileis read but the content is not analyzed. For the UPDATE operation, this meansthat dummy data is written to the file. For both UPDATE and READ, all files aretested without any PIN, with user PIN and with admin PIN. The answer is thenanalyzed to see that only the operation with correct authentication are allowed,all other shall be blocked by the smart card and return an error. See Section 5.1.1for the different access conditions for the files. This test does not verify that datais not written in case of a wrong authentication, this is tested by the unit tests.


To test GET RANDOM, the function is called 1000 times and the values are com-pared to see that no values are equal. This way the function is proved to give dif-ferent values. However it is not a proof that the values are random, but enoughfor this implementation.

The input used to test TA11/TA12 is described in Table 6.5. In addition to theinput given in Table 6.5, randomly generated input is used as well. To verify that

6.4 Use Cases 63

the function works as expected, Algorithm 5.1 on Page 51 is implemented in thetestbench. This allows the results to be compared.

Parameter ContentTest case 1

RAND1 "11 22 33 44 55 66 77 88 99 AA"RS "FF EE DD CC BB AA 99 88 77 66"

Test case 2RAND1 "FF FF FF FF FF FF FF FF FF FF"

RS "FF FF FF FF FF FF FF FF FF FF"

Table 6.5: TA11/TA12 test data.

The input used for testing TA21/TA22 is described in Table 6.6. In addition tothe input given in Table 6.6, random input is used as well. To compare the resultthe same method as described above for TA11/TA12 is used. When testing theTA21/TA22 function, GET RANDOM must first be executed to get RAND2.

Parameter ContentTest case 1

RES2 "00 00 00 00"RS "FF EE DD CC BB AA 99 88 77 66"

Test case 2RES2 "00 00 00 00"

RS "FF FF FF FF FF FF FF FF FF FF"

Table 6.6: TA21/TA22 test data.

When testing TB4/TE, only random input is used to TA11/TA12 and TA21/TA22.Testing the TB4/TE function, one tests a complete mutual authentication.

6.4 Use Cases

To better understand and motivate the tests described in Section 6.2 and Sec-tion 6.3, two use cases are presented in the following subsections.

6.4.1 Session Initialization

To initialize a session the ME first performs a language request by reading EFLP.If the preferred language is not available, the ME uses a default language. Oncethe language is selected, the ME performs a PIN verification where the user mustenter his/her user PIN. If this procedure fails the session initialization fails, oth-erwise the ME continue with the following procedures: [6]

• Administrative information request, read EFAD

64 6 Verification

• SIM Phase request, read EFPHASE

• SIM Service Table request, read EFSST

• ITSI request, read EFITSI

• ITSI temporarily disabled enquiry, read EFITSIDIS

• Subscriber class request, read EFSCT

• Preferred networks request, read EFPREF

• Mutual authentication requirement request, read EFSEC

• Forbidden networks request, read EFFORBID

• Interrupted emergency call request, read EFEINFO

As seen in the use case the session initialization only include file read opera-tions and this has been tested by the test cases mentioned in Section 6.2 andSection 6.3.

6.4.2 Authentication Between SIM and the SwMI

When the SwMI requests a SIM authentication the ME reads EFSEC to determineif a mutual authentication shall be performed or not. Then the ME runs theTA11/TA12 algorithm. Once the algorithm is done the ME runs GET RESPONSEto read Response 1 (RES1) before sending it back to the SwMI. If the SIM indi-cated that a mutual authentication should be performed the ME then runs GETRANDOM and the TA21/TA22 algorithm with the data given from the SwMI.The authentication procedure ends with the ME running the TB4 algorithm. [6]

All of the above operations are tested in the test cases described in Section 6.2and Section 6.3.

7Conclusions

This chapter presents the results and conclusions of the master thesis, and furtherwork on the subject.

7.1 Results

The TSIM standard from ETSI was analysed and a specification of requirementswas written. The requirements are described in Chapter 3. The goals in Sec-tion 1.2 specify that unclear parts shall be investigated. One unclear part duringthe master thesis was if the files for TSIM should be placed under a DF or if a ap-plication DF should be used. The conclusion was that the files should be placedin a DF as described in the report. The reason is that the files need to be accessiblefrom other applications.

From the specification of requirements, a system design consisting of an archi-tecture and a design was proposed. The system design describes how the TSIMapplication should be implemented to fulfill the requirements from ETSI and atthe same time work together with the existing E2EE application. The architectureis given in Chapter 4 and the design in Chapter 5.

From the system design, the TSIM application was implemented and tested. Theimplementation consisted of all files given in the design, as well as all functionsgiven in the design that did not exist already. The tests were done as describedin Chapter 6. Important to notice about the verifications was that the systemwas not tested together with a real network and/or terminal. The system wasonly tested through a computer that simulated the behaviour of a terminal. Thereason was, as mentioned, that the terminals existing today in Rakel does notsupport the use of a SIM card.

65

66 7 Conclusions

7.2 Conclusions

From the results described above, an important conclusion from this master the-sis is that it is possible to combine an E2EE application and a TSIM applicationon a smart card. This solution is not limited to an E2EE application. It shouldbe possible to integrate any application together with a TSIM application andget a smart card with dual functionality. However, the TSIM is not implementedas a separate application, instead the TSIM functions and files shall be accessi-ble from the already existing application(s). The reason why this is done is thatthe TSIM files and functions needs to be accessed continuously while the E2EEapplication is running.

A simplification that has been made is that the authentication algorithms for theauthentication with the SwMI are replaced by dummy algorithms. This simplifi-cation has been done because the access to the real algorithms is limited by ETSIand is only handed to those operating in a real network. Even if this simplifica-tion has been done, the variables and data sent to and from the command havebeen kept according to the standard. So if the system shall be used only thealgorithms themselves need to be replaced.

All files implemented need to be filled up with the correct (operator dependent)data. This is something that is not relevant for testing the functionality in asimulated environment, if it shall be tested in a live network this data must becorrect. This stage is part of the smart card manufacturing and personalization.

7.3 Further Work

To continue my work, one would need a device which can operate the TSIM. To-day the devices used in Sweden does not support a SIM card. Instead, the ter-minal is personalized. This is possible since the users and the service providerare tightly coupled. When looking at the market today more and more users areconnected to Rakel and a personal SIM card would allow a user to switch de-vice by just inserting his/her SIM card. This would mean that a firefighter whosehand-held device has broken down, could immediately get a spare from the truckand move his/her SIM instead of checking out a new hand-held device from theadministration.

In order to implement this in a complete product, one would need to insert datain all files and replace the authentication algorithms. After this has been done,the SIM card should be operational.

To later extend the functionality of the SIM card, the optional files and functionsshould be analyzed to see which are useful and desired in a final product.

Bibliography

[1] MSB (Swedish Civil Contingencies Agency). Om Rakel (About Rakel).[online], 2012. Available at: <https://www.msb.se/sv/Produkter–tjanster/RAKEL/Om-Rakel/> [Accessed 26 January 2012]. Cited on page9.

[2] TETRA Association. TETRA Standard. [online], 2012. Available at:<http://www.tetra-association.com/about/page/12320> [Accessed 23 Jan-uary 2012]. Cited on pages 7, 8, and 9.

[3] Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, andReed Little. Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2 edition, 2010. ISBN 978-0321552686. Cited on page 35.

[4] Hans Delfs and Helmut Knebl. Introduction to Cryptography. 2007. ISBN978-3-540-49243-6. Cited on page 25.

[5] ETSI. ETS 300 641. European telecommunication standard, ETSI, 1997.[online] Available at: <http://www.etsi.org/> [Accessed 1 February 2012].Cited on page 17.

[6] ETSI. EN 300 812-3 V2.3.1 (2005-12). European norm, ETSI, 2005. [online]Available at: <http://www.etsi.org/> [Accessed 23 January 2012]. Cited onpages 11, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 31, 32, 33, 36,37, 38, 41, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 63, and 64.

[7] ETSI. TS 100 977 V8.14.0 (2007-06). Technical specification, ETSI, 2007.[online] Available at: <http://www.etsi.org/> [Accessed 1 February 2012].Cited on pages 17, 18, and 41.

[8] ETSI. EN 300 392-2 V3.4.1 (2010-08). European norm, ETSI, 2010. [online]Available at: <http://www.etsi.org/> [Accessed 3 April 2012]. Cited onpage 43.

[9] ETSI. EN 300 392-7 V3.2.1 (2010-06). European norm, ETSI, 2010. [online]Available at: <http://www.etsi.org/> [Accessed 7 February 2012]. Cited onpages 24, 25, and 39.

67

68 Bibliography

[10] ETSI. EN 300 396-6 V1.4.1 (2010-07). European norm, ETSI, 2010. [online]Available at: <http://www.etsi.org/> [Accessed 7 February 2012]. Cited onpages 24 and 25.

[11] ETSI. TS 102 221 V10.0.0 (2011-12). Technical specification, ETSI, 2011.[online] Available at: <http://www.etsi.org/> [Accessed 23 January 2012].Cited on pages 44 and 45.

[12] Bill Holcombe. Government smart card handbook. Technical report, GSA(U.S. General Service Administration), February 2004. [online] Available at:<http://www.smartcardalliance.org/resources/pdf/smartcardhandbook.pdf>[Accessed 26 January 2012]. Cited on pages 9, 10, and 11.

[13] M G Limaye. Software Testing. Tata McGraw-Hill, 2009. ISBN 978-0-07-013990-9. Cited on pages 51 and 59.

[14] MSDN (Microsoft Developer Network). Unit Testing. [on-line], 2012. Available at: <http://msdn.microsoft.com/en-us/library/aa292197(v=vs.71).aspx> [Accessed 21 Mars 2012]. Citedon page 59.

[15] Peter Nyman and Jerry Falkcrona. System Specification Tetra E2EE smart card.System specification, February 17 2012. Y-SC-11.163.0.3. Note: CompanyConfidential. Cited on page 13.

[16] Peter Nyman, Jerry Falkcrona, and Johan Hedström. Product description –Tetra E2EE smart card v2.0 full feature. Product description, February 162012. SC-10.705.4.0. Note: Company Confidential. Cited on page 12.

[17] SS-ISO/IEC. 7816-3:2007 (2007-07-13). Swedish standard, SS-ISO/IEC,2007. Cited on pages 16, 18, and 41.

[18] Wikipedia. Terrestrial Trunked Radio. [online], January 18 2012. Available at:<http://en.wikipedia.org/wiki/TETRA> [Accessed 23 January 2012]. Citedon pages 7 and 8.

Upphovsrätt

Detta dokument hålls tillgängligt på Internet — eller dess framtida ersättare —under 25 år från publiceringsdatum under förutsättning att inga extraordinäraomständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skri-va ut enstaka kopior för enskilt bruk och att använda det oförändrat för icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten viden senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan be-skrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan formeller i sådant sammanhang som är kränkande för upphovsmannens litterära ellerkonstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet — or its possi-ble replacement — for a period of 25 years from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission for any-one to read, to download, to print out single copies for his/her own use and to useit unchanged for any non-commercial research and educational purpose. Subse-quent transfers of copyright cannot revoke this permission. All other uses of thedocument are conditional on the consent of the copyright owner. The publisherhas taken technical and administrative measures to assure authenticity, securityand accessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected againstinfringement.

For additional information about the Linköping University Electronic Press andits procedures for publication and for assurance of document integrity, pleaserefer to its www home page: http://www.ep.liu.se/

© Jonas Olofsson

http://www.ep.liu.se/

http://www.ep.liu.se/

Documents

Design and Implementation of SIM Functionality for TETRA ...535645/FULLTEXT01.pdf · Design och implementation av SIM-funktionalitet i ett smartcard för TETRA-systemet Design and