key architecture and updating protocols in large-scale card-based

Key Architecture and Updating Protocols in

Large-scale Card-based Access Control Systems

by

Zhuo Chen

Supervisors:

Boris Škorić (TU/e),

Albert Dercksen (Nedap),

Gerard Koskamp (Nedap)

Department of Mathematics and Computer Science

Computer Science - Information Security Technology

Eindhoven University of Technology

Eindhoven, August 2012

Key Architecture and Updating Protocols in Large-scale Card-based Access Control Systems

2

Abstract

Various large institutions use physical access control systems to limit the accessibility of resources.

With appropriate design, the system divides areas according to different security levels or

requirements. To acquire the protected resources without permission, the attacker has to attack the

access control system. Therefore, the system requires strong security mechanisms. Encryption

methods are used extensively in physical security systems. All critical data in transit and storage must

be protected.

The hardware in an access control system supports security functions, and the system is designed

based on these functions. Compromises in security levels must inevitably be made, due to practical

and cost related constraints. The most vulnerable hardware parts are the access cards held by users.

Thus, a key updating protocol has to be in place, which can be nontrivial to realize and maintain in a

large-scale system.

This thesis investigates access control based on Nedap's commercially available hardware. The

security properties of the hardware are analyzed and possible risks are evaluated. To mitigate the risks,

a key architecture and key updating framework is proposed that fit in the general structure of Nedap's

access control system. A hierarchy to update keys using java cards is designed and implemented on a

PC connected to Java cards.


3

Acknowledgement

This thesis marks the end of the exciting journey to achieve my master degree at Kerckhoffs

Institution at Eindhoven University of Technology. This work would not have been possible without

the help and support from a number of people.

I would like to express great appreciation to my supervisor, Boris Škorić providing helpful

suggestions during the whole project. Thanks for his time, patience and helpful suggestions.

Thanks a million to my tutors Albert Dercksen and Gerard Koskamp in Nedap. They help me a lot

not only in the project but also in the preparation of this master’s thesis. Without their help, I could

not have the chance to enjoy the great working environment in Nedap.

I am also very appreciative of my parents and all my friends around me, for their support and

encouragement in the whole process.


4

Contents

Abstract ................................................................................................................................................... 2

Acknowledgement .................................................................................................................................. 3

Glossary .................................................................................................................................................. 7

Chapter 1 Introduction ............................................................................................................................ 9

1.1 Nedap Card-based access control system ............................................................................... 9

1.2 Project goal ........................................................................................................................... 10

1.3 Thesis outline ........................................................................................................................ 11

Chapter 2 Background information....................................................................................................... 13

2.1 Cryptography concepts ......................................................................................................... 13

2.1.1 Symmetric encryption ................................................................................................... 13

2.1.2 Asymmetric encryption ................................................................................................. 13

2.1.3 Message Authentication Code (MAC) .......................................................................... 13

2.1.4 Digital signature ............................................................................................................ 14

2.1.5 Key diversification function .......................................................................................... 14

2.1.6 Public Key Certificates ................................................................................................. 14

2.2 Hardware ............................................................................................................................... 15

2.2.1 Access cards: MIFARE DESFire EV1 8K contactless chip ......................................... 15

2.2.2 SAMs: MIFARE SAM AV2 ......................................................................................... 17

2.2.3 Java cards: JCOP31 v2.4.1 ............................................................................................ 18

2.3 Protections provided by SAMs and DESFire EV1 ............................................................... 19

2.3.1 Hardware protection ...................................................................................................... 19

2.3.2 Random UID mode of DESFire .................................................................................... 19

2.3.3 Authentication protocol between a SAM and an access card ....................................... 19

2.3.4 Key classes in SAM ...................................................................................................... 21

2.3.5 Protection modes in SAMs ........................................................................................... 21

2.3.6 Mutual authentication between a controller and a SAM ............................................... 22

2.3.7 Master keys in access cards and SAMs......................................................................... 23

2.3.8 Key diversification ........................................................................................................ 24

2.3.9 Counters in SAM AV2 .................................................................................................. 25

2.3.10 Key version ................................................................................................................... 26

2.4 Usage scenarios ..................................................................................................................... 26

Chapter 3 Risk assessment .................................................................................................................... 28

3.1 Threat identification .............................................................................................................. 28


5

3.1.1 Attack purposes ............................................................................................................. 28

3.1.2 Attack sources ............................................................................................................... 28

3.1.3 Threat identification ...................................................................................................... 29

3.2 General risk and mitigation ................................................................................................... 29

3.3 Risk assessment summary ..................................................................................................... 34

Chapter 4 Initialization of the system ................................................................................................... 36

4.1 Key structure ......................................................................................................................... 36

4.1.1 Keys in cards to authenticate with a SAM .................................................................... 36

4.1.2 Symmetric keys in SAMs installed in controllers ......................................................... 37

4.1.3 Diversification master keys in the system ..................................................................... 38

4.1.4 The foreseen impact in case of key compromise .......................................................... 40

4.2 Initialization of SAMs ........................................................................................................... 41

4.3 Initialization of cards ............................................................................................................ 42

4.3.1 Pre-personalization of cards .......................................................................................... 43

4.3.2 Personalization of cards ................................................................................................ 43

4.4 DMKs in the zones ................................................................................................................ 43

4.4.1 Share a set of DMKs among zones ............................................................................... 44

4.4.2 Manage DMKs separately within each zone ................................................................. 44

4.4.3 Comparison ................................................................................................................... 45

4.5 Access control process .......................................................................................................... 46

Chapter 5 Key updating ........................................................................................................................ 48

5.1 Update PICC keys ................................................................................................................. 48

5.1.1 Prepare the new key in SAM first ................................................................................. 48

5.1.2 Store backup keys on cards ........................................................................................... 52

5.2 Update host keys ................................................................................................................... 53

5.2.1 Update host_key1 .......................................................................................................... 53

5.2.2 Update host_key2 .......................................................................................................... 54

5.3 Update PICC keys with an offline change key ..................................................................... 55

5.4 Update asymmetric keys ....................................................................................................... 55

5.5 Update symmetric keys with asymmetric ones ..................................................................... 56

Chapter 6 Java cards in the access control system ................................................................................ 57

6.1 Java cards hierarchy .............................................................................................................. 57

6.2 Example ................................................................................................................................ 58

6.3 Keys on the Java card............................................................................................................ 58

6.3.1 Unique RSA key pair for each card .............................................................................. 58


6

6.3.2 Share an RSA key pair in one level .............................................................................. 59

Chapter 7 Implementation ..................................................................................................................... 60

7.1 Tools ..................................................................................................................................... 60

7.2 Communication between a Java card and a SAM ................................................................. 60

7.3 An authentication protocol between two JCs ........................................................................ 62

7.4 Update the SAM with PKI keys through Java cards ............................................................. 63

7.5 Security evaluation ................................................................................................................ 64

7.5.1 Verification of the protocol ........................................................................................... 64

7.5.2 Random numbers in the protocol between two Java cards ........................................... 64

7.5.3 RSA algorithms ............................................................................................................. 65

7.5.4 The use of PKI keys in SAMs ....................................................................................... 66

7.5.5 New risks from Java cards ............................................................................................ 66

Chapter 8 Conclusion ............................................................................................................................ 67

8.1 Contribution .......................................................................................................................... 67

8.2 Future work ........................................................................................................................... 67

Bibliography ......................................................................................................................................... 69

Appendix A: command set .................................................................................................................... 71

A.1 Part of DESFire EV1 command set ........................................................................................... 71

A.2 Part of SAM AV2 command set ................................................................................................ 71

Appendix B: Proverif ............................................................................................................................ 74

B.1 Code ........................................................................................................................................... 74

B.2 Result .......................................................................................................................................... 75

Appendix C: Implementation details .................................................................................................... 77


7

Glossary

3DES Triple DES

AES Advanced Encryption Standard

AID Application Identifier

AK Application Key

AMK Application Master Key

API Application Programming Interface

CA Certification Authority

CAD Card Acceptance Device

CC Common Criteria, an international standard (ISO/IEC15408) for computer

security certification

CK Change Key

CMAC Cipher-based MAC

CMK Card Master Key

CSN Card Serial Number

CurVal Current Value of the key usage counter

Dec(k, A) Decryption of A with key k

DES Data Encryption Standard

DF_AID DESFire AID

DF_Key DESFire key number

DMK Diversification Master Key

EAL Evaluation Assurance Level

EEPROM Electrically Erasable Programmable Read-Only Memory

Enc(k, A) Encryption of A with key k

eID Employee identifier

ExtSET Extension configuration setting field

FID File Identifier

FK File Key

hash(A) the hash value of A

ISO International Organization for Standardization

JC Java Card

JCRE Java Card Running Environment

KeyNo Key Reference Number

KeyNoC Key Reference Number of Change Entry Key

KeyVerC Key Version of Change Entry Key

KeyNOCKUC Key Reference Number to change the current KUC Entry

KUC Key Usage Counter

KeyVerCKUC Key Version to change the current KUC Entry

LC Logical Channel

MAC Message Authentication Code

PICC Proximity Integrated Circuit Card

PCD Proximity Coupling Device

PKI Public Key Infrastructure

PKI_KST PKI Key Storage Table

PosA Position A

http://en.wikipedia.org/wiki/International_standard

http://en.wikipedia.org/wiki/International_Organization_for_Standardization

http://en.wikipedia.org/wiki/International_Electrotechnical_Commission

http://en.wikipedia.org/wiki/Computer_security

http://en.wikipedia.org/wiki/Computer_security

http://en.wikipedia.org/wiki/Data_Encryption_Standard


8

PosB Position B

PosC Position C

RefNoKUC Reference number of Key Usage Counter

RID Random Identifier

RndA Random number A

RndB Random number B

RndA’ Random number A rotated left over 1 byte

RndB’ Random number B rotated left over 1 byte

RF Radio Frequency

RSA The algorithm for public-key cryptography that is firstly publicly described by

Ron Rivest, Adi Shamir and Leonard Adleman

SAM Secure Application Module

SET Configuration Setting for KST Entry

Sig(A, k) Signature generation on a message A using key k

sKST Symmetric Key Storage Table

SW Status Word

UID User Identifier

Va Version of key a

Vb Version of key b

Vc Version of key c

Ver(h,s,k) Signature verification on a hash value h, a signature s and a key k

protected area The area within the protection of the access control system. Only with successful

authentication and authorization process can this area be accessed.

access card The badge used in the access control system to identify a user. In the project, the

access card is DESFire EV1.

host

authentication

Mutual authentication between the SAM and its host (e.g. the controller, updating

devices)

http://en.wikipedia.org/wiki/Algorithm

http://en.wikipedia.org/wiki/Public-key_cryptography

http://en.wikipedia.org/wiki/Ron_Rivest

http://en.wikipedia.org/wiki/Adi_Shamir

http://en.wikipedia.org/wiki/Leonard_Adleman


9

Chapter 1

Introduction

In any organization, especially large ones, it is common practice to restrict the accessibility of

sensitive resources. For instance, employees from one section may not be permitted to enter another

section in a company; only involved scientists can enter a research lab in a research institution. It is

not always acceptable that everybody can enter an area.

Traditionally, the door access control can be achieved by a human (such as a guard or a

receptionist), or through mechanical means like locks and keys. In addition to the safeguards, modern

automated access control systems play an important role to implement access policies. They can be

found in various places such as companies, governments, hospitals, universities, research institutions

and so on. A user must hold a special card to open the door.

Nedap Security Management develops and manufactures such access control systems. It can easily

be integrated with existing software and hardware systems of other suppliers.

1.1 Nedap Card-based access control system

The Nedap card-based access control system consists of access cards, transmitter/readers on doors,

controllers, SAMs and the connected backend system [1]. The function of each component and the

authentication procedure is introduced in this section.

Figure 1 An access control system

Access card: the credential for a person to enter a secured area. When a card is issued to a person

or company, it will be personalized with confidential information and individual keys. Mostly, the

access card used in an access control system is a contactless chip. The term proximity integrated

circuit card (PICC) is also used for the access card.

Transmitter/Reader: the first device to interact with cards. Firstly the antenna communicates with

the card in the field. Then the device will convert the data format. Usually the transmitter or the reader


10

is outside the door or outside of the protected area. Therefore, it is optimal that the reader does not

store any keys but only acts as a format transformer and data channel. Another term for the reader is

proximity coupling device (PCD) in this thesis.

Controller: the device that makes the decision to open the door or not. This device stores a local

database and also connects with the backend system. Controllers locate distributed in the system,

usually next to the door in the protected area rather than the backend system. In the system, the

number of controllers could be one or more, within communication capacity and processing power of

its own and the backend system. Each controller could manage one or more doors/readers.

Secure application module (SAM): This module provides secure storage of keys. This equipment

has dedicated cryptographic co-processor. Some SAMs are integrated into controllers. This

component can encrypt or decrypt messages with the key stored in it. It replies to the commands from

the controller. These SAMs are to deal with the sensitive data in the authentication. It is not economic

to install a new SAM to replace an old one frequently in an updating period. Some SAMs may be

used additionally in the setup. After the system is successfully installed, these SAMs are kept securely

in a special area together as a part of the backend system. Since SAMs store sensitive data about the

system, additional protections like hardware protection should be applied.

Backend system: the centralized area to store card information and management information. It is

also responsible for sending commands to controllers when necessary to control the system. An online

access system can communicate with the backend system. A general backend system can be provided

by a system integrator. The backend system stores much vital information about the system, such as

the current key number and version, valid SAMs and authorization information. Therefore, the

components that store this sensitive information should be located in the most secure place.

1.2 Project goal

The clients of the Nedap access control system include large companies and organizations. The

installed system may handle large numbers of badges, doors and events, spread across sites in

different locations. As a result, the system becomes complex and distributed.

An updating scheme for the keys in the large-scale systems is often demanded, able to withstand

unpredictable attacks. However, managing keys in a complicated system is inconvenient, time

consuming and potentially insecure. Generally, keys need to be updated manually by going physically

to the controllers.

Considering the latest product innovations and the market requirement, further research on the key

updating procedure in the Nedap access control system is needed. Therefore, a 6-month project was

proposed as the master final project.

This assignment consists of two main parts: system initialization and key management of the

system. To achieve the goal, the following tasks were identified:


11

Study the new features of the components.

Perform risk assessment on the current system.

Keys may participate in various communications. For instance, some keys may be used in the

authentication between a card and a SAM; some keys may be activated only in updating;

some keys may be used to build a secure channel between two components. The third task in

the thesis is to initialize the access cards and SAMs according to the different usage of keys

and use cases. The key management will be considered and implemented based on this

initialization scheme.

Recommend the process to update different types of keys in the system.

To update the key easily in the large system, design a tree structure with a master SAM

(which is actually a Java card) at the root, and multiple nodes, which are also Java cards.

Implement the communication between a Java card and a SAM, and communication between

Java cards.

The routing and addressing of the system will be taken care of by the devices to which Java cards

and SAMs are attached. The anticollision algorithm and process between a reader and cards are

managed by these access control devices. Therefore, the routing and anticollision algorithms are not

discussed in this thesis.

1.3 Thesis outline

The rest of this thesis is organized as follows:

Chapter 2 introduces the background information. The information about the hardware is

introduced at the start. Secondly, we briefly explain the associated cryptography concepts. The

features of the hardware are also described in this chapter. In the end, the usage scenarios are

described.

Chapter 3 contains the risk assessment of the access control system. The general threat,

vulnerability and typical attack types are identified in this section.

Chapter 4 explains the initialization of the system. How to activate the system will be explained

here, and more importantly, the key structure will be illustrated in this part. After this step, the system

is ready for use.

Chapter 5 describes the process to update keys both in the SAM and the corresponding access cards

with the help of the controller and the backend system. The command sequences are demonstrated.

Chapter 6 is for the Java card hierarchy, which is used to update the SAM described in the previous

sections. To make it practical, we consider the key structure in the Java cards based on the system

described in Chapter 4 and discuss its initialization.

Chapter 7 implements the idea of updating a key in the SAM with the Java cards. The updating

process on a SAM with a Java card is implemented following the product specification. The new


12

authentication protocol between the Java cards is designed and implemented. At last, the risk of

adding these new devices will also be discussed in this chapter.

Finally, the conclusion and future work will be given in the last chapter.


13

Chapter 2

Background information

In this chapter, we first describe key concepts of cryptography related to the thesis and then introduce

the information about the products used in this project, including the version of SAMs, access cards

and Java cards. After that, usage scenarios are described.

2.1 Cryptography concepts

Most data in the communication channel are encrypted. Mutual authentication is required before any

sensitive data are processed or transferred. The related cryptography concepts in these processes are

briefly explained here.

2.1.1 Symmetric encryption

Symmetric encryption is one form of cryptosystem in which encryption and decryption are done with

the same key. This key is stored by both the sender and the recipient securely. Together with an

encryption algorithm, the original message, or the plaintext, is transformed into the encrypted form

with this key, also known as ciphertext. Using the same key and a decryption algorithm, the plaintext

can be recovered from the ciphertext with no loss of information. The key is independent of the

plaintext and the algorithm. The algorithm outputs differently depending on the keys being used at the

time.

Popular and well-respected symmetric algorithms include DES, 3DES, AES, and so on. In this

project, AES-128 is the main symmetric encryption algorithm.

2.1.2 Asymmetric encryption

An asymmetric encryption algorithm uses a pair of keys to encrypt the plaintext and decrypt the

ciphertext. In the encryption, a key, which is called the public key, is used to generate the encrypted

form of the message using the encryption algorithm. This public key is known by the others. Thus, the

sender can generate the ciphertext with it. When receiving a ciphertext, the receiver uses the other key

in the key pair. This key is called the private key, and it should be protected by the receiver itself.

Only the receiver knows the private key. Therefore, others cannot retrieve the plaintext without the

private key.

In the project, we focus on RSA-2048 algorithm.

2.1.3 Message Authentication Code (MAC)

A message authentication code (MAC) is aimed at authenticating a message. Sometimes it is called

