Secure channel initiation between card and host

Abstract

A process for initiating a secure communication session between a card and a host, assigning a static encryption key to the card and storing in the card, each of the card and the host providing a key version number and a key identifier of the static key, the process comprising the steps at the card: receiving from the host an INITIALIZE UPDATE command comprising a host challenge, the host challenge is a value unique to the session; generating a card challenge, the card challenge being a value unique to the session, where at least the static encryption key, key diversification data, and sequence counter of the card are processed with a first cryptographic function; generating a session key (S-ENC), wherein the static encryption key, the host challenge and the card challenge of the card are processed with a second cryptographic function; calculating a card password using a session key (S-ENC); sending an INITIALIZE UPDATE reply to the host, including the card password, the sequence counter, and the card challenge, to enable the host to verify the card password; characterized in that each of the card and the host provides an SCP key identifier associated with a key version number and a key identifier of a static encryption key of the card; the INITIALIZE UPDATE command comprises an SCP secret key identifier, and does not comprise a secret key version number and a secret key identifier; in order to generate a card challenge, the key version number and the key identifier are further processed with a first cryptographic function.

Description

Technical Field

[0001] The present invention relates to secure channel initiation between a card and a host. Background Art

[0002] Document [1][GPC_SPE_014] Global Platform Technology, Secure Channel Protocol '03', Card Specification V2.3-Amendment D, Version 1.1.2, March 2019 describes the initiation of a secure channel between a card and a host using an INITIALIZE UPDATE command sent from the host to the card and an INITIALIZE UPDATE reply sent from the card to the host.

[0003] The INITIALIZE UPDATE command and the INITIALIZE UPDATE reply according to [1] include confidential data, in particular a key version number and a secret card static encrypted key identifier assigned to the card and securely stored in the card. Providing such confidential data in the command carries the risk of the confidential data being disclosed to unauthorized entities.

[0004] Document [1] relates to a "card". Known cards are payment cards, SIM cards and identification cards. Document [1] originates from a technical environment in which the card is embodied as an integrated circuit card having a card body and a chip module or chip and one or more interfaces integrated thereon. At the same time, other form factors of card-like devices are also known. For example, for SIM cards, in addition to the form factors of plug-in SIM cards or pUICCs or simply UICCs, form factors of embedded UICCs (eUICCs) and integrated UICCs (iUICCs) are also known. In addition, for payment and identification cards, in addition to the independent form factors of traditional payment cards and independent identification cards, integrated form factors integrated into larger devices such as smart phones are known.

[0005] In conjunction with the present invention, a "card" is understood as an entity having the functionality of a card, such as a payment card, a SIM card or an identification card, and having any form factor, including independent, plug-in, embedded, integrated form factors.

[0006] In conjunction with the present invention, the "card" also has one or more interfaces to enable communication between the card and the host. Summary of the invention

[0007] An object of the present invention is to provide a secure channel initiation procedure with improved security.

[0008] The object of the invention is achieved by a process having the following features according to claim 1. Embodiments of the invention are presented in the dependent claims.

[0009] In more detail, the object of the present invention is achieved by a process for initiating a secure communication session between a card and a host. A static encryption key is assigned to the card and stored in the card. Each of the card and the host provides a key version number and a key identifier of the static key.

[0010] The process comprises the steps at the card of: - receiving an INITIALIZE UPDATE command from the host including a host challenge, the host challenge being a value unique to the session;

[0011] - generating a card challenge, the card challenge being a value unique to the session, where at least the card's static encryption key, key diversification data and sequence counter are processed with a first cryptographic function;

[0012] - Generate session keys where the card's static encryption key, host challenge and card challenge are processed with a second cryptographic function;

[0013] - Use the session key to calculate the card secret;

[0014] - Send an INITIALIZE UPDATE reply to the host, which includes the card secret code, sequence counter and card challenge to enable the host to verify the card secret code.

[0015] The process is characterized by:

[0016] - each of the card and the host provides an SCP key identification associated with said key version number and said key identifier of the static encryption key of the card;

[0017] - an INITIALIZE UPDATE command includes the SCP key identification and does not include the key version number and the key identifier;

[0018] - To generate a card challenge, the key version number and the key identifier are additionally processed with a first cryptographic function.

