Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20020004905 A1
Publication typeApplication
Application numberUS 09/118,147
Publication dateJan 10, 2002
Filing dateJul 17, 1998
Priority dateJul 17, 1998
Also published asUS6401208
Publication number09118147, 118147, US 2002/0004905 A1, US 2002/004905 A1, US 20020004905 A1, US 20020004905A1, US 2002004905 A1, US 2002004905A1, US-A1-20020004905, US-A1-2002004905, US2002/0004905A1, US2002/004905A1, US20020004905 A1, US20020004905A1, US2002004905 A1, US2002004905A1
InventorsDerek L Davis, Pranav Mehta
Original AssigneeDerek L Davis, Pranav Mehta
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method for bios authentication prior to bios execution
US 20020004905 A1
Abstract
A cryptographic device is implemented in communication with a host processor to prevent the host processor from performing a standard boot-up procedure until a basic input output system (BIOS) code is authenticated. This is accomplished by a cryptographic device which is addressed by the host processor during execution of a first instruction following a power-up reset. The cryptographic device includes a first integrated circuit (IC) device and a second IC device. The first IC device includes a memory to contain firmware and a root certification key. The second IC device includes logic circuitry to execute a software code to authenticate the BIOS code before permitting execution of the BIOS code by the host processor.
Images(6)
Previous page
Next page
Claims(22)
What is claimed is:
1. A system comprising:
a processor; and
a cryptographic device in communication with the processor, the cryptographic device to authenticate a software code, loaded into the cryptographic device during a boot procedure, before permitting the processor to execute the software code.
2. The system of claim 1, wherein the software code includes a basic input output system (BIOS) code.
3. The system of claim 2, wherein the cryptographic device includes
a first integrated circuit device including a memory to contain firmware and a public key of a certification authority; and
a second integrated circuit device including logic circuitry to execute the firmware to authenticate the BIOS code loaded therein.
4. The system of claim 3, wherein the first integrated circuit device and the second integrated circuit device are packaged in a multi-chip package.
5. The system of claim 1, wherein the processor and the cryptographic device are mounted on a processor substrate including an inline connector.
6. The system of claim 1, wherein the cryptographic device is connected to the processor through a dedicated bus.
7. The system of claim 2 further comprising a storage device in communication with the processor, the storage device including the BIOS code.
8. The system of claim 7, wherein the storage device further including a BIOS certificate and a BIOS signature.
9. The system of claim 8, wherein the processor including an opcode fetch emulation bit defaulting to a set state during a power-on reset condition, the opcode fetch emulation bit in the set state causing the processor to disguise a data fetch to the storage device as an instruction fetch.
10. The system of claim 9 further comprising a chipset coupled between the processor and the storage device.
11. The system of claim 10, wherein the opcode fetch emulation bit in the set state deactivates a data/control line routed between the chipset and the processor.
12. The system of claim 8, wherein during a power-on reset condition, the processor initiates an instruction fetch to a predetermined address in the internal memory of the cryptographic device.
13. The system of claim 12, wherein the cryptographic device responding to the instruction fetch by returning an instruction to the processor, the instruction preventing access to contents of the cryptographic device until the cryptographic device has been initialized.
14. The system of claim 12, wherein the cryptographic device responding to the instruction fetch by returning an instruction to the processor, the instruction prompting the processor to initiate a data read cycle to the storage device.
15. The system of claim 14, wherein the storage device provides the BIOS code to the processor for transfer to the cryptographic device in response to the data read cycle.
16. The system of claim 15, wherein the cryptographic device generates and transmits a soft reset signal to the processor after the BIOS code has been authenticated through use of the BIOS certificate and the BIOS signature.
17. A system comprising:
processor means for execution of a plurality of macro-instructions fetched from a basic input output system (BIOS) code; and
cryptographic means for authenticating the BIOS code before execution by the processor means, the cryptographic means including
first integrated circuit means for storing information used for authentication of the BIOS code, the information including firmware and a root certification key, and
second integrated circuit means for executing the firmware to postpone the processor means from performing a boot procedure and to perform a self-initialization procedure and a self-verification procedure to authenticate the BIOS code.
18. A cryptographic device comprising:
a first integrated circuit device including a memory to contain firmware and a root certification key; and
a second integrated circuit device including logic circuitry to execute the firmware to authenticate BIOS code loaded into the first integrated circuit device before permitting execution of the BIOS code during a standard boot procedure.
19. The cryptographic device of claim 18, wherein the first integrated circuit device and the second integrated circuit device are packaged in a multi-chip package.
20. The cryptographic device of claim 18, wherein the second integrated circuit device responding to an instruction fetch by returning an instruction which prevents access to contents of the cryptographic device until internal initialization of the cryptographic device has completed.
21. The cryptographic device of claim 20, wherein the cryptographic device responding to an instruction fetch by returning an instruction to a processor, the instruction causing the processor to initiate a data read cycle to a remote storage device.
22. A method comprising:
performing an instruction fetch to a predetermined address mapped to an internal memory of a cryptographic device during a power-on reset, the instruction fetch to occur before a boot procedure;
authenticating a basic input output system (BIOS) code during the power-on reset before permitting the BIOS code to be executed; and
generating a soft reset by the cryptographic device to enable the boot procedure to proceed.
Description
BACKGROUND

