Secure element and method for mutual authentication of a secure element with a network entity

Abstract

A secure element for securely communicating over a communication network is provided. The secure element comprises a storage unit in which a set of computer readable instructions for mutual authentication of the secure element with an external entity, a static key pair and a receipt are stored. The secure element comprises a control unit configured to execute the set of computer readable instructions which configure the control unit to initiate a secure channel, generate at least one shared secret by performing an elliptic curve key agreement based on the static key pair, generate at least one session key for secure messaging over the secure channel based on the at least one shared secret and shared information, wherein the shared information comprises the receipt, determine a new receipt based on one of the at least one session key, and store the new receipt in the storage unit.

Description

Technical Field

[0001] This disclosure relates to a security element, a terminal device including the security element, and a corresponding method. This disclosure also relates to a non-transitory computer-readable medium storing related instructions. Background Technology

[0002] A large number of devices connect to existing communication networks every day, especially mobile communication networks. The number of connected devices, especially terminal devices or end (user) devices, is increasing at an accelerating rate, for example, attributable to the Fourth Industrial Revolution driven by the Internet of Things (IoT).

[0003] For secure communication over a communication network, the connected devices need to include a secure element. The secure element includes at least one security domain containing keys, profiles, PINs / PUKs, etc., and thus provides the connected device with tools upon which a secure communication channel can be established to the network entity. Establishing a secure communication channel requires authentication of the secure element, the participating external entity in the communication network, or ideally both. The latter is also known as mutual authentication, where the secure element authenticates to the network entity, and the network entity authenticates to the secure element. Authentication is achieved through the process of initiating a secure channel, providing the entity with assurance that it is communicating with an authenticated entity.

[0004] The Global Platform Card Specifications Amendment F (SCP11) specifies a secure channel protocol based on Elliptic Curve Cryptography (ECC) for mutual authentication. The Elliptic Curve Key Agreement (ECC) algorithm protocol is used for establishing AES session keys. Based on the type of ECC key used in authentication, SCP11 has three variants.

[0005] In the first variant SCP11a, two pairs of static keys and two pairs of temporary keys are used, for example, as described in NIST 800-56A as a “(cofactor) fully unified model, C(2e, 2s, ECC CDH) scheme”, for curves with a cofactor of 1.

[0006] In the second variant, SCP11b, two ephemeral key pairs and one static key pair are used. The network entity (often also referred to as the off-card entity (OCE)) does not have a static key pair. Instead, the OCE's ephemeral key pair is used twice.

[0007] In the third variant SCP11c, two static key pairs and one ephemeral key pair are used. The security domain of the secure element does not create ephemeral key pairs, and the static key pairs of the SD are used twice. This scheme is described in NIST 800-56A as "One-time pass through the unified model, C(1e, 2s, ECC CDH) scheme".

[0008] According to the SCP11c variant, the security domain includes only one static key pair used twice during ECC key negotiation. The static key is used to diversify the session key during the authentication process. This allows for the pre-computation of the probability of a session key that can be used across multiple security elements sharing the same static key. The OCE can pre-compute the session key, thus pre-computing authentication performed by the security domain using only knowledge of the public key of the static key stored in the security element. Therefore, offline scripts that include the pre-computed session key can be generated. For example, pushing application updates to a security element. Thus, the SCP11c variant can be used for authentication when managing a large number of connected devices, such as devices containing 1000 or more connections, without incurring significant overhead.

[0009] As a side effect, the SCP11c variant has several weaknesses compared to other variants. SCP11c does not provide perfect forward confidentiality because only a temporary key on the OCE side is used during authentication. Similarly, SCP11c does not provide anti-replay mechanisms. Therefore, any generated script can be executed by anyone as many times as possible during the lifetime of the secure element without any restrictions, since neither a counter that could prevent re-execution is used on the secure domain side, nor is a temporary key used. These shortcomings make SCP11c a less secure variant, vulnerable to potential attacks. Therefore, GlobalPlatform has set some restrictions to limit the impact of this flow: it prohibits application-specific protocol data units (e.g., deletion, key placement, setting state, etc.) of the SCP11c variant. It requires sophisticated mechanisms to restrict the commands executed when any authentication (ANY_AUTHENTICATED) is performed, such as the authorization mechanism within the tag "BF20" configured in the OCE certificate.

[0010] Even within these usage restrictions imposed by the global platform, the possibility of anyone re-executing offline scripts without restriction exposes the secure element and associated connected devices to further security-related risks. For example, a script used to install a new version of a mini-program might include a vulnerability discovered only some time after its first use. Therefore, the script would need to be replaced by a new script for installing the new mini-program version that includes the patched vulnerability. In this case, even after installing a version of the mini-program with the patched vulnerability, the old script that includes the vulnerability can still be executed.

[0011] While some suggestions exist to improve this situation, such as updating the public key of the OCE certificate's controlling authority, known as the PK.CA-KLOC key, for certificate verification, using a different OCE key, whitelisting serial numbers, and so on, these solutions remain insufficiently secure. None of them explicitly prevent the execution of any other scripts that have already been generated and contain pre-computed session keys. Furthermore, these solutions are not easy to implement or deploy because they require additional network functionality.

