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
Eindhoven, August 2012
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.
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 masters 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.
Contents
Abstract ................................................................................................................................................... 2 Acknowledgement .................................................................................................................................. 3 Glossary .................................................................................................................................................. 7 Chapter 1 Introduction ............................................................................................................................ 9 1.1 1.2 1.3 Nedap Card-based access control system ............................................................................... 9 Project goal ........................................................................................................................... 10 Thesis outline ........................................................................................................................ 11
Chapter 2 Background information....................................................................................................... 13 2.1 Cryptography concepts ......................................................................................................... 13 Symmetric encryption ................................................................................................... 13 Asymmetric encryption ................................................................................................. 13 Message Authentication Code (MAC) .......................................................................... 13 Digital signature ............................................................................................................ 14 Key diversification function.......................................................................................... 14 Public Key Certificates ................................................................................................. 14
2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2
Hardware ............................................................................................................................... 15 Access cards: MIFARE DESFire EV1 8K contactless chip ......................................... 15 SAMs: MIFARE SAM AV2 ......................................................................................... 17 Java cards: JCOP31 v2.4.1 ............................................................................................ 18
2.2.1 2.2.2 2.2.3 2.3
Protections provided by SAMs and DESFire EV1 ............................................................... 19 Hardware protection...................................................................................................... 19 Random UID mode of DESFire .................................................................................... 19 Authentication protocol between a SAM and an access card ....................................... 19 Key classes in SAM ...................................................................................................... 21 Protection modes in SAMs ........................................................................................... 21 Mutual authentication between a controller and a SAM ............................................... 22 Master keys in access cards and SAMs......................................................................... 23 Key diversification ........................................................................................................ 24 Counters in SAM AV2.................................................................................................. 25 Key version ................................................................................................................... 26
2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 2.4
Usage scenarios ..................................................................................................................... 26
Chapter 3 Risk assessment .................................................................................................................... 28 3.1 Threat identification .............................................................................................................. 28
3.1.1 3.1.2 3.1.3 3.2 3.3
Attack purposes ............................................................................................................. 28 Attack sources ............................................................................................................... 28 Threat identification ...................................................................................................... 29
General risk and mitigation ................................................................................................... 29 Risk assessment summary..................................................................................................... 34
Chapter 4 Initialization of the system ................................................................................................... 36 4.1 Key structure ......................................................................................................................... 36 Keys in cards to authenticate with a SAM .................................................................... 36 Symmetric keys in SAMs installed in controllers ......................................................... 37 Diversification master keys in the system ..................................................................... 38 The foreseen impact in case of key compromise .......................................................... 40
4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.3
Initialization of SAMs........................................................................................................... 41 Initialization of cards ............................................................................................................ 42 Pre-personalization of cards .......................................................................................... 43 Personalization of cards ................................................................................................ 43
4.3.1 4.3.2 4.4
DMKs in the zones................................................................................................................ 43 Share a set of DMKs among zones ............................................................................... 44 Manage DMKs separately within each zone ................................................................. 44 Comparison ................................................................................................................... 45
4.4.1 4.4.2 4.4.3 4.5
Access control process .......................................................................................................... 46
Chapter 5 Key updating ........................................................................................................................ 48 5.1 Update PICC keys ................................................................................................................. 48 Prepare the new key in SAM first ................................................................................. 48 Store backup keys on cards ........................................................................................... 52
5.1.1 5.1.2 5.2
Update host keys ................................................................................................................... 53 Update host_key1 .......................................................................................................... 53 Update host_key2 .......................................................................................................... 54
5.2.1 5.2.2 5.3 5.4 5.5
Update PICC keys with an offline change key ..................................................................... 55 Update asymmetric keys ....................................................................................................... 55 Update symmetric keys with asymmetric ones ..................................................................... 56
Chapter 6 Java cards in the access control system ................................................................................ 57 6.1 6.2 6.3 Java cards hierarchy .............................................................................................................. 57 Example ................................................................................................................................ 58 Keys on the Java card............................................................................................................ 58 Unique RSA key pair for each card .............................................................................. 58 5
6.3.1
6.3.2
Share an RSA key pair in one level .............................................................................. 59
Chapter 7 Implementation..................................................................................................................... 60 7.1 7.2 7.3 7.4 7.5 Tools ..................................................................................................................................... 60 Communication between a Java card and a SAM................................................................. 60 An authentication protocol between two JCs ........................................................................ 62 Update the SAM with PKI keys through Java cards ............................................................. 63 Security evaluation................................................................................................................ 64 Verification of the protocol ........................................................................................... 64 Random numbers in the protocol between two Java cards ........................................... 64 RSA algorithms ............................................................................................................. 65 The use of PKI keys in SAMs ....................................................................................... 66 New risks from Java cards ............................................................................................ 66
7.5.1 7.5.2 7.5.3 7.5.4 7.5.5
Chapter 8 Conclusion............................................................................................................................ 67 8.1 8.2 Contribution .......................................................................................................................... 67 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
Glossary
3DES AES AID AK AMK API CA CAD CC CK CMAC CMK CSN CurVal Dec(k, A) DES DF_AID DF_Key DMK EAL EEPROM Enc(k, A) eID ExtSET FID FK hash(A) ISO JC JCRE KeyNo KeyNoC KeyVerC KeyNOCKUC KUC KeyVerCKUC LC MAC PICC PCD PKI PKI_KST PosA Triple DES Advanced Encryption Standard Application Identifier Application Key Application Master Key Application Programming Interface Certification Authority Card Acceptance Device Common Criteria, an international standard (ISO/IEC15408) for computer security certification Change Key Cipher-based MAC Card Master Key Card Serial Number Current Value of the key usage counter Decryption of A with key k Data Encryption Standard DESFire AID DESFire key number Diversification Master Key Evaluation Assurance Level Electrically Erasable Programmable Read-Only Memory Encryption of A with key k Employee identifier Extension configuration setting field File Identifier File Key the hash value of A International Organization for Standardization Java Card Java Card Running Environment Key Reference Number Key Reference Number of Change Entry Key Key Version of Change Entry Key Key Reference Number to change the current KUC Entry Key Usage Counter Key Version to change the current KUC Entry Logical Channel Message Authentication Code Proximity Integrated Circuit Card Proximity Coupling Device Public Key Infrastructure PKI Key Storage Table Position A 7
PosB PosC RefNoKUC RID RndA RndB RndA RndB RF RSA SAM SET Sig(A, k) sKST SW UID Va Vb Vc Ver(h,s,k) protected area access card host authentication
Position B Position C Reference number of Key Usage Counter Random Identifier Random number A Random number B Random number A rotated left over 1 byte Random number B rotated left over 1 byte Radio Frequency The algorithm for public-key cryptography that is firstly publicly described by Ron Rivest, Adi Shamir and Leonard Adleman Secure Application Module Configuration Setting for KST Entry Signature generation on a message A using key k Symmetric Key Storage Table Status Word User Identifier Version of key a Version of key b Version of key c Signature verification on a hash value h, a signature s and a key k The area within the protection of the access control system. Only with successful authentication and authorization process can this area be accessed. The badge used in the access control system to identify a user. In the project, the access card is DESFire EV1. Mutual authentication between the SAM and its host (e.g. the controller, updating devices)
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
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: 10
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 11
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.
12
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 13
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).
14
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 15
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.
Card Level AID=0x000000 CMK(AK0)
Application 1 AMK(AK0)
AK1 AK2 AK3 AK4 AK5
R File 1
RW
RW
FK(change) FK(read)
FK(write) FK(r/w)
File 2
Figure 2 Structure of the contents in a card
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 16
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 cards 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 AES128, 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
17
(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)
18
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 threepass mutual authentication protocol based on two random numbers is used in the protocol (Figure 4). 19
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
20
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.
SAM
KEY k AID
PCD 1)i. RID, AID 1)ii. GetKeyVersion 1)iii. key version 2) Authentication command with key number e1 3)
PICC
KEY k
3-pass mutual authentication begins 4)

