Access control process - Initialization of the system

Chapter 4 Initialization of the system

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

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.

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

employees to update cards should be carefully chosen. Generally, they could be the same as the ones in the initialization which under sufficient protection and surveillance. If SAMs are responsible for the card updating, a series of commands is sent to SAMs from the backend system or controllers to do the updating efficiently and properly.

Since a large number of cards are issued on the system, successful updating on all cards takes some time. Therefore, in the updating period, the new keys are ready for use and should be used for authenticating with the updated cards, while the old ones should not be deleted immediately. Instead, the old keys are still valid until all or most access cards have been updated. After the updating period, the old keys should be revoked in the system. In short, in this scheme, after SAMs are updated, two keys start to exist simultaneously in the system.

The updating process can be divided into three parts:

 Part 1: Update SAMs to store new PICC keys

To start the updating process, a SAM receives the new PICC keys. This is the first step if the fields in the related PICC key entry for other two keys are initialized to random values. It is also possible that the SAM stores the value for the new versions in the initialization process if the system managers have decided the new key. In that case, the SAM has already stored the new keys; thus this step could be skipped if no changes necessary on SAMs. Suppose the key in updating is the DMK of AK4 of cards, we assume the old key is DMK_AK4_old, and the new one is DMK_AK4_new. After this step, the fields that store the keys in the entry are:

KeyNo PosA PosB PosC Va Vb Vc

5 DMK_AK4_old DMK_AK4_new (Random) 00 01 02

Other fields remain the same.

To update PICC keys in a SAM, proper authentication is required. In the key architecture, host_key2 is used specially for updating the PICC key. It is defined as the change key of DMK_AK4 in the sKST. With this configuration, authentication with host_key2 is required before updating the DMK of AK4. The controller may know nothing sensitive about the updating such as the change key and the new key. The new host authentication makes the authentication with host_key1 in the same logic channel (LC) invalid. The controller cannot mutually authenticate with SAMs after the host authentication changes. Therefore, in this short period, the communication between the controller and the SAM may stop temporarily, which means the SAM and the controller that stores the local database cannot receive data from each other. At this moment, the authorization process suspends.

After receiving the new entry successfully, the SAM uses host_key1 to authenticate with the controller again. This process is depicted in Figure 11.

 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.

Update the key entry: change PosB into the new key

sKST is updated.

The new authentication key is stored

Back to the normal authentication with host_key1

Restart the normal communication with SAM

Figure 11 Update the SAM to store the new PICC keys

diversification input data should be firstly extracted. Furthermore, if the key to be changed is a diversified key, e.g. AK4 in the structure, the data are also necessary in the diversification algorithm to generate the new key. Therefore, as a normal access control process, AK2 will be used firstly in the authentication to extract the data. Furthermore, since the card’s authenticity can be ensured by CK, authentication between the SAM and the card with the old key is not necessary. Therefore, the old key can be forbidden to participate in the authentication with SAMs once the updating begins. The process is depicted in Figure 12.

Using SAMs to update cards automatically shortens the validity of the old key significantly. If the system is attacked, the exposed key can be revoked at once in this scheme. Another advantage is less human resources and lower risk in management in the updating. However, most commands in the procedure are controlled and delivered by controllers, which requires more complex implementation

Figure 12 Update of the issued cards

DESFire SAM

Authentication with host_key1

Controller and reader

If: old version

A card is in the field

Get key version of AK2

SAM_ChangeKeyPICC key data(protected )

Change the key using key data(protected)

If: new version Normal access control process with the new PICC key

Counter increment Continue normal access control process Authentication begins

Authentication with the AK2 to extract div_input Store div_input

Get key version of the target key

Authentication with the CK

on the controller. Also, it requires the card holder to hold the card near the reader long enough to finish the whole process. In addition, if the updating for cards is not performed with SAMs but external programs in the backend system, SAMs could store nothing about the change key.

To sum up, these two options are both practical. They can be discussed and determined by the system managers considering requirements from clients.

 Part 3: Revoke the old keys from the system

After a certain period, most cards have been updated. The old keys should be deleted from the system. Another updating of the same key entry in SAM can revoke the invalid keys. Similar as the first step, host_key2 is required as the authentication key again by the updating devices. Then the related field in the key entry will be updated as:

KeyNo PosA PosB PosC Va Vb Vc

5 (Random) DMK_AK4_new (Random) 03 01 02

Finally, the SAM uses host_key1 to authenticate with the controller again to start normal communication.

5.1.2 Store backup keys on cards

If cards store backup keys before SAMs start to use a new key, the new key is possible to be used immediately in the updating. In this situation, the old one is useless immediately without influence on the availability of the system. However, this design requires a double storage on the card for the read keys. Consequently, it cannot be adopted by all the systems. Maximally 9 keys could be defined as read keys in an application. If there are 5 zones or more in the system, according to the key architecture described previously, no adequate space is available for backup keys.

Since each file can be only read by one AK, a backup file should be created under the control of the backup read key. If there is no backup file for the new read key, to enable the backup key as the new authentication key for read access, the key setting in the file has to be updated. This operation requires the authentication with the key for change access in the file, i.e. AK5, which is not stored in SAMs before the updating. Moreover, if the change access has been forbidden after the personalization, the AMK may be required to change the key setting. If this happens, the process is much more complicated than the other scheme while the old keys cannot be abandoned immediately. Firstly, the backup keys are sent to the SAM. Since the new key cannot replace the old one in this case, it should occupy another key entry in the sKST. If the old ones are replaced now, without any changes on cards, the new key cannot get the read access of the files. Secondly, the key for change access is required to authenticate with the card and then change the key setting of the file. The read access key of this file is changed to the backup key.

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.

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

In document z_chen2012.pdf (Page 46-81)