[0012] Therefore, there is a need to provide a secure element and a corresponding method suitable for mutual authentication including anti-replay mechanisms, while ensuring the authentication of the secure element via an offline script.

[0013] It may also be necessary to provide a safety element and a corresponding method configured to more securely execute the SCP11c variant for mutual authentication. Summary of the Invention

[0014] At least one of these objectives is achieved by the features of the independent claim. Furthermore, particularly advantageous embodiments are described in the dependent claims.

[0015] The core of this invention is based on the idea of ​​linking session keys derived from a secure element. This linking can be implemented into the secure element by deriving a new session key using a previous receipt calculated at the end of the key derivation process as input. In this way, the session key will be valid only once, and the script that generates these session keys can only be executed once.

[0016] According to one aspect of the invention, a secure element is provided for secure communication over a communication network (e.g., a mobile communication network). The secure element can be used in a connected device or terminal. The secure element includes a storage unit storing a set of computer-readable instructions, a static key pair, and a receipt for mutual authentication between the secure element and an external entity. The secure element includes a control unit configured to execute a set of computer-readable instructions that configure the control unit to: initiate a secure channel; generate at least one shared secret by performing elliptic curve key negotiation based on the static key pair; generate at least one session key for secure messaging over the secure channel based on the at least one shared secret and shared information, wherein the shared information includes a receipt; determine a new receipt based on one of the at least one session key; and store the new receipt in the storage unit.

[0017] According to another aspect of the invention, a secure element including a storage unit is provided, wherein a set of computer-readable instructions, static key pairs, and receipts for mutual authentication between the secure element and an external entity are stored. The secure element includes a control unit configured to execute a set of computer-readable instructions that configure the control unit to: initiate a secure channel; generate at least two shared secrets by performing elliptic curve key negotiation based on static key pairs and preferably on a static key pair and a temporary key of the external entity; generate at least four session keys for secure messaging over the secure channel based on the at least two shared secrets and shared information, wherein the shared information includes a receipt; determine a new receipt based on one of the at least four session keys; and store the new receipt in the storage unit.

[0018] According to another aspect of the present invention, a terminal for secure communication via a communication network is provided. The terminal includes a terminal control unit, a communication interface configured to communicate via a communication network, and a secure element operatively coupled to the control unit. The secure element includes a storage unit storing a set of computer-readable instructions, a static key pair, and a receipt for mutual authentication between the secure element and an external entity. The secure element includes a control unit configured to execute a set of computer-readable instructions that configure the control unit to: initiate a secure channel; generate at least one shared secret by performing elliptic curve key negotiation based on the static key pair; generate at least one session key for secure messaging via the secure channel based on the at least one shared secret and shared information, wherein the shared information includes the receipt; determine a new receipt based on one of the at least one session key; and store the new receipt in the storage unit.

[0019] According to another aspect of the present invention, a method is provided for enabling a secure element to mutually authenticate with an external entity. The method includes: initiating a secure channel; generating at least one shared secret by performing elliptic curve key negotiation based on a static key pair; generating at least one session key for secure messaging over the secure channel based on the at least one shared secret and shared information, wherein the shared information includes a receipt; determining a new receipt based on one of the at least one session key; and storing the new receipt in a storage unit.

[0020] According to another aspect of the invention, a non-transitory computer-readable medium is provided for storing encrypted computer-readable instructions, which, when decrypted and executed by a control unit of a secure element, cause the control unit of the secure element to: initiate a secure channel; generate at least one shared secret by performing elliptic curve key negotiation based on a static key pair; generate at least one session key for secure messaging over the secure channel based on the at least one shared secret and shared information, wherein the shared information includes a receipt; determine a new receipt based on one of the at least one session key; and store the new receipt in a storage unit.

[0021] A receipt can be a data structure. For example, it can be a sequence of bytes with a predetermined length and values ​​determined during a previous elliptic curve key negotiation. In other words, the receipt was determined during a previous mutual authentication process.

[0022] The security element, terminal, method, and / or associated non-transitory computer-readable medium are configured to perform mutual authentication, which is offline scriptable and protected against replay mechanisms.

[0023] Security elements, terminals, methods, and / or non-transitory computer-readable media may include one or more of the following features:

[0024] A static key pair can be a cryptographic key pair that includes a public part and a private part. In the following text, the public part of the cryptographic key pair may also be referred to as the public key, and the private part is correspondingly referred to as the private key.

[0025] External entities can also be referred to as remote entities or off-card entities (OCEs). External entities can be divided into remote entities that pre-compute data and local agents that forward data to the secure element (e.g., applications on terminal devices or connected devices). External entities can pre-compute commands or receive pre-computed commands from another entity.

[0026] The secure channel may be an SCP11c secure channel, preferably in accordance with the provisions of the Global Platform Secure Channel Protocol '11'-Revision F. The control unit may be configured to generate at least one session key, preferably at least four session keys, based on a mutual authentication command, and preferably, one of the session keys is used to calculate the receipt.