[0019] Since the key version number and the key identifier are missing in the INITIALIZE UPDATE command and are replaced by the anonymous SCP key identifier, the key version number and the key identifier cannot be found from the INITIALIZE UPDATE command. The anonymous SCP key identifier does not disclose any confidential key information even if it is found. In order to provide the card with the required information about the key version number and the key identifier, the key version number and the key identifier are processed with the first cryptographic function and are only provided in a hidden form.

[0020] Therefore, the present invention provides a secure channel initiation process with improved security.

[0021] According to some embodiments, the SCP key identification is included in the data field of said INITIALIZE UPDATE command.

[0022] According to some embodiments:

[0023] - field P1 of the INITIALIZE UPDATE command comprises a fixed value (in particular 0xFF) instead of a key version number; and / or

[0024] - Field P2 of the INITIALIZE UPDATE command comprises a fixed value (in particular 0xFF) instead of a key identifier.

[0025] In particular, according to some embodiments, and in a combination of two of the above embodiments, when field P1 of the INITIALIZE UPDATE command comprises a fixed value (in particular 0xFF) instead of a key version number, then the SCP key identifier is included in the data field of the INITIALIZE UPDATE command. Preferably, in this case, field P2 of the INITIALIZE UPDATE command also comprises a fixed value (in particular 0xFF) instead of a key identifier.

[0026] According to some embodiments, the card comprises a card application, wherein a session is initiated between the card application and the host, wherein: - for generating a card challenge, an application identifier AID of the card application is additionally processed with a first cryptographic function.

[0027] According to some embodiments, each of the card and the host provides some or all of the following security parameters:

[0028] - Security parameter flags;

[0029] -length;

[0030] - length of the SCP key identifier;

[0031] -SCP key identification;

[0032] - length of the key version and / or key identifier;

[0033] -Key version and / or key identifier.

[0034] Preferably, the above identified security parameters are preconfigured to both the card and the host.Preconfiguration may be achieved, for example, during card production, or later, for example, during card personalization or during card updating. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Embodiments of the present invention will now be described with reference to the accompanying drawings, wherein like parts are designated by like reference numerals throughout, and wherein:

[0036] Figure 1 Detailed steps and subsequent steps during secure channel initiation according to prior art [1] and embodiments of the present invention;

[0037] Figure 2 The secure channel is initiated according to the prior art [1];

[0038] Figure 3 Secure channel initiation according to an embodiment of the present invention;

[0039] Figure 4 According to an embodiment of the present invention, before initiating a secure channel, the SCP key identifier and other security parameters of the present invention need to be provided to the card and the external entity. DETAILED DESCRIPTION

[0040] Figure 1 Detailed steps are shown during session initiation between an off-card entity or host on the one hand and a card application implemented in the card on the other hand and subsequently during mutual authentication between the card and the off-card entity. The card application can access the security domain for measures of security processing such as performing cryptographic functions, generating card challenges, generating keys, and calculating cryptograms based on keys and challenges.

[0041] 1. The secure channel is initiated by an INITIALIZE UPDATE command sent by the off-card entity to the card application, where a host challenge generated by the off-card entity is passed to the card. The host challenge is a random or pseudo-random data element that is unique to the session being initiated. According to the present invention, and as will be referred to below Figure 3 To elaborate in more detail, depending on whether the value of the code field is lower than (<) a preset value (eg, 0xFF) or equal to (=) the preset value (eg, 0xFF), the INITIALIZE UPDATE command includes the standard content "key version" or the inventive content "SCP key identification".

[0042] 2. The card application, upon receiving the host challenge, generates its own card challenge, which is also a random or pseudo-random data element unique to the session. The card application creates a new secret session key using the sequence counter and the static key, and by using the card's cryptographic function, generates a first cryptographic value, the so-called card cryptogram, using one of its newly created session keys.

[0043] 3. In the INITIALIZE UPDATE response, the card secret code is sent back to the off-card entity along with the sequence counter, card challenge and other data. According to the present invention, instead of the key information, secure channel information is sent in the INITIALIZE UPDATE response, as will be referred to below. Figure 3 Elaborated in detail.

