METHODS & PROCESSES TO SECURELY UPDATE SECURE ELEMENTS

This disclosure describes techniques for updating firmware of a secure element. The techniques include operations comprising: receiving, by a gateway device, from a remote source, a firmware file; 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 of 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.

FIELD OF THE DISCLOSURE

This document pertains generally, but not by way of limitation, to a gateway that includes one or more secure elements.

BACKGROUND

Secure elements are typically used in many applications. Secure elements include hardware and/or software for performing cryptographic functions or processes—e.g., encryption, decryption, signature generation, signature verification, and/or key generation. Secure elements are contained within an explicitly defined perimeter that establishes the physical bounds of the cryptographic module and that contains any processors and/or other hardware components that store and protect any software and firmware components of the cryptographic module. Secure elements could take the form of (or include) a secure crypto-processor, a smart card, a secure digital (SD) card, a micro SD card, a SIM card, and/or any other cryptographic module.

The secure element (SE) is a tamper-resistant platform capable of securely hosting applications and their confidential and cryptographic data in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities. The SE can be considered to be a chip that offers a dynamic environment to store data securely, process data securely and perform communication with external entities securely.

SUMMARY OF THE DISCLOSURE

In some certain embodiments, a system and method are provided for updating firmware of a secure element. In some embodiments, the system and method include a gateway that receives, from a remote source, a firmware file. A processing element implemented on the gateway device receives ephemeral session specific key material for a first secure element implemented on the gateway device. The firmware file is divided 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 sends the first data packet to the first secure element.

In some implementations, the ephemeral session specific key material comprises 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.

In some implementations, the first data packet is generated by encrypting and signing the first data chuck using the encryption key and the signature key in the ephemeral session specific key material.

In some implementations, the applying and sending operations for each of the plurality of data chunks are repeated.

In some implementations, the processing element comprises a security enclave. In such cases, the ephemeral session specific key material is established 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, wherein the firmware file is divided by the processing element.

In some implementations, the security enclave is a trusted execution environments device, and wherein the master firmware key pair is stored on the remote source.

In some implementations, a processing element key pair is established between the remote source and the processing element. The ephemeral session specific key material is sent from the remote source to the processing element using the processing element key pair.

In some implementations, the processing element comprises a security enclave. In such cases, a processing element key pair is established between the first secure element and the processing element. The ephemeral session specific key material is sent from the first secure element to the processing element using the processing element key pair.

In some implementations, the processing element comprises a security enclave and the firmware file is divided by the processing element. In such cases, the processing element selects a second secure element as a manager and the first secure element as a target. The ephemeral session specific key material is established 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. A processing element key pair is established between the second secure element and the processing element. The ephemeral session specific key material is sent from the second secure element to the processing element using the processing element key pair.

In some implementations, the security enclave is a trusted execution environments device, wherein the first master firmware key pair is stored on the second secure element, and wherein a second master firmware key pair associated with the second secure element is stored on the first secure element.

In some implementations, firmware of the second secure element is updated after the firmware file is transmitted to the first secure element.

In some implementations, the ephemeral session specific key material is a first ephemeral 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. A second ephemeral session specific key material is established 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. A processing element key pair is established between the first secure element and the processing element. The second ephemeral session specific key material is sent from the first secure element to the processing element using the processing element key pair.

In some implementations, the processing element sends the first data packet to the second secure element based on the second ephemeral session specific key material.

In some implementations, the processing element comprises a second secure element, and the firmware file is divided by a processor on the gateway. In such cases, the processor receives the firmware file. The processor selects the second secure element as a manager and the first secure element as a target. The ephemeral session specific key material is established 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. The first data chunk is provided from the processor to the second secure element. The second secure element is instructed to apply the ephemeral session specific key material to the first data chunk to send the first data packet, directly or indirectly, to the first secure element.

In some implementations, firmware of the second secure element is updated after the firmware file is transmitted to the first secure element.

In some implementations, the ephemeral session specific key material is a first ephemeral session specific key material. In such cases, the processor selects the second secure element as the target and the first secure element as the manager. A second ephemeral session specific key material is established 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. The first data chunk is provided from the processor to the first secure element. The first secure element to apply the second ephemeral 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.

