WO2017157859A1

WO2017157859A1 - Duplication process of operational data contained in a source secure element into one or more recipient secure elements allowing, at most, one secure element to be operational at a given time

Info

Publication number: WO2017157859A1
Application number: PCT/EP2017/055858
Authority: WO
Inventors: Denis Pinkas
Original assignee: Dp Security Consulting Sas
Priority date: 2016-03-15
Filing date: 2017-03-13
Publication date: 2017-09-21
Also published as: EP3430552A1; FR3049083A1

Abstract

Process allowing, under the control of one or more trusted migration servers, a copy or a backup of the operational data contained in a source secure element into a recipient secure element where, at any time, at most, one and only one secure element holding the content of the source secure element can be operational at a given time. The process allows to perform: - either a copy of the operational data contained in a source secure element into a recipient secure element, and then, without powering off the two secure elements to continue immediately, in a synchronous mode, with a transition into a non-operational state of the source secure element followed by a transition into an operational state of the recipient secure element, or - a backup of the operational data of a source secure element into one or more recipient secure elements, and then, after powering off the two secure elements, to continue later on, in an asynchronous mode, with a transition into an operational state of one, and only one, of these recipient secure elements by making sure that the source secure element is no more operational.

Description

Duplication process of operational data contained in a source secure element into one or more recipient secure elements allowing, at most, one secure element to be operational at a given time

Technical Field

The present invention is applicable to any type of secure element where it is desirable to duplicate its content into another secure element either for backup purposes, for example, in the event of the loss, of the theft or of the deterioration of the original secure element ; or for an immediate transfer of the content of the original secure element into another secure element, for example, in the event of a change of its physical format, where in both cases, at any time, at most one and only one secure element holding the content of the original secure element can be operational at a given time.

Background Art

Generally, secure elements are delivered pre-personalized by a supplier (or an issuer) and, in the event of loss or of theft, a new secure element will be delivered by the same supplier. The disadvantage is that such a replacement is not instantaneous, but allows to fulfil the required objective, i.e. to provide to the rightful owner, a new secure element with the same content as the one that was initially present. That explains why techniques of controlled duplications of data contained in secure elements have not been developed.

However some secure elements accumulate data (which was thus not present at the time of the initial handing-over) or are delivered without any user data, additional data being accumulated by the owner of the secure element during its use.

The original user data (if any) and the additional data accumulated later on (if any) as well as the internal permanent states of the secure element is called in this document ‘operational data’.