[0044] 4. Since the off-card entity now has all the same information that the card used to generate the card cryptogram, it is able to generate the same session key and the same card cryptogram, and by performing a comparison it is able to verify the card cryptogram, thereby authenticating the card.

[0045] 5. Subsequently, the off-card entity can now use a similar process to create a second cryptographic value (host cryptographic key) to be passed back to the card (EXTERNALAUTEHENTICATE command).

[0046] In accordance with Figure 1 In the arrangement, preferably, one or more communication interfaces are provided between the external card entity and the card, which enable the external card entity and the card to communicate via APDU commands. APDU stands for Application Protocol Data Unit.

[0047] In addition, according to Figure 1 In the arrangement, preferably, the card application and the security domain performing the cryptographic functions communicate via a Global Platform Application Programming Interface (abbreviated as GP API).

[0048] Figure 2 A secure channel initiation according to the prior art [1] is shown for a card application implemented in a card and having an application identifier AID. According to document [1] GPC_SPE_014v2.3-Amendment D, version 1.1.2, in order to initiate a secure channel between a card and a host, an INITIALIZE UPDATE command is sent from the host to the card, and an INITIALIZE UPDATE reply is sent back from the card to the host. In particular, the INITIALIZE UPDATE command includes a key version number in a code field P1, a key identifier in a code field P2, and a host challenge generated by the host in a data field, all of which are as defined in [1]. The key version number and the key identifier are both confidential key information. In particular, the INITIALIZE UPDATE reply includes 10 bytes of key diversification data, 3 bytes of confidential key information, an 8-byte card challenge generated by the card, an 8-byte card password calculated by the card, and a 3-byte sequence counter.

[0049] Key diversification data is data that backend systems typically use to derive card static keys. Key information includes the key version number, secure channel protocol identifier (in the case of SCP 03 protocol '03') and the secure channel protocol 'i' parameter used to start a secure channel session. The sequence counter is present only if SCP03 is configured for pseudo-random challenge generation.

[0050] exist Figure 2 In the INITIALIZE UPDATE command and the INITIALIZE UPDATE reply according to [1] include confidential data, in particular a key version number and a key identifier of the secret card static encryption assigned to the card and securely stored in the card. Providing such confidential data in the command carries the risk of the confidential data being disclosed to unauthorized entities.

[0051] In more detail, since in the INITIALIZE UPDATE command, the card-external entity sends key information such as key version and key identifier (key index) in a common format, an attacker can easily find out information about which key version and key ID will be used for subsequent mutual authentication. Based on the key version in this INITIALIZE UPDATE command, an attacker can easily find out which SCP protocol is being used.

[0052] Further based on Figure 2 , the card generates a card challenge. To this end, the following card challenge input is provided: a 12-byte tag comprising 11 bytes with the value "00", followed by a one-byte derived constant as defined in [1], 2 bytes specifying the length in bits, a 1-byte counter, a 3-byte sequence counter, and the application identifier AID of the card application. The card challenge input is processed by the card's cryptographic function, applying the card's static cryptographic key. The leftmost eight bytes of the output of said processing are the card challenge.

[0053] Further based on Figure 2 , the card generates a session key. To this end, an eight-byte long host challenge, an eight-byte long card challenge and an additional byte are processed by the card's cryptographic function using the card's static encryption key. The output of the processing is the session key S-ENC.

[0054] Figure 3 A secure channel initiation according to an embodiment of the present invention is shown. Figure 2 The steps and elements that may be shown are similar to Figure 2 .according to Figure 3 The secure channel is started and Figure 2 The known process is shown with the following differences.

[0055] according to Figure 3, the INITIALIZE UPDATE command specifically includes the SCP key identification of the present invention in the code field P1, if the value of P1 is lower than a preset value (e.g. 0xFF), or if the value of P1 is equal to the preset value (e.g. 0xFF), then the SCP key identification of the present invention is included in the preset value and in the additional data field. The SCP key identification of the present invention is an additional security parameter. It can have a length of, for example, one byte to ten bytes. In addition, in the data field, a host challenge generated by the host is also provided. If P1 is filled with a known key version, P2 is also filled with a known key identifier. However, if P1 is the preset value and does not contain a known key version, the key identifier is not provided in P2 either.