a keyed (cryptographic) hash function. It accepts a key as input and an arbitrary-length message to be


14

authenticated. The output is a MAC. The MAC value protects both a message's data integrity as well

as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the

message content.

As the symmetric encryption, the sender and receiver of a message must agree on the same key

before initiating communications. The MAC value is generated and verified by this symmetric key. It

can be constructed from other cryptographic primitives, such as cryptographic hash functions (e.g.

HMAC) or from block cipher algorithms (e.g. CBC-MAC). In the product that we applied in the

system, the MAC algorithm is based on AES-CBC-MAC, and then an 8-byte truncated value is output

as the MAC.

2.1.4 Digital signature

The digital signature is the mechanism to protect both integrity and authenticity. A key pair is

necessary to generate a signature.

The signature is the output of a signature algorithm that usually takes the hash value of the message

and a private key as the input. It is verifiable by the corresponding public key, guarantees only that the

private key belonging to that public key has been used to generate the signature. If the private key is

not compromised, the appropriate signature can only be generated by the one who has the private key.

It protects the messages from being manipulated. The attacker cannot pretend to be a legal party

without the knowledge of the private key.

2.1.5 Key diversification function

The key diversification function can derive one or more secret keys from secret information such as a

master key or a password using a pseudorandom function. Keyed cryptographic hash functions are

typical key diversification functions.

In an access control system which consists of a large number of access cards, key diversification is

an efficient method to have unique keys per chip/card or device while reducing the burden of

maintaining or storing a large amount of fixed secret keys. A master key, or the DMK, is used as the

critical input in a diversification process. Other input includes the input data and the padding flag.

2.1.6 Public Key Certificates

Public keys are not confidential. An eavesdropper may intercept in communication and inject another

public key. It is necessary to establish a binding between a public key and an entity. Otherwise, the

authenticity of the public key is doubtful. A certificate consists of a public key and the digital identity,

which are bound by a digital signature of a person or an organization that is able to guarantee the

binding. This person or organization is called a trusted third party (TTP).

http://en.wikipedia.org/wiki/Data_integrity

http://en.wikipedia.org/wiki/Key_(cryptography)

http://en.wikipedia.org/wiki/Password

http://en.wikipedia.org/wiki/Pseudo-random_function

http://en.wikipedia.org/wiki/Cryptographic_hash_function


15

After a certificate is issued, it should be able to be revoked after events that result in key

compromise, identity change or termination of membership, and so on. In these cases, the validation

of the certificate should be terminated before the certificate expires.

Several implementations are possible to revoke a certificate. For instance, a certificate revocation

list may be managed by a third party. In the list, the serial numbers of certificates that have been

revoked would be recorded. This list would be published regularly.

2.2 Hardware

2.2.1 Access cards: MIFARE DESFire EV1 8K contactless chip

As described in the previous chapter, an access card is the credential issued to a user. It stores the

personalized information to determine the card and the user. To get authorization, the personal

information is used. The card should be protected from being easily copied, modified, or faked.

Therefore, the information on the card should be stored securely, which makes the card one of the

critical components of the system.

The MIFARE contactless smartcard is one of the popular choices. The products from NXP include

MIFARE Classic, MIFARE Plus, MIFARE DESFire, and so on. A large number of companies and

institutions have chosen these products to establish their access control systems. Cards that are

compliant with ISO14443A [2] may be used in the Nedap system. The latest version among the

products is DESFire EV1 8K [3]. It provides sufficient protection at a moderate cost. Therefore, we

analyze the system and design protocols in the following chapters based on this product. This chip

supports a substantial number of the ISO 7816-4 commands [4] and a specific command set called

MIFARE DESFire EV1 (NXP) command set (Appendix A.1). In the research and implementation,

these commands will be the basis. It only supports symmetric cryptographic algorithm, including

DES/2K3DES/3K3DES/AES [5, 6]. Among these algorithms, AES provides the highest security. The

asymmetric cryptographic algorithm is not supported on this card. Cards that support RSA

cryptography are more expensive than DESFire EV1. With a large number of access credentials in the

system, it may be not preferable in most cases to choose expensive cards.

In a DESFire card, the 8K non-volatile memory is organized using a flexible file system. Keys,

applications and files can be created. Data is stored in files in the applications.

Each application is identified with a 3-byte identifier, which is called the application identifier

(AID). Within an application, several files can be created to store different data after proper

authentication. How to access these files is controlled by the keys defined in the application when the

application is created.

An example of the card layout is demonstrated in Figure 1.

Initially, the card contains only one application with AID 0x000000. This application is selected as

default when there is no other application defined and selected. With the proper authentication with


16

the card master key (CMK) stored in this application, the user of the system can update the card. New

applications can be created.

When an application is created, the AID will be defined. The number of the keys in this application

is fixed together with the creation of the application is. These keys will be numbered from 0, and no

keys can be added or deleted after the creation. These keys are called the application keys (AK),

which means they are defined in an application. Among the AKs, one key can be granted to change

the other AKs except the application master key (AMK). This key is called the change key (CK). It

can be the AMK or an average AK. It is used to change the value of other AKs.

After the application is created, with the authentication with the AMK, files can be created or

deleted in it. The MIFARE DESFire EV1 chip offers the possibility to define and use various file

types with diverse characteristics and some for specialized needs. Available file types include:

standard data files, backup data files, value files with backup linear record files with backup and

cyclic record files with backup. In the access control system, standard data files are sufficient to store

the data in the communication. We will focus on this kind of files. Other file types may be involved in

other applications such as micro payment system. When a file is created, the 2-byte file identifier

(FID) will be defined by the creator. Simultaneously, the valid application keys and their functions in

this file are decided. The number of application keys is not necessarily the same as that of file keys. In

an application, there may be a set of AKs while not every key is used in one file. Generally, a file has

Card Level

AID=0x000000

CMK(AK0)

Application 1

AMK(AK0)

Application 2 Application 3

AK2 AK3 AK4 AK5

…

File 1

R W RW

File 2

R W RW

AMK(AK0) AMK(AK0)

C C

FK(change) FK(read) FK(write) FK(r/w)

AK1

Figure 2 Structure of the contents in a card


17

four classes of FKs: key for read access right, key for write access right, key for read/write access

right and key for change access right. The change access in the file level means: with the

authentication of this key the user can change the key settings in the file but not the key value. To

change the key value, the change key in the application level is required. Only one key can be added

into each class, for instance, only one key can be defined as the read key; but one key may belong to

different classes, for instance, a key can be designated as the write key and the read/write key.

The number of the applications in one card, and the number of the keys and files in each application

is restricted by the card’s ability. For a MIFARE DESFire EV1 chip, 28 applications can be created in

one card, with maximally 32 files in each application and 14 keys.

2.2.2 SAMs: MIFARE SAM AV2

Another element that stores critical information for the authentication process is the SAM. MIFARE

SAM AV2 is the latest product from NXP. It is an ideal solution for the system. It offers secure

storage and transmission in a variety of infrastructures. This device is designed based on latest

asynchronous microcontroller design. It has a dedicated hardware cryptographic co-processor and fast

ISO 7816 contact interface. Similarly as the DESFire card, each SAM has a unique serial number. To

be compliant with pervious contactless cards, it supports DES/3DES cryptography. As the chip that

we choose, DESFire EV1, is capable of doing AES-128 algorithm, and SAM AV2 also supports AES-

128, we will choose AES as the symmetric encryption algorithm in the system instead of 3DES and

DES. Furthermore, SAM AV2 also supports RSA cryptography. It can sign and decrypt the data with

RSA keys.

SAM AV2 stores the key information and the related information in tables. The symmetric keys are

stored in a symmetric key storage table (sKST), and the asymmetric keys are stored in an asymmetric

key storage table. The sKST has 128 entries. Each entry can store up to three 16-byte AES keys. The

three AES-128 keys share the same key entry number and related key information stored in this entry,

but they are differentiated from their unique key version. In other words, one key in the table is

identified by the key entry number and the key version.

Besides three keys and their key versions in each entry, the storage and configuration options are

stored in this entry. These bytes indicate the class, type and permitted operations of the keys in this

entry. It also indicates whether this entry is enabled or not. For example, one key entry can be set to a

currently valid AES-128 key, used as a host key, and some commands such as the

SAM_DumpSessionKey cannot use this key as the parameter. Other critical information given by the

entry is how to change this key entry. To change this entry, authenticating with a host key or an

offline change key is required. The number of the change key and its version can be read from the

entry. More fields are optional in this entry. They may indicate which application and which key in

the access cards this entry is associated with, or how this entry connects to the key usage counter


18

(KUC) table, and so on In the asymmetric key storage table (PKI_KST), two pairs of RSA keys and

one additional public key can be stored at most.

SAMs only communicate with other devices passively, which means a SAM cannot initialize a

communication. The controller, or the host, sends commands to the SAM. The SAM replies to the

command. A part of the SAM AV2 command set is provided in Appendix A.2.

2.2.3 Java cards: JCOP31 v2.4.1

In Chapter 6 and 7, to update SAMs effectively, a Java card (JC) architecture will be introduced into

the access control system.

JC is a smartcard that is capable of running Java-based applets. Its main design purposes are

portability and security, which makes it an excellent choice among various options to execute the

updating.

JC defines a Java Card Runtime Environment (JCRE). The JCRE and APIs are modeled after the

smart card specification ISO 7816 (4). The system architecture of the JC is illustrated in Figure 3.

When a JC is inserted into a card acceptance device (CAD), the CAD selects an applet on the card

based on the application identifier. On a card, several applets can be stored. They are independent

entities on the card. The selection, execution, and functionality of each applet is not affected by the

operations in other applets residing on the same card. After successful selection, the CAD sends the

card a series of commands to execute.

Commands such as the selection command are formatted and transmitted in the form of application

protocol data units (APDUs). The JC communicates with the terminal application using these APDUs.

Each communication result in a pair of APDUs: the command APDU (C-APDU) and the response

APDU (R-APDU). A C-APDU is composed of a mandatory header and an optional body. The header

includes class of instruction (CLA), instruction code (INS) and instruction parameters (P1, P2). In the

optional body, a sequence of bytes can be sent. The card receives the C-APDU according to the CLA

and operates based on INS and the instruction parameters. In the applets, the card replies the C-APDU

with an R-APDU, which consists of status words (SW) that indicate the result of the operation,

optionally with other data.

Figure 3 Java card system (7)


19

Not all the language features defined in the Java Language Specification are supported on all the

JCs due to limited memory resources and computing power. For example, the Java card does not

support threads and synchronization and large primitive data types, including float, double, long, and

char. These should be considered in the implementation.

In this project, the JC is JCOP31, v2.4.1, a product from NXP Semiconductor. This card supports

Java Card 2.2.2 and Global Platform 2.1.1. Hardware security certification in accordance with CC

EAL 5+ is attained. It has 80Kbyte EEPROM, designed with multiple interfaces including ISO 7816

and ISO 14443. The product supports RSA up to 2048 bit and AES up to 256 bit that is sufficient in

the access control system which applies RSA-2048 and AES-128.

2.3 Protections provided by SAMs and DESFire EV1

In this section, we illustrate part of the protection mechanisms provided by SAM AV2 and DESFire

EV1.

2.3.1 Hardware protection

The DESFire card uses glue logic to protect it from physical attack [8]. Instead of placing the blocks

on the chip in separate sections, the blocks are mixed up. An attacker is no longer able to identify the

functional building blocks by analyzing the hardware easily. The product acquires CC EAL 4+.

MIFARE SAM AV2 is the hardware solution for securely storing the keys. As claimed by the

product manufacturer, we assume that attacking this device is more difficult than attacking cards,

controllers and readers.

2.3.2 Random UID mode of DESFire

It is common that several cards may be in the field of a reader at the same time. Thus, an anticollision

process is indispensable for a reader to identify a card. During the procedure, a card has to provide its

user identifier (UID). Since this is the first step in the whole communication, the UID number cannot

get any protection. It is public and sent in plaintext. Attackers can easily get this information through

eavesdropping. If the UID of this process is unique and is fixed to a card, a privacy problem arises:

the card can be easily traced.

To protect the privacy of the card holder, DESFire EV1 supports a configuration using 4-byte

random identifiers (RIDs) in the anticollision procedure. The real unique, 7-byte UID is protected in

this configuration. Only with proper authentication can the real UID read from the card storage.

2.3.3 Authentication protocol between a SAM and an access card

This authentication protocol is applied between a SAM and a card. The card proves that it is not faked,

and the SAM proves that it knows the correct authentication key. After the initial command, a three-

pass mutual authentication protocol based on two random numbers is used in the protocol (Figure 4).


20

As a result, the session key is generated from two random numbers and the required cryptographic

algorithm. The crypto algorithm uses the session key instead of the authentication key in the rest of

the communication. Therefore, the ciphertext is different each time.

We illustrate the authentication steps between a PICC and a SAM below:

1) Send the key information to SAM.

i. When a card is present in the radio frequency (RF) field, the reader communicates

with it and gets the RID for the anticollision process and the AID.

ii. If the card can be processed by the reader, a specific command (GetKeyVersion) is

sent to PICC to extract the key version. The list of the commands for the products is

in Appendix A.

iii. The response is sent to the SAM through the reader.

2) Choose the key to authenticate a PICC.

The command used in this step in SAMs is SAM_SelectApplication. With this command,

SAM AV2 generates a list of available keys according to the AID. With the list, the SAM can

decode the key number used in the authentication. Together with the key version acquired in

the first step, SAM sends the authentication command to the card with the key number and

version as the parameter.

3) The card generates Enc(key, RndB)

Once receives information about the authentication key, the card can decide which key should

be used in the authentication process. A random number (RndB) is generated. For AES

algorithm, the random number is 16-byte-long. After the message is encrypted with the

required key, it is sent to SAM.

4) The SAM generates Enc(RndA||RndB’)

When the SAM received the encrypted RndB, it decrypts the message with the authentication

key. If this key is the same as the one used by the card, the SAM gets the correct RndB. Then

RndB is left rotating by 1 byte. The result is RndB’. Another 16-byte random number RndA

is generated by SAM. RndA and RndB’ are then concatenated and encrypted with the

authentication key. The ciphertext is sent to the card through the reader.

5) Verify RndB’

The card decrypts the message from the SAM. Only with the correct RndB’ can the process

continue. In this way, an attacker cannot pretend to be a legal SAM without the correct

authentication key. Then the card left rotates RndA by 1 byte to get RndA’ and encrypts it.

An attacker cannot continue the authentication without the key since RndA’ cannot be

encrypted.

6) Verify RndA’


21

The last step in the authentication communication is to verify RndA’ in the SAM. If the

decrypted RndA’ is not correct, the authentication fails.

7) Generate the session key.

When all the steps above succeed, the SAM and the card generate session keys based on

RndA and RndB.

2.3.4 Key classes in SAM

SAM AV2 divides symmetric keys into different groups according to their function. There are four

classes: host key, PICC key, offline crypto key and offline change key. The usage of the key entry is

restricted by its class. For example, the host key can only be used in the host authentication; a PICC

key can only be used in the authentication with cards.

2.3.5 Protection modes in SAMs

Much information is transferred between a controller and the SAM integrated on it in the access

control process. It is necessary for them to make an agreement on protecting the exchanged data. The

information about this is defined as the protection mode. During the authentication between the

1)ii. GetKeyVersion

Figure 4 3-pass Mutual Authentication Protocol

KEY k

3-pass mutual

authentication

begins

1)i. RID, AID

SAM PICC PCD

2) Authentication command with key number

KEY k

GENERATE RndB ∈ {0,1}128;

e1 = Enck(RndB) e1

RndB’ =

LeftRotate (Deck(e1),1); GENERATE RndA ∈ {0,1}128; e2 =

Enck(RndA||RndB’)

e2

VERIFY RndB’: RndA’||RndB’’ =

Deck (e2); RndB’’ == LeftRotate(RndB,1)? RndA’‘= LeftRotate(RndA’,1);

e3 = Enck (RndA’’)

e3 RndA’’’ = Deck (e3); RndA’’’ == LeftRotate(RndA,1)?

Assemble Session Keys

1)iii. key version

Assemble Session Keys

3)

4)

5)

6)

7) 7)

AID


22

controller and the SAM (see 2.3.6), the authorized controller tells the SAM the protection mode used

after the mutual authentication.

SAM AV2 provides three protection modes: plain, MAC protection and full protection. In plain

mode, data sent in the communication after the mutual authentication between the SAM and the host

are sent without any protection. This mode is useful when testing the system, but in the real cases, it is

not secure. MAC protection protects the data from being modified in the transmission. A MAC is

added to both the command and its response. The MAC algorithm used in SAM AV2 is AES-CMAC.

The 16-byte output of the standard algorithm is truncated into 8 bytes. In full protection mode, data

are encrypted and then MAC is calculated. The encryption algorithm is decided by the configuration

of the key. As we choose AES-128 in the system, data are encrypted with AES algorithm. This is the

most secure mode the SAM provides. In most cases, this protection mode should be chosen.

2.3.6 Mutual authentication between a controller and a SAM

Another unique security mechanism provided by SAM AV2 is the mutual authentication between a

controller and a SAM with a host key. After a SAM is connected with a controller, this authentication

begins to ensure the authenticity of the two components. As a result, session keys will be generated to

build a secure channel between them on both sides.

The authentication process is similar to Figure 4 but more complex than that protocol. Instead of

one pair of random numbers in Figure 4, this process uses two pairs of random numbers, namely Rnd1

and Rnd2, RndA and RndB. MAC value is added to the first two random numbers while they are sent

in plaintext. The input of the MAC calculation is the concatenation of the random number, the

protection mode and a zero array. After the exchange, another AES key, kxe, is generated from Rnd1

and Rnd2. This key is the outcome of encrypting a specific byte array composed of parts of Rnd1,

Rnd2 and a fixed padding with the authentication key. The other pair of random numbers is protected

by kxe. The protocol is depicted in Figure 5.

Since the authentication between the controller and the SAM does not happen so frequently as the

one between the SAM and a card, and there is less restriction on the speed of the feedback, it is

