Tetra E2E Smartcards Masterfile

Institutionen för systemteknik
Department of Electrical Engineering
Examensarbete
Design and Implementation of SIM Functionality for

TETRA-system on a Smart Card
Examensarbete utfört i Elektroteknik

vid Tekniska högskolan vid Linköpings universitet
av
Jonas Olofsson
LiTH-ISY-EX--12/4559--SE
Linköping 2012
Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet
SE-581 83 Linköping, Sweden 581 83 Linköping
Design and Implementation of SIM Functionality for
TETRA-system on a Smart Card
Examensarbete utfört i Elektroteknik

vid Tekniska högskolan vid Linköpings universitet
av
Jonas Olofsson
LiTH-ISY-EX--12/4559--SE
Handledare: Jerry Falkcrona

Sectra Communications
Per Karlström
isy, Linköpings University
Examinator: Ola Dahl

isy, Linköpings University
Linköping, 8 juni 2012

Avdelning, Institution Datum
Division, Department Date
Division of Computer Engineering

Department of Electrical Engineering 2012-06-08
SE-581 83 Linköping
Språk Rapporttyp ISBN

Language Report category —
⇤ Svenska/Swedish ⇤ Licentiatavhandling ISRN
⇤ Engelska/English
⇥ ⇤ Examensarbete
⇥ LiTH-ISY-EX--12/4559--SE
⇤ C-uppsats
Serietitel och serienummer ISSN
⇤ D-uppsats Title of series, numbering —
⇤ ⇤ Övrig rapport
⇤
URL för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-78597
Titel Design och implementation av SIM-funktionalitet i ett smartcard för TETRA-systemet

Title Design and Implementation of SIM Functionality for TETRA-system on a Smart Card
Författare Jonas Olofsson

Author
Sammanfattning
Abstract
TETRA is an open radio standard developed by ETSI. It is specifically designed for use by
government agencies, emergency services such as police forces, fire departments, and ambu-
lance, public safety networks, train radios, transport services, and the military. The TETRA
standard is used in the Swedish public safety net Rakel. Today the hand-held devices in
Rakel do not use a SIM card to hold the user identity. Instead, the terminal is personalised
by hard coding the user information in the terminal. As the users group grows a need for
SIM cards will probably emerge since it simplifies the handling of the users for the network
administrator, and allows the user to replace a broken terminal by simple moving his/her
SIM card to another terminal. This master thesis examines the TSIM standard and extracts
a specification of requirements, proposes a suitable software architecture, and partially im-
plements TSIM functionality on a smart card. The conclusion is that a TSIM application
can be integrated with an E2EE application but some modifications are needed compared to
only having the TSIM functionality in the smart card. The design and architecture described
in this master thesis can be used in systems that already use the SIM slot of the hand-held
devices for a smart card that extends the functionality of the terminal.
Nyckelord
Keywords smart card, TETRA, sim
Abstract
TETRA is an open radio standard developed by ETSI. It is specifically designed
for use by government agencies, emergency services such as police forces, fire
departments, and ambulance, public safety networks, train radios, transport ser-
vices, and the military. The TETRA standard is used in the Swedish public safety
net Rakel. Today the hand-held devices in Rakel do not use a SIM card to hold
the user identity. Instead, the terminal is personalised by hard coding the user
information in the terminal. As the users group grows a need for SIM cards will
probably emerge since it simplifies the handling of the users for the network ad-
ministrator, and allows the user to replace a broken terminal by simple moving
his/her SIM card to another terminal. This master thesis examines the TSIM stan-
dard and extracts a specification of requirements, proposes a suitable software
architecture, and partially implements TSIM functionality on a smart card. The
conclusion is that a TSIM application can be integrated with an E2EE application
but some modifications are needed compared to only having the TSIM functional-
ity in the smart card. The design and architecture described in this master thesis
can be used in systems that already use the SIM slot of the hand-held devices for
a smart card that extends the functionality of the terminal.
iii
Acknowledgments
I would like to thank Sectra Communications AB for giving me the opportunity
to carry out this master thesis. My supervisor at Sectra Jerry Falkcrona has been
a great help with both the technical questions about smart cards, the ETSI specifi-
cations and the content and structure of the report. I would also like to thank my
examiner and supervisor at Linköping University, Ola Dahl and Per Karlström,
for the help with the content and technical details about the report. Last but not
least, I would like to thank my opponent Mikael Rothin for good and constructive
criticisms.
Linköping, June 2012

Jonas Olofsson
v
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background 7
2.1 TETRA – Terrestrial Trunked Radio . . . . . . . . . . . . . . . . . . 7
2.1.1 Rakel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 SIM – Subscriber Identification Module . . . . . . . . . . . 11
2.3 Sectra TETRA E2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Requirements 15
3.1 SIM Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Electronic Signals and Transmission Protocols . . . . . . . . . . . . 17
3.2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 ATR - Answer To Reset . . . . . . . . . . . . . . . . . . . . . 17
3.2.3.1 PPS Procedure . . . . . . . . . . . . . . . . . . . . 18
3.2.3.2 Error Handling . . . . . . . . . . . . . . . . . . . . 18
3.3 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 DF – Dedicated Files . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 EF – Elementary Files . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2.1 Transparent EF . . . . . . . . . . . . . . . . . . . . 20
3.3.2.2 Linear Fixed EF . . . . . . . . . . . . . . . . . . . . 20
3.3.2.3 Key EF . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2.4 Cyclic EF . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3 File Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.4 File IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
vii
viii CONTENTS
3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 OTAR Cipher Key Distribution . . . . . . . . . . . . . . . . 25
3.4.3 File Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Contents of the EFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Procedures over the ME/SIM interface . . . . . . . . . . . . . . . . 32
4 Architecture 35
4.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 File Access Conditions . . . . . . . . . . . . . . . . . . . . . 36
4.2 System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5 Design 41
5.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.1 File Access Conditions . . . . . . . . . . . . . . . . . . . . . 43
5.1.2 File Commands . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.2.1 SELECT . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.2.2 READ BINARY . . . . . . . . . . . . . . . . . . . . 45
5.1.2.3 UPDATE BINARY . . . . . . . . . . . . . . . . . . 46
5.1.2.4 READ RECORD . . . . . . . . . . . . . . . . . . . 46
5.1.2.5 UPDATE RECORD . . . . . . . . . . . . . . . . . . 48
5.1.2.6 SEEK . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2.7 INVALIDATE . . . . . . . . . . . . . . . . . . . . . 49
5.1.2.8 REHABILITATE . . . . . . . . . . . . . . . . . . . 50
5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.1 GET RANDOM . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.2 TA11/TA12 Algorithm . . . . . . . . . . . . . . . . . . . . . 52
5.2.3 TA21/TA22 Algorithm . . . . . . . . . . . . . . . . . . . . . 53
5.2.4 TB4/TE Algorithm . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.5 GET RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Verification 57
6.1 Requirement Verification . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 Card Acceptance Test . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.1 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.1 Session Initialization . . . . . . . . . . . . . . . . . . . . . . 63
CONTENTS ix
6.4.2 Authentication Between SIM and the SwMI . . . . . . . . . 64
7 Conclusions 65
7.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Bibliography 67
x CONTENTS
Introduction
1
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 of
abbreviations used in the report is presented.
1.1 Background
SIM is a method to establish the identity of a subscriber and allow the operator
to set the appropriate user privileges in a mobile network. SIM cards are today
used in most types of mobile telephones and are mandatory according to the
Global System for Mobile Communications (GSM) standard. TETRA is an open
radio standard developed by the European Telecommunications Standards Insti-
tute (ETSI). TETRA systems today support the use of a SIM card and most mod-
ern TETRA terminals have a SIM slot. The SIM card functionality is currently not
supported by the terminals in the Swedish public safety net Rakel; Rakel is the
name of the TETRA network used by the Swedish emergency services. As TETRA
is spread to a larger user group in the community the SIM functionality can be
used to ease the handling of the subscribers for the network administrators.
Sectra Communications AB, from here on referred to as Sectra, has developed

an End to End Encryption (E2EE) system for a TETRA network. Sectra’s E2EE
system consist of a set of encryption functions. These encryption functions are
implemented on a smart card that is placed in the SIM slot of the hand-held
device. If a SIM card shall be used to hold the subscriber identity, it requires that
the smart card used for encryption can handle the SIM functionality.
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 work
packages have been identified:
• Analyse the standard for TSIM by ETSI and investigate unclear parts.
• Select the requirements and functions that shall be provided by a SIM card
for TETRA when the TSIM application shall coexist with an E2EE applica-
tion.
• Suggest a software architecture and a software design that are suitable for
the TSIM functionality on a smart card. The TSIM application and the ex-
isting E2EE application shall coexist on one smart card.
• Implement the TSIM functionality on a smart card and develop tests to ver-
ify the functionality. No physical terminal supporting the use of a SIM card
is available for verification, so the tests performed are the only verification
that the system works as intended.
1.2.1 Limitations
Due to licensing and the process of obtaining access to some algorithms used in
TETRA (for example the authentication algorithms), dummy algorithms are used
when the algorithm is not available. This simplification allows for testing of the
functionality but not of the actual compliance with a live network.
1.3 Document Outline

A brief description of the following chapters is given below.
• Background: Gives background information about TETRA, smart cards

