Secure IDS certificate verification for a primary platform

A tamper resistant element (TRE) in a device can operate a primary platform and support a “Smart Secure Platform”. The TRE may not keep time when electrical power is removed from the TRE. The device can receive (i) a certificate for an image delivery server (IDS) with a first timestamp and (ii) a signed second timestamp from a certificate authority, comprising a signature according to the Online Certificate Status Protocol (OCSP) with stapling. The device can forward the certificate and second timestamp to the TRE. The device can receive a ciphertext and an encrypted image from the IDS, where the ciphertext includes a third timestamp from a Time Stamp Authority (TSA), and forward the data to the TRE. The TRE can conduct a key exchange to decrypt the ciphertext. The TRE can compare the second and third timestamps to verify the certificate has not been revoked.

BACKGROUND

Technical Field

The present systems and methods relate to securely transferring firmware to a primary platform from a server, and more particularly for a tamper resistant element (TRE) to determine if a certificate or public key associated with an image delivery server has been revoked.

Description of Related Art

The commercial development and deployment of secure processing environments within microprocessors and tamper resistant elements (TRE) can increase security of computing devices such as mobile phones and networked sensors for the “Internet of Things”. A secure processing environment or TRE can enable a device to securely record cryptographic keys and conduct cryptographic operations such as key exchanges, key derivation, and also digital signatures in a computing environment that is isolated from other electrical components within the device that may not be secure. Examples available today include an embedded subscriber identity module (embedded SIM), which is also known as an embedded universal integrated circuit card (eUICC), a traditional SIM card, a secure enclave within a “system on a chip”, a trusted execution environment (TEE), and other examples are available as well. A common computing architecture includes a processor with multiple cores, where a secure processing core is isolated from the other cores, and the secure processing core can read cryptographic keys and conduct cryptographic operations. Other possibilities exist as well, including “switching” a generic processor between an insecure mode to a secure mode.

As the number of transistors and memory cells available for a given surface area of silicon continues to grow, the computational power for secure processing environments continues to increase. Some secure processing environments can operate as a host computing environment and provide the functionality of a virtual machine for different firmware images, such that each firmware image can operate as separate computing environments within the secure processing environment. As one example, secure processing environments can now enable a TRE to operate as a primary platform for hosting potentially a variety of different firmware images, where each of the firmware images can support a different application. As one example, a secure processing environment could operate a Java™ virtual machine, and different firmware images could comprise different Java applets or Java-based applications. Each Java applet could comprise different images for the Java virtual machine. A firmware can also comprise the base operating system for a primary platform, such as a primary firmware of machine executable program instructions for the primary platform to operate as a host for secondary firmware to operate as virtual machines. Other possibilities exist as well for a secure processing environment to operate as a primary platform for hosting images, and the images may also be referred to as a firmware image.

A primary platform both (i) operating within a secure processing environment and (ii) using firmware images can support a variety of useful applications for a computing device. The operation of an example primary platform can perform functions outlined in “Open Firmware Loader for Tamper Resistant Element”, version 1.3 from Global Platform dated June 2017, which is hereby incorporated by reference in its entirety (“GP OFL document”). An open firmware loader can be referred to as “OFL”. The operation of an example primary platform can also perform functions outlined in the GSM Association (GSMA) technical document “iUICC POC Group Primary Platform requirements”, Release 1.0 dated May 17, 2017, which is hereby incorporated by reference in its entirety (“GSMA PP Requirements”). Example applications supported by a primary platform using firmware images are identified in Section 3 “Use Cases” of the GSMA PP Requirement. Example applications include firmware for an embedded SIM, a traditional universal integrated circuit card (UICC), mobile payments, secure bootstrapping, digital rights management, user identification such as a drivers license, secure access to home automation, a virtual automobile key, and other applications are identified as well.

Further the European Telecommunications Standards Institute (ETSI) has begun developing standards for a “Secure Primary Platform” (SSP) as part of the development of 5G standards, and an SSP could operate as a primary platform as well. As of December, 2018, the draft standards for an SSP are not available for public review, but will likely support applications similar to those contemplated in the GSMA PP requirements document and GP OFL document. As the standards for operating a primary platform or a secure primary platform (SSP) continue to evolve, new features or the use of new cryptographic algorithms or steps may be introduced. These new features and/or cryptographic steps may require new firmware for the primary platform in order to support new or updated versions of the standards. A need exists in the art for a primary platform to securely receive updated firmware in order to support currently evolving standards and features for the operation of a primary platform or SSP and supported applications.

Secure operation of a primary platform or an SSP for each of the above standards depends on the secure delivery of firmware from a server to the primary platform. Different firmware may be required by a primary platform in order to support each of the above example applications. Further, over time new features may be added to the applications, which would also likely require a firmware update. The GP OFL document provides an overview of a proposed solution in FIG. 2-1 on page 15. Details for an OFL security scheme are outlined in the GP OFL document in FIG. 4-1 on page 33. Secure encryption and also an authenticated delivery of firmware to a primary platform is a significant technical challenge, since the computing device may include insecure components, such as a generic processor and a generic operating system. The insecure device can conduct many of the steps for communicating between (i) a server that sources the firmware and (ii) the primary platform. As one example, the computing device could comprise a mobile phone or “smartphone” based on Android or IOS or similar operating systems and could also either (i) operate with “malware” that is unknown to a user or a network or (ii) could comprise a “rooted” mobile phone that is under the control of hackers. Many other examples of insecure devices operating a TRE with a primary platform exist as well. Note that the GP OFL document does not include the words “revocation” or “revoked”, which are associated with steps to revoke or invalidate a previously issued certificate from a certificate issuer. A need exists in the art for secure steps for a TRE with a primary platform to determine revocation of a certificate or public key for an image delivery server (IDS), an OFL, or an associated server.

A primary platform or a “Smart Secure Platform” operating in a tamper resistant element can be a resource constrained computing environment, compared to a traditional computing environment of a mobile phone or a personal computer. This resource constrained environment can create significant challenges for revocation of a certificate or public key associated with a server supporting the delivery of firmware to the primary platform. As one example, a primary platform may not have an internal clock to keep track of local date and time when power is removed from the primary platform. The primary platform must communicate through the insecure mobile phone or computing device in order to send and receive data with a server, including updated firmware for the primary platform. The primary platform may not have resources to operate a full transport layer security (TLS) stack. In addition, the primary platform may lack computing resources and electrical components for the proper and full implementation of certificate revocation lists, the Online Certificate Status Protocol (OCSP), or associated schemes for checking the potential revocation of a certificate or public key from a server. A need exists in the art for a primary platform operating in a tamper resistant element to use time values received in order to securely determine if a certificate or public key used with cryptographic operations has been revoked.

Both (i) the long timeframes for a tamper resistant element to record and operate with server certificates, which could comprise certificates structured according to the X.509 family of standards and include a certificate issuer (CI) root certificate, and (ii) the use of potentially hundreds or more of IDS certificates signed by the CI root private key increases the importance and likelihood of a need in the art for a TRE to support or determine certificate revocation for a certificate received by the TRE. As one example, the root certificate from the GSMA for the system supporting the embedded universal integrated circuit card (eUICC) currently expires in approximately 2052. The CI certificate recorded in devices for a system of TRE as contemplated by GP OFL may similarly expire in future decades. An IDS may communicate with millions of devices with TREs and hundreds of service providers over time, and may prefer to use an IDS certificate that is valid for several years for operational purposes.

The GP OFL contemplates in section 4.2.6 on page 39 checking for validity of an IDS certificate using a timestamp received, but note this only contemplates the verification that an IDS certificate has not expired, where expiration of the IDS certificate may be several years into the future. There is no teaching or suggestion in the GP OFL for an intermediate check or verification by the TRE that if the IDS certificate or OFL authority certificate has been revoked. A need exists in the art for a primary platform in a TRE to conduct a check for certificate revocation where the device operating the TRE may not directly or efficiently or reliably communicate with the certificate issuer (CI) that signed a certificate used by the TRE, such as an IDS certificate or an image owner certificate.

Note that the IDS may be connected to the public Internet in order to support the potential millions of different devices with a TRE requesting firmware for the PP. This creates potential security risks for protecting the private key of the IDS corresponding to the public key stored by the TRE with an IDS certificate, especially over long period of time such as several years. As one example, the “Heartbleed” vulnerability in OpenSSL potentially exposed the private key operated by servers connected to the Internet. The cloud hosting service Cloudflare around 2014 had to revoke and reissue thousands of server certificates for that one vulnerability. Another, similar vulnerability may be found in the future, and several existing threats for server security continue in the families of Spectre and Meltdown vulnerabilities. The list from Common Vulnerabilities and Exposures contains thousands of entries for the year 2018 alone. Many of these vulnerabilities could result in exposure or leaking of bits of security for a private key of a server corresponding to the public key in a certificate operated by a TRE as contemplated by Global Platform and ESTI standards. Consequently, a need exists in the art for a certificate issuer to revoke a certificate used by a primary platform or “Smart Secure Platform” and reissue the certificate in a manner that the TRE can determine that the certificate has been revoked.

Many other examples exist as well for needs in the art for a primary platform to securely receive firmware from a server using certificates where the primary platform can determine if the certificate has been revoked, and the above are examples are just a few and intended to be illustrative instead of limiting.

SUMMARY

Methods and systems are provided for a primary platform to securely receive firmware from a server. A device can include a tamper resistant element. The primary platform (PP) can operate within the tamper resistant element (TRE) and comprise a secure processing environment operating within a computing device. The primary platform can comprise a secure enclave, a secure element, a trusted execution environment (TEE), or a “Smart Secure Platform” as specified by ETSI standards. The primary platform can also operate within an ARM® Trustzone implementation of a TEE. The TEE can support GlobalPlatform standards for a TEE. The computing device can comprise a mobile phone, wireless device, personal computer, laptop, or a networked transducer for the “Internet of Things”. The device can (i) include insecure components such as a general processor and a general operating system and (ii) communicate with the primary platform using a device driver such as an Open Firmware Loader (OFL) agent.

The device can connect with an internet protocol (IP) based network such as the public Internet in order to establish a secure session with a server. The server can comprise an image delivery server (IDS) and receive a firmware image from an image owner. The server can comprise a computer with a network interface to communicate with the device via the IP network. The server can record and operate a server database. The device can be one of a plurality of different devices communicating with the server. The server can operate an online certificate status protocol (OCSP) client in order to periodically obtain a signed verification of certificate validity from a certificate issuer.

In exemplary embodiments an image owner can obtain a firmware image for the primary platform. The firmware image can support the primary platform operating with an application, such as, but not limited to, an eUICC, a “Smart Secure Platform”, secure identification of the device using the primary platform, and other possibilities exist as well for supported applications. The image owner can obtain the firmware image for a plurality of different primary platforms. The firmware image from the image owner can comprise an unbound image, which could be subsequently used by the server communicating with a plurality of different primary platforms, after subsequent cryptographic operations by the server with the plurality of different primary platforms in order to create bound images. The image owner can receive a signed timestamp from an open firmware loader (OFL) authority, where the OFL authority also provides additional authorization information for the primary platform. The image owner can send the authorization information and the signed timestamp to the server. For some embodiments, the use of a primary platform could be omitted, and the firmware image could comprise firmware for a processor within a device operating in a secure manner (e.g. Trustzone, TEE, “secure enclave”, etc.). In addition, the image owner or IDS could receive the signed timestamp from a server different than a server associated with the OFL authority.

The primary platform and the server can record and operate a set of compatible cryptographic parameters and cryptographic algorithms for an elliptic curve Diffie Hellman (ECDH) key exchange algorithm, a symmetric ciphering algorithm, and elliptic curve digital signature algorithms (ECDSA). Before distribution to an end user of the computing device, a TRE manufacturer could record a set of data in nonvolatile memory for the TRE. In addition to a PP boot firmware and PP boot configuration for the PP, the data recorded in device before distribution could include a root certificate for a certificate issuer and a certificate for a timestamp authority. Other PKI keys could be recorded by a TRE manufacturer in a set of PKI keys for the primary platform as well