reasonable to use two pairs of random numbers in the process to improve the security. The most

crucial consideration to add Rnd1 and Rnd2 before the other pair is to ensure the integrity of

information about the protection mode. This protocol protects the information about the protection

mode from the unauthorized modification. If the attacker changes the protection mode sent to SAM in

the first step, the verification of the MAC value of Rnd2 will fail. Instead, if this step is omitted, or

Rnd1 and Rnd2 are not used, the attacker can easily change the requested protection mode in the first

message from the host to the SAM without being detected. Consequently, after the successful host

authentication, the host and the SAM cannot communicate with each other since they use different

protection modes. More dangerously, if the attacker changes the protection mode to the plain mode,


23

he can then send a request to SAM without the host authentication now because the session keys are

not used after the host authentication in the plain.

2.3.7 Master keys in access cards and SAMs

Different master keys are defined by the card the SAM to facilitate and protect the operation of these

components. In the DESFire card, the master keys include the card master key and the application

master key; SAM AV2 also has a master key.

In the default application, 0x000000, only one key is stored. This key is called the card master key

(CMK). Authenticating with this key, one would get the highest privilege to manage this card. Any

SAM Host

KEY k KEY k Authentication command with key

number, key version, protection mode

GENERATE Rnd2 ∈ {0,1}96

Rnd2 mac2’ = AES-CMACk

(Rnd2||protection mode||0x000000) ∈ {0,1}64 GENERATE Rnd1 ∈ {0,1}96

mac2’||Rnd1

mac2 = AES-CMACk

(Rnd2||protection mode||0x000000) mac2’ == mac2? mac1’ = AES-CMACk

(Rnd1||protection mode||0x000000) ∈ {0,1}64

kxe = AES-CMACk(Rnd1, Rnd2) ∈ {0,1}128

GENERATE RndB ∈ {0,1}128 e1 = Enckxe(RndB)

mac1’||e1

mac1 = AES-CMACk

(Rnd1||protection mode||0x000000) mac1’ == mac1?

kxe = AES-CMACk(Rnd1, Rnd2) ∈ {0,1}128

RndB’’= LeftRotate(Deckxe(e1),2) GENERATE RndA ∈ {0,1}128 e2 = Enckxe(RndA||RndB’’)

e2 RndA’||RndB’ = Deckxe(e2) RndB’ == LeftRotate(RndB,2)? RndA’’ = LeftRotate(RndA’, 2) e3 = Enckxe(RndA’’)

e3

GENERATE session keys from RndA and RndB

GENERATE session keys from RndA and RndB

RndA’’’ = Deckxe (e3); RndA’’’ == LeftRotate(RndA,2)?

Figure 5 Mutual authentication protocol between a controller and a SAM

RndA’’’ = Deckxe(e3) RndA’’’ == LeftRotate(RndA,2)?


24

operation is permitted with this key, including adding or deleting any application except the

application 0x000000, or even formatting the card. Nothing else can be added in this application.

With the CMK, new applications can be added. The first key with the key number 0 in each

application is defined as the application master key (AMK). Authentication with an AMK permits one

doing any operation within the application, including adding or deleting files.

Similarly, in the sKST, the key entry 0 is the SAM master key. It must be a host key and can be

used to initialize the SAM.

2.3.8 Key diversification

SAM AV2 supports key diversification function [9]. For an AES-128 key, the diversification

algorithm is AES128-CMAC. It is based on the AES-128 algorithm.

As explained in the referenced document, the diversification algorithm is:

Input:

- M: 1 to 31 bytes of diversification input;

- K: 16 bytes AES master key.

Output:

- 16 bytes AES diversified key.

Algorithm:

i. Calculate CMAC input D = 0x01 || M || Padding. Padding is chosen such that D always

has a length of 32 byes. These bytes are according to the CMAC padding, i.e. 80h followed

by 00h bytes. So the length of Padding is 0 to 30 bytes.

ii. Calculate the Boolean flag ‘Padded’, which is true if M is less than 31 bytes long, false

otherwise.

iii. Calculate output: Diversified key = AES128-CMAC(K, D, Padded).

Figure 6 Block diagram of the diversification algorithm

M

Diversification input

(1-31 bytes)

Diversification input

(1-31 bytes)

Constant

0x01 i. Padding

iii. AES128-CMAC DMK: AES-128 key

(16 bytes)

DMK

D

32 bytes

ii. Padded ∈

{0,1}

Diversified AES-128 key

(16 bytes)


25

The input data of the diversification could be the concatenation of the UID of the card, the key

number, the application number, some random numbers pre-stored in the card or their combination.

This input will be decided in the following chapters.

Ideally, the diversified result should be unique for each card.

2.3.9 Counters in SAM AV2

In SAM AV2, besides sKST and PKI_KST, a 16-entry table is defined to count the times of the usage

of the keys. In the sKST, a key can be associated with an entry in the KUC table. With this setting, the

counter increases when the key is used. The counter has an upper limit. When the counter reaches the

upper limit, the key cannot be used any more.

This feature is optional. A key can also be associated with none of KUC entries by setting the

association field to 0xFF. The upper limit of a counter from the KUC table is meaningful to improve

the security sometimes. For example, if the SAM and the controller are stolen, the SAM will stop

working after the counter reaches the limitation. However, practically, this key usage counter is not

used. The main problem is the difficulty to manage and control the KUC table. While it prevents

unlimited usage of devices, new problems are exposed with the use of this counter. How to update the

counter, how to decide the period of management and how to protect it from attacks are complex in a

complicated system. For example, in an authentication process between a SAM and a card, the key

may be required to ensure the presence of a valid card from time to time; otherwise the valid card may

be replaced by another empty card. Thus, it is easy to attack the system if the counter is used in the

authentication process and difficult to manage. Usually, this table is not used.

Another counter in the SAM is the command counter. It is a four-byte counter which is used to

prevent the replay attack in the communication between the SAM and its host. This counter is reset to

0 after each successful authentication between the controller and the SAM. After the resetting, the

counter will increase when a data exchange happens with the protection of the generated session keys.

Both the controller and the SAM store the counters. When the SAM receives the command from the

controller, it will check the command counter value from the command (ctr_controller). If this value

is bigger than the value in the SAM (ctr_SAM), it will process the command and then increase the

counter: ctr_SAM = ctr_controller + 1. Otherwise, this command will be regarded as an expired one.

This counter in the command is protected by MAC at the end of the command. Though the value is

public in the message, it is difficult to change it. Therefore, the integrity is ensured.

Finally, to use the offline keys and RSA keys, including the offline change key and the offline

crypto key, another counter named the change counter (change_ctr) is used against replay attack. It is

sent together with the specific command as a part of the input of MAC calculation. Similarly, if the

value in the command is smaller than the value stored in the SAM, SAM will not accept this

command. This also requires the SAM and the host stores simultaneously the value of the counter.

Different from the command counter, this counter will not be reset. It is not managed inside the


26

component automatically. The counter will be updated when the value contained in the message is

greater than the current one. When the controller needs to activate the offline keys, it has to know the

value of this counter to send an equal or bigger one. However, the value cannot be acquired through

current functions of the product.

2.3.10 Key version

Besides the key number and its value, another byte is stored together. This byte is regarded as the

current version of the key. In DESFire, each AES key is stored as a version. This byte is sent when the

key is updated. In the SAM, each key entry in the sKST can store at most three AES-128 keys,

namely key at position A (PosA), position B (PosB) and position C (PosC). To identify the three keys,

different versions, Va, Vb, and Vc, are defined in the fields that point to each key. Specifically,

version A (Va) points to the key at PosA; version B (Vb) points to the key at PosB; and version C (Vc)

points to the key at PosC. In the commands to a SAM, the parameters indicate which key entry and

key version should be used in the following operations. Then the SAM looks up in the entry from Va

to Vc. For example, a command indicating that the key entry 2, version 0x01 is involved in the next

step. Then the SAM queries the sKST if a version 0x01 is available in the entry. If there is no key in

this entry with a version 0x01, the SAM returns an error; if there is a key with a version 0x01, the

SAM will use it as the symmetric key in the next cryptography protocol or algorithm; if there are two

keys or more with the same version, the former result will be returned.

In a successful authentication between the SAM and the access card, two components use the same

key to accomplish the communication. To ease the key management, this implies that the key version

should be the same.

In practice, the key version is useful in the updating process to differentiate the old keys and the

new keys. With this function, it is also feasible to use two keys in the system at the same time.

2.4 Usage scenarios

The access control system may be installed in various environments and integrated with other

applications, such as secure printing and micropayment system. The system should not influence the

development of other applications.

In a large-scale system, devices may be organized in different ways. For example, in a company,

there may be several buildings in a district, and each building has tens of doors in it. Another

international company may have branches around the world, while the top company manages the

access control system of a part of these branches since the limitation on these sub-companies. The

way to construct the system influences the maintenance of the system and more importantly, the key

structure in the system. Considering different cases, in this section, we discuss the division of security

zones as the basis for the key structural design.


27

The large-scale system can be constructed by several zones. The relation among different zones

may be decided according to specific requirements on human resources, technology and security

requirement. We identify three typical structures in an access control system according to different

security requirement: the hierarchical system (Figure 7 (a)), the parallel system (Figure 7(b)) and the

combined system (Figure 7 (c)).

In a hierarchical system, the security level of each zone is different. In this figure, the resources

within zone 3 has more strict restrictions than those in zone 2 and zone 1, and resources within zone 2

have more strict restrictions than those in zone 1. A person may have the authority to enter only zone

1, or to enter zone 1 and 2, or all the zones. To enter a zone with higher security levels requires higher

privilege. This structure is easy to find in the real life. For instance, a company A installs the access

control system to control the doors in a building. All the employees of this company are permitted to

enter this building. However, not all the rooms are accessible to everyone. The fifth floor may be only

open to the managers, and some rooms on that floor can be only opened by a small group of people.

In this case, the doors that control the accessibility of the building are in zone 1, which the lowest

security level; the doors that protect the fifth floor are in zone 2, and the doors outside the specific

rooms are in zone 3.

The second type is the parallel system, which means these zones have the same security levels, but

should be accessed by different groups. For example, in a district, there are several buildings owned

by an organization B. In each building, there are labs for different research groups. Only the

researchers working on project P can open the doors of building P; only the persons working on

project Q can open the doors of building Q, and so on.

The last structure is the combination of the hierarchical system and the parallel system. It is more

common than the other two in the real life. For the company A and the organization B mentioned in

the previous examples, it is possible to add the other system. For company A, it has two departments:

M and N. People from the department M can only access the left part of the building under the fifth

floor, while people from the department N can only open the door for the right part. Thus, there is a

parallel system within zone 1. For organization B, the leader of the organization may have the

authority to enter all the buildings in the district. In addition, he may have another office that only

owned by himself. In this organization, building P is the zone 1, building Q is the zone 2, and the

leader’s office together with all the other buildings are the zone 3.

Figure 7 System structure

…

Zone

1

Zone

2

Zone

3

Zone 3

Zone

1

Zone

2

(a) (b)

(c)

Zone 1

Zone 2

Zone 3 …


28

Chapter 3

Risk assessment

To design the key architecture and updating protocols in the system, firstly we analyze the potential

attacks towards the system. As the first step in the design, various threat sources and vulnerabilities

are identified in this chapter. The necessity of key updating is illustrated.

3.1 Threat identification

Generally, the system may be installed in the environment requiring general security controls (e.g.

outside a building of a company, in public transportation), or requiring strict security controls (e.g. a

confidential department of a company, military areas). We identify the various purposes from

different attackers in this section [10].

3.1.1 Attack purposes

The access card is a private property since it is personalized when issuing. This may be one of the

motivations of the attackers, to access restricted resources by pretending to be someone else, either to

access the resource beyond his own level or to avoid the behavior audit. On the other hand, the system

with access control applications may be used to protect the area from intruders. To damage the whole

system might be another purpose of the attackers. Besides, some other applications, like the micro

payment system, may be integrated with the access control system. Hence, money transactions may be

another attractive part for attackers.

3.1.2 Attack sources

The attack sources may be internal or external.

Typical external attackers can be a computer criminal, a terrorist or a spy. As an external attacker,

the devices in the protected area have little chance to be manipulated. Their main targets should be the

devices that are exposed to the public.

A spy may be also an internal attacker if he or she have already gained the trust of the system user.

Other internal attackers could be careless or curious current employees, or discharged employees. The

attacker needs to enter the protected area first, and then performs the attack evading from additional

protections in the area, such as closed circuit televisions. However, once the attacker finds the way to

enter the protected area, the threat is much more serious than that from external attackers. Thus,

devices in the protected area usually require stricter technical protections than the outside devices. If

this policy is applied, it is more difficult to attack from inside technically.


29

3.1.3 Threat identification

Though the threat sources can be natural, environmental or human [10], the first two are out of the

scope of the report. Only the threat from human is considered in this analysis.

General threat sources are identified and listed in Table 1. The targets on the list include the devices

in the system; nevertheless people is always another intriguing and vulnerable target in any attack.

Though their purposes may be different, attackers may try various types of attacks to extract the

critical information. These attacks will be discussed later in this chapter.

Table 1 Possible threat sources in the system

Threat Source Motivation Target Action

Computer

criminal (external)

- Destruction of information

- Illegal information disclosure

- Monetary gain

- Unauthorized data alteration cards, readers

• Fraudulent act

• Spoofing

• System attack (passive)

• Bribery

• Theft

Terrorist

(external)

- Blackmail

- Destruction

- Exploitation

- Revenge

• Bomb/Terrorism

• Information warfare

• System attack

• Theft

Industrial spy - Competitive advantage

- Economic espionage

cards, readers,

SAMs,

controllers,

backend

system

• Theft

• Intrusion on personal privacy

• System attack

• Bribery

Insiders (abused

by employees or

contract-

terminated

employees)

- Curiosity

- Ego

- Intelligence

- Monetary gain

- Revenge

- Unintentional errors and

omissions

• Browsing of proprietary

information

• Computer abuse

• Theft

• Bribery

• System attack

• Sale of personal information

3.2 General risk and mitigation

To evaluate the necessity of strict protection and the risk of the whole system, we discuss the

possibility of typical types of attacks. The behavior and possible results will be discussed below, and

recommendations will be given in Table 3.

Theft: This may be the simplest physical attack. Attackers who can find the location of the

devices may try to steal the devices. An external attacker may steal a card from a user, or the

reader outside the door; an internal attacker may steal a controller with a SAM in it besides

the card and the reader.

Theft of a card: If a card is stolen, even without any knowledge about the data stored

in the card, the system can be impacted. The thief can use the card to access the

limited resources before the card is revoked. If he is an expert in attacking

information systems, keys on cards may be extracted somehow. With these keys, the


30

attacker can make faked cards, which are able to authenticate with the SAM

successfully. Then he can send any data in the authorization process. Therefore, the

card revocation is indispensable. For example, the local database stores a list of the

revoked card UIDs. Before the key diversification, the controller checks if the card

has been revoked.

Theft of a SAM or the controller: The stolen SAM or controller is under the attacker’s

control. Therefore, the attacker may apply any operation on the devices. Since the

controller cannot provide secure storage of keys as the SAM, it would be easier to

extract the keys in the controller. The host key stored in the controller is less secure

than the keys only stored in the SAM. If the host key is extracted by the attacker,

faked controllers can be made. Even without knowledge about the keys, the SAM and

controller may be used for another zone. If the keys in the SAM are exposed, though

it is much more difficult, all the related cards will be influenced.

Database and key-related information compromising: In the rest of the project, we suppose

the database is secure. However, databases could also be the targets in an attack. This attack is

on the backend system or the controller. The access control list may be modified without

permission. The attacker may be interested in the confidential information about personal

privilege, or the attacker wants to make the system unusable.

Compromising the data in the backend system: The database in the backend system

controls the whole system. If this database is compromised, the local databases in all

the connected controllers may be modified when the next updating of the database. If

the key-related information in the backend system is tampered, the backend system

may send incorrect commands to controllers through the network.

Compromising the local database and storage in a controller: when a local database or

the data storage in a controller is compromised by the attacker, this controller may

make the access decision according this compromised database. The attacker may

make someone lose the accessibility, or he can make himself accessible to the limited

resources if he has got an authenticated card but without sufficient security clearance.

Denial of service attack: Basically, a SAM will process all requests from controllers who

communicate with readers and cards. There are four logical channels in a SAM, while they

cannot be used to send commands in parallel. Practically, one SAM can only connect with a

limited number of readers; otherwise the delay in every processing would be so large that it

bothers the users. However, there is no authentication from readers to SAMs, and the data

used in the initialization of an authentication process are not secured. Thus, attackers may

send a large amount of data simultaneously to SAMs by manipulating a controller or a SAM.

This attack cannot be protected by key updating that is proposed in the report. However, this


31

attack is not so practical in a large-scale system. The controllers deliver messages between

SAMs and readers. It is not difficult to check the messages from a reader in the controller.

This property can effectively protect the system from this kind of attacks. Therefore, though it

is potential, the attack is less possible in the system.

Social engineering: social engineering is to manipulate people to acquire sensitive

information. It is a possible attack on the access control system. This attack may result in the

key information exposure during the initialization or after the installation.

Mafia Fraud attack: In the contactless devices, relay attacks are getting more common. Mafia

Fraud attacks may be applied in the system [11]. A contactless card operates over a distance

and is activated automatically when it approaches a reader. Attackers may put the malicious

devices to readers to relay the information from the card to the reader. Using this attack on the

authentication schemes mentioned above, the attacker would be able to get access. Though

this attack introduces delay into the system, the protocol does not consider the time

constraints. Given that the authentication protocol is not a Distance Bounding protocol [12],

we recommend shielding of the DESFire cards to protect from malicious readers.

Replay attack: In this attack, the message may be repeated or delayed maliciously or

fraudulently. Attackers may intercept a message sent by the card and then send it again to the

reader. If the key remains the same when the attack happens, the system cannot realize the

message is sent by an attacker rather than a legitimate user. Therefore, using random numbers

and counters to construct session keys is crucial to prevent this attack.