and Sectra’s TETRA E2EE system.
• Requirements: Describes and selects the requirements that must be ful-

filled to implement a TSIM application.
• Architecture: Describes the system architecture.
• Design: Describes the design of the system.
• Verification: Describes the test cases used to verify the system.
• Conclusions: The last chapter describes what was found during the master
thesis, thoughts about the findings, and future work.
1.4 Abbreviations 3
1.4 Abbreviations
APDU Application Protocol Data Unit
ATR Answer To Reset
CCK Common Cipher Key
CPU Central Processing Unit
DCK Derived Cipher Key
DCK1 Component one of the DCK
DCK2 Component two of the DCK
DF Dedicated File
DMO Direct-Mode Operation
E2EE End to End Encryption
EEPROM Electrically Erasable Programmable Read Only Memory
EF Elementary File
ETSI European Telecommunications Standards Institute, www.etsi.org
FIPS Federal Information Processing Standard
GCK Group Cipher Key
GSM Global System for Mobile Communications
HAL Hardware Abstraction Layer
IC Integrated Circuit
ICC Integrated Circuit Chip
IEC International Electrotechnical Commission
ISO International Organization for Standardization
ITSI Individual TETRA Subscriber Identity
K Encryption Key, a key used by the authentication process for
SwMI authentication
KE Key Encryption
KEK Key Encryption Key
KS Session Authentication Key
KS’ Session Authentication Key
ME Mobile Equipment
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ör
Samhällsskydd och Beredskap) www.msb.se
OS Operating System
OTAK Over The Air Rekeying
OTAR Over The Air Rekeying
PIN Personal Identification Number
PMR Private Mobile Radio
PPS Protocol and Parameters Selection
Rakel Radio communication for e↵ective leadership
(Radiokommunikation för e↵ektiv 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
Background
2
This chapter gives background information about TETRA and smart cards. A
short description of Sectra’s E2EE smart card for TETRA is also presented.
2.1 TETRA – Terrestrial Trunked Radio

TETRA is an open radio standard developed by the ETSI. The mandate to develop
the TETRA standard was given by the European Commission. The standard is
a digital trunked Private Mobile Radio (PMR) communication system. TETRA
was specially designed for use by government agencies, emergency services such
as police forces, fire departments and ambulance, public safety networks, train
radios, transport services and the military. [2, 18]
Time Division Multiple Access (TDMA) is used in TETRA to get four user chan-
nels on one radio carrier. 25 kHz spacing is used between the radio carriers. Both
point-to-point and point-to-multipoint transmissions can be used, meaning that
one transmitter can communicate with one or more receivers. In addition to voice
communication, data transmission is included in the standard. [18]
A TETRA Mobile Station (MS) can communicate using Direct-Mode Operation
(DMO) or Trunked-Mode Operation (TMO) using Switching and Management
Infrastructure (SwMI) built of TETRA Base Stations (TBS). The use of DMO al-
lows the MS to communicate with other MS in range even if there is no network
coverage. This is particularly useful for emergency services when working during
a catastrophe or undergrounds.
TETRA includes a feature where one or more TETRA terminals can work as relays,
and by doing this the network coverage is extended, as seen in Figure 2.1. For
7
8 2 Background
example, a police officer can use the TETRA terminal on the car as a gateway for
his hand-held device. A car terminal can operate at a higher e↵ect than a hand-
held device. So by using the car terminal as a relay, the operative can use his/her
hand-held device to communicate with the network even when the hand-held
device does not have network coverage. [18]
If two operatives wants to talk to each other using DMO, but are not in range of
each other or the network, a third terminal in between can be used as a repeater.
The third terminal then repeats the transmission between the operatives who
want to communicate with each other. In this way, a terminal can work as relay
for terminals that needs to communicate with each other. [18]
Figure 2.1: The car is connected via TMO with the TBS (1) and DMO with
the operative (2). In this configuration the car’s TETRA terminal works as a
gateway for the operative.
Example of services provided by the TETRA standard are: [2]

• Voice Services
– Group Calls: A voice service in TETRA that allows several users to
talk to each other. Due to the complexity in supporting this in an
e↵ective and efficient way the public cellular networks are unsuitable.
– Pre-Emptive Priority Call (Emergency Call): Makes sure that an emer-
gency call always gets through in the network, even if it means that
another call has to be interrupted.
– Call Retention: Allows selected terminals to be protected from being
forced o↵ the network, for example due to a pre-emptive priority call.
For the network to work properly, the number of terminals provided
with call retention should be limited to a minimum.
– Priority Call: TETRA supports 16 di↵erent priority levels.
2.2 Smart Card 9
– Dynamic Group Number: Allows for dynamic creation of groups via

the network. This can be used to set up a group at for example, a crash
site.
– Ambience Listening: Allows a dispatcher to listen to the sounds from
a radio terminal without notifying the user. This mode can be used to
listen to the background noise even if a call is not in progress.
– Call Authorized by Dispatcher: Allows a dispatcher to verify calls
before they are allowed in the network. This can be very useful when
the network is overloaded.
– Area Selection: Defines the area of operation for the user.
– Late Entry: Allows a user to join a group call that is in progress.
• Data Services
– Short Data Service: Short data messages similar to SMS. The message
can be sent to one or many receivers.
– Packet Data: Allows for bigger data packages to be sent over the net-
work at a maximum throughput of 19.2 kbit/s.
The services supported by the standard are continuously evolved by ETSI. [2]
2.1.1 Rakel
Rakel is a TETRA network and is Sweden’s national communication system for
collaboration and leadership. The Swedish government owns Rakel’s infrastruc-
ture and the Swedish Civil Contingencies Agency (MSB) is responsible for the
expansion, operation, management, and development of Rakel as well as the mar-
keting and sales of subscriptions. Today Rakel covers 99,84 % of the Swedish
population and 95 % of the land area, excluding the mountain areas. The sys-
tem is built to work in the worst possible situation and all base stations have
additional power supplies, either in form of batteries or diesel generators. [1]
Rakel has been put in place to replace the earlier systems used by the emergency
services in Sweden and unite them under one communication system. The use
of a common communication system allows for easier collaboration between dif-
ferent emergency services as well as other public vital organizations, for example
power suppliers. [1]
2.2 Smart Card

"Smart cards", "chip cards" or "integrated circuit cards" are terms used for the
same thing [12]. In this document the term "smart card" will be used.
A smart card is often a credit card sized device but can exist in other form factors,
for example the SIM card used in mobile phones. One common thing for all
smart cards is that they contain one or more Integrated Circuits (ICs). There
10 2 Background
are three di↵erent types of ICs used in smart cards: memory only, wired logic
and microcontroller. A short description of the di↵erent card types can be found
below: [12]
• Memory Only ICC cards: Memory only cards use an electronic magnetic
stripe. Compared to a magnetic card this gives the memory only cards a
higher bandwidth, bigger storage capacity and a faster read/write speed.
In addition the reader for a memory only card is cheaper than a magnetic
stripe card reader. One variant of the memory only card is the serial pro-
tected memory chip card. This card contains some hardwired data that can-
not be overwritten. This makes the card safer than the ordinary memory
only card.
• Wired Logic ICC cards: Wired logic cards contain a logic-based state ma-
chine to provide encryption and authenticated access to on-board memory.
The encrypted access to the memory is optional and supported by a file sys-
tem provided with the wired logic chip card. The file system and command
set of a wired logic chip card can only be reconfigured by redesigning the
logic of the IC. Wired logic chip cards can exist as both contact and contact-
less smart cards.
• Secure Microcontroller ICC cards: Microcontroller cards are the most com-
plex of the three types of cards. They contain a microcontroller, an OS and
a read/write memory. The microcontroller ICs have been designed to meet
di↵erent security targets, for example the Common Access Card IC criteria
by the American Department of Defence. The commonly used term "Smart
Card" often refers to this type of card. A secure microcontroller smart card
usually consists of:
– 8-bit to 32-bit CPU.
– ROM or flash memory that contains the chip’s OS and, optionally, ap-
plication software.
– RAM for temporary registers to store temporary data.
– Non-volatile memory used for storage of user data, for example EEPROM,
ferroelectric RAM or flash memory.
– Countermeasures against known and foreseen security threats, to achieve
Common Criteria or FIPS 140-2 certifications.
– Environmental sensors.
– At least one serial port for communication with a card reader.
– A random number generator.
– Timers
– Optional cryptography accelerator(s).
– Optional dedicated peripherals.
2.2 Smart Card 11
All of the above described cards exist in many di↵erent implementations on the
market today. [12]
To use a smart card, one must be able to communicate with them. There are two
primary types of smart card interfaces: contact and contactless. The di↵erent
card types are described below: [12]
• Contact Smart Cards: A contact smart card requires a direct connection to

a conductive micromodule on the surface of the card. An example of how
the IC of a contact smart card can be embedded into a plastic card can be
seen in Figure 2.2.
• Contactless Smart Cards: The contactless smart card uses Radio Frequency
(RF) waves to communicate with a reader. The smart card must often be
close to the reader, generally within 10 centimetres.
• Hybrid Smart Cards: A hybrid smart card contains two microcontrollers;

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

the contact and contactless interface inside one microcontroller.
Figure 2.2: An illustration showing how the IC and contacts

of a smart card can be embedded into a plastic card. Source:
http://en.wikipedia.org/wiki/File:SIM_chip_structure_and_packaging.svg
The focus on the rest of this document will be on the contact version of the Secure
Microcontroller Integrated Circuit Chip (ICC) card. The reason is that this is
what a SIM usually is implemented as.
2.2.1 SIM – Subscriber Identification Module

SIM is typically an application implemented in a smart card. SIM cards replaces
the need to personalize the mobile phone or TETRA terminal. Instead a SIM card
can be used to hold the information about the subscriber and the subscription. A
SIM card can vary in size, as seen in Figure 2.3. [6]
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 di↵ers from the
SIM used in GSM due to di↵erent needs in the networks. The TSIM standard has
been developed by ETSI and can be found at http://www.etsi.org/.
2.3 Sectra TETRA E2EE

Today Sectra has a smart card for E2EE in TETRA. The E2EE works on both
voice and Short Data Service (SDS) and gives the user an encrypted connection
from the transmitter to the receiver. The TETRA standard today only supports
encryption over the air interface and not in the cables between the base stations.
By using Sectra’s E2EE solution, the transmissions are protected during the whole
transmission. This is supported for both TMO and DMO transmissions. [16]
Sectra’s system consists of the smart card loaded into the SIM slot of the Mobile
Equipment (ME), an Over The Air Rekeying (OTAK) server that handles the key
distribution, a personalizer and the production of the smart cards. The system is
shown in Figure 2.4 and the steps are described below: [16]
1. Production: During this step, the smart card is loaded with the software
and is locked from future software changes.
2. Personalization: The smart card is loaded with a master key (KEK), the
address to the OTAK server, and other user specific information.
3. End User: The smart card is handed over to the end user.
4. OTAK: A server sending encrypted messages with keys to the smart card.
2.3 Sectra TETRA E2EE 13
Figure 2.4: Sectra TETRA E2EE system overview. [15]

Requirements
3
This chapter describes the requirements that shall be fulfilled according to the
standard for TSIM from ETSI. The requirements for TSIM are analysed and the
important requirements for this master thesis are extracted, and shown as seen
in Table 3.1. In addition to each requirement, a short background on the require-
ment or where to read more about it is presented.
Even if the standard shall be followed, not all requirements in the standard will
be fulfilled during the master thesis. The reason for this is the limited time for
the master thesis, so focus will be put on the mandatory software requirements.
Some requirements regarding the physical characteristics of the smart card are
out of scope of this thesis because they cannot be a↵ected (for these requirements
see Section 3.1 and Section 3.2).
In addition to the TSIM requirements, the TSIM application must be able to co-
exist with the existing applications, in this case Sectras E2EE application.
ID Description M/O
A unique Mandatory (M) or
A requirement description
requirement id optional (O)
Table 3.1: System requirement template.
The requirements given as shown in Table 3.1 are the requirements to be eval-
uated during this master thesis. Requirements only described by the text are
identified as important for a final product, but not important for a test imple-
mentation. Either because they handle non software requirements or because
they depend on the implementation environment.
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 follow
the ISO/IEC 7816-1 [17] standard for both card types. Both card types have the
same functionality but the physical characteristics di↵er. [6]
3.1.1 Format
On the ID-1 card, the identification number defined by EFI CCI D (described in
Section 3.6) must be printed on the card. On the plug-in SIM card, only the
individual account identifier and the check digit of the IC card identification
must be printed. [6]
3.1.2 Contacts
The position of the contacts on the smart card can be seen in Figure 3.1.
Figure 3.1: An example of the pin locations on a smart card. Note

that smart cards may di↵er in the layout of the contacts. Source:
http://en.wikipedia.org/wiki/File:SmartCardPinout.svg
The contacts in position C4 and C8 must not be supported by the smart card or
the ME in a SIM application. C6 is not allowed to be connected to anything in the
smart card if not used by another application. If these contacts are present and
not used by another application inside the smart card the terminal shall present
them to the smart card as ground or high impedance. [6]
When the device is turned o↵ normally, the SIM card shall be deactivated as
specified in ISO/IEC 7816-3 [17]. However, if the clock to the SIM card is stopped
the ME can deactivate the contacts in any order, but the supply voltage must
always be switched o↵ last. [6]
The contact pressure must be large enough to guarantee contact. The contact
shall be guaranteed even if vibrations occur. The contact pressure shall never be
greater than 0.5 N per contact. If the contact pressure is larger then this value,
the smart card can be damaged. [6]
3.2 Electronic Signals and Transmission Protocols 17
3.2 Electronic Signals and Transmission Protocols

A SIM-card can support both 3 V and 5 V technologies, or only 5 V. [6]
More information about limits for current and voltage can be found in TS 100
977 [7] and ETS 300 641 [5].
3.2.1 States
The SIM card can be in two di↵erent states while the power supply is on. [6]
• Operating State: The SIM is in this state when executing a command. Trans-
missions to and from the ME are also included.
• Idle State: The SIM is in this state at any other time. In this state, the
temporary memory shall be kept.
The SIM may also support a clock stop mode. Clock stop means that the ME is
allowed to switch o↵ the clock to the smart card. If the clock stop mode shall be
used, the ME has to wait 1860 clock cycles after receiving the last character of
the last request before switching o↵ the clock. Before the first command is issued
after the clock has been started, the ME has to wait at least 744 clock cycles. [6]
3.2.2 Baud Rate

The baud rate shall initially be set to (clock frequency)/372. During the rest of
the transmissions the baud rate shall be kept, unless the Protocol and Parameters
Selection (PPS) procedure has been performed and has been negotiated another
baud rate (see Section 3.2.3.1). [7]
3.2.3 ATR - Answer To Reset

Answer To Reset (ATR) is information that the SIM card presents to the ME at the
beginning of a session. The information is presented after the ME resets the SIM
card. The characters that are sent with the ATR are given and explained in TS
100 977 [7]. [6]
ID Description M/O
An ATR shall be presented by the SIM card
1 M
at the beginning of every session.
The ATR shall contain the information given
2 M
in TS 100 977 [7].
The information inside the ATR shall match
both the requirements for a TSIM
3 M
application and the existing Sectra
encryption functions.
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] and
TS 100 977 [7].
3.2.3.2 Error Handling
If something is wrong with the received ATR, the ME shall reset the SIM card
again to receive a new ATR. If a bad ATR is received three times or more the ME
is allowed to reject the SIM card, but the ME must try at least three times. [7]
3.3 File System

