Method and process to securely update secure element

Abstract

To provide a suitable system and method for updating firmware of a secure element.SOLUTION: The present disclosure describes techniques for updating firmware of a secure element. The techniques include a plurality of pieces of processing that comprise: receiving, by a gateway device, a firmware file from a remote source; receiving, by a processing element implemented on the gateway device, ephemeral session specific key material for a first secure element implemented on the gateway device; dividing the firmware file into a plurality of data chunks; applying, by the processing element, the ephemeral session specific key material to a first data chunk among the plurality of data chunks to generate a first data packet; and sending, by the processing element, the first data packet to the first secure element.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates generally, but not exclusively, to gateways that include one or more secure elements. [Background technology]

[0002] Secure elements are typically used in many applications. A secure element includes hardware and / or software for performing cryptographic functions or processes such as encryption, decryption, signature generation, signature verification, and / or key generation. A secure element is contained within an explicitly defined perimeter that establishes the physical boundary of the cryptographic module and includes any processors and / or other hardware components that store and protect the software and firmware components of the cryptographic module. A secure element can take the form of (or include) a secure crypto-processor, a smart card, a secure digital (SD) card, a microSD card, a SIM card, and / or other cryptographic modules.

[0003] A secure element (SE) is a tamper-resistant platform that can securely host applications and their sensitive and cryptographic data according to rules and security requirements established by well-known trusted authorities. SE can also be thought of as a chip that provides a dynamic environment for securely storing data, securely processing data, and securely communicating with external entities. Summary of the Invention

[0004] In some particular embodiments, a system and method for updating firmware of a secure element is provided. In some embodiments, the system and method includes a gateway that receives a firmware file from a remote source. A processing element implemented in the gateway device receives ephemeral session specific key material for a first secure element implemented in the gateway device. The firmware file is split into a plurality of data chunks. The processing element applies the ephemeral session specific key material to a first data chunk of the plurality of data chunks to generate a first data packet and transmits the first data packet to the first secure element.

[0005] In some embodiments, the ephemeral session-specific key material includes an encryption key and a signature key, where the encryption key is used to encrypt the underlying data and the signature key is used to sign the encrypted data.

[0006] In some embodiments, the first data packet is generated by encrypting and signing the first data chunk using an encryption key and a signature key of the ephemeral session-specific key material.

[0007] In some implementations, the apply and send process is repeated for each of the multiple data chunks. In some implementations, the processing element includes a security enclave, in which case temporary session-specific key material is established between the first secure element and a remote source based on a master firmware key pair associated with the first secure element, and the firmware file is partitioned by the processing element.

[0008] In some embodiments, the security enclave is a trusted execution environments device and the master firmware key pair is stored in a remote source.

[0009] In some implementations, a processing element key pair is established between the remote source and the processing element, and temporary session-specific key material is transmitted from the remote source to the processing element using the processing element key pair.

[0010] In some implementations, the processing element includes a security enclave. In such cases, a processing element key pair is established between the first secure element and the processing element. The temporary session-specific key material is transmitted from the first secure element to the processing element using the processing element key pair.

[0011] In some implementations, the processing element includes a security enclave and the firmware file is partitioned by the processing element. In such a case, the processing element selects the second secure element as a manager and the first secure element as a target. A temporary session-specific key material is established between the first secure element and the second secure element, based on a first master firmware key pair associated with the first secure element. A processing element key pair is established between the second secure element and the processing element. The temporary session-specific key material is transmitted from the second secure element to the processing element using the processing element key pair.

[0012] In some embodiments, the security enclave is a trusted execution environment device, a first master firmware key pair is stored on a second secure element, and a second master firmware key pair associated with the second secure element is stored on the first secure element.

[0013] In some implementations, after the firmware file is transmitted to the first secure element, the firmware of the second secure element is updated. In some embodiments, the temporary session-specific key material is a first temporary session-specific key material. In such a case, the processing element selects the second secure element as the target and the first secure element as the manager. The second temporary session-specific key material is established between the first secure element and the second secure element, the establishment being performed based on a second master firmware key pair associated with the second secure element. The processing element key pair is established between the first secure element and the processing element. The second temporary session-specific key material is transmitted from the first secure element to the processing element using the processing element key pair.

[0014] In some embodiments, the processing element transmits the first data packet to the second secure element based on the second ephemeral session-specific key material. In some embodiments, the processing element includes a second secure element, and the firmware file is partitioned by a processor on the gateway. In such a case, the processor receives the firmware file. The processor selects the second secure element as a manager and the first secure element as a target. A temporary session-specific key material is established between the first secure element and the second secure element, the establishment being performed based on a first master firmware key pair associated with the first secure element. The first data chunk is provided from the processor to the second secure element. The second secure element is instructed to apply the temporary session-specific key material to the first data chunk and transmit the first data packet directly or indirectly to the first secure element.

[0015] In some implementations, after the firmware file is transmitted to the first secure element, the firmware of the second secure element is updated. In some embodiments, the temporary session-specific key material is a first temporary session-specific key material. In such a case, the processor selects the second secure element as the target and the first secure element as the manager. The second temporary session-specific key material is established between the first secure element and the second secure element, the establishment being performed based on a second master firmware key pair associated with the second secure element. The first data chunk is provided from the processor to the first secure element. The first secure element, which applies the second temporary session-specific key material to the first data chunk, is instructed to transmit the first data packet directly or indirectly to the second secure element.

