US20070079120A1 - Dynamic creation and hierarchical organization of trusted platform modules - Google Patents

Dynamic creation and hierarchical organization of trusted platform modules Download PDF

Info

Publication number
US20070079120A1
US20070079120A1 US11/242,673 US24267305A US2007079120A1 US 20070079120 A1 US20070079120 A1 US 20070079120A1 US 24267305 A US24267305 A US 24267305A US 2007079120 A1 US2007079120 A1 US 2007079120A1
Authority
US
United States
Prior art keywords
trusted platform
tpm
platform module
virtual
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/242,673
Inventor
Steven Bade
Stefan Berger
Kenneth Goldman
Ronald Perez
Reiner Sailer
Leendert Van Doorn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/242,673 priority Critical patent/US20070079120A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BADE, STEVEN A., VAN DOORN, LEENDERT PETER, PEREZ, RONALD, SAILER, REINER, BERGER, STEFAN, GOLDMAN, KENNETH ALAN
Publication of US20070079120A1 publication Critical patent/US20070079120A1/en
Priority to US12/128,952 priority patent/US8549288B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates generally to a data processing system. Specifically, the present invention provides a method, an apparatus and a computer program product for the dynamic creation and hierarchical organization of trusted platform modules.
  • the Trusted Computing Group has defined the functionality and protocol for a hardware module called the Trusted Platform Module (TPM).
  • TPM Trusted Platform Module
  • This piece of hardware offers security and cryptographic functionality to computer systems such as, for example, asymmetric key generation, decryption, encryption, signing, sealing and binding of data to the state of the TPM, migration of keys between TPMs, random number generation and hashing functionality.
  • a TPM also implements a rather complex state machine which allows some of its operations to only be performed when a sequence of certain commands has been sent to the TPM before.
  • a TPM owner can only be set if an endorsement key has been created previously.
  • the present invention provides a method, system, and computer program product for the dynamic creation and hierarchical organization of trusted platform modules.
  • a trusted platform module domain is created.
  • the trusted platform module may dynamically create virtual trusted platform modules, as needed, in the trusted platform module domain.
  • the created virtual platform modules are called child trusted platform modules and the creating trusted platform module is known as a parent module.
  • Each virtual trusted platform module is associated with a specific partition.
  • Each partition is associated with an individual operating system.
  • FIG. 1 is a pictorial representation of a network of data processing systems in which exemplary aspects of the present invention may be implemented;
  • FIG. 2 is a block diagram of a data processing system in which exemplary aspects of the present invention may be implemented
  • FIG. 3 is a block diagram showing typical software architecture for a server-client system in accordance with a preferred embodiment of the present invention
  • FIG. 4 is a block diagram depicting an example of an architecture for implementing a virtual TPM in accordance with an exemplary embodiment of the present invention
  • FIG. 5 is a block diagram depicting an example of an architecture that has a TPM on the motherboard and the virtual TPM functionality as software in the TPM domain in accordance with an exemplary embodiment of the present invention
  • FIG. 6 is a block diagram depicting an example of an architecture with a TPM on the motherboard and the virtual TPM functionality as software in the domain 0 in accordance with an exemplary embodiment of the present invention
  • FIG. 7 is a flowchart illustrating a method for handling TPM commands in accordance with an exemplary embodiment of the present invention
  • FIG. 8 is a flowchart illustrating a method for handling a create TPM instance command in accordance with an exemplary embodiment of the present invention
  • FIG. 9 is a flowchart illustrating a method for handling a delete TPM instance command in accordance with an exemplary embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a method for handling a setup TPM instance command in accordance with an exemplary embodiment of the present invention
  • FIG. 11 is a flowchart illustrating a method for handling a route embedded command to TPM instance command in accordance with an exemplary embodiment of the present invention
  • FIG. 12 is a block diagram illustrating a communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention.
  • FIG. 13 is a block diagram illustrating an alternative communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention.
  • FIGS. 1-2 are provided as exemplary diagrams of data processing environments in which embodiments of the present invention may be implemented. It should be appreciated that FIGS. 1-2 are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present invention may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present invention.
  • FIG. 1 depicts a pictorial representation of a network of data processing systems in which aspects of the present invention may be implemented.
  • Network data processing system 100 is a network of computers in which embodiments of the present invention may be implemented.
  • Network data processing system 100 contains network 102 , which is the medium used to provide communications links between various devices and computers connected together within network data processing system 100 .
  • Network 102 may include connections, such as wire, wireless communication links, or fiber optic cables.
  • server 104 and server 106 connect to network 102 along with storage unit 108 .
  • clients 110 , 112 , and 114 connect to network 102 .
  • These clients 110 , 112 , and 114 may be, for example, personal computers or network computers.
  • server 104 provides data, such as boot files, operating system images, and applications to clients 110 , 112 , and 114 .
  • Clients 110 , 112 , and 114 are clients to server 104 in this example.
  • Network data processing system 100 may include additional servers, clients, and other devices not shown.
  • network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages.
  • network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
  • FIG. 1 is intended as an example, and not as an architectural limitation for different embodiments of the present invention.
  • Data processing system 200 is an example of a computer, such as server 104 or client 110 in FIG. 1 , in which computer usable code or instructions implementing the processes for embodiments of the present invention may be located.
  • data processing system 200 employs a hub architecture including north bridge and memory controller hub (MCH) 202 and south bridge and input/output (I/O) controller hub (ICH) 204 .
  • MCH north bridge and memory controller hub
  • I/O input/output
  • Processing unit 206 , main memory 208 , and graphics processor 210 are connected to north bridge and memory controller hub 202 .
  • Graphics processor 210 may be connected to north bridge and memory controller hub 202 through an accelerated graphics port (AGP).
  • AGP accelerated graphics port
  • LAN adapter 212 connects to south bridge and I/O controller hub 204 .
  • Audio adapter 216 , keyboard and mouse adapter 220 , modem 222 , read only memory (ROM) 224 , hard disk drive (HDD) 226 , CD-ROM drive 230 , universal serial bus (USB) ports and other communications ports 232 , and PCI/PCIe devices 234 connect to south bridge and I/O controller hub 204 through bus 238 and bus 240 .
  • PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not.
  • ROM 224 may be, for example, a flash binary input/output system (BIOS).
  • BIOS binary input/output system
  • Hard disk drive 226 and CD-ROM drive 230 connect to south bridge and I/O controller hub 204 through bus 240 .
  • Hard disk drive 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface.
  • IDE integrated drive electronics
  • SATA serial advanced technology attachment
  • Super I/O (SIO) device 236 may be connected to south bridge and I/O controller hub 204 .
  • An operating system runs on processing unit 206 and coordinates and provides control of various components within data processing system 200 in FIG. 2 .
  • the operating system may be a commercially available operating system such as Microsoft® Windows® XP (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both).
  • An object-oriented programming system such as the JavaTM programming system, may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 200 (Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both).
  • data processing system 200 may be, for example, an IBM eServerTM pSeries® computer system, running the Advanced Interactive Executive (AIX®) operating system or LINUX operating system (eServer, pSeries and AIX are trademarks of International Business Machines Corporation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both).
  • Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors in processing unit 206 . Alternatively, a single processor system may be employed.
  • SMP symmetric multiprocessor
  • Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 226 , and may be loaded into main memory 208 for execution by processing unit 206 .
  • the processes for embodiments of the present invention are performed by processing unit 206 using computer usable program code, which may be located in a memory such as, for example, main memory 208 , read only memory 224 , or in one or more peripheral devices 226 and 230 .
  • FIGS. 1-2 may vary depending on the implementation.
  • Other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIGS. 1 - 2 .
  • the processes of the present invention may be applied to a multiprocessor data processing system.
  • data processing system 200 may be a personal digital assistant (PDA), which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data.
  • PDA personal digital assistant
  • a bus system may be comprised of one or more buses, such as bus 238 or bus 240 as shown in FIG. 2 .
  • the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture.
  • a communications unit may include one or more devices used to transmit and receive data, such as modem 222 or network adapter 212 of FIG. 2 .
  • a memory may be, for example, main memory 208 , read only memory 224 , or a cache such as found in north bridge and memory controller hub 202 in FIG. 2 .
  • FIGS. 1-2 and above-described examples are not meant to imply architectural limitations.
  • data processing system 200 also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.
  • FIG. 3 typical software architecture, generally designated by reference number 300 , for a server-client system is depicted in accordance with a preferred embodiment of the present invention.
  • operating system 302 is utilized to provide high-level functionality to the user and to other software.
  • Operating system 302 may be implemented in server 104 or client 110 in FIG. 1 , in which computer usable code or instructions implementing the processes for embodiments of the present invention may be located.
  • Such an operating system typically includes BIOS.
  • Communication software 304 provides communications through an external port to a network such as the Internet via a physical communications link by either directly invoking operating system functionality or indirectly bypassing the operating system to access the hardware for communications over the network.
  • Application programming interface (API) 306 allows the user of the system, an individual, or a software routine, to invoke system capabilities using a standard consistent interface without concern for how the particular functionality is implemented.
  • Network access software 308 represents any software available for allowing the system to access a network. This access may be to a network, such as a LAN, WAN, or the Internet. With the Internet, this software may include programs, such as Web browsers.
  • Application software 310 represents any number of software applications designed to react to data through a communications port to provide the desired functionality the user seeks. Applications at this level may include those necessary to handle data, video, graphics, photos or text, which can be accessed by users of the Internet.
  • Hypervisor 312 is a layer of software running on a platform that allows multiple instances of operating systems.
  • a trusted computing architecture within an operating system.
  • the purpose of a trusted computing architecture is for a system to be able to establish trust into another system by learning about the software that has been started on that system.
  • the trusted computing architecture implements the concept of attestation, where attestation is based on the process of measuring all executables, libraries and script files by calculating their individual hash values, and accumulating those in Platform Configuration Registers (PCRs) of the TPM. Using the accumulated hash values along with the list of started programs and their individual measurements, other systems can determine which version of software has been started on a particular system.
  • PCRs Platform Configuration Registers
  • Attestation itself is performed by a system reporting the current values of the system's PCR registers and providing a signature over the reported values using a system-specific key.
  • the knowledge about running software can be used to establish trust into this system by comparing the individual hash values of the applications with previously measured values stored in a database as well as accumulating the hash values and comparing the results to the values of the reported PCR registers.
  • TPM command protocol defines the command set a TPM needs to implement and what parameters are passed in each command.
  • the TPM protocol is strictly request/response-based and a TPM processes one command after another in strict sequence.
  • the TPM supports around 120 different commands which have been put into more than 30 functional groups. Some of the most important functionality of the TPM is the support of storage functions, where encrypted information can be tied to the state of a TPM and can only be decrypted once the TPM has been set into that state again, for example after a reboot of the platform. Other functionality comprises the creation of keys and means to migrate keys from one TPM to another. The execution time that some of the TPM commands need greatly varies from one command type to another. Key creation, for example, can be regarded as a command that takes a long time, whereas, for example, the calculation of a hash value completes rather quickly. Since the TPM executes all commands in sequence, no other commands can complete while, for example, a key is created. This is important for multitasking/multiprocessing environments where possibly multiple processes might want to use the system's TPM at one specific instance.
  • the BIOS For the startup of the first operating system domain running on top of the hypervisor, measurements are handled in the same manner as in the case where an operating system is not running on top of a hypervisor.
  • the BIOS is regarded as a trusted root and starts taking the measurements. Specifically, the BIOS measures the BIOS code, the contents of the Master Boot Record, and the first stage of the boot loader and accumulates the measurements into several dedicated PCR registers.
  • the bootloader grub is modified to measure the kernel and initial random access memory (RAM) disks, which are provided as parameters in a script file that the bootloader grub reads when the system is booted.
  • RAM random access memory
  • Every TPM holds state, which consists of volatile and non-volatile data. This includes the endorsement key pair, the storage root key and all other private keys that are held inside the TPM. Also associated with a TPM are a particular owner and the owner's password. In the model of a single operating system on a machine, different machines with their own TPMs are likely to have different owners. Transferring this association between ownership and TPMs to platforms with multiple operating systems means that one instance of a TPM should be associated with one particular partition. Since partitions can be stopped and started, it is necessary to maintain the association between each partition and each instance of a TPM over the lifetime of a TPM or partition configuration.
  • each operating system produces are treated in a similar way as those treated on a single-operating system.
  • the difference is that measurements taken by the bootloader do not exist for any partition other than the one that is started first. Since on many systems the first partition will be involved in starting other partitions, it is this partition's responsibility to take any possible measurements and prepare the TPM to reflect them. This means, for example, measuring the kernel image and the initial RAM disk if a Linux® kernel is to be started.
  • a virtual TPM allows for the collection of measurements of multiple operating systems.
  • Each operating system is offered its own instance of a TPM where it can create an endorsement key, storage root key, take ownership of the TPM and apply its own owner password.
  • the normal command set that a TPM understands is expanded to allow management of additional instances of a TPM, such as, for example, creating new instances, deleting the new instances, preparing the new instances for usage by a partition, and sending commands to new instances indirectly through forwarding messages from other instances.
  • the extension of the command set enables the download of the complete state of a TPM, including non-volatile RAM (NVRAM) areas, and internally held keys into a file and recreating the TPM state in another multi-instance capable TPM and resume operation there.
  • NVRAM non-volatile RAM
  • a virtual TPM runs on a piece of hardware other than current TPMs that are soldered to the motherboard.
  • One such piece of hardware could be a microprocessor similar to a current single instance TPM with the difference that the hardware should be faster in order to provide enough speed for concurrent processing of TPM requests.
  • FIG. 4 is a block diagram depicting an example of an architecture for implementing a virtual TPM in accordance with an exemplary embodiment of the present invention.
  • hardware 400 provides the only TPM functionality in the system, TPM 402 .
  • the hardware is the IBM XCryptoTM card.
  • all attestations from the BIOS, bootloader, and the first started domain, here the TPM domain, DOM-TPM 406 is recorded in instance 0 .
  • Instance 0 exists in virtual TPM, vTPM 402 of hardware 400 and is always present.
  • DOM-TPM 406 is a dedicated TPM domain with a minimum of applications running. Therefore, DOM-TPM 406 only handles functions related to the TPM. This reduces the chance of errors occurring, increases reliability and improves the trusted computing base.
  • DOM-TPM 406 contains the back-end driver TPM BE 408 .
  • TPM BE 408 communicates with the front-end drivers of the other domains, TPM FE 412 , 418 , 424 and 430 .
  • the back-end driver is aware of which partition a request is coming from since a unique interrupt number has been assigned to each instance of the back-end driver for each front-end communication partner.
  • Instance 0 records the measurements taken by the BIOS, bootloader and TPM domain.
  • Instance 1 records the measurements for domain 0 , DOM- 0 410 , which is started as the second domain. Instance 1 also resides in vTPM 402 of hardware 400 . Further instances, all of which will reside in vTPM 402 of hardware 400 , are created as needed when additional domains are created.
  • DOM- 0 410 , DOM-U 416 , DOM-U 422 and DOM-U 428 are additional domains all of which are running separate operating systems in their virtualized partition. In the example depicted, each domain has multiple applications, 414 , 420 , 426 and 432 running.
  • DOM- 0 410 , DOM-U 416 , DOM-U 422 and DOM-U 428 communicate with DOM-TPM 406 through exchange of data over a channel provided by the hypervisor 404 .
  • DOM-TPM 406 then communicates with vTPM 402 .
  • FIG. 5 is a block diagram depicting an example of an architecture that has a TPM on the motherboard and the virtual TPM functionality as software in the TPM domain in accordance with an exemplary embodiment of the present invention.
  • TPM 502 is a TPM located on a motherboard. Similar to the architecture of FIG. 4 , attestations from the BIOS, bootloader and the TPM domain, DOM-TPM 506 , are recorded in TPM 502 .
  • DOM-TPM 506 is a dedicated TPM domain with a minimum of applications running. Therefore, DOM-TPM 506 only handles functions related to the TPM. This reduces the chance of errors occurring, increases reliability and improves the trusted computing base.
  • DOM-TPM 506 contains back-end driver TPM BE 508 .
  • TPM BE 508 communicates with the front-end drivers of the other domains, TPM FE 514 , 524 , 534 and 544 .
  • the back-end driver is aware of which partition a request is coming from since a unique interrupt number has been assigned to each instance of the back-end driver for each front-end communication partner.
  • vTPM 510 , 520 , 530 , and 540 are created and exist in DOM-TPM 506 .
  • Instance 0 of the vTPM 510 records the measurements for domain 0 , DOM- 0 512 , which is started as the second domain.
  • Further instances and virtual TPMs, vTPM 520 , 530 and 540 are created as need when additional domains, such as DOM-U 522 , DOM-U 532 , and DOM-U 542 , are created.
  • Each virtual TPM corresponds to one specific domain.
  • vTPM 510 corresponds to DOM- 0 512
  • vTPM 520 corresponds to DOM-U 522
  • vTPM 530 corresponds to DOM-U 532
  • vTPM 540 corresponds to DOM-U 542 .
  • each domain has multiple applications, 516 , 526 , 536 , and 546 running.
  • DOM- 0 512 , DOM-U 522 , DOM-U 532 , and DOM-U 542 communicate with DOM-TPM 506 , and their respective virtual TPMs through exchange of data over a channel provided by the hypervisor 504 .
  • FIGS. 4 and 5 both have in common that the TPM domain effectively provides proxy functionality for TPM services, with the difference being that of where the processing of the TPM requests is happening.
  • the final processing or TPM requests in FIG. 4 happens in the external XcryptoTM card, whereas in FIG. 5 all TPM requests are processed by the TPM software implementation in the vTPM instances 510 , 520 , 530 , and 540 .
  • the architecture depicted in FIG. 4 may also be considered as more secure, since all TPM functionality is provided by the hardware.
  • FIG. 6 is a block diagram depicting an example of an architecture with a TPM on the motherboard and the virtual TPM functionality as software in the domain 0 in accordance with an exemplary embodiment of the present invention.
  • TPM 602 is a TPM located on a motherboard.
  • hypervisor 604 always boots domain 0 , DOM- 0 606 , as the first domain, which forces all virtual TPM functionality into domain 0 .
  • DOM- 0 606 is not a dedicated TPM domain.
  • DOM- 0 606 has other functionality besides handling TPM functions. For example, DOM- 0 606 also handles the creation of the other domains, DOM-U 612 , DOM-U 622 , DOM-U 632 , and DOM-U 642 .
  • TPM 602 Attestations from the BIOS, bootloader and DOM- 0 606 , are recorded in TPM 602 .
  • DOM- 0 606 contains back-end driver TPM BE 608 .
  • TPM BE 608 communicates with the front-end drivers of the other domains, TPM FE 614 , 624 , 634 and 644 .
  • the back-end driver is aware of which partition a request is coming from since a unique interrupt number has been assigned to each instance of the back-end driver for each front-end communication partner.
  • vTPM 610 , 620 , 630 , and 640 are created as needed when user domains, such as DOM-U 612 , DOM-U 622 , DOM-U 632 , and DOM-U 642 are created.
  • Each virtual TPM corresponds to one specific domain.
  • vTPM 610 corresponds to DOM-U 612
  • vTPM 620 corresponds to DOM-U 622
  • vTPM 630 corresponds to DOM-U 632
  • vTPM 640 corresponds to DOM-U 642 .
  • each domain has multiple applications, 616 , 626 , 636 and 646 , running.
  • DOM-U 612 , DOM-U 622 , DOM-U 632 , and DOM-U 642 communicate with DOM- 0 606 , and their respective virtual TPMs through exchange of data over a channel provided by the hypervisor 604 .
  • One of the issues with the dynamicity of the virtual TPM is the handling of the endorsement key of each created instance.
  • the platform manufacturer establishes the endorsement key pair when the machine is built and issues a certificate for the public key part of the endorsement key.
  • the owner of the machine can use the certificate to prove ownership of the machine.
  • the certificate also indicates that the device in which the private key is stored is, in fact, a TPM device which hides the private key from its owner.
  • the platform manufacturer can not know the public key parts of all created endorsement keys. However, the manufacturer can certify the public key part of the endorsement key of instance 0 and provide the certificate to the platform owner. Then, to create certificates of individual instances of the TPM, the TPM instance 0 can be used to certify the endorsement keys of its TPM child instances by effectively creating a certificate chain. To realize this in a simple way, the public key part of the endorsement key of every TPM instance can be certified through instance 0 issuing a signature over that endorsement key using its own endorsement key, or attestation identity key (AIK) for signing.
  • AIK attestation identity key
  • An exemplary embodiment of the present invention solves this problem by creating a pool of threads at the lowest level of the TPM.
  • the pool of threads allows concurrent processing of multiple requests. At any given time only one thread is waiting for a TPM request in the driver. Once it has received a TPM request, it leaves the kernel driver and starts processing that request inside the targeted TPM instance while the next thread has been released to wait for the next request. In an exemplary embodiment of the present invention, this feature is achieved through the usage of thread locks. In another exemplary embodiment of the present invention, through a similar way of using locking mechanisms, only one thread is allowed to write a response to the driver.
  • the demultiplexing of TPM requests to be able to route them to their intended instance is solved through proper setup of the TPM back-end driver that is located under the virtual TPM.
  • TPM back-end driver that is located under the virtual TPM.
  • domain configuration files known as virtual machine configuration files
  • a declaration of what instance of the TPM will be associated with which partition is made. This is configuration information that applies only to the back-end driver and allows the back-end driver to prepend a 4-byte instance number to the TPM request before the TPM request is passed to the TPM running in the user level.
  • the instance number is made available to the back-end driver when the back-end and front-end are setup for communication during partition bootup time.
  • the back-end driver is aware of which partition a request is coming from through the unique interrupt number that has been assigned to the back-end driver for each front-end communication partner. Therefore, as prepending the instance number may be handled more securely on the back end-side, in an exemplary embodiment of the present invention, the instance number is not prepended in the front-end side. Additionally, this prevents accidentally forging the source of a request.
  • the same kind of channel that is used for a user partition to communicate with a TPM instance may also exist for communication between the privileged domain 0 and the TPM domain.
  • the extended command set uses the same layout for TPM commands as all the existing TPM commands do. Therefore, this channel can deliver those commands to the TPM.
  • downloading the state of a TPM requires a fair amount of byte transfer towards the privileged domain, which can, at least in some architecture, not be accommodated through event channels.
  • the setup procedure of the TPM back-end and front-end drivers serves as an establishment phase for a channel, but not necessarily as an instantiation request for a TPM instance.
  • an instantiation request for TPMs occur on a higher layer through the exchange of commands using the established channel.
  • the TPM domain may provide two different sets of functionality.
  • One case is where there is no hardware available to support a virtual TPM.
  • a software TPM would be hosted in the TPM domain or domain 0 and process the requests from all other domains, as shown in FIGS. 5 and 6 respectively.
  • the TPM domain becomes a pure proxy domain for transferring data from the back-end driver to the PCI device driver and vice versa, as shown in FIG. 4 .
  • a user-level application would not be necessary in this case.
  • a higher level tool exists that knows throughout the lifetime of a system which partition is associated with which instance of a TPM. Whenever a new partition is created, a TPM instance should automatically be created and that association established for as long as the partition's definition is kept on the system. When a partition is suspended, the TPM's state could also be suspended and the instance be deleted until either the partition is migrated to a new system or restarted on the local system. In both cases a new instance of a TPM should be created, the TPM state be restored and the partition configuration file updated accordingly.
  • the higher level tool should hide the peculiarities of the partition configuration files from the user.
  • the additional TPM commands can be grouped into two different groups: (i) Virtual TPM Management functions and (ii) Virtual TPM Migration support functions.
  • the first group of functions enables a user to create and delete virtual TPM instances inside a TPM as well as prepare the virtual TPM instances for immediate submission of measurements when a partition starts up.
  • the TPM's PCR registers may be pre-loaded with some initial values from measurements taken about the kernel and the initial RAM disk (initrd).
  • a virtual TPM has been implemented in such a way that the first instance, the one that is always available, allows the creation of additional virtual TPM instances.
  • the additional TPM instances themselves may be created as privileged instances which may inherit the ability to create additional instances. Using this functionality, a user may effectively build a tree of TPM instances.
  • the second group of TPM functions enables a user to download state information from the TPM and store it into a file and later on recreate the TPM on a different system.
  • the state of the TPM is comprised of NVRAM, keys, volatile and non-volatile flags, established session, and counters.
  • the availability of instances of each type are queried and downloaded, one after another, and their content are stored into a file. When recreating an instance, the contents of the file are read and uploaded to the new instance.
  • the extended commands are designed such that they pick up on the philosophy of existing TPM commands for authorization using nonces, which are unique session identifiers, and password-keyed hashes, such as the keyed-hash message authentication code (HMAC), for single or double authorization of the owner or keys.
  • nonces which are unique session identifiers
  • password-keyed hashes such as the keyed-hash message authentication code (HMAC)
  • HMAC keyed-hash message authentication code
  • an application using virtual TPM commands will build and send a request to the virtual TPM.
  • the virtual TPM receives the request, processes the request, builds a response and then sends a response to the application.
  • the request for the virtual TPM is communicated from the front-end driver to the back-end driver through the hypervisor.
  • the back-end driver then routes the request to the proper virtual TPM, as the back-end driver and the virtual TPMs reside in the same domain, DOM-TPM 506 in FIG. 5 or DOM- 0 606 in FIG. 6 .
  • the back-end driver passes the request onto the hardware device.
  • the software on the hardware device which is where the virtual TPMs reside in FIG. 4 , directs the requests to the proper virtual TPMs.
  • FIG. 7 is a flowchart illustrating a method for handling TPM commands in accordance with an exemplary embodiment of the present invention.
  • the operation begins with the TPM waiting to receive a command (step 702 ). Once a command is received, the TPM determines if the command is a “create TPM instance” command (step 704 ). If the command is the create TPM instance command (a yes output to step 704 ), then create the TPM instance as explained in greater detail in FIG. 8 . If the command is not the create TPM instance command (a no output to step 704 ), then the TPM determines if the command is a “delete TPM instance” command (step 706 ).
  • the TPM determines if the command is a “setup TPM instance” command (step 708 ).
  • the TPM determines if the command is a “route embedded command to TPM instance” command (step 710 ).
  • step 710 If the command is the route embedded command to TPM instance command (a yes output to step 710 ), then route the embedded command to the TPM instance as explained in greater detail in FIG. 11 . If the command is not the route embedded command to TPM instance command (a no output to step 710 ), then the TPM verifies the validity of the command (step 712 ) and processes it as a normal TPM command, eventually returning to step 702 .
  • FIG. 8 is a flowchart illustrating a method for handling a create TPM instance command in accordance with an exemplary embodiment of the present invention.
  • the operation begins by receiving a command to create a TPM instance as the child of instance P, where instance P is the parent instance (step 802 ).
  • the operation verifies if user authentication for the command is valid (step 804 ). If the user authentication for the command is not valid (a no output to step 804 ), the appropriate error code is sent as the result value (step 814 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 804 ), the operation determines if instance P is a descendant of the processing TPM (step 806 ).
  • instance P is not a descendant of the processing TPM (a no output to step 806 )
  • the appropriate error code is sent as the result value (step 814 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • instance P is a descendant of the processing TPM (a yes output to step 806 )
  • the operation determines if instance P is a privileged instance (step 808 ).
  • a privileged instance is an instance with permission to create other, child instances.
  • instance P is not a privileged instance (a no output to step 808 )
  • the appropriate error code is sent as the result value (step 814 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • instance P is a privileged instance (a yes output to step 808 )
  • the operation creates a TPM instance as the child of instance P with all the requested privileges (step 810 ).
  • the child TPM instance inherits the properties of parent instance P.
  • the child TPM is assigned a unique instance handle H. Unique instance handle H is returned to the caller (step 812 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 9 is a flowchart illustrating a method for handling a delete TPM instance command in accordance with an exemplary embodiment of the present invention.
  • the operation begins by receiving a command to delete a TPM instance with the unique instance handle H (step 902 ). Next the operation verifies if user authentication for the command is valid (step 904 ). If the user authentication for the command is not valid (a no output to step 904 ), the appropriate error code is sent as the result value (step 914 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 904 ), the operation determines if instance H is a descendant of the processing instance P (step 906 ).
  • step 914 the appropriate error code is sent as the result value (step 914 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H is a descendant of the processing TPM (a yes output to step 906 ), the operation determines if instance H has descendants (step 908 ).
  • An instance may only be deleted if it does not have any children instances that are dependent upon it. If instance H has any descendants (a yes output to step 908 ), the appropriate error code is sent as the result value (step 914 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H does not have any descendants (a no output to step 908 ), the operation deletes all data associated with instance H (step 910 ). The operation deletes all references to instance H from the parent instance P (step 912 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 10 is a flowchart illustrating a method for handling a setup TPM instance command in accordance with an exemplary embodiment of the present invention.
  • To setup a TPM instance means to prepare the instance for usage.
  • an application in domain 0 sends a sequence of commands to a privileged TPM instance to prepare the virtual TPM instance to accept commands from the operating system, which has a similar effect to the commands that usually the BIOS is sending to the hardware TPM to prepare it for accepting commands from the operating system.
  • the application is providing an array of PCR register indices and hash values along with string identifiers.
  • the virtual TPM instance must have been created prior to this step and is uniquely identified through its unique instance handle H.
  • the operation begins by receiving a command to setup a TPM instance with the unique instance handle H (step 1002 ). Next the operation verifies if user authentication for the command is valid (step 1004 ). If the user authentication for the command is not valid (a no output to step 1004 ), the appropriate error code is sent as the result value (step 1014 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 1004 ), the operation determines if instance H exists (step 1006 ).
  • step 1006 If instance H does not exist (a no output to step 1006 ), the appropriate error code is sent as the result value (step 1014 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H does exist (a yes output to step 1006 ), the operation determines if instance H is a descendant of the processing instance P (step 1008 ).
  • step 1014 the appropriate error code is sent as the result value (step 1014 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • instance H is a descendant of the processing instance P (a yes output to step 1008 )
  • the operation processes those actions requested (step 1010 ). Such processes include running the TPM startup command and enabling and activating the TPM instance H.
  • the operation processes the list of PCR register index values and extends PCR registers with the given hash values (step 1012 ). The operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 11 is a flowchart illustrating a method for handling to route an embedded command to a virtual TPM instance command in accordance with an exemplary embodiment of the present invention.
  • the operation begins by a privileged TPM receiving a command and determining that this command routes an embedded command to a TPM instance with the unique instance handle H (step 1102 ).
  • the operation verifies if user authentication for the command is valid (step 1104 ). If the user authentication for the command is not valid (a no output to step 1104 ), the appropriate error code is sent as the result value (step 1120 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 1104 ), the operation determines if instance H exists (step 1106 ).
  • step 1110 If instance H does not exist (a no output to step 1106 ), the appropriate error code is sent as the result value (step 1120 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H does exist (a yes output to step 1106 ), the operation determines if instance H is a descendant of the processing instance P (step 1108 ).
  • step 1108 If instance H is not a descendant of the processing instance P (a no output to step 1108 ), the appropriate error code is sent as the result value (step 1120 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H is a descendant of the processing instance P (a yes output to step 1108 ), the operation retrieves the embedded command (step 1110 ). Next the operation determines if the size indicator of the command is valid (step 1112 ).
  • step 1112 If the size indicator of the command is not valid (a no output to step 1112 ), the appropriate error code is sent as the result value (step 1120 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the size indicator of the command is valid (a yes output to step 1112 ), the operation determines if the embedded command is allowed to be embedded (step 1114 ).
  • step 1114 If the embedded command is not allowed to be embedded (a no output to step 1114 ), the appropriate error code is sent as the result value (step 1120 ) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the embedded command is allowed to be embedded (a yes output to step 1114 ), the operation processes the embedded command in the target virtual TPM instance as if the command has been sent to it directly (step 1116 ), which can include recursive handling of the command and determining that yet another layer of embedded command is to be processed, repeating steps 1102 through 1116 until no new embedded commands are found. The operation embeds the response message to the embedded command in the response (step 1118 ). The operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 12 is a block diagram illustrating the communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention.
  • allowed communication paths strictly follow the parent-child relationship. The parent always initiates communication with the child and then the child responds. The child never initiates communication to a parent. Only a predecessor may create or delete a child TPM or send a message to a child TPM.
  • TPM instance 0 is the initial TPM instance and it is a privileged instance, meaning it has permission to create, delete and set-up child TPMs.
  • TPM instance 1 , TPM instance 2 , and TPM instance 3 are child TPM instances of TPM instance 0 .
  • TPM instance 4 and TPM instance 5 are child TPM instances of TPM instance 2 , which is a privileged TPM instance.
  • TPM instance 1 and TPM instance 3 are non-privileged, meaning that the permission of parent TPM instance 0 were not passed onto those TPMS and they cannot create, delete or send messages to child TPM instances.
  • TPM instance 2 is privileged and inherited the permission of TPM instance 0 .
  • TPM instance 2 created two child instances of its own, TPM instance 4 and TPM instance 5 .
  • TPM instance 5 is non-privileged.
  • TPM instance 4 is privileged and inherited the permissions of TPM instance 2 , which inherited the permissions of TPM instance 0 .
  • Lines 1202 , 1204 and 1206 show the communication that TPM instance 0 can have.
  • TPM instance 0 can only communicate with TPM instance 1 , TPM instance 2 or TPM instance 3 .
  • Lines 1208 and 1210 show the communication that TPM instance 2 can have.
  • TPM instance 2 can only communicate with TPM instance 4 or TPM instance 5 .
  • FIG. 13 is a block diagram illustrating an alternative communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention.
  • any predecessor may create or delete a child and make the child a child of a given parent and send messages to the child.
  • TPM instance 0 is the initial TPM instance and it is a privileged instance, meaning it has permission to create, delete and set-up child TPMs.
  • TPM instance 1 , TPM instance 2 , and TPM instance 3 are child TPM instances of TPM instance 0 .
  • TPM instance 4 and TPM instance 5 are child TPM instances of TPM instance 2 , which is a privileged TPM instance.
  • TPM instance 1 and TPM instance 3 are non-privileged, meaning that the permission of parent TPM instance 0 were not passed onto those TPMS and they cannot create, delete or communicate with child TPM instances.
  • TPM instance 2 is privileged and inherited the permission of TPM instance 0 .
  • TPM instance 2 created two child instances of its own, TPM instance 4 and TPM instance 5 .
  • TPM instance 5 is non-privileged.
  • TPM instance 4 is privileged and inherited the permissions of TPM instance 2 , which inherited the permissions of TPM instance 0 .
  • Lines 1302 , 1304 , 1306 , 1308 and 1310 show the communication that TPM instance 0 can have.
  • TPM instance 0 can communicate with TPM instance 1 , TPM instance 2 or TPM instance 3 .
  • TPM instance 0 may also communicate with TPM instance 4 and TPM instance 5 , the child TPMs of TPM instance 0 's child TPM, TPM instance 2 .
  • TPM instance 0 may treat TPM instance 4 and TPM instance 5 as its own child TPMs and communicate directly with them and delete them.
  • Lines 1312 and 1314 show the communication that TPM instance 2 can have.
  • TPM instance 2 can only communicate with TPM instance 4 or TPM instance 5 .
  • the present invention provides a method, an apparatus and a computer program product for the dynamic creation and hierarchical organization of trusted platform modules.
  • the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements.
  • the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
  • a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk.
  • Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
  • a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • I/O devices including but not limited to keyboards, displays, pointing devices, etc.
  • I/O controllers can be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
  • Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Abstract

A trusted platform module is presented that is capable of creating, dynamically, multiple virtual trusted platform modules in a hierarchical organization. A trusted platform module domain is created. The trusted platform module creates virtual trusted platform modules, as needed, in the trusted platform module domain. The virtual trusted platform modules can inherit the permissions of a parent trusted platform module to have the ability to create virtual trusted platform modules themselves. Each virtual trusted platform module is associated with a specific partition. Each partition is associated with an individual operating system. The hierarchy of created operating systems and their privilege of spawning new operating systems is reflected in the hierarchy of trusted platform modules and the privileges each of the trusted platform modules has.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates generally to a data processing system. Specifically, the present invention provides a method, an apparatus and a computer program product for the dynamic creation and hierarchical organization of trusted platform modules.
  • 2. Description of the Related Art
  • The Trusted Computing Group has defined the functionality and protocol for a hardware module called the Trusted Platform Module (TPM). This piece of hardware offers security and cryptographic functionality to computer systems such as, for example, asymmetric key generation, decryption, encryption, signing, sealing and binding of data to the state of the TPM, migration of keys between TPMs, random number generation and hashing functionality. A TPM also implements a rather complex state machine which allows some of its operations to only be performed when a sequence of certain commands has been sent to the TPM before. One example of this is that a TPM owner can only be set if an endorsement key has been created previously.
  • Many hardware vendors ship their computing systems equipped with a TPM soldered to the motherboard, which allows widespread usage of the TPM by operating systems such as Linux® or Windows®. It is expected that future versions of the Windows® operating system will support trusted computing with the TPM, and use it, for example, for securely booting a system.
  • The interest in support for trusted computing on virtualizeable systems is growing as hardware virtualization becomes available for more hardware. Being able to run multiple operating systems on one machine will not remain an area only for high-end servers but will become widely available soon. Also, there are already several hypervisors in use today that were built for hardware that has been virtualizeable for many years. A hypervisor is a layer of software running on a platform that allows multiple instances of operating systems. Trusted computing is of interest for building operating system architectures and improving their security. Currently, TPMs are not available for virtualizeable platforms.
  • SUMMARY OF THE INVENTION
  • The present invention provides a method, system, and computer program product for the dynamic creation and hierarchical organization of trusted platform modules. A trusted platform module domain is created. The trusted platform module may dynamically create virtual trusted platform modules, as needed, in the trusted platform module domain. The created virtual platform modules are called child trusted platform modules and the creating trusted platform module is known as a parent module. Each virtual trusted platform module is associated with a specific partition. Each partition is associated with an individual operating system.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
  • FIG. 1 is a pictorial representation of a network of data processing systems in which exemplary aspects of the present invention may be implemented;
  • FIG. 2 is a block diagram of a data processing system in which exemplary aspects of the present invention may be implemented;
  • FIG. 3 is a block diagram showing typical software architecture for a server-client system in accordance with a preferred embodiment of the present invention;
  • FIG. 4 is a block diagram depicting an example of an architecture for implementing a virtual TPM in accordance with an exemplary embodiment of the present invention;
  • FIG. 5 is a block diagram depicting an example of an architecture that has a TPM on the motherboard and the virtual TPM functionality as software in the TPM domain in accordance with an exemplary embodiment of the present invention;
  • FIG. 6 is a block diagram depicting an example of an architecture with a TPM on the motherboard and the virtual TPM functionality as software in the domain 0 in accordance with an exemplary embodiment of the present invention;
  • FIG. 7 is a flowchart illustrating a method for handling TPM commands in accordance with an exemplary embodiment of the present invention;
  • FIG. 8 is a flowchart illustrating a method for handling a create TPM instance command in accordance with an exemplary embodiment of the present invention;
  • FIG. 9 is a flowchart illustrating a method for handling a delete TPM instance command in accordance with an exemplary embodiment of the present invention;
  • FIG. 10 is a flowchart illustrating a method for handling a setup TPM instance command in accordance with an exemplary embodiment of the present invention;
  • FIG. 11 is a flowchart illustrating a method for handling a route embedded command to TPM instance command in accordance with an exemplary embodiment of the present invention;
  • FIG. 12 is a block diagram illustrating a communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention; and
  • FIG. 13 is a block diagram illustrating an alternative communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • FIGS. 1-2 are provided as exemplary diagrams of data processing environments in which embodiments of the present invention may be implemented. It should be appreciated that FIGS. 1-2 are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present invention may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present invention.
  • With reference now to the figures, FIG. 1 depicts a pictorial representation of a network of data processing systems in which aspects of the present invention may be implemented. Network data processing system 100 is a network of computers in which embodiments of the present invention may be implemented. Network data processing system 100 contains network 102, which is the medium used to provide communications links between various devices and computers connected together within network data processing system 100. Network 102 may include connections, such as wire, wireless communication links, or fiber optic cables.
  • In the depicted example, server 104 and server 106 connect to network 102 along with storage unit 108. In addition, clients 110, 112, and 114 connect to network 102. These clients 110, 112, and 114 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 are clients to server 104 in this example. Network data processing system 100 may include additional servers, clients, and other devices not shown.
  • In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for different embodiments of the present invention.
  • With reference now to FIG. 2, a block diagram of a data processing system is shown in which aspects of the present invention may be implemented. Data processing system 200 is an example of a computer, such as server 104 or client 110 in FIG. 1, in which computer usable code or instructions implementing the processes for embodiments of the present invention may be located.
  • In the depicted example, data processing system 200 employs a hub architecture including north bridge and memory controller hub (MCH) 202 and south bridge and input/output (I/O) controller hub (ICH) 204. Processing unit 206, main memory 208, and graphics processor 210 are connected to north bridge and memory controller hub 202. Graphics processor 210 may be connected to north bridge and memory controller hub 202 through an accelerated graphics port (AGP).
  • In the depicted example, LAN adapter 212 connects to south bridge and I/O controller hub 204. Audio adapter 216, keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224, hard disk drive (HDD) 226, CD-ROM drive 230, universal serial bus (USB) ports and other communications ports 232, and PCI/PCIe devices 234 connect to south bridge and I/O controller hub 204 through bus 238 and bus 240. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM 224 may be, for example, a flash binary input/output system (BIOS).
  • Hard disk drive 226 and CD-ROM drive 230 connect to south bridge and I/O controller hub 204 through bus 240. Hard disk drive 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. Super I/O (SIO) device 236 may be connected to south bridge and I/O controller hub 204.
  • An operating system runs on processing unit 206 and coordinates and provides control of various components within data processing system 200 in FIG. 2. As a client, the operating system may be a commercially available operating system such as Microsoft® Windows® XP (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both). An object-oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 200 (Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both).
  • As a server, data processing system 200 may be, for example, an IBM eServer™ pSeries® computer system, running the Advanced Interactive Executive (AIX®) operating system or LINUX operating system (eServer, pSeries and AIX are trademarks of International Business Machines Corporation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both). Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors in processing unit 206. Alternatively, a single processor system may be employed.
  • Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 226, and may be loaded into main memory 208 for execution by processing unit 206. The processes for embodiments of the present invention are performed by processing unit 206 using computer usable program code, which may be located in a memory such as, for example, main memory 208, read only memory 224, or in one or more peripheral devices 226 and 230.
  • Those of ordinary skill in the art will appreciate that the hardware in FIGS. 1-2 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIGS. 1-2. Also, the processes of the present invention may be applied to a multiprocessor data processing system.
  • In some illustrative examples, data processing system 200 may be a personal digital assistant (PDA), which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data.
  • A bus system may be comprised of one or more buses, such as bus 238 or bus 240 as shown in FIG. 2. Of course the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communications unit may include one or more devices used to transmit and receive data, such as modem 222 or network adapter 212 of FIG. 2. A memory may be, for example, main memory 208, read only memory 224, or a cache such as found in north bridge and memory controller hub 202 in FIG. 2. The depicted examples in FIGS. 1-2 and above-described examples are not meant to imply architectural limitations. For example, data processing system 200 also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.
  • Turning to FIG. 3, typical software architecture, generally designated by reference number 300, for a server-client system is depicted in accordance with a preferred embodiment of the present invention. At the lowest level, operating system 302 is utilized to provide high-level functionality to the user and to other software. Operating system 302 may be implemented in server 104 or client 110 in FIG. 1, in which computer usable code or instructions implementing the processes for embodiments of the present invention may be located. Such an operating system typically includes BIOS. Communication software 304 provides communications through an external port to a network such as the Internet via a physical communications link by either directly invoking operating system functionality or indirectly bypassing the operating system to access the hardware for communications over the network.
  • Application programming interface (API) 306 allows the user of the system, an individual, or a software routine, to invoke system capabilities using a standard consistent interface without concern for how the particular functionality is implemented. Network access software 308 represents any software available for allowing the system to access a network. This access may be to a network, such as a LAN, WAN, or the Internet. With the Internet, this software may include programs, such as Web browsers.
  • Application software 310 represents any number of software applications designed to react to data through a communications port to provide the desired functionality the user seeks. Applications at this level may include those necessary to handle data, video, graphics, photos or text, which can be accessed by users of the Internet. Hypervisor 312 is a layer of software running on a platform that allows multiple instances of operating systems.
  • One of the most interesting areas of usage for the TPM is the realization of a trusted computing architecture within an operating system. The purpose of a trusted computing architecture is for a system to be able to establish trust into another system by learning about the software that has been started on that system. The trusted computing architecture implements the concept of attestation, where attestation is based on the process of measuring all executables, libraries and script files by calculating their individual hash values, and accumulating those in Platform Configuration Registers (PCRs) of the TPM. Using the accumulated hash values along with the list of started programs and their individual measurements, other systems can determine which version of software has been started on a particular system. Attestation itself is performed by a system reporting the current values of the system's PCR registers and providing a signature over the reported values using a system-specific key. The knowledge about running software can be used to establish trust into this system by comparing the individual hash values of the applications with previously measured values stored in a database as well as accumulating the hash values and comparing the results to the values of the reported PCR registers. The fact that measurements initially are taken at the earliest point through the BIOS, followed by the bootloader and the operating system and the fact that the PCR register values are signed, prevents a system from cheating about the list of software that has been started.
  • The usage and functionality of the TPM is defined through the TPM command protocol, which defines the command set a TPM needs to implement and what parameters are passed in each command. The TPM protocol is strictly request/response-based and a TPM processes one command after another in strict sequence.
  • The TPM supports around 120 different commands which have been put into more than 30 functional groups. Some of the most important functionality of the TPM is the support of storage functions, where encrypted information can be tied to the state of a TPM and can only be decrypted once the TPM has been set into that state again, for example after a reboot of the platform. Other functionality comprises the creation of keys and means to migrate keys from one TPM to another. The execution time that some of the TPM commands need greatly varies from one command type to another. Key creation, for example, can be regarded as a command that takes a long time, whereas, for example, the calculation of a hash value completes rather quickly. Since the TPM executes all commands in sequence, no other commands can complete while, for example, a key is created. This is important for multitasking/multiprocessing environments where possibly multiple processes might want to use the system's TPM at one specific instance.
  • Computer systems that have the capability of running multiple operating systems at the same time will also desire to extend support for trusted computing in a similar way as it has been made available for single operating system environments. In such a case, each partition needs to have access to its own virtual TPM instance.
  • For the startup of the first operating system domain running on top of the hypervisor, measurements are handled in the same manner as in the case where an operating system is not running on top of a hypervisor. In this case, the BIOS is regarded as a trusted root and starts taking the measurements. Specifically, the BIOS measures the BIOS code, the contents of the Master Boot Record, and the first stage of the boot loader and accumulates the measurements into several dedicated PCR registers. The bootloader grub is modified to measure the kernel and initial random access memory (RAM) disks, which are provided as parameters in a script file that the bootloader grub reads when the system is booted. Once the operating system starts, all measurements that are made there for libraries, scripting files and executables are accumulated in TPM PCR registers.
  • Every TPM holds state, which consists of volatile and non-volatile data. This includes the endorsement key pair, the storage root key and all other private keys that are held inside the TPM. Also associated with a TPM are a particular owner and the owner's password. In the model of a single operating system on a machine, different machines with their own TPMs are likely to have different owners. Transferring this association between ownership and TPMs to platforms with multiple operating systems means that one instance of a TPM should be associated with one particular partition. Since partitions can be stopped and started, it is necessary to maintain the association between each partition and each instance of a TPM over the lifetime of a TPM or partition configuration.
  • The measurements that each operating system produces are treated in a similar way as those treated on a single-operating system. The difference is that measurements taken by the bootloader do not exist for any partition other than the one that is started first. Since on many systems the first partition will be involved in starting other partitions, it is this partition's responsibility to take any possible measurements and prepare the TPM to reflect them. This means, for example, measuring the kernel image and the initial RAM disk if a Linux® kernel is to be started.
  • A virtual TPM allows for the collection of measurements of multiple operating systems. Each operating system is offered its own instance of a TPM where it can create an endorsement key, storage root key, take ownership of the TPM and apply its own owner password. In an exemplary embodiment of the present invention, the normal command set that a TPM understands is expanded to allow management of additional instances of a TPM, such as, for example, creating new instances, deleting the new instances, preparing the new instances for usage by a partition, and sending commands to new instances indirectly through forwarding messages from other instances. Further, the extension of the command set enables the download of the complete state of a TPM, including non-volatile RAM (NVRAM) areas, and internally held keys into a file and recreating the TPM state in another multi-instance capable TPM and resume operation there.
  • In an exemplary embodiment, a virtual TPM runs on a piece of hardware other than current TPMs that are soldered to the motherboard. One such piece of hardware, for example, could be a microprocessor similar to a current single instance TPM with the difference that the hardware should be faster in order to provide enough speed for concurrent processing of TPM requests.
  • FIG. 4 is a block diagram depicting an example of an architecture for implementing a virtual TPM in accordance with an exemplary embodiment of the present invention. In the case of FIG. 4, hardware 400 provides the only TPM functionality in the system, TPM 402. In the present example, the hardware is the IBM XCrypto™ card. In this case, all attestations from the BIOS, bootloader, and the first started domain, here the TPM domain, DOM-TPM 406, is recorded in instance 0. Instance 0 exists in virtual TPM, vTPM 402 of hardware 400 and is always present. DOM-TPM 406 is a dedicated TPM domain with a minimum of applications running. Therefore, DOM-TPM 406 only handles functions related to the TPM. This reduces the chance of errors occurring, increases reliability and improves the trusted computing base.
  • DOM-TPM 406 contains the back-end driver TPM BE 408. TPM BE 408 communicates with the front-end drivers of the other domains, TPM FE 412, 418, 424 and 430. The back-end driver is aware of which partition a request is coming from since a unique interrupt number has been assigned to each instance of the back-end driver for each front-end communication partner.
  • Instance 0 records the measurements taken by the BIOS, bootloader and TPM domain. Instance 1 records the measurements for domain 0, DOM-0 410, which is started as the second domain. Instance 1 also resides in vTPM 402 of hardware 400. Further instances, all of which will reside in vTPM 402 of hardware 400, are created as needed when additional domains are created. DOM-0 410, DOM-U 416, DOM-U 422 and DOM-U 428 are additional domains all of which are running separate operating systems in their virtualized partition. In the example depicted, each domain has multiple applications, 414, 420, 426 and 432 running. DOM-0 410, DOM-U 416, DOM-U 422 and DOM-U 428 communicate with DOM-TPM 406 through exchange of data over a channel provided by the hypervisor 404. DOM-TPM 406 then communicates with vTPM 402.
  • FIG. 5 is a block diagram depicting an example of an architecture that has a TPM on the motherboard and the virtual TPM functionality as software in the TPM domain in accordance with an exemplary embodiment of the present invention. In an exemplary embodiment of the present invention, TPM 502 is a TPM located on a motherboard. Similar to the architecture of FIG. 4, attestations from the BIOS, bootloader and the TPM domain, DOM-TPM 506, are recorded in TPM 502. DOM-TPM 506 is a dedicated TPM domain with a minimum of applications running. Therefore, DOM-TPM 506 only handles functions related to the TPM. This reduces the chance of errors occurring, increases reliability and improves the trusted computing base.
  • DOM-TPM 506 contains back-end driver TPM BE 508. TPM BE 508 communicates with the front-end drivers of the other domains, TPM FE 514, 524, 534 and 544. The back-end driver is aware of which partition a request is coming from since a unique interrupt number has been assigned to each instance of the back-end driver for each front-end communication partner.
  • However, unlike FIG. 4, future instances and all virtual TPMs, vTPM 510, 520, 530, and 540 are created and exist in DOM-TPM 506. Instance 0 of the vTPM 510 records the measurements for domain 0, DOM-0 512, which is started as the second domain. Further instances and virtual TPMs, vTPM 520, 530 and 540 are created as need when additional domains, such as DOM-U 522, DOM-U 532, and DOM-U 542, are created. Each virtual TPM corresponds to one specific domain. In the present example vTPM 510 corresponds to DOM-0 512, vTPM 520 corresponds to DOM-U 522, vTPM 530 corresponds to DOM-U 532, and vTPM 540 corresponds to DOM-U 542. In the example depicted, each domain has multiple applications, 516, 526, 536, and 546 running. DOM-0 512, DOM-U 522, DOM-U 532, and DOM-U 542 communicate with DOM-TPM 506, and their respective virtual TPMs through exchange of data over a channel provided by the hypervisor 504.
  • The architectures illustrated in FIGS. 4 and 5 both have in common that the TPM domain effectively provides proxy functionality for TPM services, with the difference being that of where the processing of the TPM requests is happening. The final processing or TPM requests in FIG. 4 happens in the external Xcrypto™ card, whereas in FIG. 5 all TPM requests are processed by the TPM software implementation in the vTPM instances 510, 520, 530, and 540. The architecture depicted in FIG. 4 may also be considered as more secure, since all TPM functionality is provided by the hardware.
  • FIG. 6 is a block diagram depicting an example of an architecture with a TPM on the motherboard and the virtual TPM functionality as software in the domain 0 in accordance with an exemplary embodiment of the present invention. In an exemplary embodiment of the present invention, TPM 602 is a TPM located on a motherboard. Unlike the architectures of FIGS. 4 and 5, hypervisor 604 always boots domain 0, DOM-0 606, as the first domain, which forces all virtual TPM functionality into domain 0. DOM-0 606 is not a dedicated TPM domain. DOM-0 606 has other functionality besides handling TPM functions. For example, DOM-0 606 also handles the creation of the other domains, DOM-U 612, DOM-U 622, DOM-U 632, and DOM-U 642.
  • Attestations from the BIOS, bootloader and DOM-0 606, are recorded in TPM 602. DOM-0 606 contains back-end driver TPM BE 608. TPM BE 608 communicates with the front-end drivers of the other domains, TPM FE 614, 624, 634 and 644. The back-end driver is aware of which partition a request is coming from since a unique interrupt number has been assigned to each instance of the back-end driver for each front-end communication partner.
  • Further instances and virtual TPMs, vTPM 610, 620, 630, and 640 are created as needed when user domains, such as DOM-U 612, DOM-U 622, DOM-U 632, and DOM-U 642 are created. Each virtual TPM corresponds to one specific domain. In the present example vTPM 610 corresponds to DOM-U 612, vTPM 620 corresponds to DOM-U 622, vTPM 630 corresponds to DOM-U 632, and vTPM 640 corresponds to DOM-U 642. In the example depicted, each domain has multiple applications, 616, 626, 636 and 646, running. DOM-U 612, DOM-U 622, DOM-U 632, and DOM-U 642 communicate with DOM-0 606, and their respective virtual TPMs through exchange of data over a channel provided by the hypervisor 604.
  • One of the issues with the dynamicity of the virtual TPM is the handling of the endorsement key of each created instance. For today's TPMs that are soldered to the computer's motherboard, the platform manufacturer establishes the endorsement key pair when the machine is built and issues a certificate for the public key part of the endorsement key. The owner of the machine can use the certificate to prove ownership of the machine. The certificate also indicates that the device in which the private key is stored is, in fact, a TPM device which hides the private key from its owner.
  • Since the virtual TPM creates TPMs dynamically, the platform manufacturer can not know the public key parts of all created endorsement keys. However, the manufacturer can certify the public key part of the endorsement key of instance 0 and provide the certificate to the platform owner. Then, to create certificates of individual instances of the TPM, the TPM instance 0 can be used to certify the endorsement keys of its TPM child instances by effectively creating a certificate chain. To realize this in a simple way, the public key part of the endorsement key of every TPM instance can be certified through instance 0 issuing a signature over that endorsement key using its own endorsement key, or attestation identity key (AIK) for signing.
  • Since multiple operating systems will submit their measurements to a multi-instance TPM, it is apparent that strict sequential processing of all individual TPM requests will not allow an operating systems to run efficiently. For example, individual partitions would be blocked until another partition's request is completed. An exemplary embodiment of the present invention solves this problem by creating a pool of threads at the lowest level of the TPM. The pool of threads allows concurrent processing of multiple requests. At any given time only one thread is waiting for a TPM request in the driver. Once it has received a TPM request, it leaves the kernel driver and starts processing that request inside the targeted TPM instance while the next thread has been released to wait for the next request. In an exemplary embodiment of the present invention, this feature is achieved through the usage of thread locks. In another exemplary embodiment of the present invention, through a similar way of using locking mechanisms, only one thread is allowed to write a response to the driver.
  • In an exemplary embodiment of the present invention, the demultiplexing of TPM requests to be able to route them to their intended instance is solved through proper setup of the TPM back-end driver that is located under the virtual TPM. Through domain configuration files, known as virtual machine configuration files, a declaration of what instance of the TPM will be associated with which partition is made. This is configuration information that applies only to the back-end driver and allows the back-end driver to prepend a 4-byte instance number to the TPM request before the TPM request is passed to the TPM running in the user level. The instance number is made available to the back-end driver when the back-end and front-end are setup for communication during partition bootup time. The back-end driver is aware of which partition a request is coming from through the unique interrupt number that has been assigned to the back-end driver for each front-end communication partner. Therefore, as prepending the instance number may be handled more securely on the back end-side, in an exemplary embodiment of the present invention, the instance number is not prepended in the front-end side. Additionally, this prevents accidentally forging the source of a request.
  • In an exemplary embodiment of the present invention, the same kind of channel that is used for a user partition to communicate with a TPM instance may also exist for communication between the privileged domain 0 and the TPM domain. One reason for this is that the extended command set uses the same layout for TPM commands as all the existing TPM commands do. Therefore, this channel can deliver those commands to the TPM. Additionally, downloading the state of a TPM requires a fair amount of byte transfer towards the privileged domain, which can, at least in some architecture, not be accommodated through event channels. The setup procedure of the TPM back-end and front-end drivers serves as an establishment phase for a channel, but not necessarily as an instantiation request for a TPM instance. In an exemplary embodiment of the present invention, an instantiation request for TPMs occur on a higher layer through the exchange of commands using the established channel.
  • Depending on the availability of hardware capable of supporting a virtual TPM, the TPM domain may provide two different sets of functionality. One case is where there is no hardware available to support a virtual TPM. In this case, a software TPM would be hosted in the TPM domain or domain 0 and process the requests from all other domains, as shown in FIGS. 5 and 6 respectively. In the second case, where a hardware TPM is available, on the PCI bus for example, the TPM domain becomes a pure proxy domain for transferring data from the back-end driver to the PCI device driver and vice versa, as shown in FIG. 4. A user-level application would not be necessary in this case.
  • In an exemplary embodiment of the present invention, a higher level tool exists that knows throughout the lifetime of a system which partition is associated with which instance of a TPM. Whenever a new partition is created, a TPM instance should automatically be created and that association established for as long as the partition's definition is kept on the system. When a partition is suspended, the TPM's state could also be suspended and the instance be deleted until either the partition is migrated to a new system or restarted on the local system. In both cases a new instance of a TPM should be created, the TPM state be restored and the partition configuration file updated accordingly. The higher level tool should hide the peculiarities of the partition configuration files from the user.
  • On a broad level, the additional TPM commands can be grouped into two different groups: (i) Virtual TPM Management functions and (ii) Virtual TPM Migration support functions.
  • The first group of functions enables a user to create and delete virtual TPM instances inside a TPM as well as prepare the virtual TPM instances for immediate submission of measurements when a partition starts up. The TPM's PCR registers may be pre-loaded with some initial values from measurements taken about the kernel and the initial RAM disk (initrd). In an exemplary embodiment of the present invention, a virtual TPM has been implemented in such a way that the first instance, the one that is always available, allows the creation of additional virtual TPM instances. The additional TPM instances themselves may be created as privileged instances which may inherit the ability to create additional instances. Using this functionality, a user may effectively build a tree of TPM instances.
  • The second group of TPM functions enables a user to download state information from the TPM and store it into a file and later on recreate the TPM on a different system. The state of the TPM is comprised of NVRAM, keys, volatile and non-volatile flags, established session, and counters. The availability of instances of each type are queried and downloaded, one after another, and their content are stored into a file. When recreating an instance, the contents of the file are read and uploaded to the new instance.
  • In an exemplary embodiment of the present invention, the extended commands are designed such that they pick up on the philosophy of existing TPM commands for authorization using nonces, which are unique session identifiers, and password-keyed hashes, such as the keyed-hash message authentication code (HMAC), for single or double authorization of the owner or keys. This additional security is not a burden on processing power, since the calculation of SHA-1 hashes, which is the most commonly used function in the secure hash algorithm (SHA) family, is comparatively inexpensive, and the additional authorization adds a level of security.
  • Typically, an application using virtual TPM commands will build and send a request to the virtual TPM. The virtual TPM receives the request, processes the request, builds a response and then sends a response to the application. In FIGS. 5 and 6, the request for the virtual TPM is communicated from the front-end driver to the back-end driver through the hypervisor. The back-end driver then routes the request to the proper virtual TPM, as the back-end driver and the virtual TPMs reside in the same domain, DOM-TPM 506 in FIG. 5 or DOM-0 606 in FIG. 6. However, in the architecture illustrated in FIG. 4, the back-end driver passes the request onto the hardware device. The software on the hardware device, which is where the virtual TPMs reside in FIG. 4, directs the requests to the proper virtual TPMs.
  • FIG. 7 is a flowchart illustrating a method for handling TPM commands in accordance with an exemplary embodiment of the present invention. The operation begins with the TPM waiting to receive a command (step 702). Once a command is received, the TPM determines if the command is a “create TPM instance” command (step 704). If the command is the create TPM instance command (a yes output to step 704), then create the TPM instance as explained in greater detail in FIG. 8. If the command is not the create TPM instance command (a no output to step 704), then the TPM determines if the command is a “delete TPM instance” command (step 706).
  • If the command is the delete TPM instance command (a yes output to step 706), then delete the TPM instance as explained in greater detail in FIG. 9. If the command is not the create TPM instance command (a no output to step 706), then the TPM determines if the command is a “setup TPM instance” command (step 708).
  • If the command is the setup TPM instance command (a yes output to step 708), then setup the TPM instance as explained in greater detail in FIG. 10. If the command is not the setup TPM instance command (a no output to step 708), then the TPM determines if the command is a “route embedded command to TPM instance” command (step 710).
  • If the command is the route embedded command to TPM instance command (a yes output to step 710), then route the embedded command to the TPM instance as explained in greater detail in FIG. 11. If the command is not the route embedded command to TPM instance command (a no output to step 710), then the TPM verifies the validity of the command (step 712) and processes it as a normal TPM command, eventually returning to step 702.
  • FIG. 8 is a flowchart illustrating a method for handling a create TPM instance command in accordance with an exemplary embodiment of the present invention. The operation begins by receiving a command to create a TPM instance as the child of instance P, where instance P is the parent instance (step 802). Next the operation verifies if user authentication for the command is valid (step 804). If the user authentication for the command is not valid (a no output to step 804), the appropriate error code is sent as the result value (step 814) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 804), the operation determines if instance P is a descendant of the processing TPM (step 806).
  • If instance P is not a descendant of the processing TPM (a no output to step 806), the appropriate error code is sent as the result value (step 814) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance P is a descendant of the processing TPM (a yes output to step 806), the operation determines if instance P is a privileged instance (step 808). A privileged instance is an instance with permission to create other, child instances.
  • If instance P is not a privileged instance (a no output to step 808), the appropriate error code is sent as the result value (step 814) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance P is a privileged instance (a yes output to step 808), the operation creates a TPM instance as the child of instance P with all the requested privileges (step 810). The child TPM instance inherits the properties of parent instance P. The child TPM is assigned a unique instance handle H. Unique instance handle H is returned to the caller (step 812) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 9 is a flowchart illustrating a method for handling a delete TPM instance command in accordance with an exemplary embodiment of the present invention. The operation begins by receiving a command to delete a TPM instance with the unique instance handle H (step 902). Next the operation verifies if user authentication for the command is valid (step 904). If the user authentication for the command is not valid (a no output to step 904), the appropriate error code is sent as the result value (step 914) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 904), the operation determines if instance H is a descendant of the processing instance P (step 906).
  • If instance H is not a descendant of the processing TPM (a no output to step 906), the appropriate error code is sent as the result value (step 914) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H is a descendant of the processing TPM (a yes output to step 906), the operation determines if instance H has descendants (step 908).
  • An instance may only be deleted if it does not have any children instances that are dependent upon it. If instance H has any descendants (a yes output to step 908), the appropriate error code is sent as the result value (step 914) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H does not have any descendants (a no output to step 908), the operation deletes all data associated with instance H (step 910). The operation deletes all references to instance H from the parent instance P (step 912) and the operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 10 is a flowchart illustrating a method for handling a setup TPM instance command in accordance with an exemplary embodiment of the present invention. To setup a TPM instance means to prepare the instance for usage. In an exemplary embodiment of the present invention, an application in domain 0 sends a sequence of commands to a privileged TPM instance to prepare the virtual TPM instance to accept commands from the operating system, which has a similar effect to the commands that usually the BIOS is sending to the hardware TPM to prepare it for accepting commands from the operating system. In addition to that the application is providing an array of PCR register indices and hash values along with string identifiers. For this command to work, the virtual TPM instance must have been created prior to this step and is uniquely identified through its unique instance handle H. The operation begins by receiving a command to setup a TPM instance with the unique instance handle H (step 1002). Next the operation verifies if user authentication for the command is valid (step 1004). If the user authentication for the command is not valid (a no output to step 1004), the appropriate error code is sent as the result value (step 1014) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 1004), the operation determines if instance H exists (step 1006).
  • If instance H does not exist (a no output to step 1006), the appropriate error code is sent as the result value (step 1014) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H does exist (a yes output to step 1006), the operation determines if instance H is a descendant of the processing instance P (step 1008).
  • If instance H is not a descendant of the processing instance P (a no output to step 1008), the appropriate error code is sent as the result value (step 1014) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H is a descendant of the processing instance P (a yes output to step 1008), the operation processes those actions requested (step 1010). Such processes include running the TPM startup command and enabling and activating the TPM instance H. The operation processes the list of PCR register index values and extends PCR registers with the given hash values (step 1012). The operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 11 is a flowchart illustrating a method for handling to route an embedded command to a virtual TPM instance command in accordance with an exemplary embodiment of the present invention. The operation begins by a privileged TPM receiving a command and determining that this command routes an embedded command to a TPM instance with the unique instance handle H (step 1102). Next the operation verifies if user authentication for the command is valid (step 1104). If the user authentication for the command is not valid (a no output to step 1104), the appropriate error code is sent as the result value (step 1120) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the user authentication for the command is valid (a yes output to step 1104), the operation determines if instance H exists (step 1106).
  • If instance H does not exist (a no output to step 1106), the appropriate error code is sent as the result value (step 1120) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H does exist (a yes output to step 1106), the operation determines if instance H is a descendant of the processing instance P (step 1108).
  • If instance H is not a descendant of the processing instance P (a no output to step 1108), the appropriate error code is sent as the result value (step 1120) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If instance H is a descendant of the processing instance P (a yes output to step 1108), the operation retrieves the embedded command (step 1110). Next the operation determines if the size indicator of the command is valid (step 1112).
  • If the size indicator of the command is not valid (a no output to step 1112), the appropriate error code is sent as the result value (step 1120) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the size indicator of the command is valid (a yes output to step 1112), the operation determines if the embedded command is allowed to be embedded (step 1114).
  • If the embedded command is not allowed to be embedded (a no output to step 1114), the appropriate error code is sent as the result value (step 1120) and the operation returns to step 702 of FIG. 7 to wait for a new command to process. If the embedded command is allowed to be embedded (a yes output to step 1114), the operation processes the embedded command in the target virtual TPM instance as if the command has been sent to it directly (step 1116), which can include recursive handling of the command and determining that yet another layer of embedded command is to be processed, repeating steps 1102 through 1116 until no new embedded commands are found. The operation embeds the response message to the embedded command in the response (step 1118). The operation returns to step 702 of FIG. 7 to wait for a new command to process.
  • FIG. 12 is a block diagram illustrating the communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention. In a hierarchical set of virtual TPMs, allowed communication paths strictly follow the parent-child relationship. The parent always initiates communication with the child and then the child responds. The child never initiates communication to a parent. Only a predecessor may create or delete a child TPM or send a message to a child TPM.
  • TPM instance 0 is the initial TPM instance and it is a privileged instance, meaning it has permission to create, delete and set-up child TPMs. TPM instance 1, TPM instance 2, and TPM instance 3 are child TPM instances of TPM instance 0. TPM instance 4 and TPM instance 5 are child TPM instances of TPM instance 2, which is a privileged TPM instance. Of TPM instance 0's three child TPMs, TPM instance 1 and TPM instance 3 are non-privileged, meaning that the permission of parent TPM instance 0 were not passed onto those TPMS and they cannot create, delete or send messages to child TPM instances. TPM instance 2 is privileged and inherited the permission of TPM instance 0. TPM instance 2 created two child instances of its own, TPM instance 4 and TPM instance 5. TPM instance 5 is non-privileged. TPM instance 4 is privileged and inherited the permissions of TPM instance 2, which inherited the permissions of TPM instance 0. Lines 1202, 1204 and 1206 show the communication that TPM instance 0 can have. TPM instance 0 can only communicate with TPM instance 1, TPM instance 2 or TPM instance 3. Lines 1208 and 1210 show the communication that TPM instance 2 can have. TPM instance 2 can only communicate with TPM instance 4 or TPM instance 5.
  • FIG. 13 is a block diagram illustrating an alternative communication path among a hierarchical set of virtual TPMs in accordance with an exemplary embodiment of the present invention. In another exemplary embodiment of the present invention, any predecessor may create or delete a child and make the child a child of a given parent and send messages to the child. TPM instance 0 is the initial TPM instance and it is a privileged instance, meaning it has permission to create, delete and set-up child TPMs. TPM instance 1, TPM instance 2, and TPM instance 3 are child TPM instances of TPM instance 0. TPM instance 4 and TPM instance 5 are child TPM instances of TPM instance 2, which is a privileged TPM instance. Of TPM instance 0's three child TPMs, TPM instance 1 and TPM instance 3 are non-privileged, meaning that the permission of parent TPM instance 0 were not passed onto those TPMS and they cannot create, delete or communicate with child TPM instances. TPM instance 2 is privileged and inherited the permission of TPM instance 0. TPM instance 2 created two child instances of its own, TPM instance 4 and TPM instance 5. TPM instance 5 is non-privileged. TPM instance 4 is privileged and inherited the permissions of TPM instance 2, which inherited the permissions of TPM instance 0.
  • Lines 1302, 1304, 1306, 1308 and 1310 show the communication that TPM instance 0 can have. As in FIG. 12, TPM instance 0 can communicate with TPM instance 1, TPM instance 2 or TPM instance 3. However, unlike the architecture shown in FIG. 12, TPM instance 0 may also communicate with TPM instance 4 and TPM instance 5, the child TPMs of TPM instance 0's child TPM, TPM instance 2. TPM instance 0 may treat TPM instance 4 and TPM instance 5 as its own child TPMs and communicate directly with them and delete them. Lines 1312 and 1314 show the communication that TPM instance 2 can have. TPM instance 2 can only communicate with TPM instance 4 or TPM instance 5.
  • Thus the present invention provides a method, an apparatus and a computer program product for the dynamic creation and hierarchical organization of trusted platform modules.
  • The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
  • A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
  • The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (19)

1. A computer implemented method for the dynamic creation and hierarchical organization of trusted platform modules, the computer implemented method comprising:
creating a trusted platform module domain, wherein a privileged trusted platform module may dynamically create one or more virtual trusted platform modules in the trusted platform module domain.
2. The computer implemented method of claim 1, wherein each virtual trusted platform module is associated with a specific partition of a plurality of partitions, wherein each partition of the plurality of partitions is associated with an individual operating system.
3. The computer implemented method of claim 1, wherein the trusted platform module domain is a dedicated domain.
4. The computer implemented method of claim 3, wherein creating virtual trusted platform modules is implemented as software in the trusted platform module domain.
5. The computer implemented method of claim 1, further comprising:
creating an endorsement key associated with each virtual trusted platform module.
6. The computer implemented method of claim 2, wherein virtual machine configuration files determine which virtual trusted platform module is associated with a particular partition.
7. The computer implemented method of claim 1, wherein at least one virtual trusted platform module comprises a privileged trusted platform module which may create other virtual trusted platforms modules; and
wherein a virtual trusted platform module comprises a child trusted platform module and wherein either a privileged trusted platform module or a virtual trusted platform module may comprise a parent trusted platform module that may create child trusted platform modules.
8. The computer implemented method of claim 7, wherein a child trusted platform module inherits permissions of a parent trusted platform module.
9. The computer implemented method of claim 7, wherein only an immediately preceding parent trusted platform module may communicate with, delete, set up, or create a child trusted platform module.
10. The computer implemented method of claim 1, further comprising:
deleting a virtual trusted platform module.
11. The computer implemented method of claim 10, wherein a virtual trusted platform module may only be deleted if the virtual trusted platform module does not have any child trusted platform modules.
12. The computer implemented method of claim 1, further comprising:
setting up a virtual trusted platform module for use.
13. The computer implemented method of claim 12, wherein setting up a virtual trusted platform module for use comprises:
sending an array of PCR register indices and hash values of the virtual trusted platform module to a creating trusted platform module, which may either be a virtual trusted platform module or a trusted platform module; and
wherein each hash value of the hash values is used to extend the PCR registers that are referenced through the indices.
14. The computer implemented method of claim 13, further comprising:
storing string identifiers and the array of PCR register indices and hash values in the virtual trusted platform module to form stored information, wherein the stored information is made available to an operating system associated with the virtual trusted platform module.
15. The computer implemented method of claim 1, further comprising:
routing embedded commands to a virtual trusted platform module.
16. The computer implemented method of claim 1, wherein the trusted platform module certifies a public key part of an endorsement key of a virtual trusted platform module by signing over the endorsement key of the virtual trusted platform module using the trusted platform module's own endorsement key, attestation identity key or a general signing key.
17. The computer implemented method of claim 1, further comprising:
creating a plurality of threads, wherein the plurality of threads allow concurrent processing of multiple requests received by the trusted platform module.
18. A computer program product comprising a computer usable medium including computer usable program code for the dynamic creation and hierarchical organization of trusted platform modules, said computer program product comprising:
computer usable program code for creating a trusted platform module domain, wherein a privileged trusted platform module may dynamically create one or more virtual trusted platform modules in the trusted platform module domain.
19. A data processing system for the dynamic creation and hierarchical organization of trusted platform modules, said data processing system comprising:
a storage device, wherein the storage device stores computer usable program code; and
a processor, wherein the processor executes the computer usable program code to create a trusted platform module domain, wherein a privileged trusted platform module may dynamically create one or more virtual trusted platform modules in the trusted platform module domain.
US11/242,673 2005-10-03 2005-10-03 Dynamic creation and hierarchical organization of trusted platform modules Abandoned US20070079120A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/242,673 US20070079120A1 (en) 2005-10-03 2005-10-03 Dynamic creation and hierarchical organization of trusted platform modules
US12/128,952 US8549288B2 (en) 2005-10-03 2008-05-29 Dynamic creation and hierarchical organization of trusted platform modules

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/242,673 US20070079120A1 (en) 2005-10-03 2005-10-03 Dynamic creation and hierarchical organization of trusted platform modules

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/128,952 Continuation US8549288B2 (en) 2005-10-03 2008-05-29 Dynamic creation and hierarchical organization of trusted platform modules

Publications (1)

Publication Number Publication Date
US20070079120A1 true US20070079120A1 (en) 2007-04-05

Family

ID=37903236

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/242,673 Abandoned US20070079120A1 (en) 2005-10-03 2005-10-03 Dynamic creation and hierarchical organization of trusted platform modules
US12/128,952 Expired - Fee Related US8549288B2 (en) 2005-10-03 2008-05-29 Dynamic creation and hierarchical organization of trusted platform modules

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/128,952 Expired - Fee Related US8549288B2 (en) 2005-10-03 2008-05-29 Dynamic creation and hierarchical organization of trusted platform modules

Country Status (1)

Country Link
US (2) US20070079120A1 (en)

Cited By (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101156A1 (en) * 2005-10-31 2007-05-03 Manuel Novoa Methods and systems for associating an embedded security chip with a computer
US20070174600A1 (en) * 2005-12-02 2007-07-26 Microsoft Corporation Interface for communicating physical presence requests
US20070192864A1 (en) * 2006-02-10 2007-08-16 Bryant Eric D Software root of trust
US20070192830A1 (en) * 2006-02-15 2007-08-16 O'connor Dennis M Security module having access limited based upon security level of code seeking access
US20080104673A1 (en) * 2006-09-29 2008-05-01 O'connor Dennis M Architecture for virtual security module
US20080114989A1 (en) * 2006-11-09 2008-05-15 Anbalagan Arun P Trusted Device Having Virtualized Registers
US20080152151A1 (en) * 2006-12-22 2008-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Highly available cryptographic key storage (hacks)
US20090154709A1 (en) * 2007-12-17 2009-06-18 Microsoft Corporation Migration of computer secrets
US20090165117A1 (en) * 2007-12-21 2009-06-25 Tasneem Brutch Methods And Apparatus Supporting Access To Physical And Virtual Trusted Platform Modules
US20090307487A1 (en) * 2006-04-21 2009-12-10 Interdigital Technology Corporation Apparatus and method for performing trusted computing integrity measurement reporting
US20100011200A1 (en) * 2006-05-24 2010-01-14 Rosenan Avner Method and system for defending security application in a user's computer
US20100031325A1 (en) * 2006-12-22 2010-02-04 Virtuallogix Sa System for enabling multiple execution environments to share a device
US20100082984A1 (en) * 2008-09-26 2010-04-01 Microsoft Corporation Protocol-Independent Remote Attestation And Sealing
EP2171633A1 (en) * 2007-06-20 2010-04-07 Nokia Corporation Method for remote message attestation in a communication system
US20100130164A1 (en) * 2006-07-11 2010-05-27 CHOWDHURY Amor Customer Identification and Authentication Procedure for Online Internet Payments using Mobile Phone
GB2466071A (en) * 2008-12-15 2010-06-16 Hewlett Packard Development Co Associating a Signing key with a Software Component of a Computing Platform
US20100153749A1 (en) * 2007-10-03 2010-06-17 Fujitsu Limited Device-access control program, device-access control process, and information processing apparatus for controlling access to device
US20100268812A1 (en) * 2009-04-16 2010-10-21 Dell Products, Lp System and Method of Migrating Virtualized Environments
EP2261832A1 (en) * 2008-02-25 2010-12-15 Panasonic Corporation Information processing device
US20100325414A1 (en) * 2006-10-20 2010-12-23 Siemens Aktiengesellschaft Method and transmitting device for securely creating and sending an electronic message and method and receiving device for securely receiving and processing an electronic message
US20120166795A1 (en) * 2010-12-24 2012-06-28 Wood Matthew D Secure application attestation using dynamic measurement kernels
WO2012093924A1 (en) * 2011-01-07 2012-07-12 Mimos Berhad System and method to provide trusted platform module (tpm) functionalities on a remote server for multiple users
US20130174220A1 (en) * 2011-12-31 2013-07-04 International Business Machines Corporation Secure boot of a data breakout appliance with multiple subsystems at the edge of a mobile data network
US20140033266A1 (en) * 2012-07-24 2014-01-30 Electronics And Telecommunications Research Institute Method and apparatus for providing concealed software execution environment based on virtualization
KR20140016137A (en) * 2012-07-24 2014-02-07 한국전자통신연구원 Method and apparatus for providing concealed software execution environment based on virtualization
US8649770B1 (en) 2012-07-02 2014-02-11 Sprint Communications Company, L.P. Extended trusted security zone radio modem
WO2014025687A2 (en) * 2012-08-10 2014-02-13 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US8667607B2 (en) 2012-07-24 2014-03-04 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
US8712407B1 (en) 2012-04-05 2014-04-29 Sprint Communications Company L.P. Multiple secure elements in mobile electronic device with near field communication capability
US8752140B1 (en) 2012-09-11 2014-06-10 Sprint Communications Company L.P. System and methods for trusted internet domain networking
US8793504B2 (en) 2012-02-22 2014-07-29 International Business Machines Corporation Validating a system with multiple subsystems using trusted platform modules and virtual platform modules
US8837318B2 (en) 2011-09-15 2014-09-16 International Business Machines Corporation Mobile network services in a mobile data network
US8862181B1 (en) 2012-05-29 2014-10-14 Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure
US8863252B1 (en) 2012-07-25 2014-10-14 Sprint Communications Company L.P. Trusted access to third party applications systems and methods
US8881977B1 (en) 2013-03-13 2014-11-11 Sprint Communications Company L.P. Point-of-sale and automated teller machine transactions using trusted mobile access device
US8954588B1 (en) 2012-08-25 2015-02-10 Sprint Communications Company L.P. Reservations in real-time brokering of digital content delivery
US8971192B2 (en) 2011-11-16 2015-03-03 International Business Machines Corporation Data breakout at the edge of a mobile data network
US8984592B1 (en) 2013-03-15 2015-03-17 Sprint Communications Company L.P. Enablement of a trusted security zone authentication for remote mobile device management systems and methods
US8989705B1 (en) 2009-06-18 2015-03-24 Sprint Communications Company L.P. Secure placement of centralized media controller application in mobile access terminal
US9015068B1 (en) 2012-08-25 2015-04-21 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
US9027102B2 (en) 2012-05-11 2015-05-05 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US20150135311A1 (en) * 2010-12-21 2015-05-14 International Business Machines Corporation Virtual machine validation
US9049013B2 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone containers for the protection and confidentiality of trusted service manager data
US9049186B1 (en) * 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone re-provisioning and re-use capability for refurbished mobile devices
US9066230B1 (en) 2012-06-27 2015-06-23 Sprint Communications Company L.P. Trusted policy and charging enforcement function
US9069952B1 (en) 2013-05-20 2015-06-30 Sprint Communications Company L.P. Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory
US9104840B1 (en) 2013-03-05 2015-08-11 Sprint Communications Company L.P. Trusted security zone watermark
US20150229619A1 (en) * 2014-02-07 2015-08-13 Microsoft Corporation Trusted execution within a distributed computing system
JP2015524128A (en) * 2012-06-19 2015-08-20 マイクロソフト コーポレーション Network-based management of protected data sets
US9118655B1 (en) 2014-01-24 2015-08-25 Sprint Communications Company L.P. Trusted display and transmission of digital ticket documentation
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
US9161227B1 (en) 2013-02-07 2015-10-13 Sprint Communications Company L.P. Trusted signaling in long term evolution (LTE) 4G wireless communication
US9171243B1 (en) 2013-04-04 2015-10-27 Sprint Communications Company L.P. System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device
US9183606B1 (en) 2013-07-10 2015-11-10 Sprint Communications Company L.P. Trusted processing location within a graphics processing unit
US9185626B1 (en) 2013-10-29 2015-11-10 Sprint Communications Company L.P. Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning
US9191522B1 (en) 2013-11-08 2015-11-17 Sprint Communications Company L.P. Billing varied service based on tier
US9191388B1 (en) 2013-03-15 2015-11-17 Sprint Communications Company L.P. Trusted security zone communication addressing on an electronic device
US9208339B1 (en) 2013-08-12 2015-12-08 Sprint Communications Company L.P. Verifying Applications in Virtual Environments Using a Trusted Security Zone
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
US9226145B1 (en) 2014-03-28 2015-12-29 Sprint Communications Company L.P. Verification of mobile device integrity during activation
US9230085B1 (en) 2014-07-29 2016-01-05 Sprint Communications Company L.P. Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
US9282898B2 (en) 2012-06-25 2016-03-15 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
CN105426772A (en) * 2015-10-29 2016-03-23 厦门雅迅网络股份有限公司 Method for securely storing root key required by encryption and authentication in FLASH
US9324016B1 (en) 2013-04-04 2016-04-26 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9374363B1 (en) 2013-03-15 2016-06-21 Sprint Communications Company L.P. Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device
US9443088B1 (en) 2013-04-15 2016-09-13 Sprint Communications Company L.P. Protection for multimedia files pre-downloaded to a mobile device
US9454723B1 (en) 2013-04-04 2016-09-27 Sprint Communications Company L.P. Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
US9560519B1 (en) 2013-06-06 2017-01-31 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US20170054566A1 (en) * 2014-02-20 2017-02-23 Phoenix Contact Gmbh & Co. Kg Method and system for creating and checking the validity of device certificates
US9613208B1 (en) 2013-03-13 2017-04-04 Sprint Communications Company L.P. Trusted security zone enhanced with trusted hardware drivers
US9684630B1 (en) * 2012-12-05 2017-06-20 Amazon Technologies, Inc. Provisioning of cryptographic modules
US9779232B1 (en) 2015-01-14 2017-10-03 Sprint Communications Company L.P. Trusted code generation and verification to prevent fraud from maleficent external devices that capture data
US9817992B1 (en) 2015-11-20 2017-11-14 Sprint Communications Company Lp. System and method for secure USIM wireless network access
US9819679B1 (en) 2015-09-14 2017-11-14 Sprint Communications Company L.P. Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers
US9838869B1 (en) 2013-04-10 2017-12-05 Sprint Communications Company L.P. Delivering digital content to a mobile device via a digital rights clearing house
US9838868B1 (en) 2015-01-26 2017-12-05 Sprint Communications Company L.P. Mated universal serial bus (USB) wireless dongles configured with destination addresses
US10282719B1 (en) 2015-11-12 2019-05-07 Sprint Communications Company L.P. Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit
US10454919B2 (en) 2014-02-26 2019-10-22 International Business Machines Corporation Secure component certificate provisioning
US10499249B1 (en) 2017-07-11 2019-12-03 Sprint Communications Company L.P. Data link layer trust signaling in communication network
US20210111892A1 (en) * 2020-12-22 2021-04-15 Anjo Lucas Vahldiek-Oberwagner Scalabe attestation for trusted execution environments

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9418040B2 (en) * 2005-07-07 2016-08-16 Sciencelogic, Inc. Dynamically deployable self configuring distributed network management system
JP2010066931A (en) * 2008-09-09 2010-03-25 Fujitsu Ltd Information processor having load balancing function
US20100161844A1 (en) * 2008-12-23 2010-06-24 Phoenix Technologies Ltd DMA compliance by remapping in virtualization
JP5287980B2 (en) * 2009-03-31 2013-09-11 富士通株式会社 Information processing device, information processing device activation control method, and activation program
US8966475B2 (en) * 2009-08-10 2015-02-24 Novell, Inc. Workload management for heterogeneous hosts in a computing system environment
US8250379B2 (en) * 2009-10-13 2012-08-21 Microsoft Corporation Secure storage of temporary secrets
US8375437B2 (en) * 2010-03-30 2013-02-12 Microsoft Corporation Hardware supported virtualized cryptographic service
US8589702B2 (en) 2010-05-28 2013-11-19 Dell Products, Lp System and method for pre-boot authentication of a secure client hosted virtualization in an information handling system
US8719557B2 (en) 2010-05-28 2014-05-06 Dell Products, Lp System and method for secure client hosted virtualization in an information handling system
US9134990B2 (en) 2010-05-28 2015-09-15 Dell Products, Lp System and method for implementing a secure client hosted virtualization service layer in an information handling system
US8990584B2 (en) 2010-05-28 2015-03-24 Dell Products, Lp System and method for supporting task oriented devices in a client hosted virtualization system
US8938774B2 (en) 2010-05-28 2015-01-20 Dell Products, Lp System and method for I/O port assignment and security policy application in a client hosted virtualization system
US8458490B2 (en) 2010-05-28 2013-06-04 Dell Products, Lp System and method for supporting full volume encryption devices in a client hosted virtualization system
US8751781B2 (en) 2010-05-28 2014-06-10 Dell Products, Lp System and method for supporting secure subsystems in a client hosted virtualization system
US8527761B2 (en) 2010-05-28 2013-09-03 Dell Products, Lp System and method for fuse enablement of a secure client hosted virtualization in an information handling system
US8639923B2 (en) 2010-05-28 2014-01-28 Dell Products, Lp System and method for component authentication of a secure client hosted virtualization in an information handling system
EP2619701B1 (en) * 2010-09-22 2015-04-22 International Business Machines Corporation Attesting use of an interactive component during a boot process
US8869264B2 (en) 2010-10-01 2014-10-21 International Business Machines Corporation Attesting a component of a system during a boot process
CN103201747B (en) 2010-11-18 2015-11-25 国际商业机器公司 For verifying the method and apparatus of multiple data handling system
US20120131334A1 (en) * 2010-11-18 2012-05-24 International Business Machines Corporation Method for Attesting a Plurality of Data Processing Systems
US9164924B2 (en) 2011-09-13 2015-10-20 Facebook, Inc. Software cryptoprocessor
US20140006776A1 (en) * 2012-06-29 2014-01-02 Mark Scott-Nash Certification of a virtual trusted platform module
US9477603B2 (en) 2013-09-05 2016-10-25 Facebook, Inc. System and method for partitioning of memory units into non-conflicting sets
US9983894B2 (en) 2013-09-25 2018-05-29 Facebook, Inc. Method and system for providing secure system execution on hardware supporting secure application execution
US10049048B1 (en) 2013-10-01 2018-08-14 Facebook, Inc. Method and system for using processor enclaves and cache partitioning to assist a software cryptoprocessor
US9747450B2 (en) * 2014-02-10 2017-08-29 Facebook, Inc. Attestation using a combined measurement and its constituent measurements
US9734092B2 (en) 2014-03-19 2017-08-15 Facebook, Inc. Secure support for I/O in software cryptoprocessor
US20170249464A1 (en) * 2015-05-28 2017-08-31 Telefonaktiebolaget Lm Ericsson (Publ) METHOD FOR ENABLING SIMULTANEOUS CONTROL OF A PLURALITY OF TPMs AND RELATED COMPONENTS
US10528739B2 (en) 2016-04-20 2020-01-07 Sophos Limited Boot security
US11086932B1 (en) 2020-03-18 2021-08-10 Amazon Technologies, Inc. Asset-level management of media recording in cloud DVR systems
US11924336B1 (en) * 2021-06-25 2024-03-05 Amazon Technologies, Inc. Cryptographic artifact generation using virtualized security modules

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110106A1 (en) * 2001-12-10 2003-06-12 Sanjay Deshpande System and method for enabling content providers in a financial services organization to self-publish content
US20050086509A1 (en) * 2003-10-17 2005-04-21 Kumar Ranganathan Extended trusted computing base
US20050135379A1 (en) * 2003-07-02 2005-06-23 Callaway Edgar H.Jr. Methods and apparatuses for routing data in a personal area network
US20050138370A1 (en) * 2003-12-23 2005-06-23 Goud Gundrala D. Method and system to support a trusted set of operational environments using emulated trusted hardware
US20050149722A1 (en) * 2003-12-30 2005-07-07 Intel Corporation Session key exchange
US20060020781A1 (en) * 2004-06-24 2006-01-26 Scarlata Vincent R Method and apparatus for providing secure virtualization of a trusted platform module
US20060256108A1 (en) * 2005-05-13 2006-11-16 Scaralata Vincent R Method and apparatus for remotely provisioning software-based security coprocessors

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7664965B2 (en) * 2004-04-29 2010-02-16 International Business Machines Corporation Method and system for bootstrapping a trusted server having redundant trusted platform modules
US7480804B2 (en) * 2004-04-29 2009-01-20 International Business Machines Corporation Method and system for hierarchical platform boot measurements in a trusted computing environment
US7484091B2 (en) * 2004-04-29 2009-01-27 International Business Machines Corporation Method and system for providing a trusted platform module in a hypervisor environment
US7380119B2 (en) * 2004-04-29 2008-05-27 International Business Machines Corporation Method and system for virtualization of trusted platform modules
US20060026418A1 (en) * 2004-07-29 2006-02-02 International Business Machines Corporation Method, apparatus, and product for providing a multi-tiered trust architecture
US20060026422A1 (en) * 2004-07-29 2006-02-02 International Business Machines Corporation Method, apparatus, and product for providing a backup hardware trusted platform module in a hypervisor environment
US7478246B2 (en) * 2004-07-29 2009-01-13 International Business Machines Corporation Method for providing a scalable trusted platform module in a hypervisor environment
US7484099B2 (en) * 2004-07-29 2009-01-27 International Business Machines Corporation Method, apparatus, and product for asserting physical presence with a trusted platform module in a hypervisor environment
US7603707B2 (en) * 2005-06-30 2009-10-13 Intel Corporation Tamper-aware virtual TPM
US8549592B2 (en) * 2005-07-12 2013-10-01 International Business Machines Corporation Establishing virtual endorsement credentials for dynamically generated endorsement keys in a trusted computing platform

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110106A1 (en) * 2001-12-10 2003-06-12 Sanjay Deshpande System and method for enabling content providers in a financial services organization to self-publish content
US20050135379A1 (en) * 2003-07-02 2005-06-23 Callaway Edgar H.Jr. Methods and apparatuses for routing data in a personal area network
US20050086509A1 (en) * 2003-10-17 2005-04-21 Kumar Ranganathan Extended trusted computing base
US20050138370A1 (en) * 2003-12-23 2005-06-23 Goud Gundrala D. Method and system to support a trusted set of operational environments using emulated trusted hardware
US20050149722A1 (en) * 2003-12-30 2005-07-07 Intel Corporation Session key exchange
US20060020781A1 (en) * 2004-06-24 2006-01-26 Scarlata Vincent R Method and apparatus for providing secure virtualization of a trusted platform module
US20060256108A1 (en) * 2005-05-13 2006-11-16 Scaralata Vincent R Method and apparatus for remotely provisioning software-based security coprocessors

Cited By (130)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101156A1 (en) * 2005-10-31 2007-05-03 Manuel Novoa Methods and systems for associating an embedded security chip with a computer
US20070174600A1 (en) * 2005-12-02 2007-07-26 Microsoft Corporation Interface for communicating physical presence requests
US20070192864A1 (en) * 2006-02-10 2007-08-16 Bryant Eric D Software root of trust
US7870399B2 (en) * 2006-02-10 2011-01-11 Arxan Defense Systems Software trusted platform module and application security wrapper
US20070192830A1 (en) * 2006-02-15 2007-08-16 O'connor Dennis M Security module having access limited based upon security level of code seeking access
US8566606B2 (en) * 2006-04-21 2013-10-22 Interdigital Technology Corporation Apparatus and method for performing trusted computing integrity measurement reporting
US20090307487A1 (en) * 2006-04-21 2009-12-10 Interdigital Technology Corporation Apparatus and method for performing trusted computing integrity measurement reporting
US9424430B2 (en) * 2006-05-24 2016-08-23 Safend Ltd. Method and system for defending security application in a user's computer
US20100011200A1 (en) * 2006-05-24 2010-01-14 Rosenan Avner Method and system for defending security application in a user's computer
US20100130164A1 (en) * 2006-07-11 2010-05-27 CHOWDHURY Amor Customer Identification and Authentication Procedure for Online Internet Payments using Mobile Phone
US8099077B2 (en) * 2006-07-11 2012-01-17 Ultra Proizvodnja Elektronskih Naprav D.O.O. Customer identification and authentication procedure for online internet payments using mobile phone
US8479264B2 (en) * 2006-09-29 2013-07-02 Micron Technology, Inc. Architecture for virtual security module
US9141810B2 (en) 2006-09-29 2015-09-22 Micron Technology, Inc. Architecture for virtual security module
US20080104673A1 (en) * 2006-09-29 2008-05-01 O'connor Dennis M Architecture for virtual security module
US8560844B2 (en) * 2006-10-20 2013-10-15 Siemens Aktiengesellschaft Method and transmitting device for securely creating and sending an electronic message and method and receiving device for securely receiving and processing an electronic message
US20100325414A1 (en) * 2006-10-20 2010-12-23 Siemens Aktiengesellschaft Method and transmitting device for securely creating and sending an electronic message and method and receiving device for securely receiving and processing an electronic message
US20080114989A1 (en) * 2006-11-09 2008-05-15 Anbalagan Arun P Trusted Device Having Virtualized Registers
US9171161B2 (en) * 2006-11-09 2015-10-27 International Business Machines Corporation Trusted device having virtualized registers
US8996864B2 (en) * 2006-12-22 2015-03-31 Virtuallogix Sa System for enabling multiple execution environments to share a device
US20100031325A1 (en) * 2006-12-22 2010-02-04 Virtuallogix Sa System for enabling multiple execution environments to share a device
US8385551B2 (en) * 2006-12-22 2013-02-26 Telefonaktiebolaget L M Ericsson (Publ) Highly available cryptographic key storage (HACKS)
US20080152151A1 (en) * 2006-12-22 2008-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Highly available cryptographic key storage (hacks)
EP2171633A1 (en) * 2007-06-20 2010-04-07 Nokia Corporation Method for remote message attestation in a communication system
EP2171633A4 (en) * 2007-06-20 2014-12-24 Nokia Corp Method for remote message attestation in a communication system
US20100153749A1 (en) * 2007-10-03 2010-06-17 Fujitsu Limited Device-access control program, device-access control process, and information processing apparatus for controlling access to device
US8208637B2 (en) 2007-12-17 2012-06-26 Microsoft Corporation Migration of computer secrets
US20090154709A1 (en) * 2007-12-17 2009-06-18 Microsoft Corporation Migration of computer secrets
US20090165117A1 (en) * 2007-12-21 2009-06-25 Tasneem Brutch Methods And Apparatus Supporting Access To Physical And Virtual Trusted Platform Modules
US8584229B2 (en) * 2007-12-21 2013-11-12 Intel Corporation Methods and apparatus supporting access to physical and virtual trusted platform modules
EP2261832A1 (en) * 2008-02-25 2010-12-15 Panasonic Corporation Information processing device
JP5411122B2 (en) * 2008-02-25 2014-02-12 パナソニック株式会社 Information processing device
US20100325628A1 (en) * 2008-02-25 2010-12-23 Tomoyuki Haga Information processing device
EP2261832A4 (en) * 2008-02-25 2012-09-26 Panasonic Corp Information processing device
US8161285B2 (en) * 2008-09-26 2012-04-17 Microsoft Corporation Protocol-Independent remote attestation and sealing
US20100082984A1 (en) * 2008-09-26 2010-04-01 Microsoft Corporation Protocol-Independent Remote Attestation And Sealing
GB2466071B (en) * 2008-12-15 2013-11-13 Hewlett Packard Development Co Associating a signing key with a software component of a computing platform
GB2466071A (en) * 2008-12-15 2010-06-16 Hewlett Packard Development Co Associating a Signing key with a Software Component of a Computing Platform
US9361462B2 (en) 2008-12-15 2016-06-07 Hewlett Packard Enterprise Development Lp Associating a signing key with a software component of a computing platform
US20100161998A1 (en) * 2008-12-15 2010-06-24 Liqun Chen Associating a Signing key with a Software Component of a Computing Platform
US8359386B2 (en) 2009-04-16 2013-01-22 Dell Products, Lp System and method of migrating virtualized environments
US20100268812A1 (en) * 2009-04-16 2010-10-21 Dell Products, Lp System and Method of Migrating Virtualized Environments
US8989705B1 (en) 2009-06-18 2015-03-24 Sprint Communications Company L.P. Secure placement of centralized media controller application in mobile access terminal
US9202062B2 (en) * 2010-12-21 2015-12-01 International Business Machines Corporation Virtual machine validation
US20150135311A1 (en) * 2010-12-21 2015-05-14 International Business Machines Corporation Virtual machine validation
US20120166795A1 (en) * 2010-12-24 2012-06-28 Wood Matthew D Secure application attestation using dynamic measurement kernels
US9087196B2 (en) * 2010-12-24 2015-07-21 Intel Corporation Secure application attestation using dynamic measurement kernels
WO2012093924A1 (en) * 2011-01-07 2012-07-12 Mimos Berhad System and method to provide trusted platform module (tpm) functionalities on a remote server for multiple users
US9014023B2 (en) 2011-09-15 2015-04-21 International Business Machines Corporation Mobile network services in a mobile data network
US8837318B2 (en) 2011-09-15 2014-09-16 International Business Machines Corporation Mobile network services in a mobile data network
US9042302B2 (en) 2011-11-16 2015-05-26 International Business Machines Corporation Data breakout at the edge of a mobile data network
US8971192B2 (en) 2011-11-16 2015-03-03 International Business Machines Corporation Data breakout at the edge of a mobile data network
US8782387B2 (en) 2011-12-31 2014-07-15 International Business Machines Corporation Secure boot of a data breakout appliance with multiple subsystems at the edge of a mobile data network
US8776182B2 (en) * 2011-12-31 2014-07-08 International Business Machines Corporation Secure boot of a data breakout appliance with multiple subsystems at the edge of a mobile data network
US20130174220A1 (en) * 2011-12-31 2013-07-04 International Business Machines Corporation Secure boot of a data breakout appliance with multiple subsystems at the edge of a mobile data network
US8793504B2 (en) 2012-02-22 2014-07-29 International Business Machines Corporation Validating a system with multiple subsystems using trusted platform modules and virtual platform modules
US20150006883A1 (en) * 2012-02-22 2015-01-01 International Business Machines Corporation VALlDATING A SYSTEM WITH MULTIPLE SUBSYSTEMS USING TRUSTED PLATFORM MODULES AND VIRTUAL PLATFORM MODULES
US9215071B2 (en) 2012-02-22 2015-12-15 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Validating a system with multiple subsystems using trusted platform modules and virtual platform modules
US8712407B1 (en) 2012-04-05 2014-04-29 Sprint Communications Company L.P. Multiple secure elements in mobile electronic device with near field communication capability
US9027102B2 (en) 2012-05-11 2015-05-05 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US9906958B2 (en) 2012-05-11 2018-02-27 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US8862181B1 (en) 2012-05-29 2014-10-14 Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure
JP2015524128A (en) * 2012-06-19 2015-08-20 マイクロソフト コーポレーション Network-based management of protected data sets
US9282898B2 (en) 2012-06-25 2016-03-15 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
US10154019B2 (en) 2012-06-25 2018-12-11 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
US9066230B1 (en) 2012-06-27 2015-06-23 Sprint Communications Company L.P. Trusted policy and charging enforcement function
US8649770B1 (en) 2012-07-02 2014-02-11 Sprint Communications Company, L.P. Extended trusted security zone radio modem
US9210576B1 (en) * 2012-07-02 2015-12-08 Sprint Communications Company L.P. Extended trusted security zone radio modem
US20140033266A1 (en) * 2012-07-24 2014-01-30 Electronics And Telecommunications Research Institute Method and apparatus for providing concealed software execution environment based on virtualization
US8667607B2 (en) 2012-07-24 2014-03-04 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
KR20140016137A (en) * 2012-07-24 2014-02-07 한국전자통신연구원 Method and apparatus for providing concealed software execution environment based on virtualization
KR102063576B1 (en) * 2012-07-24 2020-01-10 한국전자통신연구원 Method and apparatus for providing concealed software execution environment based on virtualization
US9268959B2 (en) 2012-07-24 2016-02-23 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
US8863252B1 (en) 2012-07-25 2014-10-14 Sprint Communications Company L.P. Trusted access to third party applications systems and methods
WO2014025687A2 (en) * 2012-08-10 2014-02-13 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US9183412B2 (en) * 2012-08-10 2015-11-10 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
WO2014025687A3 (en) * 2012-08-10 2014-07-24 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US20140047548A1 (en) * 2012-08-10 2014-02-13 Sprint Communications Company L.P. Systems and Methods for Provisioning and Using Multiple Trusted Security Zones on an Electronic Device
US9811672B2 (en) 2012-08-10 2017-11-07 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US8954588B1 (en) 2012-08-25 2015-02-10 Sprint Communications Company L.P. Reservations in real-time brokering of digital content delivery
US9384498B1 (en) 2012-08-25 2016-07-05 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US9015068B1 (en) 2012-08-25 2015-04-21 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
US8752140B1 (en) 2012-09-11 2014-06-10 Sprint Communications Company L.P. System and methods for trusted internet domain networking
US9684630B1 (en) * 2012-12-05 2017-06-20 Amazon Technologies, Inc. Provisioning of cryptographic modules
US9161227B1 (en) 2013-02-07 2015-10-13 Sprint Communications Company L.P. Trusted signaling in long term evolution (LTE) 4G wireless communication
US9769854B1 (en) 2013-02-07 2017-09-19 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US9104840B1 (en) 2013-03-05 2015-08-11 Sprint Communications Company L.P. Trusted security zone watermark
US9613208B1 (en) 2013-03-13 2017-04-04 Sprint Communications Company L.P. Trusted security zone enhanced with trusted hardware drivers
US8881977B1 (en) 2013-03-13 2014-11-11 Sprint Communications Company L.P. Point-of-sale and automated teller machine transactions using trusted mobile access device
US9049013B2 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone containers for the protection and confidentiality of trusted service manager data
US9049186B1 (en) * 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone re-provisioning and re-use capability for refurbished mobile devices
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
US9191388B1 (en) 2013-03-15 2015-11-17 Sprint Communications Company L.P. Trusted security zone communication addressing on an electronic device
US8984592B1 (en) 2013-03-15 2015-03-17 Sprint Communications Company L.P. Enablement of a trusted security zone authentication for remote mobile device management systems and methods
US9374363B1 (en) 2013-03-15 2016-06-21 Sprint Communications Company L.P. Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device
US9712999B1 (en) 2013-04-04 2017-07-18 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9454723B1 (en) 2013-04-04 2016-09-27 Sprint Communications Company L.P. Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device
US9324016B1 (en) 2013-04-04 2016-04-26 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9171243B1 (en) 2013-04-04 2015-10-27 Sprint Communications Company L.P. System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device
US9838869B1 (en) 2013-04-10 2017-12-05 Sprint Communications Company L.P. Delivering digital content to a mobile device via a digital rights clearing house
US9443088B1 (en) 2013-04-15 2016-09-13 Sprint Communications Company L.P. Protection for multimedia files pre-downloaded to a mobile device
US9069952B1 (en) 2013-05-20 2015-06-30 Sprint Communications Company L.P. Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory
US9949304B1 (en) 2013-06-06 2018-04-17 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
US9560519B1 (en) 2013-06-06 2017-01-31 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
US9183606B1 (en) 2013-07-10 2015-11-10 Sprint Communications Company L.P. Trusted processing location within a graphics processing unit
US9208339B1 (en) 2013-08-12 2015-12-08 Sprint Communications Company L.P. Verifying Applications in Virtual Environments Using a Trusted Security Zone
US9185626B1 (en) 2013-10-29 2015-11-10 Sprint Communications Company L.P. Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning
US9191522B1 (en) 2013-11-08 2015-11-17 Sprint Communications Company L.P. Billing varied service based on tier
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
US9118655B1 (en) 2014-01-24 2015-08-25 Sprint Communications Company L.P. Trusted display and transmission of digital ticket documentation
US9792427B2 (en) * 2014-02-07 2017-10-17 Microsoft Technology Licensing, Llc Trusted execution within a distributed computing system
US20150229619A1 (en) * 2014-02-07 2015-08-13 Microsoft Corporation Trusted execution within a distributed computing system
US10841102B2 (en) * 2014-02-20 2020-11-17 Phoenix Contact Gmbh & Co. Kg Method and system for creating and checking the validity of device certificates
US20210044441A1 (en) * 2014-02-20 2021-02-11 Phoenix Contact Gmbh & Co. Kg Method and system for creating and checking the validity of device certificates
US11743054B2 (en) * 2014-02-20 2023-08-29 Phoenix Contact Gmbh & Co. Kg Method and system for creating and checking the validity of device certificates
US20170054566A1 (en) * 2014-02-20 2017-02-23 Phoenix Contact Gmbh & Co. Kg Method and system for creating and checking the validity of device certificates
US10454919B2 (en) 2014-02-26 2019-10-22 International Business Machines Corporation Secure component certificate provisioning
US9226145B1 (en) 2014-03-28 2015-12-29 Sprint Communications Company L.P. Verification of mobile device integrity during activation
US9230085B1 (en) 2014-07-29 2016-01-05 Sprint Communications Company L.P. Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
US9779232B1 (en) 2015-01-14 2017-10-03 Sprint Communications Company L.P. Trusted code generation and verification to prevent fraud from maleficent external devices that capture data
US9838868B1 (en) 2015-01-26 2017-12-05 Sprint Communications Company L.P. Mated universal serial bus (USB) wireless dongles configured with destination addresses
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
US9819679B1 (en) 2015-09-14 2017-11-14 Sprint Communications Company L.P. Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers
CN105426772A (en) * 2015-10-29 2016-03-23 厦门雅迅网络股份有限公司 Method for securely storing root key required by encryption and authentication in FLASH
US10282719B1 (en) 2015-11-12 2019-05-07 Sprint Communications Company L.P. Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit
US10311246B1 (en) 2015-11-20 2019-06-04 Sprint Communications Company L.P. System and method for secure USIM wireless network access
US9817992B1 (en) 2015-11-20 2017-11-14 Sprint Communications Company Lp. System and method for secure USIM wireless network access
US10499249B1 (en) 2017-07-11 2019-12-03 Sprint Communications Company L.P. Data link layer trust signaling in communication network
US20210111892A1 (en) * 2020-12-22 2021-04-15 Anjo Lucas Vahldiek-Oberwagner Scalabe attestation for trusted execution environments

Also Published As

Publication number Publication date
US8549288B2 (en) 2013-10-01
US20080235804A1 (en) 2008-09-25

Similar Documents

Publication Publication Date Title
US8549288B2 (en) Dynamic creation and hierarchical organization of trusted platform modules
De Benedictis et al. Integrity verification of Docker containers for a lightweight cloud environment
EP3387580B1 (en) Chained security systems
US7836299B2 (en) Virtualization of software configuration registers of the TPM cryptographic processor
US7478246B2 (en) Method for providing a scalable trusted platform module in a hypervisor environment
US11050844B2 (en) User controlled hardware validation
US8024564B2 (en) Automating configuration of software applications
US7444670B2 (en) Method and apparatus for migrating a virtual TPM instance and preserving uniqueness and completeness of the instance
US8151262B2 (en) System and method for reporting the trusted state of a virtual machine
JP4732513B2 (en) Method and apparatus for providing a software-based security coprocessor
US10007534B2 (en) Methods and apparatus to manage asset capabilities in a computing environment using a common agent framework
JP5957004B2 (en) System, method, computer program product, and computer program for providing validation that a trusted host environment is compliant with virtual machine (VM) requirements
US20200028848A1 (en) Secure access to application instances in a multi-user, multi-tenant computing environment
US7856653B2 (en) Method and apparatus to protect policy state information during the life-time of virtual machines
US9639691B2 (en) Dynamic database and API-accessible credentials data store
JP7397557B2 (en) Secure Execution Guest Owner Environment Control
CN107704308B (en) Virtual platform vTPM management system, trust chain construction method and device, and storage medium
US11847253B2 (en) Efficient launching of trusted execution environments
WO2022271373A1 (en) Secure computing mechanism
JP2018523930A (en) Secure computing environment
JP2023015177A (en) Reduction of latency of hardware trusted execution environments
US20230030816A1 (en) Security broker for consumers of tee-protected services
US20230034725A1 (en) Security broker with consumer proxying for tee-protected services
US7913074B2 (en) Securely launching encrypted operating systems
aw Ideler Cryptography as a service in a cloud computing environment

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BADE, STEVEN A.;BERGER, STEFAN;GOLDMAN, KENNETH ALAN;AND OTHERS;REEL/FRAME:016918/0308;SIGNING DATES FROM 20050921 TO 20051003

STCB Information on status: application discontinuation

Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION