Trusted platform module certification and attestation utilizing an anonymous key system

This application is directed to trusted platform module certification and attestation utilizing an anonymous key system. In general, TPM certification and TPM attestation may be supported in a device utilizing integrated TPM through the use of anonymous key system (AKS) certification. An example device may comprise at least combined AKS and TPM resources that load AKS and TPM firmware (FW) into a runtime environment that may further include at least an operating system (OS) encryption module, an AKS service module and a TPM Certification and Attestation (CA) module. For TPM certification, the CA module may interact with the other modules in the runtime environment to generate a TPM certificate, signed by an AKS certificate, that may be transmitted to a certification platform for validation. For TPM attestation, the CA module may cause TPM credentials to be provided to the attestation platform for validation along with the TPM and/or AKS certificates.

TECHNICAL FIELD

The present disclosure relates to system security, and more particularly, to a system that supports trusted platform module certification and attestation using an anonymous key system.

BACKGROUND

Safeguarding electronic information has become an important issue based on the growing variety of transactions that may now be conducted electronically. Various threats including, for example, hackers, malicious software (e.g., malware) such as viruses, rootkits, etc. may share at least one purpose: to circumvent existing protection measures to gain access to, or control over, another users' device. Users employing a device to perform daily transactions may be unaware that their device has been compromised, and may be unknowingly providing sensitive personal, financial and/or proprietary data to a third party. Technology is continually being developed to combat these types of attacks. However, as new virus protections strategies emerge, hackers are finding ways to attack at lower levels within a device, gaining access and/or control at a level in the device having higher priority that the protection software. As a result, device manufacturers are building security measures into the actual hardware of a device. For example, these security features may be enabled an early stage of device initialization, and may ensure that programs loaded later are safe by performing a security check as the programs are loaded into the device.

At least one example of a hardware-based security system is Trusted Platform Module (TPM). TPM is an international standard for a secure cryptoprocessor, which may be a discrete microprocessor dedicated to securing hardware by integrating cryptographic keys into a device. TPM's technical specification is maintained by a computer industry consortium called Trusted Computing Group (TCG). Consistent with the 2.0 version of the TPM standard, a manufacturer-provisioned endorsement key (EK) and EK certificate are required for attestation identification key (AIK) generation. Discrete TPM solutions typically comprise on-chip storage that may be able to accommodate the EK and EK certificate. However, new integrated solutions are being contemplated that do not have space available for the EK and EK certificate. Consistent with this requirement, devices using integrated TPM may require a serial peripheral interface (SPI) Flash specifically for the EK and EK certificate, which may need to be provisioned to the SPI Flash following assembly by the original equipment manufacturer (OEM). This change to the manufacturing process may result in substantial cost increases for devices using integrated TPM.

DETAILED DESCRIPTION

The present disclosure is directed to trusted platform module certification and attestation utilizing an anonymous key system. In general, TPM certification and TPM attestation may be supported in a device utilizing integrated TPM through the use of anonymous key system (AKS) certification. A device may comprise, for example, at least combined AKS and TPM resources that load AKS and TPM firmware (FW) into a runtime environment in the device. The runtime environment may further include at least an operating system (OS) encryption module, an AKS service module and a TPM Certification and Attestation (CA) module. The CA module may be to interact with certification and attestation platforms located outside of the device (e.g., in a remote resources accessible via a network). For TPM certification, the CA module may interact with the other modules in the runtime environment to generate a TPM certificate, signed by an AKS certificate, that may be transmitted to the certification platform for validation. For TPM attestation, the CA module may cause TPM credentials to be provided to the attestation platform for validation, which may be provided along with the TPM certificate and/or the AKS certificate.

In at least one embodiment, a device supporting TPM certification and attestation using an AKS may comprise a communication module, combined AKS and integrated TPM resources, and a runtime environment. The communication module may be to communicate with at least a remote resource. The combined AKS and integrated TPM resources may be to load an AKS and TPM firmware module into the runtime environment. The runtime environment may further include at least an operating system encryption module, an AKS service module and an interface module to interact with at least a certification platform in the remote resource via the communication module.

In at least one embodiment, the interface module may further be to cause an AKS certificate to be requested by the service module from the firmware module; and interact with the encryption module to generate a TPM key handle and to initiate finalization of a TPM certificate based on at least one the TPM key handle and the AKS certificate. The anonymous key system and trusted platform module firmware module may comprise an anonymous key system firmware module loaded into a first trusted execution environment and a separate trusted platform module firmware module loaded into a second trusted execution environment. The encryption module may further be to interact with the firmware module to generate the TPM certificate based on at least the TPM key handle and to sign the trusted platform module certificate using the AKS certificate and to provide the signed TPM certificate to the interface module. The interface module may further be to cause the communication module to transmit the signed TPM certificate to the certification platform, and to receive a message from the certification platform via the communication module, the message at least indicating that signed TPM certificate is valid.