[0016] In some embodiments, the processing element transmits the first data packet to the second secure element based on the second ephemeral session-specific key material. Updating the firmware of the secure element typically requires the remote server to know the key material of the secure element so that it can perform mutual authentication and generate multiple session key pairs to provide the firmware update to the secure element. After the remote server performs mutual authentication with the secure element, it must split the firmware update into multiple chunks and encrypt each file chunk sent to the secure element. The disclosed embodiments utilize a processing element implemented locally on the gateway device to receive firmware or multiple chunks of firmware from a remote source, locally encrypt such firmware with ephemeral session-specific key material, and provide the encrypted firmware to the secure element. This reduces the processing and storage resources of the remote server used to update the firmware of the secure element and enhances the overall system security.

[0017] This Summary is intended to provide an overview of the subject matter of the present patent application. It is not intended to provide an exclusive or exhaustive description of the subject matter of the present invention. The Detailed Description is included to provide further information regarding the present patent application. [Brief description of the drawings]

[0018] In the drawings, which are not necessarily drawn to scale, like numbers refer to like elements in different views. Like numbers with different letter suffixes may represent different instances of like elements. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document. [Figure 1] FIG. 1 is a block diagram of an example of a system for updating a secure element, according to various embodiments. [Figure 2A] 1 illustrates several processes for updating a secure element, according to various embodiments. [Figure 2B] 1 illustrates several processes for updating a secure element, according to various embodiments. [Diagram 3] 1 illustrates several processes for updating a secure element, according to various embodiments. [Figure 4] 1 illustrates several processes for updating a secure element, according to various embodiments. [Diagram 5] FIG. 2 is a flow diagram illustrating an exemplary process for updating a secure element, according to various embodiments. [Figure 6] FIG. 1 is a block diagram illustrating an example of a machine in which one or more embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] The present disclosure describes techniques for, among other things, updating firmware of a secure element. In particular, the disclosed techniques utilize a processing element implemented locally on a gateway device to receive firmware or chunks of firmware from a remote source, locally encrypt such firmware with ephemeral session-specific key material, and provide the encrypted firmware to the secure element. According to the disclosed embodiments, the processing and storage resources of the remote server used to update the firmware of the secure element are thereby reduced, enhancing the overall system security. A device is considered a secure element if it provides a certain level of security assurance with respect to the storage of sensitive key material and the implementation of cryptographic algorithms. Examples of good secure elements are smart cards used as SIM cards in mobile phones, security chips in credit / debit cards, user authentication devices in enterprises, etc.

[0020] Multiple secure elements are typically used in many applications. Typically, these secure elements are manufactured with master encryption and signature keys specific to a particular one of the multiple secure elements that are used to encrypt and sign firmware packets. These master encryption and signature keys (MFKPs) are typically used to perform mutual authentication between two entities that know the value of the MFKP to generate multiple session key pairs. As an example, a secure element can use the secure element-specific MFKP to perform mutual authentication with another device that also knows the secure element's MFKP. Mutual authentication can be performed without exchanging any key material between the devices. Once mutual authentication is performed, multiple session key pairs are generated and used by the secure element and the other device to encrypt and sign data exchanged between the two devices and to decrypt data. When the session is terminated, the multiple session key pairs can be revoked and deleted.

[0021] In some cases, it is necessary to update firmware that multiple secure elements use to operate. For example, firmware may need to be updated to remove bugs or add / remove features. Firmware files for updating multiple secure elements are typically stored on a remote server, such as a cloud-based server or service. Updating firmware of a secure element typically requires the remote server to know the MFKP of the secure element to be updated in order to perform mutual authentication and generate session key pairs so that it can provide the firmware update to the secure element. Also, because the storage resources available to the secure element are limited (e.g., a secure element cannot store multiple firmware files at one time, and in many cases cannot even store one firmware file), the updated firmware file needs to be sent to the secure element in multiple chunks, which may be equal or unequal. Thus, not only does the remote server need to know the MFKP of each secure element that is the target of the update, but the remote server also needs to split the firmware file into multiple chunks and encrypt and send the split chunks to the target secure element. A typical process for updating multiple secure elements places a significant burden (both processing and implementing secure key management practices) on the multiple remote sources from which the updated firmware files are received, consuming significant amounts of processing and storage resources.

[0022] To address the shortcomings of such typical approaches, the disclosed techniques utilize a processing element implemented locally on the gateway device to receive firmware or chunks of firmware from a remote source. The local processing element locally encrypts and signs such firmware using a temporary session-specific key material associated with the target secure element, and provides the encrypted and signed firmware to the target secure element. In some cases, the local processing element receives the temporary session-specific key material from a remote source. In some other cases, the local processing element receives the temporary session-specific key material from the target secure element to be updated or another secure element (including the MFKP of the target secure element) on the gateway device. In this way, the secure key management requirements of the remote server, such as processing resources, storage resources, and cloud resources, are reduced and are reserved for performing other functions. Furthermore, the security of providing updated firmware to the multiple secure elements is not compromised.

[0023] Although the following description refers to "multiple secure elements," the teachings of the present disclosure are equally applicable to any other suitable processing elements, such as a general-purpose microprocessor. That is, for purposes of explanation, the present disclosure is described in terms of "multiple secure elements," but any functions performed below to update the multiple secure elements can be performed by other processors instead of (or in addition to) the multiple secure elements.