The file system can be seen in Figure 3.2. This figure shows the relationship and
hierarchy between the di↵erent file types that are defined in Section 3.3.1 and
3.3.2.
Figure 3.2: File system overview. [6]
Each file consists of a header and an optional body part. Operations on files can
be performed by commands sent from the ME to the smart card. The commands
"GET RESPONSE" and "STATUS" can extract the information stored in the header.
In the header, information about the structure and attributes of the file is stored.
This information is fixed during the personalization phase. In the body part of a
file the actual data is stored. [6]
Each file has a unique file ID. The file ID consists of two bytes. The first byte
identifies the file type and can be seen below: [6]
• "3F": MF
• "7F": First level DF
• "5F": Second level DF
• "2F": EF under the MF
• "6F": EF under the first level DF
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
A file shall consist of a header and an
4 M
optional body part.
Each file under a DF shall have a unique file
5 M
ID.
The file ID shall consist of two bytes,
6 M
following the rules above.
Table 3.3: File system requirements.
3.3.1 DF – Dedicated Files

A Dedicated File (DF) is a grouping of files. It consists of itself and all files in the
complete subtree (all files that has the DF in the parental hierarchy). The DF has
no body. DFTETRA and DFTELECOM are two examples of DFs. Both are children of
the Master File (MF) and can coexist in a multi-application card.
This document will focus on the DFTETRA , and if nothing else is mentioned all
Elementary Files (EFs) and second level DFs are defined under the DFTETRA .
ID Description M/O
A DF shall consist of a header but no body
7 M
part.
Table 3.4: DF requirements.
3.3.2 EF – Elementary Files

The EF consists of both a header and a body part. In TETRA four structures are
used and they are described in the following subsections.
20 3 Requirements
ID Description M/O
An EF shall consist of both a header and a
8 M
body part.
The transparent EF shall function as
9 M
described in Section 3.3.2.1.
The linear fixed EF shall function as
10 M
described in Section 3.3.2.2.
The key EF shall function as described in
11 O
Section 3.3.2.3.
The cyclic EF shall function as described in
12 M
Section 3.3.2.4.
Table 3.5: EF requirements.
3.3.2.1 Transparent EF
The Transparent EF body consists of a sequence of bytes. When one or more