A certificate issuer (CI) can receive a first public key and a second public key from the server and issue certificates for each of the public keys. The certificate issuer can use a first CI private key, corresponding to a CI root certificate recorded by the primary platform, to sign the server public keys. The first public key can be associated with elliptic curve key agreement and the second public key can be associated with elliptic curve digital signature algorithms (ECDSA). The certificate issuer can also (i) operate an OCSP responder to receive queries for interim certificate validity before the expiration time of the certificates and (ii) respond with a signed response and a time value, where the time value represents the end of an interim time into the future that the certificate can be considered valid and not revoked. In exemplary embodiments, the interim time could comprise weekly updates for the time value and interim verification for the validity of the certificate. The responses from the OCSP responder can use a second CI private key, where either (i) a certificate for the second CI private key is also recorded by the primary platform, or (ii) a certificate for the second CI private key is signed by the first CI private key and the certificate is sent along with the response for the interim update for certificate validity.

After boot and startup of both the device and the TRE operating the primary platform, the device can use an OFL agent as a device driver to communicate with the primary platform. The device can use the OFL agent to obtain (i) a firmware status, (ii) the primary platform identity, and (iii) a certificate for the primary platform. The firmware status can comprise a list of parameters associated with any firmware image recorded or stored by the primary platform, including a version number for either a stored firmware image or a version number for PP boot firmware. In exemplary embodiments, the set of cryptographic parameters in the certificate for the primary platform at least specifies a specific ECC curve for use with the primary platform private key. The device can establish a secure session with the server and receive a first server certificate for the server, where the certificate includes OCSP stapling of a current OCSP response from the certificate issuer for the first server certificate. The OCSP response with the first server certificate can include a first time value. The device can forward the first server certificate with the OCSP response and the first time value to the primary platform using the OFL agent.

The primary platform can receive the first server certificate with the OCSP response and first the time value. The primary platform can use a certificate for the certificate issuer to verify the first time value, where the first time value is stored for a later comparison with a received timestamp. The primary platform can derive an ephemeral PKI key pair comprising a first ephemeral private key and a first ephemeral public key, using parameters from the first server certificate. The primary platform can conduct a first key exchange in order to derive a first symmetric ciphering key and encrypt the certificate for the primary platform using the derived first symmetric ciphering key. The primary platform can send the ephemeral public key and the encrypted certificate for the primary platform to the OFL agent in the device, which forwards the data to the server through the secure connection.

The server can receive the ephemeral public key and the encrypted certificate for the primary platform and conduct a public key validation step for the ephemeral public key. The server can conduct a second key exchange using the received first ephemeral public key and a first server private key corresponding to the server public key sent in the first server certificate, in order to derive the first symmetric ciphering key. The server can decrypt the primary platform certificate using the derived first symmetric ciphering key.

The server can derive an ephemeral PKI key pair which includes a second ephemeral public key and a second ephemeral private key. The server can conduct a series of steps to encrypt the received firmware image and the signed timestamp, where the series of steps include using (i) the public key from the primary platform certificate, (ii) a second private key corresponding to a second public key in a second server certificate, and (iii) the derived second ephemeral private key. The server can send a message to the device with at least the second ephemeral public key, the encrypted image, the signed timestamp, and the second server certificate. The message with the second server certificate can also include OCSP stapling of a current OCSP response from the certificate issuer for the certificate. The OCSP response with the second certificate can include a second time value.

The device can receive the message from the server and use the OFL agent to send the second ephemeral public key, the encrypted image, the signed timestamp, and the second server certificate to the primary platform operating in the tamper resistant element. The primary platform can conduct a series of steps in a firmware load function in order to process the data received. The device can use (a) the received second ephemeral public key and a private key corresponding to the public key in the primary platform certificate to (b) derive at least a second symmetric ciphering key. The primary platform can use the derived symmetric ciphering key and a symmetric ciphering algorithm to decrypt the encrypted data forwarded from the device in the message to the TRE. The primary platform can decrypt the encrypted firmware image. The message can include an access rights pattern that is signed by the image owner, and the primary platform can verify the signature for the access rights platform using a public key for the image owner. The primary platform can use the access rights pattern to determine if loading and operating with the firmware image is authorized, as well as other constraints for the firmware image.

The primary platform can verify the signed timestamp using a recorded certificate for the timestamp authority. The primary platform can use a certificate for the certificate issuer to verify a second time value from the OCSP stapling with the second server certificate. The primary platform can compare both (i) the first time value from OCSP stapling for the first server certificate and (ii) the second time value from OCSP stapling for the second server certificate with (iii) the received, verified timestamp value. If the received, verified timestamp value is before both the first time value and the second time value (where the first time value and the second time value can represent the end time for validity of OCSP stapling values), then the primary platform can continue the firmware load function and establish a firmware session using the received, decrypted, and authenticated firmware from the message.

If the received, verified timestamp value is after either the first time value or the second time value, then the primary platform cannot trust or rely that both the first server certificate and the second server certificate remain valid and have not been revoked. If the received, verified timestamp value is after either the first time value or the second time value, then the primary platform can send an error response to the server through the device and stop the firmware load process, so that the received firmware is not loaded until certificates with time values (e.g. outside window of time validity or “expiration” of the OCSP stapling data) greater than the timestamp are received and verified by the primary platform.

FIG.1ais a graphical illustration of an exemplary system, where a device with a tamper resistant element and a server securely transfer encrypted firmware from the server to the tamper resistant element, in accordance with exemplary embodiments. The system100can include a device102, a server103, a certificate issuer104, an image owner105, an open firmware loader (OFL) authority107, and a network114. The various computing nodes depicted inFIG.1acan establish secure sessions such as a Transport Layer Security (TLS)115session over an Internet Protocol (IP) network114, including the TLS115session depicted between device102and server103. Server103can comprise an image delivery server (IDS). Although a single server103, device102, a CI104, etc. are depicted inFIG.1a, a system100can comprise a plurality of the computing nodes. In addition, although a single server103is depicted inFIG.1a, the exemplary server103shown for system100can comprise either different physical computers such as rack-mounted servers, or different logical or virtual servers or instances operating in a “cloud” configuration, including different computing processes which are geographically dispersed.

Device102can be a computing device for sending and receiving data, including a wireless device. Device102can take several different embodiments, such as a general purpose personal computer, a mobile phone based on the Android® from Google® or the IOS operating system from Apple®, a tablet, a device with a sensor or actuator for the “Internet of Things”, a module for “machine to machine” communications, a device that connects to a wireless or wired Local Area Network (LAN), and other possibilities exist as well without departing from the scope of the present disclosure. Device102can also be a computing device according to GSMA technical document “iUICC POC Group Primary Platform requirements”, Approved Release 1.0 dated May 17, 2017, which is hereby incorporated by reference in its entirety (“GSMA PP Requirements”). Device102can comprise a device such as that depicted in FIG. 6 on page 24 of the GSMA PP Requirements. Exemplary electrical components within a device102are depicted and described inFIG.1bbelow. Other possibilities exist as well for the physical embodiment of device102without departing from the scope of the present disclosure.

Server103could also represent different logical “server-side” processes within a network, including different programs running on a server that listen and communicate using different IP port numbers within one physical server. In exemplary embodiments, server103can operate using the physical electrical components similar to those depicted and described for a device102inFIG.1bbelow. Sever103can use electrical components with larger capacities and larger overall power consumption, compared to the capacity and power consumption for the equivalent electrical components in a device102. Other possibilities exist as well for the physical embodiment of server103without departing from the scope of the present disclosure.

IP network114could be either a Local Area Network (LAN) or a Wide Area Network (WAN), or potentially a combination of both. IP network114could include data links supporting either IEEE 802.11 (WiFi) standards. Device102could also utilize a variety of WAN wireless technologies to communicate data in a secure session115with server103, including Low Power Wide Area (LPWA) technology, 3rd Generation Partnership Project (3GPP) technology such as, but not limited to, 3G, 4G Long-Term Evolution (LTE), or 4G LTE Advanced, NarrowBand-Internet of Things (NB-IoT), LTE Cat M, planned future 5G networks, and other examples exist as well. Server103can connect to the IP network114via a wired connection such as, but not limited to, an Ethernet, a fiber optic, or a Universal Serial Bus (USB) connection (not shown). IP network114could also be a public or private network supporting Internet Engineering Task Force (IETF) standards such as, but not limited to, such as, RFC 786 (User Datagram Protocol), RFC 793 (Transmission Control Protocol), and related protocols including IPv6 or IPv4. A public IP network114could utilize globally routable IP addresses and also comprise an insecure network.

As depicted inFIG.1a, device102can include an OFL agent102xand a tamper resistant element113. A device102can also include other electrical components and data as depicted and described in connection withFIG.1bbelow, where the components for a device102are described in more detail. An OFL agent102xcan comprise a device program such as a device driver operating on a general processor outside of the tamper resistant element113. Tamper resistant element (TRE)113can comprise a tamper resistant element as described in the GSMA PP Requirements document. Tamper resistant element can comprise a silicon enclave within a tamper resistant chip such as a “system on chip” as depicted and described in connection withFIG.1bbelow.

TRE113in device102can include a primary platform (PP)101, where a primary platform is also described in the GSMA PP Requirements document and the GP OFL document. TRE113could also comprise a “Smart Secure Platform” (SSP) as described in ETSI TC SCP Meeting #81 document “SCP(17)000188”, which is hereby incorporated by reference in its entirety. Note that draft specifications for an SSP such as “103 666-1 SSP Draft Specification 0.8.0” are not publicly available and have restricted access on the ETSI web site as of Dec. 15, 2018. Primary platform101can comprise a secure operating environment, a secure enclave, a secure element, and include a dedicated processing core within a processor for device102. Primary platform101can also operate in a Trusted Execution Environment (TEE) within a processor for device102, or also within an ARM® “Trustzone” processing environment. Primary platform101can also comprise a SSP as contemplated by ETSI documents and draft specifications for 5G networks.

TRE113and PP101can support a variety of applications. TRE113can comprise the physical device such as that depicted inFIG.1aandFIG.1bbelow (e.g. silicon, electrical contacts, housing, etc.), and a primary platform101can comprise a secure processing environment operating within the TRE113(e.g. operating system, drivers, etc.). With appropriate firmware106, TRE113and PP101could operate as an “integrated universal integrated circuit card” (iUICC), an “embedded universal integrated circuit card” (eUICC), a secure element for banking applications or payments from mobile phones, an radio-frequency identity (RFID) card, a secure bootstrap environment for device102, a virtual key for cars or door locks, an secure environment for recording an identity and secret or private keys for drivers licenses, passports, online or web-site access, etc. Other applications for firmware106operating in TRE113and PP101are possible as well, without departing from the scope of the present disclosure. In general, cryptographic keys and cryptographic algorithms and parameters could be stored in PP101in order to securely support applications such as device programs operating on device102. In this manner, an insecure device program also operating on device102would not feasibly be able to ready the cryptographic keys or use the cryptographic algorithms stored in PP101.

Each of the above exemplary applications can be operated by a firmware106running within TRE113on PP101. Although a single firmware106is depicted and described in connection withFIG.1a, a TRE113and PP101can operate a plurality of different firmware106simultaneously (or “effectively simultaneously” such that rapid switching of a processor in TRE could make the firmware to appear to operate concurrently over a longer period such as a millisecond, even though only one firmware may operate at one time over a shorter period such as a nanosecond). A primary firmware can comprise the host environment for the primary platform and a secondary firmware can comprise a guest or virtual machine operating in the primary platform. A firmware106can comprise either the primary firmware or the secondary firmware as described in the previous sentence and other references herein.

Firmware106(as secondary firmware) can operate within a virtual machine for a processor for TRE113and PP101. As one exemplary embodiment, firmware106can comprise a JAVA applet running on a java virtual machine in TRE113, where the JAVA virtual machine can be recorded in secure boot firmware for TRE113and PP101. Different firmware106operating within TRE113can be isolated from each other by conventional technology for processing hosts and/or virtual machines. Other possibilities exist as well for a TRE113and PP101to operate as a host for an application downloaded as firmware106. In summary, the overall security of an application operated by TRE113and PP101can depend on securely receiving firmware106by TRE113and PP101from a server103.