In the same or a different embodiment, the interface module may further be to receive a request for TPM credentials from an attestation platform in the remote resource via the communication module, and to cause the encryption module to obtain at least the TPM credentials and the TPM certificate from the firmware module. The interface module may further be to cause the communication module to transmit a response to the request, the response including at least the TPM credentials for validation by the attestation platform, and to receive a message from the attestation platform via the communication module, the message at least indicating at least that the TPM credentials have been validated. In at least one embodiment, the response to the request may further comprise the AKS certificate or the TPM certificate for the attestation platform to use in validating the TPM credentials. In an alternative embodiment, the response to the request may further comprise the AKS certificate for the attestation platform to use in validating the TPM certificate and the TPM certificate for the attestation platform to use in validating the TPM credentials. Consistent with the present disclosure, an example method for TPM certification and attestation using an anonymous key system may comprise loading a combined AKS and TPM firmware module into a runtime environment in a device, the runtime environment further including at least an operating system encryption module, an AKS service module, an interface module to interact with at least a certification platform in a remote resource, and triggering at least one of TPM certification or TPM attestation in the device.

FIG. 1illustrates an example system for TPM certification and attestation utilizing an anonymous key system in accordance with at least one embodiment of the present disclosure. System100may comprise, for example, at least device102and remote resource104. Examples of user device102may comprise, but are not limited to, a mobile communication device such as a cellular handset or smartphone based on the Android® OS from the Google Corporation, iOS® and/or Mac® OS from the Apple Corporation, Windows® OS from the Microsoft Corporation, Tizen® OS from the Linux Foundation, Firefox® OS from the Mozilla Project, Blackberry® OS from the Blackberry Corporation, Palm® OS from the Hewlett-Packard Corporation, Symbian® OS from the Symbian Foundation, etc., a mobile computing device such as a tablet computer like an iPad® from the Apple Corporation, Nexus® from the Google Corporation, Surface® from the Microsoft Corporation, Galaxy Tab® from the Samsung Corporation, Kindle Fire® from the Amazon Corporation, etc., an Ultrabook® including a low-power chipset manufactured by Intel Corporation, a netbook, a notebook, a laptop, a palmtop, etc., a typically stationary computing device such as a desktop computer, a smart television, small form factor computing solutions (e.g., for space-limited applications, TV set-top boxes, etc.) like the Next Unit of Computing (NUC) platform from the Intel Corporation, etc. Remote resource104may comprise at least one computing device accessible to user device102via a network connection. Example networks may include, but are not limited to, a local-area network (LAN), a wide-area network (WAN) like the Internet, a global-area network (GAN), etc. In at least one embodiment, remote resource104may comprise at least one data server operating as part of a cloud computing architecture. A cloud computing architecture may comprise, for example, a plurality of data servers operating individually or in unison to provide various data processing-related services to user device102.

Device102may comprise, for example, at least AKS and integrated TPM resources106, and runtime environment (RE)108. AKS and integrated TPM resources106may comprise both a memory (e.g., including at least an AKS certificate) and cryptographic processing hardware for supporting both AKS and integrated TPM. In general, AKS may be a digital signature scheme capable of generating digital signatures for authenticating data sources while keeping the identity of the source anonymous. Enhanced Privacy ID (EPID) technology from the Intel Corporation is an example of an AKS. For example, in EPID an Intel Key Generation Facility (IKGF) may issue a group certificate comprising a common public key along with private keys corresponding to the public key. After several million private keys corresponding to the same public key have been generated, a new group may be created. An EPID private key may be used to “sign” data, the private key signature being verifiable using the EPID pubic key. The private key may be provisioned to a device (e.g., inside of AKS and integrated TPM resources106in device102) at the time of manufacturing. Given that there are a number of private keys that match the same public key, the signature verifier has no direct knowledge of which device102signed the information. This is a key privacy requirement satisfied by an AKS like EPID. It is important to note that while EPID is an example of an AKS, that embodiments consistent with the present disclosure are not limited to implementation using EPID, and may be implemented based on another AKS existing now or in the future. TPM is a standard cryptographic system that may be employed to generate certificates, keys, etc. for use in security-related operations. For example TPM may generate a nearly unforgeable hash-based key (e.g., TPM credentials) that may summarize the current hardware and software configuration of device102. The TPM credentials may be validated by a third party such as, for example, attestation platform (AP)120to verify that the configuration of device102has not changed since it was first TPM certified, which may attest to device102still being a “trusted” platform (e.g., not compromised by a hacker, malware, etc.). Again, while TPM is referenced in the present disclosure, TPM is merely an example of a device integrity platform in use today, and is not meant to limit any of the various systems and/or methodologies disclosed herein to being employed exclusively with TPM. The various disclosed embodiments may be equally applicable to other trust architectures existing now or in the future.