[0027] At least one shared secret may include a first shared secret (Shses) computed from a temporary OCE key (i.e., a temporary key of an external entity) and a static key pair of the secure element. At least one shared secret may include a second shared secret (Shsss) computed from the static key of the OCE key and the static key pair of the secure element. The first shared secret Shses and the second shared secret Shsss may be combined (particularly concatenated) into a single shared secret (ShS), which may be input into a key derivation function to generate at least one session key, preferably at least four session keys. The key derivation function may be specified as an ANSI x9.63 key derivation function (SHA-256).

[0028] The shared secret ShS generated by the elliptic curve key negotiation algorithm can be used as input to the key derivation or key generation process. The key and / or session key used to compute the receipt (which may contain the receipt key) can be derived from the shared secret as defined in the "X9.63 Key Derivation Function" in standard BSI TR-03111 version 2.0. This key derivation includes additional information about the key derivation algorithm, shared information, or also referred to as "SharedInfo". Shared information may include key usage qualifiers, such as those specified in label "95" of the mutual authentication command. Shared information may include key type e, such as those specified in label "80" of the mutual authentication command. Shared information may include key length e, such as those specified in label "81" of the mutual authentication command.

[0029] At least one session key may include a receipt key, through which a new receipt can be determined or calculated. At least one session key may include a secure channel C-MAC session key (S-MAC). At least one session key may include a secure channel R-MAC session key (S-RMAC). At least one session key may include a secure channel session key (S-ENC) for command and response encryption. At least one session key may include an optional session data encryption key (S-DEK). Session keys are generated to ensure that a different key set is used for each secure channel session.

[0030] A receipt can be generated using the exported receipt key and input data for the mutual authentication command, employing an algorithm based on the CMAC function specified in NIST SP800-3B. The control unit can be configured to provide the receipt as a response to the mutual authentication command and send it back to the network entity. The network entity can use the receipt to verify the correctness of the session key calculation.

[0031] The control unit can also be configured to receive mutual authentication commands, wherein the option to include the identifiers of external entities and security elements in the shared information is enabled. The control unit can be configured to generate at least one session key based on the mutual authentication commands.

[0032] The mutual authentication command can be specified in the Global Platform Technology Secure Channel Protocol '11' Card Specification v2.3-Revision F (GP CS Amd F) and can include identifiers and parameters related to the secure channel, also referred to as SCP identifiers and SCP parameters, respectively. For example, the SCP11c variant can be activated in the mutual authentication command by setting bits 1 and 2 of the SCP identifier specified in byte 1 of label '90' according to Table 7-15 of GP CS Amd F v1.4 in conjunction with Table 7-2 of GP CS Amd F v1.4. The option to include the identifiers of external entities and secure elements in the generation of at least four session keys can be enabled by setting bit 3 of the SCP parameter specified in byte 2 of label '90' of the mutual authentication command according to Table 7-2 of GP CS Amd F v1.4. The identifier of the external entity can include the host ID, preferably the length and value of the host ID. The host ID can be specified in label '84' ​​of the mutual authentication command.

[0033] The identifier of the secure element can be provided by the subject identifier of the secure element's certificate, which contains the public key of the static key pair used during elliptic curve key negotiation. The control unit can also be configured to update the object identifier based on a receipt. The control unit can be configured to subsequently update the signature of the certificate.

[0034] The certificate can be designated as CERT.SD.ECKA according to GP CS Amd F. The subject identifier can be specified in the label "5F20" in the CERT.SD.ECKA certificate. The subject identifier can represent a common identifier of a group of cards sharing the same CERT.SD.ECKA, also known as the card group ID.

[0035] This aspect of the disclosure has the following advantages: it allows for linking receipts to subsequent key exports essentially within the currently valid GP CS Amd F.

[0036] The control unit can be further configured to sign the certificate using the private key of the control agency (preferably an intermediate control agency) for use in providing certificates to external entities.

[0037] To add a receipt to the subject identifier field of the CERT.SD.ECKA certificate, the SK.CA-KLOC.ECDSA key (preferably the SK.KA-KLOC.ECDSA key) can be stored in the storage unit of the secure element, so that the SK.CA-KLOC.ECDSA key (preferably the SK.KA-KLOC.ECDSA key) can be used to sign the updated certificate CERT.SD.ECKA.

[0038] This method reuses most of the current version of the GP CS Amd F specification, with commands and labels not modified in any way. Using the key of the intermediate control authority KA-KLOC reduces potential security issues associated with configuring SK.CA-KLOC.ECDSA as part of the configuration of a secure element (more precisely, the secure domain of the secure element).

[0039] The control unit can also be configured to receive mutual authentication commands, wherein the option to include receipts in shared information is enabled. The control unit can also be configured to store new receipts in the non-volatile memory of the storage unit.

[0040] According to GP CS Amd F, the option to include receipts in shared information can be a new option within the SCP parameters. This option can be enabled by setting an additional flag under label '90' of the input data for the mutual authentication command, preferably by setting bit 4 in byte 2 of Table 7-2 in GP CS Amd F v1.4 or bit 1 in new byte 3.