bytes shall be read or written, a relative start address and the number of bytes to
operate on are indicated. The first byte in the body of a Transparent EF always
has the relative address 0. The total length of the body can be found in the header.
The EF structure can be seen in Figure 3.3. [6]
Figure 3.3: Structure of a transparent EF.
3.3.2.2 Linear Fixed EF
Linear Fixed EF consists of a sequence of records. All records have the same
length and the records are numbered from 1 to n. The header stores the record
length as well as the record length multiplied with the total number of records.
Figure 3.4 shows the structure of a Linear Fixed EF. A Linear Fixed EF cannot
keep more than 255 records and a record must not be greater than 255 bytes. [6]
The following list describes the di↵erent ways of accessing a record inside the EF
(if an action is aborted for some reason, the pointer shall keep the value that it
had before the action was started): [6]
• Absolute by using the record number.
• When the record pointer is not set, the first and last record can be accessed.
3.3 File System 21
• When the record pointer is set, one can perform actions on the current, next
and previous record (unless the pointer is set to the last or first record).
• Identify a record using pattern seek starting:
– Forward from the start of the file.
– Forward from the next record of which the pointer is set (if not the
pointer is set to the last record).
– Backwards from the end of the file.
– Backward from the previous record of which the pointer is set (if the
pointer is not set to the first record).
Figure 3.4: Structure of a linear fixed EF.
3.3.2.3 Key EF
A Key EF consists of a sequence of records of the same length. They are numbered
from 1 to n. The header stores the length of a record as well as a multiple of the
length and the number of records. The structure can be seen in Figure 3.5. To
access a Key EF, only absolute addressing can be used and the address is the
record number. One EF cannot store more than 255 records and the length of
a record cannot exceed 255 bytes. This is the same limitations as for the Linear
Fixed EF. [6]
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 in
Figure 3.6. The record numbers in a Cyclic EF are changing so that the newest
records always is record 1. A cyclic EF consists of a fixed number of records with
the same length. The last and the first records are linked together so that a cycle
is formed. [6]
Figure 3.6: Structure of a cyclic EF.
In Section 5.1.2.4, di↵erent modes are described for accessing the Cyclic EF. When
updating a record the "PREVIOUS" mode shall be used, but when reading a
record the modes "NEXT", "PREVIOUS", "CURRENT", or "RECORD NUMBER"
can be used. The record pointer shall always point to the oldest record. If an
action is aborted, the record pointer shall not be changed. The same limitation
as for the above described EFs holds for the Cyclic EF as well, there can never be
more than 255 records in the EF and a record cannot exceed 255 bytes. [6]
3.3.3 File Selection

After the ATR has been sent, the MF is selected as the "Current Directory". From
here, other files can be selected. The TETRA system defines two levels of DFs
under the MF. An example can be seen in Figure 3.7. [6]
From the current file, the following files can be selected: [6]
• Any file that is an immediate child of the "Current Directory"
• Any DF that is an immediate child of the current DF
• The parent of the "Current Directory"
• The current DF
• The MF
3.3 File System 23
Figure 3.7: Example file structure.
In order to select an EF, the DF for that EF must first be selected. An example
of how files can be accessed can be seen in Table 3.6. The "Current Directory" is
always set when the MF or a DF is selected, and the "Current EF" is cleared once
a new "Current Directory" is set. The "Current EF" is set once an EF is selected.
The "Current EF" is always a child of the "Current Directory". [6]
Last Selected File Valid Selections

MF DF1, DF2, EF1
DF1 MF, DF2, DF3, EF2
DF2 MF, DF1, EF3, EF4
DF3 MF, DF1, DF2, EF5
EF1 MF, DF1, DF2
EF2 MF, DF1, DF2, DF3
EF3 or EF4 MF, DF1, DF2
EF5 MF, DF1, DF3
Table 3.6: Allowed file selection for the example structure given in Fig-
ure 3.7.
ID Description M/O
A file shall only be selected according to the
13 M
rules given in EN 300 812-3 [6].
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
The reserved file IDs defined in EN 300
14 M
812-3 [6] shall be used.
Table 3.8: File IDs requirements.
3.4 Security
This section will only handle the security related TETRA features that are rele-
vant to the SIM. For other security aspects of TETRA see EN 300 392-7 [9] and
EN 300 396-6 [10].
The security of an MS is defined by a security class, see EN 300 392-7 [9] for
more information. Table 3.9 shows what the SIM needs to support in terms of
functions and key storage for di↵erent security classes.
3.4 Security 25
Class Authentication Key Storage OTAR OTAR OTAR

SCK GCK CCK
1 O n/a n/a n/a n/a
2 O SCK O n/a n/a
DCK, CCK,
3 M GCK, O O M
MGCK
Table 3.9: Security class and provided services. M = mandatory, O = optional

and n/a = not applicable. [6]
3.4.1 Authentication
The authentication process is built around a symmetric key. To read more about
symmetric keys see [4]. The key shall be shared between two parties that shall
be able to authenticate each other. The key must be kept secret from everyone
else. The two authentication parties shall prove to each other that they know the
shared key through the authentication process. The parties are the authentication
center of the SwMI and the MS. The MS is representing the user as defined by
the assigned Individual TETRA Subscriber Identity (ITSI). The SwMI can use a
base station for the authentication process. [9]
In the MS, the authentication key must be protected. A common way to do this is
to force the user of the MS to enter a Personal Identification Number (PIN) before
the authentication key can be used. [9]
The authentication process is described in EN 300 392-7 [9]. The requirements

on the authentication process are given in Table 3.10
ID Description M/O
A shared key shall be used for the
15 M
authentication process.
16 The authentication key shall be protected. M
The authentication key shall be protected by
17 O
a PIN.
The authentication process shall follow the
18 M
behaviour described in EN 300 392-7 [9].
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 performed
on them. The access condition shall always be fulfilled before a requested action
is performed. The di↵erent levels of access conditions can be seen in Table 3.11.
[6]
The di↵erent access levels are described below: [6]
NEV The action can only be performed internally on the SIM and not over the
SIM/ME interface.
AUTI The action can be performed by the MS over the SIM/ME interface if the
previous action over the SIM/ME interface was a successful authentication
of the SwMI.
PIN1 The action is only possible if one of the following conditions is fulfilled:
• A correct PIN1 value has been presented to the SIM during the current
card session.
• The PIN1 enabled/disabled indicator is set to disabled.
• UNBLOCK PIN1 has been successfully performed during the card 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 current
card session.
• UNBLOCK PIN2 has been successfully performed during the current
card session.
ADM Allocation of these levels and the requirements that they demand are the
responsibility of the appropriate administrative authority.
ALW The command is always possible.
Level Access Condition

0 ALW
1 PIN1
2 PIN2
3 AUTI
4 to 14 ADM
15 NEV
Table 3.11: Access condition level coding. [6]

3.5 Functions 27
ID Description M/O
It shall only be possible to access a file if its
19 M
access condition has been met.
Table 3.12: File access requirements.
3.5 Functions
A function is an operation that consists of a command being sent to the smart card
from the terminal. The command then triggers an operation inside the smart
card. The smart card then returns a response consisting of two status words
telling how the operation went and optional data. This section lists the available
commands.
The following functions are described in EN 300 812-3 V2.3.1 [6]:
• SELECT
• STATUS
• READ BINARY
• UPDATE BINARY
• READ RECORD
• UPDATE RECORD
• READ KEY
• SEEK
• VERIFY PIN
• CHANGE PIN
• DISABLE PIN
• ENABLE PIN
• UNBLOCK PIN
• INVALIDATE
• REHABILITATE
• TETRA Authentication Algorithms
– GET RANDOM
– TA11/TA12
– TA21/TA22
– TB4/TE
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
Functions handling files shall exist if the
20 M
corresponding file type exist.
21 All PIN functions shall exist. M
The invalidate and rehabilitate function
22 O
shall exist.
23 The authentication functions shall exist. M
24 The OTAR functions shall exist. O
Table 3.13: Function requirements.
3.5.1 Mapping
Functions are mapped onto Application Protocol Data Units (APDUs) and are
then used by the transmission protocol. An APDU can be a command APDU or
a response APDU. Figure 3.8 shows a command APDU and Figure 3.9 shows a
response APDU. [6]
More about the specific combinations and codes that shall be used can be found
in Section 4.2 and ETSI EN 300 812-3 [6].
Figure 3.8: The format of a command APDU. [6]

3.6 Contents of the EFs 29
Figure 3.9: The format of a response APDU. [6]
3.6 Contents of the EFs

Table 3.14 shows the di↵erent EFs that should be present and under which DF
they are located. If an EF is unassigned or cleared, all its bytes should be set to
"FF". [6]
EF Description Structure M/O

EFs at MF level
EFICCID Card identification T M
EFDIR Application directory T O
EFLP Language preference T M
EFs at TETRA application level
EFSST SIM service table T M
Individual TETRA
EFITSI T M
subscriber identity
EFITSIDIS ITSI disabled T M
EFUNAME Username T O
EFSCT Subscriber class table T M
EFPHASE Phase identification T M
EFCCK Common cipher key LF O
EFCCKLOC CCK location areas T O
EFSCK Static cipher Key LF O
EFGSSIS Static GSSIs LF M
Group related data for
EFGRDS LF M
static GSSIs
EFGSSID Dynamic GSSIs LF M
Group related data for
EFGRDD LF M
dynamic GSSIs
EFGCK Group cipher keys LF O
EFGINFO User’s group information T M
EFSEC Security settings T M
EFFORBID Forbidden networks C M
EFPREF Preferred networks LF O
EFSPN Service provider name T O
Broadcast network
EFDNWRK LF M
information
30 3 Requirements