PP101can include a set of PKI keys101a, a key exchange algorithm101b, and a load function119. Other data, functions, and electrical components can be included in a PP101, such as the data, functions, and electrical components for a primary platform as described in the GSMA PP requirements document and the GP OFL document. As one example, but not depicted inFIG.1a, a primary platform101can record a globally unique identity for the primary platform and/or TRE113. A set of PKI keys101acan record a plurality of certificates and private keys for primary platform101, which can include a certificate for (i) the IDS server for elliptic curve cryptography key agreement (ECKA) of CERT.IDS1.ECKA103cand (ii) the chip part number for a elliptic curve digital signature algorithm (ECDSA) of CERT.PN.ECDSA101a-2. A set of PKI keys101acan also include the exemplary keys depicted and described in connection withFIG.1cbelow. CERT.PN.ECDSA101a-2along with the corresponding private key can be recorded within PP101upon manufacturing of the TRE113. CERT.IDS.ECKA103ccan be received by PP101after manufacturing, such as during setup of a TLS115session and before PP101conducts the steps for a key exchange algorithm A101b.

Certificates depicted inFIG.1asuch as CERT.IDS.ECKA101a-1and CERT.IDS2.ECDSA103dcan specify values or settings for (i) conducting an ECDH or ECDHE key exchange, (ii) mutually deriving a symmetric ciphering key, (iii) an ECC curve which could comprise a commonly used name curve, (iv) PKI key lengths, and/or (iv) an elliptic curve digital signature algorithm (ECDSA), etc. Each of the certificates associated with PP101, server103, and other nodes inFIG.1acan record at least one compatible set of cryptographic parameters within the depicted certificates. In exemplary embodiments, the certificates inFIG.1acan specify values for algorithms supporting post-quantum cryptography, such as lattice-based algorithms, code-based algorithms, or multivariate-based algorithms, and other possibilities exist as well without departing from the scope of the present disclosure.

Cryptographic parameters within certificates can specify values for an elliptic curve cryptography (ECC) curve name, key length, key formatting (e.g. compressed or uncompressed), encoding rules, etc. As contemplated herein, the parameters and cryptographic algorithms used with certificates, ECC PKI keys and key exchanges or elliptic curve digital signature algorithms in the present disclosure can be compatible and substantially conform with ECC algorithms and keys as specified in (i) the IETF Request for Comments (RFC) 6090 titled “Fundamental Elliptic Curve Cryptography Algorithms”, and (ii) IETF RFC 5915 titled “Elliptic Curve Private Key Structure”, and also subsequent and related versions of these standards. In addition, parameters and algorithms for ECDSA in certificates can be compatible and support BSI Technical Guideline TR-03111: Elliptic Curve Cryptography. Version 2.0. Other possibilities exist as well for cryptographic parameters and algorithms specified in a certificate without departing from the scope of the present disclosure.

For use of ECC algorithms, parameters in a certificate can specify elliptic curve names such as, but not limited to NIST P-256, sect283k1, sect283r1, sect409k1, sect409r1, and other possibilities exist as well. Further, elliptic curves that do not depend on curves currently specified by the National Institute of Standards and Technology (NIST) could be utilized as well, such as, but not limited to, Curve22519, curve448, or FourQ. Parameters in a certificate can specify domain parameters for elements in system100to calculate values or numbers in a compatible manner, such as (i) a common base point G for use with ECC PKI key pairs and (ii) a defining equation for an elliptic curve.

Key exchange algorithm101bcan use CERT.IDS1.ECKA103band a derived ephemeral PKI key pair for PP101in order to derive a symmetric ciphering key M1and message authentication code key H1. The public key for the derived ephemeral PKI key pair can comprise PKE1depicted for message117inFIG.1a. Key exchange algorithm101bcan comprise the steps for section 4.1.2.1 and 4.1.2.2 on page 35 of the GP OFL document. For embodiments that support the use of post-quantum cryptographic algorithms instead of ECC algorithms, the key exchange algorithm101bcan comprise a key exchange mechanism, where the symmetric ciphering key M1could be encrypted using a public key and decrypted using a private key.

Load function119can use data received in message118, including an ephemeral public key for the IDS server of PKE2in order authenticate and decrypt an encrypted firmware106*. As contemplated herein, an encrypted firmware106can be depicted and described herein as “firmware106*” and a plaintext firmware106for a primary platform to establish a firmware session can be depicted and described as “firmware106”. A load function119for a primary platform is also depicted and described in connection withFIG.1cbelow. Individual steps within a load function119inFIG.1aare also described below with the description of message flows between the nodes in system100and operation of PP101.

Firmware106recorded in PP101upon conclusion of a load function119can provide machine executable instructions for a processor in TRE113to execute or run. Firmware106could comprise a collection of compiled software libraries and programming code for the operation of TRE113and PP101. Firmware106could comprise a Java-based applet or application as secondary firmware, where boot firmware of PP101establishes and operates a Java virtual machine such as, but not limited to JamVM or HaikuVM. Other platforms for virtualization and emulation of a computer system by PP101are possible as well, without departing from the scope of the present disclosure, where firmware106can be compiled or formatted to operate on PP101operating as a host for the virtualized computer system. In exemplary embodiments, firmware106can comprise an application where PP101operates as a process virtual machine or an application virtual machine. The environment in which firmware106operates can also be referred to as a managed runtime environment (MRE). Firmware106could also comprise a primary firmware for the operation of PP101as a host computer for the operation of secondary firmware.

Firmware106can comprise compiled software or machine executable instructions for either (i) a processor or (ii) a virtual machine in PP101, and may also be referred to herein as an “image”. In other words, although (A) firmware may traditionally refer to machine executable programming instructions that provides low-level or hardware control over computing hardware, such as memory and physical interfaces, as contemplated herein, (B) “firmware” can comprise higher level software written for a virtual machine. In addition, the computing environment of a primary platform can require secure functions such as writing and reading cryptographic keys for a firmware106specially designated protected memory, and thus firmware106comprising high level software may include features similar to traditional firmware. Further, firmware may be traditionally associated with machine executable instructions that are read from a read only memory, and firmware106comprising software that is loaded into primary platform101can have features after loading in PP101that are similar to traditional firmware, such as firmware106not being readily modified by an insecure processor in device102. In any case, although “firmware106” is described herein as firmware, “firmware106” can comprise any collection of machine executable instructions which can be loaded and operated by primary platform101. Similarly, the GSMA PP Requirements document and GP OFL document refer to the collection of machine executable code for a primary platform101as “firmware”.

As depicted inFIG.1a, an image delivery server103(or “server103”) can include a public key PK.IDS1.ECKA103a, a public key PK.IDS2.ECDSA103b, a record certificate function103e, an OCSP client103f, a public key validation function103g, a key exchange A′103halgorithm, a key exchange B′103ialgorithm, and a OCSP query repeat103jfunction. Although not depicted inFIG.1a, a server103could record the corresponding private keys for public keys PK.IDS1.ECKA103aand PK.IDS2.ECDSA103b. Server103, PP101, and the other nodes depicted inFIG.1acan also commonly share cryptographic parameters and cryptographic algorithms as specified in the depicted certificates forFIG.1aandFIG.1cbelow. The record certificate function103efor server103can record the certificate for both (i) PK.IDS1.ECKA103acomprising CERT.IDS1.ECKA103cand (ii) PK.IDS2.ECDSA103bcomprising CERT.IDS2.ECDSA103d, where the public keys are sent to certificate issuer104and the certificates are received from certificate issuer104.

OCSP client103fcan comprise a client to operating according to the online certificate status protocol (OCSP) according to IETF RFC 6960 titled “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP”, which is hereby incorporated by reference in its entirety. OCSP client103fcould support future or related standards for periodically verifying or determining if a previously issued certificate has been revoked or is invalid. OCSP client103fcan submit a query109for a certificate such as CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dto CI104and receive a response110from CI104. An exemplary query109and response110for an OCSP client103fis also depicted and described in connection withFIG.2abelow. Note that response110from OCSP responder104dincludes a signed time T2104e, where signed time T2104ecan comprise both a digital signature portion and a plaintext time value for T2104e-1(inFIG.2a). The value for T2104e-1can comprise a duration of validity confirmation of CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dover a shorter period of time than the expiration time of the certificate, such as an exemplary several days or few weeks, instead of the certificate expiration time T1104c. By receiving the value for T2104ein an authenticated manner and using the subsequent steps described herein, PP101can reasonably be assured that a certificate associated with IDS server103, such as CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dhas not been revoked.

A key exchange A′103halgorithm for server103can use a received ephemeral ECC public key PKE1from a message117and the secret or private key for PK.IDS.ECKA103ain order to mutually derive a symmetric ciphering key M1and MAC key H1with PP101. A key exchange A′103hcan include the step “KS13=DERIVE(SK.IDS1.ECKA)[PK.OFLECDHE]” in section 4.1.2.3 of the GP OFL document on page 36. Server103can then derive an ephemeral PKI key pair that includes an ephemeral public key of PKE2and a corresponding ephemeral private key. Server103can conduct a key exchange B′103iusing the corresponding ephemeral private key and the public key from CERT.PN.ECDSA101a-2. A key exchange B′103ican include the step “KS26=DERIVE(SK.IDS2.ECDHE)[PK.OFLECDHE]” in section 4.1.2.3 of the GP OFL document on page 36. Although not depicted inFIG.1a, a server103can also conduct the other steps from section 4.1.2.3 of the GP OFL document on page 36 along with key exchange A′103hand key exchange B′103iin order to prepare and process a message118with an encrypted firmware106* in a secure and authenticated manner.

A server103can include an OCSP query repeat function103j. The OCSP query repeat function103jcan determine if a time value T2104efrom an OCSP response110is less than a timestamp T3108b-1from an image owner105. If time value T2104eis less than timestamp T3108b-1, then server103can repeat the OCSP query109. Time value T2104e-1could be less than timestamp T3108b-1for embodiments where T2104e-1and timestamp T3108b-1are close together and clocks for nodes in a system100are not fully synchronized, such as an exemplary minute apart in time. Additional details for the operation of an OCSP query repeat function103jwith associated time values will be described below in the overall sequence of message flows between the nodes.

A system100can also include a certificate issuer (CI)104. CI04can comprise a collection of servers to issue certificates and also verify certificate status after issuance. CI104can include private or secret keys SK.CI.ECDSA104aand SK.CI-OCSP.ECDSA104b, a verify and sign function104c, certificates CERT.IDS1.ECKA103cand CERT.IDS2.ECDSA103d, and an OCSP Responder104d. Secret key SK.CI.ECDSA104acan comprise a root private key for the root certificate and public key in CERT.CI.ECDSA101a-3recorded in primary platform PKI keys101aas depicted inFIG.1cbelow. Secret key SK.CI-OCSP.ECDSA104bcan comprise a private key corresponding to the public key in CERT.CI-OCSP.ECDSA101a-4recorded in primary platform PKI keys101aas depicted inFIG.1cbelow. The verify and sign function104ccan receive public keys from IDS103such as PK.IDS1.ECKA103aand PK.IDS2.ECDSA103band use the secret key SK.CI.ECDSA104ain order to generate certificates of CERT.IDS1.ECKA103cand CERT.IDS2.ECDSA103d, respectively. Note that CERT.IDS2.ECDSA103dincludes an expiration time T1104c, which represents the time for end of the validity of the certificate.

CI104can operate an OCSP responder104d. OCSP responder103dcan comprise a responder to operating according to the online certificate status protocol (OCSP) according to IETF RFC 6960 titled “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP”, which is hereby incorporated by reference in its entirety. OCSP responder104dcould support future or related standards for periodically confirming or reporting if a previously issued certificate has been revoked or is invalid. OCSP responder104dcan receive a query109for a certificate such as CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dfrom a server such as IDS server103and generate a response110for the query109. An exemplary query109and response110for an OCSP responder104dis also depicted and described in connection withFIG.2abelow.

In exemplary embodiments, CI104uses private key SK.CI-OCSP.ECDSA104bfor creating and generating the signed time value T2104einstead of SK.CI.ECDSA104a, and in this manner the SK.CI.ECDSA104acan remain more secured (such as104abeing recorded offline on a different server). Consequently, PP101can use CERT.CI-OCSP.ECDSA101a-4recorded in PKI keys101a(shown inFIG.1c) to verify the signed time value T2104e. In other exemplary embodiments, CI104can use the SK.CI.ECDSA104ato generate a signature for signed time value T2104e, and in these embodiments TRE113and PP101can use the CERT.CI.ECDSA101a-3(shown inFIG.1c) to validate the signed time value T2104eusing steps equivalent to step108binFIG.2bbelow.