[0024] FIG. 1 is a block diagram of an example of a system 100 for updating firmware of a secure element, according to various embodiments. The system 100 includes a remote source 110 and a gateway 120. The remote source 110 may include one or more servers and may be accessible over a local area network or a wide area network, such as the Internet. The remote source 110 includes firmware file updates for multiple secure elements. In some embodiments, the gateway 120 communicates with the remote source 110 to obtain firmware file updates and update firmware files of one or more secure elements 150, 152 implemented in the gateway 120. In some cases, rather than a server accessible over a network, the remote source 110 may be another mobile or storage device that includes and can provide copies of the firmware files to the gateway 120.

[0025] The gateway 120 includes a control circuit 140, a processing element 130, and one or more secure elements 150, 152. In some cases, the gateway 120 includes 16 secure elements. Each secure element 150, 152 of the gateway 120 is configured to perform the same function. In some implementations, the secure elements 150, 152 are implemented (in both hardware and software) to provide a higher level of security assurance than a typical general-purpose microprocessor. In some implementations, the secure elements 150, 152 are implemented as general-purpose microprocessors without providing a higher level of security assurance.

[0026] In some cases, each secure element 150, 152 is manufactured with a different set of MFKPs. Thus, to communicate and exchange data with the first secure element 150, a given device (e.g., the processing element 130) that knows the MFKP of the first secure element 150 performs mutual authentication with the first secure element 150 to generate temporary session-specific key material. The temporary session-specific key material is used by the first secure element 150 and the given device to encrypt and sign multiple packets of information. After a session between the given device and the first secure element 150 is terminated, the temporary session-specific key material is disabled and / or deleted. Multiple sub-sequence sessions and multiple communications between the first secure element 150 and the given device may require the given device and the first secure element 150 to perform mutual authentication again using the MFKP of the first secure element 150 to generate new temporary session-specific key material.

[0027] In some embodiments, the remote source 110 updates the firmware of the first secure element 150 using a security enclave, such as a trusted execution environment, implemented by the processing element 130. In such cases, the security enclave may execute applications that utilize crypto support to provide isolation from the overall computing environment. In some implementations, the security enclave implemented by the processing element 130 includes symmetric or asymmetric key material used by the security enclave to communicate with another device. The cryptographic processes and techniques used by the security enclave to communicate with multiple devices are different from the cryptographic processes implemented by the multiple secure elements of the gateway 120.

[0028] Specifically, the key material used by the security enclave is different from the MFKP of the first secure element 150. The key material used by the security enclave to communicate with other devices is called the TEEKP and includes encryption keys used to encrypt / decrypt data and signing keys used to sign encrypted data. The process for updating firmware of the first secure element 150 using the security enclave is shown in Figure 2A.

[0029] As shown in FIG. 2A, first, the remote source 110 performs mutual authentication with the first secure element 150 using the MFKP of the first secure element 150. In this case, the remote source 110 needs to know the MFKP of the first secure element 150 that is the target of the firmware update. After performing mutual authentication with the first secure element 150, a pair of ephemeral session specific key material (SFKP) is generated and stored by the remote source 110 and the first secure element 150. After generating the SFKP, either before generating the SFKP or simultaneously with generating the SFKP, the remote source 110 performs authentication (e.g., mutual authentication) with the security enclave implemented by the processing element 130 using the TEEKP of the security enclave. At this point, the remote source 110 has the key material necessary to communicate (exchange data) with the security enclave implemented by the processing element 130 and the SFKP necessary to communicate with the first secure element 150.

[0030] According to this embodiment, the remote source 110 transmits the SFKP of the first secure element 150 to the security enclave implemented by the processing element 130 using the TEEKP of the security enclave. Specifically, the remote source 110 encrypts and signs the SFKP of the first secure element 150 using the TEEKP of the security enclave implemented by the processing element 130. After the processing element 130 receives the SFKP from the remote source 110, the processing element 130 can decrypt the SFKP using the TEEKP and then communicate with the first secure element 150 for a particular session using the decrypted SFKP of the first secure element 150. After the remote source 130 transmits the SFKP to the processing element 130, before or at the same time, the remote source 130 transmits a firmware file with a firmware update to the processing element 130. The firmware file may be transmitted in an encrypted or unencrypted format. If transmitted in encrypted form, the remote source 130 may encrypt the firmware file using the TEEKP of the security enclave implemented by the processing element 130. There are many other formats for secure exchange of the firmware file (or chunks) available to the remote server and the processing element. In some cases, the firmware file may be split by the remote source 110 and transmitted from the remote source 110 to the processing element 130 in chunks. In some cases, the firmware file may be transmitted from the remote source 110 in a complete form and stored completely in the processing element 130. In such cases, the processing element 130 splits the firmware file into chunks and transmits them to the first secure element 150.

[0031] The security enclave implemented by the processing element 130 encrypts and signs each chunk of the firmware file using the SFKP of the first secure element 150 to generate a respective data packet. The security enclave implemented by the processing element 130 provides the data packets (e.g., the encrypted and signed chunks of the firmware file) to the first secure element 150. The security enclave implemented by the processing element 130 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element 150. After all chunks of the firmware file have been received by the first secure element 150, the SFKP is invalidated and / or deleted from storage by the first secure element 150.