EFNWT Network table LF M
EFGWT Gateway table LF M
EFCMT Call modifier table LF O
Abbreviated dialling
EFADNGWT LF O
number with gateways
EFGWTEXT1 Gateway extension 1 LF O
EFADNTETRA numbers for TETRA LF O
networks
EFEXTA Extension A LF O
Fixed dialling numbers
EFFDNGWT LF O
with gateways
EFGWTEXT2 Gateway extension 2 LF O
Fixed dialling numbers
EFFDNTETRA LF O
for TETRA network
EFEXTB Extension B LF O
Last number dialled with
EFLNDGWT C O
gateways
Last numbers dialled for
EFLNDTETRA C O
TETRA network
Service dialling number
EFSDNGWT LF O
with gateway
EFGWTEXT3 Getaways extension 3 LF O
Service dialling numbers
EFSDNTETRA LF O
for TETRA network
EFSTXT Status message texts LF O
EFMSGTXT SDS-1 message texts LF O
Status and SDS type 1, 2
EFSDS123 LF O
and 3 message storage
SDS type 4 message
EFSDS4 LF O
storage
EFMSGEXT Message extension LF O
EFEADDR Emergence addresses LF M
Emergency call
EFEINFO T M
information
DMO radio channel
EFDMOCh LF O
information
MS allocation of DMO
EFMSCh T O
channels
EFKH List of key holders T O
DMO repeater and
EFREPGATE LF O
gateway list
EFAD Administrative data T M
EFPREF_LA Preferred location areas T O
3.6 Contents of the EFs 31

EFLNDComp Composite LND file C O
EFDFLSTSGT Status default target T O
EFSDSMEM_STATUS SDS memory status T O
EFWELCOME Welcome message T O
EFSDSR SDS delivery report LF O
EFSDSP SDS parameters LF O
Dialling schemes for
EFDIALSC T M
TETRA network
EFAPN APN table LF O
Private number
EFPNI LF O
information
EFSCAN Scan list files LF O
EFSCAND Scan list data LF O
DMO pre-programmed
EFDMO_GSSIS LF O
group numbers
Grouped related data for
EFDMO_GRDS LF O
DMO static GSSISs
TMO-DMO selected
EFGTMO_GDMO LF O
group association
DMO-TMO selected
EFGDMO_GTMO LF O
group association
Default encryption
EFDMO_DEP T O
parameters
EFGSKO Group session key LF O
EFs at TELECOM level
EFADN LF O
numbers
EFFDN Fixed dialling numbers LF O
Mobile Station ISDN
EFMSISDN LF O
Number
EFLND Last number dilled C O
EFSDN Service dialling numbers LF O
EFEXT1 Extension 1 LF O
Table 3.14: Content of the EFs. [6] M/O = Mandatory/Optional according

to [6], T = Transparent, LF = Linear fixed, C = Cyclic
More information about file types and what the EFs contain can be found in ETSI
EN 300 812-3 [6].
32 3 Requirements
ID Description M/O
The mandatory EFs given in Table 3.14 shall
25 M
exist.
The optional EFs given in Table 3.14 shall
26 O
exist.
Table 3.15: Content of the EFs requirements.
3.7 Procedures over the ME/SIM interface

During a TETRA network operation the SIM and ME exchange messages via the
SIM/ME interface. This can be any of the following: [6]
• A command/response pair that consists of a command and its response.
• A procedure that consists of one or more command/response pairs.
In ETSI EN 300 812-3 [6] the procedures in Table 3.16 are described.
Procedure Mode
General Procedures
Reading an EF ME
Updating an EF ME
Invalidating an EF ME
SIM Management Procedures
SIM initialization ME
TETRA session initialization ME
TETRA session termination ME
Language preference request ME
Administrative information request ME
SIM service table request ME
SIM phase request ME
SIM presence detection ME
PIN Related Procedures
PIN verification MMI
PIN value substitution MMI
PIN disabling MMI
PIN enabling MMI
PIN unblocking MMI
TETRA Security Related Procedures
TETRA algorithms computation NET
TETRA key computation NET
ITSI request NET
ITSI disabling NET
Location Information NET
Broadcast network information NET
3.7 Procedures over the ME/SIM interface 33
Forbidden networks information NET

Subscription Related Procedures
Username MMI
Subscriber class request ME
Group information MMI/NET
User’s group information ME/NET
Call modifiers NET/ME
Network information ME
Dialling numbers MMI/ME
SDS messages MMI
Preferred networks MMI
Service provider name ME
ICCID ME
Emergency addresses ME/MMI
Table 3.16: List of procedures at the SIM/ME interface in TETRA network

operation described in ETSI EN 300 812-3 [6].
ME = Procedures automatically initiated by the ME.
MMI = Procedures that requires human interactions.
NET = Procedures initiated due to interactions between the MS and the
TETRA infrastructure.
Architecture
4
This chapter describes the architecture of a TSIM application. The architecture
is an extraction from the requirements described in Chapter 3. According to [3],
software architecture is "the structure or structures of the system, which com-
prises software elements, the externally visible properties of those elements, and
the relations among them". Here, the architecture describes the general and struc-
tural aspects of a TSIM application. To get more specific details about which files
and functions that shall exist see Chapter 5.
4.1 File System

The file system is based on the file structure shown in Figure 4.1. The figure
shows that the DFTETRA is located under the MF. All files that belong to the
TSIM application shall reside under the DFTETRA .
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 conditions
are used to determine if a file can be read or updated. The four di↵erent access
conditions and notations that are used are:
• NEV: The operation is never allowed on the file, the operation can be per-
formed internally by the SIM.
• ALW: The operation is always allowed on the file.
• PIN1: The operation is allowed on the file if a valid user PIN has been
entered.
• ADM: The operation is allowed on the file if a valid administrator PIN has
been entered.
4.2 System Commands

In Section 3.5.1 the requirements for the mapping of commands are described.
The command APDU is shown in Figure 4.2. The CLA, INS, P1 and P2 fields
must be present. The Lc and DATA fields are only present if data is added to the
command and the Le field is present if the terminal expects a response. The Le
field specifies the amount of data that the terminal expects to be returned.
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 APDU
have the following meaning: [6]
• DATA: The response data.
• SW1, SW2: Status words to indicate a successful or unsuccessful command,
see Table 4.1.
Figure 4.3: The format of a response APDU. [6]
Table 4.1 shows the coding of the status words SW1 and SW2 that are used with
the response APDU.
SW1 SW2 Description

Correctly Executed Command
"90" "00" Normal ending of the command
"9F" "XX" Length "XX" of the response data
Memory Management
Command successful after using an internal
"92" "0X"
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
Access condition not fulfilled unsuccessful
due to PIN verification, at least one attempt
"98" "04"
left or unsuccessful UNBLOCK PIN
verification, at least one attempt left
"98" "08" In contradiction with PIN status
"98" "10" In contradiction with invalidation status
Unsuccessful PIN verification, no attempt
left unsuccessful UNBLOCK PIN
"98" "40"
verification, no attempt left PIN blocked
UNBLOCK PIN blocked
"98" "60" Manipulation flag set
"98" "70" SwMI authentication unsuccessful
38 4 Architecture
SW1 SW2 Description

Application Independent Errors
Incorrect parameter Lc ("XX" gives the
"67" "XX" correct length or states that no additional
information is given ("XX" = "00"))
Command not allowed (see Table 4.2 for the
"69" "XX"
coding of SW2)
Wrong parameter in P1 or P2 (see Table 4.3
"6A" "XX"
for the coding of SW2)
Incorrect parameter P1 or P2 (When the
error in P1 or P2 is caused by the addressed
"6B" "00"
record being out of range, "94 02" shall be
used instead.)
Unknown instruction code given in the
"6D" "00"
command
Wrong instruction class given in the
"6E" "00"
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 and
the SwMI. In this process the algorithms TA11, TA12, TA21, TA22, and TB4 are
performed in the SIM on the MS side.
The variables produced during the authentication process are specified in ETSI
EN 300 392-7 [9] and the dimensions are shown in Table 4.4. These dimensions
shall be kept to guarantee compatibility with the standard.
Figure 4.4: Mutual authentication between the SIM and SwMI. [9]
Parameter No. of bits

DCK 80
DCK1/DCK2 80
K 128
KS/KS’ 128
RAND1/RAND2 80
RES1/RES2 32
RS 80
XRES1/XRES2 32
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 structure
allows the smart card and its Memory Management Unit (MMU) to manage the
internal security, to ensure that one package cannot access another package with-
out permission. The packages used for the TSIM application can be seen in Fig-
ure 4.5.
Figure 4.5: The packages on the smart card.
The packages are divided into two groups, application packages and card/devel-
opment packages.
The card/development packages include the Hardware Abstraction Layer (HAL)
package and the Security Layer Package. These packages are parts of the smart
card and the development environment. They handle the on chip security and
the calls to the di↵erent parts of the smart card. These packages can only be
accessed by the OS Package. To use any of the functions that are accessed through
either the HAL packge or the Security Layer Package, the function call must pass
through the OS Package.
The OS Package does not contain an OS, it is just a name for the package con-
taining the functions to be used when using the functionality in the HAL and
Security Layer Packages.
The application packages are described in Section 5.3.
5
Design
This chapter presents the design of the system. The design shall comply with the
architecture described in Chapter 4. The design shall be testable, to provide a
way to verify the requirements given in Chapter 3. The verification is described
in Chapter 6.
Requirements 1 to 3 are covered by the existing ATR in the smart card. For
more information about how the ATR shall be built, see ETSI TS 100 977 [7]
and ISO/IEC 7816-3 [17].
The same situation holds for requirement 21, since the smart card application
has support for two levels of PIN, and the functions VERIFY PIN, CHANGE PIN,
DISABLE PIN, ENABLE PIN and UNBLOCK PIN. For more information about
the PIN see ETSI EN 300 812-3 [6].
One important change compared to if only a TSIM application is implemented is

