High-level Commands Modelling

The detailed commands modelling aspect is not in the scope of this document because it is strongly inspired from the one of the existing models.

The aim of this section however, is to present the new concepts and the way they improve the existing commands solution.

The commands approach will be an intermediary state between the entities model and the script generation process. This will combine the advantages of the existing approaches: On one hand, the approach would be fully entity oriented but, on the other hand, a modification solution would be provided. This solution could be seen as a “debug” mechanism without the runtime process.

Indeed, after script generation, it would represent the unique solution to make fast modifications without altering the application profile.

This is typically the case when the modification has to be performed on a specific online service for instance. This aspect is not card oriented and should not affect the predefined application profile.

Thus, the new commands approach includes the already existing high-level concepts and improves them by adding all types of “non-card” operations. These non-card operations were implicitly introduced in the previous section. Indeed, during the personalization process, many actions, like cryptogram or MAC computation [OPCS], have to be performed by a remote host or what is commonly called a security device. Moreover, all the key management operations (derivation, translation…) might be done on an off-card device. Let’s consider the typical example of the secure channel initialisation on an open platform card. This high-level operation includes the off-card authentication process: random, cryptogram and first MAC generation made by the host. In the existing commands approach, the flexibility was reached by allowing the user to enter all the parameters related to the secure channel (security level, key sets…).

The new approach however, is designed to allow the user to edit the operation and change the elementary commands inside.

Thus, the new commands model can also reach a low-level concept that is still scripting language independent.

4.2.1 Commands types

In the existing commands approach, the operations supported were operating system oriented (i.e. depending on the card type).

This concept is important but needs to be extended in order to support all the command types described in the following list:

o Crypto command

This type is commonly used for all cryptographic operations: encryption, signature computation… All these commands depend on the security device used during the personalization. Indeed, let’s consider two possible examples: The first security device would be a crypto card and the second one a secure online server.

In the first case, the low level command sent to the security device is an APDU one since the SDE is a smart card. In the second case, the command would be a call to an online service provided by the server.

In both cases, the result required is the same (encryption for instance) but the implementation is different.

o Online service command

The online aspect is an important part in the modelling process since it covers a big part of the key management procedure.

Indeed, in many cases, the cryptographic keys are stored on secure databases and are retrieved during the personalization process. Depending on the online service, the operation could have, like in the case of the cryptographic operations, a similar result but a different call.

That’s why, the same concept is applied to this command type in order to model all kinds of online services and to specialize them according to the implementation.

o Data command

Another operations type, involved during the personalization, is necessary for the data manipulations that precede many other commands.

One example for this aspect is the data derivation performed during the secure channel initialisation [OPCS]. Indeed, this derivation data is computed using the host and card random according to the following schema:

R_card R_host

Derivation Data 1 Derivation Data 2

4B 4B 4B 4B

Figure 11: Derivation data used during the secure channel initialisation

This example shows that a set of data commands (substring, concat…) is necessary to make the model more powerful and easily changeable.

o Operating system command

This type is already available in the existing approaches and is not going to be treated in details. The new concept however is to add a reference to the operating system of the command (since different open platform cards for instance can have the same command name with different APDU parameters). This will ensure the correct script generation during the interpretation of the commands.

4.2.2 High-level command concept

As shown in the following figure, the different commands have a common design concept that does not depend on their type.

Indeed, each command can be seen as black box receiving predefined input parameters and computing output ones. All the parameters are the result of preceding operations, which ensures the coherence of the generated script (this aspect will be treated in details, in the automatic process section).

OP2 OP1

Input Output Input Output

Other Input source

Thus, this approach defines a generic concept that could be used for all command types because it describes all the operations and the parameters needed during the personalization. Moreover, this commands sequence is not scripting language oriented and could be translated according to the personalization platform.