design and implementation of sim functionality for tetra ...535645/fulltext01.pdf · design och...
TRANSCRIPT
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
LiTH-ISY-EX--12/4559--SE
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
LiTH-ISY-EX--12/4559--SE
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
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
• Input from SIM: None
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]
Byte(s) Description Length1 to
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
• Input from SIM: None
• 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]
Byte(s) Description Length1 to
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
• Input from SIM: None
• 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]
Byte(s) Description Length1 to
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
• Input from SIM: None
• Output to ME: None
The command APDU can be seen in Table 5.14.
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]
Byte(s) Description Length1 to
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
• Input from SIM: None
• Output to ME: None
Type 2:
• Input from ME: Type and mode, pattern, length of the pattern
• Input from SIM: None
• 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]
Byte(s) Description Length1 to
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
• Input from SIM: None
• Output to ME: None
The command APDU can be seen in Table 5.20.
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]
• Input from ME: None
• Input from SIM: None
• Output to ME: None
The command APDU can be seen in Table 5.21.
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
5.2 Authentication 51
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:
• Input from ME: None
• Input from SIM: None
• 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)
5.2 Authentication 53
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 ME: None
• 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.
The command APDU can be seen in Table 5.32.
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
6.2.2 Authentication
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.
Parameter ContentInput
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
Parameter ContentInput
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.
6.3.2 Authentication
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