Brute-force attack: This is the attack which checks all possible keys until the correct key is

found. It can be used in any cryptographic system in theory. It is a possible attack approach

applied by attackers to extract key information. Practically, if the time needed in the attack is

too long, the attack can be regarded as unfeasible. For example, generally, on today’s

computing capabilities, to brute-force attack for AES-128, it needs around 1014

years. Thus,

AES-128 keys have little chance to be extracted through this kind of attack. Since the access

control system is often used in daily life, the query happens frequently. If the keys are used

for too long, the possibility of key exposure will increase significantly since each

communication will expose a little information about the key. Therefore, it is reasonable to

update keys to prevent potential attacks, which may succeed after a period. In this scenario,

keys can be updated step by step. The main focus should be about the consistency of the

system.

Side channel attack: Side channel attacks are based on the information leaked by the physical

implementation of the cryptosystem, such as time and power consumption. Generally, it needs

to be conducted in a laboratory and needs expert knowledge. The necessary equipments may

include a high-end oscilloscope, an appropriate card reader, a custom-made device for


32

measuring the power consumption, and a PC with custom-made software for controlling the

measurement as well as doing the analysis [13]. The attacker should have enough expert

knowledge and skills. In the access control system, the main crypto devices are cards and

SAMs. They could be the target of side channel attacks. Outside the protected area, a skillful

attacker can apply the attack on cards. To mitigate the risk, the latest product, like DESFire

EV1, is recommended, while the attacks are still possible to be successfully conducted in the

future. If the attacker is from the interior, he may perform the attack on SAMs besides cards.

It is recommended to use devices with sufficient hardware protection in the system to enhance

the difficulty to perform this attack, for example, using the product with EAL 4+ certification.

The products Nedap chose meet the requirement.

System abuse: Besides attackers, an authorized user may also attack the system

unintentionally by abusing the system. Key information may be exposed or modified without

protection in this case. For example, the system may respond slowly to the change of user

identity so that unwanted access may be possible in the system.

The typical attack cost is listed in Table 2. With proper protection, the attack cost would be high

enough, such that attackers may have less interest or tendency to attack it. CC EAL 4+ is obtained by

the DESFire EV1 card, and CC EAL 5+ is obtained by the SAM AV2. Therefore, the attacks that cost

less than 1,000 Euro succeed with little chance in the system.

Table 2 Typical attack cost in an access control system [1]

Attacks Cost [euro]

Intercept authentication data on radio link < 1,000

Infer secret key through cryptanalysis < 1,000

Replay authentications < 1,000

Extract master authentication keys from a card 1,000 – 50,000

Extract diversification key from SAMs through side-

channel analysis or fault injection 5,000 – 100,000

Extract diversification key through “chip hacking” 20,000 – 200,000

Among all the consequences, we address the ones which have influence on keys in the system, such

as brute force attacks and side channel attacks. The attacks may appear to be difficult now, but attack

techniques are developing all the time. Moreover, more information about the keys is leaked as the

keys are used in the system. Thus, defense mechanisms should always be considered. Besides the

intentional attacks, the keys may be compromised or unexpectedly exposed by incorrect use. In both

cases, old keys should be replaced by new ones as soon as possible, in the consideration of the

availability and consistency of the system. Even in normal situations, key updating is required


33

sometimes. When the structure of the system is changed, for example, another party gets authority of

a door; new keys should be added into old devices.

Table 3 General risk and mitigation

Attack

method Risk Impact on the system Mitigation or countermeasures

In

scope?

Theft

A card is stolen/lost

without revealing

the information on

the card

Any operations can be

performed on that card later. It

can still read and write with

correct commands and

interactive information. If the

card is not revoked in time, the

attacker can use the credential to

access the system.

- Good and strict management rules

for updating the database; revoke

the card in time.

- Integrated with other

authentication or audit method to

prevent forgery of the card owner,

e.g. biometric, monitoring, and so

on.

No

A card is stolen/lost

and then attacked

by some experts

All the data stored on the card

may be exposed to the attacker.

It is not quite profitable for the

attacker.

- Well-defined access right of the

files on the cards to prevent

unauthorized modification

- Use key diversification function,

so that the attacked card has less

chance to influence severely on the

whole system

- Revoke the card in time.

No

A SAM is stolen

SAMs can be used in attacks

outside the protected area,

which makes other attack

methods possible. It can still be

read or write with correct

commands and interactive

information.

Use key usage counter and update it

periodically, but it is not applied in

the current system because of the

difficulty to control

No

Social

engineering

The system is

hacked in pre-

personalization or

personalization

process

The attacker has knowledge

about the system management

information, e.g. CMK, AMK,

and so on Sometimes not easy

to detect.

- Define and implement strict

control in the personalization and

personalization process.

- Choose reliable product

providers.

No

Database

and key-

related

information

compromisi

ng; system

abuse

The data in the

backend system is

compromised

The access right may be

modified without authorization.

Local databases and data in the

controllers may be modified in

the next database update. The

whole system will be exposed to

attack.

- Educate the employees.

- Define and implement strict

control in the database

management.

No

The data in a

controller is

compromised

The specific local database may

be modified without

authorization. The problem

happens in the authorization.

SAMs cannot communicate

with it securely.

- Making plans for updating the

system (the stored host key).

- Educate the employees.

- Secure host communication. This

is provided by SAM AV2.

Yes

Denial of

service

attack

Too much data are

exchanged between

a SAM and the

controller

The system cannot respond to

the authorized card.

Audit the system. Prepare the

detection method for this kind of

attack.

No

Mafia Fraud A card is read by a Unwanted system access. Shield the card. No


34

attack malicious reader

Replay

attack

Messages from the

authorized

components are

sent again by

malicious ones.

Unwanted system modification. Use counters and random numbers. No

System abuse

Contract-terminated

employees can still

access the resources

Unwanted system access.

- Good and strict management of

the database

- Good cooperation with human

resource department

No

System abuse Key abuse Unwanted system access

Generate the DMK by several

parties; each keeps a part of it

without the knowledge of other

parts.

Yes

System

abuse; social

engineering;

side-channel

attack; brute

force attack

Key compromise in

SAMs

The part of the access control

system that under the control of

the SAM is not reliable.

- Update the key periodically.

Define the updating period in the

company document

- Use the newer product generation.

- Prepare the update scheme used

when the system is attacked in

company documentation.

- Add physical protections to the

devices.

Yes

3.3 Risk assessment summary

Using SAM AV2 and DESFire EV1 in the access control system can construct a strong access control

system. We summarize the security properties of the system in this section.

Confidentiality: SAMs and cards can perform symmetric cryptography. Moreover, SAM AV2

has been able to do asymmetric cryptography. The symmetric cryptographic algorithm can be

chosen from DES, 3DES or AES. Among the algorithms, AES-128 is the highest security

algorithm provided by the card. Thus, we choose AES-128 as the main symmetric crypto

algorithm in the whole system. In addition, SAM AV2 supports RSA algorithms. This

property enables implementing a public key infrastructure.

Integrity: Both SAMs and cards provide hash functions. Only with the master key can the

structure of the information on SAMs or cards be modified. More specifically, the CMK is for

managing the applications on the card; the AMK is for managing the key information within

the application; the SAM master key is for initializing the information in the SAM.

Privacy: Privacy of the user is protected by the random UID function. Instead of the public

static UID, the RID number should be used to identify the card in the authentication phase

and stored on the card with encryption. In this way, the card cannot be traced.

Authentication: SAMs and cards support fixed authentication mechanism. The session key is

generated based on random numbers during the authentication.


35

Authorization: The authorization process is in the controller or the backend system, which

stores the access control list. The authorization information is decrypted by SAM and then

sent to the database. To speed up the process, the authorization decision is usually made by

the controller in practice, which stores a local database and connects to the backend system.

Audit: The backend system can audit the authorization decision made by the controller and

any changes in the system. This is not in the scope of the thesis, but this function should be

available in practice.


36

Chapter 4

Initialization of the system

After analyzing the security property in the system, we focus on the initialization of the system. To

start the system, the key architecture is designed for blank DESFire cards and SAMs based on the

product specifications. After that, the procedure to initialize the system with this key architecture is

described.

4.1 Key structure

4.1.1 Keys in cards to authenticate with a SAM

In an access card in the access control system, at least two applications are present: the default

application with AID 0x000000 and the application for the access control. In the user-defined

application, personal data for authorization are stored in a standard data file. According to the data,

the controller is able to decide whether the user is able to access the resource according to the result of

the query to the local database. Besides, to generate the diversified key, another standard data file can

be created to store the diversification input.

For maximum security, each file should have its own set of keys to control the accessibility.

However, to keep the number of defined keys as small as possible to facilitate the key management is

necessary. In addition, the access control process does not require writing operation. Only in the

initialization phase is writing access necessary. With these concerns, we design the FKs in an

application: in the initialization process, all files within an application will use the same diversified

key for write access and read/write access; the read-only key should be different from the read/write

key.

Since the static UID is protected, the diversified key cannot be retrieved before the UID is extracted.

Therefore, a key should be used uniquely for extracting the UID. It is not diversified. With this key,

the file that stores the diversification input data can be read. To write the data into the file, the FKs for

write access and read/write access are the same as those for the other file.

The key for writing and the key for reading/writing both can write the files. It will not participate in

the authentication or authorization process. If the key is desired to be retrievable, the information

should be stored only in the backend system. Otherwise, it is unnecessary to store these keys after the

initialization. To abandon the key, the write or read/write access of the file can be forbidden through

configuration within the protection of AMK or key for change access rights.


37

Similarly, the key for change access rights in the file should be disabled in the same way after the

card is personalized. After these changes, the file can only be read in this configuration unless AMK

or CK for the application is used.

In addition to the keys for read or write, a CK should be considered. If the AMK is defined as the

CK, to update the keys on the card, the master key is required. Since AMK or CMK is also the key to

implement other changes, the system will be more vulnerable than the one defining a CK. Thus, we

recommend defining an average AK, i.e. the AKs except AK0, to be the change key. Since this key is

more powerful than other AKs, it requires better protection. It should be only used when updating the

keys, so it is used much less frequently than other AKs. Thus, the diversification key for this change

key should be different from that for other AKs.

The structure of the keys in the card is shown in Figure 8. “Div” in the figure means that the key

should be diversified. CMK has the authority to do any operations on the card; thus it has the highest

security levels. AMK can do any operation within the application, so relatively it requires stricter

protection than other AKs. The key for change (AK5), the key for write (AK3) and the key for

read/write (AK3) are discarded since generally the data on the cards are not necessarily be changed

after issuing. AK2 and AK4 are stored in SAMs for authentication. AK1 is required in key updating.

It should be stored in the updating device.

The card in the figure above is the simplest case in the access control system. Obviously, the card

in the figure has only one application and two files. With AK4, it can only be used to authenticate

with the SAMs stores the DMK for AK4. However, sometimes it requires the card to authenticate

with several SAMs that store different DMKs. More files, applications and keys may be required in

the scenario. The possibility and methods will be discussed later.

4.1.2 Symmetric keys in SAMs installed in controllers

To authenticate with a card, a SAM should store AK2 and the DMK of AK4. To update keys on cards,

the diversification master key of AK1 should also be stored. Normally in an authentication request,

AK2 and AK4 are used. Firstly, the SAM authenticates with the PICC with AK2 to get the

Figure 8 Key structure in the DESFire card

APP: 0x000000 APP: 0xXXXXXX

CMK(AK0)

(Div)

AMK

(AK0)

(Div)

AK1 -

CK

(Div)

AK2 –

extract UID

(no Div)

AK4 – key

for read

(Div)

AK3 – key for

write & read/write

(Div)

AK5 – key

for change

(Div)

DESFire EV1 File: 0xXXXX data File: 0xYYYY div_rnd

d


38

diversification input. AK4 can be diversified with the data. Then the SAM uses the diversified AK4 to

authenticate with the card. If it succeeds, it gets the read access right of the file in the application.

Other than the keys that are used in communication with the cards, the SAM stores the keys for

management purpose and authentication with the host additionally. In the first entry of the sKST

stores the SAM master key. Similar to the CMK, authenticating with the SAM master key permits any

operation on the undefined entry in sKST and PKI_KST. A host key is stored to authenticate the SAM

with the controller. That also implies that the controller, or the host, stores this AES-128 key. To

update PICC keys, a host key or an offline change key is needed. We will mainly perform the key

updating with the host key, and discuss the offline change key later. The host key in key updating

could be the same as the one used to authenticate with the controller. In this way, the controller will

know how to update the PICC keys. However, the key stored in the controller is the least secure one

in the system. On the other hand, in this thesis, we will propose an additional device, or the JCs, to

update the key later. With these concerns, it is recommended to separate the key functions. Another

host key is used specifically to update the PICC keys, which is only stored in the backend system, the

updating devices and the SAM, but not the controller.

To sum up, the AES keys in a SAM that is used in communication with cards may contain: 1) the

SAM master key; 2) a host key(host_key1), which is only used to authenticate with the host mutually;

3) a host key(host_key2), (or an offline change key), which is only used to update keys; 4) a PICC key,

which is used to authenticate with AK2 in the cards to extract the UID and other diversification input;

5) a PICC key, the DMK for AK4, which is used to authenticate with AK4 in the cards to get the read

permission of the files; 6) a PICC key, the DMK for AK1, which is prepared to change the AKs in

cards (optional).

Other key entries in the sKST should be disabled as default. Only with the SAM master key these

entries can be enabled.

4.1.3 Diversification master keys in the system

Ideally, the master keys, including CMK, AMK, and the SAM master key, should be set to a random

value at personalization time and should be discarded after the configuration. Consequently, the

layout and configuration cannot be changed after issuing or installation. However, due to current

limited experience and practice, it is desirable to allow the possibility for changes like creation and

deletion. To meet this requirement, the master keys should be retrievable when necessary. To store

and retrieve the keys efficiently, these keys should not be the random value but the diversified keys.

They are unique for each card and each SAM.

Other DMKs include the one for AK4 and the one for CK (AK1). These DMKs are unique in each

area. In other words, a number of SAMs with different DMKs are used to control different resources.

In different areas, the DMKs could be also the diversified result from another DMK. A chained frame

with three-time diversification for the PICC keys is shown in Figure 9. It is a simple example while


39

the diversification times can be set by the system managers according to their situation. All the

diversified keys can be generated with this chain, including the SAM master key, the two host keys,

the DMK for AK4 and the DMK for AK1. The key used for extracting the diversification input of the

card, which is not diversified on the card, can also apply this scheme. Though it is not diversified on

the card, each AK2 should be different among areas. Therefore, to generate unique AK2 within each

area, the diversification should be conducted.

In the figure, key_0, key_1, key_1’, key_2, key_2’ and key_2’’ are only involved in the generation

of other keys. They are not presented in actual access control process. Therefore, these keys are not

stored in any SAMs that are integrated in controllers, to participate in the authentication process.

Instead, these keys are only in devices in the backend system and protected carefully. SAM AV2

provides the function to dump PICC keys; it is possible to store these DMKs in particular SAMs in

the backend system. If this suggestion is adopted, the key entry in these SAMs should be configured

to be able to be dumped. In contrast, SAMs installed in controllers, such as SAM1 and SAM_2 in the

figure, should be used specifically to communicate with the cards. Thus, the keys are never necessary

to leave the SAMs. It means the key entries should be configured in the way that they cannot be

dumped.

Usually, the diversification input may be not confidential or may be easily acquired. In this model,

once the key owner receives the input data from its subsidiary, the diversified key can be retrieved. In

contrast, the key information is protected in each node. The subsidiary only knows its own key

information. The other diversified keys cannot be regenerated by themselves.

This chain can be applied in a practical system. For example, a company C is considering installing

an access control system to control the entry of its buildings. It is an international company. The sub-

companies distribute around the world. Storing or dynamically requesting the diversification input,

the managers at the top level can retrieve all the DMKs easily. The officers in charge of the system in

a high level office can regenerate the key information of its sub-offices. While the diversification

input is less confidential, the key information is protected strictly.


40

4.1.4 The foreseen impact in case of key compromise

Though SAMs are considered to be the most secure component in the system, as discussed previously

in Chapter 3, it is still possible that an attacker is so interested in the keys that he or she explores a

way to find the keys. On the other side, keys may be used incorrectly or be impacted accidentally by

authorized users. Thus, the impact and countermeasures of the key exposing or losing should be

considered to protect the system from collapse. Compromise of different keys has various impacts on

the whole system.

Table 4 Impact of key compromise

Components Key type that is

compromised Impact

Backend

system

DMK for CMK

Full access to data stored in any deployed chip in the area

the DMK controls

All card configurations can be changed.

DMK for AMK

Full access to data stored in the application in any deployed

chip within the area the DMK controls

All configurations in the application can be changed.

DMK for SAM master key

Configuration in the SAMs within the field can be changed,

e.g. enable/disable a new key entry.

Blank key entry can be updated after enabled.

A SAM

SAM master key All the AKs in cards which generating the diversified key will

be compromised.

Host key used to

authenticate the controller

Controllers and SAMs cannot authenticate each other. Either the

host or the SAM can be forged in the authorization phase

Figure 9 Example of the DMKs in the system

Eindhoven

SAM1

K3 = Div(K2’, input_SAM1)

Europe

K1 = Div(K0, input_key_1)

Asia

K1’ = Div(K0, input_key_1’)

Head Office

K0

Amsterdam

SAM2

K3’ = Div(K2’, input_SAM2)

Card1 Kcard = Div(K3, input_card1)

France

K2 = Div(K1, input_key_2)

Netherlands

K2’ = Div(K1, input_key_2’)

Germany

K2’’ = Div(K1, input_key_2’’)

…

…

…

Card2 Kcard’ = Div(K3’, input_card2)


41

Host key used to change

the PICC keys PICC keys can be changed.

Key to extract UID UID cannot be protected. Cards can be traced.

DMK for AK1 If the UID of the card is also exposed to the attacker, CK in the

card is exposed. Then the AKs can be changed.

DMK for AK4

If the UID of the card is also exposed to the attacker, AK4 in the