RndB = LeftRotate (Deck(e1),1); GENERATE RndA {0,1}128; e2 =
GENERATE RndB {0,1}128; e1 = Enck(RndB)
5) e2
VERIFY RndB: RndA||RndB = Deck (e2); RndB == LeftRotate(RndB,1)?
Enck(RndA||RndB) 6) e3
RndA = Deck (e3); RndA == LeftRotate(RndA,1)?
RndA= LeftRotate(RndA,1); e3 = Enck (RndA)
7) Assemble Session Keys

Figure 4 3-pass Mutual Authentication Protocol
7)
Assemble Session Keys
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 21
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,
22
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.
Host
KEY k
Authentication command with key number, key version, protection mode
SAM
KEY k
mac2 = AES-CMACk (Rnd2||protection mode||0x000000) {0,1}64 GENERATE Rnd1 {0,1}96
Rnd2
GENERATE Rnd2 {0,1}96 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
mac2||Rnd1
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) RndA (e3); kxe RndA= =Dec Dec kxe(e3) RndA == RndA == LeftRotate(RndA,2)? LeftRotate(RndA,2)? GENERATE session keys from RndA and RndB
mac1||e1
GENERATE RndB {0,1}128 e1 = Enckxe(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
Figure 5 Mutual authentication protocol between a controller and a SAM
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 23
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).
Diversification input (1-31 bytes) M Diversification input (1-31 bytes)
Constant 0x01
i. Padding D 32 bytes
ii. Padded {0,1}
DMK: AES-128 key (16 bytes)
DMK iii. AES128-CMAC
Diversified AES-128 key (16 bytes) Figure 6 Block diagram of the diversification algorithm
24
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 25
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.
26
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)).
Zone 3 Zone Zone 2 Zone 1 1 Zone 2 Zone 3 Zone 3 Zone Zone 2
(a)
(b) Figure 7 System structure
(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 leaders office together with all the other buildings are the zone 3. 27
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.
28
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.
Threat Source Computer criminal (external) Table 1 Possible threat sources in the system Motivation Target - Destruction of information - Illegal information disclosure - Monetary gain - Unauthorized data alteration - Blackmail - Destruction - Exploitation - Revenge - Competitive advantage - Economic espionage - Curiosity - Ego - Intelligence - Monetary gain - Revenge - Unintentional errors and omissions cards, readers, SAMs, controllers, backend system Action Fraudulent act Spoofing System attack (passive) Bribery Theft Bomb/Terrorism Information warfare System attack Theft Theft Intrusion on personal privacy System attack Bribery Browsing of proprietary information Computer abuse Theft Bribery System attack Sale of personal information
cards, readers
Terrorist (external)
Industrial spy
Insiders (abused by employees or contractterminated employees)
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
29
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 attackers 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 30
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 todays 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 31
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 Intercept authentication data on radio link Infer secret key through cryptanalysis Replay authentications Extract master authentication keys from a card Extract diversification key from SAMs through sidechannel analysis or fault injection Extract diversification key through chip hacking
Cost [euro] < 1,000 < 1,000 < 1,000 1,000 50,000 5,000 100,000 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
32
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 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. Mitigation or countermeasures - 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. - 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. Use key usage counter and update it periodically, but it is not applied in the current system because of the difficulty to control - Define and implement strict control in the personalization and personalization process. - Choose reliable product providers. - Educate the employees. - Define and implement strict control in the database management. In scope?
A card is stolen/lost without revealing the information on the card
No
Theft
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.
No
A SAM is stolen
Social engineering
The system is hacked in prepersonalization or personalization process
Database and keyrelated information compromisi ng; system abuse
The data in the backend system is compromised
The data in a controller is compromised Too much data are exchanged between a SAM and the controller A card is read by a
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. The attacker has knowledge about the system management information, e.g. CMK, AMK, and so on Sometimes not easy to detect. 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. The specific local database may be modified without authorization. The problem happens in the authorization. SAMs cannot communicate with it securely. The system cannot respond to the authorized card. Unwanted system access.
No
No
No
- Making plans for updating the system (the stored host key). - Educate the employees. - Secure host communication. This is provided by SAM AV2. Audit the system. Prepare the detection method for this kind of attack. Shield the card.
Yes
Denial of service attack Mafia Fraud
No
No
33
attack Replay attack
malicious reader Messages from the authorized components are sent again by malicious ones. Contract-terminated employees can still access the resources
Unwanted system modification.
Use counters and random numbers.
No
System abuse
Unwanted system access.
System abuse
Key abuse
Unwanted system access
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.
- Good and strict management of the database - Good cooperation with human resource department Generate the DMK by several parties; each keeps a part of it without the knowledge of other parts. - 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.
No
Yes
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.
34
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.
35
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.
36
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. APP: 0x000000
AMK (AK0) (Div) AK1 CK (Div)
APP: 0xXXXXXX
AK2 extract UID (no Div) AK3 key for write & read/write (Div) AK5 key for change (Div)
CMK(AK0) (Div)
AK4 key for read (Div)
DESFire EV1
File: 0xYYYY
div_rnd d
File: 0xXXXX
data
Figure 8 Key structure in the DESFire card
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 37
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 38
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 subcompanies 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.
39
Head Office K0
Europe K1 = Div(K0, input_key_1)
Asia K1 = Div(K0, input_key_1)
France K2 = Div(K1, input_key_2) Netherlands K2 = Div(K1, input_key_2) Germany K2 = Div(K1, input_key_2)
Eindhoven SAM1 K3 = Div(K2, input_SAM1)
Amsterdam SAM2 K3 = Div(K2, input_SAM2)
Card1
Kcard = Div(K3, input_card1)
Card2
Kcard = Div(K3, input_card2)
Figure 9 Example of the DMKs in the system
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 DMK for CMK Impact Full access to data stored in any deployed chip in the area the DMK controls All card configurations can be changed. 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. 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. All the AKs in cards which generating the diversified key will be compromised. Controllers and SAMs cannot authenticate each other. Either the host or the SAM can be forged in the authorization phase
Backend system
DMK for AMK
DMK for SAM master key
SAM master key A SAM Host key used to authenticate the controller
40
Host key used to change the PICC keys Key to extract UID DMK for AK1 DMK for AK4
PICC keys can be changed. UID cannot be protected. Cards can be traced. If the UID of the card is also exposed to the attacker, CK in the card is exposed. Then the AKs can be changed. 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. For a particular chip, access to data stored in it is possible. For a particular chip, configuration can be changed. 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. The chip can be forged. The authentication will succeed. Retrieving information on the chip is possible
CMK
A DESFire card
AMK
AK1 or AK4
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 prepersonalization 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.
41
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.
42
4.3.1 Pre-personalization of cards

In the pre-personalization process, cards are updated from blank ones, to be the components in the users 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
43
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 44
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. APP: 0xXXXXXX
File: 0xYYYY
div_rnd d
AMK (AK0 ) (Div)
AK1 CK (Div)
AK2 extract UID (no Div)
AK3 key for write & read/write (Div)
AK4 read: key_1
AK5 key for change (Div)
AK6 read: key_2
AK7 read: key_3
File: 0xXXX1
data
File: 0xXXX2
data
File: 0xXXX3
data
Figure 10 New files and keys in a card to access several zones
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 Administrative Authority 1 1 the number of zones required to enter - Several authorities, with the knowledge of their own zone
45
Key updating Card revocation Keys on SAMs Backend system
easy, simultaneously easy One set, only known by one backend system or manager of the system More operations and storage, more strict security requirement
- The responsibility in each zone is separated, so the risk of abusing the right is reduced. complex, separately separately, more parties involved Several sets. Some key entries may be shared (e.g. host key) 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
46
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.
47
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 48
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 5 PosA DMK_AK4_old PosB DMK_AK4_new PosC (Random) Va 00 Vb 01 Vc 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.
49
Controller and other devices used in the updating
SAM Legal cards with old keys can be authenticated and authorized. Authentication is still possible. Authorization is halted. sKST is updated. The new authentication key is stored
Normal authentication: authenticate with host_key1 Updating begin Stop the normal communication with SAM Authenticate with host_key2 Update the key entry: change PosB into the new key
Back to the normal authentication with host_key1
Begin to record the update period for PICC
Restart the normal communication with SAM
Legal cards with new or old keys can be authenticated and authorized.
Figure 11 Update the SAM to store the new PICC keys
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 50
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 cards 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. SAM Controller and reader Authentication with host_key1 A card is in the field Get key version of AK2 Authentication with the AK2 to extract div_input Store div_input Get key version of the target key DESFire
Authentication begins
If: old version Authentication with the CK SAM_ChangeKeyPICC key data(protected ) Change the key using key data(protected) Counter increment Continue normal access control process
If: new version Normal access control process with the new PICC key
Figure 12 Update of the issued cards
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 51
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 5 PosA (Random) PosB DMK_AK4_new PosC (Random) Va 03 Vb 01 Vc 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.
52
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.
53
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.
54
Controller Stores host_key1 version1 Authenticate with host_key1, version 1
SAM
Store host_key1 version1, version2, version3
Update Replaces version1 by version2
Authenticate with host_key1, version2 Updating devices Stop authentication Stop authentication
Authenticate with host_key2 Update host_key1 Store host_key1 Version2, version3, version4
Authentication with host_key1, version2
Figure 13 Update host_key1
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 55
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 1 1 Up to 3 (for RSA-2048) that can be updated once KeyNoC field in sKST Host key Offline change key It does not matter. The key is permitted to Requirement Host authentication update symmetric keys Offline key activation in the setting Command SAM_ChangeKeyEntry SAM_ChangeKeyEntry PKI_UpdateKeyEntries Change counters? No Yes Yes Reference to the protection mode in host RSA (encryption and Protection Encryption and MAC authentication: plain, signature) MAC or full protection
56
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.
JC3
JC2a
JC2b
JC1b JC1a
JC1c
JC1d
SAM1
SAM2
SAM3
SAM4
Figure 14 Java card hierarchy
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.
57
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. 58
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.
59
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 offcard 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.
60
Javacard
Controller/Host 1. Select applet: 00A40400||Len_AID||AID
SAM
New key(value, number) Change/host key(value, version, number) PRO_MAS
2. KeyNoC||KeyVerC||9000 3. SAM_AuthenticateHost 4. Authentication with the host key
CHANGE_I NS(0xC1) 5. (Succeed) PRO_MAS||9000
6. CLA||INS||P1||P2||01||CLA_SAM
7. enc||mac||9000 8. SAM_ChangeKeyEntry
Figure 15 Communication between a Java card and a SAM
Figure 16 Execution of updating a SAM with the Java card
61
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 JCs 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. 62
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. JC1
(Stores several applets) Applet a2 for communicating with JC2, storing and using JC2_PK Generate rnd {0,1}rnd_len e1 = Enc(JC2_PK,key_no||div_in put||rnd) s1 = Sig(hash(e1), JC1_SK) e1||s1 Select: a2 Select: a1
Terminal
JC2
(Stores several applets) Applet a1 for communicating with JC1, storing and using JC1_PK dmk_newkey, dmk_ck Ver(hash(e1), s1, JC1_PK) = true? key_no||div_input||rnd = Dec(JC2_SK,e1) new_key = Div(div_input, dmk_newkey)
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 e2||s2
change_key = Div(div_input, dmk_ck) e2 = Enc(JC1_PK,new_key|| change key||rnd) s2 = Sig(hash(e2), JC2_SK)
Figure 17 Communication between two Java cards
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 63
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 ProVerifs 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. 64
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. 65
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.
66
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.
67
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.
68
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/jw03-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 : 69
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). http://www.nxp.com/documents/application_note/AN10787.pdf. [26] AN10957 - Generic Access Control Data Model. http://www.nxp.com/documents/application_note/AN10957.pdf. [27] AN10969 - System level security measures for MIFARE installations. http://www.nxp.com/documents/application_note/AN10969.pdf. [28] Application of Attack Potential to Smartcards v2.7: Common Criteria, 2009.
70
Appendix A: command set

