Key structure

4.1.1 Keys in cards to authenticate with a SAM

In an access card in the access control system, at least two applications are present: the default application with AID 0x000000 and the application for the access control. In the user-defined application, personal data for authorization are stored in a standard data file. According to the data, the controller is able to decide whether the user is able to access the resource according to the result of the query to the local database. Besides, to generate the diversified key, another standard data file can be created to store the diversification input.

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

However, to keep the number of defined keys as small as possible to facilitate the key management is necessary. In addition, the access control process does not require writing operation. Only in the initialization phase is writing access necessary. With these concerns, we design the FKs in an application: in the initialization process, all files within an application will use the same diversified key for write access and read/write access; the read-only key should be different from the read/write key.

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

Therefore, a key should be used uniquely for extracting the UID. It is not diversified. With this key, the file that stores the diversification input data can be read. To write the data into the file, the FKs for write access and read/write access are the same as those for the other file.

The key for writing and the key for reading/writing both can write the files. It will not participate in the authentication or authorization process. If the key is desired to be retrievable, the information should be stored only in the backend system. Otherwise, it is unnecessary to store these keys after the initialization. To abandon the key, the write or read/write access of the file can be forbidden through configuration within the protection of AMK or key for change access rights.

37

Similarly, the key for change access rights in the file should be disabled in the same way after the card is personalized. After these changes, the file can only be read in this configuration unless AMK or CK for the application is used.

In addition to the keys for read or write, a CK should be considered. If the AMK is defined as the CK, to update the keys on the card, the master key is required. Since AMK or CMK is also the key to implement other changes, the system will be more vulnerable than the one defining a CK. Thus, we recommend defining an average AK, i.e. the AKs except AK0, to be the change key. Since this key is more powerful than other AKs, it requires better protection. It should be only used when updating the keys, so it is used much less frequently than other AKs. Thus, the diversification key for this change key should be different from that for other AKs.

The structure of the keys in the card is shown in Figure 8. “Div” in the figure means that the key should be diversified. CMK has the authority to do any operations on the card; thus it has the highest security levels. AMK can do any operation within the application, so relatively it requires stricter protection than other AKs. The key for change (AK5), the key for write (AK3) and the key for read/write (AK3) are discarded since generally the data on the cards are not necessarily be changed after issuing. AK2 and AK4 are stored in SAMs for authentication. AK1 is required in key updating.

It should be stored in the updating device.

The card in the figure above is the simplest case in the access control system. Obviously, the card in the figure has only one application and two files. With AK4, it can only be used to authenticate with the SAMs stores the DMK for AK4. However, sometimes it requires the card to authenticate with several SAMs that store different DMKs. More files, applications and keys may be required in the scenario. The possibility and methods will be discussed later.

4.1.2 Symmetric keys in SAMs installed in controllers

To authenticate with a card, a SAM should store AK2 and the DMK of AK4. To update keys on cards, the diversification master key of AK1 should also be stored. Normally in an authentication request, AK2 and AK4 are used. Firstly, the SAM authenticates with the PICC with AK2 to get the

Figure 8 Key structure in the DESFire card

APP: 0x000000 APP: 0xXXXXXX

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

38

diversification input. AK4 can be diversified with the data. Then the SAM uses the diversified AK4 to authenticate with the card. If it succeeds, it gets the read access right of the file in the application.

Other than the keys that are used in communication with the cards, the SAM stores the keys for management purpose and authentication with the host additionally. In the first entry of the sKST stores the SAM master key. Similar to the CMK, authenticating with the SAM master key permits any operation on the undefined entry in sKST and PKI_KST. A host key is stored to authenticate the SAM with the controller. That also implies that the controller, or the host, stores this AES-128 key. To update PICC keys, a host key or an offline change key is needed. We will mainly perform the key updating with the host key, and discuss the offline change key later. The host key in key updating could be the same as the one used to authenticate with the controller. In this way, the controller will know how to update the PICC keys. However, the key stored in the controller is the least secure one in the system. On the other hand, in this thesis, we will propose an additional device, or the JCs, to update the key later. With these concerns, it is recommended to separate the key functions. Another host key is used specifically to update the PICC keys, which is only stored in the backend system, the updating devices and the SAM, but not the controller.

To sum up, the AES keys in a SAM that is used in communication with cards may contain: 1) the SAM master key; 2) a host key(host_key1), which is only used to authenticate with the host mutually;

3) a host key(host_key2), (or an offline change key), which is only used to update keys; 4) a PICC key, which is used to authenticate with AK2 in the cards to extract the UID and other diversification input;