[0041] The shared information may include a receipt, preferably including the receipt's length and value. Therefore, the calculated receipt can be directly fed as input data into the next mutual authentication command. In other words, this method proposes adding new options to the SCP identifier and parameters to explicitly include the use of previously calculated receipts during the key export process.

[0042] When a mutual authentication command with this option enabled is received, the session key generation process is performed in the same manner as defined in GP CS Amd F, but during the key export process of the session key, a receipt is used and concatenated for the SCP11c variant in SharedInfo, specifically as the length and value of the previously calculated receipt.

[0043] The control unit can be configured to permanently store the calculated receipt, for example in the non-volatile memory of the storage unit, and if the option to include the receipt in the shared information is enabled, its use in the next subsequent authentication process is enabled.

[0044] Although the specifications for SCP identifiers and parameters need to be modified according to GP CS Amd F, the method according to this disclosure is the preferred method because it does not introduce any new security issues while preventing the replay mechanism of the SCP11 variant. Furthermore, according to this disclosure, the identifiers of external entities and security elements do not need to be included in the shared information.

[0045] The storage unit can also store a first receipt, which will be used as a receipt for the first mutual authentication between the secure element and an external entity in the communication network. The first receipt can be an initial receipt that can be used for the first authentication performed by the secure element. The first receipt may include a predetermined value. The first receipt may include a random value. The first receipt can be configured during the production phase of the secure element.

[0046] The control unit can also be configured to receive receipt requests from external entities. The control unit can be further configured to provide receipts to external entities for current mutual authentication between the security element and the external entity. The control unit can also be configured to provide receipts stored in a storage unit to external entities. While the card-removing entity can calculate receipts itself, new commands for retrieving stored receipts may be useful in allowing the card-removing entity to retrieve the most recently stored receipts when necessary.

[0047] The control unit can also be configured to receive a mutual authentication command, in which the option to include the identifier of the external entity, the identifier of the security element, and the receipt in the shared information is enabled. The control unit can be configured to generate at least one session key, preferably at least four session keys, based on the mutual authentication command. The new receipt can be stored in the non-volatile memory of the storage unit.

[0048] This option can be enabled by setting byte 2 to 3 under label '90' of the mutual authentication command, as shown in Table 7-15 of GP CSAmd F v1.4.

[0049] The options according to this disclosure may be variations of new options for SCP parameters introduced according to previous aspects of this disclosure. Instead of using new option parameters to incorporate receipts during key export, the method according to this disclosure redefines the byte-2 bit-3 accessible options of the SCP parameters according to Table 7-2 of GP CS Amd F v1.4 to include receipts in the key export. According to this disclosure, shared information may include identifiers of external entities, identifiers of secure elements, and receipts.

[0050] The control unit can be configured to provide an external entity with a flag indicating the completion of mutual authentication and / or the successful storage of a new receipt. This flag can indicate the end of mutual authentication, and thus indicate that a new receipt has been stored.

[0051] However, if the security domain and / or control unit of the security element does not have any offline script that includes indications of mutual authentication having reached its end, a new receipt can be stored immediately after calculation. This method ensures that the same offline script will not be sent more than once, regardless of the circumstances. However, in the case of an interruption before script completion, storing the receipt directly after its generation will prevent the re-execution of the same offline script. Therefore, the offline script may still be incomplete. Furthermore, when considering a large number of connected devices, the same offline script may execute successfully in the security elements of some connected devices while (permanently) failing in the security elements of other connected devices, resulting in inconsistencies. The offline script can be a static command script.

[0052] The control unit can be configured to generate at least one session key and determine new receipts within an atomic transaction. The control unit can also be configured to store the new receipts once a commit transaction is received during the execution of the atomic transaction.

[0053] An atomic transaction can be triggered by the PERFORM TRANSACTIONOPEARATION command defined in GP CS Amd F, serving as the point for storing receipts. The PERFORM TRANSACTIONOPEARATION command can be used to generate and manage the creation of new card content within an atomic transaction, which can be used to prevent incomplete card content setup in the event of an interruption.

[0054] According to a preferred embodiment, if appropriate options are enabled in the input data of the mutual authentication command, receipts can be used during the key export process. However, the computational receipt stored in the storage unit can only be updated using the execute transaction operation command if the corresponding offline script execution is in progress. Specifically, the computational receipt can only be stored upon receiving a submitted transaction. In this way, it is ensured that at least the relevant portion of the offline script can be executed at least once.

[0055] The term "secure element" is synonymous with the terms "UICC", "eUICC", "iUICC", "User Identity Module", "Smart Card", "iUICC", "Integrated eUICC", "Integrated Secure Element", "Embedded Secure Element", "Secure Element", "SIM", "eSIM", or "iSIM". Secure elements also include USIM, TSIM, ISIM, CSIM, or R-UIM.

[0056] In the context of this invention, a secure element (SE) is a smaller electronic module with reduced resource footprint, which may have a control unit (microcontroller) and at least one interface (data interface) for communicating with instances located outside the secure element (such as terminal devices, servers, etc.). In the case of a secure element, this communication is preferably via a connectivity protocol, particularly protocols according to ETSI TS 102 221 or ISO-7816 standards.