[0032] FIG. 2B illustrates another process for transmitting a firmware file to the first secure element 150 using a security enclave implemented by the processing element 130. As illustrated in FIG. 2B, first, the remote source 110 performs mutual authentication with the first secure element 150 using the MFKP of the first secure element 150. In this case, the remote source 110 needs to know the MFKP of the first secure element 150 that is the target of the firmware update. After performing mutual authentication with the first secure element 150, a pair of ephemeral session specific key material (SFKP) is generated and stored by the remote source 110 and the first secure element 150. After generating the SFKP, or before, or simultaneously, the first secure element 150 performs authentication (e.g., mutual authentication) with the security enclave implemented by the processing element 130 using the TEEKP of the security enclave. At this point, the first secure element 150 has the necessary key material to communicate (exchange data) with the security enclave implemented by the processing element 130, and the first secure element 150 has generated the SFKP necessary to conduct multiple communications for the session.

[0033] According to this embodiment, the first secure element 150 transmits the SFKP of the first secure element 150 to the security enclave implemented by the processing element 130 using the TEEKP of the security enclave. Specifically, the first secure element 150 encrypts and signs the SFKP of the first secure element 150 using the TEEKP of the security enclave implemented by the processing element 130. After the processing element 130 receives the SFKP from the remote source 110, the processing element 130 can decrypt the SFKP using the TEEKP and then communicate with the first secure element 150 for the particular session using the decrypted SFKP of the first secure element 150. The remote source 130 transmits a firmware file with a firmware update to the processing element 130. The firmware file can be transmitted in an encrypted or unencrypted format. If transmitted in encrypted form, the remote source 130 encrypts the firmware file using the TEEKP of the security enclave implemented by the processing element 130. In some cases, the firmware file may be split by the remote source 110 and transmitted from the remote source 110 to the processing element 130 in multiple chunks. In some cases, the firmware file may be transmitted from the remote source 110 in a complete form and stored completely on the processing element 130. In such cases, the processing element 130 splits the firmware file into multiple chunks and transmits them to the first secure element 150.

[0034] The security enclave implemented by the processing element 130 encrypts and signs each chunk of the firmware file using the SFKP of the first secure element 150 to generate a respective data packet. The security enclave implemented by the processing element 130 provides the data packets (e.g., the encrypted and signed chunks of the firmware file) to the first secure element 150. The security enclave implemented by the processing element 130 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element 150. After all chunks of the firmware file have been received by the first secure element 150, the SFKP is invalidated and / or deleted from storage by the first secure element 150.

[0035] 3 illustrates another process for transmitting a firmware file to a first secure element 150 using two secure elements implemented in the gateway 120 and a security enclave implemented by the processing element 130. In this process, the second secure element 152 is used to provide the SFKP of the first secure element 150 to the security enclave implemented by the processing element 130. This process avoids the need for the remote source 110 to hold the MFKP of each target secure element it wishes to update, thereby reducing the storage resources and secure key management requirements of the remote source 110. This process also avoids the remote source 110 having to perform mutual authentication with the first secure element 150 to provide the firmware update, thereby reducing the number of communications made over the network and improving the overall efficiency and security of the system.

[0036] To implement the process shown in FIG. 3, each secure element implemented in the gateway 120 stores a first MFKP for performing mutual authentication and generating an SFKP for its own communications, and also stores a second MFKP of another secure element implemented in the gateway 120. For example, the first secure element 150 stores a first MFKP used by the crypto processor of the first secure element 150, and also stores a second MFKP of the second secure element 152. In some cases, each secure element implemented by the gateway 120 stores an MFKP for only one other secure element implemented by the gateway 120. In some cases, each secure element implemented by the gateway 120 stores an MFKP for all secure elements implemented by the gateway 120. That is, if the gateway 120 implements 16 different secure elements, each secure element stores 16 MFKPs, including the MFKP used by the corresponding crypto processor of the secure element.

[0037] 3, remote source 130 transmits a firmware file with a firmware update to processing element 130. In some cases, the firmware file may be split by remote source 110 and transmitted from remote source 110 to processing element 130 in multiple chunks. In some cases, the firmware file may be transmitted from remote source 110 in a complete form and stored completely on processing element 130. In some cases, processing element 130 splits the firmware file into multiple chunks locally on gateway 120.

[0038] After or before receiving the firmware file, the processing element 130 selects the first secure element 150 as the manager and the second secure element 152 as the target. The first secure element 150 performs mutual authentication with the second secure element 152 using the MFKP of the second secure element 152 stored in the first secure element 150. The mutual authentication between the two secure elements can be performed by those secure elements communicating with each other directly or by those secure elements communicating through the processing element 130 and / or the control circuitry 140. After performing mutual authentication with the first secure element 150, a first pair of temporary session-specific key materials (SFKP1) is generated and stored by the first secure element 150 and the second secure element 152. The first secure element 150 provides SFKP1 to the security enclave implemented by the processing element 130. That is, the first secure element 150 uses the TEEKP of the security enclave implemented by the processing element 130 to perform mutual authentication with the security enclave implemented by the processing element 130. At this point, the first secure element 150 has the necessary key material to communicate (exchange data) with the security enclave implemented by the processing element 130. The first secure element 150 encrypts and signs SFKP1 using the security enclave's TEEKP and provides SFKP1 to the security enclave implemented by the processing element 130.

[0039] The security enclave implemented by the processing element 130 provides each chunk of the firmware file to the second secure element (target) 152 using the security enclave's SFKP1 received from the first secure element (manager) 150. That is, the security enclave implemented by the processing element 130 encrypts and signs each chunk of the firmware file using the SFKP1 of the second secure element 152 to generate a respective data packet. The security enclave implemented by the processing element 130 provides the data packets (e.g., the encrypted and signed chunks of the firmware file) to the second secure element 152. The security enclave implemented by the processing element 130 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the second secure element (target) 152. After all chunks of the firmware file have been received by the second secure element (target) 152, SFKP1 is disabled and / or deleted by the security enclave implemented by the first and second secure elements 150, 152 and by the processing element 130.