RE108may comprise equipment and/or software in device102to support operational modules including, for example, AKS and TPM FW module110(hereafter, “FW module110”), OS encryption module112(hereafter, “encryption module112”), AKS service module114(hereafter “service module114”) and CA module116. Examples of equipment that may make up RE108will be discussed with respect toFIG. 3. In general, operational modules110to116in RE108may perform various activities in support of the handling of the AKS certificate, and the generation of the TPS certificate and TPS credentials for device102. FW module110may process commands received from other modules112to116associated with AKS and/or TPM. Encryption module112may comprise an OS-specific encryption description provided with the OS of device102(e.g., Microsoft Windows, Apple Mac OS, Linux, etc.). Utilizing Windows 8 and EPID as an example, some modifications in the OS Bcrypt/NCrypt library functions may be required for processing EPID. These extensions may be integrated inside Windows 8 or may be provided by Intel unique extensions to the BCrypt/NCrypt library modules. Service module114may comprise a dynamically linked library (DLL) for managing the AKS private key, TPM key handle (e.g., the TPM key handle points to the location of the TPM key) and the TPM certificate. CA116may be an interface through which modules110to114may interact with certification platform (CP)118for TPM device certification and attestation platform (AP)120during TPM attestation operations wherein the trusted platform status of device102may be validated. In one embodiment, CA116may comprise anti-malware features to protect device102from attack. In the same or a different embodiment, the certification functionality provided by CA118and the attestation functionality provided by AP120may be performed by the same entity (e.g., CA118and AP120may be combined in a single device, or group of devices, in remote resource104).

FIG. 2illustrates an alternative example system for TPM certification and attestation utilizing an anonymous key system comprising trusted execution environments in accordance with at least one embodiment of the present disclosure. In the example disclosed inFIG. 2, FW module110may be loaded as two separate firmware modules. For example, TPM FW module200may be loaded into trusted execution environment (TEE)202and AKS FW module204may be loaded into TEE206. TEEs204and206may comprise protected areas of memory in which known-good programs may execute, confidential information may be stored in a secure manner, etc. In general, TEEs204and206may each comprise a set of computing resources that are secure such that programs executing within TEEs204and206, and any data associated with the executing programs, are isolated. Outside actors cannot be interfere with or observe the programs/data within TEEs204and206during program execution with the exception that the program may be started or stopped and the associated data may be inserted or deleted. Any data leaving TEEs204and206may be released in a controlled manner. Consistent with the present disclosure, at least one known-good program executing within each of TEEs204and206may perform any or all operations disclosed herein in regard to TEEs204and206. In one example implementation, TEEs204and206may employ Software Guard Extensions (SGX) technology developed by the Intel Corporation. SGX may provide a secure and hardware-encrypted computation and storage area within system memory, the contents of which cannot be deciphered by privileged code or even through the application of hardware probes to memory bus. When TEEs204and206are protected by SGX, embodiments consistent with the present disclosure make it impossible for intruders to decipher the contents of TEEs204and206. Protected data cannot be observed outside of SGX, and thus, is inaccessible outside of SGX.