that no application is created for TSIM. Instead, the files and functions described
below shall be accessible from the already existing E2EE application. This means
that the terminal, instead of selecting the TSIM application prior to using the
TSIM functions and files, selects the E2EE application and can from the E2EE
application use the files and functions belonging to the TSIM application. The
reason is that the E2EE application must be selected to get a TSIM application
with E2EE functionality and only one application can be selected at a time in a
smart card.
41
42 5 Design
5.1 File System

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

Files under MF
The DF that contains the
DFTETRA DF "7F90"
TETRA specific files
Unique card identification
EFICCID T "2FE2"
number
A list of applications that are
EFDIR T "2F00"
supported by the card
EFLP Language preference T "2F05"
Files under DFTETRA
SIM service table, indicates
EFSST which of the optional services T "6F01"
and EFs that are available
Individual TETRA subscriber
EFITSI T "6F02"
identity
Indicates if ITSI is temporarily
EFITSIDIS T "6F03"
disabled
Subscriber class table, holds the
EFSCT class membership of the ITSI T "6F05"
subscription
EFPHASE Phase identification T "6F06"
Static GSSIs, contains the
EFGSSIS pre-programmed group LF "6F0A"
identities
Group related data for static
EFGRDS LF "6F0B"
GSSIs
Dynamic GSSIs, contains the
EFGSSID LF "6F0C"
dynamic group identities
Group related data for dynamic
EFGRDD LF "6F0D"
GSSIs
User’s group information,
contains the user’s last active
EFGINFO group, preferred groups and T "6F10"
information about using these
groups addresses
EFSEC Security settings T "6F11"
5.1 File System 43
File Description Structure File ID

EFFORBID Forbidden networks C "6F12"
Broadcast network information,
EFDNWRK LF "6F16"
see ETSI EN 300 392-2 [8]
Network table, contains the
EFNWT network part of the TETRA LF "6F17"
addresses
Gateway table, contains the
EFGWT names and addresses for LF "6F18"
gateways in the TETRA network
EFEADDR Emergence addresses LF "6F2C"
EFEINFO Emergency call information T "6F2D"
Administrative data, contains
EFAD information about the mode of T "6F32"
operation
Dialling schemes for TETRA
EFDIALSC T "6F46"
network
Table 5.1: The file structure, shows the hierarchy and the file identifiers.
More information about the content of the files and how the bytes are coded
can be found in ETSI EN 300 812-3 [6]. T = Transparent EF, LF = Linear
fixed EF, C = Cyclic EF. [6]
5.1.1 File Access Conditions

The files have di↵erent access conditions that must be met before the file can be
read or updated. Table 5.2 shows the read and update access conditions for the
files that shall be present in the system.
In addition to the access conditions given in Table 5.2, the INVALIDATE and
REHABILITATE commands have their own access conditions for each file. For
the files that shall be implemented, these two operations require the ADM access
condition to be fulfilled.
Read Access Update Access

File
Conditions Conditions
Files under MF
EFICCID ALW NEV
EFDIR ALW ADM
EFLP ALW PIN1
Files under DFTETRA
EFSST PIN1 ADM
EFITSI PIN1 ADM
EFITSIDIS PIN1 ADM
EFSCT PIN1 ADM
EFPHASE ALW ADM
44 5 Design
Read Access Update Access

File
Conditions Conditions
EFGSSIS PIN1 ADM
EFGRDS PIN1 PIN1
EFGSSID PIN1 ADM
EFGRDD PIN1 PIN1
EFGINFO PIN1 PIN1
EFSEC PIN1 ADM
EFFORBID PIN1 PIN1
EFDNWRK PIN1 ADM
EFNWT PIN1 PIN1
EFGWT PIN1 ADM
EFEADDR ALW PIN1
EFEINFO ALW PIN1
EFAD ALW ADM
EFDIALSC PIN1 ADM
Table 5.2: The read and update conditions for the files that shall be imple-
mented. [6]
5.1.2 File Commands

5.1.2.1 SELECT
The SELECT command is already implemented in Sectra’s E2EE application. The
command is used to select a file according to the rules for file selection described
in Section 3.3.3. The input and the output can be seen below: [6]
• Input from ME: File ID
• Input from SIM: None
• Output to ME:
– Selected file is a MF or a DF:
file ID, total memory space available, PIN enabled/disabled indica-
tor, PIN status
– Selected file is an EF:
file ID, file size, access conditions, invalidate/not invalidate indica-
tor, structure of the EF, and length of the records in case of linear
fixed structure of cyclic structure
The command APDU can be seen in Table 5.3.
The response from the SELECT command depends on the file type selected. For
an MF or DF Table 5.5 shows the response and for an EF Table 5.6 shows the
response. More details about the SELECT command can be found in ETSI TS 102
221 [11].
5.1 File System 45
Class INS P1 P2 Lc Data Le

"A0" "A4" "XX" "XX" length Table 5.4 -/"00"
Table 5.3: The command APDU for SELECT, P1 and P2 values depends on
how the SELECT command shall be used see ETSI TS 102 224 [11]. [11]
Byte(s) Description Length

1 to File ID, DF name or path to file
length
length (depends on P1)
Table 5.4: SELECT command data. [6]
Description Tag
File descriptor "82"
File identifier "83"
Proprietary information (only for MF) "A5"
Life cycle status integer "8A"
"8B", "8C"
Security attribute
or "AB"
PIN status template DO "C6"
Table 5.5: The order of the response data when SELECT is used on an MF or
a DF. [11]
Description Tag
File descriptor "82"
File identifier "83"
Proprietary information (only for MF) "8A"
Life cycle status integer "8A"
"8B", "8C"
Security attribute
or "AB"
File size "80"
Table 5.6: The order of the response data when SELECT is used on an EF.
[11]
5.1.2.2 READ BINARY
The READ BINARY command is already implemented in Sectra’s E2EE applica-

tion. The command is used to read a stream of bytes from the current transparent
EF. The read operation shall only be performed if the read access is satisfied for
the current EF (see Section 4.1.1). The input and the output: [6]
• Input from ME: Relative address and the length of the string

46 5 Design
• Output to ME: String of bytes

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

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

1 to
Data to be read length
length
Table 5.8: READ BINARY response data. [6]
5.1.2.3 UPDATE BINARY
The UPDATE BINARY command is already implemented in Sectra’s E2EE appli-

cation. The command updates the current transparent EF with a string of bytes.
This function shall only be performed if the UPDATE access condition for the EF
is satisfied (see Section 4.1.1). The input and the output are given below: [6]
Relative address and the length of the string,
• Input from ME:
string of bytes
• Output to ME: None
The command APDU can be seen in Table 5.9. The command parameters can be
seen in Table 5.10.

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

1 to
Data length
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 not
be updated. The input and output are given below: [6]
Mode, record number (for absolute mode) and
• Input from ME:
the length of the record
• Output to ME: The record
There are four di↵erent 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 pointer
is not a↵ected.
NEXT: The record pointer is incremented and then the record is read. If the
record pointer has not been set, the first record shall be read.
PREVIOUS: The record pointer is decremented before the record is read. If the
record pointer has not been set, the last record shall be read.
seen in Table 5.13.

A0" "B2" Table 5.12 Table 5.12 - - length
Table 5.11: The command APDU for READ RECORD. [6]
Mode P1 P2
CURRENT "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 UPDATE
RECORD depending on the mode of operation. [6]

1 to
The data of the record length
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. The
command shall only be performed if the update access condition is satisfied (see
Section 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 number
1. The input and the output are given below: [6]
Mode, record number (for absolute mode) and
• Input from ME:
the length of the record, the new data

"A0" "DC" Table 5.12 Table 5.12 length Table 5.15 -
Table 5.14: The command APDU for UPDATE RECORD. [6]

1 to
Data length
length
Table 5.15: UPDATE RECORD command data. [6]
5.1.2.6 SEEK
This function searches through the current linear fixed EF to find a record start-
ing with the given pattern and set the record pointer to point on that record.
The SEEK command can only be used when the read access is satisfied (see Sec-
tion 4.1.1). There are two types of SEEK: [6]
Type 1:
• Input from ME: Type and mode, pattern, length of the pattern
Type 2:
• Input from ME: Type and mode, pattern, length of the pattern
• Output to ME: Status/Record number
Four modes are defined for SEEK:
5.1 File System 49
• From the beginning and forward.

• From the end and backward.
• From the next location and forward.
• From the previous location and backward.
If the record pointer has not been set it should be set to the location of the first
record 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 be
seen in 5.19
"A0" "A2" "00" Table 5.17 length Table 5.18 -/"01"
Table 5.16: The command APDU for SEEK. [6]
Type/Mode P2
Type 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]

1 to
Pattern length
length
Table 5.18: SEEK command data. [6]

1 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). An
invalidated 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


"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 be
performed if the rehabilitate access condition is satisfied (see Section 5.1.1). The
input and the output are: [6]