[0040] At this point, after the second secure element 152 has been updated with the new firmware file, the security enclave implemented by the processing element 130 may designate the second secure element 152 as the manager and the first secure element 150 as the target. In this manner, the security enclave implemented by the processing element 130 may be used to update the firmware of the first secure element 150 in the same manner. That is, the first secure element 150 performs mutual authentication with the second secure element 152 using the MFKP of the second secure element 152 stored in the first secure element 150. Mutual authentication between the two secure elements may be performed by those secure elements communicating directly with each other or by those secure elements communicating via a security enclave implemented by the control circuitry 140 and / or the processing element 130. After performing mutual authentication with the first secure element 150, a second pair of temporary session-specific key materials (SFKP2) is generated and stored by the first secure element 150 and by the second secure element 152. The second secure element (manager) 152 provides SFKP2 to the security enclave implemented by the processing element 130. That is, the second secure element 152 uses the TEEKP of the security enclave implemented by the processing element 130 to perform mutual authentication with the security enclave implemented by the processing element 130. At this point, the second secure element 152 has the necessary key material to communicate (exchange data) with the security enclave implemented by the processing element 130. The second secure element 152 uses the TEEKP of the security enclave to encrypt and sign SFKP2 and provide it to the security enclave implemented by the processing element 130.

[0041] The security enclave implemented by the processing element 130 provides each chunk of the firmware file to the first secure element 150 using the security enclave's SFKP2 received from the second secure element 152. That is, the security enclave implemented by the processing element 130 encrypts and signs each chunk of the firmware file using the SFKP2 of the first secure element 150 to generate a respective data packet. The security enclave implemented by the processing element 130 provides the data packets (e.g., the encrypted and signed chunks of the firmware file) to the first secure element 150. The security enclave implemented by the processing element 130 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element 150. After all chunks of the firmware file have been received by the first secure element 150, SFKP2 is disabled and / or deleted by the security enclave implemented by the first and second secure elements 150, 152 and by the processing element 130.

[0042] 4 illustrates another process for transmitting a firmware file to a first secure element 150 using two secure elements and a control circuit 140 implemented in the gateway 120. In this process, the processing element 130 implements a given secure element (e.g., the second secure element 152). That is, all functions of the second secure element 152 are performed by the processing element 130, even though they are depicted as separate boxes in FIG. 1. In this process, the second secure element 152 is used to locally generate an SFKP for the first secure element 150 and securely provide chunks of firmware to the first secure element 150. This process avoids the need for the remote source 110 to hold an MFKP for each target secure element that it wants to update, thereby reducing storage resources of the remote source 110. This process also avoids the remote source 110 having to perform mutual authentication with the first secure element 150 to provide the firmware update, thereby reducing the number of communications made over the network and improving the overall efficiency and security of the system. This process also avoids the need to communicate or exchange temporary session-specific key material with another device (e.g., another processor or controller on the gateway 120).

[0043] To implement the process shown in FIG. 4, each secure element implemented in the gateway 120 stores a first MFKP for performing mutual authentication and generating an SFKP for its own communications, and also stores a second MFKP of another secure element implemented in the gateway 120. For example, the first secure element 150 stores a first MFKP used by the crypto processor of the first secure element 150, and also stores a second MFKP of the second secure element 152. In some cases, each secure element implemented by the gateway 120 stores an MFKP for only one other secure element implemented by the gateway 120. In some cases, each secure element implemented by the gateway 120 stores an MFKP for all secure elements implemented by the gateway 120. That is, if the gateway 120 implements 16 different secure elements, each secure element stores 16 MFKPs, including the MFKP used by the corresponding crypto processor of the secure element.

[0044] 4, the remote source 130 transmits a firmware file with a firmware update to the control circuitry 140. The control circuitry 140 may be any suitable processor and may or may not implement a security enclave. In some cases, the firmware file may be split by the remote source 110 and transmitted from the remote source 110 to the control circuitry 140 in multiple chunks. In some cases, the firmware file may be transmitted from the remote source 110 in a complete form and stored completely in the control circuitry 140. In some cases, the control circuitry 140 splits the firmware file into multiple chunks locally on the gateway 120.

[0045] After or before receiving the firmware file, the control circuit 140 selects the first secure element 150 as the manager and the second secure element 152 as the target. The first secure element 150 performs mutual authentication with the second secure element 152 using the MFKP of the second secure element 152 stored in the first secure element 150. The mutual authentication between the two secure elements can be performed by those secure elements communicating with each other directly or by those secure elements communicating indirectly through the control circuit 140. After performing mutual authentication with the first secure element 150, a first pair of temporary session-specific key materials (SFKP1) is generated and stored by the first secure element 150 and the second secure element 152. At this point, the first and second secure elements 150, 152 can securely exchange data encrypted and signed using SFKP1.