card is exposed. Then the card can be forged. The authentication

will succeed.

A DESFire

card

CMK For a particular chip, access to data stored in it is possible.

For a particular chip, configuration can be changed.

AMK

For a particular application in a particular chip, access to

data stored in it is possible.

For a particular application in a particular chip,

configuration can be changed.

AK1 or AK4 The chip can be forged. The authentication will succeed.

Retrieving information on the chip is possible

4.2 Initialization of SAMs

When SAMs are sold by the manufacturer, the first process should be personalization to change the

default product key to the customer-specific key. In addition, SAM AV2 is set to work in the AV1

compatible mode as default, which provides weaker protection. Therefore, another purpose in the pre-

personalization is to activate the SAM AV2 into AV2 mode.

Attackers may interest in attacking the process as well because much sensitive information will be

transmitted from the backend system to SAMs. It is dangerous if attackers can get some information

or hack the system in this period. Three entities are involved in the procedure:

SAMs: Initially the SAM master key, i.e. the key entry 0 is set to 0. After the activations of

AV2 mode, the default value of other keys is 0 and disabled as default.

Hosts: Devices to send the key entries to SAMs. Some programs may send the command

automatically, or be controlled to send commands by system managers. During the operation,

they have knowledge about the default master key, the new master key and maybe the new

key entries at least.

System managers: Staffs who are responsible for the pre-personalization operation. The most

critical property he should protect is the new master key and the new key entries.

The steps to personalize a SAM are described briefly below:

1) The SAM stores the default SAM master key now. This is used for the first-time host

authentication. At this time, the host may be the system where the initialization program

located. It should be secured, which means it is preferable to be in the protected area. After

the host authentication succeeds, session keys are generated.


42

2) Change the default SAM master key into a new AES-128 key. The command is

SAM_ChangeKeyEntry, and the new key entry is protected by the session keys. This

command cannot succeed without the host authentication.

3) Switch the product into AV2 mode with the command SAM_LockUnlock with the new

master key entry in step 2. All the other key entries will be reset to default after this operation.

4) Now key entries can be changed only with the new master key. To update other key entries,

the SAM authenticates with the host again with the new master key. New session keys are

generated.

5) Change other key entries according to the design. Specifically, in this step, the second and

third key entries are set as the host keys; the fourth entry is a PICC key that is not diversified

to be used to extract the UID of cards; the fifth and sixth entry are PICC keys that are used to

generate the diversified key: one is for AK4, which is used in the authentication process to get

the read access; the other one is for AK1, which is used to update the value of other AKs on

the cards. If the SAM is not responsible for updating the cards, the sixth entry can be omitted.

The value of each field related to the valid key is generated from the frame depicted in Figure

9. Additionally, only one set of keys is used in the system, but each entry can store three keys.

Therefore, the second key and the third key in the entry may be updated simultaneously with

random values. Only when updating the SAMs are these fields related. Besides the updating

period, these fields should not be used.

6) Initialize the PKI_KST. Disable these entries.

7) Insert the SAM into a controller.

After the initialization, the SAM is ready for use. When a card is in the field, the SAM uses the

keys to decide if the card stores a proper key. Also, the SAM is ready to be involved in an updating to

improve the security of the system.

4.3 Initialization of cards

The initialization of cards can be separated into two stages. The first stage is pre-personalization. In

this step, the card is configured to be a part of the access control system. Applications, files and keys

are created. In short, after the pre-personalization, the card can be used to do the authentication, but all

the cards after this step store no data for authorization. Thus, in the second step, which is called

personalization, personal data about the card holder are written into the card with proper protection.

This usually happens when the card is issued to a user. After this step, the card is ready to be used as a

personal credential.

Separating the two phases facilitates the card issuing process. It also separates the responsibilities

of cards management and personal data management.


43

4.3.1 Pre-personalization of cards

In the pre-personalization process, cards are updated from blank ones, to be the components in the

user’s access control system. To start the procedure, a device that is used to pre-personalize the card

authenticates with the card with the default CMK. The default CMK is set by the card manufacturer

(NXP). Secondly, according to the design, applications are created. The AID is set by the user of the

institution. In this step, six AES-128 keys (AK0-AK5) are created as AKs. At the same time, AK1 is

set to be the CK. The default values for all these keys are 0.

To change the value of the ordinary AKs (AK2 –AK5), authenticating with the change key (AK1)

or the AMK (AK0) is demanded. Since AK0 has the authority to change all the other keys including

the CK of the application, in this step, it is more convenient to authenticate with AK0. After selecting

the application, with a successful authentication with AK0, AK1 – AK5 can be updated. AK2 is the

same key as stored in the corresponding SAMs, which is used to extract the UID and other

diversification input. AK1, AK3, AK4 and AK5 are the diversified results of their DMKs. The

diversification algorithm is performed on the device in the backend system, which meanwhile stores

the DMKs securely.

Next, the data files can be created under the protection of the AMK. The file IDs are also set by the

manager. The key setting is shown in Figure 8, with AK3 as the write and read/write key, AK4 as the

read key, and AK5 as the change key in this file. The file that stores the diversification information,

i.e. file 0xYYYY in Figure 8 is created. Data for diversification is sent into this file. Then write access,

read/write access and change access for this file are set to be forbidden.

The last step in this stage is to change the master keys from the default values to diversified results

of their DMKs and enable the random UID mode. After this step, this card is ready to be issued in the

access control system.

4.3.2 Personalization of cards

The personalization of a card is to link the card to a specific user. The authorization information, such

as the user name or employee ID, should be stored in the data file and the local database to do

authorization. To write the data into the files, the host authenticates with the correct FK that permits

the data writing. Thus, it requires the device in the card personalization to store the DMK for the key

for writing (the DMK for AK3 in Figure 8). Also, the software should be able to generate diversified

keys. After the personalization is accomplished, the write access, read/write access and change access

for the file is set to be forbidden.

4.4 DMKs in the zones

In Chapter 2, we described the use scenarios of the system. Several system structures may be applied

according to the requirements from the client. In the scheme, each zone has a security level, which


44

means that devices in one zone may be managed by a manager or shares DMKs. The DMKs among

different zones may be the same one or different. The possibilities are discussed in this section.

4.4.1 Share a set of DMKs among zones

To divide different zones, the simplest method is managing the local database in the controller, which

makes the decision on the authorization. This design can be applied to all the three cases mentioned

above. All the components in the system share one set of keys. The zones are not divided in the

authentication process but the authorization. Therefore, the chained structure of the distribution of

DMKs which is illustrated in 4.1.3 may be not necessary.

The prerequisite for this implementation is: all the cards in the zones are issued, owned, and

managed by one party. Because all the DMKs are shared, the system managers know the key

information stored in all SAMs. They control the whole access control system. The system

administrators should be reliable enough to operate the system.

However, this is not always applicable. For instance, in a combined system as Figure 7, persons

grouped into zone 3 are labeled with higher security levels than the other zones. Employees who are

responsible for the other zones may not have the authority to manage the sensitive information in zone

3. Meanwhile, the system managers for zone 3, who are sufficiently reliable, may not be available or

willing to manage the whole system. Besides, the personal information in zone 3 may demand better

protection. Using the same DMKs as other zones increases the risk for them. Therefore, setting

different diversification master key for each zone is necessary. In the next part, the possibility will be

analyzed and assessed.

4.4.2 Manage DMKs separately within each zone

Basically, SAMs in one zone store the same keys. For example, in zone 1, there are three doors with

three SAMs and controllers. All the keys except the SAM master keys in the three SAMs may be the

same. Their sKSTs may be the same except the first entry. However, since the SAM IDs are different,

the diversification input to generate DMKs in them should not be their own SAM_IDs; otherwise

these SAMs will receive different diversified outputs. To solve the problem, a group SAM ID is

defined by the operator who has the authority to generate the diversification master key, i.e. the

manager who is accessible to the key.

In different zones, the keys are not the same. If the zones are parallel and are managed by different

parties, the key information is protected within this field. If the zones have different security

requirements, the managers who have a higher security level may control the devices from the other

field. In this setting, the chained DMKs meet the requirement.

For example, in the combined system for the organization B we described in Chapter 2, two

employees, Alice and Bob, are responsible for building P and building Q respectively. They should

not know the keys for the other building. Another employee, Charlie, is responsible for all these


45

buildings. He should know more information about the keys in the system than Alice and Bob.

Reference to Figure 9, Charlie is the holder of K2’. He uses the group SAM IDs and K2’ to generate

the DMKs (K3, K3’) for the subsystems. He knows the keys for both buildings. Alice and Bob receive

the diversified result for their own building: Alice receives K3, and Bob receives K3’. They do not

know the keys for the other building. For the doors in zone 3, Charlie uses another set of DMKs, like

K2 in the SAMs.

To access the protected area in a zone, the card should store the corresponding diversified keys. For

example, Card1 is only used to access zone 1. The key structure and card initialization process follow

the description in previous chapters. Card2 is owned by the leader of the organization B, who should

be able to enter all the buildings. Thus, a simple framework in the card is not sufficient. Since only

one AK can be designated as the read key for a file, new files should be created to fulfill the

authentication requirement. A new file uses another AK as the read key. In this example, K3 is used

for zone 1; K3’ is used for zone 2; K2, which is generated from K2, is used for zone 3. After the

diversification, Kcard, Kcard’ and Kcard’’, generated from K2, are stored on the card. On the basis of the

simplest case (Figure 8), new files and keys are created as Figure 10. 14 keys and 32 files can be

created in an application on the DESFire EV1 card; thus 9 zones can be defined in the structure with

maximum. If more zones are defined in a structure, a new application may be created.

The initialization of these cards is similar to that of the simple ones. The only difference is that

more AKs and files need to be created in the pre-personalization. The data stored in new files should

be the required authorization information.

4.4.3 Comparison

The two methods are both feasible in a system. We compare the differences in the following table.

Table 5 Comparison of using different DMK structure

shared DMK separate DMK

The number of key set

on one card 1 the number of zones required to enter

Administrative

Authority 1

- Several authorities, with the knowledge of

their own zone

Figure 10 New files and keys in a card to access several zones

File: 0xYYYY div_rnd

d

APP: 0xXXXXXX

AMK

(AK0

)

(Div)

AK1 -

CK

(Div)

AK2 –

extract UID

(no Div)

AK4 –

read:

key_1

AK3 – key for

write & read/write

(Div)

AK5 – key

for change

(Div)

File: 0xXXX1 data File: 0xXXX2 data File: 0xXXX3 data

AK6–

read:

key_2

AK7 –

read:

key_3


46

- The responsibility in each zone is separated, so

the risk of abusing the right is reduced.

Key updating easy, simultaneously complex, separately

Card revocation easy separately, more parties involved

Keys on SAMs

One set, only known by one

backend system or manager of the

system

Several sets. Some key entries may be shared

(e.g. host key)

Backend system More operations and storage,

more strict security requirement Operate in its own zone

4.5 Access control process

In the initialized system, the cards, together with the local database, can be used to identify a person to

access a district. The data exchange in the whole process is described in detail in this section.

When a SAM is inserted into a controller, the mutual authentication with the host key begins

immediately. After successful authentication, a secure channel between them is built. All data

between them will be encrypted with the session keys.

When a card is in the field of a reader, the reader receives a four-byte number (the RID) as the

identification of the card in the anticollision process. At the same time, the reader selects the

application on the card. The reader notifies the controller the presence of a card. Then the controller

initiates the authentication process.

Since the random UID mode is enabled on the card and key diversification is used in the system,

the first task is to get the real card UID and other diversification input to do the key diversification.

The nondiversified key, which is stored both on the cards and the SAM, is used first. After this

authentication, the diversification input is encrypted and sent to the controller. The controller requires

the SAM to decrypt the message. The SAM uses the current authenticated key to decrypt the message.

After getting the plaintext, i.e. the card UID and other diversification input, the SAM encrypts it with

the valid host key and sends it to the controller. After the controller receiving the response, it can

decrypt to get the diversification input and store it for following communication.

Now the diversified key on the card can be regenerated by the SAM that stores the correct DMK.

The controller sends the command with the diversification input to the SAM to begin the

authentication between the SAM and the card. This authentication is done through the read key of the

file. After this step, the file on the card can be read out with the protection of the read key, which

means the data on the file will be sent out after being encrypted by the key.

The successful authentication between the SAM and the card indicates that the card has the

authority to send the data on it. The authentication finishes now, and the authorization begins. The

controller requests to read the file. As the response, the card sends the encrypted personal data. Again,

the controller forwards the message to the SAM. The SAM uses the current session keys that are

generated from random numbers and the diversified read key to decrypt the data. After that, the


47

personal data are sent to the controller after being encrypted and MACed with the session keys from

the mutual authentication between the SAM and the controller.

Once receiving the response, the controller extracts the personal data after decrypting the message

with the same session keys. It decides whether the door can be opened by this card after querying the

local database in it.


48

Chapter 5

Key updating

After the system is initialized, all deployed keys should have a maximum validity period. This period

is determined by the administrators. In some cases, clients maybe prefer a long updating period since

the system may be relatively less valuable to attack or the resource under protection is not extremely

sensitive. In other cases, the system user may want to update the system frequently to secure the

system and resources within the protected area.

Keys that are required in an authentication process are stored on cards and SAMs. Updating keys

causes changes in both of them. The process should be carefully designed to ensure the system

consistency and mitigate the risk of generating new vulnerabilities. Keys are stored on cards, SAMs,

controllers, and backend systems, with different purposes. The requirements or protection

mechanisms for changing them are distinct. Cards are distributed to a large number of users. To

update SAMs, the backend system usually controls the process by sending updating commands

generating from proper keys, codes and algorithms. Some other devices or software may be involved

in the procedure, such as smartcards that store the required keys.

The updating of other components, such as the local database in the controller, or the stored

information in the backend system, should be controlled by specific staffs. Their responsibilities,

restrictions, access privileges and actions should be accurately recorded and documented.

In this chapter, we focus on the key updating on SAMs and cards.

5.1 Update PICC keys

Commands are sent to the SAM through the controller. When a PICC key in the sKST in a SAM,

including AK2, the DMK for AK1 or AK4, is about to be updated, corresponding keys on the cards

are required to update at the same period. Once the updating begins, ensuring the consistency of the

system during the period is significant. It is not acceptable that the system annoys most users in the

updating. The design should make users aware of the updating at the least extend. Two possible

updating schemes are discussed here: 1) update SAMs first and then cards; or 2) store backup keys on

cards and update SAMs.

5.1.1 Prepare the new key in SAM first

If cards only store current valid keys, they can only be authenticated by the old keys during the

updating. Consequently, to import or activate new keys in the system, key information stored on each

issued card has to be renewed. The operations can be performed either manually by specific programs

or automatically by SAMs. If the updating is performed by specific programs, the place and


49

employees to update cards should be carefully chosen. Generally, they could be the same as the ones

in the initialization which under sufficient protection and surveillance. If SAMs are responsible for the

card updating, a series of commands is sent to SAMs from the backend system or controllers to do the

updating efficiently and properly.

Since a large number of cards are issued on the system, successful updating on all cards takes some

time. Therefore, in the updating period, the new keys are ready for use and should be used for

authenticating with the updated cards, while the old ones should not be deleted immediately. Instead,

the old keys are still valid until all or most access cards have been updated. After the updating period,

the old keys should be revoked in the system. In short, in this scheme, after SAMs are updated, two

keys start to exist simultaneously in the system.

The updating process can be divided into three parts:

Part 1: Update SAMs to store new PICC keys

To start the updating process, a SAM receives the new PICC keys. This is the first step if the fields

in the related PICC key entry for other two keys are initialized to random values. It is also possible

that the SAM stores the value for the new versions in the initialization process if the system managers

have decided the new key. In that case, the SAM has already stored the new keys; thus this step could

be skipped if no changes necessary on SAMs. Suppose the key in updating is the DMK of AK4 of

cards, we assume the old key is DMK_AK4_old, and the new one is DMK_AK4_new. After this step,

the fields that store the keys in the entry are:

KeyNo PosA PosB PosC Va Vb Vc

5 DMK_AK4_old DMK_AK4_new (Random) 00 01 02

Other fields remain the same.

To update PICC keys in a SAM, proper authentication is required. In the key architecture,

host_key2 is used specially for updating the PICC key. It is defined as the change key of DMK_AK4

in the sKST. With this configuration, authentication with host_key2 is required before updating the

DMK of AK4. The controller may know nothing sensitive about the updating such as the change key

and the new key. The new host authentication makes the authentication with host_key1 in the same

logic channel (LC) invalid. The controller cannot mutually authenticate with SAMs after the host

authentication changes. Therefore, in this short period, the communication between the controller and

the SAM may stop temporarily, which means the SAM and the controller that stores the local

database cannot receive data from each other. At this moment, the authorization process suspends.

After receiving the new entry successfully, the SAM uses host_key1 to authenticate with the

controller again. This process is depicted in Figure 11.


50

Part 2: Update the issued cards

After SAMs are updated, new keys are ready for use in the authentication. The second step in the

updating period is changing the corresponding application key in cards to new ones. In this process,

the system administrator could announce the updating of the system, and urge the card holders to go

to specified offices to update the cards. With the change key stored in the backend system, the card

can be changed in a secure environment. If the update of the cards is performed by this manual

method, two sets of keys should be both valid in the authentication process in the system for a period.

Another implementation to update the card is to use SAMs and controllers to update the cards

automatically. This updating happens when a card tries to use the old key to authenticate with an

updated SAM. When the card is in the field of a reader, the controller sends the command to get the

key version of the required authentication key. If the key version in the response is the old one, the

controller knows that the card should be updated. A legal card stores the CK. The controller

commands the SAM to authenticate with the card using the change key of the application. After that,

the controller sends the command SAM_ChangeKeyPICC with the diversification input to the SAM

to generate the encrypted data for the new key. The response from the SAM is sent with the message

to the card, to update the outdated application key. In this way, the controller could record the number

of renewed cards.

To change the average application keys on cards, or the AKs except the AMK and the CK,

authentication with the CK is required. Since CK is a diversified key, the UID and other

