z_chen2012.pdf

(1)

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

(2)

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)

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)

4

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

(8)

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)

(9)

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)

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)

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)

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.

(13)

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)

Amessage authentication code(MAC) is aimed at authenticatingamessage. Sometimes it is called akeyed(cryptographic)hash function. It accepts a keyas input and an arbitrary-length message to be

(14)

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 thesymmetric 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).

(15)

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)

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

(17)

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 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)

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.

(19)

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)

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.

(21)

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

PCD

_PICC

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)

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)

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

RndA’’’ = Deckxe (e3);

RndA’’’ ==

LeftRotate(RndA,2)?

Figure 5 Mutual authentication protocol between a controller and a SAM RndA’’’ = Deckxe(e3)

RndA’’’ ==

(24)

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)

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)

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)

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)

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)

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)

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)

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

z_chen2012.pdf

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

Abstract

Acknowledgement

Contents

Glossary

Chapter 1

Introduction

1.1 Nedap Card-based access control system

1.2 Project goal

1.3 Thesis outline

Chapter 2

Background information

2.1 Cryptography concepts

2.1.1 Symmetric encryption

2.1.2 Asymmetric encryption

2.1.3 Message Authentication Code (MAC)

2.1.4 Digital signature

2.1.5 Key diversification function

2.1.6 Public Key Certificates

2.2 Hardware

2.2.1 Access cards: MIFARE DESFire EV1 8K contactless chip

2.2.2 SAMs: MIFARE SAM AV2

2.2.3 Java cards: JCOP31 v2.4.1

2.3 Protections provided by SAMs and DESFire EV1

2.3.1 Hardware protection

2.3.2 Random UID mode of DESFire

2.3.3 Authentication protocol between a SAM and an access card

2.3.4 Key classes in SAM

2.3.5 Protection modes in SAMs

SAM

PICC

2.3.6 Mutual authentication between a controller and a SAM

2.3.7 Master keys in access cards and SAMs

SAM

Host

2.3.8 Key diversification

2.3.9 Counters in SAM AV2

2.3.10 Key version

2.4 Usage scenarios

Chapter 3

Risk assessment

3.1 Threat identification

3.1.1 Attack purposes

3.1.2 Attack sources

3.1.3 Threat identification

3.2 General risk and mitigation

_PICC