In some implementations, the processing element sends the first data packet to the second secure element based on the second ephemeral session specific key material.

Updating firmware of a secure element typically requires a remote server to know the key material of the secure element in order to be able to perform mutual authentication and generate session key pairs to provide the firmware update to the secure element. After the remote server performs mutual authentication with the secure element, the remote server has to split up the firmware update into chunks and encrypt each file chunk being sent to the secure element. The disclosed embodiments utilize a processing element, locally implemented on a gateway device, to receive firmware or firmware chunks from a remote source and to locally encrypt such firmware with ephemeral session specific key material to provide the encrypted firmware to the secure element. In this way, the processing and storage resources of the remote server that are used to update firmware of a secure element are reduced and security of the overall system is enhanced.

This overview is intended to provide an overview of subject matter of the present patent application. It is not intended to provide an exclusive or exhaustive explanation of the inventive subject matter. The detailed description is included to provide further information about the present patent application.

DETAILED DESCRIPTION

This disclosure describes, among other things, techniques for updating firmware of a secure element. Specifically, the disclosed techniques utilize a processing element, locally implemented on a gateway device, to receive firmware or firmware chunks from a remote source and to locally encrypt such firmware with ephemeral session specific key material to provide the encrypted firmware to the secure element. According to the disclosed embodiments, the processing and storage resources of the remote server that are used to update firmware of a secure element are thereby reduced and security of the overall system is enhanced. A device is considered a secure element if it provides a certain level of security assurances with respect to storage of sensitive key material and implementations of cryptographic algorithms. An example of a good secure element is a smart card that is used as a SIM card in mobile phones, a secure chip in credit/debit cards and user authentication devices in enterprises.

Secure elements are typically used in many applications. Typically, these secure elements are manufactured with a master encryption key and a master signature key specific to a particular one of the secure elements that are used to encrypt and sign firmware packets. These master encryption and signature keys (MFKP) are typically used to perform mutual authentication between two entities that know the value of the MFKP to generate session key pairs. As an example, a secure element can use its secure element specific MFKP to perform mutual authentication with another device that also knows the MFKP of the secure element. The mutual authentication can be performed without exchanging any key material between the devices. Once the mutual authentication is performed, 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 decrypt the data. Once the session ends, the session key pairs are no longer valid and can be deleted.

In some cases, the firmware the secure elements use to operate needs to be updated. For example, the firmware may need to be updated to remove bugs and/or add/remove features. The firmware file for updating the secure elements is typically stored on a remote server, such as a cloud-based server or service. Updating the firmware of the secure element typically requires the remote server to know the MFKP of the secure element being updated in order to be able to perform mutual authentication and generate the session key pairs to provide the firmware update to the secure element. Also, because the storage resources available on the secure element are limited (e.g., the secure element cannot store more than one firmware file at a time and quite often even one firmware file), the updated firmware file needs to be sent to the secure element in several equal or non-equal chunks. As such, the remote server, not only has to know the MFKP of each secure element that is a target of the update, the remote server also has to divide the firmware file into chunks and encrypt the divided chunks to be sent to the target secure element. The typical process for updating the secure elements places a great deal of burden (both for processing and implementation of practices around secure key management) on the remote sources from which the updated firmware file is received and consumes a tremendous amount of processing and storage resources.

To address the shortcomings of such typical approaches, the disclosed techniques utilize a processing element, locally implemented on a gateway device, to receive firmware or firmware chunks from a remote source. The local processing element locally encrypts and signs such firmware with ephemeral session specific key material associated with a target secure element to provide 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 the 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 (that contains the MFKP of target secure element) on the gateway device. In this way, the processing, storage resources and secure key management requirements of the remote server, such as a cloud resource, are reduced and preserved to perform other functions. In addition, security of providing the updated firmware to the secure elements is not compromised.

While the below discussion pertains to “secure elements,” the teachings of this disclosure are similarly applicable to any other suitable processing element, such as a general-purpose microprocessor. Namely, for illustrative purpose, the disclosure is discussed with respect to “secure elements” but any function performed below for updating the secure elements can be performed by other processors instead of (or in addition to) the secure elements.