Controller and other devices used in the updating

SAM

Authenticate with host_key2

Updating begin

Normal authentication: authenticate with host_key1

Stop the normal communication with SAM

Update the key entry: change PosB into the new key

sKST is updated.

The new authentication

key is stored Back to the normal authentication with host_key1

Restart the normal communication with SAM Begin to record

the update period

for PICC

Legal cards with old keys can be

authenticated and authorized.

Authentication is still possible. Authorization is

halted.

Legal cards with new or old keys can

be authenticated and authorized.

Figure 11 Update the SAM to store the new PICC keys


51

diversification input data should be firstly extracted. Furthermore, if the key to be changed is a

diversified key, e.g. AK4 in the structure, the data are also necessary in the diversification algorithm

to generate the new key. Therefore, as a normal access control process, AK2 will be used firstly in the

authentication to extract the data. Furthermore, since the card’s authenticity can be ensured by CK,

authentication between the SAM and the card with the old key is not necessary. Therefore, the old key

can be forbidden to participate in the authentication with SAMs once the updating begins. The process

is depicted in Figure 12.

Using SAMs to update cards automatically shortens the validity of the old key significantly. If the

system is attacked, the exposed key can be revoked at once in this scheme. Another advantage is less

human resources and lower risk in management in the updating. However, most commands in the

procedure are controlled and delivered by controllers, which requires more complex implementation

Figure 12 Update of the issued cards

DESFire SAM

Authentication with host_key1

Controller and reader

If: old version

A card is in the field

Get key version of AK2

SAM_ChangeKeyPICC

key data(protected )

Change the key using key data(protected)

If: new version

Normal access control process with the new PICC key

Counter increment Continue normal access control process

Authentication begins

Authentication with the AK2 to extract div_input

Store div_input Get key version of the target key

Authentication with the CK


52

on the controller. Also, it requires the card holder to hold the card near the reader long enough to

finish the whole process. In addition, if the updating for cards is not performed with SAMs but

external programs in the backend system, SAMs could store nothing about the change key.

To sum up, these two options are both practical. They can be discussed and determined by the

system managers considering requirements from clients.

Part 3: Revoke the old keys from the system

After a certain period, most cards have been updated. The old keys should be deleted from the

system. Another updating of the same key entry in SAM can revoke the invalid keys. Similar as the

first step, host_key2 is required as the authentication key again by the updating devices. Then the

related field in the key entry will be updated as:

KeyNo PosA PosB PosC Va Vb Vc

5 (Random) DMK_AK4_new (Random) 03 01 02

Finally, the SAM uses host_key1 to authenticate with the controller again to start normal

communication.

5.1.2 Store backup keys on cards

If cards store backup keys before SAMs start to use a new key, the new key is possible to be used

immediately in the updating. In this situation, the old one is useless immediately without influence on

the availability of the system. However, this design requires a double storage on the card for the read

keys. Consequently, it cannot be adopted by all the systems. Maximally 9 keys could be defined as

read keys in an application. If there are 5 zones or more in the system, according to the key

architecture described previously, no adequate space is available for backup keys.

Since each file can be only read by one AK, a backup file should be created under the control of the

backup read key. If there is no backup file for the new read key, to enable the backup key as the new

authentication key for read access, the key setting in the file has to be updated. This operation requires

the authentication with the key for change access in the file, i.e. AK5, which is not stored in SAMs

before the updating. Moreover, if the change access has been forbidden after the personalization, the

AMK may be required to change the key setting. If this happens, the process is much more

complicated than the other scheme while the old keys cannot be abandoned immediately. Firstly, the

backup keys are sent to the SAM. Since the new key cannot replace the old one in this case, it should

occupy another key entry in the sKST. If the old ones are replaced now, without any changes on cards,

the new key cannot get the read access of the files. Secondly, the key for change access is required to

authenticate with the card and then change the key setting of the file. The read access key of this file

is changed to the backup key.


53

Before the old key entry in the SAM is disabled, the two keys will exist in the same period, which

did not fulfill the requirement in this scheme. On the other hand, it is more complicated and much less

secure than the scheme we mentioned in the last section. Therefore, the backup file is demanded in

this scheme.

With the backup files and keys, after updating key entries in SAMs through changing the key

values and the related key numbers, the old read key is abandoned in the authentication immediately.

The advantage of this scheme is that the key updating can be accomplished in a short time. This is

significant when old keys are compromised. However, backup keys and files are required to be

created and stored on the cards. This increases the complexity of the key structure on cards and the

card initialization process. Concerning about these disadvantages and the restriction on the storage of

cards, this scheme is not recommended. Generally, the first scheme is sufficient to update the system.

The second one could be considered as a supplement for parts of the system.

5.2 Update host keys

The two kinds of host keys in SAMs - the one used to authenticate with the controller or the host to

establish a secure channel between them and the one used to change the keys - have different

influence on the system when updating.

5.2.1 Update host_key1

This host key is stored both in a controller and the SAM in it. It is only for the authentication between

the SAM and the controller. To ensure the authenticity of all SAMs and controllers, it should be

unique for each controller.

In a controller, there is only one key activated to authenticate with the SAM. On the other side, the

SAM can store three keys with different versions at the same time in an entry. This enables us to

update the key and the relative information in the controller according to that stored in the SAM,

which should be also preserved in the backend system under sufficient protection. In these processes,

SAMs will not be influenced. For instance, a controller stores key 1, version 1 to authenticate with the

SAM. This key is also stored in the SAM at entry 1 in the sKST, together with version 2 and version 3.

In this period, the host will ask the SAM to authenticate by key 1, version 1. This will be indicated in

the parameters of the command SAM_AuthenticationHost. After a certain time, the key in the

controller is updated to key 1, version 2 by the manager with devices in the backend system. After this

updating, the host asks the SAM to authenticate with key1, version 2 instead of version 1.

Although this updating is straightforward and fast, it is not complete. The key entry in the SAM

should also be updated after a key is outdated. Also, the new host key should be imported into SAMs.

Therefore, a similar key updating process as the one of the PICC keys can be considered.


54

In the key entry for host_key1, the fields can indicate that the change key is host_key2. Therefore,

to update this entry, authentication with host_key2, the other host key, is required. This key is not

stored in the controller but on the updating devices, like a JC. In the updating, the authentication

between the controller and the SAM is influenced. The communication between them suspends.

Concerning about this, the timing for this updating should be chosen at the moment with a few

requests from the cards.

To shorten the time interval without authentication between the controller and the SAM, a new host

key should be firstly ready in the sKST in the SAM, and then the controller will be updated to replace

the old key with the new one.

The updating period is set by the system administrators. Controllers are not as secure as SAMs to

store keys. It is less difficult to acquire secret information from hosts than SAMs. Updating the keys

in the controller more frequently is reasonable. Once keys in a controller are renewed, the next

consideration is whether the host key entry in the SAM should be renewed. It is more secure that the

old key is revoked by storing a new version in the entry immediately. After this updating, the old host

key is totally abandoned in the system. This requires another updating on SAMs as depicted in Figure

13. Though this is recommended to improve the security, it is also acceptable that the old key is still

stored in the sKST if no exposure of the old version is detected. In this way, the SAM can be updated

less frequently. In both cases, the managers should ensure that the SAM stores the new version before

the old version is deleted from the storage of the controller, otherwise the SAM and the controller

could not authenticate with each other.

5.2.2 Update host_key2

This host key is stored in SAMs and the backend system. It is only used in the updating process. Since

it has higher privileges in the key controlling, the change key for this entry should be defined for itself

or the SAM master key. The other host key, host_key1, should not be able to update it since

host_key1 is also available in controllers, which is less secure than SAMs.

If the change key is itself, the impact of this key exposure is increased. Having knowledge about

this key, an attacker can change all the key entries except the SAM master key because the updating

only requires the change key without the old key value. If the change key is the SAM master key,

usually the entry will not be updated unless it is compromised. Meanwhile, it can be updated by

asymmetric keys when required.


55

5.3 Update PICC keys with an offline change key

In the previous design, the offline change key is not included. It is another option to update the PICC

keys. We can define an offline change key instead of host_key2 to perform the key updating. The

procedure is similar with the updating through host_key2. The difference is at the beginning of the

updating. Instead of the mutual authentication through host_key2 with the updating devices, the

offline change key has to be activated by the command SAM_ActivateOfflineKey. There may be no

authentication with the updating device. To avoid the replay attack, two schemes can be considered.

First, the counter is updated each time. It requires the updating devices or the backend system to

monitor and update the counter properly. If the counter is not updated, the offline change key should

be updated immediately once it is used.

5.4 Update asymmetric keys

When a PKI key is updated, public keys stored in the backend system and the RSA key pairs in the

SAM are both updated. In SAM AV2, the updating of asymmetric keys is protected by symmetric

keys, especially the host keys. Similar as the symmetric ones, in the updating, an authentication with a

host key which is defined in the PKI_KST is required. Since PKI keys can update all the symmetric

keys without the protection of defined change keys, they are much more powerful in the key updating.

Therefore, we recommend that the change key for the PKI key entries to be the SAM master key or

Controller SAM

Authenticate with host_key1, version2

Update

Authenticate with host_key1, version 1

Authentication with host_key1, version2

Stores host_key1 version1

Store host_key1 version1, version2,

version3

Replaces version1 by version2

Updating devices

Stop authentication Stop authentication

Authenticate with host_key2

Update host_key1 Store host_key1

Version2, version3, version4

Figure 13 Update host_key1


56

another host key entry in sKST, which means that only persons or devices that know the SAM master

key or this new host key have the ability to update PKI keys.

5.5 Update symmetric keys with asymmetric ones

PKI keys are updated within a proper host authentication with a host key; in return, PKI keys can be

used to update the symmetric keys in the sKST. The command PKI_UpdateKeyEntries is used

specifically for updating the symmetric keys. With this command, the updating is not protected by the

defined change key in its sKST entry. Moreover, up to three key entries can be updated once using

PKI keys if RSA-2048 is used.

Generally, the PKI keys are only stored in the table but not used in the system. It is possible to

disable the entry to protect asymmetric keys. When the host_key2 requires updating, or an emergency

happens, such as all the PICC keys need to be updated as soon as possible, PKI keys can be enabled

with the SAM master key. After the updating, the entry should be disabled again.

The change_ctr must be used to prevent replay attacks in the command PKI_UpdateKeyEntries.

This value should be recorded and protected in the backend system. Once the asymmetric key entry is

activated, the counter should be updated.

Table 6 Comparison of updating with host keys and PKI keys

With host keys With offline change keys With PKI

The number of key entries

that can be updated once 1 1 Up to 3 (for RSA-2048)

KeyNoC field in sKST Host key Offline change key It does not matter.

Requirement Host authentication Offline key activation

The key is permitted to

update symmetric keys

in the setting

Command SAM_ChangeKeyEntry SAM_ChangeKeyEntry PKI_UpdateKeyEntries

Change counters? No Yes Yes

Protection

Reference to the

protection mode in host

authentication: plain,

MAC or full protection

Encryption and MAC RSA (encryption and

signature)


57

Chapter 6

Java cards in the access control system

In the previous chapters, we discuss the initialization and the updating of the system. To update the

keys, specific devices can be applied. As SAMs are integrated in controllers, which are distributed

installed in a secure place near the doors, the updating devices should be easy to carry, distribute and

protect. It is ideal that the device can communicate with a controller or a SAM easily in the way that

little change is required for the hardware. Considering these properties, the JC is an ideal option as an

updating device.

6.1 Java cards hierarchy

In the system, JCs are used to update keys in the system. They can be regarded as a part of controllers

which is only in the system when SAMs are updating. JCs store sensitive information including new

keys and other related authentication information. All the JCs should be kept safely at any time.

Practically, the system may be managed by several parties. Each of them has different knowledge

about the sensitive information. Therefore, in the updating, several authorities may be involved. Based

on the system designed in the previous chapters, we design a hierarchy for JCs.

Similar as the DMK structure, JCs in the system have different security levels (Figure 14). In the

example in Figure 14, there are three kinds of JCs. Some JCs, i.e. JC1a, JC1b, JC1c and JC1c in the

figure, are only able to authenticate with a specific group of SAMs. Generally, they are the updating

devices in the system. The administrators for SAMs use these cards to update the system. Some JCs

control other JCs. In this figure, JC2a controls JC1a and JC1b; JC2b controls JC1c and JC1d; and JC3

controls JC2a and JC2b. Basically, the JCs at the bottom can communicate with SAMs; optionally, all

the other cards may be able to authenticate with SAMs in their fields.

SAM1

SAM2

JC2a

JC2b

JC1a

JC1b

JC3

SAM3

SAM4

JC1c JC1d

Figure 14 Java card hierarchy


58

6.2 Example

Taking the company C mentioned in 4.1.3 as an example. The chained structure for JCs is consistent

with the practical scenario.

During the updating, administrators of SAMs receive JCs from their superiors. For instance, the

officer who is in charge of the access control system in the building in Eindhoven receives the JC

from an employee who is responsible for the access control system in Europe. The superior distributes

cards in Europe. He initials the cards and sends them to the subordinates in Europe. Normally it is not

necessary for him to update SAMs. The responsibilities are distributed through the cards. On the other

side, he is not authorized to control the updating process in Asia, since the keys he preserves are only

valid in his region. His superior, the one from the head office, has the knowledge about all the keys.

Though it is possible for him to update all the SAMs, generally it is not optimal and necessary due to

the low efficiency.

After the updating, these JCs could be returned or destroyed.

6.3 Keys on the Java card

To update symmetric keys in SAMs, host_key2 is required in the host authentication. Therefore,

host_key2 will be sent to a JC and stored to perform the authentication with SAMs in the updating.

Secondly, the new key entry should be acquired by the JC. After the mutual authentication between a

SAM and a JC, session keys are generated. The new key entry is encrypted and protected by the

session keys.

Before the updating on SAMs, the symmetric keys, including the host_key2 and the target key, are

transported between JCs. The JC structure is consistent with the diversification key structure. The

owner of the top JC has knowledge about the DMK. It is easy to regenerate the diversified key after

obtaining the diversification input. The output of the diversification is sent to the JC under its control.

It is mandatory to encrypt the key information. Since asymmetric encryption is more secure than

the symmetric key cryptography, the communication between JCs adopts the RSA-2048 algorithm.

To implement the algorithm, RSA keys should be stored properly in each card. Two possibilities are

discussed below.

6.3.1 Unique RSA key pair for each card

For maximal security, each card can generate and store its own RSA key pairs. Correspondingly, a

JC should acquire the public keys of the cards it needs to authenticate with. At the same time, it

should ensure the one it communicates with having a sufficient security clearance and being

configured properly. For example, JC2a can send sensitive information to JC1a or JC1b. It checks the

cards in the authentication. If the card is JC1c, key information should not be sent; otherwise a JC1c is

capable of updating SAM2 once it receives the symmetric keys.


59

To fulfill the requirement, certificates are necessary in the system. An external program, which may

be on another JC or a secure device, can act as a certification authority (CA). It is used to generate a

dedicated RSA key pair, namely pk_CA and sk_CA, and the public key (pk_CA) is extractable to all

the JCs in the system. In the initialization of a JC, its unique RSA key pair, namely pk_card and

sk_card, are generated and stored. The public key (pk_card) should be certificated. In the certificates,

the information about the card is signed together with pk_card. The data are sent to the external

program. The program outputs the certification to the card.

Besides the pk_CA and certification from the CA, a card stores information about its security

clearance and the ones that it can communicate with additionally.

In this method, the key pair can be protected within a JC. The JC can generate a key pair by itself.

The private key never leaves the card. As a result, only the card knows its private key.

6.3.2 Share an RSA key pair in one level

Another option is that all the cards in a level store the same key pair. The function of cards can be

found by matching the RSA keys. In this way, its own RSA key pair and the public keys of other

cards are stored in the card in the initialization. With these public keys, a Java card can communicate

with the cards that store corresponding private keys. The card can verify the signature and encrypt

data with the public key.

For example, JC2a and JC2b in the figure should store the same RSA key pair, namely PK_2 and

SK_2. Additionally, they store other two public keys, one of the cards below it, i.e. JC1a, JC1b, JC1c

and JC1d, namely PK_1; one of the cards above it, i.e. JC3, namely PK_3. With these public keys, a

Java card can authenticate with JC1a, JC1b, JC1c and JC3. In a JC1a, the key pair for its layer (PK_1 and

SK_1) is stored. Besides, the card would be used to communicate with a JC2a. Therefore, PK_2 is

stored. In JC3, PK_3 and its private key SK_3 are stored. Then PK_2 is imported into it. It does not

matter if JC3 can communicate with JC1a. It is preferred that a Java card can only communicate with

two kinds of JCs at most.

The difference from the first structure is that the RSA key pairs are generated externally. Keys are

generated outside the JCs and then imported into them. The certification is not necessary to identify

the card authority. Before the authentication, the cards do not exchange information about the public

keys. They only utilize the public key that stored in them. Besides, this scheme requires the card

distributors know the public key of the card with which it will communicate. For example, the owner

of JC3 knows PK_2 before the authentication begins.


60

Chapter 7

Implementation

In this chapter, the applets on JCs are implemented. They may be used to update SAMs, or

communicate with other JCs. To protect the key information, a protocol between two JCs is designed

and analyzed.

7.1 Tools

The implementation is developed in eclipse 3.3.2 using JDK 1.3. JCOP tools are installed in it,

including NXP JCOP tools, version 3.2.7 and NXP SmartMX Target-Pack for NXP JCOP Tools,

version 1.2.7.

The JCOP Tools can facilitate the development of applets on JCs. It can simulate NXP JCOP-based

JCs with source-level debugging, and performance profiling capabilities. It supports the JCOP off-

card API and on-card API. The on-card API includes Global platform 2.1.1, JC 2.2.2 and JC 2.2.1 and

so on.

7.2 Communication between a Java card and a SAM

Before a JC is used to change keys on SAMs, it should receive the key number, version and the value

of both the target key and the associated change key. Sometimes the updating is not for the whole