5) a PICC key, the DMK for AK4, which is used to authenticate with AK4 in the cards to get the read permission of the files; 6) a PICC key, the DMK for AK1, which is prepared to change the AKs in cards (optional).

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

4.1.3 Diversification master keys in the system

Ideally, the master keys, including CMK, AMK, and the SAM master key, should be set to a random value at personalization time and should be discarded after the configuration. Consequently, the layout and configuration cannot be changed after issuing or installation. However, due to current limited experience and practice, it is desirable to allow the possibility for changes like creation and deletion. To meet this requirement, the master keys should be retrievable when necessary. To store and retrieve the keys efficiently, these keys should not be the random value but the diversified keys.

They are unique for each card and each SAM.

Other DMKs include the one for AK4 and the one for CK (AK1). These DMKs are unique in each area. In other words, a number of SAMs with different DMKs are used to control different resources.

In different areas, the DMKs could be also the diversified result from another DMK. A chained frame with three-time diversification for the PICC keys is shown in Figure 9. It is a simple example while

39

the diversification times can be set by the system managers according to their situation. All the diversified keys can be generated with this chain, including the SAM master key, the two host keys, the DMK for AK4 and the DMK for AK1. The key used for extracting the diversification input of the card, which is not diversified on the card, can also apply this scheme. Though it is not diversified on the card, each AK2 should be different among areas. Therefore, to generate unique AK2 within each area, the diversification should be conducted.

In the figure, key_0, key_1, key_1’, key_2, key_2’ and key_2’’ are only involved in the generation of other keys. They are not presented in actual access control process. Therefore, these keys are not stored in any SAMs that are integrated in controllers, to participate in the authentication process.

Instead, these keys are only in devices in the backend system and protected carefully. SAM AV2 provides the function to dump PICC keys; it is possible to store these DMKs in particular SAMs in the backend system. If this suggestion is adopted, the key entry in these SAMs should be configured to be able to be dumped. In contrast, SAMs installed in controllers, such as SAM1 and SAM_2 in the figure, should be used specifically to communicate with the cards. Thus, the keys are never necessary to leave the SAMs. It means the key entries should be configured in the way that they cannot be dumped.

Usually, the diversification input may be not confidential or may be easily acquired. In this model, once the key owner receives the input data from its subsidiary, the diversified key can be retrieved. In contrast, the key information is protected in each node. The subsidiary only knows its own key information. The other diversified keys cannot be regenerated by themselves.

This chain can be applied in a practical system. For example, a company C is considering installing an access control system to control the entry of its buildings. It is an international company. The sub-companies distribute around the world. Storing or dynamically requesting the diversification input, the managers at the top level can retrieve all the DMKs easily. The officers in charge of the system in a high level office can regenerate the key information of its sub-offices. While the diversification input is less confidential, the key information is protected strictly.

40

4.1.4 The foreseen impact in case of key compromise

Though SAMs are considered to be the most secure component in the system, as discussed previously in Chapter 3, it is still possible that an attacker is so interested in the keys that he or she explores a way to find the keys. On the other side, keys may be used incorrectly or be impacted accidentally by authorized users. Thus, the impact and countermeasures of the key exposing or losing should be considered to protect the system from collapse. Compromise of different keys has various impacts on the whole system.

 Full access to data stored in any deployed chip in the area the DMK controls

 All card configurations can be changed.

DMK for AMK

 Full access to data stored in the application in any deployed chip within the area the DMK controls

 All configurations in the application can be changed.

DMK for SAM master key

 Configuration in the SAMs within the field can be changed, e.g. enable/disable a new key entry.

 Blank key entry can be updated after enabled.

A SAM

SAM master key All the AKs in cards which generating the diversified key will be compromised.

Host key used to

authenticate the controller

Controllers and SAMs cannot authenticate each other. Either the host or the SAM can be forged in the authorization phase Figure 9 Example of the DMKs in the system

Eindhoven

41 Host key used to change

the PICC keys PICC keys can be changed.

Key to extract UID UID cannot be protected. Cards can be traced.

DMK for AK1 If the UID of the card is also exposed to the attacker, CK in the card is exposed. Then the AKs can be changed.

DMK for AK4

If the UID of the card is also exposed to the attacker, AK4 in the card is exposed. Then the card can be forged. The authentication will succeed.

A DESFire card

CMK  For a particular chip, access to data stored in it is possible.

 For a particular chip, configuration can be changed.

AMK

 For a particular application in a particular chip, access to data stored in it is possible.

 For a particular application in a particular chip, configuration can be changed.

AK1 or AK4  The chip can be forged. The authentication will succeed.

 Retrieving information on the chip is possible