[0057] Security elements can also be integrated portions of larger integrated circuits, such as modems or application processors. Such SEs are referred to as "integrated UICC," "integrated TRE," "integrated eUICC," or "integrated SE." This SE is permanently integrated into the SoC as an integrated processor block and can be connected via an on-chip bus. The SE has, for example, internal or external secure non-volatile memory regions where identity data is securely placed to prevent tampering and / or misuse attempts during network identification and / or authentication.

[0058] In one embodiment, the safety element can be operated by means of a terminal device, thus the SE in this embodiment is self-sufficient except for power supply signals such as supply voltage, clock, and reset. The safety element can then have an interface (data interface, communication interface) for communicating with the terminal device, into which the safety element can be inserted to be ready for operation. This communication is preferably via a connection protocol, particularly a protocol according to ETSI TS 102 221 or ISO-7816 standards.

[0059] A terminal device suitable for secure communication via a mobile communication network is also provided. The terminal device includes the security element described above, and a communication interface suitable for communication via a communication network.

[0060] The terminal device can be adapted to forward data packets between security elements and network entities.

[0061] A system for secure communication via a communication network is also provided. This system includes a terminal device and a card-removing entity.

[0062] The terminal device includes the security element and communication interface as described above. The terminal device is configured to receive authentication requests from external entities or to transmit authentication requests from the security element to external entities to initiate a mutual authentication process with the external entities.

[0063] External entities are configured to send authentication requests to or receive active authentication requests from secure elements from the terminal device, participate in the mutual authentication process, and establish secure communication channels to the communication interface of the terminal device.

[0064] It also provides corresponding methods.

[0065] The method may further include receiving a mutual authentication command, wherein an option is enabled to include the identifier of the external entity and the identifier of the secure element in the shared information, wherein the generation of at least one session key (preferably at least four session keys) is based on the mutual authentication command. In a preferred embodiment, the method may further include receiving a perform security operation command prior to the mutual authentication command to prepare for key derivation to be performed under the mutual authentication command. The identifier of the secure element may be provided by the subject identifier of the secure element's certificate, which contains the public key of the static key pair used during elliptic curve key negotiation. The method may further include updating the subject identifier based on a receipt.

[0066] The method may also include receiving a mutual authentication command, wherein the option to include the receipt in the shared information is enabled. The new receipt may be permanently stored in the non-volatile memory of the storage unit.

[0067] The method may further include: receiving a mutual authentication command, in which the mutual authentication command enables an option to include the identifier of the external entity, the identifier of the security element, and the receipt in the shared information, wherein the generation of at least one session key is based on the mutual authentication command. The new receipt may be permanently stored in the non-volatile memory of the storage unit.

[0068] The method generates at least one session key, preferably at least four session keys, and determines that the new receipt can be executed within an atomic transaction. The method may also include storing the new receipt once a commit transaction is received during the execution of the atomic transaction. Attached Figure Description

[0069] The invention, or other embodiments and advantages thereof, are explained in more detail below with reference to the accompanying drawings, which illustrate only embodiments of the invention. The same parts in the drawings are given the same reference numerals. Elements drawn with dashed lines are considered optional.

[0070] The accompanying drawings should not be considered to be of true scale, but rather the various elements of the drawings may be shown in an exaggerated or exaggeratedly simplified form.

[0071] Figure 1 An exemplary embodiment of a security element according to one aspect of this disclosure is shown.

[0072] Figure 2 An exemplary embodiment of a system according to one aspect of this disclosure is shown.

[0073] Figure 3A sequence diagram of a method for mutually authenticating a security element with an external entity of a communication network according to one aspect of this disclosure is shown.

[0074] Figure 4 A high-level flowchart for generating at least four session keys is shown according to one aspect of this disclosure. Detailed Implementation

[0075] according to Figure 1 The security element SE may include a storage unit SU and a control unit CU. The security element SE may include a security domain (not shown). A static key pair (not shown) may be stored in the storage unit SU. The static key pair may include a private key SK.SD.ECKA (see...). Figure 4 Receipt 8D can be stored in storage unit SU. Static key pairs and receipt 8D can be accessed through security domains. Static key pairs can be used during elliptic curve key negotiation. Receipt 8D can be a byte string representing a receipt from a previously successfully completed authentication process. Receipt 8D can be stored directly in the storage unit. Receipt 8D can also be stored within the subject identifier of the certificate CERT.SD.ECKA, which contains the public key of the static key pair used during elliptic curve key negotiation.

[0076] In addition, a set of computer-readable instructions for mutual authentication between the security element and external entities in the communication network can be stored in the storage unit SU.

[0077] The control unit (CU) of a Secure Element (SE) can be configured to initiate a secure channel session. Initiating a secure channel can refer to receiving a request from an external entity (OCE) to perform a secure operation. Initiating a secure channel may include receiving the external entity's certificate CERT.OCE.ECKA, verifying the certificate CERT.OCE.ECKA, and, if successful, extracting the external entity's public key PK.OCE.ECKA from the certificate CERT.OCE.ECKA. Initiating a secure channel may also include providing a response to the external entity (OCE) to perform a secure operation.