[0001] 1. Field

[0002] The present invention relates to the field of data security. More particularly, this invention relates to a system and method for authenticating software code before execution by the host processor.

[0003] 2. General Background

[0004] Over the last few years, computers have become products highly valued by consumers. The reason is that computers are highly versatile and enjoy a wide range of applications. Of major concern, however, is that computers, especially mobile computers such as laptops or hand-helds, are vulnerable to theft due to their commercial value and their exposure to insecure environments such as cars, hotel rooms and airport lobbies.

[0005] Currently, there exist a number of security mechanisms that are marginally effective. However, these mechanisms are still vulnerable to component or device replacement since no protected environment for execution of code and for manipulation of data is provided. For example, one type of conventional security mechanism involves the use of password software, which is normally executed after a host processor of the computer has been powered-up and has already fetched macro-instructions from Basic Input/Output System (BIOS) code residing in a Read Only Memory (ROM) device. The ROM device is physically separate from the host processor.

[0006] More specifically, during a normal power-on reset, a host processor of a conventional computer automatically jumps to a predetermined hardwired address. This address is a predetermined reset vector which is mapped to a ROM device containing the BIOS code. As a result, the host processor performs instruction fetches of BIOS code which usually prompts the computer to perform the following operations: (i) initialize its electronic hardware; (ii) initialize its peripheral devices; and (iii) boot its Operating System.

[0007] Unfortunately, the password-based security mechanism and other current security mechanisms can be easily circumvented. One way would be to replace the ROM device containing BIOS code with another memory device having a new, different BIOS code.

[0008] Additionally, due to the growing usage of networking solutions such as the Internet, computers are becoming more susceptible to invasive software virus attacks. Software viruses may be obtained during transactions over the Internet such as, for example, downloading data from either a website or an electronic bulletin board. For example, the software virus may include a program, infiltrating the BIOS code and executing in the background, that sends contents of hard disk drive over the Internet. Likewise, some of the software viruses are intended to damage the BIOS code which renders the computer inoperable.

[0009] These above-described scenarios further demonstrate the necessity in providing a protected environment for execution of code and for manipulation of data within a computer.

SUMMARY OF THE INVENTION

[0010] The present invention relates to processor in communication with a cryptographic device. The cryptographic device authenticates software code, loaded into the cryptographic device during a boot procedure, before permitting the host processor to execute the software code.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The features and advantages of the present invention will become apparent from the following detailed description of the present invention in which:

[0012]FIG. 1 is an illustrative embodiment of the electronic system practicing the present invention.