entry. A byte indicating which fields will be updated is proposed. This byte is called “program mask”

(PRO_MAS). The JC should also store this value before the updating.

After a JC is inserted into a controller, the controller detects it and selects the application for

updating. This requires the controller knows the AID of this applet. To update a PICC key, the mutual

authentication between the JC and the SAM with a host key is necessary. If the selection command

succeeds, the JC sends the number and the version of the host key. The controller uses the information

to construct the command SAM_AuthenticateHost, then sends it to the SAM to initiate the

authentication process. After the host authentication finishes, the session keys are generated. Then the

JC sends the PRO_MAS to the controller and the controller replies the JC with the parameters in the

message to the SAM. Now the JC can encrypt the new key entry and add the MAC value with the

session keys. The procedure is depicted in Figure 15.

If there is no successful mutual authentication, the card should throw exceptions if the host

intended to perform any operation in step 5, 6, 7, 8. The result of the program on the terminal is

shown in Figure 16. The key “dump session key” is for testing purpose. It outputs the keys and

random numbers in the process. In practice, this function should be deleted.


61

Figure 16 Execution of updating a SAM with the Java card

Figure 15 Communication between a Java card and a SAM

Javacard Controller/Host SAM

1. Select applet:

00A40400||Len_AID||AID

2. KeyNoC||KeyVerC||9000

3. SAM_AuthenticateHost

4. Authentication with the host key

5. (Succeed) PRO_MAS||9000

6. CLA||INS||P1||P2||01||CLA_SAM

New key(value,

number)

Change/host

key(value,

version, number)

PRO_MAS

CHANGE_I

NS(0xC1)

7. enc||mac||9000 8. SAM_ChangeKeyEntry


62

7.3 An authentication protocol between two JCs

As mentioned in Chapter 6, before a JC is used to communicate with SAMs, the necessary keys are

transported from the JC’s superior. Another applet on the JC is implemented for this procedure. In the

JC with a lower clearance which may receive information from its superior stores the applet that is

used for receiving information in the authentication. On the other side, the card with a higher

clearance stores the applet that is used for sending information. In the implementation, we assume that

the RSA keys have been successfully acquired and verified by both cards. The necessary public keys

and their own private keys are stored in the applets before the authentication begins. In addition, the

JCs have received and stored the information about which key is updating and whether diversification

is used in the process. This can be done through external programs when initializing the cards.

The general idea to do the mutual authentication is through random numbers. In this protocol, a JC1

and a JC2 are inserted into a host like a computer and communicate with the help of a program. The

program assists the communication by sending C-APDUs to both cards, and receiving the responses.

It stores nothing sensitive but only the public parameters.

Firstly, the host program selects the applets on JC1 and JC2. After the communication starts, the

host sends the instruction to the JC1. The JC1 replies the host by sending the request. In this response,

the card states the number of the key to be updated. Also, the diversification input (e.g. SAM_ID) is

sent together with a flag before it. If the key diversification is not used for this key, the flag is set to 0.

A random number is generated and concatenated at the end. After encrypted with the public key of the

JC2 which has been stored in JC1, the updating information and the random number is protected. The

padding scheme in the encryption is RSAES-PKCS-v1.5 [15]. Further discussion about the padding

scheme is provided in the security evaluation (7.5).

To link this message with the JC1, a signature is appended to the encrypted message. Typical

signature schemes include RSASSA-PSS, RSA-SSA-PKCS1-v1.5 [15]. In this implementation, we

choose RSASSA-PKCS1-v1.5, since RSASSA-PSS is not supported in the chosen JC.

After receiving the request, JC2 verifies the signature with the public key of JC1. If the signature is

verified, it decrypts the encryption part with its own private key. If diversification is used, the

requested diversified key will be generated. According to the key information in the request, this card

will check if the new key entry is available currently. Also, it looks up to the proper change key used

in the updating, i.e. the correct host key. The host key will be concatenated after the new key entry,

and then the received random number is added to the end. They are encrypted with the public key of

JC1. After that, a signature of JC2 is appended.

Once JC1 receives information from the superior, it verifies the signature and the random number.

If the signature is correct, the information is decrypted with its own private key. After the decryption,

the random number can be extracted. If the number is correct, the new key entry and its change key

are stored in the card.


63

After all these steps, this card is ready to update a SAM. The applet for communication between the

JC and a SAM can use the stored key information.

The protocol is depicted in Figure 17.

7.4 Update the SAM with PKI keys through Java cards

Besides the symmetric keys, asymmetric keys can be used to update the keys in sKST. This updating

can be conducted by a particular powerful device, like a computer in the backend system. Then

messages can be sent through the network in the access control system. Concerning the convenience

of distributing and protecting JCs, the possibility of updating with RSA keys through JCs is

considered.

The SAM chooses to use RSAES-OAEP as the encryption scheme and RSASSA-PSS as the

signature scheme. However, these algorithms are not supported by the chosen JCs. Some other

versions of JCs may support this padding scheme, such as Oberthur Cosmo Dual 72K [14]. On the

other hand, it is possible to implement RSAES-OAEP on the JC without the native functions by

manually generating a padded plaintext first and then encrypt it using the algorithm without the

padding scheme. In RSAES-OAEP, it requires a hash function and a mask generation function. These

Figure 17 Communication between two Java cards

e1||s1

JC1 JC2 Terminal

(Stores several applets) Applet a2 for communicating with JC2, storing and using JC2_PK

(Stores several applets) Applet a1 for communicating with JC1, storing and using JC1_PK dmk_newkey, dmk_ck

Select: a2

Select: a1

Generate rnd ∈ {0,1}rnd_len e1 = Enc(JC2_PK,key_no||div_input||rnd) s1 = Sig(hash(e1), JC1_SK)

Ver(hash(e1), s1, JC1_PK) = true? key_no’||div_input’||rnd’ = Dec(JC2_SK,e1) new_key = Div(div_input’, dmk_newkey) change_key = Div(div_input’, dmk_ck) e2 = Enc(JC1_PK,new_key|| change key||rnd’) s2 = Sig(hash(e2), JC2_SK)

e2||s2

Ver(hash(e2), s2, JC2_PK) = true? new_key’|| change_key’||rnd’’ = Dec(JC1_SK,e2) rnd’’ = rnd? Store new_key_entry’ and change key’


64

functions in SAM can be chosen from SHA-1, SHA-224 and SHA-256. Since the padding algorithm

does not use the key, the key information is not leaked in this way.

On the other side, RSASSA-PSS is not supported by the JC. Differently from the encryption part,

the JC does not provide a signature scheme without padding. If RSASSA-PSS has to be used on JCs,

the function has to be implemented by hand without native functions.

7.5 Security evaluation

7.5.1 Verification of the protocol

ProVerif is an automatic cryptographic protocol verifier, in the formal model (Dolev-Yao model) [15].

We have verified the authentication protocol between two JCs using Proverif. The ProVerif code can

be found in Appendix B. The result demonstrates that no attack is found on the secrecy of the keys.

Proving secrecy is ProVerif’s most basic capability. The secrecy of the new key and the private

keys are verified by queries:

query attacker: newkey.

query attacker: sk(JCA).

query attacker: sk(JCB).

In the authentication between two JCs, it is necessary to ensure that only with the authentication,

the information can be extracted. ProVerif can capture relationships between events which can be

expressed in the form “if an event e has been executed, then event e’ has been previously executed.

With this property, we verify that when the symmetric key is transferred in a valid authentication:

query evinj: endAuth(w,x,y) ==> evinj: startAuth(w,x,y)

The event startAuth(JCA,JCB,nonce) is annotated in the process executed by the superior (JCB in

the code), after receiving the random number from a subordinate (JCA in the code). The event

endAuth(JCA,JCB,nonce) is annotated in the process executed by JCA, after verifying the signature

and the encrypted random number. This query aims to verify that each successful mutual

authentication is accomplished by two authenticate JCs with requires private keys.

The output of ProVerif indicates that the new key and private keys in JCs are secret in the whole

process. ProVerif does not find an attack in the verification. The relationship between

startAuth(JCA,JCB,nonce) and endAuth(JCA,JCB,nonce) is also verified. Each event

endAuth(JCA,JCB,nonce) corresponds to an event startAuth(JCA,JCB,nonce).

7.5.2 Random numbers in the protocol between two Java cards

In the authentication between two JCs, the random number is critical. Other data, such as the key

number and the diversification input in the request, has low information entropy. The key used for

encryption is public. Consequently, the random number can be acquired theoretically by exhaustive

search if the attacker analyzes a request from the sender. With a large random number, this risk is low.


65

Meanwhile, even if the random number is exposed, it is still difficult to attack the authentication since

the reply is also protected by a signature. Without a correct private key, the signature cannot be

generated properly.

On the other hand, if the random numbers in two communications are the same, the encryption and

signature from JC1 will be the same. In this case, the attacker can insert a response intercepted before

as the response, while the old key entry should not be used any more. This possibility decreases as the

length of the random number increases.

Therefore, to secure the communication, the length of the random number should not be too short.

The key number is 1 byte; the diversification flag is 1 byte and the diversification input is 7 bytes.

Later in the communication, the random number is concatenated with the key entry and the change

key in the encryption by a superior. The key entry is 61 bytes. For RSA-2048, the length of the

plaintext varies. RSAES-OAEP requires the plaintext of one encryption is less than (256 – 2hLen – 2)

bytes, where hLen is the length in bytes of the hash function output. RSAES-PKCS-v1.5 requires that

length is less than (256 – 11) = 245 bytes. Since we choose the RSAES-PKCS-v1.5 currently to

implement with the program, the maximum length of the random number is 245 – 61 (length of the

new key entry) – 16 (length of the change key) = 168 bytes. This length is long enough to protect the

random number.

7.5.3 RSA algorithms

The two padding schemes, RSAES-OAEP and RSAES-PKCS-v1.5 [15] can be both implemented on

the JCs. RSAES-OAEP is claimed to be more secure than RSAES-PKCS-v1.5. It is recommended for

new applications by RSA Laboratory. The other one, RSAES-PKCS1-v1_5 is provided mainly for

compatibility with existing applications.

In RSAES-OAEP, hLen = 20 for SHA-1, hLen = 28 for SHA-224 and hLen = 32 for SHA-256; so

the length of the padded input is 214 bytes, 198 bytes or 190 bytes, respectively. Therefore, if we use

RSAES-OAEP as the padding scheme in the protocol between the JCs, the length of the random

number should be adjusted. Since the length of the new key entry is 61 bytes and the length of the

change key is 16 bytes, the length of the plaintext in the response should be 77 bytes. Therefore, the

random number can be 137 bytes, 121 bytes or 113 bytes, respectively.

To simplify the protocol and provide reasonable security, we choose RSAES-PKCS-v1.5 instead of

RSAES-OAEP in the protocol between two JCs as the first step in the project. We choose the one

using SHA-1 in the implementation.

The two signature schemes are both secure currently. RSASSA-PSS is recommended since it is

more robust than the other one. However, as RSA-SSA-PKCS1-v1.5 is provided as the native

function of the JCs, we implement the protocol with this scheme first. MD5, RIPEMD160 and SHA-1

are provided as the options in the function. In the implementation, we use SHA-1 in the applet.

RSASSA-PSS may be implemented in the future.


66

7.5.4 The use of PKI keys in SAMs

It is unequivocal that asymmetric cryptography is more secure than the symmetric ones. However,

AES-128, which is mainly used in the system as the symmetric cryptography, is difficult enough to

attack. To introduce the additional PKI keys in SAMs requires much more effort. The initialization

and maintenance would be more complicated than the system without asymmetric keys. Also, the PKI

keys in SAMs are more powerful in the key updating, since no host protection is required in the PKI

keys updating commands. Exposure of PKI keys would be more dangerous than that of the symmetric

keys.

Moreover, the updating commands with PKI keys require a correct value of the command counter.

No commands are available currently to extract this value. This implies the backend system, or the

updating devices store this value, and can synchronize the changes in each SAM. To facilitate the use

or the command counter for authorized external devices, the SAM may be improved by providing

new commands for this counter.

7.5.5 New risks from Java cards

Though JCs are ideal to store sensitive information and the protocol ensures the authenticity, to use

them in the updating process, new risks are introduced into the system.

Firstly, attackers can now attack JCs in addition to the installed access system. Though the

hardware is secured, the management of the cards may also have vulnerabilities. The distribution and

the usage of the cards should be recorded in the system securely. Once the update is finished, the card

can be destroyed or returned. If a JC is stolen or lost in the process, the sensitive information is not

exposed. However, the stolen JC should be detected and recorded to control the updating process.

Management rules are indispensable in the distribution of JCs.

Secondly, in the new key entry, the associated change key should be updated after each updating.

This can be done by indicating a new version of the same change key or updating the host key. If the

change key remains the same, there is a potential risk that the JC may be used to update the SAM

again later even when this version is expired.


67

Chapter 8

Conclusion

In this work, we investigate the Nedap access control system, especially the devices that store the key

information. A large-scale access control system can be designed, initialized and updated based on

this thesis.

8.1 Contribution

Though products in Nedap access control system provides sufficient security protection, key updating

scheme is critical in the system. Based on the property and function of the products chosen in the

Nedap access control system, including the access card MIFARE DESFire EV1 card, SAM module

MIFARE SAM AV2 and Java card JCOP31, v2.4.1, the thesis contributes to the system on several

aspects. The first achievement of the project is a thorough security analysis on the system. After that,

a system constructed by various DMKs is designed. The key structure of these components is given in

detail. The main improvement in the project is the updating process in the system. Following the

instructions, the keys stored in the devices can be successfully and securely updated with little

influence on the consistency and availability of the system, which is critical to protect the system but

now is not sufficiently researched in the current system. Last but not the least, a new device, the Java

card, is introduced into the system, to help with the updating in the large-scale system. The

communication between two Java cards and communication between a Java card and a SAM is

defined and implemented. With the Java cards and the protocol, the key information in the system can

be distributed conveniently and safely.

8.2 Future work

Currently the initialization of JCs is assumed secure. The RSA keys are pre-stored on the updating

cards. The transportation of these keys is not protected by any keys in the current system. The devices

that are used to communicate with the JCs may store keys. This may be similar to the mutual

authentication between a controller and a SAM. In the future, the authentication between a JC and the

device may be considered to improve the security.

Also, like all other keys, the JCs also need to be protected by key updating scheme. The certificates

may be used to ensure the authenticity of the public key of the Java card in the Java card infrastructure.

Therefore, the management of the certificates in the system should be discussed and defined,

including the issuing, updating and revocation.


68

Other updating information, such as the key number, version and host mode, should be sent to the

JC before the updating. This can be taken care by some external programs in the system, which can be

another part of future implementation.

Updating the SAM with JCs is protected by AES-128 in this thesis. The symmetric algorithm and

communication protocol provides sufficient security currently. To improve the security of

transportation of sensitive information, it is ideal to use the asymmetric cryptography between them.

Unfortunately, SAMs only support RSAES-OAEP as the encryption scheme and RSASSA-PSS as the

signature scheme, whereas these two APIs are not supported by the chosen Java card. In the next step,

these two asymmetric cryptographic algorithms will be implemented on JCs.

A secure access control system, including a key updating protocol, can be built based on the thesis.

The implementation can be integrated with current available hardware and software in Nedap.


69

Bibliography

[1] Andreas Rohr, Karsten Nohl, Henryk Plotz. Establishing Security Best Practices in Access

Control. s.l. : RWE, Security Research Labs.

[2] 14443-1:2008, ISO/IEC. Identification cards -- Contactless integrated circuit cards -- Proximity

cards -- Part 1: Physical characteristics.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39693.

[3] NXP. MIFARE Smartcard ICs. http://www.mifare.net/products/mifare-smartcard-ic-s/.

[4] 7816-4, ISO/IEC. Identification cards - Integrated circuit cards - Part 4: Organization, security

and commands for interchange. 2005.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36134.

[5] DESFire product leaflet. http://www.nxp.com/documents/leaflet/75015782.pdf.

[6] NXP. MISFARE DESFire EV1 contactless multiapplication IC - Product short data sheet. 2010.

[7] Understanding Java Card 2.0. Java World. http://www.Javaworld.com/Javaworld/jw-03-1998/jw-

03-Javadev.html?page=2.

[8] Witteman, Marc. Advances in Smartcard Security. Information Security Bulletin. July 2002.

[9] NXP. Key diversification function.

http://www.nxp.com/documents/application_note/AN10922.pdf.

[10] Gary Stoneburner, Alice Goguen, Alexis Feringa. Risk Management Guide for Information

Technology Systems. s.l. : NIST.

[11] Desmedt, Thomas Beth and Yvo. Identification Tokens — or: Solving the Chess Grandmaster

Problem: Advances in Cryptology-CRYPT0'90.

[12] Chaum, Stefan Brands and David. Distance-Bounding Protocols: Advances in Cryptology—

EUROCRYPT'93.

[13] NXP. http://mifare.net/technology/security/mifare-desfire-d40/frequently-asked-questions/.

[14] http://en.wikipedia.org/wiki/MIFARE.

[15] ISO. http://www.iso.org/iso/home.html.

[16] http://www.mifare.net/products/mifare-sam-av21/mifare-sam-av2/.

[17] Brute force attack. http://en.wikipedia.org/wiki/Brute_force_attack.

[18] Hancke, Gerhard. A Practical Relay Attack on ISO 14443 Proximity Cards. University of

Cambridge. 2005.

[19] NXP. Security of MF3ICD40. http://mifare.net/technology/security/mifare-desfire-d40/.

[20] Tan, Wee Hon. Practical Attacks on the MIFARE Classic: Computing Science of Imperial

College London, 2009.

[21] PKCS #1 v2.1: RSA Cryptography Standard. Laboratories, RSA. 2002.

[22] Hancke, Gerhard. A Practical Relay Attack on ISO 14443 Proximity Cards. Cambridge :


70

University of Cambridge, 2005.

[23] Dworkin, Morris. Recommendation for Block Cipher Modes of Operation: The CMAC Mode for

Authentication.: National Institute of Standards and Technology, 2005.