For secure elements which support the FIDO standard, there is originally no user data while pairs of pseudonyms and private keys are accumulated during the life of the secure element (see: https://fidoalliance.org/specs/).
If the secure element which contains these data is lost, stolen or damaged, the user does not have any more an access to the accounts that he could reach using these pseudonyms and these private keys within the framework of U2F (Universal Second Factor) protocol of FIDO.

The process of copying the content of a secure element to another secure element is particularly useful as a complement of an “access method to an on line service by means of access tokens and secure elements restricting the use of these access tokens to their legitimate owner" that is the topic of another patent application.

Indeed, taking into account the fact that, within the framework of this other patent application, a secure element allows, in particular, to obtain access tokens indicating that the owner of the access token is major, it is particularly important to prevent that another secure element containing the same operational data of the first secure element could be created and placed in an operational state and then transmitted to a person who would be minor, because in such a case this person could consequently obtain an access token indicating that she is major, whereas it is not the case.

In other words, if it is allowed for a legitimate owner of a secure element to duplicate its content, only one secure element containing the operational data of the original secure element shall be able to be operational at a given time.

Disclosure of Invention

The objective of the process is to create one or more copies of the operational data contained in one source secure element into one or more other recipient secure elements but to have, at any given time, at most, one and only one secure element in an operational state.

The process includes two variants which allow to perform:

either a copy of the operational data contained in a source secure element into a recipient secure element then to continue immediately, in a synchronous mode, with a transition into a non-operational state of the source secure element followed immediately by a transition into an operational state of this other secure element, or
a backup of the operational data of a source secure element into one or more recipient secure elements, and then to continue, after powering off the two secure elements, in an asynchronous mode, by a transition into a non-operational state of the source secure element followed by a transition into an operational state of one, and only one, of these recipient secure elements.

A given user shall only be able to use at any given time only one such operational secure element. One of the objectives is to prevent a user to duplicate the operational data contained in his operational secure element into another operational secure element and to transmit it to another user.

The process allows to perform:

either a copy of the operational data contained in a source secure element into a recipient secure element, or
as a preventive measure, a backup of the operational data contained in source secure element into one or more other secure elements.

The copy of operational data between secure elements shall be prevented if one of the secure elements has been declared as being lost or stolen.

Each secure element shall be delivered by the manufacturer, the supplier or the customizer of the secure element with the following data:

a public key certificate specific to the secure element,
a private key associated this public key certificate, where the private key and the public key contained in the public key certificate form a single pair,
a public key allowing to authenticate the origin of the messages transmitted by the migration server associated with this secure element.

The public key certificate contains at least information making it possible to know, by the means of a contact to a certificate status server (Cert. status), if the public key contained in the public key certificate specific to the secure element is still valid (using white lists) or has been invalidated (using black lists).
If an operational secure element has been declared as lost or stolen, the public key certificate of this secure element must be revoked by the user as soon as possible. That is applicable for source secure elements as well as for recipient secure elements which would have received a copy of the information contained in a source secure element.

However, since secure elements do not usually possess a reliable clock, they do not have the possibility to check by themselves a revocation date. So it is mandatory to rely upon an on line server, called a “migration server” (MS), which has a clock synchronized with the UTC (Universal Coordinated Time).

Within the framework of this process, the operational data does not flow through the migration servers, but is carried out directly between the secure elements with an encipherment and an integrity control of the exchanged data.

As an option, an address (e.g. a URL) giving access to the migration server associated with the secure element may also be present in the secure element. The address giving access to a migration server of a secure element is optional, because it can be obtained through as means, e.g. it may be deduced from the content of the public key certificate of the secure element or be integrated as an extension in the public key certificate of the secure element.

The process includes two phases:

a copy phase or a backup phase of the operational data contained in an operational source secure element into a recipient secure element placed in a non-operational state, with data confidentiality protection and data integrity protection / detection during the data transfer,
the deactivation of the operational state of the source secure element followed by the activation of the operational state of one, and only one, recipient secure element containing the operational data originally contained in the source secure element.

This second phase has two variants whether it is carried out:

in a synchronous mode, i.e. immediately following the copy phase or a backup phase without powering off the secure elements, or
in an asynchronous mode, i.e. later on, once the backup phase has been completed and once the secure elements have been disconnected.

1. Copy phase or backup phase of the operational data contained in a source secure element into a non-operational recipient secure element

The components of architecture are specified on figure 1 (Fig.1). These components are :

a source secure element A (SE_A), which is a secure element in an operational state containing operational data. This component is numbered 1.
a server or a workstation (S/STA) supporting the secure element A (SE_A). This component is numbered 2.
a recipient secure element B (SE_B), which is initially in an non-operational phase and that is not containing any operational data and which will receive, later on, operational data from the secure element A (SE_A). This component is numbered 3.
a server or workstation supporting the secure element B (SE_B).
This component is numbered 4.
a migration server A (MS_A) associated with the secure element A (SE_A). This component is numbered 5.
a migration server B (MS_B) associated with the secure element B (SE_B). This component is numbered 6.
certificate status Information (Cert Info.). accessible to the migration servers. This component is numbered 7.

Note: In certain cases, there may only be one server or only one workstation supporting the two secure elements.

Note: In certain cases, the migration server associated with the two secure elements may be the same.

The role of these migration servers is to make sure that each of the two secure elements which will be involved in the transfer of the operational data strictly fulfils the constraints associated with the transfer and according to the case:

to authorize or to prohibit the backup or the copy of the operational data from a source a secure element into another recipient secure element, and/or
to authorize or to prohibit the change of status of the secure elements from an operational state into a non-operational state and vice versa.

Each secure element contains at least three data originally loaded by a manufacturer or a customizer of the secure element, namely:

a public key certificate specific to the secure element. This public key certificate materializes the fact that the secure element has the adequate properties for the implementation of this process. It is delivered by a certification authority trusted by the migration servers.
an associated private key,
a public key allowing the secure element to authenticate the origin of the messages generated by the migration server associated with the secure element.

As an option, an address (e.g. a URL) giving access the migration server to which this secure element is associated.

A copy or a backup of the operational data between the secure elements shall only be possible if that the recipient secure element has the adequate properties for the implementation of this process and if does not contain any operational data at the beginning of the copy or backup process.

The fact that the recipient secure element has adequate properties for the implementation of this process is materialized by the fact that it has an
ad- hoc public key certificate delivered by a trusted certification authority, that this public key certificate is within its validity period and is valid (e.g. not revoked).

The copy phase or the backup phase of the operational data from the source secure element (SE_A) towards a non-operational recipient secure element (SE_B) can thus only start if the secure element (SE_B) does not contain any operational data. If the recipient secure element already contains operational data or if the user did not erase it beforehand, the operational data shall be erased and/or reinitialised before the beginning of the copy or of the backup process.

The goal is to prevent from being able to add operational data to operational data that would be already present in a recipient secure element. In this way, at the end of the copy or of the backup process, the content of the operational data in the two secure elements will be identical.

The secure element SE_B verifies that the zone that it will use to store the data communicated by the SE_A is empty or has been re-initialised. If the zone is not empty or has not been re-initialised, an error is returned. The secure element SE_B also contains specific data intended to store a cryptographic checksum value computed on this zone. The secure element SE_B verifies that it is not in an operational state. If this is not the case, it shall be placed beforehand into a non-operational state.

Figure 2 (Fig. 2) illustrates the exchanges between the various components of the system. The dialog starts with a signed Diffie-Hellman key exchange carried out between the operational source secure element (SE_A) and the non-operational recipient secure element (SE_B).

A signed Diffie-Hellman key exchange entails three messages:

a message 1 (M1): a random number "n" and a modulo "p" are exchanged between the SE_A and the SE_B. This message is numbered (M1) on figure 2,
a message 2 (M2): a random number "n" elevated to the secret power "a" by the SE_A, reduced to the modulo "p", a digital signature computed over the previous data using the private key of the SE_A associated with the public key certificate of the SE_A. This message is numbered (M2) on figure 2,
a message 3 (M3): a random number "n" elevated to the secret power "b" by the SE_B, reduced to the modulo "p", a digital signature computed over the previous data using the private key of the SE_B associated with the public key certificate of the SE_B. This message is numbered (M3) on figure 2.

The number of messages can be reduced to two by combining the message 1 (M1) and the message 2 (M2). The message 1 (M1) can be sent at the same time as the message 2 (M2) or the message 3 (M3) combined with the message 1 (M1) can be sent before the message 2 (M2). According to the secure element which takes the initiative of the dialog, the order of the messages 2 (M2) and 3 (M3) can be reversed.

The resulting secret key "k" built using the signed Diffie-Hellmann key exchange is random number "n" elevated to the secret power "ab", the whole being reduced modulo p. A “man in the middle” is unable to compute it.

Each server or workstation supporting a secure element obtains an address (e.g. a URL) giving access the migration server of that secure element. That address can be prefixed and predefined within the framework of a convention or can be deduced from the content of the public key certificate of the secure element or can be integrated as an extension in the public key certificate of the secure element or can be present in the secure element.

So that the migration server can detect replays, a challenge is requested from each migration server by the server or by the workstation supporting the secure element.

The server or the workstation supporting the SE_A sends a request for a challenge (Ch_A Req) to the MS_A and receives in return a challenge A (Ch_A). This challenge A is then relayed by the server or by the workstation supporting the SE_A to the server or the workstation supporting the SE_B.

The server or the workstation supporting the SE_B sends a request for challenge (Ch_B Req) to the MS_B and receives in return a challenge B (Ch_B). This challenge B is then relayed by the server or by the workstation supporting the SE_B to the server or workstation supporting the SE_A.

The SE_B generates a message 4 (M4) that is sent by the server or by the workstation supporting the SE_B to the server or to the workstation supporting the SE_A which is then relayed as message M4_R to the MS_A.

This message 4 (M4) includes the following data:

a message identifier allowing to know that it is a message of type 4,
the challenge A (Ch_A) obtained from the MS_A,
a message 2 (M2) that the SE_B received from the SE_A
(which contains the public key certificate of the SE_A),
the public key certificate of the SE_B,
a digital signature computed over the previous data using the private key of the SE_B.

Alternatively the public key certificate of the SE_B can be placed after the digital signature and this case it does not enter into the computation of the digital signature.

The server or the workstation supporting the secure element SE_A requests a challenge to the MS_B which provides in return a challenge B which is then transmitted to the SE_A.

The SE_A then generates a message 5 (M5) which is sent by the server or by the workstation supporting the SE_A to the server or the workstation supporting the SE_B which is then relayed as message M5_R to the MS_B.

This message 5 (M5) includes the following data:

a message identifier allowing to know that it is a message of type 5,
the challenge (Ch_B) obtained from the MS_B,
a message 3 (M3) that the SE_A received from SE_B
(which contains the public key certificate of the SE_B),
the public key allowing to authenticate the origin of the messages issued by the MS_A,
the public key certificate of the SE_A,
as an option, an address (e.g. a URL) giving access the MS_A,
a digital signature computed over the previous data using the private key of the SE_A.

Note: the URL giving access the MS_A and/or the public key certificate of the SE_A can also be placed after the digital signature and in this case it does not enter into the computation of the digital signature.

These messages are sent and received by the server or by the workstation supporting the secure element. It is obvious that the order of the messages 4 (M4) and 5 (M5) can be reversed.

Each message is then sent by the secure element to its migration server.

The MS_A server verifies that it is indeed a message of type 4, that the challenge which is present is identical to the one it has just sent, that the public key certificate of the SE_A is delivered by a trusted certification authority, that this certificate has the adequate properties for the implementation of this process, that it is during its validity period and that it is valid (e.g. not revoked) using the messages 6 (M6) and 7 (M7) that are sent to a server holding certificate statuses (Cert. status).

It also verifies that the message 2 (M2) which is contained in this message 4 (M4) is correctly signed by the public key contained in the public key certificate of the SE_B, that the public key certificate of the SE_B is a certificate issued by a trusted certification authority, that is has the adequate properties for the implementation of this process, that it is during its validity period and that it is valid (e.g. not revoked).

It also verifies that the whole data set is correctly signed using the private key corresponding to the public key certificate of the SE_A.

Following the reception and the checking of a message of type 4, the MS_A server stores in a data entry the following data:

the public key certificate of the SE_A,
the public key certificate of the SE_B,
an indicator specifying the operational state of the SE_B, and in this case this indicator is positioned to indicate a non-operational state,
the public key allowing to authenticate the origin of the messages issued by the migration server (MS_B) of this SE_B.

Note: the date of the writing or/and the date of the modification of each entry can advantageously be added in order to be able to know the date of the event.
In no case, a data entry relative to the SE_A shall be removed by the MS_A before the end of the validity period of the public key certificate of the SE_A.

If the first data of a data entry already contains the public key certificate of the SE_A, a new entry shall be added afterwards. This information makes it possible to identify the recipient secure elements which got a copy or a backup of the operational data of a given source secure element.

It should be observed that the operational data contained in one source secure element can be backed up into more than one recipient secure elements.

As it will be explained later on, these entries will make possible to control and carry out the change into an operational state of one, and only one, recipient secure element to which the operational data of the SE_A will have been transferred beforehand.

In the same way, the server MS_B verifies that it is indeed a message of type 5, that the challenge which is present is identical to the one which it has just sent, that the public key certificate of the SE_B is delivered by a trusted certification authority, that this certificate contains the adequate properties for the implementation of this process, that it is during its validity period and that it is valid (e.g. not revoked) using the messages 8 (M8) and 9 (M9) that are sent to a server holding certificate statuses (Cert. status). It also verifies that the message 3 (M3) which is contained in this message 5 (M5) is correctly signed by the public key contained in the public key certificate of the SE_A, that the public key certificate of the SE_A is a certificate issued by a trusted certification authority, that it has the adequate properties for the implementation of this process, that it is during its validity period and that it is valid (e.g. not revoked).

It also verifies that the whole data set is correctly signed using the private key corresponding to the public key certificate of the SE_B.

Following the reception and the checking of a message of type 5, the MS_B server stores in a data entry the following data:

the public key certificate of the SE_B,
the public key certificate of the SE_A,
the public key allowing to authenticate the origin of the messages issued by the migration server of SE_A (MS_A).

As an option, the URL giving access the migration server of SE_A (MS_A) can also be stored.

In no case, a data entry relative to the SE_B shall be removed before the end of the validity period of the public key certificate of the SE_B.

Note: the date of the writing or/and of the modification of each entry may be added in order to know the date of the event.

If the first data of a data entry already contains the public key certificate of the SE_B, a new entry shall be added afterwards. It can be observed that the same secure element can successively be carrying operational data of various secure elements. The last entry (or the more recent entry) makes it possible to identify the source secure element of the last operational data copied into a given recipient secure element. These data will be used later on to control the changes of the operational states, in order to make sure that a secure element SE_B which is a candidate to obtain an operational state is still indeed carrying the operational data which it received from the SE_A.

The public key certificate of the SE_A makes possible for the MS_B to specify to the MS_A the source secure element which may be concerned by a deactivation operation.

The public key allowing to authenticate the origin of the messages transmitted by the MS_A, and the address (e.g. a URL) giving access the MS_A makes possible for the MS_B to contact the MS_A and to make sure that it is indeed connected with the MS_A.

Note: The order of the verification of messages 4 (M4) and 5 (M5) can be reversed.

The migration server MS_A then returns to the server or to the workstation supporting the secure element SE_A that contacted it a message 10 (M10) which contains:

a message identifier allowing to know that it is a message of type 10,
data allowing to detect replays,
an agreement indicator for the transfer of the operational data between the secure elements, and
a digital signature computed over the previous data using the private key of the MS_A.

The data allowing to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a single data already present in a previous message. As an example, a data allowing to detect replays in message 6 (M6) can be data already present in message 4 (M4), such as the value of the digital signature computed using the private key of the SE_A. A convention shall be defined between the secure element and its migration server to determine which is the data making possible to detect replays.

The SE_A verifies that the message that it received from the MS_A is indeed a message of type 10 and that the value making possible to detect replays has the expected value. The SE_A verifies the digital signature of the message using the public key of the MS_A.

If the digital signature is correct, the SE_A verifies the presence of the agreement indicator for the transfer of the operational data between the secure elements.

The migration server MS_B returns to the server or to the workstation of the secure element SE_B which contacted it a message 11 (M11) which contains:

a message identifier allowing to know that it is a message of type 11,
data allowing to detect replays,
an agreement indicator for the of the transfer of the operational data between the secure elements, and
a digital signature computed over the previous data using the private key of the MS_B.

The data allowing to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, it can be a single data already present in a previous message. As an example, data allowing to detect replays in message 11 (M11) can be data already present in the relayed message 5 (M5_R), such as value of the digital signature computed using the private key of the SE_A.

A convention shall be defined between the secure element and its migration server to determine which is the data making possible to detect replay.

The SE_B verifies that that the message that it received from the MS_A is indeed a message of type 11 and that the value making possible to detect replays has the expected value. The SE_B verifies the digital signature of the message using the public key of the MS_B.

If the digital signature is correct, the SE_B verifies the presence of the agreement indicator for the transfer of the operational data between the secure elements.

In the same way, the SE_A verifies that the message that it received is indeed a message of type 10 and that the value making possible to detect replays has the expected value. The SE_A verifies the digital signature of the message by means of the public key of the MS_A.

Each secure element announces to the other that is ready to begin the transfer of the operational data. This transfer is carried out by means of messages exchanged directly between the two secure elements via the servers or the workstations supporting these secure elements.

Figure 3 (Fig.3) illustrates the exchanges carried out between the two secure elements. It is a succession of n exchanges numbered E1, E2,
until E1n and E2n. Each message entails a message identifier making it possible to know that it is a message of type “transfer of operational data”.

The operational data of the SE_A are transferred to the SE_B:

enciphered using the key "k" or a key derived from the key "k", and
integrity protected using the key "k" or a key derived from the key "k".

The secret key "k" is the key which was built during the Diffie-Hellmann key exchange: it is the random number "n" elevated to the secret power "ab", the whole being reduced modulo "p".

The received data is deciphered by the SE_B before being stored in the SE_B.

In order to make sure that no message is removed during the transfer, a cryptographic checksum is progressively computed while the data is being transferred (Fig. 3). The SE_B verifies that the value of the final cryptographic checksum that is sent is equal to the one that it has locally computed.

If this is not the case, the whole of the data already transferred on the SE_B is erased. A new transfer of the data may however be attempted.

If this is the case, the operational data which was present in the SE_A is now present in the SE_B. The SE_B uses an internal indicator to memorize the fact that it contains the full set of the operational data of another secure element.

At this stage, the SE_B is still in a non-operational state.

2. Phase of setting the source secure element in a non-operational state followed by the transition to an operational state for the recipient secure element containing the operational data that has been transferred to it

Beforehand, it is recalled that during a transfer of operational data between secure elements:
(a) the migration server to which is associated the source secure
element has been able to memorize data making possible to know to
which secure element(s) the operational data of this source secure
element has been transferred (making the assumption that the
transfer of the operational data has been successfully accomplished),
and
(b) the migration server to which is associated the recipient secure
element has been able to memorize data making possible to know
from which secure element(s) the operational data of this recipient
secure element has been received (making the assumption that the
transfer of the operational data has been successfully accomplished).

In the case (a), the data that has been memorized for a source secure element (SE_A) is one or more data entries composed of :

the public key certificate of a secure element (SE_A),
the public key certificate of a SE_B,
the public key allowing to authenticate the origin of the messages sent by the MS_B,
an indicator specifying if this SE_B is in an operational state or in a non-operational state.

In the case (b), the data that has been memorized for a recipient secure element (SE_B) is one or more data entries composed of:

the public key certificate of a secure element (SE_B),
the public key certificate of a SE_A,
the public key allowing to authenticate the origin of the messages sent by the MS_A.

For the MS_A, each entry allows to know towards which recipient secure element(s) the operational data of this source SE_A has been transferred.

For the MS_B, each entry allows to know from which source secure element(s) the operational data has been transferred to this recipient SE_B.

In order to allow the SE_B to switch into an operational state, it is first necessary to place the SE_A in a non-operational state. There are two ways so that the SE_A can switch from an operational state to a non-operational state:

to carry out a setting into a non-operational state for the SE_A with a direct dialog between the SE_A and the SE_B, or
to carry out a setting in non-operational state for the SE_A without a dialog with the SE_A. In this case, the owner of the secure element must beforehand ask for the invalidation (e.g. the revocation) of the public key certificate of the secure element which it used.

2.1. Setting in an operational state of a recipient secure element of operational data in an synchronous mode with a dialog between the SE_A and the SE_B
The process that is described hereafter is always immediately performed after the copy of the operational data contained in the SE_A into the SE_B, without powering off the SE_A, nor the SE_B. It thus requires the physical presence of the SE_A and is carried out without the checking of the validity of the certificate of the SE_A since the non-revocation of the public key certificate of the SE_A has already been checked before the beginning of the copy of information of the SE_A towards the SE_B, it is thus not necessary to check it once again.

It is thus recalled that the two secure elements still share a secret key "k" which is a random number "n" exchanged in the beginning elevated to the secret power "ab", the whole being reduced modulo p.

The process has two variants. In the first variant, the MS_A is directly contacted by the SE_A, while in the second variant, the MS_A is indirectly contacted by the SE_A via the SE_B and the MS_B.

2.2.1. Variant 1: the MS_A is directly contacted by the SE_A

The recipient secure elements of the operational data will only be able to switch into an operational state after having received an approval from the migration server to which of the source secure element is associated.
This variant is a simplified process that shall never be used if one of the two secure elements support the process of a transition into an operational state using the asynchronous mode, because the MS_B does not track the operational state changes of the recipient secure elements.

Figure 4 (Fig. 4) which is placed chronologically after figure 3 (Fig. 3) illustrates the exchanges between the various components of the system.

The SE_A sends to the MS_A a message 12 (M12) which contains:

a message identifier allowing to know that it is a message of type 12,
data allowing to detect replays,
the public key certificate of the SE_A,
a digital signature computed over the previous data using the private key of the SE_A.

Note: the public key certificate of the SE_A can also be placed after the digital signature and this case it does not enter into the computation of the digital signature.

Note: It is not required to encipher this exchange.

The data allowing to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a single data already present in a previous message, as an example, the digital signature present in message 10 (M10),

The MS_A verifies that message 12 (M12) it received is indeed a message of type 12, that is not a replay of a previous message and that is correctly signed by the SE_A.

In an entry that contains in its first element the certificate of the SE_A, it examines the second element looking for an element that contains the value of the public key certificate of the SE_B. If this entry is not found, then an error message is returned to the SE_A. Otherwise, the MS_A modifies the indicator specifying whether the secure element SE_B is or not in an operational state and positions it into an “operational” state".

In practice, the MS_A anticipates this change of the operational state, because the SE_B only will become operational after the reception and the processing of the message 14 (M14).

The MS_A sends to the SE_A a message 13 (M13) which contains:

a message identifier allowing to know that it is a message of type 13,
data allowing to detect replays,
an agreement indicator for the setting of the SE_B into an operational state,
a digital signature computed over the previous data using the private key of the MS_A.

The data allowing to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a data already present in a previous message, for example, the digital signature present in message 12 (M12).

The SE_A verifies:

that the message which it received is indeed of a message of type 13,
that the data allowing to detect replay has the expected value,
that the agreement indicator for the passage into an operational state of the SE_B is present,
that the digital signature is valid by using the public key of the MS_A.

The SE_A then places itself into a non-operational state and authorizes the change of the operational state of the SE_B into an operational state by means of the message 14 (M14) which is composed of:

a message identifier allowing to know that it is a message of type 14,
data allowing to detect replays,
an agreement indicator for the setting of the SE_B into an operational state,
a cryptographic checksum computed over the previous data using the secret key "k" or a key derived from the key "k".

Note: It is not required to encipher this exchange.

The data allowing to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a data already present in a previous message, for example, the cryptographic checksum computed over the last exchange of the operational data between the two secure elements.

The SE_B verifies that the message it received is indeed a message of type 14 and that the value making possible to detect replays has the expected value. Using the secret key "k" or a key derived from the key "k", the SE_B verifies that the message contains the expected cryptographic checksum. It verifies the presence of the agreement indicator for the transition into an operational state and then places itself into an operational state.

2.2.2. Variant 2: the MS_A is indirectly contacted by the SE_A

A recipient secure element shall only be able to transit into an operational state after its MS_B has received the approval of the migration server associated with the source secure element SE_A.

The messages are exchanged immediately after the copy of the operational data contained in the SE_A into the SE_B, without powering off the SE_A or the SE_B.

The data making possible for the MS_B to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a data already present in a previous message, for example, the digital signature contained in the message 11 (M 11) that has been sent by the MS_B to the SE_B. When an additional exchange is being used, the SE_B first requests a challenge (Ch_B Req) to the MS_B and receives back a challenge called Ch_B.

Figure 5 (Fig. 5) which is chronologically placed after figure 3 (Fig. 3) illustrates the other exchanges between the various components of the system.

The SE_B sends to the SE_A a message 15 (M15) which contains:

a message identifier allowing to know that it is a message of type 15,
data allowing the MS_B to detect replays,
a cryptographic checksum computed over the previous data using the secret key "k" or a key derived from the key "k".

The SE_A verifies that the message it received is indeed a message of type 15 and using the secret key "k" or a key derived from the key "k",
the SE_A verifies that the message contains the expected cryptographic checksum. It then places itself into a non-operational state.

The SE_A sends to the SE_B a message 16 (M16) which contains:

a message identifier allowing to know that it is a message of type 16,
data allowing both the MS_B and the SE_B to detect replays,
the public key certificate of the SE_A,
an indicator stating that the SE_A has been placed into a non-operational state,
a digital signature computed over the previous data using the private key of the SE_A.
a cryptographic checksum computed on the previous data using the secret key "k" of a key derived from the key "k".

Note: It is not required to encrypt this exchange.

The SE_B verifies that the message 16 (M16) that it received is indeed a message of type 16 and that the value making possible to detect replays has the expected value. Using the secret key "k" of a key derived from the key "k", the SE_B verifies that the message contains the expected cryptographic checksum.

Since it is necessary to centralize at the level of a migration server (the MS_A) the changes of operational states of the source secure elements, the exchanges continue to signal to the MS_A that a given SE_B wishes a transition into an operational state. Additional messages are thus needed to be exchanged to support this variant.

The server or the workstation supporting the SE_B connects to the MS_B and requests a challenge to the MS_B (Ch_B req). The server or the workstation supporting the SE_B communicates this challenge B (Ch_B) to the SE_B.

The SE_B sends to the MS_B a message 17 (M17) which contains :

a message identifier allowing to know that it is a message of type 17,
the message 16 (M16),
the challenge (Ch_B) received from the MS_B allowing to detect replays,
the public key certificate of the SE_B,
a digital signature computed over the previous data using the private key of the SE_B.

The MS_B verifies that:

the message is indeed a message of type 17,
the challenge contained in the message 17 (M17) corresponds to the challenge (Ch_B) that has been sent,
the message 17 (M17) contains the expected digital signature using the public key of the SE_B.

The MS_B then verifies that :

the message that is included in the message 17 (M17) is indeed a message of type 16,
the challenge contained in the message 16 (M16) corresponds to the challenge (Ch_B) that has been sent,
the message 16 (M16) contains the expected digital signature using the public key of the SE_A.

The MS_B then extracts from the message 16 (M16):

the message identifier allowing to know that it is a message of type 16,
data allowing to detect replays,
the public key certificate of the SE_A,
an indicator stating that the SE_A has been placed into a
non-operational state,
a digital signature computed over the previous data using the private key of the SE_A.

The MS_B then verifies that that the message that it received is indeed a message of type 16 and that the value making possible to detect replays has the expected value. The MS_B verifies the digital signature of the message using the public key certificate of the SE_A.

The MS_B browses through the entries that it has memorized looking for entries containing the public key certificate of the SE_B and recovers from the last entry:

the public key certificate of a SE_A,
the public key allowing to authenticate the origin of the messages issued by the migration server of SE_A (MS_A).

By means of the messages 18 (M18) and 19 (M19) addressed to a certificate status server (Cert. status), the MS_B verifies that both the public key certificate of the SE_A and the public key certificate of the SE_B are issued by a trusted certification authority, that they have the adequate properties for the implementation of this process, that they are within their validity period and that they are valid (e.g. they have not been revoked).

If all these verifications are satisfied then the MS_B connects to the MS_A using an address (e.g. a URL) allowing to access the MS_A associated with this SE_A and requests a challenge (Ch_A Req) to the MS_A.

The MS_B sends to the MS_A a message 20 (M20) which contains:

a message identifier allowing to know that it is a message of type 20,
the challenge A (Ch_A) generated by the MS_A,
the public key certificate of the SE_A,
the public key of the MS_B,
a digital signature computed over the previous data using the private key of the MS_B.

Note: the public key of the MS_B can also be placed after the digital signature and in this case it does not enter into the computation of the digital signature.

The MS_A verifies that the message that it received is indeed a message of type 20 and that challenge A contained in message 20 (M20) is identical to the challenge which it had sent. If this is not the case, an error is returned.

The MS_A verifies the digital signature of message 20 (M20) using the public key of the MS_B contained in this entry. If the verification is not conclusive, an error is returned.

The MS_A extracts from the message 20 (M20) the public key certificate of the SE_A and makes sure that the public key certificate of the SE_A has already been memorized. If this is not the case, an error is returned.

By means of the messages 21 (M21) and 22 (M22) addressed to a certificate status server (Cert. status), the MS_A verifies that the public key certificate of the SE_A is valid (e.g. it has not been revoked).

The MS_A examines all the entries associated with the certificate of the SE_A. If anyone entry already contains an indicator specifying that a secure element moved into an operational state, an error is returned.

The MS_A recovers the entries associated with the certificate of the SE_A, i.e. one or more entries, each entry being composed of:

the certificate of a SE_A,
the certificate of a SE_B,
an indicator specifying whether this SE_B is or is not operational,
the public key allowing to authenticate the origin of the messages issued by the MS_B of this SE_B.

It looks for the last entry containing the certificate of this SE_B. If this certificate does not appear in any entry, an error is returned. In that entry, the MS_A modifies the indicator specifying the operational state of the SE_B and places it into an operational state. In practice, the MS_A anticipates this change of state, because the SE_B only will become operational after the reception and the processing by the SE_B of the message 24 (M24).

The MS_A sends to the MS_B a message 23 (M23) which contains:

a message identifier allowing to know that it is a message of type 23,
data allowing to detect replays,
the public key certificate of the SE_B,
an agreement indicator for the transition into an operational state of the SE_B,
a digital signature computed over the previous data using the private key of the MS_A.

The data allowing to detect replays shall be unique data already present in the previous message, for example, the digital signature present in the message 20 (M20), or a data sent specifically to this end in an additional message.

The MS_B verifies that the message that it received is indeed a message of type 23 and that the value making possible to detect replays has the expected value. The MS_B verifies that the digital signature is correct. The MS_B then indicates to the SE_B that it is authorized to switch into an operational state using the message 24 (M24).

The MS_B sends to the SE_B a message 24 (M24) which contains:

a message identifier allowing to know that it is a message of type 24,
data allowing to detect replays,
the public key certificate of the SE_B,
an agreement indicator for the switching into an operational state of the SE_B,
a digital signature computed over the previous data using the private key of the MS_B.

The data allowing to detect replays shall be unique data already present in the previous message, for example, the digital signature present in the message 17 (M17), or a data sent specifically to this end in an additional message.

The SE_B verifies that the message that it received is indeed a message of type 24 and that the value making possible to detect replays has the expected value and that the value of the public key certificate of the SE_B matches with its own public key certificate. The SE_B verifies that the digital signature of message 24 (M24) is correct. If this is not the case, an error is returned. If this is the case, the SE_B switches into an operational state.

2.1. Setting into an operational state of a recipient secure element SE_B using the asynchronous mode without any dialog with the SE_A

Figure 6 (Fig. 6) illustrates the exchanges between the various components of the system.

The SE_B verifies itself that it is in a non-operational state and that it contains a full transfer of backed up operational data by verifying the presence of an internal indicator that memorizes the fact that it contains the full set of the operational data of another secure element. If these verifications are unsuccessful, then an error is returned by the SE_B.

The server or the workstation supporting the SE_B connects to the MS_B and requests a challenge to the MS_B by means of a message (Ch_B Req). The server or the workstation supporting the SE_B communicates this challenge B to the SE_B by means of a message (Ch_B).

The SE_B generates to the attention of the migration server MS_B a message 25 (M25) which contains:

a message identifier allowing to know that it is a message of type 25,
the challenge B (Ch_B),
the public key certificate of the SE_B,
a digital signature computed over the previous data using the private key of the SE_B.

Note: the public key certificate of the SE_B can also be placed after the digital signature and in this case it does not enter into the computation of the digital signature.

The MS_B verifies that:

the message which it received is indeed a message of type 25,
the challenge Ch_B corresponds to the one that has just been sent,
the public key certificate of the SE_B has been issued by a trusted certification authority, that it has the adequate properties for the implementation of this process, that it is during its validity period,
by means of the messages 26 (M26) and 27 (M27) that public key certificate of the SE_B is valid (e.g. not revoked),
the digital signature is valid, using the public key contained in the public key certificate of the SE_B.

If anyone of these conditions is not verified, an error message is returned to the SE_B. The MS_B browses through the entries that it memorized looking for an entry containing in the first element of the entry the public key certificate of the SE_B. If such an entry is missing, an error message is returned to the SE_B.

The MS_B recovers the last entry associated with the certificate of the SE_B which shall at least contain:

the public key certificate of a SE_B,
the public key certificate of a SE_A,
the public key allowing to authenticate the origin of the messages transmitted by the MS_A associated with this SE_A.

The MS_B verifies that the public key certificate of the SE_A has been issued by a trusted certification authority, that it has the adequate properties for the implementation of this process, that it is during its validity period. By means of the messages 26 (M26) and 27 (M27) addressed to a certificate status server (Cert. status), the MS_B verifies that the public key certificate of the SE_A is no more valid (e.g. it has been revoked) and that the public key certificate of the SE_B is valid (e.g. it has not been revoked). If these verifications are not carried out successfully then an error message is returned to the MS_B and then after to the SE_B.

If all these verifications are satisfied, then the server MS_B contacts the MS_A using an address (e.g. a URL) giving access the MS_A associated with this SE_A.

The MS_B requests a challenge to the MS_A (Ch_A Req). The MS_A communicates this challenge A (Ch_A) to the MS_B.

The MS_B generates for the MS_A a message 28 (M28) which contains:

a message identifier allowing to know that it is a message of type 28,
the challenge A (Ch_A) generated by the MS_A,
the public key certificate of the SE_A,
the public key certificate of the SE_B,
the public key of the MS_B,
a digital signature computed over the previous data using the private key of the MS_B.

The MS_A verifies that the message that it received is indeed a message of type 28 and that the challenge contained in the message 28 (M28) is identical to the challenge (Ch_A) which it has sent. The MS_A verifies the digital signature using the public key of the MS_B. If one of these verification fails, an error message is returned to the MS_B and then after to the SE_B.

The MS_A browses through the entries which it memorized looking for an entry containing in the first element of the entry the public key certificate of the SE_A. If this entry is missing, an error message is returned to the MS_B and then after to the SE_B.

If this entry is present, it makes sure by means of messages 29 (M29) and 30 (M30) addressed to a certificate status server (Cert. status) that the certificate of the SE_A is no more valid (e.g. it has been revoked) and that the certificate of the SE_B is valid (e.g. it has not been revoked). If this is not the case, an error message is returned to the MS_B and then after to the SE_B.

So that the MS_A can authorize the transition of the SE_B into an operational state, it is necessary that no other secure element containing the data of this SE_A already switched into an operational state. To this end, the MS_A examines all the entries associated with the certificate of the SE_A. If anyone of these entries contains an indicator specifying in the third element of the entry that a recipient secure element already switched into an operational state, an error message is returned to the MS_B and then after to the SE_B.

The MS_A looks for an entry containing in the second element of that entry the certificate of the recipient secure element SE_B as contained in the message 28 (M28). If this certificate does not appear in any entry, an error message is returned to the MS_B and then after to the SE_B.

In the entry that contains the value of the public key certificate of the SE_B, the MS_A modifies the indicator specifying the operational state of the SE_B and positions it to indicate an operational state. In practice, the MS_A anticipates this change of state, because the SE_B will only become operational after the reception and the processing of a further message, message 32 (M32).

The MS_A then sends to the MS_B a message 31 (M31) composed of the following data:

a message identifier allowing to know that it is a message of type 31,
data allowing to detect replays,
the public key certificate of the SE_B,
an agreement indicator for the setting into operational state the SE_B,
a digital signature computed over the previous data using the private key of the MS_A.

The data allowing to detect replays shall be unique data already present in the previous message, for example, the digital signature present in the message 28 (M28), or a data sent specifically to this end in an additional message.

The MS_B verifies that the message that it received is indeed a message of type 31 and that the value making possible to detect replays has the expected value. The MS_B also verifies that the digital signature is correct using the public key of the MS_A. If one of these verifications fails, an error message is returned to the MS_A and another one to the SE_B.

Otherwise, the MS_B then indicates to the SE_B that it is authorized to switch into an operational state.

For that purpose, the MS_B sends to the SE_B a message 32 (M32) composed of the following data:

a message identifier allowing to know that it is a message of type 32,
data allowing to detect replays,
the public key certificate of the SE_B,
an agreement indicator for the switching into an operational state of the SE_B,
a digital signature computed over the previous data using the private key of the MS_B.

The data allowing to detect replays will be unique data already present in the previous message, as an example, the digital signature present in message 25 (M25) or a data sent specifically to this end in an additional message.

The SE_B verifies that the message that has been received is indeed a message of type 32 and that the value making possible to detect replays has the expected value and that the value of the public key certificate of the SE_B matches with its own public key certificate. The SE_B also verifies that the digital signature is correct using the public key of the MS_B. If this is not the case, an error is returned. If this is the case, the SE_B switches itself into an operational state.

If only the process of the switching into an operational state in a synchronous mode is supported by both the source and the recipient secure elements, then it is not essential to inform the MS_A of the switching into an operational state of the SE_B and messages 12 (M12) and 13 (M13) can then be omitted (See Figure 4).

In this case, an order is addressed to the SE_A so that it is placed into a non-operational state and the SE_A then authorizes the transition of the SE_B into an operational state by means of the message 14 (M14).

3. New backups are then strongly recommended

Once a SE_B became operational, it is strongly recommended that the user carries out as soon as possible a backup of the data contained in the new secure element into one or more other secure elements. If other backups of the SE_A have been performed on other recipient secure elements, unless the operational data contained in these recipient secure elements is deleted, these secure elements are not usable anymore for back up or recovery purposes.

4. Advantages of the process

Making the assumption that all the exchanges were successfully accomplished, it is possible to know whether a secure element has participated to a copy or to a backup process and if it is the case :

by querying the migration server associated with a source secure element (e.g. MS_A) to know towards which recipient secure element(s) the content of that source secure element has been transferred and whether the operational state of that source secure element has or has not been transferred to one of these recipient secure elements, and /or
by querying the migration server associated with a recipient secure element (e.g. MS_B) to know from which source secure element(s), operational data has been successively transferred into a given recipient secure element.

The audit of the operations of backup, copy and switching into an operational state is thus ensured. This audit may be particularly useful if one of the secure elements containing a backup copy of the operational data from the legitimate owner of a secure element switched into an operational state against the willingness of its legitimate owner (e.g. subsequent to operations performed under constraint). Afterwards, the legitimate user will be able to contact the MS_A in order to identify the SE_B that became operational and to request the invalidation of its certificate, hence making it unusable as soon as the certificate status of that certificate will be checked. This may limit damages.

Each entry stored by a migration server associated with a source secure element (e.g. MS_A) shall at least contain:

the public key certificate of a source secure element SE_A,
the public key certificate of a recipient secure element SE_B,
an indicator specifying the operational state of the recipient secure element SE_B,
the public key allowing to authenticate the origin of the messages issued by the MS_B of this recipient secure element SE_B.

Each entry stored by a migration server associated with a recipient secure element (e.g. MS_B) shall at least contain:

the public key certificate of a recipient secure element SE_B,
the public key certificate of a SE_A,
the public key allowing to authenticate the origin of the messages issued by the migration server of the source secure element SE_A (MS_A).

Brief Description of Drawings

Figure 1 illustrates the architecture of the system and the possible dialogs between the various components of the system.

Figure 2 illustrates the dialogs to be able to carry out the transfer of the operational data.

Figure 3 illustrates only the phase of the transfer of the operational data.

Figure 4 illustrates the transition into an operational state of a SE_B containing a copy of the operational data of a SE_A, in a synchronous mode, consecutively with a dialog with the SE_A where the MS_A is directly contacted by the SE_A.

Figure 5 illustrates the transition into an operational state of a SE_B containing a copy of the operational data of a SE_A, in a synchronous mode, consecutively with a dialog with the SE_A where the MS_A is indirectly contacted by the SE_A via the SE_B and the MS_B.

Figure 6 illustrates the transition in an operational state of a SE_B containing a backup of the operational data of a SE_A, in an asynchronous mode, without dialog with the SE_A.

Mode(s) for Carrying Out the Invention

The secure element may be implemented by means of a single electronic component, e.g. a Trusted Platform Module (TPM) or a coprocessor, or by means of several electronic components encapsulated in another component, or by means of several electronic components protected by a security enclosure, generally called a “cryptographic enclosure” or a "Hardware Security Module (HSM), one or the other of these achievements having the functionalities required by the invention. When the secure element is placed in a device, the aforementioned “secure element” may be interfaced with its external environment, either by means of an interface with contacts, e.g. a smart card with contacts, or by means of an interface without contact, e.g. a smart card without contacts or a Near Field Contact (NFC) card.

The servers or the workstations supporting the secure elements will be connected between them by means of a network. The migration servers will be connected between them by means of a network and also to the servers or working stations supporting the secure elements by means of a network. When each secure element is governed by the same migration server, there is only one migration server instead of two.

Claims

Process allowing to carry out, under the control of one or more migration servers, either a copy of the operational data contained in a source secure element into a recipient secure element, or a backup of the operational data contained in a source secure element into one or more recipient secure elements, and allowing, at most, one secure element to be operational at any given time where the process includes two phases:

- a copy phase or a backup phase of the operational data contained in a

source operational secure element into a recipient secure element placed in

a non-operational state, with data confidentiality protection and data

integrity detection during the data transfer,

- the deactivation of the operational state of the source secure element

followed by the activation of the operational state of one, and only one,

recipient secure element containing the operational data originally

contained in the source secure element.

The second phase has two variants whether it is carried out:

- in a synchronous mode, i.e. immediately following a copy phase while

the secure elements are still being connected, or

- in an asynchronous mode, i.e. later on, once the backup phase has been

accomplished and after the secure elements have been disconnected.

Claim 2. Process according to claim 1 characterized in that every secure element supporting this process is associated with one migration server, where the role of that migration server is to authorize or to prohibit :

- the backup or the copy of the operational data from one source secure

element into another recipient secure element, and/or

- the change of the status of one secure element from an operational state

into a non-operational state and vice versa.

Claim 3. Process according to claims 1 and 2 characterized in that every secure element shall be personalized beforehand at least with the following data:

- a public key certificate specific to the secure element,

- a private key associated this public key certificate,

- a public key allowing the secure element to authenticate the origin of the

messages issued by the migration server associated with the secure

element.

The process requires the availability for the migration servers of revocation status information related to the public key certificates issued to the secure elements by the certification authorities issuing these certificates.

Claim 4. Process according to the claims 1, 2 and 3 characterized in that the migration server to which a source secure element is associated is able to memorize data making possible to know to which recipient secure element(s) the operational data contained in the source secure element has been successfully transferred (making the assumption that all the exchanges were successfully accomplished).

Claim 5. Process according to the claims 1 to 4 characterized in that the migration server to which a recipient secure element is associated is able to memorize data making possible to know from which source secure element(s) the operational data contained in the source secure element has been successfully transferred (making the assumption that all the exchanges were successfully accomplished).

Claim 6. Process according to claims 1 to 5 characterized in that, before a backup or a copy can take place, a secure element that will be a recipient of operational data shall:

- contain a zone able to store the operational data communicated by the

source secure element which must be originally empty or re-initialised. If

this is not the case, that zone shall be beforehand erased or re-initialised.

- contain a zone able to memorize a cryptographic checksum computed over

the operational data that will be transferred.

- be in a non-operational state. If this is not the case, the secure element

shall be placed beforehand in a non-operational state.

Claim 7. Process according to claims 1 to 6, characterized in that the backup or the copy of the operational data contained in a source secure element (SE_A) in another secure element (SE_B) is carried out by means of the following protocol exchanges:

(a) the dialog starts with a signed Diffie-Hellman key exchange performed

between the operational source secure element (SE_A) and the non-

operational recipient secure element (SE_B),

- message 1 (M1): a random number "n" and a modulo "p" are

exchanged between the SE_A and the SE_B.

- a message 2 (M2): a random number "n" elevated to the secret power

"a" by the SE_A, reduced to the modulo "p", a digital signature

computed over the previous data using the private key of the SE_A

associated with the public key certificate of the SE_A.

- message 3 (M3): a random number "n" elevated to the secret power

"b" by the SE_B, reduced to the modulo "p", a digital signature

computed over the previous data using the private key of the SE_B

associated with the public key certificate of the SE_B.

The message 1 (M1) can be sent at the same time as the message 2 (M2) or message 3 (M3) compound with message 1 (M1) can be sent before message 2 (M2). According to the secure element which takes the initiative of the dialog, the order of messages 2 (M2) and 3 (M3) can be reversed.

The resulting secret key "k" built using the signed Diffie-Hellmann key exchange is random number "n" elevated to the secret power "ab", the whole being reduced modulo p. A “man in the middle” will be unable to compute it.

(b) each server or each workstation supporting a secure element obtains an

address (e.g. a URL) giving access the migration server of that secure

element.

So that the migration server can detect replays, a challenge is requested from each migration server by the server or by the workstation supporting the secure element.

(c) the server or the workstation supporting the SE_A sends a request for a

challenge (Ch_A Req) to the MS_A and receives in return a challenge A

(Ch_A). Challenge A is then relayed by the server or by the workstation

supporting the SE_A to the server or the workstation supporting the

SE_B.

(d) the server or the workstation supporting the SE_B sends a request for

challenge (Ch_B Req) to the MS_B and receives in return a challenge B

(Ch_B). The challenge B is then relayed by the server or by the

workstation supporting the SE_B to the server or workstation supporting

the SE_A.

(e) the SE_B generates a message 4 (M4) that is sent by the server or by the

workstation supporting the SE_B to the server or to the workstation

supporting the SE_A which is then relayed to the MS_A.

This message 4 (M4) includes the following data:

- a message identifier allowing to know that it is a message of type 4,

- the challenge A (Ch_A) obtained from the MS_A,

- a message 2 (M2) that the SE_B received SE_A (which contains the

public key certificate of the SE_A),

- the public key certificate of the SE_B,

- a digital signature computed over the previous data using the specific

private key of the SE_B.

(f) the server or the workstation supporting the secure element SE_A

requests a challenge to the MS_B which provides in return a challenge B

which is then transmitted to the SE_A.

(g) the SE_A then generates a message 5 (M5) which is sent by the server

or by the workstation supporting the SE_A to the server or the workstation

supporting the SE_B then which is relayed as message M5_R to the

MS_B.

This message 5 (M5) includes the following data:

- a message identifier allowing to know that it is a message of type 5,

- the challenge (Ch_B) obtained from the MS_B,

- a message 3 (M3) that the SE_A received SE_B (which contains the

public key certificate of the SE_B),

- the public key allowing to authenticate the origin of the messages

transmitted by the MS_A,

- the public key certificate of the SE_A,

- as an option, a URL giving access the MS_A,

- a digital signature computed over the previous data using the specific

private key of the SE_A.

These messages are sent and received by the server or by the workstation supporting the secure element. It is obvious that the order of the messages 4 (M4) and 5 (M5) can be reversed.

Each message is then sent by the secure element to its migration server.

(h) The MS_A server verifies that it is indeed a message of type 4, that the

challenge which is present is identical to the one it has just sent, that the

public key certificate of the SE_A is delivered by a trusted certification

authority, that this certificate has the adequate properties for the

implementation of this process, that it is during its validity period and that

it is valid (e.g. not revoked) using the messages 6 (M6) and 7 (M7) that

are sent to a server holding certificate statuses (Cert. status).

It also verifies that message 2 (M2) which is contained in this message 4

(M4) is correctly signed by the public key contained in the public key

certificate of the SE_B, that the public key certificate of the SE_B is a

certificate issued by a trusted certification authority, that it has the

adequate properties for the implementation of this process, that it is

during its validity period and that it is valid (e.g. not revoked).

It also verifies that the whole data set is correctly signed using the private

key corresponding to the public key certificate of the SE_A.

Following the reception and the checking of a message of type 4, the MS_A server stores in a data entry the following data :

- the public key certificate of the SE_A,

- the public key certificate of the SE_B,

- an indicator specifying the operational state of the SE_B, and in this

case this indicator is positioned to indicate a non-operational state,

- the public key allowing to authenticate the origin of the messages

issued by the migration server (MS_B) of this SE_B.

In no case, these data shall be removed by the MS_A before the end of the validity period of the public key certificate of the SE_A.

If the first data of an entry already contains the public key certificate of the SE_A, a new entry is added afterwards.

(i) the MS_B server verifies that it is indeed a message of type 5, that the

challenge which is present is identical to that which he has just sent, that

the public key certificate of the SE_B is delivered by a trusted certification

authority, that this certificate contains the adequate properties for the

implementation of this process, that it is during its validity period and that

it is valid (e.g. not revoked) using the messages 8 (M8) and 9 (M9) that

are sent to a server holding certificate statuses (Cert. status).

It also verifies that message 3 (M3) which is contained in this message 5

(M5) is correctly signed by the public key contained in the public key

certificate of the SE_A, that the public key certificate of the SE_A is a

certificate issued by a trusted certification authority, that it lays out the

adequate properties for the implementation of this process, that it is

during its validity period and that it is valid (e.g. not revoked).

It also verifies that the whole data set is correctly signed using the private

key corresponding to the public key certificate of the SE_B.

Following the reception and the checking of a message of type 5, the MS_B stores in a data entry, the following data:

- the public key certificate of the SE_B,

- the public key certificate of the SE_A,

- the public key allowing to authenticate the origin of the messages

transmitted by the migration server of SE_A (MS_A).

As an option, the URL giving access the migration server of SE_A (MS_A) may also be stored.

In no case, these data shall be removed before the end of the validity period of the public key certificate of the SE_B.

If the first data of an entry already contains the public key certificate of the SE_B, a new entry shall be added afterwards.

The order of the verification of the messages 4 (M4) and 5 (M5) can be reversed.

(j) the migration server MS_A returns then to the server or to the

workstation supporting the secure element SE_A that contacted it a

message 10 (M10) which contains:

- a message identifier allowing to know that it is a message of type 10,

- data allowing to detect replays,

- an agreement indicator for the transfer of the operational data between

the secure elements, and

- a digital signature computed over the previous data using the private

key of the MS_A.

The data allowing to detect replays shall be unique data. It can be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a single data already present in a previous message, as an example, data allowing to detect replays in message 6 (M6) can be data already present in message 4 (M4), such as the value of the digital signature computed using the private key of the SE_A.

A convention shall be defined between the secure element and its migration server to determine which is the data making possible to detect replays.

(k) the SE_A verifies that the message that it received from the MS_A is

indeed a message of type 10 and that the value making possible to

detect replays has the expected value. The SE_A verifies the digital

signature of the message using the public key of the MS_A.

If the digital signature is correct, the SE_A verifies the presence of the

agreement indicator for the transfer of the operational data between the

secure elements.

(l) the migration server MS_B returns then to the server or to the

workstation of the secure element SE_B which contacted it a message

11 (M11) which contains:

- a message identifier allowing to know that it is a message of type 11,

- data allowing to detect replays,

- an agreement indicator for the transfer of the operational data between

the secure elements, and

- a digital signature computed over the previous data using the private

key of the MS_B.

The data allowing to detect replays shall be unique data. It can be communicated by means of an additional exchange or in order to avoid this additional exchange, it can be a single data already present in a previous message. As an example, data allowing to detect replays in message 11 (M11) can be data already present in the relayed message 5 (M5_R), such as the value of the digital signature computed using the private key of the SE_A.

A convention shall be defined between the secure element and its migration server to determine which is the data making possible to detect replay.

(m) the SE_B verifies that the message that it received is indeed a message

of type 11 and that the value making possible to detect replays has the

expected value. The SE_B verifies the digital signature of the message

by means of the public key of the MS_B. If the digital signature is

correct, the SE_B verifies the presence of the agreement indicator for

the transfer of the operational data between the secure elements.

(n) each secure element announces with the other one that it is ready to

begin the transfer of the operational data. This transfer is carried out by

means of messages exchanged directly between the two secure

elements via the servers or the workstations supporting these secure

elements. It is a succession of "n" numbered exchanges. Each message

entails a message identifier making it possible to know that it is a

message of type “transfer of operational data”.

(o) the operational data of the SE_A are transferred to the SE_B:

- enciphered using the key "k" or a key derived from the key "k", and

- integrity protected using the key "k" or a key derived from the key "k".

The secret key "k" is the key which was built during the exchange of Diffie-Hellmann key: it is random number n" elevated to the secret power "ab", the whole being reduced modulo "p". The received data are deciphered by the SE_B before being stored in the SE_B.

In order to make sure that no message is removed during the transfer, a cryptographic checksum is progressively computed while the data is being transferred and is transmitted in the last message.

The SE_B verifies that the value of the final value cryptographic checksum that is sent is equal to the one that it has locally computed. If this is not the case, the whole of the data already transferred is erased. A new transfer of the data may however be attempted. If this is the case, the operational data which was present in the SE_A is now present in the SE_B. The SE_B uses an internal indicator to memorize that property. At this stage, the SE_B is still in a non-operational state.

Claim 8. Process according to claims 1, 2, 3, 4, 5, 6 and 7, characterized in that the setting in operational state of a secure element SE_B recipient of operational data which have been just copied is consecutively carried out with a dialog with the SE_A where the MS_A is directly contacted by the SE_A in the following way :

(a) the messages are exchanged immediately after the end of the copy of

the operational data contained in the SE_A into of the SE_B, without

powering off the SE_A nor the SE_B,

(b) the SE_A sends to the MS_A a message 12 (M12) which contains:

- a message identifier allowing to know that it is a message of type 12,

- data allowing to detect replays,

- the public key certificate of the SE_A,

- a digital signature computed over the previous data using the private

key of the SE_A.

The data allowing to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a single data already present in a previous message, as an example, the digital signature present in message 10 (M10).

(c) the MS_A verifies that the message it received is indeed a message of

type 12 and which message 12 (M12) that is not a replay of a previous

message and that is correctly signed by the SE_A. In an entry that

contains in its first element the certificate of the SE_A, it examines the

second element looking for an element that contains the value of the

public key certificate of the SE_B. If this entry is not found, then an error

message is returned to the SE_A. Otherwise, the MS_A modifies the

indicator specifying whether the secure element SE_B is or not in an

operational state and positions it into an “operational” state".

(d) the MS_A sends to the SE_A a message 13 (M13) which contains:

- a message identifier allowing to know that it is a message of type 13,

- data allowing to detect replays,

- an agreement indicator for the setting of the SE_B into an operational

state,

- a digital signature computed over the previous data using the private

key of the MS_A.

The data allowing to detect replays will be shall be unique data. It may

be communicated by means of an additional exchange or in order to

avoid this additional exchange, that can be a single data already present

in a previous message, for example, the digital signature present in

message 12 (M12).

(e) the SE_A verifies:

- that the message which it received is indeed a message of type 13,

- that the data allowing to detect replay has the expected value,

- that the agreement indicator for the transition into an operational state

of the SE_B is present,

- that the digital signature is valid by using the public key of the MS_A.

The SE_A then places itself in a non-operational state and authorizes the change of the state of the SE_B into an operational state by means of the message 14 (M14) which is composed of:

- a message identifier allowing to know that it is a message of type 14,

- data allowing to detect replays,

- an agreement indicator for the setting of the SE_B into an operational

state,

- a cryptographic checksum computed over the previous data using the

secret key "k" or a key derived from the key "k".

The data allowing to detect replays shall be unique data present. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a data already present in a previous message, for example, the previous cryptographic checksum computed over the last exchange of the operational data between the two secure elements.

(f) the SE_B verifies that the message it received is indeed a message of

type 14 and that the value making possible to detect replays has the

expected value. Using the secret key "k" or a key derived from the key

"k", the SE_B verifies that the message contains the expected

cryptographic checksum. It verifies the presence of the agreement

indicator for the transition into an operational state and then places itself

into an operational state.

Claim 9. Process according to claims 1, 2, 3, 4, 5, 6 and 7, characterized in that the setting into an operational state of a recipient secure element SE_B is carried out immediately after the successful transfer of operational data between two secure elements using a dialog between the SE_A and the SE_B and where the MS_A is indirectly contacted by the SE_A via the SE_B and via the MS_B.

The messages are exchanged immediately after the transfer of the operational data contained in the SE_A into the SE_B, without powering off the SE_A or the SE_B.

The data making possible for the MS_B to detect replays shall be unique data. It may be communicated by means of an additional exchange or in order to avoid this additional exchange, that can be a data already present in a previous message, for example, the digital signature contained in the message 11 (M 11) that has been sent by the MS_B to the SE_B. When an additional exchange is being used, the SE_B first requests a challenge (Ch_B Req) to the MS_B and receives back a challenge called Ch_B. The other exchanges are as follows.

(a) the SE_B sends to the SE_A a message 15 (M15) which contains:

- a message identifier allowing to know that it is a message of type 15,

- data allowing the MS_B to detect replays,

- a cryptographic checksum computed over the previous data using the

secret key "k" or a key derived from the key "k".

(b) the SE_A verifies that the message it received is indeed a message of

type 15 and using the secret key "k" or a key derived from the key "k",

the SE_A verifies that the message contains the expected cryptographic

checksum.

It then places itself into a non-operational state.

(c) the SE_A sends to the SE_B a message 16 (M16) which contains:

- a message identifier allowing to know that it is a message of type 16,

- data allowing both the MS_B and the SE_B to detect replays,

- the public key certificate of the SE_A,

- an indicator stating that the SE_A has been placed into a

non-operational state,

- a digital signature computed over the previous data using the private

key of the SE_A.

- a cryptographic checksum computed on the previous data using the

secret key "k" of a key derived from the key "k".

(d) the SE_B verifies that the message that it received is indeed a message

of type 16 and that the value making possible to detect replays has the

expected value. Using the secret key "k" of a key derived from the key

"k", the SE_B verifies that the message contains the expected

cryptographic checksum.

(e) the server or the workstation supporting the SE_B connects to the MS_B

and requests a challenge to the MS_B (Ch_B req). The server or the

workstation supporting the SE_B communicates this challenge B (Ch_B)

to the SE_B.

(f) the SE_B sends to the MS_B a message 17 (M17) which contains:

- a message identifier allowing to know that it is a message of type 17,

- the message 16 (M16),

- the challenge (Ch_B) received from the MS_B allowing to detect

replays,

- the public key certificate of the SE_B,

- a digital signature computed over the previous data using the private

key of the SE_B.

(g) the MS_B verifies that:

- the message which it received is indeed a message of type 17,

- the challenge contained in the message 17 (M17) corresponds to the

challenge (Ch_B) that has been sent,

- the message 17 (M17) contains the expected digital signature using

the public key of the SE_B.

(h) the MS_B then verifies that :

- the message that is included in the message 17 (M17) is indeed a

message of type 16,

- the challenge contained in the message 16 (M16) corresponds to the

challenge (Ch_B) that has been sent,

- the message 16 (M16) contains the expected digital signature using

the public key of the SE_A.

(i) the MS_B then extracts from the message 16 (M16):

- the message identifier allowing to know that it is a message of type 16,

- data allowing to detect replays,

- the public key certificate of the SE_A,

- an indicator stating that the SE_A has been placed into a

non-operational state,

- a digital signature computed over the previous data using the private

key of the SE_A.

(j) the MS_B then verifies that that the message that it received is indeed a

message of type 16 and that the value making possible to detect replays

has the expected value. The MS_B verifies the digital signature of the

message using the public key certificate of the SE_A.

(k) the MS_B browses through the entries that it has memorized looking for

entries containing the public key certificate of the SE_B and recovers

from the last entry:

- the public key certificate of a SE_A,

- the public key allowing to authenticate the origin of the messages

issued by the migration server of SE_A (MS_A).

By means of the messages 18 (M18) and 19 (M19) addressed to a certificate status server (Cert. status), the MS_B verifies that both the public key certificate of the SE_A and the public key certificate of the SE_B are issued by a trusted certification authority, that they have the adequate properties for the implementation of this process, that they are within their validity period and that they are valid (e.g. they have not been revoked).

If all these verifications are satisfied then the server MS_B connects to the MS_A using an address (e.g. a URL) giving access the MS_A associated with this SE_A and requests a challenge to the MS_A.

(l) the MS_B sends to the MS_A a message 20 (M20) which contains:

- a message identifier allowing to know that it is a message of type 20,

- the challenge A (Ch_A) generated by the MS_A,

- the public key certificate of the SE_A,

- the public key of the MS_B,

- a digital signature computed over the previous data using the private

key of the MS_B.

(m) the MS_A verifies that the message that it received is indeed a

message of type 20 and that challenge A contained in message 20

(M20) is identical to the challenge which it had sent. If this is not the

case, an error is returned.

The MS_A verifies the digital signature of message 20 (M20) using the

public key of the MS_B contained in this entry. If the verification is not

conclusive, an error is returned.

The MS_A extracts from the message 20 (M20) the public key certificate

of the SE_A and makes sure that the public key certificate of the SE_A

has already been memorized. If this is not the case, an error is returned.

By means of the messages 21 (M21) and 22 (M22) addressed to a certificate status server (Cert. status), the MS_A verifies that the public key certificate of the SE_A is valid (e.g. it has not been revoked).

The MS_A examines all the entries associated with the certificate of the SE_A. If anyone entry already contains an indicator specifying that a secure element moved into an operational state, an error is returned. The MS_A recovers the data entries associated with the certificate of the SE_A, i.e. one or more data entries, each entry being composed of:

- the certificate of a SE_A,

- the certificate of a SE_B,

- an indicator specifying whether this SE_B is or is not operational,,

- the public key allowing to authenticate the origin of the messages

issued by the MS_B of this SE_B.

It looks for the last entry containing the certificate of this SE_B. If this

certificate does not appear in any entry, an error is returned. In that

entry, the MS_A modifies the indicator specifying the operational state

of the SE_B and places it into an operational state.

(n) the MS_A sends to the MS_B a message 23 (M23) which contains:

- a message identifier allowing to know that it is a message of type 23,

- data allowing to detect replays,

- an agreement indicator for the setting into operational state the SE_B,

- a digital signature computed over the previous data using the private

key of the MS_A.

The data allowing to detect replays shall be unique data already present

in the previous message, for example, the digital signature present in the

message 20 (M20), or a data sent specifically to this end in an additional

message.

(o) the MS_B verifies that the message that it received is indeed a message

of type 23 and that the value making possible to detect replays has the

expected value. The MS_B also verifies that the digital signature is

correct.

(p) the MS_B sends to the SE_B a message 24 (M24) which contains:

- a message identifier allowing to know that it is a message of type 24,

- data allowing to detect replays,

- the public key certificate of the SE_B,

- an agreement indicator for the transition into an operational state of

the SE_B,

- a digital signature computed over the previous data using the private

key of the MS_B.

The data allowing to detect replays shall be unique data already present

in the previous message, for example, the digital signature present in

the message 17 (M17), or a data sent specifically to this end in an

additional message.

(q) the SE_B verifies that the message that it received is indeed a message

of type 24 and that the value making possible to detect replays has the

expected value and that the value of the public key certificate of the

SE_B matches with its own public key certificate. The SE_B verifies

that the digital signature of message 24 (M24) is correct. If this is not

the case, an error is returned. If this is the case, the SE_B switches into

an operational state.

Claim 10. Process according to claims 1, 2, 3, 4, 5, 6 and 7, characterized in that the switching into an operational state of recipient secure element SE_B is carried out in asynchronous mode without a dialog with the SE_A in the following way:

(a) the SE_B verifies itself that it is in a non-operational state and that it

contains a complete transfer of backed up operational data by verifying

the presence of an internal indicator that memorizes the fact that it

contains the full set of the operational data of another secure element.

If these verifications are unsuccessful, then an error is returned by the

SE_B.

(b) the server or the workstation supporting the SE_B connects to the MS_B

and requests a challenge to the MS_B by means of message

(Ch_B Req). The server or the workstation supporting the SE_B

communicates this challenge B to the SE_B by means of a message

(Ch_B).

(c) the SE_B generates to the attention of the migration server MS_B a

message 25 (M25) which contains:

- a message identifier allowing to know that it is a message of type 25,

- the challenge B (Ch_B),

- the public key certificate of the SE_B,

- a digital signature computed over the previous data using the private

key of the SE_B.

(d) the MS_B verifies that:

- the message which it received is indeed a message of type 25,

- the challenge B corresponds to the one that has just been sent,

- the public key certificate of the SE_B was issued by a trusted

certification authority, that it has the adequate properties for the

implementation of this process, that it is during its validity period and

by means of the messages 26 (M26) and 27 (M27) that it is valid

(e.g. not revoked),

- the digital signature is valid, using the public key contained in the

public key certificate of the SE_B.

If anyone of these conditions is not verified, an error message is returned to the SE_B.

(e) the MS_B browses through the entries which it memorized looking for an

entry containing in the first element of the entry the public key certificate

of the SE_B. If such an entry is missing, an error message is returned to

the SE_B.

The MS_B recovers the last entry associated with the certificate of the

SE_B which shall at least contain:

- the public key certificate of a SE_B,

- the public key certificate of a SE_A,

- the public key allowing to authenticate the origin of the messages

transmitted by the MS_A associated with this SE_A.

The MS_B verifies that the public key certificate of the SE_A has been

issued by a trusted certification authority, that it has the adequate

properties for the implementation of this process, that it is during its

validity period. By means of the messages 26 (M26) and 27 (M27)

addressed to a certificate status server (Cert. status). The MS_B verifies

that the public key certificate of the SE_A is no more valid (e.g. it has

been revoked) and that the public key certificate of the SE_B is valid

(e.g. it has not been revoked). If these verifications are not carried out

successfully then an error message is returned to the MS_B and then

after to the SE_B.

If all these verifications are satisfied then the server MS_B contacts the MS_A using an address (e.g. a URL) giving access the MS_A associated with this SE_A.

(f) the MS_B requests a challenge to the MS_A (Ch_A Req). The MS_A

communicates this challenge A (Ch_A) to the MS_B. The MS_B

generates for the MS_A a message 28 (M28) which contains:

- a message identifier allowing to know that it is a message of type 28,

- the challenge A (Ch_A) generated by the MS_A,

- the public key certificate of the SE_A,

- the public key certificate of the SE_B,

- the public key of the MS_B,

- a digital signature computed over the previous data using the private

key of the MS_B.

(g) the MS_A verifies that the message that it received is indeed a message

of type 28 and that the challenge contained in the message 28 (M28) is

identical to the challenge (Ch_A) which it has sent. The MS_A verifies

the digital signature using the public key of the MS_B. If one of these

verification fails, an error message is returned to the MS_B and then

after to the SE_B. The MS_A browses through the entries which it

memorized looking for an entry containing in the first element of the

entry the public key certificate of the SE_A. If this entry is missing, an

error message is returned to the MS_B and then after to the SE_B.

If this entry is present, it makes sure by means of messages 29 (M29)

and 30 (M30) addressed to a certificate status server (Cert. status) that

the certificate of the SE_A is no more valid (e.g. it has been revoked)

and that the certificate of the SE_B is valid (e.g. it has not been

revoked). If this is not the case, an error message is returned to the

MS_B and then after to the SE_B.

The MS_A examines all the entries associated with the certificate of the

SE_A. If anyone of these entries contains an indicator specifying in the

third element of the entry that a recipient secure element already

switched into an operational state, an error message is returned to the

MS_B.

The MS_A looks for an entry containing in the second element of that

entry the certificate of the recipient secure element SE_B as contained in

the message 28 (M28). If this certificate does not appear in any entry, an

error message is returned to the MS_B.

In the entry that contains the value of the public key certificate of the

SE_B, the MS_A modifies the indicator specifying the operational state

of the SE_B and positions it to indicate an operational state.

The MS_A then sends to the MS_B a message 31 (M31) composed of

the following data:

- a message identifier allowing to know that it is a message of type 31,

- data allowing to detect replays,

- the public key certificate of the SE_B,

- an agreement indicator for the setting into operational state the SE_B,

- a digital signature computed over the previous data using the private

key of the MS_A.

The data allowing to detect replays shall be unique data already present

in the previous message, for example, the digital signature present in the

message 28 (M28), or a data sent specifically to this end in an additional

message.

(h) the MS_B verifies that the message that it received is indeed a message

of type 31 and that the value making possible to detect replays has the

expected value. The MS_B also verifies the digital signature of the

message using the public key of the MS_A. If one of these verifications

fails, an error message is returned to the MS_A and another one to the

SE_B.

(i) otherwise, the MS_B then indicates to the SE_B that it is authorized to

switch into an operational state. For that purpose, the MS_B sends to the

SE_B a message 32 (M32) composed of the following data:

- a message identifier allowing to know that it is a message of type 32,

- data allowing to detect replays,

- the public key certificate of the SE_B,

- an agreement indicator for the switching into an operational state of

the SE_B,

- a digital signature computed over the previous data using the private

key of the MS_B.

The data allowing to detect replays shall be unique data already present in the previous message, for example, the digital signature present in the message 25 (M25), or a data sent specifically to this end in an additional message.

(j) the SE_B verifies that the message that has been received is indeed a

message of type 32 and that the value making possible to detect replays

has the expected value and that the value of the public key certificate of

the SE_B matches with its own public key certificate. The SE_B also

verifies that the digital signature is correct using the public key of the

MS_B. If this is not the case, an error is returned. If this is the case, then

the SE_B switches itself into an operational state.

Claim 11. Process according to claims 1, 2, 3, 4, 6 and 7, characterized in that, if only the process of the switching into an operational state in a synchronous mode is supported by both the source and the recipient secure elements, an order may be addressed to the SE_A so that it is placed into a non-operational state and the SE_A then authorizes the transition of the SE_B into an operational state by means of the message 14 (M14). Hence, messages 12 (M12) and 13 (M13) can then be omitted.