A system100can also include an image owner105. Image owner105can comprise a collection of servers to create or record firmware106images for PP101and also process or issue authentication tokens to enable PP101to load and operate firmware106. The authentication tokens can include information for permission or rights of the TRE113to operate with the firmware106. Note that a TRE manufacturer could also operate as an image owner105, and other possibilities exist as well for the entity that performs the functionality of an image owner105. An image owner105in a system100can be compatible with an image owner as described in the GP OFL document. Although a single firmware106image is depicted inFIG.1a, an image owner105could record a plurality of firmware106images. Image owner105can receive signed timestamp T3108bfrom an OFL authority107. Note that a signed timestamp108bcan include both a plaintext time value T3108b-1and a digital signature from a timestamp authority (TSA). For some exemplary embodiments, a signed timestamp108bcan include both a plaintext time value T3108b-1and a transaction identity (ID)117x, where (i) the transaction ID117xcan be generated by TRE113. Additional details regarding using a signed timestamp T3108bare provided inFIG.2bbelow.

A system100can also include an OFL authority107. OFL authority107can comprise an entity or collection of servers for granting the rights to an Image Owner for managing an image by using OFL. Although not depicted inFIG.1a, an OFL authority107can also send an image owner105an authentication token with access rights. In some embodiments, such as when an OFL state becomes “locked”, an image owner105can become the OFL Authority107. As depicted inFIG.1a, and OFL authority can operate with a time stamp authority (TSA)108. TSA108could operate according to the American National Standards Institute standard X9.95 for creating signed timestamps, and other possibilities exist as well. Although depicted as operated by OFL authority107, TSA108could operate outside of OFL authority107and be associated with OFL authority107or an IDS103.

TSA108can record a secret key SK.TSA108acorresponding to the public key in CERT.TSA101a-5from PP101PKI keys101ainFIG.1c. TSA108can operate a clock for tracking date and time that is closely synchronized with established time standards. TSA108can create a signed timestamp T3108busing the SK.TSA108a. The signed timestamp T3108bcan comprise a digital signature portion and a plaintext timestamp value of T3108b-1. For some embodiments as depicted inFIG.1a, TSA108could include a transaction ID117xwith the signed timestamp T3108b, where (i) the TSA108could receive the transaction ID117xfrom a message117bfrom IDS103and (ii) the IDS103could receive the transaction ID117xfrom TRE113in a message117. As depicted inFIG.1a, the signed timestamp T3108bcan be received by image owner105, and image owner105can send server103a message112with both the encrypted firmware106and the signed timestamp108b, along with other data to support an open firmware loader.

The nodes for system100depicted inFIG.1acan communicate a series of messages with data in order for PP101to receive firmware106in a secure an authenticate manner. As described above, IDS server103can periodically conduct an OCSP query109with CI104in order to receive a response110, where an exemplary response110is depicted and described in connection withFIG.2abelow. The response110can include a digital signature104efor time value T2104e-1, where the signed time value T2104e-1represents a time where a certificate for IDS103such as CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dhave not been revoked. In other words, the signed time value T2104e-1can comprise a point in time in the future through which the certificate can be considered valid and not revoked, where the point in time is shorter than the certificate expiration time T1104c. In exemplary embodiments the signed time value T2104e-1could be an exemplary week into the future, while certificate expiration time T1104ccould be several years into the future.

As described above, server103could receive firmware106image and a digital signature108bfor timestamp value T3108b-1from image owner105in a message112. The signed timestamp value T3108b-1could originate from a TSA108. Note that IDS103could receive message112before or after device102and IDS server103establish a secure session such as TLS115(for embodiments where a transaction ID117xis not included in digital signature108bfor at least T3108b-1). For embodiments where a transaction ID117xis included in digital signature108b, then message112could be received by IDS103after (i) the receipt of a message117from TRE113and (ii) sending or transmitting a transaction ID value117xto TSA108in a message117b.

Although timestamp value T3108b-1(originating from a timestamp authority108) along with signature108bis depicted inFIG.1aas being received by server103from an image owner105, timestamp value T3108b-1along with signature108bcould be received from another entity for a system100besides image owner105. For some embodiments, server103could operate as a timestamp authority and generate timestamp value T3108b-1along with signature108b. Device102and server103can establish a secure session, which could comprise a TLS session115. For system100, server103and device102may establish a secure session115, which could comprise establishing a secure communications link between the two servers using protocols such as TLS, IPSec, a virtual private network (VPN), a secure shell (SSH), or similar networking, transport, or application layer technologies in order to establish secure communications between server103and device102.

Secure session115is depicted inFIG.1aas “TLS115” but other methods for establishing secure sessions could be used as well, including Datagram Transport Layer Security (DTLS). Secure session115can utilize certificates for server103and/or device102in order to provide mutual authentication and mutual key derivation for a symmetric encryption key in secure session115. For some embodiments, the use of a certificate for device102in secure session115could be omitted, and for these embodiments only server103would be authenticated. Other possibilities exist as well for establishing a secure session108between server103and device102without departing from the scope of the present disclosure. Server103can begin listening for incoming messages from a device102using a physical network interface that provides connectivity to the IP network114and server103can use a specific port number such as TCP port443to listen for incoming data for secure session115from a device102. Note that TLS session115is established between device102and server103, and a TRE113may not establish the secure session directly, but rather send and receive data over a secure session established by device102.

As depicted inFIG.1a, server103can use an OCSP Query Repeat103jstep after the receipt or generation of a signed timestamp T3108b-1, such as the receipt in a message112. For embodiments where (i) a clock to generate T3108b-1and (ii) the validity time set by a CI104and specified in T2104e-1are close together, such as a few seconds apart, there could be instances where time for received T3108bis after the time value T2104e-1. Server103could detect that T3108b-1is after T2104e-1in an OCSP Query Repeat103jstep before sending message118and consequently “refresh” or repeat the query109with responder101din order to obtain a response110with a signed time value T2104e-1that is after the signed timestamp T3108b-1.

Server103can then send device102a message116, where message116can include a value for code M and the certificate for server103comprising CERT.IDS1.ECKA103c. Code M can comprise a challenge or nonce from server103which will subsequently be signed and used by PP101in order to authenticate PP101with server103. Note that in exemplary embodiments, CERT.IDS1.ECKA103cin message116can utilize OCSP stapling, which is also known as the TLS Certificate Status Request extension. The extension is described in section 8, “Certificate Status Request” of IETF RFC 6066 titled “Transport Layer Security (TLS) Extensions: Extension Definitions”. In other words, the certificate103cin message116can include a response110from OCSP responder104d, where a response110is also depicted and described in connection withFIG.2abelow. An extension for certificate103cverifying CERT.IDS1.ECKA103chas not been revoked for an interim period could utilize related or future versions of the standards as well.

Note that CERT.IDS1.ECKA103cin message116can include a first signed time value T2104e-1where the digital signature comprises104e. A second time value T2104e-1for CERT.IDS2.ECDSA103dcan be included in message118below. In exemplary embodiments, message116could also include a CERT.CI-OCSP.ECDSA101a-4(not shown inFIG.1abut shown inFIG.1c), where CERT.CI-OCSP.ECDSA101a-4can be used to verify the first signed time value T2104e-1in the form of digital signature104e. For embodiments where CERT.CI-OCSP.ECDSA101a-4is included in a message116, then PP101can use certificate CERT.CI.ECDSA101a-3to validate the certificate CERT.CI-OCSP.ECDSA101a-4.

Device102can receive message116and forward data in the message to PP101through OFL agent102x. PP101can receive the data from message116and conduct steps in section 4.1.2.1 and 4.1.2.2 of the GP OFL document, including a key exchange101bin order to encrypt CERT.PN.ECDSA101a-2. PP101can then respond to OLF agent102xwith a derived ephemeral public key PKE1and the encrypted CERT.PN.ECDSA101a-2. Device102using a TRE113can also generate a transaction ID117x, where transaction ID117xcan comprise a pseudo-random number or other unique number to uniquely identify a subsequent message117and response118. Device102can then send server103a message117, where message107includes the derived ephemeral public key PKE1and the encrypted CERT.PN.ECDSA101a-2, and also the transaction ID117x. Note that message117can include other data from steps in section 4.1.2.1 and 4.1.2.2 of the GP OFL document.

Server103can receive message117and conduct the series of steps to verify the received ephemeral public key PKE1and derive a symmetric ciphering key that was used to encrypt CERT.PN.ECDSA101a-2. Server103can conduct a public key validation step103gon received ephemeral public key PKE1in order to ensure the key is valid and on the selected curve in parameters for CERT.IDS1.ECKA103a. Step103gby server103can comprise conducting the steps for an ECC Full Public-Key Validation Routine in section 5.6.2.3.2 of FIPS publication SP800-56A (revision 2) for the received device ephemeral public key PKE1. Alternatively, step103gcan comprise server103performing the steps ECC Partial Public-Key Validation Routine in section 5.6.2.3.3 of the same FIPS publication. Other example steps within a public key validation step103gcan comprise (i) verifying the public key is not at the “point of infinity”, and (ii) verifying the coordinates of the point for the public key are in the range [0, p−1], where p is the prime defining the finite field. Other possibilities exist as well for evaluating and validating a received public key is cryptographically secure in a public key validation step103g, without departing from the scope of the present disclosure.

In exemplary embodiments, a public key validation step103gcan include verifying that a point or public key received in a message such as message117is not reused, and in this manner a step103gcan be used to reject messages299that could comprise a “replay attack”. Server101could record in a server database a list of received PP101ephemeral public keys PKE1for an extended period of time, and if any key PKE1is reused then message117could be rejected. The period of time could be suitable for the application used by TRE113and server103, including potentially a period of years. As contemplated in the present disclosure a PP101and server102can conduct a public key validation step103gany time a public key or a point on an elliptic curve is received.

Server103can conduct the key exchange A′103hwith the PKE1and secret key for PK.IDS1.ECKA103ain order to derive the symmetric ciphering key. Server103can use the symmetric ciphering key to decrypt CERT.PN.ECDSA101a-2and read and process data using the plaintext certificate. Note that transaction ID117acan be included either (i) within ciphertext that includes CERT.PN.ECDSA101a-2or (ii) as plaintext within message117and external to the ciphertext. For some exemplary embodiments as depicted inFIG.1a, server103can then send the Timestamp Authority (TSA)108the transaction ID117ain a message117b.

Server103can use the steps in section 4.1.2.3 of the GP OFL document in order to process data for a message118with the ciphertext firmware106*. Server103can receive the data for a message118to send to device102from image owner105in a message112. Message118can include both (i) a digital signature108bfor timestamp T3108b-1and (ii) the timestamp T3108b-1. A server103can conduct the key exchange step B′103iwhen conducting the steps for section 4.1.2.3 of the GP OFL document. Server103can then send device102a message118, where message118includes an ephemeral public key PKE2, (i) the ciphertext firmware106* (ii) an encrypted CERT.IDS2.ECDSA103d, and (iii) a timestamp T3108b-1along with the digital signature108bfor the timestamp T3108b-1. For some exemplary embodiments, both the timestamp T3108b-1and the digital signature108bfor the timestamp T3108b-1can be included within encrypted data within message118, such as within a value M4from the load function119depicted inFIG.1cbelow.

Note that in exemplary embodiments, CERT.IDS2.ECDSA103din message118can utilize OCSP stapling, which is also known as the TLS Certificate Status Request extension as described above. In other words, the certificate103din message118can include a response110from OCSP responder104d, where a response110is also depicted and described in connection withFIG.2abelow. An extension for certificate103dverifying CERT.IDS2.ECDSA103dhas not been revoked for an interim period could utilize related or future versions of the standards as well. Note that CERT.IDS2.ECDSA103din message118can include a second time value T2104e. A first time value T2104efor CERT.IDS1.ECKA103ccould be included in message116above. The timestamp T3108b-1can be from TSA108and received by server103in message112.

In exemplary embodiments, the timestamp T3108bcan be different than the “timestamp” generated by IDS1 in FIG. 4.1 of the GP OFL document. The timestamp generated by IDS1 in the GP OLF document (i) is not signed using a digital signature algorithm such as ECDSA and (ii) verified by TRE113using a certificate such as Cert.TSA101a-5(depicted inFIG.1cbelow). In other words, the GP OFL document does not suggest a separate timestamp or verification means other than the generation of a timestamp and encryption with a static public key from an image delivery server. Further, there is no teaching or suggestion in the GP OFL document for using the transaction ID to generate the timestamp depicted in FIG. 4.1 of the GP OFL document.

