text:
Police Briefs 06-05-2013
by Journal Staff • June 5, 2013 • 0 Comments
Bernie Sanchez, 29, of 55 Cliff Ave., Winthrop, was arrested on charges of operating a motor vehicle while under the influence of liquor and reckless operation of a motor vehicle.
Ruben Rodriguez, 33, of 172 Hichborn St., was arrested on charges of two counts of assault & battery.
Daniel G. Moran, 46, of 80 American Legion Highway, was arrested on an outstanding warrant.
Seth William Cromwell, 30, of Salem, was arrested on charges of assault & battery by means of a dangerous weapon, possession of a firearm without a license, committing a firearms violation after two prior violent or drug crimes, possession of ammunition without an FID card, discharging a firearm within 500 feet of a dwelling, and possession of a firearm in the commission of a felony.
David Bryan, 50, of Everett, was arrested on an outstanding warrant.
William A. Amaya, 28, of Chelsea, was arrested on a charge of larceny of property over $250.
Donald J. Leach, 49, of East Boston, was arrested on a charge of shoplifting.
Dana A. Conigliaro, 55, of East Boston, was arrested on charges of operating a motor vehicle while under the influence of liquor, reckless operation of a motor vehicle, and leaving the scene of an accident after causing property damage.
Juan David Gonzalez, 27, of 128 Yeamans St., was arrested on a charge of assault by means of a dangerous weapon.
Courtney Wilcox, 24, of Everett, was arrested on an outstanding warrant.
Wilfred E. Couchon, 32, of Dorchester, was arrested on an outstanding warrant.
William E. Ginepra, 36, of 895 Broadway, was arrested on an outstanding warrant and on a charge of assault & battery by means of a dangerous weapon.
Steven P. Porix, 22, of Jamaica Plain, was arrested on charges of reckless operation of a motor vehicle, failing to stop for a police officer, and operating a motor vehicle with a suspended license. He also was cited for the civil motor vehicle infraction of failing to stop for a traffic control sign or signal.
Angel M. Rivera, 59, of 541 Beach St., was arrested on an outstanding warrant and on charges of assault and making a threat to commit a crime.
Robert F. Ventullo, 25, of Lynn, was arrested on an outstanding warrant.
Janette Jamison, 52, of 250 Broadway, was arrested on an outstanding warrant.
Latonya Jamison, 44, of 250 Broadway, was arrested on an outstanding warrant.
Michael P. Buonopane, 32, 198 Bellingham Ave., was arrested on a charge of being rude & disorderly in violation of the city ordinance.
Robinson A. Adams, 32, of East Boston, was arrested on an outstanding warrant.
← Lady Patriots Bid Farewell to Hill Park in Style in 3-2 Win
Farewell to Hill Park →


