Method and process for securely updating a secure element - Patent Application 20070122997

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. The 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. SEs can also be thought of as chips that provide 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, systems and methods are provided for updating firmware of a secure element. In some embodiments, the systems and methods include 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 divided into multiple data chunks. The processing element applies the ephemeral session-specific key material to a first data chunk of the multiple data chunks to generate a first data packet and transmits the first data packet to the first secure element.

[0005] In some embodiments, the temporary 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 temporary 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 a second secure element as a manager and the first secure element as a target. 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, and the 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 sent to the first secure element, the firmware of the second secure element is updated. In some embodiments, the temporary session-specific key material is first temporary session-specific key material. In such cases, the processing element selects the second secure element as the target and the first secure element as the manager. Second temporary session-specific key material is established between the first secure element and the second secure element, based on a second master firmware key pair associated with the second secure element. A 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 temporary 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. 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 sent to the first secure element, the firmware of the second secure element is updated. In some embodiments, the temporary session-specific key material is first temporary session-specific key material. In such cases, the processor selects a second secure element as the target and the first secure element as the manager. 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 send 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 temporary session-specific key material. Updating the firmware of a 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. 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, enhancing overall system security.

[0017] This Summary is intended to provide an overview of the subject matter of this 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 this patent application. [Brief explanation 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, and not by way of limitation, various embodiments discussed in the present document. [Figure 1] FIG. 1 is a block diagram of an example 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. [Figure 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. [Figure 5] FIG. 1 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 INVENTION

[0019] This disclosure describes, among other things, techniques for updating secure element firmware. Specifically, 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 disclosed embodiments, the processing and storage resources of the remote server used to update the secure element firmware are thereby reduced, enhancing 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 multiple cryptographic algorithms. Examples of good secure elements include smart cards used as SIM cards in mobile phones, security chips in credit / debit cards, and corporate user authentication devices.

[0020] Multiple secure elements are typically used in many applications. These secure elements are typically manufactured with master encryption and signature keys specific to a particular secure element among the multiple secure elements, which 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 MFKP value 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 ends, the multiple session key pairs can be revoked and deleted.

[0021] In some cases, it is necessary to update the firmware used by multiple secure elements to operate. For example, the 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 the firmware of the secure elements typically requires the remote server to know the MFKP of the secure elements to be updated so that it can perform mutual authentication, generate session key pairs, and provide the firmware update to the secure elements. Additionally, because the storage resources available to the secure elements are limited (e.g., a secure element cannot store multiple firmware files at a time, and in many cases cannot even store a single firmware file), the updated firmware file must be sent to the secure elements in multiple chunks, which may or may not be equal. Thus, not only does the remote server need to know the MFKP of each secure element targeted for the update, but it also needs to split the firmware file into chunks, encrypt the chunks, and send them to the target secure elements. 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 a gateway device to receive firmware or chunks of firmware from a remote source. The local processing element locally encrypts and signs such firmware using ephemeral session-specific key material associated with a target secure element and provides the encrypted and signed firmware to the target secure element. In some cases, the local processing element receives the ephemeral session-specific key material from a remote source. In some other cases, the local processing element receives the ephemeral session-specific key material from the target secure element being updated or another secure element on the gateway device (including the target secure element's MFKP). In this way, the secure key management requirements of remote servers, such as processing, storage, and cloud resources, are reduced and reserved for performing other functions. Furthermore, the security of providing updated firmware to 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] 1 is a block diagram of an example system 100 for updating firmware of secure elements, 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 contains 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 the firmware files of one or more secure elements 150, 152 implemented on 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 contains copies of the firmware files and can provide them 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 a general-purpose microprocessor without providing a high 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 first secure element 150's MFKP 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 the session between the given device and the first secure element 150 ends, the temporary session-specific key material is disabled and / or deleted. Multiple subsequence 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 first secure element 150's MFKP 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 run applications that utilize cryptographic 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 signature keys used to sign encrypted data. The process for updating the firmware of the first secure element 150 using the security enclave is shown in Figure 2A.

[0029] 2A , the remote source 110 first 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, which 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 security enclave's TEEKP. 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 security enclave's TEEKP. 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 the 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, or before or simultaneously, 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. Many other formats exist for secure exchange of firmware files (or chunks) available at the remote server and 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 in complete form from the remote source 110 and stored entirely on 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] 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 shown 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, which 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 security enclave's TEEKP. At this point, the first secure element 150 has the key material necessary 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 security enclave's TEEKP. 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 first secure element's 150 decrypted SFKP. 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, remote source 130 encrypts the firmware file using the TEEKP of the security enclave implemented by 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 complete form and stored entirely on processing element 130. In such cases, processing element 130 splits the firmware file into multiple chunks and transmits them to 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 maintain 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 occurring 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 gateway 120 stores a first MFKP for performing mutual authentication and generating an SFKP for its own communications, and also stores a second MFKP for another secure element implemented in gateway 120. For example, first secure element 150 stores a first MFKP used by its cryptographic processor and also stores a second MFKP for second secure element 152. In some cases, each secure element implemented by gateway 120 stores an MFKP for only one other secure element implemented by gateway 120. In some cases, each secure element implemented by gateway 120 stores MFKPs for all secure elements implemented by gateway 120. That is, if gateway 120 implements 16 different secure elements, each secure element stores 16 MFKPs, including the MFKP used by the secure element's corresponding cryptographic processor.

[0037] 3, remote source 110 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 its entirety and stored entirely 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. Mutual authentication between the two secure elements can be performed by the secure elements communicating with each other directly or by the 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 material (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., 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 invalidated 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 can 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 two secure elements can be performed by the secure elements communicating with each other directly or by the secure elements communicating through 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 key material necessary to communicate (exchange data) with the security enclave implemented by the processing element 130. The second secure element 152 encrypts and signs SFKP2 using the security enclave's TEEKP and provides SFKP2 to the security enclave implemented by the processing element 130.

[0041] The security enclave implemented by processing element 130 provides each chunk of the firmware file to first secure element 150 using the security enclave's SFKP2 received from second secure element 152. That is, the security enclave implemented by processing element 130 encrypts and signs each chunk of the firmware file using the first secure element 150's SFKP2 to generate a respective data packet. The security enclave implemented by processing element 130 provides the data packets (e.g., encrypted and signed chunks of the firmware file) to first secure element 150. The security enclave implemented by processing element 130 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to 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 multiple chunks of firmware to the first secure element 150. This process avoids the need for the remote source 110 to maintain an MFKP for each target secure element to be updated, thereby reducing storage resources on 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 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 gateway 120 stores a first MFKP for performing mutual authentication and generating an SFKP for its own communications, and also stores a second MFKP for another secure element implemented in gateway 120. For example, first secure element 150 stores a first MFKP used by its cryptographic processor and also stores a second MFKP for second secure element 152. In some cases, each secure element implemented by gateway 120 stores an MFKP for only one other secure element implemented by gateway 120. In some cases, each secure element implemented by gateway 120 stores MFKPs for all secure elements implemented by gateway 120. That is, if gateway 120 implements 16 different secure elements, each secure element stores 16 MFKPs, including the MFKP used by that secure element's corresponding cryptographic processor.

[0044] 4, remote source 130 transmits a firmware file with a firmware update to control circuitry 140. 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 remote source 110 and transmitted from remote source 110 to control circuitry 140 in multiple chunks. In some cases, the firmware file may be transmitted from remote source 110 in its entirety and stored entirely in control circuitry 140. In some cases, control circuitry 140 splits the firmware file into multiple chunks locally on 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. Mutual authentication between two secure elements can be performed by the secure elements communicating with each other directly or by the 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 material (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 first and second secure elements 150, 152. First secure element 150 repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to second secure element 152. After all chunks of the firmware file have been received by second secure element 152, SFKP1 is invalidated and / or deleted from storage by 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 manner, 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. Mutual authentication between two secure elements can be performed by the secure elements communicating with each other directly or by the 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 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 first secure 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 disabled 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 plurality of 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 upon which any one or more of the techniques (e.g., methods) described herein may operate. In alternative embodiments, machine 600 may operate as a stand-alone 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. Furthermore, 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., a set) of circuits embodied in tangible entities including hardware (e.g., simple circuits, gates, logic, etc.). Circuitry membership may be flexible over time and with underlying hardware variability. Circuits may include members that, when operating, perform specific tasks singly or in combination. In one example, circuitry hardware may have an unchanging configuration (e.g., hardwired) and be configured to perform a specified operation. In one example, circuitry hardware 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, electrically, by moving immutable mass particles, etc.) to encode specific operational instructions. 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 cause the participating hardware (e.g., execution units or loading mechanisms) to perform a portion of a particular task during operation by variably connecting components of the circuitry within the hardware. 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 components 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 touchscreen 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 sets of data structures or instructions 624 (e.g., software) embodied in 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, 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 shown 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 instructions 624.

[0057] The term “machine-readable medium” may include any transitory or non-transitory medium capable of storing, encoding, or transferring transitory or non-transitory instructions for execution by machine 600 and enabling machine 600 to perform any one or more of the techniques of this disclosure, or to store, encode, or transfer data structures used by or associated with 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 an unchanging mass (e.g., rest mass). Thus, a massive machine-readable medium is not a transitory propagating signal. Specific 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, magneto-optical disks, CD-ROM, and DVD-ROM disks.

[0058] Instructions 624 (e.g., software, programs, operating systems (OS), etc.) or other data stored on 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 using virtual memory can significantly degrade the user experience due to the latency of the storage device (as opposed to main memory 604, e.g., DRAM). Furthermore, using storage device 621 for virtual memory can significantly reduce 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 several 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, among others, a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile phone network (e.g., a cellular network), a Plain Old Telephone Service (POTS) network, and wireless data networks (e.g., the IEEE (Institute of Electrical and Electronics Engineers) 802.11 family of standards known as Wi-Fi®, the IEEE 802.16 family of standards known as WiMax®), the IEEE 802.15.4 family of standards, and peer-to-peer (P2P) networks. 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 examples described herein may stand on its own or may be combined with one or more of the other examples 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 present subject matter may be practiced. These embodiments are also referred to herein as "examples." These 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. Furthermore, the inventors also contemplate examples (or one or more aspects thereof) using any combination or permutation of the elements shown or described in relation to a particular example (or one or aspects thereof) or in relation to 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, as is common in patent documents, to include one or more, independently of any other instance or use of "at least one" or "one or more." The term "or" is used herein to mean non-exclusive, unless otherwise noted, or such that "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 "comprising" 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 a claim are still considered to be within the scope of that claim. Furthermore, 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 a computer-readable medium or machine-readable medium encoded with temporary or non-transitory instructions operable to configure an electronic device to perform 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-transitory computer-readable instructions for performing 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-transitory, 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, not limiting. For example, the above-described examples (or one or more aspects thereof) can be used in combination with each other. Other embodiments may be employed by those skilled in the art upon review of 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. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be construed as intending that any unclaimed disclosed feature is essential to any claim. Rather, 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 system for updating firmware of a secure element, comprising: a plurality of secure elements implemented on a gateway device, each of said plurality of secure elements storing one or more keys for encryption and signing associated with one or more of the other secure elements, each of said plurality of secure elements: performing mutual authentication between a first secure element and a second secure element of the plurality of secure elements implemented by the gateway device based on a first key for encryption and signing associated with the first secure element of the plurality of secure elements and stored in a second secure element of the plurality of secure elements; establishing first temporary session-specific key material between the first secure element and the second secure element of the plurality of secure elements implemented by the gateway device based on the first key for the encryption and signing; a processing element implemented on the gateway device, establishing a secure session between a remote source and the processing element; receiving, by the gateway device, a firmware file from the remote source; receiving the first ephemeral session-specific key material for the first secure element of the plurality of secure elements from the second secure element of the plurality of secure elements implemented by the gateway device to enable the processing element to securely communicate with the first secure element of the plurality of secure elements; the processing element applying the first temporary session-specific key material to a first data chunk of the firmware file to generate a first data packet; the processing element configured to perform a plurality of operations including:

2. The processing element designating the first secure element of the plurality of secure elements as a target; 2. The system of claim 1, further configured to: designate the second secure element of the plurality of secure elements as a manager.

3. the processing element is further configured to establish processing element key material between the processing element and the second secure element of the plurality of secure elements; 3. The system of claim 2, wherein the processing element's key material is used to securely transmit the temporary session-specific key from the second secure element of the plurality of secure elements to the processing element.

4. after all of the plurality of data packets of the plurality of data chunks of the firmware file have been transmitted to the first secure element; each of the first and second secure elements of the plurality of secure elements is further configured to: establish second temporary session-specific key material between the first secure element and the second secure element of the plurality of secure elements implemented by the gateway device based on a second key for encryption and signing associated with and stored in the first secure element of the plurality of secure elements; The processing element designating the second secure element of the plurality of secure elements as the target; designating the first secure element of the plurality of secure elements as the manager; receiving the second ephemeral session-specific key material for the second secure element of the plurality of secure elements from the first secure element of the plurality of secure elements implemented by the gateway device to enable the processing element to securely communicate with the second secure element of the plurality of secure elements; applying the second temporary session-specific key material to the first data chunk of the firmware file to generate an additional first data packet; 4. The system of claim 3, further configured to: and transmitting the additional first data packet to the second secure element of the plurality of secure elements.

5. 4. The system of claim 1, wherein the first temporary session-specific key material includes a first encryption key and a first signature key, the first encryption key being used to encrypt underlying data and the first signature key being used to sign the encrypted data.

6. 5. The system of claim 4, wherein the second ephemeral session-specific key material includes a second encryption key and a second signature key, the second encryption key being used to encrypt underlying additional data and the second signature key being used to sign the encrypted additional data.

7. 6. The system of claim 5, wherein the first data packet is generated by the processing element by encrypting and signing the first data chunk using the first encryption key and the first signature key in the first ephemeral session-specific key material.

8. 7. The system of claim 6, wherein a first additional data packet is generated by the processing element by encrypting and signing the first data chunk using the second encryption key and the second signature key in the second temporary session-specific key material.

9. 9. The system of claim 1, wherein the processing element is further configured to repeat the applying and transmitting operations for each of a plurality of data chunks of the firmware file for transmission to the first secure element of the plurality of secure elements.

10. 10. The system of claim 1, wherein the processing element is further configured to repeat the applying and transmitting operations for each of a plurality of data chunks for transmission to the second secure element of the plurality of secure elements.

11. 1. A system for updating firmware of a secure element, comprising: a plurality of secure elements implemented on a gateway device, each of said plurality of secure elements storing one or more keys for encryption and signing associated with one or more of the other secure elements, each of said plurality of secure elements: performing mutual authentication between a first secure element and a second secure element of the plurality of secure elements implemented by the gateway device based on a first key for encryption and signing associated with the first secure element of the plurality of secure elements and stored in a second secure element of the plurality of secure elements; establishing first temporary session-specific key material between the first secure element and the second secure element of the plurality of secure elements implemented by the gateway device based on the first key for the encryption and signing; a processing element implemented on the gateway device, establishing a secure session between a remote source and the processing element; receiving, by the gateway device, a firmware file from the remote source; the processing element transmitting a first data chunk of the firmware file to the second secure element of the plurality of secure elements and requesting encryption and signing by the second secure element of the plurality of secure elements; The second secure element of the plurality of secure elements comprises: the second secure element of the plurality of secure elements applying the first ephemeral session-specific key material to the first data chunk of the firmware file to generate a first data packet; and a processing element configured to perform a plurality of operations including: the second secure element of the plurality of secure elements transmitting the first data packet to the first secure element of the plurality of secure elements.

12. The processing element designating the first secure element of the plurality of secure elements as a target; 12. The system of claim 11, further configured to: designate the second secure element of the plurality of secure elements as a manager.

13. 13. The system of claim 12, wherein the processing element is further configured to establish processing element key material between the processing element and the second secure element of the plurality of secure elements, the processing element key material being used to securely transmit the plurality of data chunks of the firmware file from the processing element to the second secure element of the plurality of secure elements.

14. after all of the plurality of data packets of the plurality of data chunks of the firmware file have been transmitted to the first secure element; Each of the first and second secure elements of the plurality of secure elements comprises: establishing second temporary session-specific key material between the first secure element and the second secure element of the plurality of secure elements implemented by the gateway device based on a second key for encryption and signing associated with the second secure element of the plurality of secure elements and stored in the first secure element of the plurality of secure elements; The processing element designating the second secure element of the plurality of secure elements as the target; designating the first secure element of the plurality of secure elements as the manager; sending the first data chunk of the firmware file to the first secure element of the plurality of secure elements and requesting encryption and signing by the first secure element of the plurality of secure elements; The first secure element of the plurality of secure elements comprises: the first secure element of the plurality of secure elements applying the second ephemeral session-specific key material to the first data chunk of the firmware file to generate an additional first data packet; the first secure element of the plurality of secure elements transmitting the additional first data packet to the second secure element of the plurality of secure elements.

15. 14. The system of claim 11, wherein the first temporary session-specific key material includes a first encryption key and a first signature key, the first encryption key being used to encrypt underlying data and the first signature key being used to sign the encrypted data.

16. 15. The system of claim 14, wherein the second ephemeral session-specific key material includes a second encryption key and a second signature key, the second encryption key being used to encrypt underlying additional data and the second signature key being used to sign the encrypted additional data.

17. 16. The system of claim 15, wherein the first data packet is generated by the first secure element of the plurality of secure elements by encrypting and signing the first data chunk using the first encryption key and the first signature key in the first ephemeral session-specific key material.

18. 17. The system of claim 16, wherein an additional first data packet is generated by the second secure element of the plurality of secure elements by encrypting and signing the first data chunk using the second encryption key and the second signature key in the second ephemeral session-specific key material.

19. 19. The system of claim 11, wherein the second secure element of the plurality of secure elements is further configured to repeat the applying and sending operations for each of a plurality of data chunks of the firmware file for transmission to the first secure element of the plurality of secure elements.

20. 20. The system of claim 11, wherein the first secure element of the plurality of secure elements is further configured to repeat the applying and transmitting operations for each of a plurality of data chunks for transmission to the second secure element of the plurality of secure elements.

21. 1. A system for updating firmware of a secure element, comprising: a plurality of secure elements implemented on a gateway device, a first secure element of the plurality of secure elements; performing mutual authentication between the remote server and the first secure element of the plurality of secure elements based on a first key for encryption and signing associated with the first secure element of the plurality of secure elements and stored in a remote server; establishing temporary session-specific key material between the remote server and the first secure element of the plurality of secure elements; a processing element implemented on the gateway device, establishing a secure session between a remote source and the processing element; receiving, by the gateway device, a firmware file from the remote source; receiving the temporary session-specific key material for the first secure 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 configured to perform a plurality of operations including:

22. The processing element performing authentication with the remote server using key material of a trusted environment associated with the processing element; 22. The system of claim 21, further configured to: receive from the remote server the temporary session-specific keying material for the first secure element of the plurality of secure elements encrypted using keying material of the trusted environment.

23. The processing element performing authentication with the first secure element of the plurality of secure elements using key material of a trusted environment associated with the processing element; 22. The system of claim 21, further configured to: receive, from the first secure element of the plurality of secure elements, the temporary session-specific keying material for the first secure element of the plurality of secure elements encrypted using keying material of the trusted environment.

24. 24. The system of claim 22 or 23, wherein the processing element is further configured to repeat the applying and sending operations for each of a plurality of data chunks of the firmware file for transmission to the first secure element of the plurality of secure elements.

25. After all of the plurality of data chunks of the firmware file are transmitted to the first secure element, each of the first secure element and a second secure element of the plurality of secure elements: performing mutual authentication between the first secure element and the second secure element of the plurality of secure elements based on a second key for encryption and signing associated with the second secure element of the plurality of secure elements and stored in the first secure element of the plurality of secure elements; establishing second temporary session-specific key material between the first secure element and the second secure element of the plurality of secure elements implemented by the gateway device based on the second key for the encryption and signing; The processing element designating the second secure element of the plurality of secure elements as a target; designating the first secure element of the plurality of secure elements as a manager; The second secure element of the plurality of secure elements comprises:

25. The system of claim 24, further configured to receive an additional first data packet generated from the first data chunk of the firmware file encrypted using the second temporary session-specific key material.

26. The processing element receiving the second ephemeral session-specific keying material from the first secure element of the plurality of secure elements; applying the second temporary session-specific key material to the first data chunk of the firmware file to generate the additional first data packet; 26. The system of claim 25, further configured to: transmit the additional first data packet to the second secure element of the plurality of secure elements.

27. The first secure element of the plurality of secure elements comprises: receiving the first data chunk of the firmware file from the processing element; receiving a request from the processing element to encrypt and sign using the second temporary session-specific key material; applying the second temporary session-specific key material to the first data chunk of the firmware file to generate the additional first data packet; 26. The system of claim 25, further configured to: transmit the additional first data packet to the second secure element of the plurality of secure elements.

28. 1. A method for updating firmware of a secure element, comprising: performing mutual authentication between a first secure element and a second secure element of the plurality of secure elements; establishing temporary session-specific keying material between the first secure element and the second secure element of the plurality of secure elements implemented by a gateway device; establishing a secure session between a remote source and a processing element implemented by said gateway device; receiving, by the gateway device, a firmware file from the remote source; receiving the temporary session-specific key material for the first secure element from the second secure element of the plurality of secure elements implemented on the gateway device 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.

29. 30. The method of claim 28, further comprising repeating the applying and transmitting operations for each of a plurality of data chunks of the firmware file for transmission to the first secure element.

30. 30. The method of claim 28, 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.

31. 1. A method for updating firmware of a secure element, comprising: performing mutual authentication between a first secure element and a second secure element of the plurality of secure elements; establishing temporary session-specific keying material between the first secure element and the second secure element of the plurality of secure elements implemented by a gateway device; establishing a secure session between a remote source and a processing element implemented by said gateway device; receiving, by the gateway device, a firmware file from the remote source; the processing element sending a first data chunk of the firmware file to the second secure element of the plurality of secure elements and requesting encryption and signing by the second secure element of the plurality of secure elements; applying the temporary session-specific key material to the first data chunk of the firmware file by the second secure element of the plurality of secure elements to generate a first data packet; the second secure element of the plurality of secure elements transmitting the first data packet to the first secure element.

32. 32. The method of claim 31, further comprising repeating the sending, applying, and sending operations for each of a plurality of data chunks of the firmware file for transmission to the first secure element.

33. 32. The method of claim 31 , wherein the temporary session-specific key material is established based on a key for encryption and signing stored in the second secure element of the plurality of secure elements.

34. 1. A method for updating firmware of a secure element, comprising: establishing cryptographic 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 a processing element implemented by the gateway device; receiving, by the processing element implemented on the gateway device, the cryptographic key material for the first secure element from the remote source via the secure session to enable the processing element to securely communicate with the first secure element; the processing element sending a first data packet to the first secure element, the first data packet being encrypted by the processing element using the encryption key material.

35. the processing element applying the cryptographic key material to a plurality of data chunks of a firmware file to generate a plurality of data packets; 35. The method of claim 34, further comprising the processing element transmitting the plurality of data packets to the first secure element.

36. 35. The method of claim 34, wherein the cryptographic 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.

Images