[0013]FIG. 2 is a more-detailed illustrative embodiment of the electronic system of FIG. 1.

[0014]FIG. 3 is an illustrative embodiment of the processing unit of FIG. 2.

[0015]FIG. 4 is a more-detailed embodiment of the processing unit of FIG. 3.

[0016]FIG. 5 is an illustrative block diagram of an embodiment of the cryptographic device placed by the processing unit of FIG. 4.

[0017]FIGS. 6A and 6B are an illustrative embodiment of cryptographic operations, performed by the cryptographic device, host processor and nonvolatile memory containing the BIOS code, in authenticating the BIOS code before its execution during the boot procedure.

DESCRIPTION OF AN EMBODIMENT OF THE INVENTION

[0018] The present invention relates to an electronic system and method for authenticating software code before execution by the host processor. Herein, certain examples of hardware and methods of operation are described in an illustrative sense, and should not be construed in a restrictive sense.

[0019] To clarify various qualities of the present invention, certain terminology set forth below is used to describe hardware or cryptographic-related terms. In particular, an “electronic system” is defined as any hardware with processing and internal data storage capability. Examples of electronic systems include computers (e.g., laptops, desktops, hand-held, servers, etc.), imaging equipment (e.g., printers, facsimile machines, scanners, etc.), wireless communication equipment (e.g., cellular phones, pagers, etc.), automated teller machines and the like. “Information” is defined as one or more bits of data, address, control or any combination thereof. A “bus” is any medium used to transfer information.

[0020] With respect to cryptography related terminology, a “key” is commonly defined as an encoding and/or decoding parameter. Normally, this parameter is a sequence of binary data such as (i) one or more public/private key pairs used by any public key cryptographic function (e.g., Rivest, Shamir and Adleman “RSA” related functions, Digital Signature Standard, Elliptic Curve, etc.) or (ii) a secret key shared in confidence between the two electronic systems executing any type of secret key cryptographic function (e.g., Data Encryption Standard). A “digital signature” includes digital information encrypted with a private key of its signatory to ensure that the digital information has not been illicitly modified after being digitally signed. This digital information may be provided in its entirety or as a digest produced by a one-way hash function. The “one-way hash function” includes a function, mathematical or otherwise, that converts information of a variable-length into information of a fixed-length (referred to as a “digest”). The term “one-way” indicates that there does not readily exist an inverse function to recover any discernible portion of the original information from the fixed-length digest. A “digital certificate” includes digital information used to authenticate a sender of information. For example, a digital certificate may include a public key of a person or entity being certified which is encrypted with the private key of a certification authority. Examples of a “certification authority” include an original equipment manufacturer (OEM), a software vendor, a trade association, a governmental entity, a bank or any other trusted entity.

[0021] Referring to FIG. 1, an illustrative embodiment of an electronic system 100 employing the present invention is shown. Electronic system 100 comprises a processing unit 110 and a system memory 120 coupled together by a chipset 130. System memory 120 includes a volatile memory such as any type of random access memory. Chipset 130 operates as an interface between a plurality of buses, namely a host bus 140, a memory bus 150 and a bus 160.

[0022] Referring still to FIG. 1, bus 160 provides a communication path between (i) chipset 130 and (ii) one or more peripheral devices 170 m (“m” being a positive whole number). Bus 160 may be a multiplexed bus such as a Peripheral Component Interconnect (PCI) bus, an Industry Standard Architecture (ISA) bus or any other type of bus architecture. It is contemplated that bus 160 includes a single bus (e.g., a PCI bus) as shown, or alternatively, multiple buses coupled together through bridge circuitry. In the later illustrative example, each peripheral device 170 m would be coupled to at least one of the multiple buses.

