EP2005642A1 - Procédé et appareil pour assortir une image de code externe à une clé privée sur une puce - Google Patents

Procédé et appareil pour assortir une image de code externe à une clé privée sur une puce

Info

Publication number
EP2005642A1
EP2005642A1 EP07758833A EP07758833A EP2005642A1 EP 2005642 A1 EP2005642 A1 EP 2005642A1 EP 07758833 A EP07758833 A EP 07758833A EP 07758833 A EP07758833 A EP 07758833A EP 2005642 A1 EP2005642 A1 EP 2005642A1
Authority
EP
European Patent Office
Prior art keywords
key
code
code image
encrypted
storage
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.)
Withdrawn
Application number
EP07758833A
Other languages
German (de)
English (en)
Other versions
EP2005642A4 (fr
Inventor
Peter Munguia
Dhiraj Bhatt
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.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of EP2005642A1 publication Critical patent/EP2005642A1/fr
Publication of EP2005642A4 publication Critical patent/EP2005642A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • 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

Definitions

  • Typical computing platforms use boot code to enable system start-up. Such code is a particularly attractive route for malevolent entities to gain access to such systems and thus requires protective mechanisms and/or schemes to prevent un-authorized access to the boot code or its image.
  • Current methods for protecting boot code rely on physical restrictions such as burying signal layers to or from boot devices (e.g., memory devices that store boot code or boot code images), applying material such as glue to boot devices to prevent physical access, minimizing trace lengths between devices, etc.
  • additional protection is provided in the form of a software chain of trust rooted in the boot code itself.
  • a software chain of trust originating in the boot code can be compromised if the boot code itself can be accessed or replaced with malevolent boot code.
  • FIG. 1 is a block diagram illustrating a system in accordance with some implementations of the invention.
  • Figure 2 is a block diagram illustrating a system similar to portions of the system of Fig. 1 in accordance with some implementations of the invention.
  • Figures 3-6 are flow charts illustrating processes in accordance with some implementations of the invention. DETAILED DESCRIPTION
  • FIG. 1 illustrates an example system 100 according to some implementations of the invention.
  • System 100 includes a media processor 102 coupled to a display controller 104, a cryptographic module 106, storage media 107 and a communications pathway 108.
  • System 100 also includes memory 110 (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile memory such as flash memory, etc.) coupled to pathway 108, a display 112 coupled to controller 104, and an input/output (I/O) controller 114 coupled to pathway 108.
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • I/O controller 114 input/output
  • system 100 includes wireless transmitter circuitry and wireless receiver circuitry 116 coupled to I/O controller 114 and an antenna 118 (e.g., dipole antenna, narrowband Meander Line Antenna (MLA), wideband MLA, inverted "F” antenna, planar inverted “F” antenna, Goubau antenna, Patch antenna, etc.) coupled to circuitry 116.
  • antenna 118 e.g., dipole antenna, narrowband Meander Line Antenna (MLA), wideband MLA, inverted "F” antenna, planar inverted “F” antenna, Goubau antenna, Patch antenna, etc.
  • System 100 may be any system suitable for the cryptographic processing of cryptographic keys, data or software instructions such as boot code or boot code images in accordance with implementations of the invention as will be described in greater detail below.
  • system 100 may assume a variety of physical implementations.
  • system 100 may be implemented in a personal computer (PC), a networked PC, a server computing system, a handheld computing platform (e.g., a personal digital assistant (PDA)), a gaming system (portable or otherwise), a 3D capable cellular telephone handset, etc.
  • PC personal computer
  • PDA personal digital assistant
  • gaming system portable or otherwise
  • 3D capable cellular telephone handset etc.
  • all components of system 100 may be implemented within a single device, such as a system-on-a-chip (SOC) integrated circuit (IC), components of system 100 may also be distributed across multiple ICs or devices.
  • SOC system-on-a-chip
  • media processor 102, module 106, storage 107, pathway 108, memory 110, controller 114, circuitry 116 and antenna 118 may be implemented, in part, as multiple ICs contained within a single computing platform, such as a personal computer (PC) or a set top box (STB) to name a few examples, while display controller 104 may be implemented in a separate device such as display 112 coupled to media processor 102.
  • PC personal computer
  • STB set top box
  • Media processor 102 may comprise special purpose or general purpose processor core (s) including any control and/or processing logic, hardware, software and/or firmware, capable of processing audio and/or image and/or video data and of providing display controller 104 with image and/or video data.
  • Processor 102 may also utilize cryptographic module 106 to encrypt or decrypt cipher keys, data and/or software instructions such as boot code, and may provide encrypted or decrypted keys, data and/or software instructions such as boot code to memory 110 and/or storage 107 as will be explained in greater detail below.
  • processor 102 may also include control logic for controlling access to storage media 107 and/or memory 110.
  • Processor 102 may further be capable of performing any of a number of additional tasks that support mating an external code image with an on-chip private key. These tasks may include, for example, although the invention is not limited in this regard, obtaining external code images from devices external to system 100 by, for example, downloading such code images via antenna 118, transmitter and receiver circuitry 116 and I/O controller 114. Those skilled in the art will recognize that processor 102 may undertake other support tasks such as, initializing and/or configuring registers within module 106 or controller 104, interrupt servicing, etc.
  • processor 102 may include two or more processor cores. While Fig. 1 may be interpreted as showing media processors 102 and 104 as distinct devices, the invention is not limited in this regard and those of skill in the art will recognize that media processor 102 and display controller 104 and possibly additional components of system 100 may be implemented within a single IC.
  • Display controller 104 may comprise any processing logic, hardware, software, and/or firmware, capable of converting graphics or image data supplied by media processor 102 into a format suitable for driving display 112 (i.e., display-specific data).
  • processor 104 may provide graphics and/or image and/or video data to controller 104 in a specific color format, for example in a compressed red-green-blue (RGB) pixel format, and controller 104 may process that RGB data by generating, for example, corresponding liquid crystal display (LCD) drive data levels, etc.
  • LCD liquid crystal display
  • the invention is not limited to a particular type of display 112.
  • display 112 may be any type of display such as a LCD display, or an electroluminescent (EL) display, to name a few examples.
  • Bus or communications pathway(s) 108 may comprise any mechanism for conveying information (e.g., encrypted code images, keys, etc.) between or amongst any of the elements of system 100.
  • communications pathway(s) 108 may comprise a multipurpose bus capable of conveying, for example, code images and code keys to processor 102.
  • pathway(s) 108 may comprise a wireless communications pathway
  • FIG. 2 illustrates a system 200 similar to portions of system 100 and in accordance with some implementations of the invention.
  • System 200 includes a cryptographic module (CM) 202 including encryption logic (EL) 204 and decryption logic (DL) 206, a one-time-programmable (OTP) memory 208 storing at least one private key 209, key derivation logic (KDL) 210 coupled to both OTP memory 208 and CM 202, unsecured storage 212 coupled to CM 202, secured storage 214 coupled to CM 202, and processor core(s) 216 coupled to secured storage 214 and CM 202.
  • CM cryptographic module
  • EL encryption logic
  • DL decryption logic
  • OTP key derivation logic
  • KDL key derivation logic
  • System 200 may be any system suitable for the cryptographic processing of keys, data or software instructions such as boot code or boot code images in accordance with implementations of the invention as will be described in greater detail below.
  • system 200 may assume a variety of physical implementations. While all components of system 200 may be implemented within a single device, such as a system-on-a-chip (SOC) integrated circuit (IC), components of system 100 may also be distributed across multiple ICs or devices.
  • processor core(s) 216 may comprise any special purpose or a general purpose processor core(s) including any control and/or processing logic, hardware, software and/or firmware, capable of supporting mating an external code image with an on-chip private key in accordance with implementations of the invention as will be explained in greater detail below.
  • CM 202 may comprise any processing logic, hardware, software, and/or firmware, capable of enabling the mating of an external code image with a private key in accordance with implementations of the invention as will be explained in greater detail below.
  • CM 202 may receive one or more code images (e.g., CodeA, CodeB, etc) and associated encryption keys (e.g., K A , K B , etc) from devices external to system 200.
  • CM 202 may also receive private key 209 from OTP memory 208.
  • CM 202 may receive one or more keys from derivation logic 210 where those keys have been derived from private key 209.
  • CM 202 may then use EL 204 to encrypt each code image with an associated code key and store the resulting encrypted code image in unsecured storage 212.
  • CM 202 may also use EL 204 and encryption keys such as private key 209 or the derived keys provided by derivation logic 210 to encrypt each code key and may then store the encrypted code key in unsecured storage 212 along with the associated encrypted code image.
  • CM 202 may further use DL 206 to decrypt an encrypted code key retrieved from unsecured storage 212, use that decrypted code key to decrypt an associated encrypted code image, and store the resulting decrypted or clear code key and clear code image in secured storage 214.
  • CM 202 may undertake these encryption and decryption tasks in response to commands issued by processor core(s) 216.
  • the functionality of CM 202 may be similar to that of CM 106 of Fig.1.
  • the invention is not limited to a particular type of code key and/or to a particular type of cryptographic process implemented by EL 204 and DL 206.
  • the code keys associated with the code images and provided to system 200 may be dependent on the type of encryption process used by EL 204 to encrypt the code images with the code keys.
  • the code keys may be consistent with well known Public Key Infrastructure (PKI) techniques, such as the Rivest, Shamir, and Adelman (RSA) digital signature algorithm (DSA).
  • PKI Public Key Infrastructure
  • RSA Rivest, Shamir, and Adelman
  • DSA digital signature algorithm
  • the code keys may be keys consistent with other cryptographic schemes such as symmetric keys or random unique keys, to name a few more examples.
  • Unsecured storage 212 may be, for example, any storage means that is user- accessible. In other words, the contents of storage 212 may be accessed by a user of system 200 in a conventional manner.
  • storage 212 may be a fixed nonvolatile memory device (e.g., flash memory, hard disk drive, etc.), or a removable nonvolatile memory device (e.g., a memory card containing flash memory, etc.) to name several examples.
  • storage 212 may be off-chip memory that is formed in a semiconductor substrate other than the semiconductor substrate incorporating CM 202 and/or processor core(s) 216.
  • secured storage 214 may be any storage means that is user- inaccessible.
  • storage 214 may not be accessed by a user of system 200 in a conventional manner.
  • storage 214 may be on-chip or cache memory that is formed in the same semiconductor substrate as CM 202 and/or processor core(s) 216.
  • storage 214 may comprise system memory, such as double-data-rate (DDR) random-access-memory (RAM), formed on a separate semiconductor substrate and coupled to processor core(s) 216 by a high speed system bus.
  • DDR double-data-rate
  • RAM random-access-memory
  • FIG. 2 shows private key 209 held in OTP 208, the invention is not limited in this regard, and those skilled in the art will recognize that private key 209 could be held securely in other means such as polysilicon fuses, read-only memory (ROM) or logic gates, etc.
  • FIG. 3 is a flow chart illustrating a process 300 for mating an external code image with an on-chip private key in accordance with some implementations of the invention. While, for ease of explanation, process 300 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible. While process 300 and related processes are discussed below using the example of a code image, the invention is not limited in this regard and contemplates the term code image to encompass any information confidential or otherwise, whether executable code or non-executable data. Thus the term code image encompasses a code image, a boot code image, one or more keys, or data in general, confidential or otherwise, to name several examples.
  • Process 300 may begin with the provision of a code image [act 302].
  • act 302 may be undertaken by wireless receiver 116 receiving via antenna 118 a boot code image (e.g., CodeA), and I/O controller 114 conveying that boot code image to EL 204 of CM 202 located within media processor 102.
  • Act 302 is not, however, limited to boot code images or to obtaining code images wirelessly and, thus, act 302 may comprise providing the code image through other devices (not shown) coupled to system 100 by, for example, by I/O controller 114.
  • Process 300 may continue with the provision of a code key [act 304].
  • Act 304 may be undertaken along the same lines as discussed directly above with regard to act 302.
  • Process 300 may continue with the encryption of the code image [act 306].
  • EL 204 may use the code key provided in act 304 (e.g., K A ) to encrypt the code image.
  • K A code key provided in act 304
  • EL 204 may employ well known cryptographic techniques, such as the Advanced Encryption Standard (AES) algorithm to undertake act 306.
  • AES Advanced Encryption Standard
  • Process 300 may then continue with the placement of the encrypted code image in unsecured storage [act 308].
  • Process 300 may continue with the provision of an encryption key [act 310].
  • act 308 may be undertaken by having CM 202 obtain the private key 209 from OTP 208 and employ that key as an encryption key.
  • KDL 210 and EL 204 may undertake act 310 by obtaining private key 209 from OTP 208 and using private key 209 as a root key to derive the encryption key.
  • Figure 4 is a flow chart illustrating a process 400 for providing an encryption key in accordance with some implementations of act 310 of process 300. While, for ease of explanation, process 400 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible.
  • Process 400 may begin with the provision of a master key [act 402].
  • KDL 210 may undertake act 402 by deriving a master key using well known PKI techniques and providing that master key to CM 202.
  • KDL 210 may undertake act 402 by deriving a master key using well known PKI techniques and providing that master key to CM 202.
  • the invention is not limited to hardware implementations of key derivation, such as KDL 210, and also contemplates deriving keys using, for example, an external software application to derive keys such as the master key of act 402 or similar acts.
  • Process 400 may then continue with the provision of a private key [act 404].
  • act 404 may be undertaken by having CM 202 obtain the private key 209 from OTP 208.
  • Process 400 may continue with the encryption of the master key [act 406] and the storage of the resulting encrypted master key [act 407].
  • act 406 may be undertaken by EL 204 using well known encryption techniques and the private key provided in act 404
  • act 407 may be undertaken by CM 202 providing the encrypted master key to unsecured storage 212.
  • Process 400 may then continue with the provision of a platform key [act 408] and the encryption of the platform key [act 410] using the master key.
  • Acts 408 and 410 may be undertaken in the same manner as acts 404 and 406 respectively as described above.
  • the product of act 410, the encrypted platform key may be stored [act 412] in, for example, unsecured storage 212.
  • the platform key provided in act 408 may be used as the encryption key provided in act 310 of process 300.
  • process 400 depicts the use of two keys, a master key and a platform key, the invention is not limited to particular types of keys employed in process 400 nor is the invention limited to the use of two keys in process 400. Thus, for example, additional keys may be employed in processes similar to process 400.
  • process 300 may then continue with the encryption of the code key [act 312] using the encryption key provided in act 310.
  • act 312 may be undertaken by EL 204 using well known encryption techniques to encrypt the code key with the encryption key provided in act 310.
  • Process 300 may then conclude with the placement of the encrypted code key (e.g., QK A ) in unsecured storage [act 314].
  • the encrypted code key e.g., QK A
  • One way to undertake act 314 is to have CM 202 place the encrypted code key in storage 212 in association with the corresponding code image that was encrypted with the code key in act 306.
  • process 300 may be undertaken two or more times to result in two or more encrypted code images (e.g., eCodeA(KA), eCodeB(K B ), etc.) and associated encrypted code keys (e.g., eKA, eK B , etc.) being placed in unsecured storage (e.g., storage 212).
  • the encryption of each code key may be undertaken using a different platform key unique to each code key.
  • Figure 5 is a flow chart illustrating a process 500 for mating an external code image with an on-chip private key in accordance with some implementations of the invention. While, for ease of explanation, process 500 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible.
  • Process 500 may begin with the provision of an encrypted code key [act 502].
  • act 502 may be undertaken by having CM 202, in response to one or more commands from processor core(s) 216, obtaining an encrypted code key (e.g., QK A ) from unsecured storage 212 where, for example, CM 202 had placed that encrypted code key in storage 212 in act 314.
  • Process 500 may then continue with the provision of a decryption key [act 504].
  • act 504 may be undertaken by having CM 202 obtain the private key 209 from OTP 208 and employ private key 209 as a decryption key.
  • FIG. 6 is a flow chart illustrating a process 600 for providing a decryption key in accordance with some implementations of act 504 of process 500. While, for ease of explanation, process 600 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible.
  • Process 600 may begin with the provision of an encrypted master key [act 602] .
  • CM 202 may undertake act 602 by obtaining an encrypted master key from unsecured storage 212.
  • Process 600 may then continue with the provision of a private key [act 604].
  • act 604 may be undertaken by having CM 202 obtain the private key 209 from OTP 208.
  • Process 600 may continue with the decryption of the encrypted master key [act 606].
  • act 606 may be undertaken by DL 206 using well known decryption techniques and the private key provided in act 604.
  • Process 600 may then continue with the provision of an encrypted platform key [act 608] and the decryption of the encrypted platform key [act 610] using the decrypted master key resulting from act 606.
  • Acts 608 and 610 may be undertaken in the same manner as acts 604 and 606 respectively as described above.
  • the product of act 610, the decrypted platform key may then be used as the decryption key provided in act 504 of process 500. [0035] Returning to Fig.
  • process 500 may then continue with the decryption of the encrypted code key [act 506] using the decryption key provided in act 504.
  • act 506 may be undertaken by DL 206 using well known decryption techniques to decrypt the encrypted code key with the decryption key provided in act 504.
  • Process 500 may then continue with the placement of the decrypted code key in secured storage [act 510].
  • One way to undertake act 510 is to have CM 202 place the decrypted or clear code key (e.g., K A ) in storage 214.
  • Process 500 may then continue with the provision of an encrypted code image [act 508].
  • act 508 may be undertaken by CM 202 obtaining an encrypted code image (e.g., eCodeA(K A )) from unsecured storage 212 where that encrypted code image is associated with the encrypted code key (e.g., eK ⁇ ) obtained in act 502.
  • the encrypted code image may then be decrypted [act 512] using the associated decrypted code key resulting from act 506.
  • act 512 may be undertaken by DL 206 using well known decryption techniques to decrypt the encrypted code image (e.g., eCodeA(KA)) using the associated decrypted code key (e.g., K A ).
  • Process 500 may then conclude with the placement of the decrypted code image in secured storage [act 514].
  • One way to undertake act 514 is to have CM 202 place the decrypted or clear code image (e.g., CodeA) in storage 214.
  • process 500 may be undertaken two or more times to result in two or more decrypted or clear code images (e.g., CodeA, CodeB, etc.) and associated decrypted code keys (e.g., K A , K B , etc.) being placed in secured storage (e.g., storage 214).
  • decrypted or clear code images e.g., CodeA, CodeB, etc.
  • decrypted code keys e.g., K A , K B , etc.
  • Systems 100/200 and/or processes 300-600 may, in accordance with some implementations of the invention, support hardware encrypt and decrypt functions that are destination specific (i.e., where the destination is unsecured storage versus secured storage) where those encrypt and decrypt hardware functions allow the mating of the contents of an external device (e.g., an external device providing a code image) to the IC chip containing a private key.
  • an external device e.g., an external device providing a code image
  • those encrypt and decrypt hardware functions allow the mating of multiple boot code images in a secure boot application or in storing other private keys off chip.
  • a host application having access to the chip with the private key may issue a command to the hardware function to encrypt a known code key, where the code key has been used to protect (i.e., encrypt or sign) a code image, and place the encrypted code key in unsecured storage with the encrypted code image.
  • the host application may then issue a second command to the hardware function to decrypt the encrypted code key and use the recovered code key to access (i.e., decrypt) the code image.
  • only a device or system with the private key used to create the encrypted code key can recover the code key and access the code image.
  • code image is protected by an externally provided code key
  • any number of independently protected code images may be created using distinct, independent code keys.
  • application code from different external sources may likewise be mated to the device or system holding the private key.
  • the private key is a shared secret
  • the owner of the shared secret can create the encrypted code key using an equivalent encrypt function without requiring the actual device or system (e.g., systems 100 or 200).
  • code image updates can be applied in the field and initial boot code programming can be done at manufacturing time without having to reveal the private key to the device or system customer and without having to run a special application on the device or system prior to programming the image.
  • Figs. 3-6 need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. For example, acts in processes 300, 400, 500 and/or 600 may be undertaken in parallel when processing multiple code images each having unique master and/or platform keys. In addition some acts may be undertaken before other acts. For example, the act 310 of process 300 may be undertaken prior to acts 302-308. Further, at least some of the acts in this figure may be implemented as instructions, or groups of instructions, implemented in a machine-readable medium.
  • the code images processed in processes 300 and 500 can be any arbitrary "secret" data such as a set of encryption keys or other data such as algorithm parameters.
  • many other implementations may be employed to enable mating an external code image with an on-chip private key consistent with the claimed invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un appareil, des systèmes et des procédés destinés à assortir une image de code externe à une clé privée sur une puce ainsi qu'un procédé conçu pour recevoir une image de code et une clé de code et pour chiffrer l'image de code et la clé de code si ces dernières doivent être mises dans un stockage non sécurisé. La présente invention concerne également d'autres mises en application.
EP07758833A 2006-04-07 2007-03-19 Procédé et appareil pour assortir une image de code externe à une clé privée sur une puce Withdrawn EP2005642A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US40076606A 2006-04-07 2006-04-07
PCT/US2007/064321 WO2007117879A1 (fr) 2006-04-07 2007-03-19 Procédé et appareil pour assortir une image de code externe à une clé privée sur une puce

Publications (2)

Publication Number Publication Date
EP2005642A1 true EP2005642A1 (fr) 2008-12-24
EP2005642A4 EP2005642A4 (fr) 2011-12-21

Family

ID=38581433

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07758833A Withdrawn EP2005642A4 (fr) 2006-04-07 2007-03-19 Procédé et appareil pour assortir une image de code externe à une clé privée sur une puce

Country Status (4)

Country Link
EP (1) EP2005642A4 (fr)
JP (1) JP2009525556A (fr)
CN (1) CN101433013A (fr)
WO (1) WO2007117879A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090285390A1 (en) * 2008-05-16 2009-11-19 Ati Technologies Ulc Integrated circuit with secured software image and method therefor
JPWO2016088273A1 (ja) * 2014-12-05 2017-09-07 富士通株式会社 セキュリティ装置および制御方法
CN105046138A (zh) * 2015-07-13 2015-11-11 山东超越数控电子有限公司 一种基于飞腾处理器的可信管理系统及方法
WO2020159497A1 (fr) * 2019-01-30 2020-08-06 Hewlett-Packard Development Company, L.P. Distribution sécurisée d'image de code

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1536308A2 (fr) * 2003-11-10 2005-06-01 Broadcom Corporation Système et procédé de sécurisation de code exécutable
WO2006003529A2 (fr) * 2004-04-23 2006-01-12 Securewave S.A. Chiffrement transparent et controle d'acces pour dispositifs de stockage de masse

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003303882A1 (en) * 2003-02-03 2004-08-30 Nokia Corporation Architecture for encrypted application installation
KR20040097717A (ko) * 2003-05-13 2004-11-18 펜타시큐리티시스템 주식회사 세션키 전송 방법 및 시스템
JP4691337B2 (ja) * 2003-08-26 2011-06-01 パナソニック株式会社 プログラム実行装置、認証局装置
JP2005227995A (ja) * 2004-02-12 2005-08-25 Sony Corp 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
KR100617456B1 (ko) * 2004-04-28 2006-08-31 주식회사 니츠 비밀키 관리 기능을 가지는 비밀키 단말장치 및 비밀키관리방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1536308A2 (fr) * 2003-11-10 2005-06-01 Broadcom Corporation Système et procédé de sécurisation de code exécutable
WO2006003529A2 (fr) * 2004-04-23 2006-01-12 Securewave S.A. Chiffrement transparent et controle d'acces pour dispositifs de stockage de masse

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Menezes, Vanstone, Oorschot: "Handbook of Applied Cryptography", 1997, CRC Press LLC, USA, XP002663014, * page 490 - page 491 * * page 546 - page 553 * * page 578 - page 581 * *
See also references of WO2007117879A1 *

Also Published As

Publication number Publication date
WO2007117879A1 (fr) 2007-10-18
CN101433013A (zh) 2009-05-13
EP2005642A4 (fr) 2011-12-21
JP2009525556A (ja) 2009-07-09

Similar Documents

Publication Publication Date Title
US20090323971A1 (en) Protecting independent vendor encryption keys with a common primary encryption key
US7984301B2 (en) Bi-processor architecture for secure systems
US8014530B2 (en) Method and apparatus for authenticated, recoverable key distribution with no database secrets
US7058818B2 (en) Integrated circuit for digital rights management
US9230109B2 (en) Trusted platform module security
EP3518128B1 (fr) Activation d'une application logicielle à exécuter sur un dispositif matériel
CN104252881B (zh) 半导体集成电路及系统
EP3264316B1 (fr) Utilisation de mémorisation de clé sécurisée pour lier une implémentation de boîte blanche à une plate-forme
US7571329B2 (en) Method of storing unique constant values
EP2506176A1 (fr) Établissement de clé unique durant la fabrication de puce
KR20000052797A (ko) 멀티칩 집적 회로 패키지내에서의 상호 접속 보안 회로 및 방법
US20130080764A1 (en) Secure Remote Credential Provisioning
KR20080100477A (ko) 미디어 스트림 복호화 장치, 미디어 스트림 복호화 방법 및미디어 스트림 복호화 시스템
JPH076096A (ja) データ記憶装置
JP4964945B2 (ja) 共通プライベートキーセットを利用した複数のキーラダーのサポート
US10841287B2 (en) System and method for generating and managing a key package
US20070226806A1 (en) Method and apparatus for enhancing cryptographic engines against security attacks
WO2007117879A1 (fr) Procédé et appareil pour assortir une image de code externe à une clé privée sur une puce
EP3881215B1 (fr) Méthode pour fournir une clé secrète unique pour un fpga
CN101465726B (zh) 用于秘钥的反破解方法及执行此方法的控制器与储存装置
CN102955916B (zh) 保护数字内容的方法与储存装置
KR101610182B1 (ko) 원격서비스 시스템의 클라이언트 단말기 보안장치 및 그 방법
EP2334005A1 (fr) Circuit intégré et son procédé de production associé

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080709

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/08 20060101AFI20111109BHEP

Ipc: G06F 21/00 20060101ALI20111109BHEP

A4 Supplementary search report drawn up and despatched

Effective date: 20111117

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20130307