[0078] After performing a security operation and before performing Elliptic Curve Key Negotiation (ECKA), the control unit (CU) of the security element can be configured to receive a temporary key from the external entity (OCE) via a mutual authentication command.

[0079] The control unit CU of the secure element SE can be configured to generate at least one shared secret ShSes, ShSss, and ShS by performing elliptic curve key negotiation (ECKA) based on a static key pair. The ECKA can additionally be based on the public key PK.OCE.ECKA of the external entity OCE and the received temporary key of the external entity OCE.

[0080] The control unit CU of the secure element SE can be configured to generate at least four session keys for secure messaging over a secure channel based on at least two shared secrets and shared information, wherein the shared information includes receipt 8D. At least one session key may also include a receipt key (not shown), which the external entity OCE can use to verify the correctness of the receipt, thereby verifying the key derivation performed by the secure element SE.

[0081] The control unit CU of the security element SE can be configured to determine a new receipt 8D* based on one of at least one session key. The control unit CU of the security element SE can preferably be configured to determine a new receipt 8D based on a receipt key.

[0082] The control unit CU of the security element SE can be configured to store a new receipt 8D* in the storage unit. The control unit CU of the security element SE can be configured to update the receipt 8D in the storage unit based on the newly determined receipt 8D*. Preferably, in each case, only one receipt 8D, 8D* is stored in the storage unit SD.

[0083] The control unit CU of the safety element SE can communicate via the terminal device TD, and so on. Figure 2 As shown.

[0084] Figure 2 An exemplary embodiment of a system SY according to one aspect of this disclosure is shown.

[0085] System SY may include a safety element SE, such as regarding Figure 1 The security element SE can be hosted in the terminal device TD. The system SY can also include an external entity OCE. The external entity OCE can communicate with the terminal device TD via the terminal device's communication interface CI. The security element SE can protect the communication channel between the terminal device TD and the external entity OCE.

[0086] The external entity OCE can perform a key export corresponding to the key export performed by the control unit CU of the security element SE. The external entity OCE can determine the new receipt 8D* itself and / or receive the new receipt 8D* from the security element SE, particularly via the communication interface CI of the terminal device TD.

[0087] Figure 3A sequence diagram of a method for mutual authentication between a security element SE and an external entity OCE according to one aspect of this disclosure is shown.

[0088] This method may involve a security element (SE), a terminal device (TD) hosting the security element (SE), and an external entity (OCE). The method is described below from the perspective of the security element (SE).

[0089] The method may include receiving and performing a security operation from an external entity OCE. In the first step S10, the command may instruct the security element SE to initialize a security channel or a security channel session.

[0090] In response to the first step, the Secure Element (SE) can receive a mutual authentication request or command. The input to the mutual authentication command may include SCP identifiers and parameters that can be specified based on GP CS Amd F v1.4, Table 7-2. SCP identifiers and parameters can be accessed via label '90' of the ECKA (label 'A6') control reference template. Exemplary configurations of SCP identifiers and parameters according to one aspect of this disclosure are summarized below in Table 1.

[0091]

[0092] Table 1

[0093] If byte 2 (the second row in Table 1) is set to b3, the host ID can be provided under label '84' ​​in the data field of the mutual authentication command.

[0094] According to GP CS Amd F, the key session export process should include at least the following data from the mutual authentication command as shared information (SharedInfo): key usage qualifier (label '95'); key type (label '80'); key length (label '81').

[0095] Additionally, when the “Include host and card IDs during key export” option is enabled in the SCP parameters of the mutual authentication command, the following data should be concatenated for the SCP11c variant in SharedInfo during the key export process of the session key: the length and value of the host ID from the mutual authentication command (label '84'); the length and value of the card group ID (the principal identifier in CERT.SD.ECKA - label '5F20', as defined in Table 3-6 of GP CS Amd A).

[0096] According to GP CS Amd F, a group ID is "a public identifier for a group of cards sharing the same CERT.SD.ECKA". It is designed to identify a group of cards sharing the same credentials. Therefore, using the host and group ID options, a session key can be calculated only for a specified group ID.

[0097] The card group ID is defined as the subject identifier (label '5F20') value from the certificate CERT.SD.ECKA. This certificate contains the public key of a static key pair stored in the storage unit SU of the secure element SE and used during key negotiation ECKA. The certificate CERT.SD.ECKA can be signed by the SK.CA-KLCC.ECDSA key (or SK.KA-KLCC.ECDSA).

[0098] According to the first aspect of this disclosure, the configuration of the SCP identifier and the parameters used for the mutual authentication command can be specified as shown in Table 1. When the "Include Host and Card Group IDs during Key Export" option (byte 2 and bit 3 of the SCP identifier and parameters provided in the mutual authentication command according to Table 1) is selected, HostID-LV (length-value pair) and Card Group ID-LV are included as inputs for the session key export. The HostID is provided as part of the data in the mutual authentication command, and the Card Group ID is the value of the subject identifier (tag 5F20) in the certificate CERT.SD.ECKA. Once the subject identifier of the certificate CERT.SD.ECKA is calculated, it can be updated using receipt 8D*. Therefore, the signature of the certificate can be recalculated. Thus, the new receipt 8D* can be used in subsequent authentication processes.