[0023] As shown for illustrative purposes, the peripheral devices 170 m comprise a storage device 170 1, a mass storage device 170 2 (e.g., a hard disk drive, a CD ROM player, CD recordable player, digital tape drive, a floppy disk drive, a digital video disk “DVD” player, etc.) and/or a transceiver device 170 3 (e.g., a network interface circuit card, a modem card, etc.). Storage device 170 1 contains actual Basic Input/Output System (BIOS) code 180 for execution by processing unit 110 as well as a digital (BIOS) certificate 181 and a digital (BIOS) signature 182. BIOS signature 182 includes a digest of BIOS code 180 signed by a private key of the BIOS vendor for example. This digest is the resultant data after running the BIOS code through a one-way hash function. BIOS certificate 181 includes a public key of the BIOS vendor signed by a private key of the certification authority.

[0024] Referring now to FIG. 2, one embodiment of processing unit 110 placed with electronic system 100 is shown. Processing unit 110 is connected to a connector 200 mounted on a system substrate 210 which is outlined by dashed lines. Controlling the overall functionality of electronic system 100, system substrate 210 typically is formed with any type of material or combination of materials upon which integrated circuit devices can be attached. Connector 200 enables communications between logic placed on system substrate 210 and processing unit 110. Any style for connector 200 may be used, provided a complementary connection is used by processing unit 110. Examples of connector 200 include, for example, a standard female edge connector (shown), a pin field connector or a socket attached to system substrate 210.

[0025] Referring now to FIG. 3, one illustrative embodiment of processing unit 110 features a processor substrate 300 formed from any type of material upon which integrated circuitry (not shown) can be attached through well-known techniques (e.g., solder connections, etc.). Processor substrate 300 is substantially covered by a package 310 in order to protect its integrated circuitry from damage or harmful contaminants. In this embodiment, processor substrate 300 includes a connector 320, which is adapted to establish a mechanical and an electrical connection with connector 200 of FIG. 2. Connector 320 includes a standard male edge connector.

[0026] Referring to FIG. 4, an illustrative embodiment of processor substrate 300 are shown. The integrated circuitry of processor substrate 300 includes a host processor 400 and a cryptographic device 410. To enable communications with host processor 400, in this embodiment, cryptographic device 410 is connected to host processor 400 through a dedicated processor bus 420. Herein, cryptographic device 410 is arranged to function as a co-processor. It is contemplated, however, that cryptographic device 410 may be connected to host bus 140 or bus 160 of FIG. 1 in lieu of dedicated processor bus 420, in which case, cryptographic device 410 would not be placed in processing unit 110. Instead, it may be mounted on system substrate 210 as an independent device or on a daughter card (not shown).

[0027] Of course, there exist many other embodiments which, although slightly different in design, do not deviate from the spirit and scope of the invention. For example, processing unit 110 may simply include a microprocessor which is mounted onto system substrate 210 along with chipset 130 and cryptographic device 410 of FIG. 4.

[0028] As further shown in FIG. 5, one embodiment of cryptographic device 410 comprises a first integrated circuit (IC) device 500 and a second IC device 520 connected by an internal bus 540. In one embodiment, the IC devices 500 and 520 are implemented within a single multi-chip package. Alternatively, IC devices 500 and 520 may be implemented as separate packaged IC devices.

[0029] Herein, second IC device 520 includes internal memory 525 and a small amount of support logic 535. Support logic 535 includes interface circuitry to handle information received from and routed to first IC device 500. Optionally, support logic 535 can include a cryptographic engine which is used by cryptographic device 410 to assist in performing various cryptographic operations in accordance with either symmetric key cryptography or asymmetric key cryptography. The cryptographic engine would operate as either a symmetric (e.g., DES-based) encryption/decryption unit or an asymmetric (e.g., RSA-based) encryption/decryption unit.