[24] NXP. P5DF081-MIFARE SAM AV2 Product short data sheet. 2011.

[25] AN10787 - MIFARE Application Directory (MAD).


[26] AN10957 - Generic Access Control Data Model.


[27] AN10969 - System level security measures for MIFARE installations.


[28] Application of Attack Potential to Smartcards v2.7: Common Criteria, 2009.


71

Appendix A: command set

A.1 Part of DESFire EV1 command set

Command Description

Authenticate MIFARE DESFire EV1 and the other device show in an encrypted way

that they possess the same secret(the same key)

Change KeySettings change the master key settings on MIFARE DESFireEV1 and application

level

Set Configuration configures the card and pre-personalizes the card with a key, defines if the

UID or the random ID is sent back during communication setup.

Change Key change any key stored on the card

Get Key Version reads out the current key version of any key stored on the card

Create Application creates new applications on the card

Delete Application permanently deactivates applications on the card

Get Application IDs returns the AID of all applications on the card

Free Memory returns the free memory available on the card

Get KeySettings gets information on the card and application master key setting; in addition

it returns the maximum number of keys with are configured for the selected

application

Select Application selects one specific application for further access

Get Version returns manufacturing related data of the card

GetCardUID returns the UID

Get FileIDs returns the FID of all active files within the currently selected application

Get FileSettings gets information on the properties of a specific file

Change FileSettings changes the access parameters of an existing file

Create StdDataFile creates files for the storage of plain unformatted user data within an

existing application on the card

DeleteFile permanently deactivates a file within the file directory of the currently

selected application

Read Data reads data from Standard Data files or Backup Data files

Write Data writes data to Standard Data files or Backup Data files

A.2 Part of SAM AV2 command set

Command Description

SAM_DisableCrypto This command allows the permanent and irreversible disabling of the

cryptographic functionality of the SAM. Successful host authentication

with one of the three keys stored in KeyNo 00h is required to send this

command.

SAM_AuthenticateHost The command is used to run a mutual authentication between the SAM

and host system. Such an authentication rpoves that both the SAM and

the host contain the same secret.

SAM_LoadInitVector The command is used to load an init vector for the next cryptographic


72

operation.

SAM_KillAuthentication Invalidates any kind of authentication in the logical channel the

command is issued.

SAM_SelectApplication The command is the equivalent of the SelectApplication command of

DESFire. The SAM generates a list of available keys linked to the

specified AID as defined in the key entry. For every key number, up to 6

key versions can be stored in the list.

SAM_GetVersion The command returns manufacturing related data of the SAM. It can be

used to detect whether a SAM has been switched to the AV2 mode

SAM_ActivateOfflineKey This command is used to activate both offline crypto and offline change

key.

SAM_ChangeKeyEntry This command updates any key entry of the sKST. The complete data set

of the full key entry must always be sent, and it will be programmed to

the non-volatile memory of the MIFARE SAM AV2 as defined in the

non-volatile ProMas.

SAM_GetKeyEntry This command allows reading the contents of the key entry specified in

the parameter KeyNo. Instead of the full keys on positions a, b and c,

only their key version will be returned, each packed in one byte. It can be

issued without valid (host) authentication.

SAM_ChangeKUCEntry Updates any KUC entry.

SAM_GetKUCEntry Allows reading the data of the KUC entry specified within the parameter.

It can be issued without valid (host) authentication

SAM_DumpSessionKey This command can be used to retrieve the session key generated by the

SAM. This feature is necessary if cryptographic operations like encipher

or decipher should be handled by the terminal microcontroller instead of

the SAM. As this feature can be seen as a potential security risk if not

used in the correct way, it can be enabled/disabled using the

configuration setting of every key entry.

SAM_DisableKeyEntry The command disables a key entry. After executing this command, the

corresponding disable flag in the key entry is set and the key entry

cannot be used any more for authentication and key change procedures.

The key entry can still be read by a SAM_GetKeyEntry command. To

reactivate the entry, a SAM_ChangeKeyEntry command has to be

issued. All fields in the key entry can still be changed by this command

even if the entry has been disabled.

SAM_Verify_MAC Verifies the MAC which was sent by the PICC based on the given

MACed plain text data and the currently valid cryptographic key.

SAM_Generate_MAC Creates a MAC which is meant to be sent to the PICC based on the given

MACed plain text data and the currently valid cryptographic key.

SAM_Decipher_Data Deciphers data packages sent by a PICC based on the currently valid

cryptographic key and returns plain data to the PCD.

SAM_Encipher_Data Creates data packages which are meant to be sent to a PICC based on the

given plaintext and the currently valid cryptographic key. To do so, the

plaintext is enciphered in cipher block chaining send mode. CRC and

padding bytes are appended automatically.

PKI_GenerateKeyPair Creates a pair of a public and a private key. MIFARE SAM AV2 only


73

supports the CRT format. A successful host authentication in the LC

using SAM_AuthenticateHost with a host key is required to execute this

command.

PKI_ImportKey Imports an RSA key. This can be either a public key or a full key pair.

When a change key is specified, a successful host authentication in the

LC using SAM_AuthenticateHost with a host key is required to execute

this command.

PKI_UpdateKeyEntries The command can be used to change key entries of the sKST. Executing

this command does not require any protection coming from the change

key of the key entries. Instead the command’s execution is protected by

asymmetric techniques using the RSA encryption. On top a digital

signature is added using the RSA signature algorithm. This allows offline

preparation of the cryptogram.

PKI_GenerateSignature Generates a signature on a hash given as input using one of the two

private keys stored in the PKI_KST

PKI_SendSignature Returns a pre-computed signature. The returned signature is protected

according to the SAM-Host protection in place on the corresponding LC.

PKI_VerifySignature Verifies the correctness of a signature

SAM_AuthenticatePICC In this procedure both the PICC as well as the MIFARE SAM AV2 show

in an encrypted way that they poses the same secret which especially

means the same key.

SAM_ChangeKeyPICC This command generates the cryptogram that has to be sent to the PICC

in order to change any key stored in the PICC. Both the current and the

new key need to be stored in the KST to execute this command. This

means a new PICC key need to be loaded into the SAM prior to issuing

this command.


74

Appendix B: Proverif

B.1 Code

free net. (* public channel between two Java cards *)

(* Functions to provide public key encryption and signing*)

fun pk/1. (* public key *)

private fun sk/1. (* private key*)

fun pencrypt/2. (* asymmetric encryption *)

fun sign/2. (* signature *)

reduc pdecrypt(pencrypt(x,pk(y)),sk(y)) = x. (* symmetric decryption *)

reduc checksign(sign(m,sk(k)), pk(k)) = m. (* check signature *)

private free newkey. (* secret new key entry sent from B to A *)

free reqinfo. (*public information sent in the request*)

query attacker: newkey. (* secrecy query *)

query attacker: sk(JCA).

query attacker: sk(JCB).

(* Check authentication*)

query evinj: endAuth(w,x,y) ==> evinj: startAuth(w,x,y).

let JCA =

new nonce;

let encA = pencrypt((reqinfo,nonce),pk(JCB)) in

out(net, (encA, sign(encA, sk(JCA))));

in(net, response);

let enckey = checksign(response,pk(JCB)) in

let (newkey, =nonce) = pdecrypt(enckey, sk(JCA)) in

event endAuth(JCA,JCB,nonce);

0.


75

let JCB =

in(net, request);

let (=reqinfo, nonce) = checksign(request,pk(JCA)) in

let encB = pencrypt((newkey,nonce),pk(JCA)) in

event startAuth(JCA,JCB,nonce);

out(net,(encB, sign(encB,sk(JCB))));

0.

process

((!JCA) | (!JCB)) (* execution of the protocol*)

B.2 Result

-- Secrecy & events.

Starting rules:

Rule 0: equal:v_20,v_20

(Definition of equal.)

…

Completing...

Starting query evinj:endAuth(w_17,x_18,y_19) ==> evinj:startAuth(w_17,x_18,y_19)

RESULT evinj:endAuth(w_17,x_18,y_19) ==> evinj:startAuth(w_17,x_18,y_19) is true.


Starting rules:



Rule 1: attacker:v_112 & attacker:v_111 -> attacker:pencrypt(v_112,v_111)

(The attacker applies function pencrypt.)

…

Completing...

Starting query not attacker:sk(JCB[])

RESULT not attacker:sk(JCB[]) is true.


76


Starting rules:





…

Completing...

Starting query not attacker:sk(JCA[])

RESULT not attacker:sk(JCA[]) is true.


Starting rules:





…

Completing...

Starting query not attacker:newkey[]

RESULT not attacker:newkey[] is true.


77

Appendix C: Implementation details

1. JC1:

Applet:

JCReceive (AID: 010203040510): receives the keys for updating.

APDU parameters:

CLA_JC1: 0xA0

INS_JC1_SEND_REQUEST: 0x11;

This INS is used when the applet tries to send a request to a superior JC. The data included in

the request are the updating key number, diversification information and a 168-byte-long

random number

INS_JC1_RECEIVE: 0x12;

This INS indicates that the C-APDU contains the requested information. The JC can receive

the key information and store it to update a SAM.

Error information:

ERROR_N: 0x66;

Indicate that the random number check is failed.

ERROR_SIGN: 0x77;

Indicate that the signature is wrong.

Applet:

Update (AID: 010203040500): interacts with a SAM using keys from JCReceive.

APDU parameters:

CLA_HOST: 0xA0;

INS_STEP_1: 1;

The first command in authentication with a SAM: generating MAC & rnd1

INS_STEP_2: 2;

The second command step in authentication with a SAM: verifying MAC

INS_STEP_3: 3;

The third command in authentication with a SAM: final check and session key generation

INS_STEP_4: 4;

The fourth command in authentication with a SAM: receiving the header in the updating

Error information:

MAC_FAILED: 0x11;

WRONG_HOSTMODE: 0x22;

CHECK_FAILED: 0x33;


78

NO_HOST_AUTH: 0x55;

2. JC2:

Applet:

JCSend (AID: 01020304050A): store the keys for updating and interacts with JC1.

APDU parameters:

CLA_JC2: 0xA0;

INS_JC2: 0x21;

A C-APDU with this INS is the request from another JC which would like to receive key

information to update a SAM.

Error information:

ERROR_SIGN: 0x77;

Indicate that the signature is wrong.

ERROR_NOKEY: 0x88;

Indicate that there is no new key available now.

3. Terminals:

Application:

UpdatingHost:

This application is used to transfer the data between a JC and a SAM following the mutual

authentication protocol.

UpdatingHost_RSA:

This application is used to transfer the data between two JCs.

4. A result from UpdatingHost_RSA:

Step1: get encrypted random number from JC1, host <-> JC1

C-APDU: A011000000

R-APDU:

B186C458CE817101B877222E2A888FDC1AF9FF1D574796022D222C344110BE89C3829

42D7DF19F88ED7419998C4550C4FAB4E4ED4943E7656A8A4BEE3901CCF49461B5109

746341BCDDCA16402FF571A58AB80F3C3538B32105692029432339F8D1B4C8E649984

A23573DDF5A664D3645A5E8C4879861D132BC41D54E30C09F21EB004D7D6007A9300

9F214AFD5199088791964C7789EE8FAF220E76179FD88E906DC9921A0285181827153A

D7FB59CC31EB69B46B6D445057B9AE29FBDDEE83C20420941948B6F5CBF1AD32E9

3474E084CDF4487BBAFE685EE58840FF772D8C9F652AD026557A778375A54A00F30C

7C7A20396F93375BBC3651BF31C239916D00


79

C-APDU: A011000000

R-APDU:

C1C1E4AB9695B5E4C09F027931876390C40061334A230101B6CEBE8C9566D46AC7BE

66C5CA79714D5DBCE5E2744475D270C80C2A211615F602714DDE8EF15F7E0F564A41

CB14F9004FD723B416D8B56A15BF133B9CAC8D555FBE3F5E8BB295D9A62FAD45E6

AD95A3A95104B62E08073D8F70062E6F36791501A22E1EE3CE80536E132CF98821129

C94BD148393D445B697E206EEFFA837CCE5A1E95903DCE8D459855D15E1FEB5A7FB

B335D3B67A2E9C29E93C6C2A84B10BD96F1964BD1969B3024F37394C821E9A539C03

02889B75D6B8BAFE5F641585CADA7E0179BA874A546052A0FA77AA6A28C4DE5B97

6C187E2C54FDEDE150ECB6C9606B1D02A37D896D00

C-APDU: A011000000

R-APDU: 24389000

Step2: get new entry from JC2, host <-> JC2

C-APDU:

A0210000000200B186C458CE817101B877222E2A888FDC1AF9FF1D574796022D222C3

44110BE89C382942D7DF19F88ED7419998C4550C4FAB4E4ED4943E7656A8A4BEE390

1CCF49461B5109746341BCDDCA16402FF571A58AB80F3C3538B32105692029432339F

8D1B4C8E649984A23573DDF5A664D3645A5E8C4879861D132BC41D54E30C09F21EB0

04D7D6007A93009F214AFD5199088791964C7789EE8FAF220E76179FD88E906DC9921

A0285181827153AD7FB59CC31EB69B46B6D445057B9AE29FBDDEE83C20420941948

B6F5CBF1AD32E93474E084CDF4487BBAFE685EE58840FF772D8C9F652AD026557A7

78375A54A00F30C7C7A20396F93375BBC3651BF31C23991C1C1E4AB9695B5E4C09F0

27931876390C40061334A230101B6CEBE8C9566D46AC7BE66C5CA79714D5DBCE5E27

44475D270C80C2A211615F602714DDE8EF15F7E0F564A41CB14F9004FD723B416D8B5

6A15BF133B9CAC8D555FBE3F5E8BB295D9A62FAD45E6AD95A3A95104B62E08073D

8F70062E6F36791501A22E1EE3CE80536E132CF98821129C94BD148393D445B697E206

EEFFA837CCE5A1E95903DCE8D459855D15E1FEB5A7FBB335D3B67A2E9C29E93C6C

2A84B10BD96F1964BD1969B3024F37394C821E9A539C0302889B75D6B8BAFE5F6415

85CADA7E0179BA874A546052A0FA77AA6A28C4DE5B976C187E2C54FDEDE150ECB

6C9606B1D02A37D892438

R-APDU:

39D717C623ECC16BCB5BD296FB1BCAC23C3E1C8A6AA128FC6F5D0DF4F47AEEE89

8CF0BC172DF85B4D27F19DE3250216D70D9EDD7D0814EB28BAE3CD75BE3481DB4


80

CED99506BB5472B713E9FF05FB0241B43295D7AF82D0C41FD73B079482F3510FF1580

353002A8A670392237805ECA03EE44AEA2F2325253F3494653D18D2BC57B69A888953

10C97F11B6982B11CF9522D6023840DFA7424AB96B8B1FAF91C50DC1EE1305F752B1

293B18E6CD5D078C4C741F8BAA122F1E2B6548C26933C46F08EB27AFC43964DF18E2

45F7A37392BC529F617E1CFC02D6D3ED7B7D5C47DB3D50358BE0FB233D4A1AA3E5

0D1CE820017453FA524223BF52B70489C6996D2F6D00

C-APDU: A021000000

R-APDU:

9A08F98CA3415626A862CAF5E859D2356996EC112FEF249A656CF2AA2CB2382C2DA

1A3C8AF43681841810AB5714B2F65E7E71C669590E413CB62845E17B4CD757A1779B3

3F1008A36114533178935A4195B9ED412057973D6E64ACA11E9B9880D6EE2DDE3A04

1CC386CF2E2284E9728F94E07546A008E707DED9C6152AE875880AC2AA08AD1C9C9

CDBB06A035DA3B63A84C226A44BFB54F2AFD4EFD7E12A686443573EB9910FF87DD

D07DAF0B4719C030C83F2524AA7FC3F04405A3B676079F973BBFF974C6ED9558D8B

4F18E091C30E07CEEFEDAD4F69CC734D884E6FD18FE41BB0DB4474DD289EBAF2F6

DF1DC84DFA0BD279B9C9B84AF8912FE272A6BDD46D00

C-APDU: A021000000

R-APDU: B2A99000

Step3: get encrypted key entry from JC2 and store in JC1, host <-> JC1

C-APDU:

A012000000020039D717C623ECC16BCB5BD296FB1BCAC23C3E1C8A6AA128FC6F5D

0DF4F47AEEE898CF0BC172DF85B4D27F19DE3250216D70D9EDD7D0814EB28BAE3C

D75BE3481DB4CED99506BB5472B713E9FF05FB0241B43295D7AF82D0C41FD73B079

482F3510FF1580353002A8A670392237805ECA03EE44AEA2F2325253F3494653D18D2B

C57B69A88895310C97F11B6982B11CF9522D6023840DFA7424AB96B8B1FAF91C50DC

1EE1305F752B1293B18E6CD5D078C4C741F8BAA122F1E2B6548C26933C46F08EB27A

FC43964DF18E245F7A37392BC529F617E1CFC02D6D3ED7B7D5C47DB3D50358BE0FB

233D4A1AA3E50D1CE820017453FA524223BF52B70489C6996D2F9A08F98CA3415626

A862CAF5E859D2356996EC112FEF249A656CF2AA2CB2382C2DA1A3C8AF436818418

10AB5714B2F65E7E71C669590E413CB62845E17B4CD757A1779B33F1008A361145331

78935A4195B9ED412057973D6E64ACA11E9B9880D6EE2DDE3A041CC386CF2E2284E

9728F94E07546A008E707DED9C6152AE875880AC2AA08AD1C9C9CDBB06A035DA3B

63A84C226A44BFB54F2AFD4EFD7E12A686443573EB9910FF87DDD07DAF0B4719C03


81

0C83F2524AA7FC3F04405A3B676079F973BBFF974C6ED9558D8B4F18E091C30E07CE

EFEDAD4F69CC734D884E6FD18FE41BB0DB4474DD289EBAF2F6DF1DC84DFA0BD2

79B9C9B84AF8912FE272A6BDD4B2A9

R-APDU: 9000

key architecture and updating protocols in large-scale card-based

Documents