[0099] In order to add a new receipt 8D* to the subject identifier field of the certificate CERT.SD.ECKA, the security element SE, and in particular its security domain, should be configured to have the private key SK.CA-KLOC.ECDSA of the control authority for the OCE certificate, or preferably the private key SK.KA-KLOC.ECDSA of the intermediate control authority, to sign the updated certificate CERT.SD.ECKA.

[0100] The method further includes a second step S20, preferably executed in response to a mutual authentication command, according to which at least one shared key is generated by performing elliptic curve key negotiation based on a static key pair.

[0101] The method also includes a third step S30, which is based on the second step S20 and involves generating at least one session key for secure messaging over a secure channel based on at least one shared secret and shared information. The shared information includes receipt 8D. By linking the previously calculated receipt 8D to the input of the third step S30, a different session key can be generated during each authentication, even within the SCP11c variant.

[0102] Used according to Figure 3 The third step S30, which involves generating at least one session key, is also part of the publicly disclosed method. Figure 4 It is shown as a high-level flowchart.

[0103] Based on the second and third aspects, Receipt 8D can be directly input as an additional parameter for shared information. To implement this input, modifications to Table 1 above are proposed.

[0104] According to a second aspect of this disclosure, the SCP identifier and parameters can be enriched by setting bit 4 of byte 2 to indicate that the stored receipt 8D is included, as shown in Table 2 below.

[0105]

[0106] Table 2

[0107] When a mutual authentication command is received with this option enabled, the session calculation process can be performed in the same manner as defined in GP CSAmd F, but during the key export process of the session key, the receipt will be used and concatenated for the length and value of the previously calculated receipt 8D in the SCP11c variant in SharedInfo.

[0108] If the option to include receipts during the key export process is selected, the newly calculated receipt 8D* will be permanently stored for use in the next authentication process.

[0109] According to the third aspect of this disclosure, SCP identifiers and parameters (specifically the "Include host and deck IDs during key export" option) can be applied to include receipts. This method is a variation of the method in the second aspect ("Include receipts during key export"). Instead of using receipt 8D during key export, the new option parameter can be redefined as "Include host and deck IDs during key export" to include receipt 8D during key export. The meaning or definition of bit 3 of byte 2 in Table 1 can be redefined as "Include host, deck ID, and receipt during key export". During the key export process, the length and value of the previously calculated receipt can be additionally concatenated to the SharedInfo of the SCP11c variant.

[0110] During the authentication process, in step S40, the derived receipt key and shared information are used as input data, preferably using the CMAC function algorithm (NIST SP 800-3B), to generate a new receipt 8D*. The new receipt 8D* can be sent back as a response to a mutual authentication command, so the external entity OCE can use it to verify the correctness of the session key calculation.

[0111] In step S50, the generated receipt 8D* is stored. It is crucial to determine when the new receipt 8D* will be stored in the NVM memory by the control unit CU for subsequent calculations. Since it is impossible to know the end of the offline script (the security element SE has no indication that a script issued by the external entity OCE has reached its end), storing the new receipt 8D* immediately after calculation ensures that the script will not be sent more than once under any circumstances. However, in the event of an interruption or if the script is not completed, storing the new receipt 8D* directly after its generation will prevent any re-execution of the script.

[0112] Preferably, the Execute Transaction Operation command, as defined in GP CS Amd F, can be used as the point for storing the new receipt 8D*. The Execute Transaction Operation command is used to generate and manage the creation of new card content within an atomic transaction, which is useful for preventing incomplete card content setup in the event of an interruption. In the event of an interruption, a script rollback can be performed, allowing for new attempts to run the same script.

[0113] Preferably, a new receipt 8D* can only be stored if the received execution transaction operation contains P2=commit transaction. In this way, it is ensured that at least the relevant part of the script can be executed at least once. When storing a receipt using an execution transaction operation command, if the command does not exist in the script, the calculated receipt 8D* can be left unstored, thus rendering the anti-replay mechanism ineffective for that script.

[0114] In summary, this disclosure provides a solution for linking session keys exported through a secure element. This linking can be implemented into the secure element by exporting a new session key using a previously calculated receipt as input at the end of the key export process. In this way, the session key will be valid only once, and the scripts generated with these session keys can only be executed once.

[0115] List of reference numerals in the attached diagram:

[0116] SE safety element

[0117] SU storage unit

[0118] CU control unit

[0119] 4C At least one session key

[0120] 8D Receipt

[0121] 8D* New Receipt

[0122] TD terminal device

[0123] Communication interface of CI terminal device TD

[0124] OCE external entity

[0125] SY system

[0126] S10 initiates secure channel

[0127] S20 generates at least one shared secret

[0128] S30 generates at least one session key

[0129] S40 confirms new receipt 8D*

[0130] S50 Stores New Receipts

Claims