FIG.1is a block diagram of an example of a system100for updating firmware of a secure element in accordance with various embodiments. System100includes a remote source110and a gateway120. The remote source110may include one or more servers and may be accessible via a local area network or wide area network, such as the Internet. The remote source110includes a firmware file update for secure elements. In some embodiments, the gateway120communicates with the remote source110to obtain the firmware file update and to update the firmware file of one or more secure elements150and152implemented on the gateway120. In some cases, rather than being a server accessible via a network, the remote source110may be another mobile device or storage device that includes and can provide a copy of the firmware file to the gateway120.

The gateway120includes control circuitry140, a processing element130, and one or more secure elements150and152. In some cases, the gateway120includes 16 secure elements. Each secure element150and152of gateway120is configured to perform the same function. In some implementations, secure elements150and152are implemented (both in hardware and software) to provide a higher level of security assurance than typical general-purpose microprocessors. In some implementations, secure elements150and152are implemented as general-purpose microprocessors without providing higher level of security assurance.

In some cases, each secure element150and152is manufactured with a different set of MFKP. As such, in order to communicate and exchange data with a first secure element150, a given device (e.g., processing element130) that knows the MFKP of the first secure element150performs mutual authentication with the first secure element150to generate an ephemeral session specific key material. The ephemeral session specific key material is used by the first secure element150and the given device to encrypt and sign packets of information. After the session ends between the given device and the first secure element150, the ephemeral session specific key material becomes invalidated and/or deleted. Subsequence sessions and communications between the first secure element150and the given device may require that the given device and the first secure element150again perform mutual authentication using the MFKP of the first secure element150to generate a new ephemeral session specific key material.

In some embodiments, the remote source110updates the firmware of the first secure element150via a security enclave, such as a trusted execution environment, implemented by the processing element130. In such cases, the security enclave may run applications that make use of crypto support and offer isolation from the general computing environment. In some implementations, the security enclave implemented by the processing element130includes symmetric or asymmetric key material that is used by the security enclave to communicate with another device. The cryptographic process and technique used by the security enclave to communicate with devices is different from the cryptographic process implemented by the secure elements of the gateway120.

Specifically, the key material used by the security enclave is different from the MFKP of the first secure element150. The key material used by the security enclave to communicate with other devices is referred to as TEEKP and includes an encryption key used to encrypted/decrypt data and a signature key used to sign the encrypted data. The process for updating the firmware of the first secure element150via the security enclave is illustrated inFIG.2A.

As shown inFIG.2A, initially the remote source110performs mutual authentication with the first secure element150using the MFKP of the first secure element150. In this case, the remote source110needs to know the MFKP of the first secure element150that is the target of the firmware update. After performing mutual authentication with the first secure element150, a pair of ephemeral session specific key material (SFKP) is generated and stored by the remote source110and the first secure element150. After, before or concurrently with generating the SFKP, the remote source110performs authentication (e.g., mutual authentication) with the security enclave implemented by the processing element130using the TEEKP of the security enclave. At this point, the remote source110has the key material needed to communicate (exchange data with) the security enclave implemented by the processing element130and the SFKP needed to communicate with the first secure element150.

According to this embodiment, the remote source110sends the SFKP of the first secure element150to the security enclave implemented by the processing element130using the TEEKP of the security enclave. Specifically, the remote source110encrypts and signs the SFKP of the first secure element150using the TEEKP of the security enclave implemented by the processing element130. After the processing element130receives the SFKP from the remote source110, the processing element130can decrypt the SFKP using the TEEKP and is then able to communicate with the first secure element150for the particular session using the decrypted SFKP of the first secure element150. After, before, or concurrently with the remote source130transmitting the SFKP to the processing element130, the remote source130also transmits the firmware file with the firmware update to the processing element130. The firmware file may be sent in encrypted or non-encrypted form. If sent in encrypted form, the remote source130can encrypt the firmware file using the TEEKP of the security enclave implemented by the processing element130. There are many other forms of secure exchange of firmware file (or chunks) that can be leveraged by the remote server and processing element. In some cases, the firmware file may be divided by the remote source110and sent to the processing element130in chunks from the remote source110. In some cases, the firmware file may be sent in complete form from the remote source110and be completely stored on the processing element130. In such cases, the processing element130divides the firmware file into chunks for transmission to the first secure element150.