[0030] As shown, in this embodiment, internal memory 525 includes nonvolatile (NV) memory such as, for example, read only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. Internal memory 525 contains firmware 526 which is a small computer program executed by first IC device 500 for initialization and authentication purposes in order to ensure that the firmware in storage element 1701 of FIG. 1 has not been tampered with or corrupted. Internal memory 525 further contains a public key 527 of a certification authority of the cryptographic device 410 of FIG. 4 (hereinafter referred to as a “root certification key”). It is contemplated that root certification key 527 may be a public key of an OEM of the cryptographic device or a key assigned to another type of entity (e.g., trade association, governmental entity, bank, etc.) if that entity digitally signed BIOS certificate 181 of FIG. 1. The root certification key 527 is needed for certificate verification purposes.

[0031] Referring still to FIG. 5, first IC device 500 is logic circuitry 510 including a small amount of non-volatile memory 515. Logic circuitry 510 includes a processor 511, an optional random number generator 512 (as denoted by dashed lines) and a bus control unit 513. If implemented, random number generator 512 would generate the initial values used to produce key(s) contained within cryptographic device 410. The bus control unit 513 provides an interface to control the transfer of information between cryptographic device 410 and host processor 400 of FIG. 4 through dedicated processor bus 420.

[0032] Referring now to FIGS. 6A and 6B, a flowchart is provided which illustrates the operations of an embodiment of the electronic system used for verification of BIOS code to determine whether the BIOS code has been illicitly modified. If so, execution by the host processor is prevented.

[0033] As shown in blocks 605 and 610, firmware and the root certification key are initially pre-programmed into internal memory of the cryptographic device (FIG. 5) during manufacture. The firmware continues execution, including responses to instruction fetches by the host processor, after a power-on system reset in order to retrieve contents from a storage element (e.g., BIOS code) for authentication purposes.

[0034] In response to a power-on system reset (block 615), both the host processor and the cryptographic device begin their respective internal initialization (block 620). Each hardware device begins execution of internally stored microcode. After completion of its internal initialization, the host processor initiates an instruction fetch to a predetermined address that is mapped to the address range of internal memory of the cryptographic device (block 625). If the cryptographic device has not completed its internal initialization, the instruction fetch by the host processor is delayed by the cryptographic device until its internal initialization has completed (blocks 630 and 635). A technique for delaying access by the host processor includes transmission of a JUMP-to-SELF instruction back to the host processor, or insertion of wait states as shown.

[0035] Upon completing a successful internal initialization, the cryptographic device responds to the instruction fetch with a first instruction, typically a MOV instruction, from the predetermined memory location in its internal memory 525 (block 640). The MOV instruction includes, as an operand, an address falling in an address range of a legacy platform BIOS device (storage device 170 1 of FIG. 1). Upon receiving the MOV instruction, the host processor initiates a data read cycle on a front side bus with the memory address of the BIOS device provided with the MOV instruction from the cryptographic device (block 645).