1. A safety element, comprising: A storage unit, wherein a set of computer-readable instructions, static key pairs, and receipts for mutual authentication between the security element and an external entity are stored; as well as A control unit configured to execute the set of computer-readable instructions that configure the control unit to: Initiate a secure channel; At least one shared secret is generated by performing elliptic curve key negotiation based on the static key pair; At least one session key for secure messaging over the secure channel is generated based on the at least one shared secret and shared information, wherein the shared information includes the receipt; A new receipt is determined based on one of the at least one session keys; as well as The new receipt is stored in the storage unit.

2. The safety element according to claim 1, wherein, The control unit is also configured to receive a mutual authentication command, in which the option to include the identifier of the external entity and the identifier of the security element in the shared information is enabled, wherein the control unit is configured to generate the at least one session key based on the mutual authentication command.

3. The safety element according to claim 2, wherein, The identifier of the secure element is provided by the subject identifier of the certificate of the secure element, the certificate containing the public key of the static key pair used during the elliptic curve key negotiation, and wherein the control unit is also configured to update the subject identifier based on the receipt.

4. The safety element according to claim 3, wherein, The control unit is also configured to sign the certificate using the private key of a control authority used to provide certificates for the external entity, the control authority preferably being an intermediate control authority.

5. The safety element according to claim 1, wherein, The control unit is also configured to receive a mutual authentication command, in which the option to include the receipt in the shared information is enabled. as well as The new receipt is stored in the non-volatile memory of the storage unit.

6. The safety element according to claim 5, wherein, The option is enabled by setting an additional flag under label '90' in the mutual authentication command.

7. The safety element according to claim 5, wherein, The shared information includes the receipt, and preferably includes the length and value of the receipt.

8. The safety element according to claim 1, wherein, The secure channel is an SCP11c secure channel, preferably as specified in the Global Platform Secure Channel Protocol '11'-Revision F, and wherein the control unit is configured to generate at least one session key, preferably at least four session keys, based on a mutual authentication command.

9. The safety element according to claim 1, wherein, The storage unit also stores a first receipt, which will be used as a receipt for the first mutual authentication between the security element and the external entity, wherein the first receipt includes a predetermined value.

10. The safety element according to claim 1, wherein, The control unit is also configured to receive a receipt request from the external entity and provide a receipt to the external entity for current mutual authentication between the security element and the external entity.

11. The safety element according to claim 1, wherein, The control unit is further configured to receive a mutual authentication command, wherein the mutual authentication command enables the option to include the identifier of the external entity, the identifier of the security element, and the receipt in the shared information, wherein the control unit is configured to generate the at least one session key based on the mutual authentication command; and The new receipt is stored in the non-volatile memory of the storage unit.

12. The safety element according to claim 11, wherein, The option is enabled by setting bit 3 under label '90' in the mutual authentication command.

13. The safety element according to claim 1, wherein, The control unit is configured to provide a flag to the external entity indicating that mutual authentication is complete and / or the new receipt is successfully stored.

14. The safety element according to claim 1, wherein, The control unit is configured to generate the at least one session key and determine the new receipt within an atomic transaction, and wherein the control unit is further configured to store the new receipt when a submitted transaction is received during the execution of the atomic transaction.

15. A method for enabling a secure element to mutually authenticate with an external entity, the secure element comprising a static key pair and a receipt, and the method comprising: Initiate a secure channel; At least one shared secret is generated by performing elliptic curve key negotiation based on the static key pair; At least one session key for secure messaging over the secure channel is generated based on the at least one shared secret and shared information, wherein the shared information includes the receipt; A new receipt is determined based on one of the at least one session keys; as well as The new receipt is stored in the storage unit.

16. The method of claim 15, further comprising: Receive a mutual authentication command, in which the option to include the identifier of the external entity and the identifier of the security element in the shared information is enabled, wherein the generation of the at least one session key is based on the mutual authentication command; and Preferably, the identifier of the security element is provided by the subject identifier of the certificate of the security element, the certificate containing the public key of the static key pair used during the elliptic curve key negotiation, and the method further includes updating the subject identifier based on the receipt.

17. The method of claim 15, further comprising: Receive a mutual authentication command, in which the option to include the receipt in the shared information is enabled. Storing the new receipt includes storing the new receipt in non-volatile memory.

18. The method of claim 15, further comprising: Receive a mutual authentication command, in which the option to include the identifier of the external entity, the identifier of the secure element, and the receipt in the shared information is enabled, wherein the generation of at least one session key is based on the mutual authentication command. Storing the new receipt includes storing the new receipt in non-volatile memory.

19. The method according to claim 15, wherein, The generation of at least one session key and the determination of the new receipt are performed within an atomic transaction, and the method further includes: The new receipt is stored when a submitted transaction is received during the execution of the atomic transaction.

20. A non-transitory computer-readable medium storing encrypted computer-readable instructions, said encrypted computer-readable instructions causing the control unit of the secure element to: Initiate a secure channel; At least one shared secret is generated by performing elliptic curve key negotiation based on the static key pair; At least one session key for secure messaging over the secure channel is generated based on the at least one shared secret and shared information, wherein the shared information includes the receipt; A new receipt is determined based on one of the at least one session keys; as well as The new receipt is stored in the storage unit.

Images