"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 presented
to 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. The
algorithms used in the functions below are therefore only dummy algorithms and
the only similarity with the real algorithms is the dimension of the variables. The
GET RANDOM function described in Section 5.2.1 is not a dummy algorithm
and can be used with a live system in a real network.
The use of dummy functions, having the correct variable dimension and thereby
the correct interface format, in test situations where the actual algorithm is not
tested. In a live system, the dummy algorithms will be replaced by algorithms
according to the standard. To read more about dummy functions, or stubs, in

testing 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 l e n g t h A and l e n g t h B .

/ / R e s u l t i s w r i t t e n t o sum
void AddArray ( b y t e _ a r r a y termA , b y t e _ a r r a y termB , b y t e _ a r r a y sum )
/ / C a l c u l a t e t h e maximum and minimum l e n g t h

i 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 )
integer carry = 0
/ / Add t h e b y t e s c o v e r e d by b o t h a r r a y s
f o r ( i = 0 ; ( i < minLength ) && ( i < sum . Length ) ; i ++)
sum [ i ] = termA [ i ] + termB [ i ] + c a r r y
c a r r y = C a l c u l a t e C a r r y ( c a r r y , termA [ i ] , termB [ i ] )
/ / Check i f A o r B i s l o n g e s t . Then add t h e r e m a i n i n g numbers .

i f ( termA . Length > termB . Length )
f o r ( i ; ( i < maxLength ) && ( i < l e n g t h ) ; i ++)
sum [ i ] = termA [ i ] + c a r r y
c a r r y = C a l c u l a t e C a r r y ( c a r r y , termA [ i ] )
else
f o r ( i ; ( i < maxLength ) && ( i < l e n g t h ) ; i ++)
sum [ i ] = termB [ i ] + c a r r y
c a r r y = C a l c u l a t e C a r r y ( c a r r y , termB [ i ] )
Algorithm 5.1: "Add" two byte arrays
The dummy algorithm described by Algorithm 5.1 replaces the plus operator in
the equations in the subsections below. The only requirements on the dummy
algorithm described in Algorithm 5.1 was that it should somehow change the
data depending on the input.
5.2.1 GET RANDOM

This function shall produce a random number that shall be used in the authenti-
cation algorithms. The input and the output are given below:
• Output to ME: RAND2
The RAND2 shall be stored internally in the SIM to be used in the TA21/TA22
algorithm. [6]
seen in Table 5.23
The random number shall be generated using the Random Number Generator
(RNG) on the smart card.
52 5 Design

"A0" "CE" "00" "00" - - "0A"
Table 5.22: The command APDU for GET RANDOM. [6]

1 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 the
TETRA 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 command
described 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 response
parameters can be seen in Table 5.25 and Table 5.26.

"A0" "40" "00" "00" "14" Table 5.25 "04"
Table 5.24: The command APDU for TA11/TA12. [6]

1 to 10 RAND1 10
11 to 20 RS 10
Table 5.25: TA11/TA12 command data. [6]

1 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.
K S = (K + RS) truncate to 128 bits (5.1)

The TA12 algorithm takes KS and RAND1 as input and produces RES1 and
DCK1. The dummy algorithm for producing RES1 can be seen in (5.2) and the
dummy algorithm for DCK1 can be seen in (5.3).
RES1 = (K S + RAN D1) truncate to 32 bits (5.2)
DCK1 = (K S + RAN D1) 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 command
described 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 response
parameters can be seen in Table 5.28 and 5.29.

"A0" "42" "00" "00" "0E" Table 5.28 "04"
Table 5.27: The command APDU for TA21/TA22. [6]

1 to 4 RES2 4
5 to 14 RS 10
Table 5.28: TA21/TA22 command data. [6]

1 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.
K S 0 = (K + RS) truncate to 128 bits (5.4)

54 5 Design
The TA22 algorithm takes KS’ and RAND2 as input and produces XRES2 and
DCK2. The operation for producing XRES2 can be seen in (5.5) and the operation
for DCK2 can be seen in (5.6).
XRES2 = (K S 0 + RAN D2) truncate to 32 bits (5.5)
DCK2 = (K S 0 + RAN D2) 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 the
TA11/TA12 and TA21/TA22 algorithms. In addition, the TE algorithm can be
run if that service is enabled (indicated in EFSST ). The TE algorithm will not be
implemented in this solution and only a dummy algorithm will be used instead
of the TB4 algorithm. The input and the output are given below:
• Input from SIM: DCK1, DCK2 (KE if TE shall be used)
• Output to ME: DCK
If not a mutual authentication has been performed but, an unilateral authenti-
cation has been done either DCK1 or DCK2 is set to zero depending on which
algorithms that have been performed. [6]
The command APDU can be seen in Table 5.30 and the response can be seen in
Table 5.31.

"A0" "46" "00" "00" - - "0A"
Table 5.30: The command APDU for TB4/TE. [6]

1 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) is
performed.
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 immediately
after the command that produces the response. If this is not the case, the data
is 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 length
shall 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.

"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 in
Section 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 functions
and handles everything concerning the PIN verification.
The Interpreter package contains the main loop of the smart card and parses
the commands from the terminal. This package is updated to support all TSIM
related operations. This package also holds the file system on the card. So all files
described in Table 5.1 should be added here.
The OS package is used to communicate with the HAL, Security Layer and to
write and read from the EEPROM. The OS package is for example used by the
authentication function GET RANDOM (Section 5.2.1) to access the on chip RNG.
The Registry package contains the ATR.
6
Verification
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 stated
earlier, testing with a simulated terminal is the only way to verify that the system
works because it cannot yet be tested in a device connected to a real network.
Two di↵erent test methods are used for testing of functionality; unit testing (see
Section 6.2) and card acceptance tests with a real smart card connected to a PC,
simulating MEs from di↵erent manufacturers (see Section 6.3).
Unit testing is used to verify that the code works as expected before programming
the smart card. This makes it easier to debug the code, since once the code is
written to the smart card there is no way to step one line at a time. But the
unit tests cannot simulate the memory handling on the smart card. The MMU
behavior 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 is
given if the requirement has been tested and how. If the requirement has not
been tested, a reason is given to why.
Req.
Status Comment
no.
Already Fulfilled by the existing ATR in the smart card. Ver-
1 to 3
implemented ified by analyzing the code and the existing tests
57
58 6 Verification
Req.
Status Comment
no.
By analyzing the code, all files were verified to con-
sist of a header and a body when needed. Analysis
Code shows that all files has a unique file ID if they are
4 to 6
analysis placed under the same DF, the file ID consist of two
bytes, and are specified according to the rules given
in Section 3.3
Code Code analysis verifies that all DFs only consist of a
7
analysis header
Code analysis verifies that all EFs consist of both a
Code
8 header and a body. This is also verified by the tests
analysis
for each file type
Verified by testing the functions operating on the
9, 10
Tested files. The tests are described in Section 6.2.1 and
and 12
Section 6.3.1
Not The key EF is not implemented because no manda-
11
implemented tory file is of the key type
Files are verified that they can be selected. Not
enough tests are performed to verify that a file can-
13 Partly tested not be selected from the wrong location. Tests are
not performed to verify that a file cannot be selected
from all other DFs then the direct parent
Code
The file ID are verified by code analysis and the se-
14 analysis and
lection tests are described in Section 6.3.1
test
Code
15 to Verified by code analysis and by running the tests
analysis and
18 described in Section 6.2.2 and Section 6.3.2
tests
19 Tested Verified by the tests described in Section 6.3.2
Verified by checking which file types that exists, and
Analysis and then verifying that the corresponding functions are
20
tested available. The functions are verified in Section 6.2.1
and Section 6.3.1
This functionality already exists in the available
Already
21 smart card. The functionality is not explicitly tested
implemented
but the functions are used during other test cases
Verified by the tests described in Section 6.2.1 and
22 Tested
Section 6.3.1
Verified by the tests described in Section 6.2.2 and
23 Tested
Section 6.3.2
Not
24 The OTAR functionality is not implemented
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. The
unit under test shall be separated from the rest of the software, to be able to test
the functionality of that specific unit without the influence of other units. The
goal is to verify that each unit is correct before moving forward and integrating
them, 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. More
testing 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. The
test files were EFDNWRK and EFFORBID . EFDNWRK is a cyclic EF and EFFORBID is a
linear 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 di↵ers 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 last
record 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 cyclic
EF only allows the previous record to be updated.
For the cyclic EF, the READ and UPDATE are also tested to verify that only the
PREVIOUS 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 end
or start of the file. When searching in a cyclic EF the search should only end if
the 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), the
following test cases were used:
• Invalidate a file and try to access it
• Rehabilitate an invalidated file
To verify that the authentication algorithms work as intended the algorithms
were called upon and the result was compared to the expected results given for
each algorithm.
GET RANDOM (Section 5.2.1) is tested by calling the function and reading out
the result RAND2. The result is then tested by Algorithm 6.1. The algorithm
takes an array of bytes and views the data as a matrix, 8 bits wide and length
high, and verifies that each column contains at least one ’0’ and one ’1’.
bool DataLooksRandom ( b y t e _ a r r a y data , i n t e g e r l e n g t h )
byte mask1 = " 00 " ;