In an example implementation wherein TEEs204and206employ SGX, the identity of programs (e.g., based on a cryptographic hash measurement of each program's contents) may be signed and stored inside each program. When the programs are then loaded into SW112, the processor may verify that the measurement of the program (e.g., as computed by the processor) is identical to the measurement previously embedded inside the program. The signature used to sign the embedded measurement is also verifiable because the processor may be provided with a public key used to verify the signature at program load time. This way malware can't tamper with the program without also altering its verifiable measurement. Malware also cannot spoof the signature because the signing key is secure with the program's author. Thus, the software may not be read, written to or altered by any malware. Moreover, data may also be protected in TEE module106. For example, known-good programs in SW112may encrypt data such as keys, passwords, licenses, etc. so that only verified good programs may decrypt this data. At least one benefit of having at least two separate TEE modules202and206is that if either TEE module202or TEE module206malfunctions or becomes compromised, the remaining TEE will still be intact and protecting either TPM FW module200or AKS FW module204, respectively.

Consistent with the present disclosure, AKS FW module200may be utilized to attest to operations performed by TPM FW module204via, for example, a separable attestation channel. The separable attestation channel may provide evidence to mistrust TPM FW module200should TEE202become compromised. The signing (e.g., certification) of a TPM certificate by an AKS certificate may confirm that AKS FW module204, which is isolated from TPM FW module200, asserts the TPM environment, including protection of the TPM keys, is intact, trustworthy, etc. At least one benefit of this arrangement that TPM FW module200may be able to process TPM “field upgrade” commands and other TPM operations that would normally call into question the trustworthiness of TPM FW module200, but without the trust concerns due to the presence of AKS FW module204isolated in TEE206. This confidence may exist because AKS FW module204may objectively evaluate the trust of TPM FW module200. In at least one embodiment, AKS FW module204may be more constrained and less complex than TPM FW module200.

FIG. 3illustrates example configurations for a device and at least one device making up a remote resource usable in accordance with at least one embodiment of the present disclosure. In particular, device102′ and/or remote resource104′ may be capable of performing example functionality such as disclosed inFIG. 1. However, device102′ and remote resource104′ are meant only as examples of apparatuses that may be usable in embodiments consistent with the present disclosure, and are not meant to limit these various embodiments to any particular manner of implementation.

Device102′ may comprise, for example, system module300configured to manage device operations. System module300may include, for example, processing module302, memory module304, power module306, user interface module308and communication interface module310. Device102′ may also include communication module312. While communication module312has been illustrated as separate from system module300, the example implementation shown inFIG. 3has been provided merely for the sake of explanation. Some or all of the functionality associated with communication module312may be incorporated into system module300.

In device102′, processing module302may comprise one or more processors situated in separate components, or alternatively, one or more processing cores embodied in a single component (e.g., in a System-on-a-Chip (SoC) configuration) and any processor-related support circuitry (e.g., bridging interfaces, etc.). Example processors may include, but are not limited to, various x86-based microprocessors available from the Intel Corporation including those in the Pentium, Xeon, Itanium, Celeron, Atom, Core i-series product families, Advanced RISC (e.g., Reduced Instruction Set Computing) Machine or “ARM” processors, etc. Examples of support circuitry may include chipsets (e.g., Northbridge, Southbridge, etc. available from the Intel Corporation) configured to provide an interface through which processing module302may interact with other system components that may be operating at different speeds, on different buses, etc. in device102′. Some or all of the functionality commonly associated with the support circuitry may also be included in the same physical package as the processor (e.g., such as in the Sandy Bridge family of processors available from the Intel Corporation).

Processing module302may be configured to execute various instructions in device102′. Instructions may include program code configured to cause processing module302to perform activities related to reading data, writing data, processing data, formulating data, converting data, transforming data, etc. Information (e.g., instructions, data, etc.) may be stored in memory module304. Memory module304may comprise random access memory (RAM) or read-only memory (ROM) in a fixed or removable format. RAM may include volatile memory configured to hold information during the operation of device102′ such as, for example, static RAM (SRAM) or Dynamic RAM (DRAM). ROM may include non-volatile (NV) memory modules configured based on BIOS, UEFI, etc. to provide instructions when device102′ is activated, programmable memories such as electronic programmable ROMs (EPROMS), Flash, etc. Other fixed/removable memory may include, but are not limited to, magnetic memories such as, for example, floppy disks, hard drives, etc., electronic memories such as solid state flash memory (e.g., embedded multimedia card (eMMC), etc.), removable memory cards or sticks (e.g., micro storage device (uSD), USB, etc.), optical memories such as compact disc-based ROM (CD-ROM), Digital Video Disks (DVD), Blu-Ray Disks, etc.

Power module306may include internal power sources (e.g., a battery, fuel cell, etc.) and/or external power sources (e.g., electromechanical or solar generator, power grid, external fuel cell, etc.), and related circuitry configured to supply device102′ with the power needed to operate. User interface module308may include hardware and/or software to allow users to interact with device102′ such as, for example, various input mechanisms (e.g., microphones, switches, buttons, knobs, keyboards, speakers, touch-sensitive surfaces, one or more sensors configured to capture images and/or sense proximity, distance, motion, gestures, orientation, biometric data, etc.) and various output mechanisms (e.g., speakers, displays, lighted/flashing indicators, electromechanical components for vibration, motion, etc.). The hardware in user interface module308may be incorporated within device102′ and/or may be coupled to device102′ via a wired or wireless communication medium.

Communication interface module310may be configured to manage packet routing and other control functions for communication module312, which may include resources configured to support wired and/or wireless communications. In some instances, device102′ may comprise more than one communication module312(e.g., including separate physical interface modules for wired protocols and/or wireless radios) managed by a centralized communication interface module310. Wired communications may include serial and parallel wired mediums such as, for example, Ethernet, Universal Serial Bus (USB), Firewire, Thunderbolt, Digital Video Interface (DVI), High-Definition Multimedia Interface (HDMI), etc. Wireless communications may include, for example, close-proximity wireless mediums (e.g., radio frequency (RF) such as based on the RF Identification (RFID) or the Near Field Communications (NFC) standards, infrared (IR), etc.), short-range wireless mediums (e.g., Bluetooth, WLAN, Wi-Fi, etc.), long range wireless mediums (e.g., cellular wide-area radio communication technology, satellite-based communications, etc.), electronic communications via sound waves, etc. In one embodiment, communication interface module310may be configured to prevent wireless communications that are active in communication module312from interfering with each other. In performing this function, communication interface module310may schedule activities for communication module312based on, for example, the relative priority of messages awaiting transmission. While the embodiment disclosed inFIG. 3illustrates communication interface module310being separate from communication module312, it may also be possible for the functionality of communication interface module310and communication module312to be incorporated into the same module.

Consistent with the present disclosure, at least part of RE108(e.g., RE108′ which may comprise at least a software portion of RE108) may reside in memory module306. Similarly at least part of CP118′ and AP120′ may reside in remote resource104′. Remote resource104′ may comprise computing resources that are substantially similar to user device102′ including, for example, system module300′, processing module302′, memory module304′, power module306′, user interface module308′, communications interface module310′ and communication module312′. Additions or subtractions to modules300′ to312′ may be based on the particular implementation of remote resource104′. For example, given remote resource104′ comprises a rack server (e.g., in a cloud computing architecture), some or all of user interface module308′ may be omitted to save space for processors, storage, etc., the user interface functionality being provided by a remote client station when required. Operational modules in RE108′ (e.g., CA module116), may interact with CP118′ and/or AP120′ by causing communication module312to send messages that may be received in remote resource104′ via communication module312′.

FIG. 4illustrates an example of certification in accordance with at least one embodiment of the present disclosure. In general,FIG. 4discloses an example of interactions that may occur between operational modules110to116and CP118during the TPM certification of device102. TPM certification may be initiated by, for example, activating (e.g., booting or rebooting) device102, activating an application in device requiring TPM certification, by manual configuration of device102, etc. CA module may then request that service module114obtain the device's AKS certificate at400. Service module114may then interact with FW module110, as shown at402, to cause FW module110to retrieve the AKS certificate from, for example, storage in AKS and integrated TPM resources106. Service module114may then provide the AKS certificate to CA module116at404.

CA module116may interact with encryption module112to generate a TPM key handle as shown at406, and then may initiate TPM key finalization based on the AKS certificate at408. Encryption module112may then interact with FW module110to cause a TPM certificate to be generated at410, and then for the TPM certificate to be signed at412. Encryption module112may then provide the TPM certificate signed by the AKS certificate to CA module116at414, which may proceed to cause device102to transmit the signed TPM certificate to CP118at416. TPM certification may initially comprise, for example, CP118validating the AKS signature on the TPM certificate, and then generating TPM credentials for device102based on the TPM certificate at418. CP118may then transmit at least the TPM credentials back to CA module116in device102at420. Device102may then be considered successfully TPM certified at422.

While not disclosed in the operations shown inFIG. 4, CP118may also be responsible for revoking TPM credentials in device102. CP118may manage a list of rogue devices102. It may also maintain a list of TPM credentials issued for those devices. When TPM credentials are revoked, all corresponding TPM certificates must be revoked as well. For example, assuming a TPM certificate needs to be revoked because of an exploited TPM FW vulnerability, at least one solution would first comprise the AKS certificate issuer first revoking all AKS certificates for an effected public key group. However, the revocation of an AKS group certificate would affect all of the private key holders in the key group, and thus, such large scale revocation may prove to be overkill unless there is a widespread systemic problem. It may be possible for the AKS systems in device102to be intact regardless of the TPM system state. As disclosed inFIG. 2, in at least one embodiment AKS and TPM systems may be isolated in device102. Attestation of TPM FW module200would be revealed in the attestation of TEE202. AKS FW module204should then refuse to sign (endorse) the TPM certificate under these conditions. Regardless of how the TPM and/or AKS FW flaw is determined (e.g., based on the implementation of device102), CP118may then revoke the TPM root key was associated with the bad version of the TPM FW. CP118may then issue a certificate revocation list (CRL) update to its CRL distribution servers which, in at least one example implementation, are downloaded periodically (e.g., on a weekly basis). The revocation of the TPM credentials may be realized on the next attempted use of TPM credentials by device102. The TPM software on device102would be notified of the revocation and would trigger a TPM FW update to fix the vulnerability that caused the original revocation.

FIG. 5illustrates an example implementation of certification in accordance with at least one embodiment of the present disclosure. In particular, example implementation500utilizes EPID on a device102running a Windows OS. TPM certification may start by CA module116′ initially issuing a GetEpidCert( ) command to service module114′, which may cause service module114′ to subsequently transmit a GetGid( ) instruction to FW module110′. FW module110′ may then return a :GID including an EPID certification. Service module114′ may extract the EPID certification as shown by the ExtracEpidCert( ) instruction, and the :EPID_CERT may be sent to CA module116′. CA module116′ may then issue an NCryptCreatePersistedKey( ) instruction to Encryption module112′, which may provide the :AIK_KEY_HANDLE back to CA module116′. CA module116′ may then issue an NcryptSetProperty( ) command to Encryption module112′, followed by an NcryptFinalizeKey(EPID_SIG_ON_KEY) command to cause encryption module112′ to work with FW module110′ to generate the signed TPM key.

Encryption module112′ may then issue a TPM2_Create(EPID_OID) instruction to FW module110′, which may respond with an attestation identity key (AIK) that may correspond to the TPM certificate inFIG. 4. A TPM2_CertifyCreation(AIK_PUB_EPID_SIG) command may then be used by Encryption module112′ to instruct FW module110′ to sign the AIK with the EPID certificate. The signed AIK certificate (e.g., :ID_BINDING_EPID_SIG) may then be provided to CA module116′, which may transmit the ID_BINDING_EPID_SIG to CP118′ in a pmAttPubKeyFromIdBinding(AikPub, EPID_SIG, EPID_CERT) message. CP118′ may ValidateEpidSig( ) (e.g., validate the EPID signature on the AIK) and then GenAikCred( ) (e.g., generate AIK credentials) which are then transmitted back to CA module116′ as :SUCCESS.

FIG. 6illustrates an example of attestation in accordance with at least one embodiment of the present disclosure. In general,FIG. 6discloses an example of interactions that may occur between operational modules110to116and CP118during the attestation of the TPM “trusted platform” status of device102. AP120may initiate attestation by requesting TPM credentials from device102via CA module116at600. CA module116may then request TPM credentials from encryption module as shown at602. The request received at602may cause encryption module112to interact with FW module602to obtain the TPM credentials as shown at604. Encryption module12may then provide the TPM credentials, along with the TPM certificate, to CA module116at606, and the CA module may cause device102to transmit a response to the request at608, the response including at least the TPM credentials and TPM certificate. As shown at610, AP120may then validate the TPM credentials using the TPM certificate that was provided in the response, and if validated, may transmit a confirmation of successful validation to CA module116at612. Device102may then be considered a “trusted platform” at614.

FIG. 7illustrates an example implementation of attestation in accordance with at least one embodiment of the present disclosure. In particular, example implementation700utilizes EPID on a device102running a Windows OS. AP120′ may transmit a GetQuote command to CA module116′. A TpmAttGeneratePlatformAttestation(AIK_KEY_HANDLE) instruction may then be sent from CA module116′ to encryption module112′, which cause encryption module112′ to send a TPM2_Quote( ) command to FW module110′ A quote (e.g., TPM credentials) may then be forwarded from FW module110′ to encryption module112′ to CA module116′. CA module116′ may then cause device102to transmit a SendAttestation(Quote) message to AP120′, which may validate the quote. If the quote is validated, AP120′may send :SUCCESS message notifying CA module116′ in device102that validation was successful.

FIG. 8illustrates an alternative example of attestation including secondary validation in accordance with at least one embodiment of the present disclosure. In general, the operations inFIG. 8disclose attestation operations wherein both the AKS certificate and TPM certificate are used to validate the trusted platform status of device102. From a structural standpoint, modules110to114(e.g., as shown inFIG. 1) may be the same. However, in the embodiment disclosed inFIG. 8, CA module116may retain the AKS certificate and the TPM certificate signed by the AKS certificate, and may append to the attestation response the TPM credential signed by the TPM certificate, the TPM certificate signed by the AKS certificate and the AKS certificate. The attestation operation may then be modified to accept a signature-based revocation list (SIG-RL) structure which may be included in the AKS signing operation. The TPM certificate signed by AKS key may then be verified by the AP120as part of a TPM certificate enrollment protocol (e.g., utilizing a Public Key Cryptography Standard (PKCS) #10with an extension containing an AKS signature). AKS signature verification may then check for signature revocation in addition to group certificate revocation using certificate revocation lists (CRLs). AP118may also include a policy object identifier (OID) indicating that the TPM certificate was attested using the AKS certificate and that CA validated the signature. Optionally, the PK#10extension may be included directly into the certificate for third party verification and inspection.

InFIG. 8, the module interactions illustrated at800to806may be substantially the same as interactions500to506illustrated inFIG. 6. However, at808service module114may append the TPM credentials, the TPM certificate and the AKS certificate to the response sent to AP120at810. AP120may then validate the TPM certificate using the AKS certificate at812, and then may validate the TPM credentials using the validated TPM certificate at814. Similar toFIG. 5, if validation is successful at812and814, then a success message may be sent from AP120to CA module116as shown at816, and device102may be considered a trusted platform at818.

FIG. 9illustrates an alternative example of attestation including AKS-based validation in accordance with at least one embodiment of the present disclosure. In general, the operations inFIG. 9disclose attestation operations wherein AP120may utilize only the AKS certificate to validate the TPM credentials, eliminating the need for certification of the TPM credentials as disclosed inFIGS. 3 and 4. Similar toFIG. 8, modules110to114(e.g., as shown inFIG. 1) may be the same. However, CA module116may able to retain the AKS Certificate and to append the TPM quote response with the AKS Certificate. The quote interface may be modified to accept a SIG-RL revocation structure that is included in the AKS signature operation. In addition, AP120must be able to verify TPM credentials signed using AKS-based signature algorithm. AKS signature validation checks for signature revocation in addition to group certificate revocation using CRLs. In at least one embodiment, AKS certificate validation may also be offloaded to another entity (e.g., another server in remote resource104) which the requestor is able to trust.

InFIG. 9, the module interactions illustrated at900to906may be substantially the same as interactions500to506illustrated inFIG. 5and interactions700to706illustrated inFIG. 7. However, at908only the TPM credentials and the AKS certificate may be appended to the response. CA module116may then cause device102to transmit the response to AP120, which may validate the TPM credentials based on the AKS certificate at912. Similar toFIGS. 5 and 7, if validation is successful at912, then a success message may be transmitted from AP120to CA module116as shown at914, and device102may be considered a trusted platform at916.

As used in any embodiment herein, the term “module” may refer to software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage mediums. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices. “Circuitry”, as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. The modules may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smartphones, etc.

Thus, this application is directed to trusted platform certification and attestation utilizing an anonymous key system. In general, TPM certification and TPM attestation may be supported in a device utilizing integrated TPM through the use of anonymous key system (AKS) certification. An example device may comprise at least combined AKS and TPM resources that load AKS and TPM firmware (FW) into a runtime environment that may further include at least an operating system (OS) encryption module, an AKS service module and a TPM Certification and Attestation (CA) module. For TPM certification, the CA module may interact with the other modules in the runtime environment to generate a TPM certificate, signed by an AKS certificate, that may be transmitted to a certification platform for validation. For TPM attestation, the CA module may cause TPM credentials to be provided to the attestation platform for validation along with the TPM and/or AKS certificates.

The following examples pertain to further embodiments. The following examples of the present disclosure may comprise subject material such as a device, a method, at least one machine-readable medium for storing instructions that when executed cause a machine to perform acts based on the method, means for performing acts based on the method and/or a system for TPM certification and attestation utilizing an anonymous key system, as provided below.

According to example 1 there is provided a device for supporting trusted platform module certification and attestation using an anonymous key system. The device may comprise a communication module to communicate with at least a remote resource and combined anonymous key system and integrated trusted platform module resources to load an anonymous key system and trusted platform module firmware module into a runtime environment in the device, the runtime environment further including at least an operating system encryption module, an anonymous key system service module and an interface module to interact with at least a certification platform in the remote resource via the communication module.

Example 2 may include the elements of example 1, wherein the anonymous key system and trusted platform module firmware module comprises an anonymous key system firmware module loaded into a first trusted execution environment and a separate trusted platform module firmware module loaded into a second trusted execution environment.

Example 3 may include the elements of any of examples 1 to 2, wherein the interface module is further to cause an anonymous key system certificate to be requested by the service module from the firmware module and interact with the encryption module to generate a trusted platform module key handle and to initiate finalization of a trusted platform certificate based on at least one the trusted platform module key handle and the anonymous key system certificate.

Example 4 may include the elements of example 3, wherein the encryption module is further to interact with the firmware module to generate the trusted platform module certificate based on at least the trusted platform module key handle and to sign the trusted platform module certificate using the anonymous key system certificate and provide the signed trusted platform module certificate to the interface module.

Example 5 may include the elements of example 4, wherein the interface module is further to cause the communication module to transmit the signed trusted platform module certificate to the certification platform and receive a message from the certification platform via the communication module, the message at least indicating that signed trusted platform module certificate is valid.

Example 6 may include the elements of any of examples 3 to 5, wherein the interface module is further to receive a request for trusted platform module credentials from an attestation platform in the remote resource via the communication module and cause the encryption module to obtain at least the trusted platform module credentials and the trusted platform module certificate from the firmware module.

Example 7 may include the elements of example 6, wherein certification and attestation are handled by the same platform.

Example 8 may include the elements of any of examples 6 to 7, wherein the interface module is further to cause the communication module to transmit a response to the request, the response including at least the trusted platform module credentials for validation by the attestation platform and receive a message from the attestation platform via the communication module, the message at least indicating at least that the trusted platform module credentials have been validated.

Example 9 may include the elements of example 8, wherein the response to the request further comprises the anonymous key system certificate or the trusted platform module certificate for the attestation platform to use in validating the trusted platform module credentials.

Example 10 may include the elements of any of examples 8 to 9, wherein the response to the request further comprises the anonymous key system certificate for the attestation platform to use in validating the trusted platform module certificate and the trusted platform module certificate for the attestation platform to use in validating the trusted platform module credentials.

Example 11 may include the elements of any of examples 3 to 10, wherein the interface module is further to receive a request for trusted platform module credentials from an attestation platform in the remote resource via the communication module, cause the encryption module to obtain at least the trusted platform module credentials and the trusted platform module certificate from the firmware module, cause the communication module to transmit a response to the request, the response including at least the trusted platform module credentials for validation by the attestation platform and receive a message from the attestation platform via the communication module, the message at least indicating at least that the trusted platform module credentials have been validated.

Example 12 may include the elements of any of examples 1 to 11, wherein the anonymous key system is based on Enhanced Privacy Identification (EPID) technology.

According to example 13 there is provided a method for trusted platform module certification and attestation using an anonymous key system. The method may comprise loading a combined anonymous key system and trusted platform module firmware module into a runtime environment in a device, the runtime environment further including at least an operating system encryption module, an anonymous key system service module, an interface module to interact with at least a certification platform in a remote resource, and triggering at least one of trusted platform module certification or trusted platform module attestation in the device.

Example 14 may include the elements of example 13, wherein triggering trusted platform module certification comprises causing an anonymous key system certificate to be requested by the service module from the firmware module and interacting with the encryption module to generate a trusted platform module key handle and to initiate finalization of a trusted platform module certificate based on at least one the trusted platform module key handle and the anonymous key system certificate.

Example 15 may include the elements of example 14, and may further comprise interacting with the firmware module to generate the trusted platform module certificate based on at least the trusted platform module key handle and to sign the trusted platform module certificate using the anonymous key system certificate and providing the signed trusted platform module certificate to the interface module.

Example 16 may include the elements of example 15, and may further comprise causing the communication module to transmit the signed trusted platform module certificate to the certification platform and receiving a message from the certification platform via the communication module, the message at least indicating that signed trusted platform module certificate is valid.

Example 17 may include the elements of any of examples 14 to 16, and may further comprise interacting with the firmware module to generate the trusted platform module certificate based on at least the trusted platform module key handle and to sign the trusted platform module certificate using the anonymous key system certificate, providing the signed trusted platform module certificate to the interface module, causing the communication module to transmit the signed trusted platform module certificate to the certification platform and receiving a message from the certification platform via the communication module, the message at least indicating that signed trusted platform module certificate is valid.

Example 18 may include the elements of any of examples 14 to 17, wherein triggering trusted platform module attestation comprises receiving a request for trusted platform module credentials from an attestation platform in the remote resource via the communication module; and causing the encryption module to obtain at least the trusted platform module credentials and the trusted platform module certificate from the firmware module.

Example 19 may include the elements of example 18, wherein certification and attestation are handled by the same platform.

Example 20 may include the elements of any of examples 18 to 19, and may further comprise causing the communication module to transmit a response to the request, the response including at least the trusted platform module credentials for validation by the attestation platform and receiving a message from the attestation platform via the communication module, the message at least indicating at least that the trusted platform module credentials have been validated.

Example 21 may include the elements of example 20, wherein the response to the request further comprises the anonymous key system certificate or the trusted platform module certificate for the attestation platform to use in validating the trusted platform module credentials.

Example 22 may include the elements of any of examples 20 to 21, wherein the response to the request further comprises the anonymous key system certificate for the attestation platform to use in validating the trusted platform module certificate and the trusted platform module certificate for the attestation platform to use in validating the trusted platform module credentials.

Example 23 may include the elements of any of examples 14 to 22, wherein triggering trusted platform module attestation comprises receiving a request for trusted platform module credentials from an attestation platform in the remote resource via the communication module, causing the encryption module to obtain at least the trusted platform module credentials and the trusted platform module certificate from the firmware module, causing the communication module to transmit a response to the request, the response including at least the trusted platform module credentials for validation by the attestation platform and receiving a message from the attestation platform via the communication module, the message at least indicating at least that the trusted platform module credentials have been validated.

Example 24 may include the elements of any of examples 13 to 23, wherein the anonymous key system is based on Enhanced Privacy Identification (EPID) technology.

According to example 25 there is provided a system including at least a device and a remote resource, the system being arranged to perform the method of any of the above examples 13 to 24.

According to example 26 there is provided a chipset arranged to perform the method of any of the above examples 13 to 24.

According to example 27 there is provided at least one machine readable medium comprising a plurality of instructions that, in response to be being executed on a computing device, cause the computing device to carry out the method according to any of the above examples 13 to 24.

According to example 28 there is provided a device configured for trusted platform module certification and attestation using an anonymous key system, the device being arranged to perform the method of any of the above examples 13 to 24.

According to example 29 there is provided a system for trusted platform module certification and attestation using an anonymous key system. The system may comprise means for loading a combined anonymous key system and trusted platform module firmware module into a runtime environment in a device, the runtime environment further including at least an operating system encryption module, an anonymous key system service module, an interface module to interact with at least a certification platform in a remote resource and means for triggering at least one of trusted platform module certification or trusted platform module attestation in the device.

Example 30 may include the elements of example 29, wherein the means for triggering trusted platform module certification comprise means for causing an anonymous key system certificate to be requested by the service module from the firmware module and means for interacting with the encryption module to generate a trusted platform module key handle and to initiate finalization of a trusted platform module certificate based on at least one the trusted platform module key handle and the anonymous key system certificate.

Example 31 may include the elements of example 30, and may further comprise means for interacting with the firmware module to generate the trusted platform module certificate based on at least the trusted platform module key handle and to sign the trusted platform module certificate using the anonymous key system certificate and means for providing the signed trusted platform module certificate to the interface module.

Example 32 may include the elements of example 31, and may further comprise means for causing the communication module to transmit the signed trusted platform module certificate to the certification platform and means for receiving a message from the certification platform via the communication module, the message at least indicating that signed trusted platform module certificate is valid.

Example 33 may include the elements of any of examples 30 to 32, wherein the means for triggering trusted platform module attestation comprise means for receiving a request for trusted platform module credentials from an attestation platform in the remote resource via the communication module and means for causing the encryption module to obtain at least the trusted platform module credentials and the trusted platform module certificate from the firmware module.

Example 34 may include the elements of example 33, wherein certification and attestation are handled by the same platform.

Example 35 may include the elements of any of examples 33 to 34, and may further comprise means for causing the communication module to transmit a response to the request, the response including at least the trusted platform module credentials for validation by the attestation platform and means for receiving a message from the attestation platform via the communication module, the message at least indicating at least that the trusted platform module credentials have been validated.

Example 36 may include the elements of example 35, wherein the response to the request further comprises the anonymous key system certificate or the trusted platform module certificate for the attestation platform to use in validating the trusted platform module credentials.

Example 37 may include the elements of any of examples 35 to 36, wherein the response to the request further comprises the anonymous key system certificate for the attestation platform to use in validating the trusted platform module certificate and the trusted platform module certificate for the attestation platform to use in validating the trusted platform module credentials.

Example 38 may include the elements of any of examples 29 to 37, wherein the anonymous key system is based on Enhanced Privacy Identification (EPID) technology.