US20050091496A1 - Method and system for distributed key management in a secure boot environment - Google Patents

Method and system for distributed key management in a secure boot environment Download PDF

Info

Publication number
US20050091496A1
US20050091496A1 US10693378 US69337803A US2005091496A1 US 20050091496 A1 US20050091496 A1 US 20050091496A1 US 10693378 US10693378 US 10693378 US 69337803 A US69337803 A US 69337803A US 2005091496 A1 US2005091496 A1 US 2005091496A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
module
image
authenticable
public key
verifiable
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10693378
Inventor
Chris Hyser
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett-Packard Development Co LP
Original Assignee
Hewlett-Packard Development Co LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure boot
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic 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/3236Cryptographic 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 cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic 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/3247Cryptographic 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 involving digital signatures

Abstract

A methods for preparing an authenticable and verifiable image of a software module by adding to the received software module image a size and location block, an authentication block including a cryptographically protected module-specific public key and a clear-text version of the module-specific public key, and a verification block that includes a digital signature prepared from the module image. In one particular embodiment of the present invention, a next firmware-module that is to be accessed during a secure boot process is created to include a module-specific public key, a hashed and encrypted version of the module-specific public key, and a digital signature of the firmware-module image prepared using a module-specific private key.

Description

    TECHNICAL FIELD
  • The present invention relates to secure computer systems.
  • BACKGROUND OF THE INVENTION
  • The present invention is related to computer-system security, in particular, to the process by which a secure computing platform is bootstrapped during initialization or restart of a secure computing platform, including secure firmware and optionally including a secure kernel. The techniques of the present invention are, however, potentially applicable to many other secure-computing problems.
  • FIGS. 1A-C illustrate a secure-computing-platform booting problem described below as an example of the application of one embodiment of the present invention. FIG. 1A shows a number of components of a computer system, including: (1) a processor 102; (2) a read-only memory (“ROM”) 104, soldered into the system for security reasons, discussed below, that stores the first instructions/routine 106 executed by the processor following a hard reset or boot; (3) two flash memories 108 and 110 that contain a number of firmware modules 112-117 that are run during system bootstrap, and some of which that are subsequently called as library routines through various interfaces by an operating system; (4) a system bus 120; (5) a bus bridge 122 interconnecting the system bus 120 with a peripherals bus 124; (6) an I/O controller 126 that controls a mass-storage device 128, such as a disk drive; and a system memory 130. As shown in FIG. 1A by arrow 132, following a hard reset or power on, the processor 102 is hardwired to fetch initial instructions, or, equivalently, an initial routine or set of routines 106, from the ROM memory 104. Because a secure system is to be bootstrapped, the initial routine or set of routines needs to be verifiably secure. Thus, the computer-system manufacturer creates the initial routine or routines and verifies their security, and places them on a true ROM that cannot be overwritten and can only be replaced by physically removing the ROM from the computer system. Once the initial routine or routines are executed, the computer system proceeds to successively access and execute firmware modules 112-115 incorporated into one of the flash memories 108, as shown in FIG. 1B. Then, as shown in FIG. 1C, additional firmware modules 116 and 117 in another flash memory 110 are accessed and executed. Eventually, one or intermediate phases are reached, after which an operating system kernel can be loaded from the mass-storage device 128 into memory and the operating system can be securely booted to produce a fully functional, secure computer system.
  • The bootstrap discussed above with reference to FIGS. 1A-C begins securely, with routines extracted from a true ROM memory, but when the first firmware module in flash memory is accessed, security mechanisms must be in place to validate the security of the firmware module. Flash memories may be rewritten, and can thus be maliciously altered after the computer system has been shipped from the manufacturer. While the ROM can be depended on to be secure, the first routines executed from the ROM must validate the first firmware module accessed, and each firmware module successively accessed must be verified. This verification cannot depend on retrieving information from outside of the computer system, and may not even be able to access information stored on mass-storage devices or on other peripheral devices.
  • Various techniques have been developed for facilitating a secure boot process, a portion of one example of which is illustrated in FIGS. 1A-C. There are various integrated circuits devoted specifically to security purposes, such as the Trusted Computing Platform Alliance (“TCPA”) trusted platform module (“TPM”). Certain modern computer architectures provide simple machine checking of a portion of an initial firmware image. In addition, various rather elegant cryptography-based methodologies have been proposed for general authentication and validation of software executables. However, each of these types of techniques and methodologies for addressing the secure-boot problem have attendant disadvantages and deficiencies. The TCPA TPM chip may require expensive engineering to be incorporated into a secure computing environment. The simple machine checking cannot be performed to validate and authenticate third-party firmware images loaded during a secure boot. Many of the elegant cryptography solutions require storage of cryptographic keys in ways that create vulnerabilities at the hardware level. For these reasons, designers, manufacturers and users of computing systems have recognized the need for a relatively inexpensive, secure, and reliable method for authenticating and validating firmware modules during sequential loading up and building of a secure kernel or monitor via a secure bootstrap process.
  • SUMMARY OF THE INVENTION
  • Various embodiments of the present invention provide methods for preparing authenticable and verifiable images of a software modules by adding to received software module images a size and location block, an authentication block including a cryptographically protected module-specific public key and a clear-text version of the module-specific public key, and a verification block that includes a digital signature prepared from the module image. In one particular embodiment of the present invention, a next firmware-module that is to be accessed during a secure boot process is created to include a module-specific public key, a hashed and encrypted version of the module-specific public key, and a digital signature of the firmware-module image prepared using a module-specific private key.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIGS. 1A-C illustrate a secure-computing-platform booting problem described below as an example of the application of one embodiment of the present invention.
  • FIG. 2 illustrates a basic principle underlying cryptographic methodologies.
  • FIG. 3 illustrates preparation of a firmware module compatible with the loading techniques of one embodiment of the present invention.
  • FIGS. 4-7 illustrate the firmware-module-image authentication and verification process used by a calling module to authenticate and verify a firmware module prepared as described with reference to FIG. 3.
  • DETAILED DESCRIPTION OF THE INVENTION
  • In one particular embodiment of the present invention, a next firmware-module that is to be accessed during a secure boot process is created to include a module-specific public key, a hashed and encrypted version of the module-specific public key, and a digital signature of the firmware-module image prepared using a module-specific private key. A calling firmware module that directs loading of the next firmware module, according to one embodiment of the present invention, employs a calling-module-specific public key to decrypt the hashed and encrypted module-specific public key included in the next firmware module and compare the resulting decrypted, hashed module-specific public key to a hashed, clear-text module-specific public key included in the next firmware module. If the decrypted, hashed module-specific public key is equal to a hashed, clear-text module-specific public key, then, as a second step, the calling firmware module hashes the next-firmware-module image and compares the hashed next-firmware-module image with a hashed next-firmware-module image extracted from the digital signature included within the next firmware-module image using the module-specific public key. If the two hashed firmware-module images match, then the calling firmware module is guaranteed that the next firmware-module is authentic, or, in other words, was produced by the party assumed to have produced the next firmware-module by the calling firmware module, and that the next firmware-module is verified, or, in other words, the next firmware-module has not been modified or corrupted since it was produced.
  • One embodiment of the present invention relates to a secure bootstrap process that is initiated upon power up or reset of a secure computer system and that leads to sequential access and execution of various firmware modules, and perhaps software modules, leading to an intermediate, secure state in the secure bootstrap process from which an operating system can be launched to produce a fully functional and running secure computing platform. Were all the firmware modules produced by the hardware vendor, and were all the firmware modules able to be stored in read-only memory within the computer hardware, the techniques of the present invention would be of less importance. However, modern secure computing systems are complex combinations of hardware platforms, firmware, and software secure kernels and operating systems that are not produced by a single vendor. Therefore, a flexible, but secure, technique for authenticating and verifying modules during sequential bootstrapping of a secure computing environment are of great importance in the design, manufacture, and use of secure computing systems.
  • The present invention relies on a combination of several well-known cryptographic methodologies, a summary of which is provided in a following subsection. Following the presentation of these well-known cryptographic methodologies, the present invention is described with reference to a number of block-diagram-like and control-flow-like diagrams.
  • Cryptography
  • The present invention employs cryptographic methodologies in order to secure communications between an administrative console, or host, and remote agents. In this subsection, the basic cryptographic methods employed are described in general terms. FIG. 2 illustrates a basic principle underlying cryptographic methodologies. Cryptography is designed to transform plain text information into encoded information that cannot be easily decoded by unauthorized entities. For example, FIG. 2 shows a plain text message 202 that includes an English-language sentence. This plain text message can be encrypted by any of various encryption functions E 1904 into a corresponding cipher text message 206 that is not readily interpretable. An authorized user is provided with a decryption function D 208 that allows the authorized user to decrypt the cipher text message 206 back to the plain text message 1902.
  • The basic cryptographic methods can be described using the following definitions: A m = alphabet for messages = { a m 1 , a m 2 , a m 3 a m n } A c = alphabet for cipher - text = { a c 1 , a c 2 , a c 3 a c n } M = message - space = strings of a m C = cipher - text space = strings of a c K = key space = { e 1 , e 2 e n } where E e i ( m ) c = { d 1 , d 2 d n } where D d i ( d ) m
    Plain text messages are instances of messages contained within the message space M and cipher text messages are instances of the cipher text messages contained within cipher test space C. A plain text message comprises a string of one or more characters selected from a message alphabet Am, while a cipher-text message comprises a string of one or more characters selected from the cipher-text alphabet Ac. Each encryption function E employs a key e and each decryption function D employs a key d, where the keys e and d are selected from a key space K. In a symmetric-key encryption system, the keys e and d are identical, and the secret distribution and maintenance of the symmetric keys in secret provide security. In an asymmetric-key encryption system, the keys e and d are different. The following discussion relates to asymmetric encryption systems.
  • A key pair is defined as follows:
    key pair=(e, d)
    where eεK, dεK, Dd(Ee(m))=Ee(m), and mεM
    One key of the key pair, e, is used during encryption to encrypt a message to cipher text via an encryption function E, and the other key of the key pair, d, can be used to regenerate the plain text message from the cipher-text message via a decryption function D. In symmetric.
  • Public-key cryptographic methods are encryption/decryption techniques employing key pairs (e,d) having the property that, for all key pairs (e,d), no function f(e)=d can be easily determined. Thus, the encryption key e of a public-key pair (e,d) can be freely distributed, because the corresponding decryption key d of the public-key pair cannot be determined from the encryption key e. A well-known example of public-key encryption is the RSA encryption scheme. The RSA scheme employs integer division of large numbers, generated from plain text and cipher-text messages, by large integers n that represent the product of two prime numbers p and q as follows:
    E(m)=m e mod n
    D(c)=c d mod n
    ed mod(p−1)(q−1)=1
    n=pq
    Thus, a plain text message is encrypted by considering all of the numeric representations of the characters of the message to be a large number, computing the result of raising the large number to a power equal to the encryption key e, dividing that result by n, and using the remainder of the division as the encrypted message. Decryption employs the same process, raising the cipher-text message to a power equal to the decryption key d, then regenerating the plain text message by considering the remainder, followed by division by n, as a string of numerically represented characters.
  • A digital signature is a value generated from a message that can be used to authenticate the message. The digital signature space S contains all possible digital signatures for a particular digital signature algorithm applied to messages selected from message space M. Generation of a digital signature involves a secretly held digital signature generation function SA applied to a message:
    S A(m)→s
    The digital signature s is sent, along with the message m from which the digital signature is generated, to a recipient. The recipient employs a public verification function VA to determine whether the digital signature authenticates the message or, in other words, whether the message was composed by the signer, and has not been modified in the interim. Thus, VA can be expressed, as follows:
    V A(m,s)→{true,false}
    where the result true indicates that the message m was composed by the signer who provided the digital signature s.
  • A digital-signature system can be generated from a reversible public-key encryption system, defined as follows:
    for all m, D d(E e(m))=E e(D d(m))
    where the message space, M=the cipher space, C=the digital signature space, S. The digital-signature-generating function SA can be selected as:
    SA=Dd
    so that:
    S=D d(m)
    The verification function VA can then be selected as: V A ( m , s ) = { true , if E e ( s ) = m false
  • Thus, the techniques of the public key encryption technique can be used to generate digital signatures that can, in turn, be used by a digitally signed message recipient, to verify that a message was sent by the party supplying the digital signature. While it is generally feasible to digitally sign entire, short email messages, it is rather inefficient to digitally sign large amounts of data, such as an executable image. A more efficient way to digitally sign a large amount of data, such as an executable image, is to first digitally hash the large amount of data to a hash value, and then digitally sign the hash value. An efficient hashing function is required that produces a relatively small hash value from a large amount of data in a way that generates large distances in hash-value space between hash values generated from data inputs relatively close together in data-input space. In other words, small changes to input data should widely disperse generated hash values in hash-value space, so that the hash function cannot be deduced systematically. One example of a hash function widely used for this purpose is the Secure Hash Algorithm (“SHA-1”) specified by the Secure Hash Standard, available at the web site specified by the URL: http://www.itl.nist.gov/fipspubs/fip180-1.htm. The SHA-1 secure hash algorithm generates a 160-bit hash value, called a message digest, from a data file of any length less than 264 bits in length. The SHA-1 algorithm is a secure hash because it is computationally infeasible to find a message which corresponds to a given message digest, or to find two different messages which produce the same message digest.
  • Secure-Boot Embodiment of the Present Invention
  • One embodiment of the present invention provides a method by which a calling firmware module or combination of firmware modules can authenticate and verify a next firmware module that needs to accessed, possibly executed, and incorporated into the processing environment of a secure computing system. FIG. 3 illustrates preparation of a firmware-module image compatible with the authentication and verification techniques of one embodiment of the present invention. FIG. 3 includes both block diagrams and flow-control-like annotations.
  • The process of constructing the authenticable and verifiable firmware-module image begins with a firmware image 301 that includes an image size, location, and globally unique identifier (“GUID”) header (“ISLGUID”) 302 that serves to describe the size and location of the firmware image within a flash memory or other non-volatile memory and to identify, via the GUID, the class of machines for which the firmware module has been created. By accessing the ISLGUID header, a calling module accessing firmware-module can determine where to find additional information in order to authenticate and verify the firmware module. Note that the ISLGUID block does not necessarily need to be a header, as shown in FIG. 3, but may be incorporated into the firmware-module image at any specific, commonly known location to allow access by a calling module.
  • In a next step in the preparation of the authenticable and verifiable firmware-module image, a secure hash function, such as the SHA-1 secure hash function described above, is used to hash a public encryption key (“PK2P”) 303 associated with the firmware module to produce a hashed public key, or message digest, 304 corresponding to the public key “PK2P.” Next, the firmware-module developer provides the hashed public key “PK2P” to the vendor of the calling firmware module, who uses a private key “PK1V305 to encrypt the hashed PK2P 304 to produce an encrypted, hashed, module-specific public key “PK2P*” 306 that the calling-firmware-module vendor returns to the firmware-module developer. The hashed, encrypted public key “PK2P*” 306 is placed, along with the clear-text version of public key “PK2P” into an authentication header 308 that is prepended to the firmware-module image 301. The private key “PK1V” is a secret key used by the vender or manufacturer of the calling firmware module. In general, the private key “PK1V” will be kept secure by the calling module's manufacturer, never disclosing the private key “PK1V” to any third party. Because the encryption key “PK2P” is a public encryption key associated with the firmware-module image, the public encryption key “PK2P” can be freely furnished by the vendor of the firmware-module image to third parties.
  • Next, the agreed-upon secure hash algorithm is used to hash the contents of the firmware-module image 301, excluding the prepended authentication header 308, and the resulting message digest is encrypted with a private encryption key “PK2V310 corresponding to the public encryption key “PK2P303. The hashing and encryption operations are shown in FIG. 3 as step 312. The hashing and encryption of the firmware-module image 312 produces a digital signature which is appended to the firmware-module image as a verification footer 314.
  • The completed authenticatable and verifiable firmware module thus comprises an authentication header 308 including a hashed and encrypted public key “PK2*P” and clear-text version of the public key “PK2P,” the firmware module 301 including an ISLGUID block 302, and a verification footer that includes a digital signature 314. Note that both the authentication header 308 and verification footer 314 may be alternatively included within the firmware module at specific, commonly known locations, may be both prepended or appended to the firmware module, or may be packaged as discrete entities along with the firmware module. In the discussed embodiment, the authentication block is prepended as a header and the verification block is appended as a footer, as shown in FIG. 3.
  • FIGS. 4-7 illustrate the firmware-module-image authentication and verification process used by a calling module to authenticate and verify a firmware module prepared as described with reference to FIG. 3. The accessed firmware module is referred to as the “next firmware module.” In FIG. 4, the calling firmware module 402 is shown abstractly incorporated within the current execution environment of a secure computer system 404. Note that the calling module includes a stored version of the calling module's public encryption key “PK1P406.
  • FIG. 5 illustrates the first step of the authentication process that represents a portion of one embodiment of the present invention. In FIG. 5, the calling module 402 accesses the ISLGUID block 302 of the next firmware module. The calling module 402 accesses the ISLGUID block in order to first check the GUID included in the ISLGUID to make sure that the next firmware module is intended for the machine on which it has been loaded, and to then determine the sizes and locations of the relevant portions of the next firmware module, including the authentication header 308, the firmware-module image 301, and the verification footer 314.
  • As shown in FIG. 6, the calling module 402 next accesses the authentication header, extracting from the authentication header the hashed, encrypted public encryption key “PK2P*” associated with the next firmware module 306. The calling module 402 then employs its public key “PK1P406 to decrypt the encrypted, hashed public key “PK2P*” to produce a hashed public key “PK2P602. Then, the calling module 402 extracts the clear-text public encryption key “PK2P” from the authentication header 308 and hashes the clear-text public encryption key “PK2P604, and then compares 606 the extracted hashed PK2P with the decrypted, hashed PK2P 602 in order to determine whether or not the next firmware module is an authentic firmware module. If the decrypted, hashed PK2P 602 is identical to the extracted hashed PK2P 604, then the next firmware module is an authentic firmware module produced by the firmware module vendor after receiving the hashed, encrypted public encryption key “PK2P*” from the vendor of the calling module 402. After the next firmware module is authenticated, the verification portion of the authentication and verification process ensues, described below with respect to FIG. 7. Otherwise, as indicated by the negative arrow 608 in FIG. 6, the authentication portion of the authentication and verification process fails, and the calling module 402 may take appropriate action. The calling module 402 may, for example, display an authentication failure message to a console and terminate the bootstrap process.
  • The verification portion of the authentication and verification process that represents one embodiment of the present invention is illustrated in FIG. 7. In the verification portion of the process, the calling module hashes the firmware-module image 301, including the ISLGUID block 302, and then compares 707 the hashed firmware-module image 706 with a hashed firmware-module image 708 obtained by extracting the digital signature stored in the verification footer 314 appended to the firmware module and decrypting 709 the digital signature with the module-specific public encryption key “PK2P.” If the extracted and decrypted digital signature is equal to the digital signature 706 produced in the hashing step 702, then the next firmware-module image has been both authenticated and verified, as indicated by the positive arrow 710 in FIG. 7. Otherwise as indicated by the negative arrow 712 in FIG. 7, the verification step has failed. Again, the calling module can take appropriate steps upon failure and success.
  • The authentication portion of the authentication and verification process thus authenticates a next firmware module as having been produced by the expected vendor. No other vendor or malicious firmware producer can include the hashed and encrypted public key “PK2P*” into the authentication header 308. The verification portion of the authentication and verification process ensures that the firmware-module image produced by the authenticated firmware vendor has not been altered or corrupted since being produced by the firmware-module vendor. By undertaking the authentication and verification process illustrated in FIGS. 4-7, the calling module can confidently access, execute, and/or incorporate the next firmware-module image within the secure-system execution environment without compromising the security of the secure system.
  • Although the present invention has been described in terms of a particular embodiment, it is not intended that the invention be limited to this embodiment. Modifications within the spirit of the invention will be apparent to those skilled in the art. For example, as discussed above, a next firmware-module image may include the ISLGUID block, authentication block, and verification block in various different locations within the authenticatable and verifiable firmware-module image. While the technique of one embodiment of the present invention has been described with respect to a secure-boot procedure that sequentially accesses, executes, and/or incorporates firmware modules into a secure system, the same technique can be applied to software modules and to other instruction-containing entities. Specific cryptographic methodologies are used in the disclosed embodiment, but many comparable and equally effective cryptographic methodologies may alternatively be employed. For example, various different secure hash algorithms are available, and it may be possible to employ another method to produce a small, easily encrypted portion of a next image.
  • The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the invention. The foregoing descriptions of specific embodiments of the present invention are presented for purpose of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously many modifications and variations are possible in view of the above teachings. The embodiments are shown and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents:

Claims (18)

  1. 1. A method for preparing an authenticable and verifiable image of a module, the method comprising:
    receiving a module image;
    adding to the module image a size and location block;
    adding to the module image an authentication block including a cryptographically protected module-specific public key and a clear-text version of the module-specific public key to produce an authenticable image; and
    adding to the authenticable image a verification block that includes a digital signature prepared from the module image.
  2. 2. The method of claim 1 wherein adding to the module image a size and location block further includes:
    adding, in a specific location, a header that includes an image size, location, and globally unique identifier describes a size and location of the firmware image within a flash memory or other non-volatile memory and that identifies a class of machines for which the firmware module has been created.
  3. 3. The method of claim 1 wherein adding to the module image an authentication block including a cryptographically protected module-specific public key and a clear-text version of the module-specific public key to produce an authenticable image further includes:
    adding to the module image an authentication block including an encrypted, hashed module-specific public key and a clear-text version of the module-specific public key to produce an authenticable image.
  4. 4. The method of claim 1 wherein adding to the authenticable image a verification block that includes a digital signature prepared from the module image further includes:
    adding to the authenticable image a verification block that includes a digital signature prepared by hashing the module image and encrypting the hashed module image with a module-specific private key.
  5. 5. Computer instructions that together compose a program that carries out the method of method of claim 1 stored in computer readable medium.
  6. 6. A method for authenticating and verifying an authenticable and verifiable module, the method comprising:
    extracting, from the authenticable and verifiable module, a module-specific public key and cryptographically protected data related to the module-specific public key;
    comparing the cryptographically protected data with the module-specific public key to authenticate the authenticable and verifiable module;
    comparing a value calculated from an image, including a size and location block, included within the authenticable and verifiable module a value extracted from a digital signature contained in a verification block within the authenticable and verifiable image to verify the authenticable and verifiable module.
  7. 7. The method of claim 6 wherein extracting, from the authenticable and verifiable module, a module-specific public key and cryptographically protected data related to the module-specific public key further includes:
    extracting, from an authentication block at a known location within the authenticable and verifiable image, an encrypted, hashed module-specific public key and a clear-text version of the module-specific public key.
  8. 8. The method of claim 7 wherein comparing the cryptographically protected data with the module-specific public key to authenticate the authenticable and verifiable image further includes:
    hashing the clear-text version of the module-specific public key to produce a newly hashed module-specific public key;
    decrypting the encrypted, hashed module-specific public key using a first private encryption key; and
    comparing the decrypted, hashed module-specific public key with the newly hashed module-specific public key.
  9. 9. The method of claim 8 wherein, when the decrypted, hashed module-specific public key is identical to the newly hashed module-specific public key, the authenticable and verifiable image is determined to be authenticated.
  10. 10. The method of claim 6 wherein comparing a value calculated from an executable image, including a size and location block, included within the authenticable and verifiable image a value extracted from a digital signature contained in a verification block within the authenticable and verifiable image to verify the authenticable and verifiable image further includes:
    hashing an executable image, including a size and location block, included within the authenticable and verifiable image to produce a newly hashed image;
    extracting a digital signature from a verification block within the authenticable and verifiable image, and decrypting the digital signature using the module-specific public key to produce an extracted hashed image;
    comparing the extracted hashed image to the newly hashed image.
  11. 11. The method of claim 10 wherein, when the extracted hashed image is identical to the newly hashed image, the authenticable and verifiable image is determined to be verified.
  12. 12. The method of claim 6 employed during secure access, execution, and/or incorporation of the authenticable and verifiable image into a secure-computer processing environment, wherein, when the authenticable and verifiable image is authenticated and verified by the method of claim 6, the authenticable and verifiable image is accessed, executed, and/or incorporated, and when the authenticable and verifiable image is not authenticated or not verified, the authenticable and verifiable image is not executed and/or incorporated.
  13. 13. The method of claim 12 employed in the secure booting of a secure computer system, wherein, when an authenticable and verifiable image is not executed and/or incorporated, the secure boot fails.
  14. 14. Computer instructions that together compose a program that carries out the method of method of claim 6 stored in computer readable medium.
  15. 15. An authenticable and verifiable image of an module stored in a computer-readable medium comprising:
    a module image, including a size, location, and globally unique-identifier block;
    an authentication block; and
    a verification block.
  16. 16. An authenticable and verifiable image of an module of claim 15 wherein the authentication block contains an encrypted, hashed module-specific public key and a clear-text version of the module-specific public key to produce an authenticable image.
  17. 17. An authenticable and verifiable image of an module of claim 15 wherein the verification block that includes a digital signature prepared by hashing the module image and encrypting the hashed module image with a module-specific private key.
  18. 18. A method for preparing an authenticable and verifiable image of a module, the method comprising:
    a module-image receiving step;
    a size-and-location-data adding step that adds size-and-location data to the received module image;
    an authentication-adding step that adds, to the module image, authentication information including a cryptographically protected module-specific public key and a clear-text version of the module-specific public key; and
    a verification-block-adding step that adds a digital signature prepared from the module image to the module image.
US10693378 2003-10-23 2003-10-23 Method and system for distributed key management in a secure boot environment Abandoned US20050091496A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10693378 US20050091496A1 (en) 2003-10-23 2003-10-23 Method and system for distributed key management in a secure boot environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10693378 US20050091496A1 (en) 2003-10-23 2003-10-23 Method and system for distributed key management in a secure boot environment
US12260153 US8250373B2 (en) 2003-10-23 2008-10-29 Authenticating and verifying an authenticable and verifiable module

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12260153 Division US8250373B2 (en) 2003-10-23 2008-10-29 Authenticating and verifying an authenticable and verifiable module

Publications (1)

Publication Number Publication Date
US20050091496A1 true true US20050091496A1 (en) 2005-04-28

Family

ID=34522377

Family Applications (2)

Application Number Title Priority Date Filing Date
US10693378 Abandoned US20050091496A1 (en) 2003-10-23 2003-10-23 Method and system for distributed key management in a secure boot environment
US12260153 Active US8250373B2 (en) 2003-10-23 2008-10-29 Authenticating and verifying an authenticable and verifiable module

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12260153 Active US8250373B2 (en) 2003-10-23 2008-10-29 Authenticating and verifying an authenticable and verifiable module

Country Status (1)

Country Link
US (2) US20050091496A1 (en)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060174055A1 (en) * 2005-02-02 2006-08-03 Insyde Software Corporation System and method for reducing memory requirements of firmware
US20070061570A1 (en) * 2005-09-14 2007-03-15 Michael Holtzman Method of hardware driver integrity check of memory card controller firmware
US20070061581A1 (en) * 2005-09-14 2007-03-15 Micky Holtzman Methods used in a secure yet flexible system architecture for secure devices with flash mass storage memory
US20070067617A1 (en) * 2005-09-16 2007-03-22 Nokia Corporation Simple scalable and configurable secure boot for trusted mobile phones
US20070192610A1 (en) * 2006-02-10 2007-08-16 Chun Dexter T Method and apparatus for securely booting from an external storage device
WO2007104899A1 (en) * 2006-03-16 2007-09-20 Thomson Licensing Method for robust software updating
US20080163383A1 (en) * 2006-12-29 2008-07-03 Kumar Mohan J Methods and apparatus for authenticating components of processing systems
US20080267406A1 (en) * 2004-11-22 2008-10-30 Nadarajah Asokan Method and Device for Verifying The Integrity of Platform Software of an Electronic Device
US20080320311A1 (en) * 2007-06-20 2008-12-25 Samsung Electronics Co. Apparatus and method for authenticating firmware
WO2009047438A1 (en) * 2007-09-18 2009-04-16 Thomson Licensing Semi-permament application hosting
US20090110190A1 (en) * 2007-10-30 2009-04-30 Sandisk Il Ltd. Fast secure boot implementation
US20090113558A1 (en) * 2007-10-26 2009-04-30 Qualcomm Incorporated Progressive boot for a wireless device
US20090144559A1 (en) * 2007-10-12 2009-06-04 Samsung Electronics Co., Ltd. Electronic device booted up with security, a hash computing method, and a boot-up method thereof
US20090172377A1 (en) * 2007-12-26 2009-07-02 Shay Gueron Method and apparatus for booting a processing system
US20090327741A1 (en) * 2008-06-30 2009-12-31 Zimmer Vincent J System and method to secure boot uefi firmware and uefi-aware operating systems on a mobile internet device (mid)
US20100083349A1 (en) * 2007-09-14 2010-04-01 China Iwncomm Co., Ltd Method for realizing trusted network management
US7743409B2 (en) 2005-07-08 2010-06-22 Sandisk Corporation Methods used in a mass storage device with automated credentials loading
US7913074B2 (en) 2007-09-28 2011-03-22 Microsoft Corporation Securely launching encrypted operating systems
US20110138164A1 (en) * 2009-12-04 2011-06-09 Lg Electronics Inc. Digital broadcast receiver and booting method of digital broadcast receiver
US20120321089A1 (en) * 2009-11-09 2012-12-20 Siemens Aktiengesellsghaft Method and System for Confidentially Providing Software Components
US20130151861A1 (en) * 2011-12-08 2013-06-13 Raytheon Company System and method to protect computer software from unauthorized use
US20130156017A1 (en) * 2010-12-28 2013-06-20 Sanyo Electric Co., Ltd. Terminal apparatus for transmitting or receiving a signal including predetermined information
US20170109533A1 (en) * 2009-10-13 2017-04-20 Google Inc. Firmware verified boot

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8312431B1 (en) * 2004-09-17 2012-11-13 Oracle America, Inc. System and computer readable medium for verifying access to signed ELF objects
US7752428B2 (en) * 2005-03-31 2010-07-06 Intel Corporation System and method for trusted early boot flow
US8589698B2 (en) * 2009-05-15 2013-11-19 International Business Machines Corporation Integrity service using regenerated trust integrity gather program
US8938796B2 (en) 2012-09-20 2015-01-20 Paul Case, SR. Case secure computer architecture
US9965639B2 (en) * 2015-07-17 2018-05-08 International Business Machines Corporation Source authentication of a software product

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5754659A (en) * 1995-12-22 1998-05-19 General Instrument Corporation Of Delaware Generation of cryptographic signatures using hash keys
US6185678B1 (en) * 1997-10-02 2001-02-06 Trustees Of The University Of Pennsylvania Secure and reliable bootstrap architecture
US6253324B1 (en) * 1997-06-30 2001-06-26 Microsoft Corporation Server verification of requesting clients
US6381693B2 (en) * 1998-12-31 2002-04-30 Intel Corp. Arrangements having firmware support for different processor types
US6401201B2 (en) * 1998-12-31 2002-06-04 Intel Corporation Arrangements offering firmware support for different input/output (I/O) types
US6425081B1 (en) * 1997-08-20 2002-07-23 Canon Kabushiki Kaisha Electronic watermark system electronic information distribution system and image filing apparatus
US6519762B1 (en) * 1998-12-15 2003-02-11 Dell Usa, L.P. Method and apparatus for restoration of a computer system hard drive
US20030161475A1 (en) * 2002-02-28 2003-08-28 Crumly James D. Encryption of digitized physical information based on physical tags
US20040019785A1 (en) * 2002-07-24 2004-01-29 Hawkes Philip Michael Efficient encryption and authentication for data processing systems
US6959184B1 (en) * 1999-06-30 2005-10-25 Lucent Technologies Inc. Method for determining the security status of transmissions in a telecommunications network
US7007159B2 (en) * 2002-05-10 2006-02-28 Intel Corporation System and method for loading and integrating a firmware extension onto executable base system firmware during initialization
US7073059B2 (en) * 2001-06-08 2006-07-04 Hewlett-Packard Development Company, L.P. Secure machine platform that interfaces to operating systems and customized control programs

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010007131A1 (en) * 1997-09-11 2001-07-05 Leonard J. Galasso Method for validating expansion roms using cryptography
US6263431B1 (en) * 1998-12-31 2001-07-17 Intle Corporation Operating system bootstrap security mechanism

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5754659A (en) * 1995-12-22 1998-05-19 General Instrument Corporation Of Delaware Generation of cryptographic signatures using hash keys
US6272631B1 (en) * 1997-06-30 2001-08-07 Microsoft Corporation Protected storage of core data secrets
US6253324B1 (en) * 1997-06-30 2001-06-26 Microsoft Corporation Server verification of requesting clients
US6425081B1 (en) * 1997-08-20 2002-07-23 Canon Kabushiki Kaisha Electronic watermark system electronic information distribution system and image filing apparatus
US6185678B1 (en) * 1997-10-02 2001-02-06 Trustees Of The University Of Pennsylvania Secure and reliable bootstrap architecture
US6519762B1 (en) * 1998-12-15 2003-02-11 Dell Usa, L.P. Method and apparatus for restoration of a computer system hard drive
US6381693B2 (en) * 1998-12-31 2002-04-30 Intel Corp. Arrangements having firmware support for different processor types
US6401201B2 (en) * 1998-12-31 2002-06-04 Intel Corporation Arrangements offering firmware support for different input/output (I/O) types
US6959184B1 (en) * 1999-06-30 2005-10-25 Lucent Technologies Inc. Method for determining the security status of transmissions in a telecommunications network
US7073059B2 (en) * 2001-06-08 2006-07-04 Hewlett-Packard Development Company, L.P. Secure machine platform that interfaces to operating systems and customized control programs
US20030161475A1 (en) * 2002-02-28 2003-08-28 Crumly James D. Encryption of digitized physical information based on physical tags
US7007159B2 (en) * 2002-05-10 2006-02-28 Intel Corporation System and method for loading and integrating a firmware extension onto executable base system firmware during initialization
US20040019785A1 (en) * 2002-07-24 2004-01-29 Hawkes Philip Michael Efficient encryption and authentication for data processing systems

Cited By (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080267406A1 (en) * 2004-11-22 2008-10-30 Nadarajah Asokan Method and Device for Verifying The Integrity of Platform Software of an Electronic Device
US8954738B2 (en) * 2004-11-22 2015-02-10 Core Wireless Licensing, S.a.r.l. Method and device for verifying the integrity of platform software of an electronic device
US7603562B2 (en) * 2005-02-02 2009-10-13 Insyde Software Corporation System and method for reducing memory requirements of firmware
US8468331B2 (en) * 2005-02-02 2013-06-18 Insyde Software Corp. Reducing memory requirements of firmware
US20060174055A1 (en) * 2005-02-02 2006-08-03 Insyde Software Corporation System and method for reducing memory requirements of firmware
US20090327738A1 (en) * 2005-02-02 2009-12-31 Insyde Software Corporation Reducing memory requirements of firmware
US7743409B2 (en) 2005-07-08 2010-06-22 Sandisk Corporation Methods used in a mass storage device with automated credentials loading
US7748031B2 (en) 2005-07-08 2010-06-29 Sandisk Corporation Mass storage device with automated credentials loading
US8220039B2 (en) 2005-07-08 2012-07-10 Sandisk Technologies Inc. Mass storage device with automated credentials loading
US7934049B2 (en) * 2005-09-14 2011-04-26 Sandisk Corporation Methods used in a secure yet flexible system architecture for secure devices with flash mass storage memory
US20070061597A1 (en) * 2005-09-14 2007-03-15 Micky Holtzman Secure yet flexible system architecture for secure devices with flash mass storage memory
US20070061581A1 (en) * 2005-09-14 2007-03-15 Micky Holtzman Methods used in a secure yet flexible system architecture for secure devices with flash mass storage memory
US20070061897A1 (en) * 2005-09-14 2007-03-15 Michael Holtzman Hardware driver integrity check of memory card controller firmware
US20070061570A1 (en) * 2005-09-14 2007-03-15 Michael Holtzman Method of hardware driver integrity check of memory card controller firmware
US8966284B2 (en) 2005-09-14 2015-02-24 Sandisk Technologies Inc. Hardware driver integrity check of memory card controller firmware
US20080215847A1 (en) * 2005-09-14 2008-09-04 Sandisk Corporation And Discretix Technologies Ltd. Secure yet flexible system architecture for secure devices with flash mass storage memory
US20070067617A1 (en) * 2005-09-16 2007-03-22 Nokia Corporation Simple scalable and configurable secure boot for trusted mobile phones
EP1934882A4 (en) * 2005-09-16 2010-12-22 Nokia Corp Simple scalable and configurable secure boot for trusted mobile phones
US8201240B2 (en) 2005-09-16 2012-06-12 Nokia Corporation Simple scalable and configurable secure boot for trusted mobile phones
EP1934882A2 (en) * 2005-09-16 2008-06-25 Nokia Corporation Simple scalable and configurable secure boot for trusted mobile phones
WO2007095465A3 (en) * 2006-02-10 2008-01-10 Dexter Tamio Chun Method and apparatus for securely booting from an external storage device
WO2007095465A2 (en) * 2006-02-10 2007-08-23 Qualcomm Incorporated Method and apparatus for securely booting from an external storage device
KR101049647B1 (en) 2006-02-10 2011-07-14 콸콤 인코포레이티드 From an external storage device, a method and apparatus for securely booting
US20070192610A1 (en) * 2006-02-10 2007-08-16 Chun Dexter T Method and apparatus for securely booting from an external storage device
US8291226B2 (en) 2006-02-10 2012-10-16 Qualcomm Incorporated Method and apparatus for securely booting from an external storage device
WO2007104899A1 (en) * 2006-03-16 2007-09-20 Thomson Licensing Method for robust software updating
US20120265998A1 (en) * 2006-12-29 2012-10-18 Kumar Mohan J Methods And Apparatus For Authenticating Components Of Processing Systems
US20080163383A1 (en) * 2006-12-29 2008-07-03 Kumar Mohan J Methods and apparatus for authenticating components of processing systems
US8209542B2 (en) * 2006-12-29 2012-06-26 Intel Corporation Methods and apparatus for authenticating components of processing systems
US8832457B2 (en) * 2006-12-29 2014-09-09 Intel Corporation Methods and apparatus for authenticating components of processing systems
US20080320311A1 (en) * 2007-06-20 2008-12-25 Samsung Electronics Co. Apparatus and method for authenticating firmware
US20100083349A1 (en) * 2007-09-14 2010-04-01 China Iwncomm Co., Ltd Method for realizing trusted network management
US8230220B2 (en) * 2007-09-14 2012-07-24 China Iwncomm Co., Ltd. Method for realizing trusted network management
WO2009047438A1 (en) * 2007-09-18 2009-04-16 Thomson Licensing Semi-permament application hosting
US7913074B2 (en) 2007-09-28 2011-03-22 Microsoft Corporation Securely launching encrypted operating systems
US20090144559A1 (en) * 2007-10-12 2009-06-04 Samsung Electronics Co., Ltd. Electronic device booted up with security, a hash computing method, and a boot-up method thereof
US20090113558A1 (en) * 2007-10-26 2009-04-30 Qualcomm Incorporated Progressive boot for a wireless device
US8683213B2 (en) 2007-10-26 2014-03-25 Qualcomm Incorporated Progressive boot for a wireless device
US20090110190A1 (en) * 2007-10-30 2009-04-30 Sandisk Il Ltd. Fast secure boot implementation
US8127363B2 (en) * 2007-12-26 2012-02-28 Intel Corporation Method and apparatus for booting a processing system
US20090172377A1 (en) * 2007-12-26 2009-07-02 Shay Gueron Method and apparatus for booting a processing system
US20090327741A1 (en) * 2008-06-30 2009-12-31 Zimmer Vincent J System and method to secure boot uefi firmware and uefi-aware operating systems on a mobile internet device (mid)
US20170109533A1 (en) * 2009-10-13 2017-04-20 Google Inc. Firmware verified boot
US20120321089A1 (en) * 2009-11-09 2012-12-20 Siemens Aktiengesellsghaft Method and System for Confidentially Providing Software Components
US9542537B2 (en) * 2009-11-09 2017-01-10 Siemens Aktiengesellschaft Method and system for confidentially providing software components
US20110138164A1 (en) * 2009-12-04 2011-06-09 Lg Electronics Inc. Digital broadcast receiver and booting method of digital broadcast receiver
US8583909B2 (en) * 2009-12-04 2013-11-12 Lg Electronics Inc. Digital broadcast receiver and booting method of digital broadcast receiver
US20130156017A1 (en) * 2010-12-28 2013-06-20 Sanyo Electric Co., Ltd. Terminal apparatus for transmitting or receiving a signal including predetermined information
US8725649B2 (en) * 2011-12-08 2014-05-13 Raytheon Company System and method to protect computer software from unauthorized use
US20130151861A1 (en) * 2011-12-08 2013-06-13 Raytheon Company System and method to protect computer software from unauthorized use

Also Published As

Publication number Publication date Type
US8250373B2 (en) 2012-08-21 grant
US20090055658A1 (en) 2009-02-26 application

Similar Documents

Publication Publication Date Title
Seshadri et al. Swatt: Software-based attestation for embedded devices
US6625729B1 (en) Computer system having security features for authenticating different components
US7194092B1 (en) Key-based secure storage
US7243230B2 (en) Transferring application secrets in a trusted operating system environment
US7380136B2 (en) Methods and apparatus for secure collection and display of user interface information in a pre-boot environment
US7103779B2 (en) Method and apparatus for incremental code signing
US6532542B1 (en) Protected storage of core data secrets
US7568114B1 (en) Secure transaction processor
US7159240B2 (en) Operating system upgrades in a trusted operating system environment
US20050251857A1 (en) Method and device for verifying the security of a computing platform
US7107463B2 (en) Manifest-based trusted agent management in a trusted operating system environment
US7181016B2 (en) Deriving a symmetric key from an asymmetric key for file encryption or decryption
US20050166024A1 (en) Method and apparatus for operating multiple security modules
US20050257073A1 (en) Method and system for bootstrapping a trusted server having redundant trusted platform modules
US20060288232A1 (en) Method and apparatus for using an external security device to secure data in a database
US6647494B1 (en) System and method for checking authorization of remote configuration operations
US6389535B1 (en) Cryptographic protection of core data secrets
US20050210287A1 (en) Secure mode controlled memory
US20030140238A1 (en) Implementation of a secure computing environment by using a secure bootloader, shadow memory, and protected memory
US20080130893A1 (en) Methods and systems for utilizing cryptographic functions of a cryptographic co-processor
US6009524A (en) Method for the secure remote flashing of a BIOS memory
US6263431B1 (en) Operating system bootstrap security mechanism
US20100169667A1 (en) Protecting content on client platforms
US20090086979A1 (en) Virtual tpm keys rooted in a hardware tpm
US20100287363A1 (en) Method and system for secure software provisioning

Legal Events

Date Code Title Description
AS Assignment

Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HYSER, CHRIS D.;REEL/FRAME:015175/0621

Effective date: 20031120