A.1 Part of DESFire EV1 command set
Command Authenticate Change KeySettings Set Configuration Change Key Get Key Version Create Application Delete Application Get Application IDs Free Memory Get KeySettings Description MIFARE DESFire EV1 and the other device show in an encrypted way that they possess the same secret(the same key) change the master key settings on MIFARE DESFireEV1 and application level 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 any key stored on the card reads out the current key version of any key stored on the card creates new applications on the card permanently deactivates applications on the card returns the AID of all applications on the card returns the free memory available on the card 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 selects one specific application for further access returns manufacturing related data of the card returns the UID returns the FID of all active files within the currently selected application gets information on the properties of a specific file changes the access parameters of an existing file creates files for the storage of plain unformatted user data within an existing application on the card permanently deactivates a file within the file directory of the currently selected application reads data from Standard Data files or Backup Data files writes data to Standard Data files or Backup Data files
Select Application Get Version GetCardUID Get FileIDs Get FileSettings Change FileSettings Create StdDataFile DeleteFile Read Data Write Data
A.2 Part of SAM AV2 command set

Command SAM_DisableCrypto Description 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. 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. The command is used to load an init vector for the next cryptographic 71
SAM_AuthenticateHost
SAM_LoadInitVector
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
72
PKI_ImportKey
PKI_UpdateKeyEntries
PKI_GenerateSignature PKI_SendSignature PKI_VerifySignature SAM_AuthenticatePICC
SAM_ChangeKeyPICC
supports the CRT format. A successful host authentication in the LC using SAM_AuthenticateHost with a host key is required to execute this command. 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. 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 commands 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. Generates a signature on a hash given as input using one of the two private keys stored in the PKI_KST Returns a pre-computed signature. The returned signature is protected according to the SAM-Host protection in place on the corresponding LC. Verifies the correctness of a signature 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. 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.
73
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.
74
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. -- Secrecy & events. Starting rules: Rule 0: equal:v_109,v_109 (Definition of equal.)
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. 75
-- Secrecy & events. Starting rules: Rule 0: equal:v_173,v_173 (Definition of equal.)
Completing... Starting query not attacker:sk(JCA[]) RESULT not attacker:sk(JCA[]) is true. -- Secrecy & events. Starting rules: Rule 0: equal:v_237,v_237 (Definition of equal.)
Completing... Starting query not attacker:newkey[] RESULT not attacker:newkey[] is true.
76
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; 77
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 78
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 79
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 80
0C83F2524AA7FC3F04405A3B676079F973BBFF974C6ED9558D8B4F18E091C30E07CE EFEDAD4F69CC734D884E6FD18FE41BB0DB4474DD289EBAF2F6DF1DC84DFA0BD2 79B9C9B84AF8912FE272A6BDD4B2A9 R-APDU: 9000
81