text:
US9467430B2 - Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware - Google Patents
Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware Download PDF
computing device
Ned M. Smith
George W. Cox
Adi Shaliv
Intel Corp
2012-09-28 Priority to US13/631,562 priority Critical patent/US8954735B2/en
2015-02-10 Application filed by Intel Corp filed Critical Intel Corp
230000004224 protection Effects 0 description title 3
238000003860 storage Methods 0 claims description 23
230000004044 response Effects 0 claims description 20
230000002146 bilateral Effects 0 abstract description 11
239000002609 media Substances 0 claims description 9
239000011162 core materials Substances 0 claims description 7
230000002093 peripheral Effects 0 description 16
230000000977 initiatory Effects 0 description 6
230000001815 facial Effects 0 description 2
210000000554 Iris Anatomy 0 description 1
229930002945 all-trans-retinaldehyde Natural products 0 description 1
230000003993 interaction Effects 0 description 1
238000005192 partition Methods 0 description 1
230000002085 persistent Effects 0 description 1
239000011604 retinal Substances 0 description 1
230000002207 retinal Effects 0 description 1
H04L63/00—Network architectures or network communication protocols for network security
H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
G—PHYSICS
G06—COMPUTING; CALCULATING; COUNTING
G06F—ELECTRIC DIGITAL DATA PROCESSING
G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F21/60—Protecting data
G06F21/602—Providing cryptographic facilities or services
H04L63/08—Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
H04L63/0861—Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using biometrical features, e.g. fingerprint, retina-scan
H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
H04L9/3231—Biological data, e.g. fingerprint, voice or retina
G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F2221/2149—Restricted operating environment
H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
H04L2209/12—Details relating to cryptographic hardware or logic circuitry
H04L2209/127—Trusted platform modules [TPM]
A method and device for securely provisioning trust anchors includes generating a database wrapper key as a function of computing device hardware. The database wrapper key encrypts a key database when it is not in use by a trusted execution environment and may be generated using a Physical Unclonable Function (PUF). A local computing device establishes a secure connection and security protocols with a remote computing device. In establishing the secure connection, the local computing device and remote computing device may exchange and/or authenticate cryptographic keys, including Enhanced Privacy Identification (EPID) keys, and establish a session key and device identifier(s). One or more trust anchors are then provisioned depending on whether unilateral, bilateral, or multilateral trust is established. The local computing device may act as a group or domain controller in establishing multilateral trust. Any of the devices may also require user presence to be verified.
CROSS-REFERENCE TO RELATED APPLICATION
The present application is a continuation application of U.S. application Ser. No. 13/631,562, entitled "DEVICE, METHOD, AND SYSTEM FOR SECURE TRUST ANCHOR PROVISIONING AND PROTECTION USING TAMPER-RESISTANT HARDWARE," which was filed on Sep. 28, 2012.
Developers have implemented various protocols for ensuring the security of information. Asymmetric cryptographic systems are used for authentication purposes and to exchange keys between entities. Additionally, public key certificates may be issued by, for example, a certificate authority to verify the authenticity of a particular entity's key signature or public key. Public Key Infrastructure (PKI) schemes are implemented in this way and a PKI validation path terminates at a trusted public key known as a trust anchor. Oftentimes, the public key of a certificate authority (CA) is such a trust anchor. PKI schemes rely on the trustworthiness and meticulousness of the certificate authority to ensure that the trust anchor is valid.
Entities interacting with one another sometimes require that their identities be kept secret from each other. In such circumstances, PKI schemes are inappropriate but other schemes may be used. For example, direct anonymous attestation and Enhanced Privacy Identification allow each entity to remain anonymous in an interaction. However, when a certificate authority or other third party is not used to establish a trust anchor, the entities must establish a trust anchor among themselves. In doing so, one or more of the entities may store public keys. If malware is able to modify or introduce new public keys to the key database of an entity, then an adversary may be able to induce the entity into trusting it. As such, in some implementations, public keys should be kept as safe as private keys to ensure optimal security.
The concepts described herein are illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements.
FIG. 1 is a simplified block diagram of at least one embodiment of a system for securely provisioning one or more trust anchors;
FIG. 2 is a simplified block diagram of at least one embodiment of a environment of a local computing device of the system of FIG. 1;
FIG. 3 is a simplified flow diagram of at least one embodiment of a method for securely accessing a key database on the local computing device of FIG. 1;
FIG. 4 is a simplified flow diagram of at least one embodiment of a method for securely provisioning a trust anchor on the local computing device of FIG. 1;
FIG. 5 is a simplified flow diagram of at least one embodiment of a method for initiating a key exchange session on the local computing device of FIG. 1; and
FIG. 6 is a simplified flow diagram of at least one embodiment of a method for establishing a multilateral trust relationship on the local computing device of FIG. 1.
While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.
References in the specification to "one embodiment," "an embodiment," "an illustrative embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.
Referring now to FIG. 1, a system 100 for securely provisioning one or more trust anchors includes a local computing device 102, a network 104, and a remote computing device 106. In use, as discussed in more detail below, the local computing device 102 and the remote computing device 106 may communicate with one another over the network 104 to establish one or more trust anchors and establish a unilateral, bilateral, or multilateral trust relationship. Although only one local computing device 102, one network 104, and one remote computing device 106 are illustratively shown in FIG. 1, the system 100 may include any number of local computing devices 102, networks 104, and remote computing device 106 in other embodiments. For example, as discussed in FIG. 6 below, the local computing device 102 may establish a multilateral trust relationship and act as a group or domain controller. In doing so, the local computing device 102 may communicate with multiple remote computing devices 106 (i.e., nodes) over one or more networks 104.
The local computing device 102 may be embodied as any type of computing device capable of performing the function described herein. For example, the local computing device 102 may be embodied as a desktop computer, a laptop computer, a mobile internet device, a handheld computer, a smart phone, a personal digital assistant, a telephony device, or other computing device. In the illustrative embodiment of FIG. 1, the local computing device 102 includes a processor 108, an I/O subsystem 110, a memory 112, a communication circuitry 116, a data storage device 118, one or more peripheral devices 120, a security co-processor 122, a database key generator 124, and a key database 126. As discussed in detail below, the local computing device 102 may also include a secure memory 114, a biometric capturing device 128, and a secure input/output circuitry 130. In some embodiments, several of the foregoing components may be incorporated on a motherboard of the local computing device 102, while other components may be communicatively coupled to the motherboard via, for example, a peripheral port. Furthermore, it should be appreciated that the local computing device 102 may include other components, sub-components, and devices commonly found in a computer and/or computing device, which are not illustrated in FIG. 1 for clarity of the description.
The processor 108 of the local computing device 102 may be embodied as any type of processor capable of executing software/firmware, such as a microprocessor, digital signal processor, microcontroller, or the like. In some embodiments, the processor 108 may be a single core processor having a processor core. However, in other embodiments, the processor 108 may be embodied as a multi-core processor having multiple processor cores. Additionally, the local computing device 102 may include additional processors 108, each having one or more processor cores.
The I/O subsystem 110 of the local computing device 102 may be embodied as circuitry and/or components to facilitate input/output operations with the processor 108 and/or other components of the local computing device 102. In some embodiments, the I/O subsystem 110 may be embodied as a memory controller hub (MCH or "northbridge"), an input/output controller hub (ICH or "southbridge"), and a firmware device. In such embodiments, the firmware device of the I/O subsystem 110 may be embodied as a memory device for storing Basic Input/Output System (BIOS) data and/or instructions and/or other information (e.g., a BIOS driver used during booting of the local computing device 102). However, in other embodiments, I/O subsystems having other configurations may be used. For example, in some embodiments, the I/O subsystem 110 may be embodied as a platform controller hub (PCH). In such embodiments, the memory controller hub (MCH) may be incorporated in or otherwise associated with the processor 108, and the processor 108 may communicate directly with the memory 112 (as shown by the hashed line in FIG. 1). Additionally, in other embodiments, the I/O subsystem 110 may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor 108 and other components of the local computing device 102, on a single integrated circuit chip.
The processor 108 is communicatively coupled to the I/O subsystem 110 via a number of signal paths. These signal paths (and other signal paths illustrated in FIG. 1) may be embodied as any type of signal paths capable of facilitating communication between the components of the local computing device 102. For example, the signal paths may be embodied as any number of wires, cables, light guides, printed circuit board traces, via, bus, intervening devices, and/or the like.
The memory 112 of the local computing device 102 may be embodied as or otherwise include one or more memory devices or data storage locations including, for example, dynamic random access memory devices (DRAM), synchronous dynamic random access memory devices (SDRAM), double-data rate synchronous dynamic random access memory device (DDR SDRAM), mask read-only memory (ROM) devices, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) devices, flash memory devices, and/or other volatile and/or non-volatile memory devices. The memory 112 is communicatively coupled to the I/O subsystem 110 via a number of signal paths. Although only a single memory device 112 is illustrated in FIG. 1, the local computing device 102 may include additional memory devices in other embodiments. Various data and software may be stored in the memory device 112. For example, one or more operating systems, applications, programs, libraries, and drivers that make up the software stack executed by the processor 108 may reside in memory 112 during execution. Furthermore, software and data stored in memory 112 may be swapped between the memory 112 and the data storage 118 as part of memory management operations.
The communication circuitry 116 of the local computing device 102 may be embodied as any number of devices and circuitry for enabling communications between the local computing device 102 and remote computing devices (e.g., the remote computing device 106) over the network 104. The network 104 may be embodied as any number of various wired and/or wireless communication networks. For example, the network 104 may be embodied as or otherwise include a local area network (LAN), a wide area network (WAN), or a publicly-accessible, global network such as the Internet. Additionally, the network 104 may include any number of additional devices to facilitate communication between the local computing device 102 and the remote computing device 106. The local computing device 102 and the remote computing device 106 may use any suitable communication protocol to communicate with each other over the network 104 depending on, for example, the particular type of network(s) 104. In some embodiments, the local computing device 102 and the remote computing device 106 may communicate with each other over the network 104 using a version of the standardized Internet Key Exchange (IKE) protocol. In other embodiments, the local computing device 102 and remote computing device 106 may communicate using a SIGMA Sign-and-MAC protocol (e.g., any variant of the SIGMA Sign-and-Mac algorithm including, but not limited to, SIGMA-I, SIGMA-R, SIGMA-4, and/or JFK).
The data storage device(s) 118 may be embodied as any type of device or devices configured for the short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. The encrypted key database 126 of the local computing device 102 may be stored in the data storage device 118. As discussed in more detail below, the key database 126 may be encrypted using a database wrapper key, which may be a symmetric cryptographic key generated as a function of hardware of the local computing device 102. For example, in some embodiments, the database wrapper key may be generated using a Physical Unclonable Function (PUF or PUFS) and/or PUF circuitry. The peripheral devices 120 of the local computing device 102 may include any number of peripheral or interface devices. For example, the peripheral devices 120 may include a display, a keyboard, a mouse, external speakers, and/or other peripheral devices. The particular devices included in the peripheral devices 120 may depend upon, for example, the intended use of the local computing device 102. The peripheral devices 120 are communicatively coupled to the I/O subsystem 110 via a number of signal paths thereby allowing the I/O subsystem 110 and/or processor 108 to receive inputs from and send outputs to the peripheral devices 120.
The security co-processor 122 may embodied as any hardware component(s) or circuitry capable of establishing a trusted execution environment 202 (see FIG. 2). For example, the security co-processor 122 may be embodied as a Trusted Platform Module (TPM), a manageability engine (ME), or an out-of-band processor. In some embodiments, a public Enhanced Privacy Identification (EPID) key and a private EPID key may be provisioned into the security co-processor 122 during the manufacturing process of the security co-processor 122. In other embodiments, EPID keys may be provisioned into one or more other components of the local computing device 102. As discussed in detail below, it should be appreciated that EPID keys are associated with a group having a single public EPID key. Any private EPID, of which there may be many, belonging to the group may be paired with the public EPID key as a valid public-private cryptographic pair. For example, the security co-processor 122 of the local computing device 102 may have one private EPID key and the security co-processor 146 of the remote computing device 106 may have a different private EPID key. If the security co-processor 122 and the security co-processor 146 are members of the same group, then both of their private EPID keys are valid asymmetric key pairs with the same public EPID key. As such, EPID keys allow both anonymity and unlinkability of the members. In other embodiments, another one-to-many cryptographic scheme may be used.
The database key generator 124 may embodied as any hardware component or circuitry capable of generating a database wrapper key as a function of the hardware of the local computing device 102. For example, the database key generator 124 may include PUF circuitry or circuit elements or otherwise use a tamper-resistant hardware entropy source (e.g., based on PUF technology) to generate the database wrapper key. In some embodiments, the database key generator 124 may also include error correction circuits or logic associated with the PUF circuitry. As discussed below, the database key generator 124 may be implemented upon boot of the local computing device 102 to generate the database wrapper key (i.e., a symmetric cryptographic key), which may be used to decrypt the key database 126. The key database 126 may be any electronic arrangement or structure suitable for storing cryptographic keys and unique device/entity identifiers. In the illustrative embodiment, the key database 126 is encrypted with the database wrapper key and stored in persistent storage such as, for example, the data storage device 118. In order to access cryptographic keys or otherwise update the key database 126, the trusted execution environment 202 retrieves the encrypted key database 126 from the data storage device 118 and decrypts the encrypted key database 126 with the database wrapper key.
The local computing device 102 may include the secure memory 114, the biometric capturing device 128, and the secure input/output circuitry 130 in embodiments that require user presence to be verified on the local computing device 102 to provision the trust anchor(s). In such embodiments, the secure input/output circuitry 130 may be included in the I/O subsystem 110 and is a hardware reinforced path to securely transfer media. Additionally, the memory 112 may include a portion of secure memory 114. The secure memory 114 may be used for hardware-enforced protection between the application(s) and hardware. In some embodiments, the secure memory 114 may be included on a processor graphics circuitry or a graphics peripheral card or may be a separate partition of the memory 112 for use by the processor graphics circuitry or graphics peripheral card. In one embodiment, Protected Audio Video Path (PAVP) and/or Protected Transaction Display (PTD) technology may be used to implement such hardware reinforced security using the secure memory 114 and the secure input/output circuitry 130. For example, in some embodiments, a Protected Transaction Display may be used to authenticate the user via a randomized Personal Identification Number (PIN) pad that is virtually displayed on a display of the local computing device 102 via a Protected Audio Video Path. Furthermore, it should be appreciated that alternative implementations of hardware reinforced security may use the secure memory 114 and the secure input/output circuitry 130 to verify user presence.
The biometric capturing device 128 may be embodied as any type of biometric capturing device that is capable of generating real-time biometric data of a user of the local computing device 102. For example, the biometric capturing device 128 may be embodied as a camera, such as a still camera, a video camera, or the like, that is capable of generating real-time images of a user of the local computing device 102. Alternatively or in addition, the biometric capturing device 128 may include a fingerprint scanner, handprint scanner, iris scanner, retinal scanner, or voice analyzer. The biometric capturing device may also include a biometric system, which may be embodied as any type of biometric system including multimodal biometric systems. In some embodiments, the biometric capturing device 128 may be incorporated into a housing of the local computing device 102. For example, the biometric capturing device 128 may be a camera incorporated near the display screen of the local computing device 102 (e.g., a webcam). In particular, the camera may capture the facial image of the current user of the local computing device 102. In other embodiments, the biometric capturing device 128 may be a peripheral device communicatively coupled to the local computing device 102.
The remote computing device 106 may be similar to the local computing device 102. As such, the remote computing device 106 may be embodied as any type of computing device capable of performing the functions described herein. In the illustrative embodiment of FIG. 1, the remote computing device 106 includes a processor 132, an I/O subsystem 134, a memory 136, a communication circuitry 140, a data storage device 142, one or more peripheral devices 144, a security co-processor 146, a database key generator 148, and a key database 150. The remote computing device 106 may also include a secure memory 138, a biometric capturing device 152, and a secured input/output circuitry 154. In some embodiments, several of the foregoing components may be incorporated on a motherboard of the remote computing device 106, while other components may be communicatively coupled to the motherboard via, for example, a peripheral port. Furthermore, it should be appreciated that the remote computing device 106 may include other components, sub-components, and devices commonly found in a computer and/or computing device, which are not illustrated in FIG. 1 for clarity of the description.
The processor 132, the I/O subsystem 134, the memory 136, the secure memory 138, the communication circuitry 140, the data storage device 142, the one or more peripheral devices 144, the security co-processor 146, the database key generator 148, the key database 150, the biometric capturing device 152, and the secure input/output circuitry 154 may be similar to the corresponding components of the local computing device 102 as described above. As such, the descriptions of such similar components of the local computing device 102 is equally applicable to the similar components of the remote computing device 106 and are not repeated herein for clarity of the description.
In use, as shown in FIG. 2, the local computing device 102 may establish an environment 200 for securely provisioning a trust anchor. The environment 200 in the illustrative embodiment includes a trusted execution environment 202, the database key generator 124, the key database 126, the communication module 204, a secured input/output module 206, and the biometric capturing device 128.
The trusted execution environment 202 may be implanted by the security co-processor 122 to establish a secure environment. In some embodiments, the cryptographic keys stored in the key database 126 may only be accessed by the trusted execution environment 202 when in use. When not in use, the key database 126 may be encrypted with the database wrapper key generated by the database key generator 124 and stored in the data storage device 118. In the illustrative embodiment of FIG. 2, the cryptographic key stored in the key database 126 and the database wrapper key generated by the database key generator 124 are inaccessible to the processor 108. As such, in some embodiments, only the trusted execution environment 202 may access the database wrapper key. In some embodiments, the environment 200 may also include the secured input/output module 206, which may be software/firmware designed to securely interact with the secure input/output circuitry 130 in the I/O subsystem 110 of the local computing device 102.
The communication module 204 may handle the communication between the local computing device 102 and remote computing devices, including the remote computing device 106, through the network 104. Each of the trusted execution environment 202, the database key generator 124, the key database 126, the communication module 204, the secured input/output module 206, and the biometric capturing device 128 may be embodied as hardware, software, firmware, or a combination thereof. It should be appreciated that the remote computing device 106 may establish an environment similar to the environment 200 for communicating with the local computing device 102 to establish one or more trust anchors. For example, the remote computing device 106 may also have a trusted execution environment that may communicate with the trusted execution environment 202 of the local computing device 102 through the communication module 204.
Referring now to FIG. 3, one illustrative embodiment of a method 300 for securely accessing the key database 126, which may be executed by the local computing device 102, begins with block 302. In block 302, the local computing device 102 determines whether the system power of the local computing device 102 has been reset. If so, the local computing device 102 generates the database wrapper key as a function of hardware of the local computing device 102 in block 304. That is, the database wrapper key is stored in volatile memory and re-derived each time the local computing device 102 platform is powered up. In other embodiments, the database wrapper key may not be generated until the trusted execution environment 202 needs to use it to access the cryptographic keys stored in the key database 126. In yet other embodiments, the database wrapper key may be generated by the database key generator 124 when directed to do so by the trusted execution environment 202 and immediately deleted from memory after it has been used. As discussed above, in generating the database wrapper key, the local computing device 102 may use a tamper-resistant hardware entropy source to generate the database wrapper key. In some embodiments, in block 306, the local computing device 102 may use PUFS to generate the database wrapper key.
In block 308, the local computing device 102 may retrieve the encrypted key database 126 from the data storage device 118 via the trusted execution environment 202. Within the trusted execution environment 202, the local computing device 102 may then decrypt the encrypted key database 126 with the database wrapper key generated by the database key generator 124 in block 310. After the key database 126 has been encrypted, the cryptographic keys stored in the key database 126 may be used by the trusted execution environment 202 in block 312. For example, the key database 126 may contain keys used to establish a trust anchor, public and private asymmetric keys, symmetric cryptographic keys, session keys, and/or other cryptographic keys. In block 314, the trusted execution environment 202 of the local computing device 102 may update the key database 126. For example, the trusted execution environment 202 may add cryptographic keys, delete cryptographic keys, or otherwise modify the cryptographic keys stored in the key database 126. In some embodiments, the key database 126 may be configured to store identifiers associated with a device, hardware component, entity, or relationship. In such embodiments, the trusted execution environment 202 may also update any identifiers in block 314. It should be appreciated that the key database 126 may not need to be updated in some circumstances.
In block 316, the local computing device 102 waits until the trusted execution environment 202 has finished updating the key database 126. Once the key database 126 has been updated, if at all, the trusted execution environment 202 encrypts the key database 126 using the database wrapper key in block 318. In block 320, the encrypted key database 126 is then stored in the data storage device 118 of the local computing device 102. As discussed above, in the illustrative embodiment, the key database 126 is decrypted and then re-encrypted every time the trusted execution environment 202 accesses a key stored in the key database 126. In other embodiments, the trusted execution environment 202 may decrypt the key database 126 and store the decrypted key database 126 in secure memory (e.g., secure volatile memory) accessible only to the security co-processor 122 and the trusted execution environment 202. The trusted execution environment 202 may then utilize the decrypted key database 126 and make any required updates directly through the secure memory. If there were any updates, the trusted execution environment 202 may re-encrypt the key database 126 and store the updated key database 126 to the data storage device 118. Otherwise, when the local computing device 102 powers down, the decrypted key database 126 in the volatile secure memory is deleted. It should be appreciated that the remote computing device 106 may execute a similar method to the method 400 for securely accessing the key database 150.
Referring now to FIG. 4, one illustrative embodiment of a method 400 for securely provisioning a trust anchor, which may be executed by the local computing device 102, begins with block 402. If the local computing device 102 has been provisioned with a set of EPID keys in block 402, then the method 400 advances to block 404. As discussed above, in some embodiments, a one-to-many cryptography scheme other than EPID may be used. In block 404, the local computing device 102 establishes a connection with the remote computing device 106 over the network 104. In doing so, the trusted execution environment 202 of the local computing device 102 may communicate with the corresponding trusted execution environment of the remote computing device 106.
In block 406, the local computing device 102 may establish security protocols with the remote computing device 106, which may include initiating a key exchange session with the remote computing device 106 in block 408. As indicated above, the local computing device 102 may initiate a SIGMA Sign-and-MAC session or a variant thereof with the remote computing device 106. To do so, the local computing device 102 may execute a method 500 to establish a SIGMA Sign-and-MAC session with the remote computing device 106 using EPID keys as shown in FIG. 5. The method 500 may be executed by, for example, the trusted execution environment 202 of the local computing device 102. The method 500 begins with block 502 in which the local computing device 102 authenticates to the remote computing device 106 using the local computing device 102 EPID key. For example, in block 504, the local computing device 102 may sign a communication with the private EPID key of the security co-processor 122. The local computing device 102 may then transmit the signed communication to the remote computing device 106 for authentication. Because the security co-processor 122 of the local computing device 102 and the security co-processor 146 of the remote computing device 106 belong to the same group, they share the same public EPID key. As such, the remote computing device 106 may use the public EPID key provisioned to its security co-processor 146 to validate the signature of the local computing device 102. In other embodiments, another one-to-many cryptographic scheme may be used. In such embodiments, the cryptographic keys may be provisioned into the security co-processors at manufacturing or transferred to the security co-processors sometime thereafter.
In block 506, the local computing device 102 waits until it has received a signed communication back from the remote computing device 106. Once the local computing device 102 receives a signed communication from the remote computing device 106, the local computing device 102 authenticates the remote computing device 106 in block 508. In embodiments in which bilateral trust is desired, the remote computing device 106 may sign the communication using its private EPID key. As such, in block 510, the local computing device 102 may validate the signature of the remote computing device 106 using the public EPID key stored in the security co-processor 122 of the local computing device 102. In other embodiments, only unilateral trust may be required. In such embodiments, the remote computing device 106 may sign the communication using a standard private cryptographic key. For example, the remote computing device 106 may use X.509 or another Public Key Infrastructure (PKI) scheme. That is, the remote computing device 106 may sign the communication using a private key generated with a Rivest-Shamir-Adleman (RSA) algorithm or elliptic curve cryptography. It should be appreciated that, in such embodiments, the certification path terminates with a certificate authority rather than the remote computing device 106 itself. In some embodiments, the standard cryptographic key may be provisioned to the security co-processor 146 at manufacturing time. In such unilateral trust embodiments, in block 512, the local computing device 102 may validate the signature of the remote computing device 106 using the public cryptographic key corresponding to the private cryptographic key used to sign the communication. The local computing device 102 may retrieve the public key from, for example, a public key certificate sent with the communication from the remote computing device 106.
In block 514, the local computing device 102 may establish an identifier to identify the security co-processor 146 or trusted execution environment of the remote computing device 106 or the remote computing device 106 itself for future communications. If a unilateral trust relationship is established, the local computing device 102 may use, for example, a key hash or a globally unique identifier (GUID) or other domain specific identifier to disambiguate the security co-processor 146 of the remote computing device 106. For example, the local computing device 102 may simply use the X.509 serial number or a one-time password previously provisioned to the remote computing device 106. When bilateral trust is established, the local computing device 102 may assert the selected identifier to subsequently identify the remote computing device 106. Similarly, the remote computing device 106 may select a unique identifier to identify the local computing device 102 for future communications. Additionally, each endpoint may select identifiers of their own choosing and communicate the identifier to the other device. In block 516, the local computing device 102 may generate a session key (e.g., a symmetric cryptographic key) that may be used to securely provision the trust anchors.
It should be appreciated that each of the signed communications may comprise components necessary to effect a Diffie-Hellman type key exchange. As such, the local computing device 102 may generate the session key as a function of the signed communications between the local computing device 102 and the remote computing device 106. Similarly, the remote computing device 106 may also generate the session key as a function of the signed communications. The local computing device 102 and the remote computing device 106 may use the session key or a key generated as a function of the session key to encrypt future communications between them. Thereafter, when the local computing device 102 desires to communicate with the remote computing device 106, they may negotiate a virtual private network (VPN) channel or other secure channel using the session keys. The local computing device 102 may update the key database 126 with the generated session key and/or any established identifiers by executing the method 300 shown in FIG. 3. Similarly, the remote computing device 106 may update its key database 150.
Referring back to FIG. 4, after the security protocols have been established in block 406, the trusted execution environment 202 of the local computing device 102 determines whether multilateral trust and provisioning is desired in block 410. If so, the method 400 advances to method 600 for establishing a multilateral trust relationship, which is described below in the discussion of FIG. 6. Otherwise, unilateral or bilateral provisioning is assumed and the local computing device 102 provisions the trust anchor(s) in block 412. In doing so, the local computing device 102 generates an asymmetric key pair in block 414. The asymmetric key pair may be generated using any suitable cryptographic procedure. In the illustrative embodiment, the asymmetric key pair is a standard one-to-one public-private key pair. For example, the asymmetric key pair may be generated using an RSA algorithm or elliptic curve cryptography. In other embodiments, a one-to-many asymmetric cryptographic key pair may be used. In block 416, the local computing device 102 transmits the public key of the asymmetric key pair to the remote computing device 106. To do so, the security co-processor 122 of the local computing device 102 may communicate with the security co-processor 146 of the remote computing device 106 as discussed above. This creates a trust anchor and establishes a unilateral trust relationship between the local computing device 102 and the remote computing device 106. It should be appreciated that, alternatively, the remote computing device 106 may generate the asymmetric key pair and transmit the public key to the local computing device 102.
If a bilateral trust relationship is required, the remote computing device 106 may generate a second asymmetric key pair and transmit the public key of that public-private key pair to the local computing device 102. In block 418, the local computing device 102 may receive the public key generated by the remote computing device 106. With bilateral trust, each endpoint (i.e., computing device) possesses the public key of the other endpoint after the exchange. However, with unilateral trust, only one side provisions a public key. As discussed above, the key transfers performed in block 414 may be encrypted or otherwise secured. For example, a SIGMA Sign-and-MAC session key generated in block 516 of FIG. 5 may be used to encrypt communications.
If the trusted execution environment 202 of the local computing device 102 has a security policy that requires user presence authorization in order to provision the trust anchors, the local computing device 102 may verify the presence of the local computing device 102 user in block 420. In some embodiments, the local computing device 102 may simply verify that any person is using the local computing device 102 and that it is not being operated remotely. In the illustrative embodiment, however, the local computing device 102 verifies the presence of a particular user (e.g., an administrator). To do so, the local computing device 102 may compare biometric recognition data to real-time biometric data captured from the capturing device 128. The biometric recognition data may be embodied as any type of data usable by the local computing device 102 to identify a current user of the local computing device 102 such as pre-generated biometric data, biometric feature data, biometric template data, or other data that may be used for comparison with a real-time biometric data of the current user. As discussed above, a camera may be used as a biometric capturing device 128. In such an embodiment, pre-generated pictures of an authorized user's face or facial feature data may be used as suitable biometric recognition data. The biometric recognition data may be stored in the secure memory 114 or other suitable secure storage.
The biometric capturing device 128 may capture the real-time biometric data of the user and transmit the data via the secured input/output module 206 through the secure input/output circuitry 130 (e.g., using PAVP) to the processor 108, the processor graphics circuitry, or the graphics peripheral card for processing. A suitable biometric recognition procedure may be executed to identify the current user as an authorized user or an unauthorized user. In some embodiments, verification of user presence may include providing a Turing test or a user presence test to the current user. In such embodiments, the Turing test or user presence test may be embodied as any test presented to the current user of the local computing device 102 suitable to determine that the current user is physically present. Such tests may, for example, require the user to interact with the local computing device 102 based on information displayed on a display screen of the local computing device 102.
If bilateral trust is established, the remote computing device 106 may also have a security policy that requires user presence authorization in order to provision the trust anchors. If so, the remote computing device 106 may verify the presence of the user of the remote computing device 106 in block 422. To do so, the remote computing device 106 may execute a similar process to the process executed by the local computing device 102 discussed in block 420. In block 424, the local computing device 102 may update the key database 126 with cryptographic keys generated or received while provisioning the trust anchor(s) by executing the method 300 shown in FIG. 3. The remote computing device 106 may also update its key database 150.
Referring now to FIG. 6, one illustrative embodiment of a method 600 for establishing a multilateral trust relationship, which may be executed by the local computing device 102, begins with block 602. It should be appreciated that, prior to method 600, the local computing device 102 and the remote computing device 106 initiate a key exchange session (see block 408 of FIG. 4) to establish a session key such as a SIGMA Sign-and-MAC session key for use in encrypting communications or otherwise establishing a secure channel between the devices throughout method 600. In block 602, the trusted execution environment 202 of the local computing device 102 notifies the corresponding trusted execution environment of the remote computing device 106 that it would like to become a domain or group controller for a multi-way trust relationship. That is, the local computing device 102 sends a request to the remote computing device 106 to be a group controller. In doing so, the local computing device 102 may generate a group or domain identifier in block 604. For example, the local computing device 102 may generate a GUID unique to the group and indicate the generated GUID in the message to the remote computing device 106.
In block 608, the local computing device 102 receives an acknowledgment from the remote computing device 106. That is, the remote computing device 106 verifies, in block 610, that the group identifier generated by the local computing device 102 in block 604 has not already been provisioned. In block 612, the local computing device 102 may generate one-to-many asymmetric keys associated with the group using a multi-key cryptosystem. Similar to EPID keys, the local computing device 102 may generate several private keys such that each private key and the single generated public key constitute a valid asymmetric key pair. In some embodiments, these cryptographic keys may be pre-generated. In block 612, the local computing device 102 selects one of the multiple private keys generated in block 612 for the remote computing device 106. The local computing device 102 then provisions the selected private key and the public key to the remote computing device 106 through its trusted execution environment.
In block 616, if the trusted execution environment of the remote computing device 106 has a security policy that requires user presence authorization in order to provision the trust anchors, the remote computing device 106 may verify the presence of the user of the remote computing device 106 by a process similar to the process discussed in block 420. In block 618, the local computing device 102 may delete the private key provisioned to the remote computing device 106 so that it cannot be provisioned to a different remote computing device. The local computing device 102 may make any needed updates to the key database 126 in block 620. For example, the local computing device 102 may store the cryptographic keys generated in block 612 in the key database 126. In block 624, the local computing device 102 determines whether to provision another remote computing device in the multilateral trust relationship. If another remote computing device is to be provision, the method 600 returns to block 602 in which the local computing device 102 sends a group or domain controller request to the other remote computing device.
For iterations of the method 600 in provisioning remote computing devices other than the first remote computing device 106, it is unnecessary to execute the block 612 because the group keys have already been generated. Further, although not shown in the illustrative embodiment, the local computing device 102 may initiate a key exchange and establish a session key (e.g., via SIGMA Sign-and-MAC protocol) with each remote computing device to be provisioned with group keys. Any member of the group may subsequently authenticate to another member of the group using its private group key and the group identifier. As such, it follows that any two devices belonging to the group may establish unilateral or bilateral trust between them using the methods discussed herein. Similar to the EPID keys, neither member knows what other specific member of the group it is establishing a trust relationship with, but knows only that the other member is a legitimate member of the domain or group.
Illustrative examples of the devices, systems, and methods disclosed herein are provided below. An embodiment of the devices, systems, and methods may include any one or more, and any combination of, the examples described below.
Example 1 includes a local computing device for establishing a trust relationship with a remote computing device. The local computing device includes a database key generator to generate a database wrapper key as a function of hardware of the local computing device; and a trusted execution environment to (i) establish a secure connection with the remote computing device, (ii) generate a local asymmetric cryptographic key pair including a local public key and a local private key, (iii) transmit the local public key to the remote computing device, (iv) decrypt an encrypted key database stored on the local computing device using the database wrapper key, (v) store the local private key in the decrypted key database; and (vi) encrypt the key database using the database wrapper key.
Example 2 includes the subject matter of Example 1, and wherein the database key generator is to generate the database wrapper key as a function of hardware of the local computing device using a Physical Unclonable Function.
Example 3 includes the subject matter of any of Examples 1 and 2, and wherein the database key generator is to generate the database wrapper key in response to powering the local computing device.
Example 4 includes the subject matter of any of Examples 1-3, and wherein the trusted execution environment is to establish the secure connection by performing a secure cryptographic key exchange.
Example 5 includes the subject matter of any of Examples 1-4, and wherein the trusted execution environment is to establish the secure connection by establishing a unilateral or bilateral trust relationship with the remote computing device.
Example 6 includes the subject matter of Examples any of 1-5, and wherein the trusted execution environment is to establish the secure connection by initiating a SIGMA Sign-and-MAC session.
Example 7 includes the subject matter of any of Examples 1-6, wherein the trusted execution environment is to establish the secure connection by transmitting a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key stored on the local computing device; receiving a second signed communication from the remote computing device in response to transmitting the first signed communication; authenticating the second signed communication using a public key of the remote computing device; establishing a device identifier for the remote computing device; and generating a session key as a function of the first signed communication and the second signed communication.
Example 8 includes the subject matter of any of Examples 1-7, and wherein the trusted execution environment is to authenticate the second signed communication by validating the signature of the second signed communication using a public Enhanced Privacy Identification key.
Example 9 includes the subject matter of any of Examples 1-8, and wherein the trusted execution environment is to establish a device identifier by establishing a globally unique identifier for the remote computing device.
Example 10 includes the subject matter of any of Examples 1-9, and wherein the trusted execution environment is to update the decrypted key database with the session key, the device identifier, and the local public key.
Example 11 includes the subject matter of any of Examples 1-10, and wherein the trusted execution environment is to update the decrypted key database with the local public key.
Example 12 includes the subject matter of any of Examples 1-11, and wherein the trusted execution environment is to receive a remote public key of a remote public-private key pair from the remote computing device; and update the decrypted key database with the remote public key.
Example 13 includes the subject matter of any of Examples 1-12, and further includes biometric capturing device to capture real-time biometric data from a current user of the local computing device; and a processor graphics circuitry to verify the presence of the current user by comparing biometric authentication data with the captured real-time biometric data.
Example 14 includes the subject matter of any of Examples 1-13, and further includes a secured input/output circuitry, wherein the biometric authentication data and the real-time biometric data are transferred to the processor graphics circuitry through the secure input/output circuitry.
Example 15 includes the subject matter of any of Examples 1-14, and wherein the trusted execution environment is to establish the secure connection with a trusted execution environment of the remote computing device belonging to a same manufacturing group as the trusted execution environment of the local computing device.
Example 16 includes a local computing device for establishing a trust relationship with one or more remote computing devices. The local computing device includes a database key generator to generate a database wrapper key as a function of hardware of the local computing device; a trusted execution environment to (i) establish a secure connection with a remote computing device, (ii) generate multiple private keys and one public key such the one public key and each private key of the multiple private keys comprises a valid public-private cryptographic key pair, (iii) provision the one public key and an unprovisioned private key of the multiple private keys to the remote computing device, (iv) decrypt an encrypted key database of the local computing device using the generated database wrapper key, (v) update the decrypted key database based on the provisioning, and (vi) encrypt the key database using the database wrapper key.
Example 17 includes the subject matter of Example 16, and wherein the database key generator is to generate the database wrapper key as a function of hardware of the local computing device using a Physical Unclonable Function.
Example 18 includes the subject matter of any of Examples 16 and 17, and wherein the database key generator is to generate the database wrapper key in response to powering the local computing device.
Example 19 includes the subject matter of any of Examples 16-18, and wherein the trusted execution environment is to establish the secure connection by performing a secure cryptographic key exchange.
Example 20 includes the subject matter of any of Examples 16-19, and wherein the trusted execution environment is to establish the secure connection by initiating a SIGMA Sign-and-MAC session.
Example 21 includes the subject matter of any of Examples 16-20, and wherein the trusted execution environment is to establish the secure connection by transmitting a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key; receiving a second signed communication from the remote computing device; authenticating the second signed communication using a public key of the remote computing device; and generating a session key as a function of the first signed communication and the second signed communication.
Example 22 includes the subject matter of any of Examples 16-21, and wherein the trusted execution environment is to authenticate the second signed communication by validating the signature of the second signed communication using a public Enhanced Privacy Identification key.
Example 23 includes the subject matter of any of Examples 16-22, and wherein the trusted execution environment is to provision another unprovisioned private key of the multiple private keys to another remote computing device.
Example 24 includes the subject matter of any of Examples 16-23, and wherein the trusted execution environment is to transmit a group controller request to the remote computing device.
Example 25 includes the subject matter of any of Examples 16-24, and wherein the trusted execution environment is to transmit the group controller request in response to generating a group identifier.
Example 26 includes the subject matter of any of Examples 16-25, and wherein the trusted execution environment is to receive verification of the availability of the ground identifier from the remote computing device in response to transmitting the group controller request.
Example 27 includes the subject matter of any of Examples 16-26, and wherein the trusted execution environment is to update the decrypted key database based on the provisioning in response to receiving a notification from the remote computing device indicating that the remote computing device verified the presence of the user of the remote computing device.
Example 28 includes a method for securely establishing a trust relationship between a local computing device and a remote computing device. The method includes generating, on the local computing device, a database wrapper key as a function of hardware of the local computing device; establishing a secure connection between the local computing device and the remote computing device; generating, on the local computing device, a local asymmetric cryptographic key pair including a local public key and a local private key; transmitting the local public key to the remote computing device; decrypting an encrypted key database stored on the local computing device using the generated database wrapper key; storing the local private key in the decrypted key database; and encrypting the key database using the database wrapper key.
Example 29 includes the subject matter of any of Example 28, and wherein generating the database wrapper key comprises generating a database wrapper key as a function of hardware of the local computing device using a Physical Unclonable Function.
Example 30 includes the subject matter of any of Example 28 and 29, and wherein generating the database wrapper key comprises generating the database wrapper key in response to powering the local computing device.
Example 31 includes the subject matter of any of Examples 28-30, and wherein establishing the secure connection comprises performing a secure cryptographic key exchange.
Example 32 includes the subject matter of any of Examples 28-31, wherein establishing the secure connection comprises establishing a unilateral or bilateral trust relationship with the remote computing device.
Example 33 includes the subject matter of any of Examples 28-32, and wherein establishing the secure connection comprises initiating a SIGMA Sign-and-Mac session.
Example 34 includes the subject matter of Examples 28-33, wherein establishing the secure connection comprises transmitting a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key stored on the local computing device; receiving a second signed communication from the remote computing device in response to transmitting the first signed communication; authenticating the second signed communication using a public key of the remote computing device; establishing a device identifier for the remote computing device; and generating a session key as a function of the first signed communication and the second signed communication.
Example 35 includes the subject matter of any of Examples 28-34, and wherein authenticating the second signed communication comprises validating the signature of the second signed communication using a public Enhanced Privacy Identification key.
Example 36 includes the subject matter of any of Examples 28-35, and wherein establishing a device identifier comprises establishing a globally unique identifier for the remote computing device.
Example 37 includes the subject matter of any of Examples 28-36, and further includes updating the decrypted key database with the session key, the device identifier, and the local public key.
Example 38 includes the subject matter of any of Examples 28-37, and further includes updating the decrypted key database with the local public key.
Example 39 includes the subject matter of any of Examples 28-38, and further includes receiving a remote public key of a remote public-private key pair from the remote computing device; and updating the decrypted key database with the remote public key.
Example 40 includes the subject matter of any of Examples 28-39, and further includes verifying the presence of a user of the local computing device.
Example 41 includes the subject matter of any of Examples 28-40, and wherein verifying the presence of the user comprises comparing biometric authentication data with biometric data received from the user that is captured in real-time using a biometric capturing device of the computing device.
Example 42 includes a method for securely establishing a trust relationship between a local computing device and one or more remote computing devices. The method includes generating a database wrapper key as a function of hardware of the local computing device; establishing a secure connection with the remote computing device; generating multiple private keys and one public key such the one public key and each private key of the multiple private keys comprises a valid public-private cryptographic key pair; provisioning the one public key and an unprovisioned private key of the multiple private keys to the remote computing device; decrypting an encrypted key database of the local computing device using the generated database wrapper key; updating the decrypted key database based on the provisioning; and encrypting the key database using the database wrapper key.
Example 43 includes the subject matter of Example 42, and wherein generating the database wrapper key comprises generating a database wrapper key as a function of hardware of the local computing device using a Physical Unclonable Function.
Example 44 includes the subject matter of any of Examples 42 and 43, and wherein generating the database wrapper key comprises generating the database wrapper key in response to powering the local computing device.
Example 47 includes the subject matter of any of Examples 42-46, and wherein establishing the secure connection comprises transmitting a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key; receiving a second signed communication from the remote computing device; authenticating the second signed communication using a public key of the remote computing device; and generating a session key as a function of the first signed communication and the second signed communication.
Example 49 includes the subject matter of any of Examples 42-48, and further includes provisioning another unprovisioned private key of the multiple private keys to another remote computing device.
Example 50 includes the subject matter of any of Examples 42-49, and further includes transmitting a group controller request to the remote computing device.
Example 51 includes the subject matter of any of Examples 42-50, and wherein transmitting the group controller request comprises generating a group identifier.
Example 52 includes the subject matter of any of Examples 42-51, and further includes receiving verification of the availability of the ground identifier from the remote computing device in response to transmitting the group controller request.
Example 53 includes the subject matter of any of Examples 42-52, and further includes verifying the presence of the user of the remote computing device.
Example 55 includes one or more machine readable media comprising a plurality of instructions stored thereon that in response to being executed by a computing device results in performing any of Examples 28-54.
The invention claimed is:
1. A local computing device comprising:
a processor including at least one core;
a database key generator to generate a database wrapper key as a function of hardware of the local computing device; and
a security co-processor coupled to the database key generator, the security co-processor to establish a trusted execution environment to (i) establish a secure connection with a remote computing device by:
transmission of a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key stored on the local computing device;
receipt of a second signed communication from the remote computing device in response to transmission of the first signed communication;
authentication of the second signed communication using a public key of the remote computing device;
establishment of a device identifier for the remote computing device; and
generation of a session key as a function of the first signed communication and the second signed communication;
(ii) generate a local asymmetric cryptographic key pair including a local public key and a local private key, (iii) transmit the local public key to the remote computing device, (iv) decrypt an encrypted key database stored on the local computing device using the database wrapper key, the encrypted key database and the database wrapper key inaccessible to the processor, (v) store the local private key in the decrypted key database, and (vi) encrypt the key database using the database wrapper key.
2. The local computing device of claim 1, wherein the database key generator is to generate the database wrapper key as a function of hardware of the local computing device using a Physical Unclonable Function in response to powering the local computing device.
3. The local computing device of claim 1, wherein the trusted execution environment is to authenticate the second signed communication by validating the signature of the second signed communication using a public Enhanced Privacy Identification key.
4. The local computing device of claim 1, wherein the trusted execution environment is to:
establish the device identifier by establishing a globally unique identifier for the remote computing device; and
update the decrypted key database with the session key, the device identifier, and the local public key.
receive a remote public key of a remote public-private key pair from the remote computing device; and
update the decrypted key database with at least one of: the remote public key and the local public key.
6. The local computing device of claim 1, further comprising:
a biometric capturing device to capture real-time biometric data from a current user of the local computing device;
a processor graphics circuitry to verify the presence of the current user by comparing biometric authentication data with the captured real-time biometric data; and
a secured input/output circuitry, wherein the biometric authentication data and the real-time biometric data are transferred to the processor graphics circuitry through the secure input/output circuitry.
7. The local computing device of claim 1, wherein the trusted execution environment is to establish the secure connection with a trusted execution environment of the remote computing device belonging to a same manufacturing group as the trusted execution environment of the local computing device.
a database key generator to generate a database wrapper key as a function of hardware of the local computing device;
transmission of a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key;
receipt of a second signed communication from the remote computing device;
authentication of the second signed communication using a public key of the remote computing device; and
(ii) generate multiple private keys and one public key such that the one public key and each private key of the multiple private keys comprises a valid public-private cryptographic key pair, the one public key associated with a group of computing devices including the local computing device and the remote computing device and the multiple private keys comprising group private keys, (iii) provision the one public key and an unprovisioned private key of the multiple private keys to the remote computing device, (iv) decrypt an encrypted key database of the local computing device using the generated database wrapper key, (v) update the decrypted key database based on the provisioning, and (vi) encrypt the key database using the database wrapper key.
9. The local computing device of claim 8, wherein the database key generator is to generate the database wrapper key as a function of hardware of the local computing device using a Physical Unclonable Function.
10. The local computing device of claim 8, wherein the database key generator is to generate the database wrapper key in response to powering the local computing device.
11. The local computing device of claim 10, wherein the trusted execution environment is to authenticate the second signed communication by validating the signature of the second signed communication using a public Enhanced Privacy Identification key.
12. The local computing device of claim 8, wherein the trusted execution environment is to provision another unprovisioned private key of the multiple private keys to another remote computing device.
13. The local computing device of claim 8, wherein the trusted execution environment is to:
transmit a group controller request to the remote computing device in response to generating a group identifier; and
receive verification of the availability of the group identifier from the remote computing device in response to transmitting the group controller request.
14. The local computing device of claim 8, wherein the trusted execution environment is to update the decrypted key database based on the provisioning in response to receiving a notification from the remote computing device indicating that the remote computing device verified the presence of the user of the remote computing device.
15. One or more non-transitory machine-readable storage media comprising a plurality of instructions stored thereon that, in response to being executed, result in a computing device:
generating a database wrapper key as a function of hardware of the computing device;
establishing a secure connection with a remote computing device comprising:
transmitting a first signed communication to the remote computing device signed by a private Enhanced Privacy Identification key stored on the computing device;
receiving a second signed communication from the remote computing device in response to transmitting the first signed communication;
authenticating the second signed communication using a public key of the remote computing device;
establishing a device identifier for the remote computing device; and
generating a session key as a function of the first signed communication and the second signed communication;
generating a local asymmetric cryptographic key pair including a local public key and a local private key;
transmitting the local public key to the remote computing device;
decrypting an encrypted key database stored on the computing device using the generated database wrapper key;
storing the local private key in the decrypted key database; and
encrypting the key database using the database wrapper key.
16. The one or more non-transitory machine-readable storage media of claim 15, wherein generating the database wrapper key comprises generating a database wrapper key as a function of hardware of the computing device using a Physical Unclonable Function in response to powering the computing device.
17. The one or more non-transitory machine-readable storage media of claim 15, wherein authenticating the second signed communication comprises validating the signature of the second signed communication using a public Enhanced Privacy Identification key.
US14/618,757 2012-09-28 2015-02-10 Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware Active US9467430B2 (en)
US13/631,562 US8954735B2 (en) 2012-09-28 2012-09-28 Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US13/631,562 Continuation US8954735B2 (en) 2012-09-28 2012-09-28 Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US13/631,562 Active 2033-03-08 US8954735B2 (en) 2012-09-28 2012-09-28 Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US14/618,757 Active US9467430B2 (en) 2012-09-28 2015-02-10 Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
Family Applications Before (1)
EP3474180A1 (en) * 2017-10-17 2019-04-24 Princeton Scitech, LLC Authentication for computing systems
CN107612685A (en) 2011-12-29 2018-01-19 英特尔公司 Use the secure key storage of physically unclonable function
US8954735B2 (en) 2012-09-28 2015-02-10 Intel Corporation Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US8928347B2 (en) 2012-09-28 2015-01-06 Intel Corporation Integrated circuits having accessible and inaccessible physically unclonable functions
US9215249B2 (en) 2012-09-29 2015-12-15 Intel Corporation Systems and methods for distributed trust computing and key management
US8938792B2 (en) 2012-12-28 2015-01-20 Intel Corporation Device authentication using a physically unclonable functions based key generation system
US9191203B2 (en) * 2013-08-06 2015-11-17 Bedrock Automation Platforms Inc. Secure industrial control system
KR20150033368A (en) * 2013-09-24 2015-04-01 삼성전자주식회사 Method and apparatus for security domain notification in trusted execution environment
US20160036826A1 (en) * 2014-07-29 2016-02-04 Mcafee, Inc. Secure content packaging using multiple trusted execution environments
US9716716B2 (en) 2014-09-17 2017-07-25 Microsoft Technology Licensing, Llc Establishing trust between two devices
WO2016048177A1 (en) * 2014-09-26 2016-03-31 Intel Corporation Securely exchanging vehicular sensor information
US9774571B2 (en) * 2015-03-10 2017-09-26 Microsoft Technology Licensing, Llc Automatic provisioning of meeting room device
US10136310B2 (en) 2015-04-24 2018-11-20 Microsoft Technology Licensing, Llc Secure data transmission
US20160364787A1 (en) 2015-06-09 2016-12-15 Intel Corporation System, apparatus and method for multi-owner transfer of ownership of a device
US9965618B1 (en) * 2015-08-27 2018-05-08 Amazon Technologies, Inc. Reducing privileges for imported software packages
US10044514B1 (en) * 2015-09-25 2018-08-07 Xilinx, Inc. Secure external key storage for programmable ICS
US10355854B2 (en) 2015-12-17 2019-07-16 Intel Corporation Privacy preserving group formation with distributed content key generation
US20050021946A1 (en) 2003-06-27 2005-01-27 Ram Gopal Lakshmi Narayanan System and method for nodes communicating in a shared network segment
US20060104441A1 (en) * 2004-11-17 2006-05-18 Microsoft Corporation Password protection
US7293178B2 (en) 2002-12-09 2007-11-06 Microsoft Corporation Methods and systems for maintaining an encrypted video memory subsystem
US20080022121A1 (en) * 2006-06-06 2008-01-24 Red Hat, Inc. Methods and systems for server-side key generation
US20080089514A1 (en) * 2005-01-24 2008-04-17 Yuichi Futa Signature Generation Device, Key Generation Device, and Signature Generation Method
US7702925B2 (en) 2002-09-19 2010-04-20 Silicon Image, Inc. Method and apparatus for content protection in a personal digital network environment
US20110072266A1 (en) * 2008-10-10 2011-03-24 Hisashi Takayama Information processing device, authentication system, authentication device, information processing method, information processing program, recording medium, and integrated circuit
US20120173877A1 (en) 2011-01-05 2012-07-05 Ramesh Pendakur Method and apparatus for building a hardware root of trust and providing protected content processing within an open computing platform
US20120324234A1 (en) * 2000-07-25 2012-12-20 Laurence Hamid Flexible method of user authentication
US20130010957A1 (en) * 2011-07-07 2013-01-10 Verayo, Inc. Cryptographic security using fuzzy credentials for device and server communications
US20130254636A1 (en) * 2012-03-22 2013-09-26 Purdue Research Foundation System on chip and method for cryptography using a physically unclonable function
US20140042627A1 (en) * 2012-08-09 2014-02-13 International Business Machines Corporation Electronic structure containing a via array as a physical unclonable function
US20140075550A1 (en) * 2012-09-13 2014-03-13 Mojtaba Mirashrafi Hardware-enforced access protection
Non-Patent Citations (13)
"Enhanced Privacy ID, A remote anonymous attestation scheme for hardware devices," available at http://www.drdobbs.com/security/enhanced-privacy-id/219501634, Sep. 8, 2009, 7 pages.
Alexei Czeskis, "FIDO NFC Protocol Specification v1.0", FIDO Alliance Proposed Standard, May 14, 2015, pp. 1-5, FIDO Alliance.
Brickell, Ernie, et al., "Enhanced Privacy ID (EPID)," 22 pages.
Brickell, Ernie, et al., "Enhanced Privacy ID using Bilinear Pairing," NIST Identity Based Encryption Workshop, Jun. 2008, 8 pages.
Brickell, et al., "Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities," Aug. 17, 2007, 36 pages.
Dirk Balfanz, "FIDO U2F Implementation Considerations", FIDO Alliance Proposed Standard, May 14, 2015, pp. 1-5, FIDO Alliance.
Dirk Balfanz, "FIDO U2F Raw Message Formats", FIDO Alliance Proposed Standard, May 14, 2015, pp. 1-10, FIDO Alliance.
Dirk Balfanz, FIDO U2F Javascript API, FIDO Alliance Proposed Standard, May 14, 2015, pp. 1-7, FIDO Alliance.
Krawczyk, Hugo, "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and it's Use in the IKE Protocols," Jun. 12, 2003, 32 pages.
Paral, Zdenek (Sid), et al., "Reliable and Efficient PUF-Based Key Generation Using Pattern Matching," 6 pages.
Rolf Lindemann, "FIDO Security Reference", FIDO Alliance Proposed Standard, May 14, 2015, pp. 1-30, FIDO Alliance.
Salah Machani, et al., "FIDO UAF Review Draft Spec Set", FIDO Alliance Proposed Standard, Dec. 8, 2014, pp. 1-202.
Sampath Srinivas, "Universal 2nd Factor (U2F) Overview", FIDO Alliance Proposed Standard, May 14, 2015, pp. 1-5, FIDO Alliance.
US7571489B2 (en) 2009-08-04 One time passcode system
US7865936B2 (en) 2011-01-04 System and method for controlling access to multiple public networks and for controlling access to multiple private networks
US8943311B2 (en) 2015-01-27 System and methods for online authentication
JP4617763B2 (en) 2011-01-26 Device authentication system, device authentication server, terminal device, device authentication method, and device authentication program
US8306228B2 (en) 2012-11-06 Universal secure messaging for cryptographic modules
TWI582638B (en) 2017-05-11 Electronic device, method for establishing and enforcing a security policy associated with an access control element, and secure element
US20180375848A1 (en) 2018-12-27 Un-password: risk aware end-to-end multi-factor authentication via dynamic pairing
DE102011051498A1 (en) 2012-12-06 Secure access to data in one device
US9330245B2 (en) 2016-05-03 Cloud-based data backup and sync with secure local storage of access keys
US8532620B2 (en) 2013-09-10 Trusted mobile device based security
US8997192B2 (en) 2015-03-31 System and method for securely provisioning and generating one-time-passwords in a remote device
CN104170312B (en) 2018-05-22 For using the method and apparatus that hardware security engine is securely communicated by network
US20130191632A1 (en) 2013-07-25 System and method for securing private keys issued from distributed private key generator (d-pkg) nodes
US9264426B2 (en) 2016-02-16 System and method for authentication via a proximate device
US20160119291A1 (en) 2016-04-28 Secure communication channel with token renewal mechanism
JP2004513420A (en) 2004-04-30 Method and apparatus for leveled security access control
US8719569B2 (en) 2014-05-06 User authentication system
US8074265B2 (en) 2011-12-06 Methods and systems for verifying a location factor associated with a token
US8689290B2 (en) 2014-04-01 System and method for securing a credential via user and server verification
US8739260B1 (en) 2014-05-27 Systems and methods for authentication via mobile communication device
US20090276623A1 (en) 2009-11-05 Enterprise Device Recovery
AU2015308608A1 (en) 2017-02-02 Methods for secure cryptogram generation
US20080077592A1 (en) 2008-03-27 method and apparatus for device authentication
CN102595404A (en) 2012-07-18 Methods and apparatus for storage and execution of access control clients
CN104115464A (en) 2014-10-22 Access control