The security enclave implemented by the processing element130encrypts and signs each chunk of the firmware file using the SFKP of the first secure element150to generate respective data packets. The security enclave implemented by the processing element130provides the data packet (e.g., the encrypted and signed firmware file chunk) to the first secure element150. The security enclave implemented by the processing element130repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element150. After all chunks of the firmware file are received by the first secure element150, the SFKP becomes invalidated and/or deleted from being stored by the first secure element150.

FIG.2Bshows another process for sending a firmware file to the first secure element150using a security enclave implemented by the processing element130. As shown inFIG.2B, initially the remote source110performs mutual authentication with the first secure element150using the MFKP of the first secure element150. In this case, the remote source110needs to know the MFKP of the first secure element150that is the target of the firmware update. After performing mutual authentication with the first secure element150, a pair of ephemeral session specific key material (SFKP) is generated and stored by the remote source110and the first secure element150. After, before or concurrently with generating the SFKP, the first secure element150performs authentication (e.g., mutual authentication) with the security enclave implemented by the processing element130using the TEEKP of the security enclave. At this point, the first secure element150has the key material needed to communicate (exchange data with) the security enclave implemented by the processing element130and the first secure element150has generated the SFKP needed to exchange communications for the session.

According to this embodiment, the first secure element150sends the SFKP of the first secure element150to the security enclave implemented by the processing element130using the TEEKP of the security enclave. Specifically, the first secure element150encrypts and signs the SFKP of the first secure element150using the TEEKP of the security enclave implemented by the processing element130. After the processing element130receives the SFKP from the remote source110, the processing element130can decrypt the SFKP using the TEEKP and is then able to communicate with the first secure element150for the particular session using the decrypted SFKP of the first secure element150. The remote source130transmits the firmware file with the firmware update to the processing element130. The firmware file may be sent in encrypted or non-encrypted form. If sent in encrypted form, the remote source130encrypts the firmware file using the TEEKP of the security enclave implemented by the processing element130. In some cases, the firmware file may be divided by the remote source110and sent to the processing element130in chunks from the remote source110. In some cases, the firmware file may be sent in complete form from the remote source110and be completely stored on the processing element130. In such cases, the processing element130divides the firmware file into chunks for transmission to the first secure element150.

The security enclave implemented by the processing element130encrypts and signs each chunk of the firmware file using the SFKP of the first secure element150to generate respective data packets. The security enclave implemented by the processing element130provides the data packet (e.g., the encrypted and signed firmware file chunk) to the first secure element150. The security enclave implemented by the processing element130repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element150. After all chunks of the firmware file are received by the first secure element150, the SFKP becomes invalidated and/or deleted from being stored by the first secure element150.

FIG.3shows another process for sending a firmware file to the first secure element150using two secure elements implemented on gateway120and a security enclave implemented by the processing element130. In this process, a second secure element152is used to provide the SFKP of the first secure element150to the security enclave implemented by the processing element130. This process avoids the need to have the remote source110maintain an MFKP for each target secure element it would like to update which reduces storage resources and secure key management requirements of the remote source110. This process also avoids having the remote source110perform mutual authentication with the first secure element150to provide the firmware update which reduces the number of communications that are exchanged over a network and increases the overall efficiency and security of the system.

To implement the process shown inFIG.3, each secure element implemented on gateway120stores 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 on gateway120. For example, first secure element150stores a first MFKP that is used by the crypto-processor of the first secure element150and also stores a second MFKP of a second secure element152. In some cases, each secure element implemented by gateway120stores the MFKP for only one other secure element implemented by gateway120. In some cases, each secure element implemented by gateway120stores the MFKP of every secure element implemented by gateway120. Namely, if gateway120implements16different secure elements, each secure element stores16MFKP including the MFKP used by the respective crypto-processor of the secure element.

As shown inFIG.3, the remote source130transmits the firmware file with the firmware update to the processing element130. In some cases, the firmware file may be divided by the remote source110and sent to the processing element130in chunks from the remote source110. In some cases, the firmware file may be sent in complete form from the remote source110and be completely stored on the processing element130. In such cases, the processing element130divides the firmware file into chunks locally on the gateway120.