[0056] according to Figure 3 , the INITIALIZE UPDATE reply includes one byte of secure channel information instead of three bytes of key information.

[0057] Further based on Figure 3 , the card generates a card challenge, where the difference from the prior art is that the two-byte key version and key index also find entries in the card challenge. To this end, the following card challenge input is provided: a 12-byte tag, which includes (or consists of) 11 bytes with a value of "00", followed by a one-byte derived constant as defined in [1], 2 bytes specifying the length in bits, a 1-byte counter, a 3-byte sequence counter, and the application identifier AID of the card application, and in addition, according to the embodiment of the present invention, a two-byte key version and key index associated with the SCP key identification of the present invention. The card challenge input is processed by the card's cryptographic function, applying the card's static cryptographic key. The leftmost eight bytes of the output of the processing are the card challenge.

[0058] Further based on Figure 3 , the card generates a session key. To this end, an eight-byte long host challenge, an eight-byte long card challenge and an additional byte are processed by the card's cryptographic function using the card's static encryption key. The output of the processing is the session key S-ENC.

[0059] Figure 4The SCP key identifier of the present invention and other security parameters that need to be provided to the card and the external entity before starting the secure channel according to one embodiment of the present invention are shown. Before starting the secure channel, the following mandatory security parameters need to be provided to the card and the external entity: a security parameter tag with a length of one byte; a length tag with a length of one byte; a length of the SCP key identifier with a length of 1 byte; an SCP key identifier of the present invention, which can have a length from one byte to ten bytes; a length of the key version / key identifier with a length of one byte; a key version / key identifier with a length of two bytes. Deviations in the byte length of some or all security parameters are possible, and the lengths of some or all security parameters may need to follow fixed values ​​preset in the standard in order to ensure interoperability of the card and host with the cards and hosts of other market participants.

[0060] exist Figure 4 In an embodiment, before establishing a secure channel between the card and the host using the SCP key identification, Figure 4 The security parameters need to be pre-configured to the card and the host.

[0061] Referenced Documents

[0062] [1][GPC_SPE_014] Global Platform Technology, Secure Channel Protocol '03', Card Specification v2.3-Amendment D, Version 1.1.2, March 2019.

Claims

1. A process for initiating a secure communication session between a card and a host, a static encryption key being assigned to the card and stored in the card, each of the card and the host providing a key version number and a key identifier of the static key, the process comprising the steps at the card: - receiving from the host an INITIALIZE UPDATE command including a host challenge, the host challenge being a value unique to the session; - generating a card challenge, said card challenge being a value unique to said session, whereby at least a static encryption key, key diversification data and a sequence counter of said card are processed with a first cryptographic function; - Generate session keys (S-ENC), where the card's static encryption key, host challenge and card challenge are processed with a second cryptographic function; - Calculate the card cryptogram using the session key (S-ENC); - Sending an INITIALIZE UPDATE reply to the host, including the card password, the sequence counter and the card challenge, so that the host can verify the card password; characterized in that: - each of the card and the host provides an SCP key identification associated with the key version number and the key identifier of the static encryption key of the card; - the INITIALIZE UPDATE command includes the SCP key identification and does not include the key version number and the key identifier; - To generate the card challenge, additionally processing the key version number and the key identifier with the first cryptographic function.

2. The process of claim 1, wherein: The SCP key identification is included in the data field of the INITIALIZEUPDATE command.

3. The method according to claim 1 or 2, wherein: - field P1 of the INITIALIZE UPDATE command comprises a fixed value, in particular 0xFF, instead of a key version number; and / or - Field P2 of the INITIALIZE UPDATE command comprises a fixed value, in particular 0xFF, instead of a key identifier.

4. The process according to any one of claims 1 to 3, wherein: The card comprises a card application, and wherein the session is initiated between the card application and the host, and wherein: - for generating the card challenge, an application identifier AID of the card application is additionally processed with the first cryptographic function.

5. The method according to any one of claims 1 to 4, wherein: Each of the card and the host provides some or all of the following security parameters: - Security parameter flags; -length; - length of the SCP key identifier; -SCP key identification; - length of the key version and / or key identifier; -Key version and / or key identifier.

Images