[0046] The control circuit 140 provides each chunk of the firmware file to the first secure element 150. The first secure element 150 encrypts and signs each chunk of the firmware file received from the element 150 using the SFKP1 of the second secure element 152 to generate a respective data packet. That is, the first secure element 150 provides the data packet (e.g., the encrypted and signed chunk of the firmware file) to the second secure element 152 directly or indirectly via the control circuit 140. When indirectly transmitting a data packet (e.g., the encrypted and signed chunk of the file), the first secure element 150 returns a data packet to the control circuit 140 that includes the chunk of the file encrypted and signed using the SFKP1 of the second secure element 152. The element 150 then transmits the data packet to the second secure element 152. That is, element 150 can act as a blind and dumb conduit for data exchanged between the first and second secure elements 150, 152. The first secure element 150 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the second secure element 152. After all chunks of the firmware file have been received by the second secure element 152, SFKP1 is invalidated and / or deleted from being stored by the first and second secure elements 150, 152.

[0047] At this point, after the second secure element 152 has been updated with the new firmware file, the control circuit 140 may designate the second secure element 152 as the manager and the first secure element 150 as the target. In this way, the second secure element 152 can be used to update the firmware of the first secure element 150 in the same manner. That is, the second secure element 152 performs mutual authentication with the first secure element 150 using the MFKP of the first secure element 150 stored in the second secure element 152. The mutual authentication between the two secure elements may be performed by those secure elements communicating directly with each other or by those secure elements communicating indirectly through the control circuit 140. After performing mutual authentication with the second secure element 152, a second pair of temporary session-specific key material (SFKP2) is generated and stored by the first secure element 150 and by the second secure element 152. At this point, the first and second secure elements 150, 152 can securely exchange data that is encrypted and signed using SFKP2.

[0048] The control circuitry 140 provides each chunk of the firmware file to the second secure element 152. The second secure element 152 encrypts and signs each chunk of the firmware file received from the element 150 using the SFKP2 of the first secure element 150 to generate a respective data packet. The second secure element 152 provides the data packets (e.g., encrypted and signed chunks of the firmware file) to the first secure element 150 directly or indirectly via the control circuitry 140. The second secure element 152 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element 150. After all chunks of the firmware file have been received by the first secure element 150, the SFKP2 is invalidated and / or deleted from storage by the first and second secure elements 150, 152.

[0049] FIG. 5 is a flow diagram illustrating an example process 500 for updating firmware of a secure element, according to various embodiments. In operation 510, the gateway device receives a firmware file from a remote source.

[0050] In operation 520, a processing element implemented in the gateway device receives temporary session-specific key material of a first secure element implemented in the gateway device. In operation 530, the firmware file is divided into multiple data chunks.

[0051] In operation 540, the processing element applies the temporary session-specific key material to a first data chunk of the multiple data chunks to generate a first data packet. In operation 550, the processing element transmits a first data packet to a first secure element.

[0052] FIG. 6 is a block diagram of an example machine 600 on which any one or more of the techniques (e.g., methods) described herein may be implemented. In alternative embodiments, machine 600 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked configuration, machine 600 may operate in the capacity of a server machine, a client machine, or both in a server-client network environment. In one example, machine 600 may operate as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Machine 600 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web appliance, an IoT device, an automotive system, an aerospace system, or any machine capable of executing instructions (sequential or otherwise) that define operations to be performed by the machine. Additionally, although only a single machine is illustrated, the term "machine" should also be interpreted to include any collection of machines that individually or collectively execute a set (or sets) of instructions to perform any one or more of the methods described herein, such as using cloud computing, software as a service (SaaS), or other computer cluster configurations.

[0053] Examples described herein may include or operate with logic, components, devices, packages, or mechanisms. Circuitry is a collection (e.g., set) of circuits embodied in tangible entities including hardware (e.g., simple circuits, gates, logic, etc.). The membership of the circuitry may be flexible over time and with the underlying hardware variability. Circuits may include members that perform specific tasks alone or in combination when operating. In one example, the hardware of the circuitry may have an invariable configuration (e.g., hardwired, etc.) and be configured to perform a specified operation. In one example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) that include computer-readable media that have been physically modified (e.g., magnetically modified, electrically modified, modified by the movable arrangement of immutable mass particles, etc.) to encode instructions for a particular operation. The connection of the physical components changes the underlying electrical properties of the hardware construct, for example, from an insulator to a conductor (or vice versa). The instructions enable the hardware involved (e.g., execution units or loading mechanisms) to perform a portion of a particular task during operation by creating members of the circuitry in the hardware through variable connections. Thus, the computer-readable medium is communicatively connected to other components of the circuitry when the device is operating. In one example, any of these physical components may be used in two or more members of two or more circuit configurations. For example, depending on the operation, multiple execution units may be used in a first circuit of a first circuit configuration at one time, and those execution units may be reused by a second circuit in the first circuit configuration, or those execution units may be used by a third circuit in the second circuit configuration at a different point in time.