After or before receiving the firmware file, the processing element130selects the first secure element150as a manager and the second secure element152as a target. The first secure element150performs mutual authentication with the second secure element152using the MFKP of the second secure element152that is stored on the first secure element150. The mutual authentication between the two secure elements may be performed by the secure elements communicating directly with each other or by the secure elements exchanging communications via the processing element130and/or control circuitry140. After performing mutual authentication with the first secure element150, a first pair of ephemeral session specific key material (SFKP1) is generated and stored by the first secure element150and by the second secure element152. The first secure element150provides the SFKP1to the security enclave implemented by the processing element130. Namely, the first secure element150performs mutual authentication with the security enclave implemented by the processing element130using the TEEKP of the security enclave implemented by the processing element130. At this point, the first secure element150has the key material needed to communicate (exchange data) with the security enclave implemented by the processing element130. The first secure element150encrypts and signs the SFKP1and provides the SFKP1to the security enclave implemented by the processing element130using the TEEKP of the security enclave.

The security enclave implemented by the processing element130provides each chunk of the firmware file to the second secure element (the target)152using the SFKP1the security enclave received from the first secure element (the manager)150. Namely, the security enclave implemented by the processing element130encrypts and signs each chunk of the firmware file using the SFKP1of the second secure element152to generate respective data packets. The security enclave implemented by the processing element130provides data packet (e.g., the encrypted and signed firmware file chunk) to the second secure element152. The security enclave implemented by the processing element130repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the second secure element (the target)152. After all chunks of the firmware file are received by the second secure element (the target)152, the SFKP1becomes invalidated and/or deleted from being stored by the first and second secure elements150and152and by the security enclave implemented by the processing element130.

At this point, after the second secure element152has been updated with the new firmware file, the security enclave implemented by the processing element130may designate the second secure element152as the manager and the first secure element150as the target. In this way, the security enclave implemented by the processing element130may be used to update the firmware of the first secure element150in the same manner. Namely, the first secure element150performs mutual authentication with the second secure element152using the MFKP of the second secure element152that is stored on the first secure element150. The mutual authentication between the two secure elements may be performed by the secure elements communicating directly with each other or by the secure elements exchanging communications via the control circuitry140and/or the security enclave implemented by the processing element130. After performing mutual authentication with the first secure element150, a second pair of ephemeral session specific key material (SFKP2) is generated and stored by the first secure element150and by the second secure element152. The second secure element (the manager)152provides the SFKP2to the security enclave implemented by the processing element130. Namely, the second secure element152performs mutual authentication with the security enclave implemented by the processing element130using the TEEKP of the security enclave implemented by the processing element130. At this point, the second secure element152has the key material needed to communicate (exchange data) with the security enclave implemented by the processing element130. The second secure element152encrypts and signs the SFKP2and provides the SFKP2to the security enclave implemented by the processing element130using the TEEKP of the security enclave.

The security enclave implemented by the processing element130provides each chunk of the firmware file to the first secure element150using the SFKP2the security enclave received from the second secure element152. Namely, the security enclave implemented by the processing element130encrypts and signs each chunk of the firmware file using the SFKP2of the first secure element150to generate respective data packets. The security enclave implemented by the processing element130provides the data packet (e.g., the encrypted and signed firmware file chunk) to the first secure element150. The security enclave implemented by the processing element130repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element150. After all chunks of the firmware file are received by the first secure element150, the SFKP2becomes invalidated and/or deleted from being stored by the first and second secure elements150and152and by the security enclave implemented by the processing element130.

FIG.4shows another process for sending a firmware file to the first secure element150using two secure elements implemented on gateway120and the control circuitry140. In this process, the processing element130implements a given secure element (e.g., the second secure element152). Namely, all of the functionality of the second secure element152is embodied by the processing element130even though they are drawn as separate boxes inFIG.1. In this process, a second secure element152is used to locally generate the SFKP of the first secure element150and securely provides firmware chunks to the first secure element150. This process avoids the need to have the remote source110maintain an MFKP for each target secure element it would like to update which reduces storage resources of the remote source110. This process also avoids having the remote source110perform mutual authentication with the first secure element150to provide the firmware update which reduces the number of communications that are exchanged over a network and increases the overall efficiency and security of the system. This process also avoids the need to have ephemeral session specific key material communicated or exchanged with another device (e.g., another processor or controller on the gateway120).