Z Chen2012 PDF

Uploaded by

Copyright:

Available Formats

Z Chen2012 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Z Chen2012 PDF

Uploaded by

Copyright:

Available Formats

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

Eindhoven, August 2012

2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2

2.2.1 2.2.2 2.2.3 2.3

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

Chapter 3 Risk assessment .................................................................................................................... 28 3.1 Threat identification .............................................................................................................. 28

3.1.1 3.1.2 3.1.3 3.2 3.3

General risk and mitigation ................................................................................................... 29 Risk assessment summary..................................................................................................... 34

4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.3

4.3.1 4.3.2 4.4

4.4.1 4.4.2 4.4.3 4.5

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

5.1.1 5.1.2 5.2

5.2.1 5.2.2 5.3 5.4 5.5

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

7.5.1 7.5.2 7.5.3 7.5.4 7.5.5

1.1 Nedap Card-based access control system

Figure 1 An 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

AK1 AK2 AK3 AK4 AK5

Figure 2 Structure of the contents in a card

2.2.2 SAMs: MIFARE SAM AV2

2.2.3 Java cards: JCOP31 v2.4.1

Figure 3 Java card system (7)

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

3-pass mutual authentication begins 4)

GENERATE RndB {0,1}128; e1 = Enck(RndB)

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

RndA= LeftRotate(RndA,1); e3 = Enck (RndA)

7) Assemble Session Keys

Assemble Session Keys

2.3.4 Key classes in SAM

2.3.5 Protection modes in SAMs

2.3.6 Mutual authentication between a controller and a SAM

mac2 = AES-CMACk (Rnd2||protection mode||0x000000) {0,1}64 GENERATE Rnd1 {0,1}96

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

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

GENERATE session keys from RndA and RndB

Figure 5 Mutual authentication protocol between a controller and a SAM

2.3.7 Master keys in access cards and SAMs

2.3.8 Key diversification

Output: 16 bytes AES diversified key.

ii. Padded {0,1}

DMK: AES-128 key (16 bytes)

DMK iii. AES128-CMAC

2.3.9 Counters in SAM AV2

2.3.10 Key version