[0054] The machine (e.g., computer system) 600 includes a hardware processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof, e.g., a memory controller, etc.), a main memory 604, and a static memory 606, some or all of which may communicate with each other via an interlink (e.g., a bus) 608. The machine 600 may further include a display device 610, an alphanumeric input device 612 (e.g., a keyboard), and a user interface (UI) navigation device 614 (e.g., a mouse). In one example, the display device 610, the alphanumeric input device 612, and the UI navigation device 614 may be touch screen displays. The machine 600 may further include a storage device 622 (e.g., a drive unit), a signal generator 618 (e.g., a speaker), a network interface device 620, one or more sensors 616, such as a global positioning system (GPS) sensor, wing sensors, mechanical device sensors, temperature sensors, ICP sensors, bridge sensors, audio sensors, industrial sensors, compasses, accelerometers, or other sensors, and one or more system-in-package data acquisition devices 690. The system-in-package data acquisition devices 690 may implement some or all of the functionality of the offset calibration system 100. The machine 600 may include an output controller 628, such as a serial (e.g., Universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection, for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0055] Storage device 622 includes a machine-readable medium on which is stored one or more set of data structures or instructions 624 (e.g., software) embodied or utilized by any one or more of the techniques or functions described herein. Instructions 624 may also reside, completely or at least partially, within main memory 604, within static memory 606, or within hardware processor 602 during execution thereof by machine 600. In one example, one or any combination of hardware processor 602, main memory 604, static memory 606, or storage device 621 may constitute a machine-readable medium.

[0056] Although the machine-readable medium is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) configured to store the instructions 624.

[0057] The term "machine-readable medium" may include any transitory or non-transient medium capable of storing, encoding, or transferring instructions, either transitory or non-transient, for execution by the machine 600, and enabling the machine 600 to execute any one or more of the techniques of this disclosure, or to store, encode, or transfer data structures used by or related to such instructions. Non-limiting examples of machine-readable media may include solid-state memory, and optical and magnetic media. In one example, a massive machine-readable medium includes a machine-readable medium with particles having a constant mass (e.g., rest mass). Thus, a massive machine-readable medium is not a transitory propagating signal. Particular examples of massive machine-readable media may include non-volatile memory, such as semiconductor memory devices and flash memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.), magnetic disks, such as internal hard disks and removable disks, magnetic optical disks, CD-ROM and DVD-ROM disks.

[0058] Instructions 624 (e.g., software, programs, operating system (OS), etc.) or other data stored in storage device 621 may be accessed by main memory 604 for use by hardware processor 602. Main memory 604 (e.g., DRAM) is a different type of storage device than storage device 621 (e.g., SSD), which is typically fast but volatile and therefore suitable for long-term storage, including during "off" states. Instructions 624 or data used by a user or machine 600 are typically loaded into main memory 604 for use by hardware processor 602. When main memory 604 becomes full, virtual space from storage device 621 can be allocated to supplement main memory 604. However, storage device 621 is typically slower than main memory 604, with write speeds typically at least twice as slow as read speeds, so the use of virtual memory can significantly degrade the user experience due to the latency of storage devices (as opposed to main memory 604, e.g., DRAM). Furthermore, using storage device 621 for virtual memory can significantly shorten the usable life of storage device 621.

[0059] The instructions 624 may further be transmitted or received over a communications network 626 using a transmission medium via a network interface device 620 utilizing any of a number of transport protocols (e.g., Frame Relay, Internet protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), HyperText Transfer Protocol (HTTP), etc.). Example communications networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone Service (POTS) network, and wireless data networks (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards referred to as Wi-Fi®, the IEEE 802.16 family of standards referred to as WiMax®), the IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, among others. In one example, the network interface device 620 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 626. In one example, the network interface device 620 may include multiple antennas to communicate wirelessly using at least one of Single-Input Multiple-Output (SIMO), Multiple-Input Multiple-Output (MIMO), or Multiple Input Single Output (MISO) techniques.The term "transmission medium" is intended to include any tangible or intangible medium capable of storing, encoding, or transmitting instructions for execution by machine 600, including digital or analog communication signals or other tangible or intangible media for enabling communication of such software.

[0060] Each of the non-limiting aspects or embodiments described herein may exist by itself or may be combined with one or more of the other embodiments in various permutations or combinations.

[0061] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the subject matter of the present invention may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described. However, the inventors also contemplate examples in which only the elements shown or described are provided. Moreover, the inventors also contemplate examples (or one or more aspects thereof) that use any combination or permutation of the elements shown or described in connection with the particular example (or one or aspects thereof) or in connection with any other example (or one or more aspects thereof) shown or described herein.

[0062] In the event of a conflicting usage between this specification and a document incorporated by reference, the usage in this specification will control. The terms "a" or "an" are used herein to include one or more, as is common in patent documents, independently of any other instances or usages of "at least one" or "one or more." The term "or" is used herein to mean non-exclusive, unless otherwise noted, or "A or B" includes "A but not B," "B but not A," and "A and B." The terms "including" and "in which" are used herein as the plain English equivalents of the respective terms "comprising" and "wherein." Also, in the appended claims, the terms "including" and "comprising" are open-ended, i.e., systems, devices, articles, compositions, formulations, or processes that include elements in addition to those listed after these terms in the claims are still considered to be within the scope of the claims. Moreover, in the appended claims, the terms "first," "second," and "third," etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0063] Examples of the methods described herein may be at least partially executed by a machine or computer. Some examples may include computer-readable or machine-readable media encoded with temporary or non-transient instructions operable to configure an electronic device to execute the methods described in the examples above. Implementations of such methods may include code, such as microcode, assembly language code, high-level language code, etc. Such code may include temporary or non-transient computer-readable instructions for executing various methods. The code may form part of a computer program product. Further, in one example, the code can be tangibly stored on one or more volatile, non-transient, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memory (RAM), read-only memory (ROM), etc.