Device102can receive message118and forward PP101in TRE113data from the message using OFL agent102x. PP101can receive data in message118. PP101can then conduct a load function119, where details for a load function119are also depicted and described in connection withFIG.1cbelow. In summary, load function119for PP101can conduct the series of steps for section 4.1.2.4 of the GP OFL document on page 37 with at least the additional steps depicted inFIG.1a. Note that steps in section 4.1.2.4 of the GP OFL document on page 37 include the steps to derive symmetric ciphering keys and convert the encrypted data in message118into plaintext. As depicted inFIG.1a, the use of brackets such as “{ }” depicts that the data in a message is encrypted with a symmetric ciphering key and a symmetric ciphering algorithm.

In a step119a, PP101can verify the digital signature for both (i) the first time value T2104efor CERT.IDS1.ECKA103c(in OCSP stapling extensions for the certificate) and (ii) the second time value T2104efor CERT.IDS2.ECDSA103d(again in OCSP stapling extensions for the certificate) using CERT.CI-OCSP.ECDSA101a-4within PKI keys101aas depicted inFIG.1c. Note that the first time value T2104e-1can be received by PP101along with the digital signature104ein a message116and the second time value T2104e-1can be received by PP101along with the digital signature104ein a message118. The exemplary logic for a step119ais also depicted for a load function119inFIG.1cbelow, such as the depicted step of “VERIFY(CERT101a-4) [Signed T2104e]”. An exemplary signature verification step using a public key, a value, and a signature is also depicted and described in connection withFIG.2bbelow. As described above, T2104ecan comprise two portions of a signature and the plaintext time value T2104e-1, as depicted and described in connection withFIG.2abelow. Upon conclusion of a step119a, PP101can record the first and second plaintext time values T2104e-1for use in a subsequent time comparison step119c(where the first plaintext time value T2104e-1was with CERT.IDS1.ECKA103cand the second plaintext time value T2104e-1was with the CERT.IDS2.ECDSA103d. Note that the verification step119aconfirms the signatures104efor the first time value T2104e-1and second time value T2104eare valid, but PP101may need to verify and read a plaintext value for timestamp T3108b-1before determining if the first time value T2104e-1and second time value T2104e-1are acceptable time values (such as determining if time T3108b-1is in the future of a time T2104e, which could be an error or unacceptable state since a certificate may have been revoked after time T2104eand before time T3108b). In other words, since PP101may not have the functionality to keep local or UTC date and time, additional data and steps can be required in order to determine if CERT.IDS1.ECKA103cand CERT.IDS2.ECDSA103dhave not been revoked or remain reasonably valid using both (i) first time T2104eand second time T2104e, and (ii) time T3108b.

A step119bwithin load function119can comprise PP101verifying a signature108bfor timestamp T3108b-1using a public key from a certificate associated with TSA108, such as CERT.TSA101a-5in PP101PKI keys101aas depicted inFIG.1cbelow. The exemplary logic for a second step119ais also depicted for a load function119inFIG.1cbelow, such as the depicted step of “Verify(CERT101a-5) [Signed T3108b]”. Step119bcan also comprise PP101storing the timestamp T3108b-1for use in subsequent steps. Note that the signature108bfor timestamp T3108b-1can also be over the transaction ID117xgenerated by TRE113and PP101in the processing of a message117. Part of a step119bcan include verifying that digital signature for timestamp T3108bis also over (or includes) the transaction ID117x. In this manner, TRE113and PP101can trust that the signature108bfor timestamp T3108b-1is current and generated after TRE113creates transaction ID117xand sends message117. In other words, the use of transaction ID117xhelps prevent a “reply attack” by server103simply sending an old timestamp value.

A step119cwithin load function119can comprise PP101comparing the first and second plaintext time values T2104e-1and timestamp T3108b-1. Again, PP101may not keep date and time due to limited resources of a TRE113, and thus can rely on time values with digital signatures that have been previously verified in steps119aand119bin order to determine if a certificate remains valid or reasonably determine that a certificate has not been revoked. In step119c, PP101can compare timestamp T3108b-1with both the first time T2104e-1associated with CERT.IDS1.ECKA103c(from message116) and the second time T2104e-1associated with CERT.IDS2.ECDSA103d(from message118). The time values T2can represent the “next update” date and time from an OCSP response110as depicted inFIG.2a, for both of the certificates103cand103d. The status of the certificates in an OCSP response can also be “good” or the equivalent of not being revoked. Time values T2should be in the future when representing the “Next Update” time within an OCSP response110as depicted inFIG.2a(while PP101may not track local or global time).

PP101can compare the first and second time values T2104e-1(from message116and message118) with timestamp T3108b-1in a step119c. If the time values T2104e-1are greater than timestamp T3108b, then T3108bcan be considered in the future and certificates CERT.IDS1.ECKA103cand CERT.IDS2.ECDSA103dcan be accepted and PP101can proceed to step119dfor establishing a firmware session with plaintext firmware106. Alternatively, PP101could determine that timestamp T3108bis less than either of time values T2104e-1in a step119cin order to accept the certificates103cand103d. Although not depicted inFIG.1a, TRE113and PP101could also use the “timestamp” value from the GP OFL document in FIG. 4.1 (“GP timestamp”) to additionally confirm proper time values. For example, the PP101could confirm that the GP timestamp is less than the first and second time values T2104efor certificates103cand103d, respectively.

Note that PP101should perform the other steps for a load function119such as certificate verification, at least one ECDH key exchange to derive a symmetric key, and symmetric decryption of ciphertext in message118in order to read an authenticated the plaintext firmware106. Exemplary additional steps are depicted and described in connection withFIG.1c, and also the exemplary additional steps could comprise the steps within section 4.1.2.4 of the GP OFL document. Note that for some embodiments, the use of two separate time values T2104e-1and/or two separate certificates such as CERT.IDS1.ECKA103c(from message116) and CERT.IDS2.ECDSA103d(from message118) could be omitted, and the use of a single time value T2104e-1for a single certificate could be use in a step119c.

For a first portion of step119c, if timestamp T3108b-1is either in the future or greater than the first time value T2104e-1(e.g. from a message116), then PP101cannot be reasonably assured or confirm that CERT.IDS1.ECKA103cremains valid and the certificate could potentially be revoked. An equivalent determination in a step119ccan be if the first time value T2104e-1is less than or at a past time compared to timestamp T3108b-1. For this case PP101can stop the firmware106load function119and conduct other steps or queries with server103in order to notify or attempt to rectify the error state. In other words, PP101may not be able to confirm CERT.IDS1.ECKA103cremains valid at the time of timestamp T3108b-1. Alternatively PP101could determine that the first time value T2104e-1is in the future or greater than timestamp T3108b-1, and thus CERT.IDS1.ECKA103cwas reasonably valid and not revoked at the time timestamp T3108b-1was created. If the first time value T2104e-1is in the future or greater than timestamp T3108b-1, then PP101can proceed with a second portion of step119cbefore loading firmware106and step119dfor creating a firmware session to begin operating with the firmware106(after the next check of the second time value T2104e-1in the next paragraph).

For a second portion of step119c, if timestamp T3108b-1is in the future or greater than or after a second time value T2104e-1associated with certificate103d, then PP101cannot be reasonably assured or confirm that CERT.IDS2.ECDSA103dhas been revoked. An equivalent determination in a step119ccan be if the second time value T2104e-1is less than or at a past time compared to timestamp T3108b. For this case PP101can stop the firmware106load function119and conduct other steps or queries with server103in order to notify or attempt to rectify the error state. In other words, PP101cannot confirm CERT.IDS2.ECDSA103dremains valid at the time of timestamp T3108b-1.

Alternatively, for a second portion of step119c, PP101could determine that the second time value T2104e-1is in the future or greater or after timestamp T3108b-1, and thus CERT.IDS2.ECDSA103dwas reasonably valid and not revoked at the time timestamp T3108b-1was created. If the second time value T2104e-1is in the future or greater than or after timestamp T3108b-1(and the first portion of step119cis also successful), then PP101can proceed with loading firmware106and step119dfor creating a firmware session to begin operating with the firmware106. The conclusion of a step119dfor PP101can comprise the exemplary state of loaded firmware in state3of loaded firmware in FIG. 2-5 of section 2.4 “Loading Procedure” of the GP OLF document. Other examples exist as well for (i) loading firmware106after a step119cto compare time values and (ii) establishing a firmware session in a PP101without departing from the scope of the present disclosure.

FIG.1bis a graphical illustration of hardware, firmware, and software components for a device, including a tamper resistant element with a primary platform, in accordance with exemplary embodiments.FIG.1bis illustrated to include many components that can be common within a device102, and device102may also operate in a wireless configuration in order to connect with a wireless network. In a wireless configuration, the physical interface102aof device102may support radio-frequency (RF) communications with networks including a wireless network via standards such as GSM, UMTS, mobile WiMax, CDMA, LTE, LTE Advanced, 5G, and/or other mobile-network technologies. In a wireless configuration, the physical interface102amay also provide connectivity to local networks such as 802.11 WLAN, Bluetooth, Zigbee, or an IEEE 802.15.4 network, among other possibilities. In a wireless configuration, device102could use a physical interface102aconnected with both a wireless WAN and wireless LAN simultaneously. In a wired configuration, the physical interface102acan provide connectivity to a wired network such as through an Ethernet connection or USB connection.

The physical interface102acan include associated hardware to provide connections to components such as radio-frequency (RF) chipsets, an RF amplifier, an antenna, cable connectors, RF filters, etc. Device drivers102gcan communicate with the physical interfaces102a, providing hardware access to higher-level functions on device102. Device drivers102gmay also be embedded into hardware or combined with the physical interfaces. Device drivers102gcan include an OFL agent102x, which can be utilized by a device102and operating system102hin order to read and write data to TRE113, including communicating with a primary platform101within TRE113. Device102may preferably include an operating system102hto manage device drivers102gand hardware resources within device102. The operating systems described herein can also manage other resources such as memory and may support multiple software programs or software libraries operating on device102, including applications that communicate with PP101through a device driver102g.

The operating system102hcan include Internet protocol stacks such as a User Datagram Protocol (UDP) stack, Transmission Control Protocol (TCP) stack, a domain name system (DNS) stack, etc., and the operating system102hmay include timers and schedulers for managing the access of software to hardware resources, including TRE113. The operating system shown of102hcan be appropriate for a low-power device with limited memory and CPU resources (compared to a server103). Example operating systems102hfor a device102includes Linux, Android® from Google®, IoS from Apple®, Windows® Mobile, or Open AT® from Sierra Wireless®. Additional example operating systems102hfor device102include eCos, uC/OS, LiteOs, Contiki, OpenWRT, Raspbian, and other possibilities exist as well without departing from the scope of the present disclosure.

A device program102imay be an application programmed in a language such as, but not limited to, C, C++, Java, and/or Python, and could provide functionality to support M2M applications such as remote monitoring of sensors and remote activation of actuators. A device program102icould also comprise an application for a mobile phone, table, personal computer, or the like. Device program102icould also be a software routine, subroutine, linked library, or software device, according to one preferred embodiment. As contemplated herein, a device program102imay be an application operating within a smartphone, such as an iPhone® or Android®-based smartphone, and in this case device102could comprise the smartphone. The application functioning as a device program102icould be downloaded from an “app store” associated with the smartphone. Device program102ican include secure session library102y, which can provide the functionality or “System on a Chip” (SOC)109instructions for conducting secure session115.

SOC109can include a plurality of processing cores appropriate for typically low power consumption requirements for a device102(compared to a server103), and may also function as a microcontroller. The processing cores can include at least one processor core for device102such as an ARM® based processor or an Intel® based processor such as belonging to the Atom or MIPS family of processors, and other possibilities exist as well including exemplary ARM Cortex-M processors and cores. A single or set of processor or processing cores could operate as a processor for device102and a second processor could operate as a TRE113. Processing cores within SOC109can also comprise specialized processing cores, such as including hardware based cryptographic accelerators, field-programmable gate arrays (FPGAs), and other possibilities exist as well without departing from the scope of the present disclosure. For some embodiments, one core could be “split” or divided via time multiplexing such that during a first time period the processing core operates as a generic processor for device102, and during a second time period the processing core operates as a primary platform101. The embodiment from the previous sentence could comprise using an ARM “Trustzone” implementation for the TRE113and PP101for the system100and other systems herein.

Many of the logical steps for operation of device102can be performed in software and hardware by various combinations of sensor102f, actuator102z, physical interface102a, device driver102g, operating system102h, device program102i, and SOC109. Note that device102may also optionally include user interface102jwhich may include one or more devices for receiving inputs and/or one or more devices for conveying outputs. User interfaces are known in the art for devices102and could include a few LED lights or LCD display or OLED display, and thus user interfaces are not described in detail here. User interface102jcould comprise a touch screen if device102operates as a smartphone or mobile phone. As illustrated inFIG.1b, device102can optionally omit a user interface102j, since no user input may be required for many “Internet of Things” applications, although a user interface102jcould be included with device102.

Device102may be a computing device or wireless device that includes computer components for the purposes of collecting data from a sensor102for triggering an action by an actuator102y. Device102may include a central processing unit (CPU) within SOC109, a random access memory (RAM)102e, and a system bus102dthat couples various system components including the random access memory102eto the processing unit102b. The system bus102dmay be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures including a data bus.

Device102may include a read-only memory (ROM)102cwhich can contain a boot loader program. Although ROM102cis illustrated as “read-only memory”, ROM102ccould comprise long-term memory storage chipsets or physical units that are designed primarily for writing once and reading many times, such as Electrically Erasable Programmable Read-Only Memory (EEPROM). As contemplated within the present disclosure, a read-only address could comprise an address within a read only memory such as a ROM102cmemory address or another hardware address for read-only operations accessible via bus102d. Changing data recorded in a ROM102ccan require a technician have physical access to device102, such as removing a cover or part of an enclosure, where the technician can subsequently connect equipment to a circuit board in device102, including replacing ROM102c. ROM102ccould also comprise a nonvolatile memory, such that data is stored within ROM102ceven if no electrical power is provided to ROM102c.

Device102can include a SOC109. SOC109can include TRE113, and additional details for the operation of SOC109and TRE113is provided in other figures herein. Although TRE113is depicted inFIG.1bas operating within SOC109, TRE113could be operated within a removable unit such as an SD card, a SIM card, etc. Or TRE113could operate within a separate soldered chip connected to bus102d. An exemplary removable form factor for TRE113could comprise a standard SD card, a mini SD card, a micro SD card, a mini UICC, a micro UICC, or a nano UICC, and other possibilities exist as well without departing from the scope of the present disclosure. SOC109can include electrical contacts (such as external pads109adepicted inFIG.1c) which provide electrical connectivity to bus102d. SOC109can include NAND or NOR flash memory in order to record data when device102is not powered, and other nonvolatile memory technologies can be used in a storage unit as well without departing from the scope of the present disclosure.

The inclusion of TRE113and the operation of TRE113with PP101in SOC109can add functionality for SOC109that is not normally included in commercially available SOC in the market as of 2018, such as with the secure receipt of firmware106as described herein. TRE113within SOC109can include a processor, bus, and memory similar (but with less power and on a smaller scale) equivalent to bus102d, and ROM102c, NVM102s. TRE113can perform cryptographic functions using either boot firmware or downloaded firmware106such as (i) internally deriving a private key with a corresponding public key such as PKE1(in message117inFIG.1a) in a cryptographically secure manner, (ii) recording the private key in a protected memory such that device102or external parties cannot feasibly or cost-effectively read the derived private key, and (ii) conducting key exchanges and encryption/decryption such as key exchange101bfromFIG.1a.

Although the exemplary environment described herein employs ROM102c, RANI102e, and nonvolatile memory (NVM)102s, it should be appreciated by those skilled in the art that TRE113could also operate within other types of computer readable media which can store data that is accessible by a device102, such as memory cards, subscriber identity device (SIM) cards, local miniaturized hard disks, and the like, which may also be used in the exemplary operating environment without departing from the scope of the disclosure. The memory and associated hardware illustrated inFIG.1bprovide nonvolatile storage of computer-executable instructions, data structures, program devices, device program102i, device drivers102g, and other data for computer or device102. Note the device102may include a physical data connection at the physical interface102asuch as a miniaturized universal serial bus adapter, firewire, optical, or other another port and the computer executable instructions such as device program102i, operating system102h, or device driver102gcan be initially loaded into memory such as ROM102cor NVM102sthrough the physical interface102abefore device102is given to an end user, shipped by a manufacturer to a distribution channel, or installed by a technician.

Further, device program102i, operating system102h, or device driver102gcan be separately loaded into NVM102sbefore or after distribution of device102. In some exemplary embodiments, applications or programs operating within device102can be given limited or restricted access to TRE113in order to support the applications or programs. For example, a mobile payment application operating a device program102icould authenticate either device102or a user with keys recorded in TRE113and a firmware106. Device program102icould provide a graphical user interface (GUI) to a user through user interface101j. Other possibilities exist as well for a device program102ito operate in conjunction with keys and identities recorded in TRE113without departing from the scope of the present disclosure.

A number of program devices may be stored in RAM102e, ROM102c, or NVM102s, including an operating system102h, device driver102g, an http client (not shown), a DNS client, and related software. TRE113can record program devices as well, where the program devices in TRE113may be focused on cryptographic operations and functions conducted within TRE113in support of the operation of device102. A firmware106depicted and described in connection withFIG.1aand other figures herein can comprise a program device. Program devices include routines, sub-routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. Aspects of the present disclosure may be implemented in the form of (i) a device program102iwhich are executed by the device102working in conjunction with (ii) firmware106on TRE113and PP101to authenticate device102with a server using public key infrastructure. In exemplary embodiments, program devices for TRE113in SOC109can include cryptographic algorithms to operate with the cryptographic parameters specified by certificates recorded in the nodes of system100, such as with PKI keys101a.

A user may enter commands and information into device102through an optional user interface102j, such as a keypad, keyboard (possibly miniaturized for a mobile phone form-factor), and a pointing device. Pointing devices may include a trackball, an electronic pen, or a touch screen. A user interface102jmay also include a display (not shown) such as a device screen. A display may also be connected to system bus102dvia an interface. The display can comprise any type of display devices such as a liquid crystal display (LCD), a plasma display, and an organic light-emitting diode (OLED) display. Device102may also include a camera (not shown) connected to or integrated with device102through a physical interface102a, and the camera can comprise a video camera for the device102to collect sensor data that includes video or images. The camera (not shown) can be a CCD (charge-coupled device) camera, a CMOS (complementary metal-oxide-semiconductor) camera, or a similar device to collect video or camera input including QR codes. Other arrangements could be used as well, without departing from the disclosure.

The device102, comprising a computer, may operate in a networked environment using logical connections to one or more remote computers, such as servers. Servers communicating with device102can also function as a general purpose server to provide files, programs, disk storage, remote memory, and other resources to device102usually through a networked connection. Additional remote computers with which device102communicates may include another device102or mobile device, an M2M node within a capillary network, a personal computer, other servers, a client, a router, a network PC, a peer device, a wireless network, or other common network nodes. The servers or networks communicating with device102or a remote computer typically includes many of the elements and electrical components described above relative to the device102, including a CPU, memory, and physical interfaces. It will be appreciated that the network connections shown throughout the present disclosure are exemplary and other means of establishing a wireless or wired communications link may be used between mobile devices, computers, servers, corresponding nodes, and similar computers. The operation of a TRE113within device102with a firmware106can be utilized to authenticate a device102in each or any of the above described networking environments.

The device program102ioperating within device102illustrated inFIG.1band communicating with TRE113can provide computer executable instructions to hardware such as SOC109through a system bus102din order for a device102to (i) transmit and receive data with a service provider, (ii) monitor a sensor and/or change the state of an actuator102y, (iii) send or receive packets with a server or network, and (iv) authenticate with a server, thus allowing the server to remotely monitor or control device102in an authenticated and secure manner. The device program102ican enable the device102to authenticate and communicate with a server by recording data in memory such as RANI102e, where the data can include sensor data, a destination IP address number, a packet or packet header value, an encryption or ciphering algorithm and key, a digital signature and public key, etc, where cryptographic operations or calculations for the device program102ican be performed by TRE113using firmware106. The data recorded in RANI102ecan be subsequently read by the operating system102hor the device driver102g. The operating system102hor the device driver102gcan write the data to a physical interface102ausing a system bus102din order to use a physical interface102ato send data such as a digital signature for authentication to a server using the Internet114. In exemplary embodiments, the digital signature can be generated or processed in the TRE113using a PP101and firmware106. Alternatively, the device program102ican write the data directly to the physical interface102ausing the system bus102d.

In general, digital signatures for authentication with a server can be performed in TRE113, where the digital signature output is transferred from TRE113to RANI102eusing a device driver102gbefore being transmitted from device102to a server through the IP network114. The data recorded in RAM102esuch as a digital signature can be subsequently read by the operating system102hor the device driver102g. Note that device driver102gcan include OFL agent102xin order to communicate with TRE113. Thus, OFL agent102xcan be a device driver102gspecifically for TRE113. The operating system102hor the device driver102gcan write the data to a physical interface102ausing a system bus102din order to use a physical interface102ato send data such as a digital signature for authentication to a server using the Internet114. Alternatively, the device program102ican write the data directly to the physical interface102ausing the system bus102d. Other possibilities exist as well without departing from the scope of the present disclosure.

The device program102ior operating system102husing TRE113and PP101with firmware106can include steps to process the data recorded in memory such as encrypting data, selecting a destination address, or encoding sensor data acquired by (i) a sensor102for (ii) through a physical interface102asuch as a thermocouple, shock or vibration sensor, light sensor, or global positioning system (GPS) receiver, etc. The device102can use the physical interface102asuch as a radio to transmit or send (i) the data from a sensor or (ii) a digital signature from TRE113to a wireless network. For those skilled in the art, other steps are possible as well for a device program102ior operating system102hto collect data from either (i) a sensor102for (ii) a TRE113and send the data in a packet without departing from the scope of the present disclosure.

Conversely, in order for device102to receive a packet or response from server, which could include a challenge or nonce in order to authenticate a device102with the server, the physical interface102acan use a radio to receive the challenge or nonce from a wireless network. The challenge or nonce received from the server through the wireless network could comprise a random number or a pseudo random string of digits, bits, and/or characters. The received data can include information from a server and may also comprise a datagram, a source IP address number, a packet or header value, an instruction for device102, an acknowledgement to a packet that device102sent, a digital signature, and/or encrypted data. The operating system102hor device driver102gcan use a system bus102dand SOC109to record the received data such as a challenge or nonce from a server in memory such as RANI102e, and the device program102ior operating system102hmay access the memory in order to process the received data and determine the next step for the device102after receiving the data.

Processing the received data from a server to device102could include deciphering or decrypting received data by TRE113with a key recorded in TRE113, sending the challenge or nonce to the TRE113, reading an instruction from a server, or similar transformations of the received data. The steps within the paragraph above may also describe the steps a device program102ican perform in order to receive a packet. For those skilled in the art, other steps are possible as well for a device program102ior device102to receive a packet or challenge or nonce from a server without departing from the scope of the present disclosure. A server described herein without the designation of “server103” or IDS103can comprise a different server than server103communicating with device102in support of an application operating as a device program102i(e.g. a server supporting mobile payments, TRE113operating an embedded SIM, TRE113authenticating device102with a wireless network, etc.)

Moreover, those skilled in the art will appreciate that the present disclosure may be implemented in other computer system configurations, including hand-held devices, netbooks, portable computers, multiprocessor systems, microprocessor based or programmable consumer electronics, network personal computers, minicomputers, mainframe computers, servers, and the like. The disclosure may also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program devices may be located in both local and remote memory storage devices. In addition, the terms “mobile node”, “mobile station”, “mobile device”, “M2M device”, “M2M device”, “networked sensor”, or “industrial controller” can be used to refer to device102as contemplated herein.

Although not depicted inFIG.1b, a server shown above inFIG.1asuch as IDS server103and other servers as well can include equivalent internal components as device102in order to operate. The server103inFIG.1acould include a processor similar to SOC109, with primary differences for the processor server being increased speed, increased memory cache, an increased number and size of registers, the use of a 64 bits for datapath widths, integer sizes, and memory address widths, as opposed to an exemplary 32 bits for processor cores in SOC109or an exemplary 32 or 16 bits for a processor in TRE113. Other possibilities exist as well for the size of datapath widths for a TRE113and processing core in device102without departing from the scope of the present disclosure. Similarly, RAM in a server could be a RANI similar to RAM102ein device102, except the RANI in a server could have more memory cells such as supporting exemplary values greater than an exemplary 16 gigabytes, while RAM in device102could support fewer memory cells such as less than an exemplary 8 gigabytes. Non-volatile memory for storage in a server103inFIG.1acould comprise disks, “solid state drives” (SSDs) or “storage area networks” (SAN) for a server. For a physical interface102a, in exemplary embodiments, a server103inFIG.1acould use a physical, wired LAN interface such as a high-speed Ethernet or fiber optic connection.

In exemplary embodiments, a device102can include the functional capabilities of (i) collecting sensor data, (ii) changing state of an actuator102z, (iii) communicating the data associated with a sensor or actuator with a wireless network, and/or receiving a challenge or nonce from a server and sending a digital signature. The device driver102g, operating system102i, and/or device program102icould optionally be combined into an integrated system for providing the device102functionality. Other possibilities exist as well for the configuration or combination of components illustrated inFIG.1bwithout departing from the scope of the present disclosure.

FIG.1cis a graphical illustration of a primary platform, in accordance with exemplary embodiments. A primary platform101can include a set of PKI keys101aand a load function119. Other data and structures can be included in a PP101operating within a TRE113without departing from the scope of the present disclosure. Note that a TRE113operating a PP101, such as the TRE113depicted inFIG.1aandFIG.1bcan include electrical components similar to those depicted for a device101inFIG.1b, such as including memory, a processor, and an internal data bus. PP101can operate on the electrical components within TRE113, and the exemplary set of PKI keys101acan be recorded in nonvolatile memory or read only memory of TRE113. The set of PKI keys101afor PP101can include certificates of (i) CERT.IDS1.ECKA103c, (ii) CERT.PN.ECDSA101a-2, (iii) CERT.CI.ECDSA101a-3, (iv) CERT.CI-OCSP.ECDSA101a-4, (v) CERT.TSA101a-5, (vi) CERT.OFL.ECDSA101a-6, a secret key SK.OFL.ECDSA101a-7corresponding to the public key for a certificate of TRE113by server103or OFL authority107, and a public key for a TRE manufacturer of PK.TREM.ECDSA101a-8. Other keys and certificates can be recorded in a set of PKI keys101afor a PP101without departing from the scope of the present disclosure. The set of PKI keys101acan be use with cryptographic algorithms for both key exchange101band load function119. Note that PP101and TRE113record the data for PKI keys101ain a secure manner, such that device102cannot read or write data to PKI keys101awithout specific permission (such as device102passing TRE113certificate103cfrom a message116).

The certificates in a set of PKI keys101awithout leading numeral designations inFIG.1ccan also comprise the certificates for a primary platform as specified in the GP OFL document. The use of these PKI keys without leading numeral designations is also described in section 4.1.2.4 of the load function of the GP OFL document. The certificates in a set of PKI keys101adepicted inFIG.1cwith numeral designations of “for 119” can comprise certificates used by a PP101that are not specified or contemplated by the GP OFL document. Some certificates in PKI keys101acould be recorded during manufacturing of TRE113, such as CERT.PN.ECDSA101a-2and

CERT.CI.ECDSA101a-3. Other keys in PP101could be subsequently received after distribution of device102with TRE113to end users, such as CERT.IDS1.ECKA103c(which could be received via a message116).

CERT.CI-OCSP.ECDSA101a-4in PKI keys101acan comprise a certificate for PP101used to validate signed time value T2104ein a step119a, where an exemplary signed time value T2104eis depicted inFIG.2abelow. CERT.CI-OCSP.ECDSA101a-4could be stored or recorded in PKI keys101aafter (i) PP101receives data from message116via device102and (ii) PP verifies CERT.CI-OCSP.ECDSA101a-4using CERT.CI.ECDSA101a-3(where CI104signs CERT.CI-OCSP.ECDSA10101a-4using SK.CI.ECDSA104a). Or, in other embodiments CERT.CI.ECDSA101a-3could be written along with CERT.CI-OCSP.ECDSA101a-4to nonvolatile memory of PP101during manufacturing of TRE113.

Note that CI104can use the private key SK.CI-OCSP.ECDSA104corresponding to the public key in CERT.CI-OCSP.ECDSA101a-4in order to create signed time value T2104e. In exemplary embodiments, (i) CI104uses a different private key than SK.CI.ECDSA104ato sign time value T2104e(since a server or computer with SK.CI.ECDSA104amay be offline and more secured), and consequently (ii) PP101uses a public key different from the key in CERT.CI.ECDSA101a-3in order to verify signed time value T2104esuch as the signature inFIG.2a, and the different public key can comprise the public key in CERT.CI-OCSP.ECDSA101a-4. However, PP101could use CERT.CI.ECDSA101a-3to verify or validate CERT.CI-OCSP.ECDSA101a-4(if received in message116), and thus CERT.CI.ECDSA101a-3can be used indirectly to verify signed time value T2104e.

CERT.TSA101a-5in PKI keys101acan comprise a certificate for PP101used to validate signed timestamp T3108b, where the use of CERT.TSA101a-5by PP101is depicted and described in connection withFIG.2bbelow. Timestamp Authority108can use a private key of SK.TSA108a, corresponding to the public key in CERT.TSA101a-5, in order to create the digital signature108bfor timestamp T3108b-1. For some exemplary embodiments, the use of a separate certificate CERT.TSA101a-5to validate a digital signature108bfor timestamp T3108b-1could be omitted, and timestamp T3108b-1could be included in data which is signed by a private key corresponding to a different certificate stored by PP101in PKI keys101a. As one example, timestamp T3108b-1could be included in data signed by server103, and PP101could rely upon a public key from a verified certificate from server103such as a CERT.IDS2.ECDSA103din order to validate a digital signature108bfor timestamp T3108b-1. For embodiments where PP101uses a CERT.IDS2.ECDSA103din order to validate a digital signature108bfor timestamp T3108b-1, the received CERT.IDS2.ECDSA103dcan include a signed time value T2104e-1and PP101can verify the signed time value T2104e-1using CERT.CI-OCSP.ECDSA101a-4and/or CERT.CI.ECDSA101a-3.

However, for other embodiments, such as those depicted for a load function119inFIG.1c, the use of a separate certificate of CERT.TSA101a-5for verifying a digital signature108bfor timestamp T3108b-1can be preferred, since relying upon a different certificate (e.g. such as CERT.CI-OCSP.ECDSA101a-4and/or CERT.CI.ECDSA101a-3) can mean essentially that the timestamp T3108b-1is “self signed”, In other words, without (X) a separately signed timestamp T3108b-1which is verified by a separate CERT.TSA101a-5, then (Y) PP101may not be able to securely rely upon timestamp T3108b-1in order to use signed time value T2104e-1to verify that a certificate CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dhas not been revoked.

For example with embodiments alternative to those depicted for a load function119inFIG.1c, if timestamp T3108bis within signed data verified by PP101using a certificate such as CERT.IDS2.ECDSA103d, then PP101cannot securely or reliably use a time value T2104e-1associated with certificate CERT.IDS2.ECDSA103d, because that means the signature for timestamp T3108b-1is essentially “self signed”. If the certificate for CERT.IDS2.ECDSA103dhas been revoked and the private key associated with CERT.IDS2.ECDSA103dhas been compromised, then (i) the compromised private key associated with CERT.IDS2.ECDSA103dcould be used to sign timestamp T3108b-1with an earlier date before revocation of CERT.IDS2.ECDSA103d, and (ii) an earlier signed timestamp T3108b-1from before revocation of CERT.IDS2.ECDSA103dcould be sent in a message118fromFIG.1a. Consequently, PP101could incorrectly determine that CERT.IDS2.ECDSA103dis valid, when it could have been revoked. Thus, in exemplary embodiments PP101can use a recorded CERT.TSA101a-5from a set of PKI keys101ain order to validate a signature108bfor timestamp T3108b-1.

A primary platform101can include a load function119. The load function119depicted inFIG.1ccan comprise the load function119fromFIG.1awith exemplary additional details for conducting signature or certificate verification, ECDH key exchange to derive symmetric ciphering keys, and also decryption with an integrity check. The steps in a load function119without leading numeral designations inFIG.1ccan also comprise the steps for a primary platform to perform to process a message118such as the steps specified in the GP OFL document. The use of these steps without leading numeral designations is also described in section 4.1.2.4 of the load function of the GP OFL document.

The steps depicted inFIG.1cwith numeral designations of a leading “119” can comprise steps of the present disclosure that are not specified or contemplated by the GP OLF document in order to securely load firmware106while also allowing a PP101to determine if a certificate has been revoked. Again, note that there is no description of certificate revocation or the use of the term “revocation” or “revoked” or like descriptions for invalidating a certificate in the GP OLF document. However, support for revocation of a certificate can be essential in order to maintain the security of a system100fromFIG.1a. Further, conventional technology for determining if a certificate has been revoked does not support revocation for firmware load with a primary platform, since the primary platform normally does not have the ability to independently keep date and time, especially when power is removed from PP101. Subsequent descriptions for a load function119will focus on the additional steps not contemplated or described by the GP OLF document. Steps for a load function without leading numeral designations can be found within the GP OFL document.

A step119afor a load function119in exemplary embodiments can comprise the depicted step of “VERIFY(CERT101a-4) [Signed T2104e]”. PP101can use the certificate CERT.CI-OCSP.ECDSA101a-4from PP keys101ain order to verify the signed time value T2104e-1. The signed time value T2104e-1can comprise an interim time value before the expiration time T1104cwhere CI104confirms that a certificate such as CERT.CI.ECDSA101a-3remains valid. In exemplary embodiments, the signed time value T2104ecan comprise a digital signature over a time value T2104e-1, and the time value T2104e-1can comprise the plaintext time value for an end date/time of validity for an OSCP stapling, as depicted and described in connection withFIG.2a.

The signed time value T2104e-1can be included as the end of an interim time window for certificate validity such as for the signed time value T2104e-1depicted inFIG.2abelow. The signed time value T2104e-1could be included in an OCSP response110value that is “stapled” or included with a certificate such as CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dwhich are received by PP101via messages116and118, respectively. Consequently, although a message118inFIG.1adepicts a message118including a digital signature104efor time value T2104e-1, the message118can also include the time value T2104e-1. Conducting an exemplary signature verification step is depicted inFIG.2bbelow for a different signature using a different key, but the same logic and sequence of steps can be used in a step119afor PP101to verify the signed time value T2104e. Although not depicted inFIG.1c, for embodiment where PP101received CERT.CI-OCSP.ECDSA101a-4via device102from a message116, PP101could also verify CERT.CI-OCSP.ECDSA101a-4using CERT.CI.ECDSA101a-3before using CERT.CI-OCSP.ECDSA101a-4in a step119a.

As depicted inFIG.1c, upon conclusion of a step119a, PP101can securely read and store the plaintext time value T2104e-1(e.g. the time value T2separate or without a signature). Note that although a single instance of step119ais depicted for a load function119inFIG.1c, a PP101could conduct a step119afor each certificate received, such as, but not limited to CERT.IDS1.ECKA103cand CERT.IDS2.ECDSA103d. Consequently, after a step119c, PP101can store and operate with more than one time value T2104e-1, and subsequently use each of the time values T2104e-1with a subsequent step119c. For the case where the signature verification fails in a step119a, then PP101could abort the load firmware function119and report an error condition.

A step119bfor a load function119in exemplary embodiments can comprise the depicted step of “Verify(CERT101a-5) [Signed T3108b]”. PP101can use the certificate CERT.TSA101a-5from PP keys101ain order to verify the digital signature108bfor timestamp T3108b-1. As contemplated herein, a “time value” and a timestamp can be considered equivalent. The digital signature108bfor a timestamp T3108b-1can comprise a timestamp of recent time from a TSA108associated with the time for which data in message118is processed by server103. Although not depicted inFIG.1cfor a step119b, a step119bcan comprise PP101verifying a digital signature over both the signed time value T3108b-1and the transaction ID117x.

Since PP101or TRE113may not reliably internally track date and time, the digital signature108bfor a timestamp T3108b-1can represent the time PP101should use for checking the validity or interim validity of certificates and other time windows. The inclusion of transaction ID117xwithin a digital signature108bfor timestamp T3108b-1can be useful for PP101to verify that the digital signature108bover at least T3108b-1was generated after the PP101sends a message117with the transaction ID117x. Upon conclusion of a step119b, PP101can securely read and store the plaintext time value T3108b-1(e.g. the timestamp T3separate or without a signature). As discussed above regarding the use of a CERT.TSA101a-5, an independent certificate from server103can be used to verify the signed timestamp108bfor preferred embodiments. Although not depicted inFIG.1a, the date/time value for the digital signature108bof timestamp T3108b-1can be sent along with a message118. For other embodiments, a different recorded certificate for PP101in PKI keys101a, such as a PK.IMO.ECDSA (not depicted inFIG.1c, but included in a primary platform in the GP OFL document) could be used to verify digital signature108bfor timestamp T3108b-1(assuming the secret key for PK.IMO.ECDSA was used to generate the digital signature108bfor timestamp T3108b-1. In general, a certificate used to verify a signed timestamp108bcan be from a different entity than server103, such as from an image owner105, an OFL authority107, or a TRE manufacturer.

A step119cfor a load function119can comprise PP101comparing the plaintext, verified time value T3108b-1with each of the time values T2104e-1. As depicted inFIG.1c, the time value T3108b-1should be less than each time value T2104e-1. Although only a signed time value T2104e-1for CERT.IDS2.ECDSA is depicted inFIG.1c, a PP101could also use the verified time value T3108b-1to verify a different, previous signed time value T2104e-1for CERT.IDS1.ECKA103cfrom a message116in a load function119. In other words, the timestamp T3from data in message118and associated with received firmware106should be before each time value T2104e-1. For a step119c, if PP101determines that any time value T2104e-1is before timestamp T3108b-1, then PP101cannot confirm that a certificate associated with the time value T2104e-1remains valid and has not been revoked. If PP101determines that any time value T2104e-1is before timestamp T3108b-1, then PP101can abort the load119function and report the error condition. Or, PP101could respond with an error code and wait for an updated, valid certificate with an updated signed time value T2104e-1before completing the load function119and begin operating with the firmware106, such as establishing a firmware session.

After step119cthen PP101can conduct a step119dand proceed with loading firmware106and create a firmware session to begin operating with the firmware106. The conclusion of a step119dfor PP101can comprise the exemplary state of loaded firmware in state3of loaded firmware in FIG. 2-5 of section 2.4 “Loading Procedure” of the GP OLF document. Other examples exist as well for (i) loading firmware106after a step119cto compare time values and (ii) establishing a firmware session in a PP101using firmware106from a message118without departing from the scope of the present disclosure.

FIG.2ais a simplified response from a certificate authority to verify certificate validity, in accordance with exemplary embodiments. Although a certificate normally has an ultimate expiration time, nodes in a system100can need the ability to check that a certificate has not been revoked. As mentioned above, a primary platform recording and using a plurality of different certificates may record and use certificates with long time frames such as several years into the future. For a system100potentially hundreds of servers103distributed globally and also connected to a public Internet114, there is a reasonable chance that some certificates for some servers103may need to be revoked before the long expiration time of certificates recorded by a PP101in a TRE113. The use of a protocol such as OCSP and an exemplary response110depicted inFIG.2acan support a PP101determining if a certificate has been revoked.

As depicted and described in connection withFIG.1a, a server103could operate a client for requesting a signed, updated status for a certificate. The client could comprise an OCSP client and server103could send the request109fromFIG.1ain order for CI104to generate the exemplary response110depicted inFIG.2a. CI104could operate an OCSP responder104dfromFIG.1ain order to process the request109and generate the response110. The exemplary data depicted for a response110is shown using ECDSA algorithms with an SHA-256 hash algorithm, but other algorithms could be utilized as well.

A response110inFIG.2acan include the query109, such that an entity receiving the response110can determine the query109used to generate the response. As shown, the query could include hash values over the certificate issuer data and a serial number associated with the certificate being checked, such as a serial number for CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103d. The format and logic and algorithms used to create the exemplary data in query109within response110can be compatible with IETF RFC 6960 and future, related standards, although other, similar techniques could be used as well to generate an interim confirmation by a certificate issuer that a certificate has not been revoked.

The response data in a response110include the certificate issuer information and the certificate serial number, as well as a signed time value T2104e, which can comprise a digital signature104e. The plaintext time value T2104e-1can be read separately from response110, although digital signature104ecan be over plaintext time value T2104e-1. In exemplary embodiments, time value T2104e-1can comprise the value of “Next Update” or a time into the future (at the time of CI104creating signature104e) through which a certificate can be considered valid. Further, the status of the certificate can be “good” or “OK” or the equivalent. The response110for a certificate such as CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dcan be appended to the CERT.IDS1.ECKA103cor CERT.IDS2.ECDSA103dfor delivery by server103to device102and PP101. In other words, (i) the message116with a CERT.IDS1.ECKA103ccan include a first response110with a first time value T2104e-1and first digital signature104eand (ii) the message118with a CERT.IDS2.ECDSA103dcan include a second response110with a second time value T2104e-1and a second digital signature104e. After verifying the signed time value T2104e, as well as any intermediate certificate associated with the signed time value T2104e, such as CERT.CI-OCSP.ECDSA101a-4, PP101can use plaintext time value T2104e-1to compare with verified timestamp T3108bto determine if the status in response110(e.g. “good”) is at the time of timestamp T3108b. In other words, PP101can trust or rely upon the status of a certificate if timestamp T3108bbefore the time value T2104e-1.

FIG.2bis a flow chart illustrating exemplary steps for verifying a digital signature using PKI keys, parameters, and data input, in accordance with exemplary embodiments. The processes and operations, described below with respect to all of the logic flow diagrams and flow charts may include the manipulation of signals by a processor and the maintenance of these signals within data structures resident in one or more memory storage devices. For the purposes of this discussion, a process can be generally conceived to be a sequence of computer-executed steps leading to a desired result.

These steps usually require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, or otherwise manipulated. It is convention for those skilled in the art to refer to representations of these signals as bits, bytes, words, information, elements, symbols, characters, numbers, points, data, entries, objects, images, files, or the like. It should be kept in mind, however, that these and similar terms are associated with appropriate physical quantities for computer operations, and that these terms are merely conventional labels applied to physical quantities that exist within and during operation of the computer.

It should also be understood that manipulations within the computer are often referred to in terms such as listing, creating, adding, calculating, comparing, moving, receiving, determining, configuring, identifying, populating, loading, performing, executing, storing etc. that are often associated with manual operations performed by a human operator. The operations described herein can be machine operations performed in conjunction with various input provided by a human operator or user that interacts with the device, wherein one function of the device can be a computer.

In addition, it should be understood that the programs, processes, methods, etc. described herein are not related or limited to any particular computer or apparatus. Rather, various types of general purpose machines may be used with the following process in accordance with the teachings described herein.

The present disclosure may comprise a computer program or hardware or a combination thereof which embodies the functions described herein and illustrated in the appended flow charts. However, it should be apparent that there could be many different ways of implementing the disclosure in computer programming or hardware design, and the disclosure should not be construed as limited to any one set of computer program instructions.

Further, a skilled programmer would be able to write such a computer program or identify the appropriate hardware circuits to implement the disclosed disclosure without difficulty based on the flow charts and associated description in the application text, for example. Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the disclosure. The inventive functionality of the claimed computer implemented processes will be explained in more detail in the following description in conjunction with the remaining Figures illustrating other process flows.

Further, certain steps in the processes or process flow described in all of the logic flow diagrams below must naturally precede others for the present disclosure to function as described. However, the present disclosure is not limited to the order of the steps described if such order or sequence does not alter the functionality of the present disclosure. That is, it is recognized that some steps may be performed before, after, or in parallel other steps without departing from the scope and spirit of the present disclosure.

The processes, operations, and steps performed by the hardware and software described in this document usually include the manipulation of signals by a CPU or remote server and the maintenance of these signals within data structures resident in one or more of the local or remote memory storage devices. Such data structures impose a physical organization upon the collection of data stored within a memory storage device and represent specific electrical or magnetic elements. These symbolic representations are the means used by those skilled in the art of computer programming and computer construction to most effectively convey teachings and discoveries to others skilled in the art.

A step119a, and related steps for verifying a digital signature in the present disclosure, can use an ECC based elliptic curve digital signature algorithm (ECDSA) algorithm, and other possibilities exist as well without departing from the scope of the present disclosure. PP101can use a signature verification in step119ain order to validate a signature for a received timestamp108b. When using ECDSA algorithm in non-deterministic mode for a signature creation, a value of “k” or “r”, which could comprise a random number that can be included with the digital signature108b. When using a DSA or ECDSA in deterministic mode, such as specified in IETF RFC 6979 and titled “Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)”, which are hereby incorporated by reference, then the requirement for a separately transmitted random number with a digital signature such as signed timestamp108b(such including as value “k” or “r”) can be optionally omitted, such that “r” can be deterministically calculated based on the message to sign.

In exemplary embodiments, server103and other servers inFIG.1acan utilize deterministic ECDSA without also sending a random number along with a digital signature, although the value “r” from the deterministic mode could be sent with the digital signature such as signed timestamp108b. In other words, a value can be sent with the digital signature such as signed timestamp T3108bthat is deterministically derived and associated with the message to sign. In other exemplary embodiments, a random number can be generated as a derived value for the random number such as “r” sent with a digital signature such as signed timestamp T3108b.

For a signature verification step119b, the exemplary message to verify comprises the plaintext timestamp value T3108b-1, which can be decrypted by PP101using a load function119. Although a load function119inFIG.1cabove depicts the timestamp value T3108b-1as decrypted from a message M4, for some embodiments the timestamp value T3108b-1could be sent as plaintext in a message118. In other words, the timestamp value T3108b-1does not need to be encrypted using an encrypted message M4since a digital signature108bfor the timestamp value T3108b-1can separately be included with a message118as depicted inFIG.1a.

The message to verify values can be transmitted to PP101, such as shown for timestamp T3108b-1and the digital signature108bfor timestamp T3. Note that in some exemplary embodiments for a step119b, the message to verify can include both the timestamp T3108b-1and the transaction ID117x, where PP101generates the transaction ID117xfor creation of the message117as depicted and described in connection withFIG.1a. The message to verify values can be input into a message digest algorithm230, which could comprise a standard algorithm such as SHA-256, SHA-3, or similar algorithms. The output of message digest algorithm230can be input along with parameters and a public key from a certificate such as CERT.TSA101a-5into signature verification algorithm228. Parameters can specify encoding rules, padding, key lengths, selected algorithms, curve names, and other values or fields necessary to utilize a signature algorithm228. Parameters can be specified in the certificate. Both a signature creation step and a signature verification step use the same or equivalent values for parameters. Private key SK.TSA108acan comprise the private key used to create the digital signature108bfor at least the timestamp T3108b-1. Although not depicted inFIG.2b, a random number for values such as “k” and “r” for ECDSA and related signatures could be input as well into a signature algorithm228.

A signature algorithm228for a step119bcan also use input of the received digital signature108bfor timestamp108b-1, which can be received from a message118. The calculation of a digital signature108busing the public key from a certificate such as CERT.TSA105a-1can be compared with the received, digital signature108b. If the two values for the calculated version of the digital signature108band the received version of the digital signature108b(from message118) match or are equal, then the received, signed timestamp T3108b-1can be considered valid and the plaintext timestamp value of T3108b-1can be used with a comparison step119cand T2104e-1. If the two values for the calculated version of the digital signature108band the received version of the digital signature108b(from message118) do not match or are not equal, then the received, signed timestamp T3108b-1can be considered invalid and subsequently not used. PP101can respond with an error code or status to request a new, different signed timestamp T3108b-1and stop the firmware load function119.

Conclusion

Various exemplary embodiments have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to those examples without departing from the scope of the claims.