[0036] In order to maintain compatibility with legacy memory controller hub and I/O controller hub devices, this data cycle is configured to appear as an instruction fetch cycle. This is accomplished by placing the host processor into a CHECK mode by setting an opcode fetch emulation bit. Herein, the architecture of the host processor includes the opcode fetch emulation bit that defaults to a “SET” state after a power-on reset. Upon detecting that the opcode fetch emulation bit is set, the host processor deasserts a data/control (D/C#) control line so that the data fetch appears to the chipset as an instruction fetch.

[0037] In block 650, the bytes read from the BIOS device are then transferred to the cryptographic device. The acts performed in blocks 640-650 are part of an iterative process which continues until the BIOS code, BIOS certificate and BIOS signature are retrieved from the BIOS device (block 655) under control of further instructions provided to the host processor by the cryptographic device. As a result, during this iterative process, the host processor temporarily operates effectively as a Direct Memory Access (DMA) device between the BIOS device and the cryptographic device.

[0038] Concurrent or subsequent to this data transfer, within the cryptographic device, the BIOS certificate is decrypted using the root certification key (block 660). This operation is performed to retrieve a public key of the signatory of the BIOS signature (e.g., BIOS vendor). Then, the preloaded digest signature is decrypted using the public key of the BIOS vendor, for example, to recover a pre-loaded digest (block 665). After recovering the pre-loaded digest, the BIOS code is read and undergoes the one-way hash function to produce a resultant digest (block 670). The resultant digest is compared to the pre-loaded digest (block 675). If no match occurs, the host processor is precluded from continuing its boot procedure (blocks 680 and 685). However, if there is a match, the BIOS code has been authenticated as valid.

[0039] As an alternative, it is contemplated that the pre-loaded digest may be a one-way hash of a portion of the BIOS code. Then, only a predetermined portion of the BIOS code needs to be read into the cryptographic device. However, this technique may be less secure than the technique discussed above.

[0040] Once the BIOS code has been authenticated, the cryptographic device generates a soft reset to the host processor (block 690). In this embodiment, the soft reset may occur through activation of a predetermined signal line. This soft reset causes the opcode fetch emulation bit to be reset, which signals the host processor to begin execution at the standard legacy reset vector to fetch its first instruction from the BIOS device to perform a normal boot procedure. In lieu of using signal line(s), as an alternative, successive software instructions may be used to reset the opcode fetch emulation bit and to jump to a particular address for the legacy reset vector.

[0041] After the opcode fetch emulation bit has been reset and execution of the legacy reset vector begins, the electronic system continues its normal boot procedure (block 695). An optional user authentication procedure may now be performed because the BIOS code has been authenticated.

[0042] In summary, the above-described operations require only slight changes in the host processor architecture by inclusion of new initial instruction fetches to a predetermined address in the address range of internal memory within the cryptographic device, an optional implementation of an opcode fetch emulation bit to signal emulation of an instruction fetch when a data fetch is being performed by the host processor, and a soft reset. As a result, this architecture and procedure maintain backward compatibility with conventional electronic systems.

[0043] While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US6782349 *May 3, 2002Aug 24, 2004International Business Machines CorporationMethod and system for updating a root of trust measurement function in a personal computer
US7200758Oct 9, 2002Apr 3, 2007Intel CorporationEncapsulation of a TCPA trusted platform module functionality within a server management coprocessor subsystem
US7216369 *Jun 28, 2002May 8, 2007Intel CorporationTrusted platform apparatus, system, and method
US7309004 *Dec 26, 2003Dec 18, 2007Diebold Self-Service Systems, Division Of Diebold, IncorporatedCash dispensing automated banking machine firmware authentication system and method
US7464256Sep 17, 2004Dec 9, 2008Aristocrat Technologies Australia Pty. LimitedBios protection device preventing execution of a boot program stored in the bios memory until the boot program is authenticated
US7467304 *Jun 22, 2006Dec 16, 2008Discretix Technologies Ltd.System, device, and method of selectively allowing a host processor to access host-executable code
US7496957 *Jan 2, 2002Feb 24, 2009Hewlett-Packard Development Company, L.P.System and method for preventing use of a wireless device
US7565553Jan 14, 2005Jul 21, 2009Microsoft CorporationSystems and methods for controlling access to data on a computer with a secure boot process
US7711952Sep 13, 2005May 4, 2010Coretrace CorporationMethod and system for license management
US7725703Jan 7, 2005May 25, 2010Microsoft CorporationSystems and methods for securely booting a computer with a trusted processing module
US7818574 *Sep 10, 2004Oct 19, 2010International Business Machines CorporationSystem and method for providing dynamically authorized access to functionality present on an integrated circuit chip
US7831869 *Nov 15, 2004Nov 9, 2010Hewlett-Packard Development Company, L.P.DDS logical data grouping
US7988039Dec 17, 2007Aug 2, 2011Diebold Self-Service Systems Division Of Diebold, IncorporatedCard activated cash dispensing automated banking machine firmware authentication system
US8019994Apr 13, 2006Sep 13, 2011Hewlett-Packard Development Company, L.P.Authentication of a request to alter at least one of a BIOS and a setting associated with the BIOS
US8060732 *Apr 13, 2007Nov 15, 2011Stmicroelectronics (Research & Development) LimitedMultiple purpose integrated circuit
US8135960 *Oct 9, 2008Mar 13, 2012International Business Machines CorporationMultiprocessor electronic circuit including a plurality of processors and electronic data processing system
US8332635May 29, 2007Dec 11, 2012International Business Machines CorporationUpdateable secure kernel extensions
US8332636Oct 2, 2007Dec 11, 2012International Business Machines CorporationSecure policy differentiation by secure kernel design
US8342395 *Jul 29, 2011Jan 1, 2013Diebold Self-Service SystemsCard activated cash dispensing automated banking machine
US8422674May 29, 2007Apr 16, 2013International Business Machines CorporationApplication-specific secret generation
US8433927May 29, 2007Apr 30, 2013International Business Machines CorporationCryptographically-enabled privileged mode execution
US8483847 *Mar 3, 2011Jul 9, 2013Kabushiki Kaisha ToshibaControl system and control method
US8495759 *Jul 28, 2009Jul 23, 2013Sii Nanotechnology Inc.Probe aligning method for probe microscope and probe microscope operated by the same
US8533442Sep 19, 2008Sep 10, 2013Aristocrat Technologies Australia Pty Ltd.BIOS protection device
US20080214309 *Jan 22, 2008Sep 4, 2008Cyberview Technology, Inc.Dynamic configuration of a gaming system
US20090285280 *Jun 22, 2006Nov 19, 2009Thomas Patrick NewberryMethod and Apparatus for Securing Digital Content
US20100031402 *Jul 28, 2009Feb 4, 2010Shigeru WakiyamaProbe aligning method for probe microscope and probe microscope operated by the same
US20110270417 *Mar 3, 2011Nov 3, 2011Kabushiki Kaisha ToshibaControl system and control method
CN1606374BOct 9, 2004Nov 23, 2011得州仪器公司Method and device bound flashing/booting for cloning prevention
EP1523203A2 *Oct 6, 2004Apr 13, 2005Texas Instruments IncorporatedDevice bound flashing/booting for cloning prevention
EP1643405A1 *Jul 21, 2005Apr 5, 2006Robert Bosch Gmbhtamper-proof microprocessor system and method of operation thereof
EP1679632A2 *Dec 19, 2005Jul 12, 2006Microsoft CorporationSystems and methods for securely booting a computer with a trusted processing module
EP1845470A1 *Apr 13, 2006Oct 17, 2007STMicroelectronics (Research & Development) LimitedMultiple purpose integrated circuit
EP1975836A2 *Mar 28, 2008Oct 1, 2008Intel Corporation (a Delaware Corporation)Server active management technology (AMT) assisted secure boot
WO2004034238A2 *Oct 7, 2003Apr 22, 2004Intel CorpEncapsulation of a tcpa trusted platform module functionality within a server management coprocessor subsystem
WO2005026951A1 *Sep 17, 2004Mar 24, 2005Aristocrat Technologies AuBios protection device
WO2006137073A2 *Jun 22, 2006Dec 28, 2006Hagai Bar-ElSystem, device, and method of selectively allowing a host processor to access host-executable code
WO2009043744A1 *Sep 22, 2008Apr 9, 2009IbmSecure policy differentiation by secure kernel design
Classifications
U.S. Classification713/193
International ClassificationG06F21/00, G06F9/445
Cooperative ClassificationG06F21/88, G06F21/575, G06F9/4401
European ClassificationG06F21/57B, G06F21/88, G06F9/44A
Legal Events
DateCodeEventDescription
Nov 20, 2013FPAYFee payment
Year of fee payment: 12
Nov 25, 2009FPAYFee payment
Year of fee payment: 8
Dec 2, 2005FPAYFee payment
Year of fee payment: 4
Jul 17, 1998ASAssignment
Owner name: INTEL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DAVIS, DEREK L.;MEHTA, PRANAV;REEL/FRAME:009349/0597;SIGNING DATES FROM 19980630 TO 19980707