>FIG. 1 also stores two individual keys, a cipher key SK12c and an integrity key SK12i. The personalization process of the Mobile UICC belonging to the group j computes and thus stores into each card: MKj1, SKj2c and SKj2i.

The server SV comprises, or is connected to, a memory MEM storing as many first group's master keys MKj1 as groups of mobile device MD it is intended to connect to.

It also stores a table of individualization master keys MKj2, such individualization master keys being in practice second group master keys which are managed by the server SV. From each MKj2 and a Mobile UICC identity, typically an EID or ICCID, the server SV can derive SKj2c, the individual cipher key, and SKj2i, the individual integrity key, which are specific to each Mobile UICC.

FIG. 2 shows in further details the implementation of the invention.

FIG. 2A shows the two first exchanges of the invention allowing to setup a ciphered session, or dialogue with a reasonable level of security including data privacy integrity, authenticity, confidentiality and anti-replay.

The attachment message ATTR(IMSI)_1 of the protocol from the mobile MD to server SV has 0 byte payload and only carries a mobile IMSI value. In the invention, this IMSI is a random IMSI value rIMSI taken out of the range of ephemeral IMSI RGj(IMSI) pre-loaded in the Mobile CC in a step PR0.

Then a 32 bytes payload authentication request message AUTR(rIMSI)_1 is sent by the server SV to the mobile device's CC(MD). Among the 32 bytes payload, some bytes, for example bytes 0 and 21 are not free. In the Easy Connect technology the byte 0 identifies the Easy Connect command C and the byte 21 shall follow the AMF (Authentication Management Field) encoding according 3GPP TS 33.102.

In a step PR1, processing is performed by the server SV to construct an authentication request message AUTR(RND, AUTN)_2 in answer to the attachment request ATTR(rIMSI)_1.

The authentication request message AUTR(RND,AUTH)_2 comprises two parts: a random part RND and an authentication part AUTN.

During the processing step PR1, the server SV gets the IMSI range RG1(IMSI) from the randomly chosen rIMSI. An HSS-MSIN can then be allocated to the CC(MD). This can be done subsequently or the HSS-MSIN is only used for “subsequent messages” and thus is allocated at the very last time before it is needed. The ephemeral IMSI range thus first enables the server SV to identify the group master key MK11.

It then generates an HSS Random value Rnd and generates a 8 bytes Random value for signature CMAC of the authentication request message AUTR(RND,AUTN)_2.

Using the randomly chosen rIMSI as received, the server SV derives a cipher key SK11c from the master key MK11 to compute a CMAC signature.

Typically, the derivation is the following: SK11c/SK11i=SP800-108 (MK11, context=rIMSI, label=label1, PRF=AES-CMAC), label1 being a predefined constant. This derivation corresponds to the definition as defined in the NIST special publication 800-108 of October 2009 by Lily Chen: Recommendation for Key Derivation Using Pseudorandom Functions.

Then the server SV computes a signature CMAC using the integrity key SK11i: CMAC(SK11i) (01∥ . . . ∥padding).

Then the authentication request message AUTR(RND, AUTH)_2 is formatted in a first part RND and a second AUTN. This message is not ciphered except if the protocol requires it. This is not currently the case but it may be the case in 5G standard.

In the shown example, the first part RND contains the Easy Connect command C, parameters IX (one byte) and a portion of the HSS Random value Rnd (5 and 3 bytes shared on the two portions RND and AUTN). The second part AUTN comprises another portion of the server random value Rnd, the AMF, the CMAC signature on 4 bytes. Payload PL comprises parameters allowing to establish a unique session using the random rIMSI and the server random value Rnd. Payload PL is divided in three portions of 9 bytes in the portion RND and of 3 and 5 bytes in portion AUTN in the Easy Connect example of FIG. 2A. The payload is signed with a CMAC. It allows to authenticate the server using a CMAC.

The mobile UICC, while receiving the authentication request message AUTR(RND, AUTN)_2, also derives the first group master key MK11 into a cipher key SK11c and an integrity key SK11i: SK11c/SK11i=SP800-108 (MK11, context=rIMSI, label=label1, PRF=AES-CMAC), label1 being a fixed constant.

It then computes and checks the received CMAC using SK11i and checks that the received rIMSI in the payload is the sent rIMSI from the attachment request ATTR(rIMSI)_1.

As illustrated on FIG. 2B, the mobile CC then prepares a specific mobile to server authentication failure message AUTF(rIMSI,AUTS)_3 having a limited payload, here 14 bytes, where byte 0 shall not be ciphered as it defines the Easy Connect command. This payload shall contain an identifier CCId of the Mobile UICC. To ensure the data privacy, the Mobile UICC identity CCId shall be encrypted for confidentiality and the full command shall be signed for integrity and authenticity. This figure shows a possible implementation for the third message ciphering which contains a CMAC to check the data integrity and the authenticity of the Mobile/UICC sending the AUTS payload.

Thus the mobile UICC proceeds to a ciphering of the identifier CCId of the mobile UICC using the cipher key SK11c and the MSIN corresponding to the randomly chosen ephemeral rIMSI MSIN: Cipher [CID_10]SK11c=AES-CTR (SK11c, Nonce=MSIN∥Random, CTR=0x000081). The RANDOM being the server random value Rnd sent at the previous stage.

Then a CMAC signature is computed on the ciphered identifier. The result is truncated if needed regarding the available payload: CMAC=2 first bytes of AES-CMAC (SK11i) (0x81∥[CID_10]SK11c∥0x00).

Thus the authentication failure message AUTF(rIMSI, AUTN)_3 returned by the mobile UICC comprises a first byte with a response command Rsp, the ciphered identifier of the UICC on 10 bytes CCId, a free byte reserved for future use set to 0x00 and the CMAC on two bytes. Encrypted data are illustrated in bold characters on figures.

After receiving this last authentication failure message AUTF(rIMSI, AUTN)_3, the server SV uses the derived integrity key SK11i to check the CMAC and the derived cipher key SK11c to decrypt the UICC identified CID on 10 bytes. By using the CC received and decrypted identifier CCId of the CC and internal business rules, the server SV is able to allocate a temporary IMSI t-IMSI and miscellaneous subscription parameters.

The server SV then prepares a new authentication request message AUTR(RND, AUTN)_4 having a 32 bytes payload with bytes 0 and 21 are again not free as already indicated in the second message.

The server SV uses the second group master key MK2 and the decrypted identifier CCId of the CC to derive two individual keys SK12c and SK12i: SK12c/SK12i=SP800-108 (MK2[IX0], context=CID_16, label=label2, PRF=AES-CMAC), with IX0 used to select the group master key MK2 key to be used.

The server SV then ciphers, using AES-CTR with a nonce composed of rIMSI MSIN and the server random value Rnd, Payload PL and Timeout and Index divided in three payload portion of 10 bytes in the RND portion of the message PL1 and of 6 and 9 bytes in the AUTN portion of the message, PL2 and PL3.