redpajama_set_name: RedPajamaCommonCrawl


text:
Device Development Makes a Move
Don''t be deterred by Microsoft''s recent changes to the mobile development space.
By Dan Fergus
Change is usually good. However, sometimes too much change too quickly can be bewildering and confusing. That's how I feel about the device development space. I've always been a big advocate of Microsoft doing more to help its developer community tackle mobile development. The company is starting to respond — the folks in Redmond are now offering new products for device application developers.
Over the last few months, we've seen a lot of activity at Microsoft, from the release of SQL Server 2005 Mobile Edition to the even more recent release of Windows Mobile 6. As the hardware becomes more appealing, users will demand more from the software that is available for their mobile devices. And those of us who develop that software will have a lot to keep up with.
Take a look at databases. Way back when, if you wanted a database on a device, you used Access. But with the release of the .NET Framework, you could no longer support the Access data layer in managed code. Instead, Microsoft released a version of SQL Server 2005 for devices, a product that has been revised several times over the years.
Microsoft's most recent rev of this product is the SQL Server 2005 Compact Edition. It is truly mobile database nirvana. (Okay, maybe I exaggerate a bit, but it's an extremely useful tool.) For example, you need portability between the databases on a device and data on the desktop. Previous versions restricted your database to devices and tablets. SQL Server Compact lets you copy a database from a device to the desktop and access it as a desktop file. For those of you who still use Access, you will find an Access database synchronizer that allows you to sync data from Access to the SQL Server Compact database.
Just this month, Microsoft released another tool for device applications developers: the Service Pack 2 (SP2) of the .NET Compact Framework version 1.0 and 2.0. A big feature in SP2 is the Remote Performance Monitor. This feature helps you find those pesky memory leaks in the managed heap. You are able to take snapshots of the heap at any point in the execution of your application. With these snapshots, you can compare the allocation trends of your application across multiple executions and the live instances of objects on the heap. Plus, Microsoft fixed a long list of bugs in SP2.
But the biggest news came with the recent release of Windows Mobile 6 — a release that some may say is premature. Those of you who are just getting into device development and only beginning to adjust to Windows Mobile 5 may be concerned with compatibility problems. However, Microsoft provides an easy upgrade, and almost all types of applications written for Windows Mobile 5 will run on Windows Mobile 6 devices. Conversely, applications written after you've installed the SDK for Windows Mobile 6 are also portable back to Windows Mobile 5, provided that you do not use calls exclusive to the Windows Mobile 6 API set.
Additionally, Windows Mobile 6 introduces the Device Emulator 2.0. I often suggest using a device on the network whenever possible to debug applications in Windows Mobile 5. While that advice is still valid, your debugging experience is greatly improved if you use emulator functionality. The Device Emulator 2.0 has better performance than the previous release and many useful features, including more emulator skins, power state emulation and phone emulation.
Another new, and fun, feature in Windows Mobile 6 is FakeGPS. This utility lets you test your global positioning system (GPS) applications without actually accessing GPS feeds or a device with GPS.
Dan Fergus is the chief architect at Forest Software Group, developing .NET applications, including Pocket PC sports team applications. He speaks at major conferences, does consulting, and teaches Compact Framework, VB.NET, and ASP.NET courses. He coauthored The Definitive Guide to the .NET Compact Framework (Apress). Reach him at [email protected].