[0064] The foregoing description should be construed as illustrative rather than limiting. For example, the above examples (or one or more aspects thereof) can be used in combination with each other. Other embodiments can be used by those of ordinary skill in the art who have reviewed the above description. The Abstract is provided to enable the reader to quickly identify the nature of the technical disclosure. It should be understood that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the above detailed description, various features may be grouped together to simplify the disclosure. This should not be construed as intending that an unclaimed disclosed feature is essential to any claim. Rather, the inventive subject matter may reside in less than all features of a particular disclosed embodiment. Thus, the appended claims are hereby incorporated into the detailed description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the inventive subject matter should be determined with reference to the appended claims, along with the full scope of equivalents to which the claims are entitled.

Claims

1. 1. A method for updating firmware of a secure element, comprising: Establishing temporary session-specific key material between a remote source and a first secure element implemented by a gateway device; establishing a secure session between the remote source and a processing element implemented by the gateway device; the gateway device receiving a firmware file from the remote source; receiving, by the processing element implemented in the gateway device, the ephemeral session-specific key material of the first secure element from the remote source via the secure session established between the remote source and the processing element to enable the processing element to securely communicate with the first secure element; the processing element applying the temporary session-specific key material to a first data chunk of the firmware file to generate a first data packet; the processing element transmitting the first data packet to the first secure element.

2. 2. The method of claim 1 , wherein the temporary session-specific key material includes an encryption key and a signature key, the encryption key being used to encrypt underlying data and the signature key being used to sign the encrypted data.

3. The method of claim 2 , wherein the first data packet is generated by encrypting and signing the first data chunk using the encryption key and the signature key of the temporary session-specific key material.

4. The method of any one of claims 1 to 3, further comprising repeating the applying and transmitting operations for each of a plurality of data chunks.

5. the processing element includes a security enclave; 5. The method of claim 1, further comprising: establishing the temporary session-specific key material between the first secure element and the remote source, the establishing being performed based on a master firmware key pair associated with the first secure element, and the firmware file being partitioned by the processing element.

6. the security enclave is a trusted execution environment device, and the master firmware key pair is stored in the remote source; establishing a processing element key pair between the remote source and the processing element; The method of claim 5 , further comprising transmitting the temporary session-specific key material from the remote source to the processing element using the processing element key pair.

7. establishing a processing element key pair between the first secure element and the processing element; 6. The method of claim 5, further comprising transmitting the temporary session-specific key material from the first secure element to the processing element using the processing element key pair.

8. the processing element includes a security enclave, the firmware file is partitioned by the processing element; the processing element selecting a second secure element as a manager and selecting the first secure element as a target; establishing the temporary session-specific key material between the first secure element and the second secure element, the establishing being performed based on a first master firmware key pair associated with the first secure element; establishing a processing element key pair between the second secure element and the processing element; 8. The method of claim 1, further comprising: transmitting the ephemeral session-specific key material from the second secure element to the processing element using the processing element key pair, wherein the security enclave is a trusted execution environment device, the first master firmware key pair is stored on the second secure element, and a second master firmware key pair associated with the second secure element is stored on the first secure element.

9. The method of claim 8 , further comprising updating firmware of the second secure element after the firmware file is transmitted to the first secure element.

10. the temporary session-specific keying material is a first temporary session-specific keying material; the processing element selecting the second secure element as the target and the first secure element as the manager; establishing second ephemeral session-specific key material between the first secure element and the second secure element, the establishing being performed based on a second master firmware key pair associated with the second secure element; establishing a processing element key pair between the first secure element and the processing element; 10. The method of claim 9, further comprising transmitting the second ephemeral session-specific key material from the first secure element to the processing element using the processing element key pair.

11. 11. The method of claim 10, further comprising the processing element transmitting the first data packet to the second secure element based on the second ephemeral session-specific key material.

12. the processing element includes a second secure element, the firmware file being partitioned by a processor on the gateway device; receiving the firmware file by the processor; the processor selecting the second secure element as a manager and the first secure element as a target; establishing the temporary session-specific key material between the first secure element and the second secure element, the establishing being performed based on a first master firmware key pair associated with the first secure element; providing the first data chunk from the processor to the second secure element; 12. The method of claim 1, further comprising instructing the second secure element to apply the temporary session-specific key material to the first data chunk and to transmit the first data packet directly or indirectly to the first secure element.

13. updating firmware of the second secure element after the firmware file has been transmitted to the first secure element, the ephemeral session-specific material being a first ephemeral session-specific key material; the processor selecting the second secure element as the target and the first secure element as the manager; establishing second ephemeral session-specific key material between the first secure element and the second secure element, the establishing being performed based on a second master firmware key pair associated with the second secure element; providing the first data chunk from the processor to the first secure element; 13. The method of claim 12, further comprising instructing the first secure element to apply the second ephemeral session-specific key material to the first data chunk and transmit the first data packet directly or indirectly to the second secure element.

14. 14. The method of claim 13, further comprising the processing element transmitting the first data packet to the second secure element based on the second ephemeral session-specific key material.

15. 1. A system for updating firmware of a secure element, comprising: A processing element implemented in the gateway device and configured to perform a number of operations, The plurality of operations include: establishing temporary session-specific key material between a remote source and a first secure element implemented by the gateway device; establishing a secure session between the remote source and the processing element; the gateway device receiving a firmware file from the remote source; receiving, by the processing element implemented in the gateway device, the ephemeral session-specific key material of the first secure element from the remote source via the secure session established between the remote source and the processing element to enable the processing element to securely communicate with the first secure element; the processing element applying the temporary session-specific key material to a first data chunk of the firmware file to generate a first data packet; the processing element transmitting the first data packet to the first secure element.

Images