byte mask2 = " FF " ;
/ / Check t h e d a t a
f o r ( i = 0 ; i < l e n g t h ; i ++)
mask1 = mask1 | data [ i ] ;
mask2 = mask2 & data [ i ] ;
/ / Does t h e d a t a l o o k random ?
i f ( mask1 != " FF " ) && ( mask2 != " 00 " )
return f a l s e ;
else
return t r u e ;
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 that
the function works as expected. The result RES1 is returned from the command
and DCK1 is read from the internal storage.
6.2 Unit Test 61
Parameter Content
Input
RAND1 "11 22 33 44 55 66 77 88 99 AA"
RS "FF EE DD CC BB AA 99 88 77 66"
Output
RES1 "10 22 33 44"
DCK1 "10 22 33 44 55 66 77 88 99 AA"
Expected Output
RES1 "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 running
Algorithm 5.1 by hand.
TA21/TA22 (Section 5.2.3) is tested with the data given in Table 6.3 to verify that
the function works as expected. The result XRES2 is returned from the command
and DCK2 is read from the internal storage.
Parameter Content
Input
RES2 "10 22 33 44"
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 Output
XRES2 "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 running
TB4/TE (Section 5.2.4) is tested with the data given in Table 6.4 to verify that the
function works as expected. The result, DCK, is returned from the command.
62 6 Verification
Parameter Content
Input
DCK1 "11 22 33 44 55 66 77 88 99 AA"
DCK2 "FF EE DD CC BB AA 99 88 77 66"
Output
DCK "10 22 33 44 55 66 77 88 99 AA"
Expected Output
DCK "10 22 33 44 55 66 77 88 99 AA"
Table 6.4: TB4/TE test data, the expected output is generated by running
6.3 Card Acceptance Test

Card acceptance tests are performed to verify that the functions work on a real
smart 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 aimed
to test that the functions works as intended on a physical smart card instead of
debugging and verifying the code on a PC. The biggest di↵erence between the
unit tests and the card acceptance tests is that the unit tests cannot test how the
MMU limit the access to di↵erent 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 the
correct DF.
To test the READ and UPDATE functions, as well as the access conditions for
the files an access test is used. For the READ operation, this means that the file
is read but the content is not analyzed. For the UPDATE operation, this means
that dummy data is written to the file. For both UPDATE and READ, all files are
tested without any PIN, with user PIN and with admin PIN. The answer is then
analyzed 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.1
for the di↵erent access conditions for the files. This test does not verify that data
is not written in case of a wrong authentication, this is tested by the unit tests.
To test GET RANDOM, the function is called 1000 times and the values are com-
pared to see that no values are equal. This way the function is proved to give dif-
ferent values. However it is not a proof that the values are random, but enough
for this implementation.
The input used to test TA11/TA12 is described in Table 6.5. In addition to the
input 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 the

testbench. This allows the results to be compared.
Parameter Content
Test case 1
RAND1 "11 22 33 44 55 66 77 88 99 AA"
Test case 2
RAND1 "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 to
the input given in Table 6.6, random input is used as well. To compare the result
the same method as described above for TA11/TA12 is used. When testing the
TA21/TA22 function, GET RANDOM must first be executed to get RAND2.
Parameter Content
Test case 1
RES2 "00 00 00 00"
Test case 2
RES2 "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. Once
the language is selected, the ME performs a PIN verification where the user must
enter 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 and
Section 6.3.
6.4.2 Authentication Between SIM and the SwMI

When the SwMI requests a SIM authentication the ME reads EFSEC to determine
if a mutual authentication shall be performed or not. Then the ME runs the
TA11/TA12 algorithm. Once the algorithm is done the ME runs GET RESPONSE
to 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 GET
RANDOM 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.2
and Section 6.3.
Conclusions
7
This chapter presents the results and conclusions of the master thesis, and further
work on the subject.
7.1 Results
The TSIM standard from ETSI was analysed and a specification of requirements
was 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 during
the 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 placed
in a DF as described in the report. The reason is that the files need to be accessible
from 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 TSIM
application should be implemented to fulfill the requirements from ETSI and at
the same time work together with the existing E2EE application. The architecture
is given in Chapter 4 and the design in Chapter 5.
From the system design, the TSIM application was implemented and tested. The
implementation consisted of all files given in the design, as well as all functions
given in the design that did not exist already. The tests were done as described
in Chapter 6. Important to notice about the verifications was that the system
was not tested together with a real network and/or terminal. The system was
only tested through a computer that simulated the behaviour of a terminal. The
reason was, as mentioned, that the terminals existing today in Rakel does not
support 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 application
on a smart card. This solution is not limited to an E2EE application. It should
be possible to integrate any application together with a TSIM application and
get a smart card with dual functionality. However, the TSIM is not implemented
as 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 that
the TSIM files and functions needs to be accessed continuously while the E2EE
application is running.
A simplification that has been made is that the authentication algorithms for the
authentication with the SwMI are replaced by dummy algorithms. This simplifi-
cation has been done because the access to the real algorithms is limited by ETSI
and 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 have
been kept according to the standard. So if the system shall be used only the
algorithms 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 a
simulated environment, if it shall be tested in a live network this data must be
correct. 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 provider
are tightly coupled. When looking at the market today more and more users are
connected 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 whose
hand-held device has broken down, could immediately get a spare from the truck
and move his/her SIM instead of checking out a new hand-held device from the
administration.
In order to implement this in a complete product, one would need to insert data
in 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 functions
should 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 page
9.
[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, and
Reed 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. ISBN
978-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 on
pages 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.
Available at: <http://www.etsi.org/> [Accessed 3 April 2012]. Cited on
page 43.
Available at: <http://www.etsi.org/> [Accessed 7 February 2012]. Cited on
pages 24, 25, and 39.
67
68 Bibliography
Available at: <http://www.etsi.org/> [Accessed 7 February 2012]. Cited on
pages 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]. Cited
on 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: Company
Confidential. 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 16
2012. 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]. Cited
on 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ära
omstä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 vid
en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den 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 form
eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller
konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets
hemsida 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 barring
exceptional 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 use
it unchanged for any non-commercial research and educational purpose. Subse-
quent transfers of copyright cannot revoke this permission. All other uses of the
document are conditional on the consent of the copyright owner. The publisher
has taken technical and administrative measures to assure authenticity, security
and accessibility.
According to intellectual property law the author has the right to be mentioned
when his/her work is accessed as described above and to be protected against
infringement.
For additional information about the Linköping University Electronic Press and
its procedures for publication and for assurance of document integrity, please
refer to its www home page: http://www.ep.liu.se/
© Jonas Olofsson

Tetra E2E Smartcards Masterfile

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tetra E2E Smartcards Masterfile

Uploaded by

Copyright:

Available Formats

Institutionen för systemteknik

Department of Electrical Engineering

Design and Implementation of SIM Functionality for

Examensarbete utfört i Elektroteknik

Department of Electrical Engineering Linköpings tekniska högskola

Examensarbete utfört i Elektroteknik

Handledare: Jerry Falkcrona

Examinator: Ola Dahl

Linköping, 8 juni 2012

Division of Computer Engineering

Språk Rapporttyp ISBN

URL för elektronisk version

Titel Design och implementation av SIM-funktionalitet i ett smartcard för TETRA-systemet

Författare Jonas Olofsson

Linköping, June 2012

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

Sectra Communications AB, from here on referred to as Sectra, has developed

1.3 Document Outline

• Background: Gives background information about TETRA, smart cards

• Requirements: Describes and selects the requirements that must be ful-

• Architecture: Describes the system architecture.

• Design: Describes the design of the system.

• Verification: Describes the test cases used to verify the system.

MGCK Modified Group Cipher Key

TETRA Terrestrial Trunked Radio

2.1 TETRA – Terrestrial Trunked Radio

Example of services provided by the TETRA standard are: [2]

– Dynamic Group Number: Allows for dynamic creation of groups via

2.2 Smart Card

• Contact Smart Cards: A contact smart card requires a direct connection to

• Hybrid Smart Cards: A hybrid smart card contains two microcontrollers;

• Dual-Interface Smart Cards: A dual-interface smart card supports both

Figure 2.2: An illustration showing how the IC and contacts

2.2.1 SIM – Subscriber Identification Module

2.3 Sectra TETRA E2EE

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

Table 3.1: System requirement template.

3.1 SIM Characteristics

Figure 3.1: An example of the pin locations on a smart card. Note

3.2 Electronic Signals and Transmission Protocols

3.2.2 Baud Rate

3.2.3 ATR - Answer To Reset

Table 3.2: ATR requirements.

3.2.3.1 PPS Procedure

3.3 File System

Figure 3.2: File system overview. [6]

• "4F": EF under the second level DF

Table 3.3: File system requirements.

3.3.1 DF – Dedicated Files

Table 3.4: DF requirements.

3.3.2 EF – Elementary Files

Table 3.5: EF requirements.

The Transparent EF body consists of a sequence of bytes. When one or more

Figure 3.3: Structure of a transparent EF.

3.3.2.2 Linear Fixed EF

• Absolute by using the record number.

Figure 3.4: Structure of a linear fixed EF.

Figure 3.5: Structure of a key EF.

Figure 3.6: Structure of a cyclic EF.

3.3.3 File Selection

Figure 3.7: Example file structure.

Last Selected File Valid Selections

Table 3.7: File selection requirements.

3.3.4 File IDs