text:
Another COVID-19 like pandemic likely to strike within 60 years, says study
World Covid
60 years from now, another pandemic similar to the COVID-19 pandemic is likely to strike, warned researchers from Duke University.
As per the team, the number of new diseases spreading to humans may rise by three times over the coming decades.
"The most important takeaway is that large pandemics like COVID-19 and the Spanish flu are relatively likely," says study author Dr William Pan in University release.
Pan further highlighted that understanding that pandemics are not so rare should become a priority for health officials in charge of controlling them in the future.
The team used new statistical methods to measure the scale and frequency of outbreaks over the past four centuries.
This included a range of deadly pathogens including plague, smallpox, cholera, typhus, and novel influenza viruses.
Co-author Professor Gabriel Katul said that this is not to say it is a guarantee that the world will go virus-free for 59 years. As per the findings, such events are equally probable in any given year during the next few decades.
Prof. Katul said, "When a 100-year flood occurs today, one may erroneously presume that one can afford to wait another 100 years before experiencing another such event". He further added, "This impression is false. One can get another 100-year flood the next year."


text:
Civil War Trails
Gigapan Photos
Hanover Junction 3
Pennsylvania's railroads were prime targets for the Confederate Army prior to the Battle of Gettysburg, as Rebel troops cut telegraph wires and destroyed bridges in their efforts to isolate Washington from the rest of the Union. After the tragic Battle, President Lincoln traveled via the Northern Central to the Gettysburg battlefield, his train stopping in Hanover Junction on November 18 and 19, 1863. The station was restored to its 1863 Civil War appearance in 2001, and a Civil War museum is open to the public.
Panorama by Alan Chaffee Photography
The Battle Cry for Equality
Journey along the trail of Underground Railroad stations, abolitionist freedom fighters, and African American soldiers. This is the roadtrip of freedom-seekers.
View the Roadtrips
Discover Northern Appalachia
150th Civil War anniversary
Shop the PA Heritage Book Store
Subscribe to the visitPA newsletter
PA Tourism Office