To implement the process shown inFIG.4, each secure element implemented on gateway120stores 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 on gateway120. For example, first secure element150stores a first MFKP that is used by the crypto-processor of the first secure element150and also stores a second MFKP of a second secure element152. In some cases, each secure element implemented by gateway120stores the MFKP for only one other secure element implemented by gateway120. In some cases, each secure element implemented by gateway120stores the MFKP of every secure element implemented by gateway120. Namely, if gateway120implements16different secure elements, each secure element stores16MFKP including the MFKP used by the respective crypto-processor of the secure element.

As shown inFIG.4, the remote source130transmits the firmware file with the firmware update to the control circuitry140. Control circuitry140may be any suitable processor and may or may not implement a security enclave. In some cases, the firmware file may be divided by the remote source110and sent to the control circuitry140in chunks from the remote source110. In some cases, the firmware file may be sent in complete form from the remote source110and be completely stored on the control circuitry140. In such cases, the control circuitry140divides the firmware file into chunks locally on the gateway120.

After or before receiving the firmware file, the control circuitry140selects the first secure element150as a manager and the second secure element152as a target. The first secure element150performs mutual authentication with the second secure element152using the MFKP of the second secure element152that is stored on the first secure element150. The mutual authentication between the two secure elements may be performed by the secure elements communicating directly with each other or indirectly by the secure elements exchanging communications via the control circuitry140. After performing mutual authentication with the first secure element150, a first pair of ephemeral session specific key material (SFKP1) is generated and stored by the first secure element150and by the second secure element152. At this point, the first and second secure elements150and152are able to securely exchange data that is encrypted and signed using the SFKP1.

The control circuitry140provides each chunk of the firmware file to the first secure element150. The first secure element150encrypts and signs each chunk of the firmware file received from the element150using the SFKP1of the second secure element152to generate respective data packets. Namely, the first secure element150provides the data packet (e.g., the encrypted and signed firmware file chunk) to the second secure element152either directly or indirectly via the control circuitry140. In the case of sending the data packet (e.g., the encrypted and signed file chunk) indirectly, the first secure element150returns to the control circuitry140the data packet that includes the file chunk that has been encrypted and signed using the SFKP1of the second secure element152. Then, the element150sends the data packet to the second secure element152. Namely, the element150may act as a blind and dumb conduit of data exchanged between the first and second secure elements150and152. The first secure element150repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the second secure element152. After all chunks of the firmware file are received by the second secure element152, the SFKP1becomes invalidated and/or deleted from being stored by the first and second secure elements150and152.

At this point, after the second secure element152has been updated with the new firmware file, the control circuitry140may designate the second secure element152as the manager and the first secure element150as the target. In this way, the second secure element152may be used to update the firmware of the first secure element150in the same manner. Namely, the second secure element152performs mutual authentication with the first secure element150using the MFKP of the first secure element150that is stored on the second secure element152. The mutual authentication between the two secure elements may be performed by the secure elements communicating directly with each other or indirectly by the secure elements exchanging communications via the control circuitry140. After performing mutual authentication with the second secure element152, a second pair of ephemeral session specific key material (SFKP2) is generated and stored by the first secure element150and by the second secure element152. At this point, the first and second secure elements150and152are able to securely exchange data that is encrypted and signed using the SFKP2.

The control circuitry140provides each chunk of the firmware file to the second secure element152. The second secure element152encrypts and signs each chunk of the firmware file received from the element150using the SFKP2of the first secure element150to generate respective data packets. The second secure element152provides the data packet (e.g., the encrypted and signed firmware file chunk) to the first secure element150either directly or indirectly via the control circuitry140. The second secure element152repeats the process of encrypting and signing each chunk of the firmware file until all chunks have been sent to the first secure element150. After all chunks of the firmware file are received by the first secure element150, the SFKP2becomes invalidated and/or deleted from being stored by the first and second secure elements150and152.

FIG.5is a flow diagram depicting an example process500for updating firmware of a secure element in accordance with various embodiments.

At operation510, a gateway device receives from a remote source, a firmware file.

At operation520, a processing element implemented on the gateway device receives ephemeral session specific key material for a first secure element implemented on the gateway device.

At operation530, the firmware file is divided into a plurality of data chunks.

At operation540, 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.

At operation550, the processing element sends the first data packet to the first secure element.

FIG.6is a block diagram of an example machine600upon which any one or more of the techniques (e.g., methodologies) discussed herein may be performed. In alternative embodiments, the machine600may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine600may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine600may act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine600may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, an IoT device, an automotive system, an aerospace system, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as via cloud computing, software as a service (SaaS), or other computer cluster configurations.

Examples, as described herein, may include, or may operate by, logic, components, devices, packages, or mechanisms. Circuitry is a collection (e.g., set) of circuits implemented in tangible entities that include hardware (e.g., simple circuits, gates, logic, etc.). Circuitry membership may be flexible over time and underlying hardware variability. Circuitries include members that may, alone or in combination, perform specific tasks when operating. In an example, hardware of the circuitry may be immutably designed to carry out a specific operation (e.g., hardwired). In an example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a computer-readable medium physically modified (e.g., magnetically, electrically, by moveable placement of invariant-massed particles, etc.) to encode instructions of the specific operation. In connecting the physical components, the underlying electrical properties of a hardware constituent are changed, for example, from an insulator to a conductor or vice versa. The instructions enable participating hardware (e.g., the execution units or a loading mechanism) to create members of the circuitry in hardware via the variable connections to carry out portions of the specific tasks when in operation. Accordingly, the computer-readable medium is communicatively coupled to the other components of the circuitry when the device is operating. In an example, any of the physical components may be used in more than one member of more than one circuitry. For example, under operation, execution units may be used in a first circuit of a first circuitry at one point in time and reused by a second circuit in the first circuitry, or by a third circuit in a second circuitry, at a different time.

The machine (e.g., computer system)600may include a hardware processor602(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof, such as a memory controller, etc.), a main memory604, and a static memory606, some or all of which may communicate with each other via an interlink (e.g., bus)608. The machine600may further include a display device610, an alphanumeric input device612(e.g., a keyboard), and a user interface (UI) navigation device614(e.g., a mouse). In an example, the display device610, alphanumeric input device612, and UI navigation device614may be a touchscreen display. The machine600may additionally include a storage device622(e.g., drive unit); a signal generation device618(e.g., a speaker); a network interface device620; one or more sensors616, such as a Global Positioning System (GPS) sensor, wing sensors, mechanical device sensors, temperature sensors, ICP sensors, bridge sensors, audio sensors, industrial sensors, a compass, an accelerometer, or other sensors; and one or more system-in-package data acquisition devices690. The system-in-package data acquisition device(s)690may implement some or all of the functionality of the offset calibration system100. The machine600may include an output controller628, 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 to communicate with or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage device622may include a machine-readable medium on which is stored one or more sets of data structures or instructions624(e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions624may also reside, completely or at least partially, within the main memory604, within the static memory606, or within the hardware processor602during execution thereof by the machine600. In an example, one or any combination of the hardware processor602, the main memory604, the static memory606, or the storage device621may constitute the machine-readable medium.

The instructions624(e.g., software, programs, an operating system (OS), etc.) or other data that are stored on the storage device621can be accessed by the main memory604for use by the hardware processor602. The main memory604(e.g., DRAM) is typically fast, but volatile, and thus a different type of storage from the storage device621(e.g., an SSD), which is suitable for long-term storage, including while in an “off” condition. The instructions624or data in use by a user or the machine600are typically loaded in the main memory604for use by the hardware processor602. When the main memory604is full, virtual space from the storage device621can be allocated to supplement the main memory604; however, because the storage device621is typically slower than the main memory604, and write speeds are typically at least twice as slow as read speeds, use of virtual memory can greatly reduce user experience due to storage device latency (in contrast to the main memory604, e.g., DRAM). Further, use of the storage device621for virtual memory can greatly reduce the usable lifespan of the storage device621.

Each of the non-limiting aspects or examples described herein may stand on its own, or may be combined in various permutations or combinations with one or more of the other examples.