US20080310622A1 - E-fuses for storing security version data - Google Patents

E-fuses for storing security version data Download PDF

Info

Publication number
US20080310622A1
US20080310622A1 US12/055,647 US5564708A US2008310622A1 US 20080310622 A1 US20080310622 A1 US 20080310622A1 US 5564708 A US5564708 A US 5564708A US 2008310622 A1 US2008310622 A1 US 2008310622A1
Authority
US
United States
Prior art keywords
data
security version
version parameter
security
secure
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
US12/055,647
Inventor
Robert A. Drehmel
William E. Hall
Russell D. Hoover
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US12/055,647 priority Critical patent/US20080310622A1/en
Publication of US20080310622A1 publication Critical patent/US20080310622A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols 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 communications; Network security protocols 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
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11CSTATIC STORES
    • G11C17/00Read-only memories programmable only once; Semi-permanent stores, e.g. manually-replaceable information cards
    • G11C17/14Read-only memories programmable only once; Semi-permanent stores, e.g. manually-replaceable information cards in which contents are determined by selectively establishing, breaking or modifying connecting links by permanently altering the state of coupling elements, e.g. PROM
    • G11C17/16Read-only memories programmable only once; Semi-permanent stores, e.g. manually-replaceable information cards in which contents are determined by selectively establishing, breaking or modifying connecting links by permanently altering the state of coupling elements, e.g. PROM using electrically-fusible links

Definitions

  • the present invention generally relates to data encryption and, more particularly, to methods and apparatus for updating parameters used for encryption, such as version control parameters.
  • a system on a chip generally includes one or more integrated processor cores, some type of embedded memory, such as a cache shared between the processors cores, and peripheral interfaces, such as memory control components and external bus interfaces, on a single chip to form a complete (or nearly complete) system.
  • SOC system on a chip
  • Some type of embedded memory such as a cache shared between the processors cores
  • peripheral interfaces such as memory control components and external bus interfaces
  • some SOCs encrypt some portions of data prior to storing it in external memory. Adding such encryption to an SOC may add valuable benefits, such as preventing a hacker from obtaining instructions of a copyrighted program, such as a video game, or data that may be used to determine such instructions through reverse engineering.
  • the encrypted data When the encrypted data is subsequently retrieved from external memory, it must first be decrypted before it can be used by the processor cores.
  • the encryption is typically carried out with the use of one or more encryption keys generated, in some way, based on a master key. Often the master key is unique to the device, in an effort to ensure no two devices perform encryption in the exact same way.
  • a security version parameter (hereinafter, simply the version) maintained on the system may be used in combination with the encryption, in an effort to provide some degree of flexibility regarding how and on what encryption is performed.
  • a current version may reflect a current state of privileges a user has, in effect, determining what content the user may access. As an example, in a gaming system a user may purchase and download a new game.
  • the version may be updated and used to encrypt the game program, with the game, in encrypted form, marked as having been encrypted using the updated version.
  • system validation logic may compare the current version of the system against the version used to encrypt the game to verify the system is authorized to run the game. If the versions match, the game will be decrypted and allowed to run, otherwise it will not.
  • NVRAM battery-backed non-volatile random access memory
  • batteries are expensive and the reliance on batteries introduces complexity as designers must deal with the possibility of having to restore values in the event battery voltage is lost.
  • storing master key and version data in external memory invites attacks by hackers attempting to gain unauthorized access.
  • some systems utilize tamper detection hardware designed to notify the system in the event unauthorized access is detected, which also increases system cost.
  • a mechanism for storing Master Key and version information that does not require batteries.
  • a mechanism for storing Master Key and version information would allow Master Key and version information to be maintained internal to a device, such as an SOC, implementing security.
  • the present invention generally provides methods and devices for dynamically updating security version parameters stored in persistent storage.
  • One embodiment provides a method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor.
  • the method generally includes maintaining a security version parameter in persistent storage on the processor, wherein blocks of secure data are encrypted as a function of the security version parameter and dynamically changing the security version parameter by modifying the contents of the persistent storage.
  • Another embodiment provides a method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor.
  • the method generally includes maintaining a security version parameter and master key data in persistent storage on the processor, encrypting a block of secure data, generating an integrity check value for the block of secure data, wherein at least one of the encrypting and the generating is performed as a function of the security version parameter, storing the encrypted block of secure data in the external memory, and dynamically changing the security version parameter by modifying the contents of the persistent storage.
  • the device generally includes first persistent storage elements for storing a security version parameter, second persistent storage elements for storing master key data, an encryption engine configured to encrypt secure blocks of data to be stored in the external memory, wherein at least one of: the encrypted secure blocks or an integrity check value generated therefore are affected by the security version parameter, and a mechanism for modifying the first persistent storage elements to update the security version parameter without modifying previously modified first persistent storage elements.
  • Another embodiment provides a method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor.
  • the method generally includes maintaining a security version parameter and master key data in persistent storage on the processor and storing first and second copies of an encrypted data structure in external memory, wherein at least one of: the encrypted data structure or an integrity check value calculated therefor are affected by the security version parameter.
  • the security version parameter may be updated without modifying the contents of the persistent storage.
  • the first copy of the encrypted data structure may be overwritten with a new encrypted data structure, wherein at least one of: the encrypted data structure or an integrity check value calculated therefor are affected by the updated security version parameter.
  • the first copy of the new encrypted data structure may be read back and validated.
  • the persistent storage may be updated to reflect the updated security version parameter only if the first copy of the new encrypted data structure is valid.
  • FIG. 1 illustrates an exemplary system including a CPU, in which embodiments of the present invention may be utilized.
  • FIGS. 2A-2B are block diagrams illustrating data flow through the CPU, according to one embodiment of the present invention.
  • FIGS. 3A and 3B illustrate different configurations of persistent storage, according to exemplary embodiments of the present invention.
  • FIG. 4 is a flow diagram of exemplary operations for initializing secure operations utilizing master key and version data in persistent storage according to one embodiment of the present invention.
  • FIG. 5 is a flow diagram of exemplary operations for secure runtime operations utilizing master key and version data in persistent storage according to one embodiment of the present invention.
  • FIG. 6 is a flow diagram of exemplary operations for secure updating of version data in persistent storage according to one embodiment of the present invention.
  • Embodiments of the present invention may be utilized in systems to dynamically update a security version parameter used to encrypt and/or validate secure data.
  • the version may be maintained in persistent storage located on a device implementing the encryption, such as a system on a chip (SOC).
  • SOC system on a chip
  • the persistent storage does not require battery backing and, thus, the cost and complexity associated with conventional systems utilizing battery backed storage may be reduced.
  • an additional level of security may be achieved, by avoiding inadvertent or intentional (e.g., initiated by a hacker) rollback of versions.
  • security metadata generally refers to any type of data used during any part of the encryption process.
  • security metadata may include such data as encryption keys, version numbers, and the like, used to encrypt and/or validate data.
  • secure data refers to data that is to be encrypted when stored external to an encryption-enabled device, such as an SOC
  • non-secure data refers to data that may be stored externally in non-encrypted form.
  • plaintext data that is non-secure
  • ciphertext data that is encrypted is referred to herein as ciphertext.
  • the CPU 110 may include one or more processor cores 112 , which may each include any number of different type functional units including, but not limited to arithmetic logic units (ALUs), floating point units (FPUs), and single instruction multiple data (SIMD) units. Examples of CPUs utilizing multiple processor cores include the PowerPC® line of CPUs, available from International Business Machines (IBM) of Armonk, N.Y.
  • IBM International Business Machines
  • each processor core 112 may have access to its own primary (L 1 ) cache 114 , as well as a larger shared secondary (L 2 ) cache 116 .
  • L 1 primary
  • L 2 shared secondary
  • copies of data utilized by the processor cores 112 may be stored locally in the L 2 cache 116 , preventing or reducing the number of relatively slower accesses to external main memory 140 .
  • data utilized often by a processor core 112 may be stored in its L 1 cache 114 , preventing or reducing the number of relatively slower accesses to the L 2 cache 116 .
  • the CPU 110 may communicate with external devices, such as a graphics processing unit (GPU) 130 and/or a memory controller 136 via a system or frontside bus (FSB) 128 .
  • the CPU 110 may include an FSB interface 120 to pass data between the external devices and the processing cores 112 (through the L 2 cache) via the FSB 128 .
  • An FSB interface 132 on the GPU 130 may have similar components as the FSB interface 120 , configured to exchange data with one or more graphics processors 134 , input output (I/O) unit 138 , and the memory controller 136 (illustratively shown as integrated with the GPU 130 ).
  • the FSB interface 120 may include any suitable components, such as a physical layer (not shown) for implementing the hardware protocol necessary for receiving and sending data over the FSB 128 .
  • a physical layer may exchange data with an intermediate “link” layer which may format data received from or to be sent to a transaction layer.
  • the transaction layer may exchange data with the processor cores 112 via a core bus interface (CBI) 118 .
  • CBI core bus interface
  • the CPU 110 may encrypt some portions of data, referred to herein as secure data, prior to storing it in main memory 140 (such encrypted portions of data are illustratively shown as secure data 142 in main memory 140 ).
  • the CPU 110 may include a security component 150 used to encrypt secure data prior to transmission over the FSB 128 by the FSB interface 120 .
  • the security component 150 may also be used to decrypt the encrypted secure data prior to passing it into the L 2 cache 116 for use by one or more of the processor cores 112 .
  • the security component 150 may employ any suitable encryption algorithms or combination of algorithms for encryption/decryption, including, but not limited to algorithms utilizing whitening keys, hash keys, and/or Advanced Encryption Standard (AES) keys. For some embodiments, one or more of these keys may be generated based on a master key 162 stored in persistent storage 160 located on the CPU 110 . For other embodiments, the master key 162 may be used to protect these keys, for example, by encrypting a data structure containing the keys or used to generate the keys. As will be described in greater detail below, encryption may also utilize a security version parameter (version 164 ) also stored in persistent storage 160 .
  • version 164 security version parameter
  • information regarding the key(s), as well as the version 164 used for encryption, and/or validation of encrypted data may be encrypted and stored externally, as a secure block of data, shown as security metadata 144 .
  • security metadata 144 may be retrieved for validation and/or decryption purposes.
  • the version 164 may actually be used to encrypt data (e.g., as an input to an encryption algorithm implemented in hardware or software). However, for other embodiments, the version 164 may be used to generate an integrity check value (a checksum or hash value) on a block of encrypted data. In either case, the encrypted data may be validated against a current version. For example, if the data was encrypted using a different version, the decrypted data would not validate. Similarly, an integrity check value for the encrypted data were generated with a different version would not match an integrity check value generated with the current version.
  • an integrity check value for the encrypted data were generated with a different version would not match an integrity check value generated with the current version.
  • FIG. 2A is a block diagram that illustrates the flow of both secure and non-secure data through the CPU, in accordance with one embodiment of the present invention, for example, as data is read into the cache from main memory and written out from the cache to main memory. Such data flow may take place, for example, when loading instructions and/or data of a program, such as a game program, into the CPU 110 for execution. While not shown, flow control logic configured to identify and route secure and non-secure data in accordance with FIG. 2A may be included in the FSB interface 120 .
  • data received from cache will typically be unencrypted (plaintext) regardless of whether the data is secure or non-secure. If the data is not secure, the plaintext data is written directly out to external memory. Any suitable technique may be utilized to determine if the data is secure. As an example, a specific address range may be reserved for secure data. As another example, secure data may be identified by one or more bit settings in a page table entry, for example, indicating a corresponding cache line is secure. In any case, if the data is secure, the plaintext data is routed to an encryption engine 152 of the security component 150 for encryption. The encryption engine 152 encrypts the secure data and returns the secure data encrypted (as ciphertext).
  • an integrity check value may be calculated based on the secure data in plaintext and/or ciphertext form, to allow for subsequent authentication to ensure the encrypted data was not modified (tampered with).
  • this integrity check value may also be stored externally, as metadata 144 , or internally.
  • the encryption engine 152 may encrypt the plaintext data using the master key 162 (and/or other keys) and version 164 stored in persistent storage 160 . Accordingly, a change in version 164 results in different encryption (e.g., different ciphertext given the same plaintext), thus providing a convenient mechanism to vary the encryption.
  • the decryption engine 154 may also use the master key 162 (and/or other keys) and version 164 to decrypt ciphertext data retrieved from external memory.
  • the encryption engine may perform encryption and decryption using the updated security version (shown as VERSION +1), prior to actually storing the updated security version in persistent storage 160 .
  • Select logic 155 may allow the encryption and decryption engines to select the proper version.
  • data retrieved from external memory that is not secure is forwarded on to the cache, as no decryption is required. If the data is secure, however, the data is ciphertext and, therefore, is routed to a decryption engine 154 of the security component 150 for decryption. In some cases, information regarding the keys and version data used for encryption (metadata 144 ) may also be retrieved with the secure data. As will be described in further detail below, for some embodiments, a validation component 170 may be configured to compare the version data retrieved with the current version 164 in persistent storage 160 to ensure the current system is authorized to access the secure data.
  • encryption/decryption engines implemented in hardware
  • some or all of the encryption and/or validation operations described herein and shown in the Figures may be performed in software (e.g., running in a secure environment).
  • software may have direct access (via the CPU) to the master key and/or version information stored in persistent storage, instead of or in addition to the hardware security component. Accordingly, the concepts described herein related to storing version information in persistent storage may be used to advantage in systems utilizing hardware encryption, software encryption, or any combination thereof.
  • the current version 164 in persistent storage 160 of the system may be updated periodically, for example, to reflect a user's current set of security privileges that may determine what secure data that user is authorized to access.
  • the persistent storage 160 should be some type of storage that allows writing.
  • the persistent storage 160 should be such that, once storage elements thereof are programmed, they may not be subsequently modified.
  • the persistent storage 160 may be configured to provide monotonic updates in one direction with time, such as a version value that may only be increased.
  • e-Fuses electrically programmable fuses, commonly referred to as e-Fuses.
  • a first set of e-Fuses 302 1 . . . 302 N may be used to store master key information
  • a second set of e-Fuses 304 1 . . . 304 M may be used to store version information.
  • fuse control logic 310 may be included In such embodiments, to blow the e-Fuses 302 - 304 by applying a high blow voltage (V BLOW ) to fuses, as indicated by e-Fuse programming data (which may be a simple bit string indicating which fuses are to be blown).
  • V BLOW high blow voltage
  • the fuse control logic 310 may also be used to readout the state of the fuses 302 - 304 which may subsequently be latched into registers accessible by the security component 150 .
  • the next available e-Fuse 304 may be blown. Accordingly, arbitrarily assuming fuses are blown from left to right, the rightmost fuse may be indicative of the current version. For many applications, it may not be critical that the next e-Fuse 304 in sequence be blown, but may be sufficient that the version is changed to a new value (which will result in different encryption).
  • the fuse control logic 310 may be configured to monitor the state of any e-Fuse 304 being blown and, if the e-Fuse 304 does not blow (e.g., within a given period of time), the next fuse may be blown instead. While this may have the effect of skipping some versions (e.g., if fuse 304 100 will not blow but 304 101 will, “version 100 ” may be skipped).
  • version and master key information may be stored in different types of persistent storage.
  • the master key information might not be changed during the life of the product, master key information may be stored in laser fuses 322 1 - 322 N rather than e-Fuses, as illustrated in FIG. 3B .
  • the laser fuses 322 1 - 322 N may be blown during a manufacturing process, while the device containing them is still in wafer form, which may be convenient for system (e.g., game box, PC, etc.) manufacturers.
  • the device e.g., CPU
  • one advantage to storing the master key in e-fuses is that system manufactures incorporating the devices in their products may be able to set the master keys themselves.
  • Suitable persistent storage may include electrically erasable programmable read-only memory (EEPROM) or flash memory.
  • EEPROM electrically erasable programmable read-only memory
  • systems utilizing EEPROM or flash memories may include control circuitry to ensure that previously written storage elements (memory cells) cannot be modified, while still allowing subsequent storage elements to be programmed.
  • control circuitry may be configured to permanently disable writing to all addresses below an address currently being written.
  • FIG. 4 is a flow diagram of exemplary operations for initializing master key and version data, according to one embodiment of the present invention.
  • the operations 400 assume that the master key information is stored in some type of persistent storage that is writable at run time.
  • the operations 400 begin, at step 402 , by booting the system.
  • the first time the system is booted it may do so in a non-secure mode.
  • a master key is generated, for example, based on a hardware random number generator (not shown).
  • the master key is stored in persistent storage.
  • an initial security version is obtained.
  • the initial security version may simply be the initial state of the persistent storage, such as the initial (e.g., un-blown or partially blown) state of eFuses.
  • the initial security may be predetermined, for example, to reflect a current version of a product. In such cases, the predetermined security version may be stored in persistent storage, at step 410 .
  • the device may enter a secure mode, whereby secure data is encrypted using the master key and current version.
  • the master key and security version may be used to encrypt data structures to be stored in external memory, such as a data structure containing security key sets.
  • the security version may be stored and encrypted with the data, to allow later comparison against the current security version when retrieving the encrypted data structure.
  • the initial security version is put in a data structure to be encrypted and, at step 414 , the data structure is encrypted using the initial security version and master key information.
  • the encrypted data structure is stored in external (e.g., FLASH) memory.
  • At step 418 at least one additional copy of the encrypted data structure is stored in external memory.
  • maintaining more than one copy of the encrypted data structure may ensure at least one good copy of the encrypted data is available even if one or more other copies become invalid for some reason, such as tampering or some type of writing error, which may allow data to be recovered in the occurrence of some such event. Maintaining multiple copies may also allow recovery in the event that updates to the encrypted data structure (e.g., to grant/revoke privileges as described below), which may involve relatively lengthy operations, are interrupted for any reason, such as an unexpected loss of power. For example, by maintaining multiple copies, even if one copy becomes corrupted, if the other copy is good it may be used to restore the corrupted copy.
  • FIG. 5 is a flow diagram of exemplary operations 500 for secure runtime operations utilizing version information, according to one embodiment of the present invention.
  • the operations 500 assume that multiple copies (illustratively, two) of an encrypted secure data structure have been stored in external memory, for example, as shown in the operations 400 described above. Further, for illustrative purposes, the operations 500 are assumed to be performed in a game system. However, one skilled in the art will recognize that similar operations may be performed to provide secure operations in a wide variety of different type systems.
  • the operations 500 begin, at step 502 , by retrieving a first copy of the encrypted data structure and validating the secure data structure using a current security version.
  • the validation may involve generating an integrity check value for the retrieved data structure using the current security version or decrypting the retrieved data structure using the current security version.
  • the first copy of the data structure is valid, as determined at step 504
  • the second copy of the data structure is retrieved and validated, at step 512 . If the second copy of the data structure is also valid, as determined at step 514 , redundancy is maintained and an operations mode is entered, at step 522 .
  • recovery procedures may be attempted in an effort to maintain redundancy. For example, if the first copy is not valid, a recovery procedure may be attempted, at step 508 , wherein the first copy is overwritten with the second copy, after which the operations may return to step 502 , to determine if the recovery procedure was successful in restoring the first copy. Alternatively, if the second copy is not valid, a recovery procedure may be attempted, at step 518 , wherein the second copy is overwritten with the first copy, after which the operations may return to step 512 to determine if the recovery procedure was successful in restoring the second copy.
  • invalid copies may be the result of unrecoverable problems (e.g., irreparable portions of external memory) there may be a maximum allowable number of retries that, if exceeded (as determined at steps 506 and 516 ), may result in failures (steps 510 and 520 ), for example, not allowing the system to enter into an operational mode.
  • unrecoverable problems e.g., irreparable portions of external memory
  • a loop of operations ( 524 - 536 ) is entered, in which one of two basic operations is performed: a game is played or privileges are updated. If a game is to be played, as determined at step 524 , the game is loaded using current security and privilege settings, at step 526 . Once the game is over, as determined at step 528 , the loop of operations is entered again.
  • a user may choose to update privileges, for example, to gain some new type of desired functionality. For example, a user may initially receive a first set of privileges when purchasing a game system. This first set of privileges may authorize the user to play a first set of games supplied with the system. The privileges may be stored (in external memory) in the data structure encrypted using a security version setting that shipped with the game system. To play any additional games may require additional privileges, which may be requested by a user, for example, via an online purchase.
  • an update procedure to securely modify the privilege information and security version is performed, at step 532 . If the update procedure is successful, the user's account is charged, at step 536 and the system is rebooted, at step 540 , to reflect the update privilege information. On the other hand, if the update procedure is not successful, the user's account is not charged, at step 538 . However, the system may still be rebooted, for example, in an effort restore one of the copies of the secure data structure which (as will be described in greater detail below) may have been corrupted during the failed update procedure.
  • FIG. 6 illustrates exemplary operations 600 for an update procedure to modify the secure data structure (e.g., to reflect a change in privileges) and update a security version.
  • the secure data structure e.g., to reflect a change in privileges
  • FIG. 6 illustrates exemplary operations 600 for an update procedure to modify the secure data structure (e.g., to reflect a change in privileges) and update a security version.
  • privilege updates may require modifying the security version. For example, if certain privileges are not to be revoked, and the user is paying for the updates, privilege information may be updated in the secure data structure without modifying the security version used to encrypt the data structure.
  • the operations 600 begin, at step 602 , by receiving a request to update the security structure with a new security version.
  • a test is performed to determine if both copies of the data structure stored in external memory are valid (e.g., by decrypting and/or generating an integrity check value using the current security version). If both copies of the current data structure are not valid, a recovery procedure may be attempted, at step 608 . As previously described, a recovery procedure may involve overwriting an invalid copy of the data structure with a valid copy. The validation operations of step 604 may then be repeated. In some cases, if a maximum number of retries is exceeded, as determined at step 606 , a failure may be reported, at step 610 .
  • the data structure is modified (e.g., to reflect a change in privileges) and the current security version is incremented, at step 612 .
  • the new data structure is encrypted (and/or an integrity check value is generated) using the new security version.
  • only one copy of the data structures in external memory may be overwritten until the security version is successfully updated in persistent storage, possibly allowing recovery in the event of a failure in writing the new data structure to external memory or in writing the new security information to persistent storage.
  • the first copy of the data structure in external memory is overwritten with the new data structure.
  • the new data structure is read back from external memory and validated. If the copy read back is not valid, indicating a possible write failure, the operations 616 - 620 may be repeated, up to a maximum number of retries, after which a failure may be reported, at step 626 (e.g., resulting in the user not being charged for updates, per step 538 of FIG. 5 ).
  • the persistent storage is modified to reflect the incremented security version, for example, by burning one or more fuses, at step 628 .
  • updates to the persistent storage may not be successful, for example, due to faulty storage elements (e.g., fuses that will not burn).
  • a test may be performed to determine if the update to persistent storage is successful, for example, by performing a read back of fuses, at step 630 . If a fuse did not burn successfully, attempts to burn the fuse may be repeated, up until a maximum number of retries for that fuse. For some embodiments, the particular fuse burned may not be matter, for example if a security version is reflected by a total number of fuses burned.
  • the blow operations may be repeated with a different (e.g., the next) fuse selected, at step 636 . If the fuse limit has been reached, a failure may be reported, at step 628 .
  • the second copy of the data structure in external memory is overwritten with the new data structure, at step 640 , and secure update procedure is complete.
  • the second copy of the data structure may be read back and validated. Recall, however (referring back to FIG. 5 ), that after updating the data structure, the system may be rebooted (step 540 ) causing the first and second copies of the data structure to be validated (at steps 502 and 512 , respectively).
  • Storing security versions in persistent, but changeable, storage may allow such version information to be stored securely while still providing the flexibility to change the versions while the system is running.
  • Changing the version information while the system is running may allow privileges to be granted and/or revoked dynamically.
  • data structures containing the privilege information may be encrypted and validated using security version information.

Abstract

Methods and devices that may be utilized in systems to dynamically update a security version parameter used to encrypt secure data are provided. The version may be maintained in persistent storage located on a device implementing the encryption, such as a system on a chip (SOC). The persistent storage does not require battery backing and, thus, the cost and complexity associated with conventional systems utilizing battery backed storage may be reduced.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application is a continuation of co-pending U.S. patent application Ser. No. 10/892,431, filed Jul. 15, 2004, which is hereby incorporated by reference in its entirety.
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention generally relates to data encryption and, more particularly, to methods and apparatus for updating parameters used for encryption, such as version control parameters.
  • 2. Description of the Related Art
  • A system on a chip (SOC) generally includes one or more integrated processor cores, some type of embedded memory, such as a cache shared between the processors cores, and peripheral interfaces, such as memory control components and external bus interfaces, on a single chip to form a complete (or nearly complete) system. The use of cache memory hierarchies is well established to improve a processor performance by reducing and/or eliminating read access requests to external main memory.
  • As part of an enhanced security feature, some SOCs encrypt some portions of data prior to storing it in external memory. Adding such encryption to an SOC may add valuable benefits, such as preventing a hacker from obtaining instructions of a copyrighted program, such as a video game, or data that may be used to determine such instructions through reverse engineering. When the encrypted data is subsequently retrieved from external memory, it must first be decrypted before it can be used by the processor cores.
  • The encryption is typically carried out with the use of one or more encryption keys generated, in some way, based on a master key. Often the master key is unique to the device, in an effort to ensure no two devices perform encryption in the exact same way. In some cases, a security version parameter (hereinafter, simply the version) maintained on the system may be used in combination with the encryption, in an effort to provide some degree of flexibility regarding how and on what encryption is performed. A current version may reflect a current state of privileges a user has, in effect, determining what content the user may access. As an example, in a gaming system a user may purchase and download a new game. As part of the process of installing the new game on the system, the version may be updated and used to encrypt the game program, with the game, in encrypted form, marked as having been encrypted using the updated version. Upon loading the game, system validation logic may compare the current version of the system against the version used to encrypt the game to verify the system is authorized to run the game. If the versions match, the game will be decrypted and allowed to run, otherwise it will not.
  • In conventional systems, master key and version data are often stored in battery backed registers or external nonvolatile storage, such as battery-backed non-volatile random access memory (NVRAM). Unfortunately, batteries are expensive and the reliance on batteries introduces complexity as designers must deal with the possibility of having to restore values in the event battery voltage is lost. Further, storing master key and version data in external memory invites attacks by hackers attempting to gain unauthorized access. To combat this, some systems utilize tamper detection hardware designed to notify the system in the event unauthorized access is detected, which also increases system cost.
  • Accordingly, what is needed is a mechanism for storing Master Key and version information that does not require batteries. Preferably, such a mechanism would allow Master Key and version information to be maintained internal to a device, such as an SOC, implementing security.
  • SUMMARY OF THE INVENTION
  • The present invention generally provides methods and devices for dynamically updating security version parameters stored in persistent storage.
  • One embodiment provides a method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor. The method generally includes maintaining a security version parameter in persistent storage on the processor, wherein blocks of secure data are encrypted as a function of the security version parameter and dynamically changing the security version parameter by modifying the contents of the persistent storage.
  • Another embodiment provides a method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor. The method generally includes maintaining a security version parameter and master key data in persistent storage on the processor, encrypting a block of secure data, generating an integrity check value for the block of secure data, wherein at least one of the encrypting and the generating is performed as a function of the security version parameter, storing the encrypted block of secure data in the external memory, and dynamically changing the security version parameter by modifying the contents of the persistent storage.
  • Another embodiment provides a device for encrypting blocks of data to be stored in memory external to the device. The device generally includes first persistent storage elements for storing a security version parameter, second persistent storage elements for storing master key data, an encryption engine configured to encrypt secure blocks of data to be stored in the external memory, wherein at least one of: the encrypted secure blocks or an integrity check value generated therefore are affected by the security version parameter, and a mechanism for modifying the first persistent storage elements to update the security version parameter without modifying previously modified first persistent storage elements.
  • Another embodiment provides a method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor. The method generally includes maintaining a security version parameter and master key data in persistent storage on the processor and storing first and second copies of an encrypted data structure in external memory, wherein at least one of: the encrypted data structure or an integrity check value calculated therefor are affected by the security version parameter. The security version parameter may be updated without modifying the contents of the persistent storage. The first copy of the encrypted data structure may be overwritten with a new encrypted data structure, wherein at least one of: the encrypted data structure or an integrity check value calculated therefor are affected by the updated security version parameter. The first copy of the new encrypted data structure may be read back and validated. The persistent storage may be updated to reflect the updated security version parameter only if the first copy of the new encrypted data structure is valid.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • So that the manner in which the above recited features, advantages and objects of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.
  • It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
  • FIG. 1 illustrates an exemplary system including a CPU, in which embodiments of the present invention may be utilized.
  • FIGS. 2A-2B are block diagrams illustrating data flow through the CPU, according to one embodiment of the present invention.
  • FIGS. 3A and 3B illustrate different configurations of persistent storage, according to exemplary embodiments of the present invention.
  • FIG. 4 is a flow diagram of exemplary operations for initializing secure operations utilizing master key and version data in persistent storage according to one embodiment of the present invention.
  • FIG. 5 is a flow diagram of exemplary operations for secure runtime operations utilizing master key and version data in persistent storage according to one embodiment of the present invention.
  • FIG. 6 is a flow diagram of exemplary operations for secure updating of version data in persistent storage according to one embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Embodiments of the present invention may be utilized in systems to dynamically update a security version parameter used to encrypt and/or validate secure data. The version may be maintained in persistent storage located on a device implementing the encryption, such as a system on a chip (SOC). The persistent storage does not require battery backing and, thus, the cost and complexity associated with conventional systems utilizing battery backed storage may be reduced. Further, by utilizing persistent storage that does not allow previously written storage elements to be re-written (erased) an additional level of security may be achieved, by avoiding inadvertent or intentional (e.g., initiated by a hacker) rollback of versions.
  • As used herein, the term security metadata generally refers to any type of data used during any part of the encryption process. For example, security metadata may include such data as encryption keys, version numbers, and the like, used to encrypt and/or validate data. As used herein, the term secure data refers to data that is to be encrypted when stored external to an encryption-enabled device, such as an SOC, while the term non-secure data refers to data that may be stored externally in non-encrypted form. Data that is non-encrypted (whether secure or non-secure) is referred to herein as plaintext while data that is encrypted is referred to herein as ciphertext. These terms are used for convenience and do not imply the encrypted or non-encrypted data is actually textual data.
  • In the following, reference is made to embodiments of the invention. It should be understood, however, that the invention is not limited to any specific embodiments described herein. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. However, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and, unless explicitly present, are not considered elements or limitations of the appended claims.
  • An Exemplary System
  • Referring now to FIG. 1, an exemplary computer system 100 including a central processing unit (CPU) 110 is illustrated, in which embodiments of the present invention may be utilized. As illustrated, the CPU 110 may include one or more processor cores 112, which may each include any number of different type functional units including, but not limited to arithmetic logic units (ALUs), floating point units (FPUs), and single instruction multiple data (SIMD) units. Examples of CPUs utilizing multiple processor cores include the PowerPC® line of CPUs, available from International Business Machines (IBM) of Armonk, N.Y.
  • As illustrated, each processor core 112 may have access to its own primary (L1) cache 114, as well as a larger shared secondary (L2) cache 116. In general, copies of data utilized by the processor cores 112 may be stored locally in the L2 cache 116, preventing or reducing the number of relatively slower accesses to external main memory 140. Similarly, data utilized often by a processor core 112 may be stored in its L1 cache 114, preventing or reducing the number of relatively slower accesses to the L2 cache 116.
  • The CPU 110 may communicate with external devices, such as a graphics processing unit (GPU) 130 and/or a memory controller 136 via a system or frontside bus (FSB) 128. The CPU 110 may include an FSB interface 120 to pass data between the external devices and the processing cores 112 (through the L2 cache) via the FSB 128. An FSB interface 132 on the GPU 130 may have similar components as the FSB interface 120, configured to exchange data with one or more graphics processors 134, input output (I/O) unit 138, and the memory controller 136 (illustratively shown as integrated with the GPU 130).
  • The FSB interface 120 may include any suitable components, such as a physical layer (not shown) for implementing the hardware protocol necessary for receiving and sending data over the FSB 128. Such a physical layer may exchange data with an intermediate “link” layer which may format data received from or to be sent to a transaction layer. The transaction layer may exchange data with the processor cores 112 via a core bus interface (CBI) 118.
  • Secure Data Processing
  • As part of an enhanced security feature, the CPU 110 may encrypt some portions of data, referred to herein as secure data, prior to storing it in main memory 140 (such encrypted portions of data are illustratively shown as secure data 142 in main memory 140). Accordingly, the CPU 110 may include a security component 150 used to encrypt secure data prior to transmission over the FSB 128 by the FSB interface 120. Upon later retrieval of the encrypted data, the security component 150 may also be used to decrypt the encrypted secure data prior to passing it into the L2 cache 116 for use by one or more of the processor cores 112.
  • The security component 150 may employ any suitable encryption algorithms or combination of algorithms for encryption/decryption, including, but not limited to algorithms utilizing whitening keys, hash keys, and/or Advanced Encryption Standard (AES) keys. For some embodiments, one or more of these keys may be generated based on a master key 162 stored in persistent storage 160 located on the CPU 110. For other embodiments, the master key 162 may be used to protect these keys, for example, by encrypting a data structure containing the keys or used to generate the keys. As will be described in greater detail below, encryption may also utilize a security version parameter (version 164) also stored in persistent storage 160. In some cases, information regarding the key(s), as well as the version 164 used for encryption, and/or validation of encrypted data, may be encrypted and stored externally, as a secure block of data, shown as security metadata 144. As will be described in greater detail below, upon retrieval of secure data 141, this metadata 144 may be retrieved for validation and/or decryption purposes.
  • As shown in the Figures described below, for some embodiments, the version 164 may actually be used to encrypt data (e.g., as an input to an encryption algorithm implemented in hardware or software). However, for other embodiments, the version 164 may be used to generate an integrity check value (a checksum or hash value) on a block of encrypted data. In either case, the encrypted data may be validated against a current version. For example, if the data was encrypted using a different version, the decrypted data would not validate. Similarly, an integrity check value for the encrypted data were generated with a different version would not match an integrity check value generated with the current version.
  • FIG. 2A is a block diagram that illustrates the flow of both secure and non-secure data through the CPU, in accordance with one embodiment of the present invention, for example, as data is read into the cache from main memory and written out from the cache to main memory. Such data flow may take place, for example, when loading instructions and/or data of a program, such as a game program, into the CPU 110 for execution. While not shown, flow control logic configured to identify and route secure and non-secure data in accordance with FIG. 2A may be included in the FSB interface 120.
  • Note that data received from cache will typically be unencrypted (plaintext) regardless of whether the data is secure or non-secure. If the data is not secure, the plaintext data is written directly out to external memory. Any suitable technique may be utilized to determine if the data is secure. As an example, a specific address range may be reserved for secure data. As another example, secure data may be identified by one or more bit settings in a page table entry, for example, indicating a corresponding cache line is secure. In any case, if the data is secure, the plaintext data is routed to an encryption engine 152 of the security component 150 for encryption. The encryption engine 152 encrypts the secure data and returns the secure data encrypted (as ciphertext). For some embodiments, an integrity check value (ICV) may be calculated based on the secure data in plaintext and/or ciphertext form, to allow for subsequent authentication to ensure the encrypted data was not modified (tampered with). Depending on the embodiment, this integrity check value may also be stored externally, as metadata 144, or internally.
  • As illustrated in FIG. 2B, the encryption engine 152 may encrypt the plaintext data using the master key 162 (and/or other keys) and version 164 stored in persistent storage 160. Accordingly, a change in version 164 results in different encryption (e.g., different ciphertext given the same plaintext), thus providing a convenient mechanism to vary the encryption. As illustrated, the decryption engine 154 may also use the master key 162 (and/or other keys) and version 164 to decrypt ciphertext data retrieved from external memory. As will be described in greater detail below, for some embodiments, in an effort to ensure a secure transition to a dynamically updated security version, the encryption engine may perform encryption and decryption using the updated security version (shown as VERSION +1), prior to actually storing the updated security version in persistent storage 160. Select logic 155 may allow the encryption and decryption engines to select the proper version.
  • As illustrated, data retrieved from external memory that is not secure is forwarded on to the cache, as no decryption is required. If the data is secure, however, the data is ciphertext and, therefore, is routed to a decryption engine 154 of the security component 150 for decryption. In some cases, information regarding the keys and version data used for encryption (metadata 144) may also be retrieved with the secure data. As will be described in further detail below, for some embodiments, a validation component 170 may be configured to compare the version data retrieved with the current version 164 in persistent storage 160 to ensure the current system is authorized to access the secure data.
  • While some embodiments may use encryption/decryption engines implemented in hardware, for some embodiments some or all of the encryption and/or validation operations described herein and shown in the Figures may be performed in software (e.g., running in a secure environment). In such embodiments, software may have direct access (via the CPU) to the master key and/or version information stored in persistent storage, instead of or in addition to the hardware security component. Accordingly, the concepts described herein related to storing version information in persistent storage may be used to advantage in systems utilizing hardware encryption, software encryption, or any combination thereof.
  • Storing Version Information In Persistent Storage
  • In any case, the current version 164 in persistent storage 160 of the system may be updated periodically, for example, to reflect a user's current set of security privileges that may determine what secure data that user is authorized to access. In order to accommodate these changes, the persistent storage 160 should be some type of storage that allows writing. For some embodiments, however, to prevent inadvertent or unauthorized rollback of versions used for encryption, the persistent storage 160 should be such that, once storage elements thereof are programmed, they may not be subsequently modified. In other words, the persistent storage 160 may be configured to provide monotonic updates in one direction with time, such as a version value that may only be increased.
  • One example, of a suitable type of storage is electrically programmable fuses, commonly referred to as e-Fuses. As illustrated in FIG. 3A, for some embodiments, a first set of e-Fuses 302 1 . . . 302 N may be used to store master key information, while a second set of e-Fuses 304 1 . . . 304 M may be used to store version information. As illustrated, fuse control logic 310 may be included In such embodiments, to blow the e-Fuses 302-304 by applying a high blow voltage (VBLOW) to fuses, as indicated by e-Fuse programming data (which may be a simple bit string indicating which fuses are to be blown). The fuse control logic 310 may also be used to readout the state of the fuses 302-304 which may subsequently be latched into registers accessible by the security component 150.
  • For some embodiments, in order to update the version, the next available e-Fuse 304 may be blown. Accordingly, arbitrarily assuming fuses are blown from left to right, the rightmost fuse may be indicative of the current version. For many applications, it may not be critical that the next e-Fuse 304 in sequence be blown, but may be sufficient that the version is changed to a new value (which will result in different encryption). In such embodiments, the fuse control logic 310 may be configured to monitor the state of any e-Fuse 304 being blown and, if the e-Fuse 304 does not blow (e.g., within a given period of time), the next fuse may be blown instead. While this may have the effect of skipping some versions (e.g., if fuse 304 100 will not blow but 304 101 will, “version 100” may be skipped).
  • For some embodiments, version and master key information may be stored in different types of persistent storage. For example, for some embodiments, the master key information might not be changed during the life of the product, master key information may be stored in laser fuses 322 1-322 N rather than e-Fuses, as illustrated in FIG. 3B. The laser fuses 322 1-322 N may be blown during a manufacturing process, while the device containing them is still in wafer form, which may be convenient for system (e.g., game box, PC, etc.) manufacturers. As a result, however, the device (e.g., CPU) manufactures would have to be provided with the master key data which may create opportunities for the master key values to be mishandled, which may compromise security. Therefore, for highly sensitive applications, one advantage to storing the master key in e-fuses (or some other type of electrically writable persistent storage) is that system manufactures incorporating the devices in their products may be able to set the master keys themselves.
  • Other types of suitable persistent storage may include electrically erasable programmable read-only memory (EEPROM) or flash memory. For some embodiments, systems utilizing EEPROM or flash memories may include control circuitry to ensure that previously written storage elements (memory cells) cannot be modified, while still allowing subsequent storage elements to be programmed. For example, such control circuitry may be configured to permanently disable writing to all addresses below an address currently being written.
  • Initializing Version And Master Key Information
  • FIG. 4 is a flow diagram of exemplary operations for initializing master key and version data, according to one embodiment of the present invention. For illustrative purposes, the operations 400 assume that the master key information is stored in some type of persistent storage that is writable at run time.
  • The operations 400 begin, at step 402, by booting the system. As described in the commonly assigned, co-pending U.S. application Ser. No. 10/691,924 entitled “Initializing, Maintaining, Updating and Recovering Secure Operation within an Integrated System Employing a Data Access Control Function,” Filed on Oct. 23, 2003, hereby incorporated herein by reference in its entirety, the first time the system is booted, it may do so in a non-secure mode. In preparation of entering a secure mode, at step 404, a master key is generated, for example, based on a hardware random number generator (not shown). At step 406, the master key is stored in persistent storage.
  • At step 408, an initial security version is obtained. For some embodiments, the initial security version may simply be the initial state of the persistent storage, such as the initial (e.g., un-blown or partially blown) state of eFuses. For other embodiments, the initial security may be predetermined, for example, to reflect a current version of a product. In such cases, the predetermined security version may be stored in persistent storage, at step 410.
  • With the master key and version in place, the device may enter a secure mode, whereby secure data is encrypted using the master key and current version. For example, the master key and security version may be used to encrypt data structures to be stored in external memory, such as a data structure containing security key sets. As previously described, the security version may be stored and encrypted with the data, to allow later comparison against the current security version when retrieving the encrypted data structure. Accordingly, at step 412, the initial security version is put in a data structure to be encrypted and, at step 414, the data structure is encrypted using the initial security version and master key information. At step 416, the encrypted data structure is stored in external (e.g., FLASH) memory.
  • At step 418, at least one additional copy of the encrypted data structure is stored in external memory. For some embodiments, maintaining more than one copy of the encrypted data structure may ensure at least one good copy of the encrypted data is available even if one or more other copies become invalid for some reason, such as tampering or some type of writing error, which may allow data to be recovered in the occurrence of some such event. Maintaining multiple copies may also allow recovery in the event that updates to the encrypted data structure (e.g., to grant/revoke privileges as described below), which may involve relatively lengthy operations, are interrupted for any reason, such as an unexpected loss of power. For example, by maintaining multiple copies, even if one copy becomes corrupted, if the other copy is good it may be used to restore the corrupted copy.
  • Utilizing Version Information For Secure Validation At Runtime
  • FIG. 5 is a flow diagram of exemplary operations 500 for secure runtime operations utilizing version information, according to one embodiment of the present invention. The operations 500 assume that multiple copies (illustratively, two) of an encrypted secure data structure have been stored in external memory, for example, as shown in the operations 400 described above. Further, for illustrative purposes, the operations 500 are assumed to be performed in a game system. However, one skilled in the art will recognize that similar operations may be performed to provide secure operations in a wide variety of different type systems.
  • The operations 500 begin, at step 502, by retrieving a first copy of the encrypted data structure and validating the secure data structure using a current security version. As previously described, the validation may involve generating an integrity check value for the retrieved data structure using the current security version or decrypting the retrieved data structure using the current security version. In any case, if the first copy of the data structure is valid, as determined at step 504, the second copy of the data structure is retrieved and validated, at step 512. If the second copy of the data structure is also valid, as determined at step 514, redundancy is maintained and an operations mode is entered, at step 522.
  • If either of the copies of the data structure are not valid, recovery procedures may be attempted in an effort to maintain redundancy. For example, if the first copy is not valid, a recovery procedure may be attempted, at step 508, wherein the first copy is overwritten with the second copy, after which the operations may return to step 502, to determine if the recovery procedure was successful in restoring the first copy. Alternatively, if the second copy is not valid, a recovery procedure may be attempted, at step 518, wherein the second copy is overwritten with the first copy, after which the operations may return to step 512 to determine if the recovery procedure was successful in restoring the second copy. For some embodiments, because invalid copies may be the result of unrecoverable problems (e.g., irreparable portions of external memory) there may be a maximum allowable number of retries that, if exceeded (as determined at steps 506 and 516), may result in failures (steps 510 and 520), for example, not allowing the system to enter into an operational mode.
  • Assuming the operational mode is reached, at step 522, a loop of operations (524-536) is entered, in which one of two basic operations is performed: a game is played or privileges are updated. If a game is to be played, as determined at step 524, the game is loaded using current security and privilege settings, at step 526. Once the game is over, as determined at step 528, the loop of operations is entered again.
  • In some cases, a user may choose to update privileges, for example, to gain some new type of desired functionality. For example, a user may initially receive a first set of privileges when purchasing a game system. This first set of privileges may authorize the user to play a first set of games supplied with the system. The privileges may be stored (in external memory) in the data structure encrypted using a security version setting that shipped with the game system. To play any additional games may require additional privileges, which may be requested by a user, for example, via an online purchase.
  • If privileges are to be updated, as determined at step 530, an update procedure to securely modify the privilege information and security version is performed, at step 532. If the update procedure is successful, the user's account is charged, at step 536 and the system is rebooted, at step 540, to reflect the update privilege information. On the other hand, if the update procedure is not successful, the user's account is not charged, at step 538. However, the system may still be rebooted, for example, in an effort restore one of the copies of the secure data structure which (as will be described in greater detail below) may have been corrupted during the failed update procedure.
  • Utilizing Version Information For Secure Runtime Operation
  • FIG. 6 illustrates exemplary operations 600 for an update procedure to modify the secure data structure (e.g., to reflect a change in privileges) and update a security version. It should be noted, however, that not all types of privilege updates may require modifying the security version. For example, if certain privileges are not to be revoked, and the user is paying for the updates, privilege information may be updated in the secure data structure without modifying the security version used to encrypt the data structure. On the other hand, if some privileges are being revoked, it may be desirable to modify the security version to prevent the user from “rolling back” the system to regain the privileges revoked, for example, by replacing the secure data block with a previous copy.
  • The operations 600 begin, at step 602, by receiving a request to update the security structure with a new security version. At step 604, a test is performed to determine if both copies of the data structure stored in external memory are valid (e.g., by decrypting and/or generating an integrity check value using the current security version). If both copies of the current data structure are not valid, a recovery procedure may be attempted, at step 608. As previously described, a recovery procedure may involve overwriting an invalid copy of the data structure with a valid copy. The validation operations of step 604 may then be repeated. In some cases, if a maximum number of retries is exceeded, as determined at step 606, a failure may be reported, at step 610.
  • However, if both copies of the current data structure are valid, the data structure is modified (e.g., to reflect a change in privileges) and the current security version is incremented, at step 612. At step 614, the new data structure is encrypted (and/or an integrity check value is generated) using the new security version. In an effort to always maintain at least one valid copy of the data structure, only one copy of the data structures in external memory may be overwritten until the security version is successfully updated in persistent storage, possibly allowing recovery in the event of a failure in writing the new data structure to external memory or in writing the new security information to persistent storage.
  • Therefore, at step 616, the first copy of the data structure in external memory is overwritten with the new data structure. At step 618, the new data structure is read back from external memory and validated. If the copy read back is not valid, indicating a possible write failure, the operations 616-620 may be repeated, up to a maximum number of retries, after which a failure may be reported, at step 626 (e.g., resulting in the user not being charged for updates, per step 538 of FIG. 5).
  • If the data structure read back is valid, the persistent storage is modified to reflect the incremented security version, for example, by burning one or more fuses, at step 628. In some cases, updates to the persistent storage may not be successful, for example, due to faulty storage elements (e.g., fuses that will not burn). Accordingly, a test may be performed to determine if the update to persistent storage is successful, for example, by performing a read back of fuses, at step 630. If a fuse did not burn successfully, attempts to burn the fuse may be repeated, up until a maximum number of retries for that fuse. For some embodiments, the particular fuse burned may not be matter, for example if a security version is reflected by a total number of fuses burned. Therefore, provided the fuse limit has not been reached (no more fuses to blow), as determined at step 634, the blow operations may be repeated with a different (e.g., the next) fuse selected, at step 636. If the fuse limit has been reached, a failure may be reported, at step 628.
  • If the fuse burning is successful, the second copy of the data structure in external memory is overwritten with the new data structure, at step 640, and secure update procedure is complete. Of course, for some embodiments, the second copy of the data structure may be read back and validated. Recall, however (referring back to FIG. 5), that after updating the data structure, the system may be rebooted (step 540) causing the first and second copies of the data structure to be validated (at steps 502 and 512, respectively).
  • Conclusion
  • Storing security versions in persistent, but changeable, storage, such as electronically programmable fused (e-Fuses), may allow such version information to be stored securely while still providing the flexibility to change the versions while the system is running. Changing the version information while the system is running may allow privileges to be granted and/or revoked dynamically. For some embodiments, data structures containing the privilege information may be encrypted and validated using security version information.
  • While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.

Claims (12)

1. A method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor, comprising:
maintaining a security version parameter in persistent storage on the processor, wherein blocks of secure data are encrypted as a function of the security version parameter; and
dynamically changing the security version parameter by modifying the contents of the persistent storage.
2. The method of claim 1, wherein the security version parameter is dynamically changed while the secure system is running.
3. The method of claim 1, further comprising:
dynamically updating the privileges of a user;
encrypting a data structure containing privilege information indicating the updated privileges; and
generating an integrity check value on the data structure, wherein at least one of the encrypting or the generating is affected by the security version parameter.
4. The method of claim 1, wherein dynamically changing the security version parameter comprises blowing a fuse.
5. The method of claim 1, wherein dynamically changing the security version parameter comprises only one of increasing or decreasing the security version.
6. A method of handling secure data in a secure system, wherein the secure data is passed between a processor and memory external to the processor, comprising:
maintaining a security version parameter and master key data in persistent storage on the processor;
encrypting a block of secure data;
generating an integrity check value for the block of secure data, wherein at least one of the encrypting and the generating is performed as a function of the security version parameter;
storing the encrypted block of secure data in the external memory; and
dynamically changing the security version parameter by modifying the contents of the persistent storage.
7. The method of claim 6, wherein the encrypting and generating is performed in software.
8. The method of claim 6, wherein encrypting a block of secure data is affected by at least one of: the master key data, one or more keys derived from the master key data, and one or more keys protected by the master key data.
9. The method of claim 6, further comprising encrypting the security version parameter and storing the security version parameter in external memory with the block of secure data.
10. The method of claim 9, further comprising:
retrieving the encrypted block of secure data and security version parameter from external memory;
decrypting the encrypted block of secure data and security version parameter retrieved from external memory; and
comparing the security version parameter retrieved from external memory with the security version parameter stored in persistent storage.
11. The method of claim 10, further comprising:
generating a security exception if the retrieved security version parameter and the security version parameter maintained in the persistent storage are not equal.
12. The method of claim 6, wherein the master key information and security version parameter are stored in different types of persistent storage.
US12/055,647 2004-07-15 2008-03-26 E-fuses for storing security version data Abandoned US20080310622A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/055,647 US20080310622A1 (en) 2004-07-15 2008-03-26 E-fuses for storing security version data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/892,431 US7461268B2 (en) 2004-07-15 2004-07-15 E-fuses for storing security version data
US12/055,647 US20080310622A1 (en) 2004-07-15 2008-03-26 E-fuses for storing security version data

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/892,431 Continuation US7461268B2 (en) 2004-07-15 2004-07-15 E-fuses for storing security version data

Publications (1)

Publication Number Publication Date
US20080310622A1 true US20080310622A1 (en) 2008-12-18

Family

ID=35600841

Family Applications (3)

Application Number Title Priority Date Filing Date
US10/892,431 Expired - Fee Related US7461268B2 (en) 2004-07-15 2004-07-15 E-fuses for storing security version data
US12/055,647 Abandoned US20080310622A1 (en) 2004-07-15 2008-03-26 E-fuses for storing security version data
US12/057,207 Abandoned US20080175381A1 (en) 2004-07-15 2008-03-27 E-fuses for storing security version data

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/892,431 Expired - Fee Related US7461268B2 (en) 2004-07-15 2004-07-15 E-fuses for storing security version data

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/057,207 Abandoned US20080175381A1 (en) 2004-07-15 2008-03-27 E-fuses for storing security version data

Country Status (1)

Country Link
US (3) US7461268B2 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070214361A1 (en) * 2006-10-11 2007-09-13 Frank Rubin Device, System and Method for Fast Secure Message Encryption Without Key Distribution
US20070297614A1 (en) * 2006-10-11 2007-12-27 Frank Rubin Device, System and Method for Fast Secure Message Encryption Without Key Distribution
US20080069345A1 (en) * 2006-10-11 2008-03-20 Frank Rubin Device, System and Method for Cryptographic Key Exchange
US20080069346A1 (en) * 2006-10-11 2008-03-20 Frank Rubin Device, System and Method for Cryptographic Key Exchange
US20110091036A1 (en) * 2008-06-06 2011-04-21 Telefonaktiebolaget Lm Ericsson (Publ) Cryptographic Key Generation
US20110167198A1 (en) * 2010-01-07 2011-07-07 Richard Soja Non-volatile storage alteration tracking
US20120159239A1 (en) * 2010-12-20 2012-06-21 Chon Peter B Data manipulation of power fail
US8458804B1 (en) 2011-12-29 2013-06-04 Elwha Llc Systems and methods for preventing data remanence in memory
US10936771B1 (en) 2019-10-02 2021-03-02 Microsoft Technology Licensing, Llc Using a common fuse controller hardware design for different applications

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7461268B2 (en) * 2004-07-15 2008-12-02 International Business Machines Corporation E-fuses for storing security version data
US8954751B2 (en) 2004-10-08 2015-02-10 International Business Machines Corporation Secure memory control parameters in table look aside buffer data fields and support memory array
US7941860B2 (en) * 2005-05-13 2011-05-10 Intel Corporation Apparatus and method for content protection using one-way buffers
US8949273B2 (en) * 2005-08-24 2015-02-03 Alcatel Lucent Online customer support system
US8438658B2 (en) * 2006-02-02 2013-05-07 International Business Machines Corporation Providing sealed storage in a data processing device
US20070180271A1 (en) * 2006-02-02 2007-08-02 Ibm Corporation Apparatus and method for providing key security in a secure processor
US7835518B2 (en) * 2006-04-03 2010-11-16 Sandisk Corporation System and method for write failure recovery
WO2007118034A2 (en) * 2006-04-03 2007-10-18 Sandisk Corporation System and method for write failure recovery
US20070230690A1 (en) * 2006-04-03 2007-10-04 Reuven Elhamias System for write failure recovery
DE602006008598D1 (en) * 2006-06-29 2009-10-01 Incard Sa Transaction method for memory management of persistent data in a transaction stack
US9811330B2 (en) * 2006-10-06 2017-11-07 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for version control in a reprogrammable security system
US7949130B2 (en) * 2006-12-28 2011-05-24 Intel Corporation Architecture and instruction set for implementing advanced encryption standard (AES)
US8332660B2 (en) * 2008-01-02 2012-12-11 Arm Limited Providing secure services to a non-secure application
US8775824B2 (en) * 2008-01-02 2014-07-08 Arm Limited Protecting the security of secure data sent from a central processor for processing by a further processing device
US7761714B2 (en) * 2008-10-02 2010-07-20 Infineon Technologies Ag Integrated circuit and method for preventing an unauthorized access to a digital value
US10255463B2 (en) 2008-11-17 2019-04-09 International Business Machines Corporation Secure computer architecture
US8612777B2 (en) * 2009-01-09 2013-12-17 Infineon Technologies Ag Apparatus and method for writing data to be stored to a predetermined memory area
US8194489B2 (en) * 2010-01-21 2012-06-05 International Business Machines Corporation Paired programmable fuses
US8972746B2 (en) * 2010-12-17 2015-03-03 Intel Corporation Technique for supporting multiple secure enclaves
US10110380B2 (en) * 2011-03-28 2018-10-23 Nxp B.V. Secure dynamic on chip key programming
US9042551B2 (en) 2012-06-04 2015-05-26 International Business Machines Corporation Electronically programmable fuse security encryption
US9294267B2 (en) 2012-11-16 2016-03-22 Deepak Kamath Method, system and program product for secure storage of content
CN104995627B (en) * 2013-03-15 2018-04-27 英特尔公司 Cipher key revocation in system-on-chip apparatus
US9135834B2 (en) * 2013-04-30 2015-09-15 The United Sates of America as represented by the Secretary of the Air Force Apparatus and method to prevent side channel power attacks in advanced encryption standard using floating point operation
US9570193B2 (en) 2014-12-17 2017-02-14 International Business Machines Corporation Implementing hidden security key in eFuses
US11146397B2 (en) * 2017-10-31 2021-10-12 Micro Focus Llc Encoding abelian variety-based ciphertext with metadata
DE102018006208A1 (en) * 2018-08-06 2019-10-02 Giesecke+Devrient Mobile Security Gmbh Chipset, for terminal, with updatable program
CN110611670A (en) * 2019-09-12 2019-12-24 贵阳叁玖互联网医疗有限公司 API request encryption method and device
US11216597B2 (en) 2020-05-14 2022-01-04 Nuvoton Technology Corporation Security system and method for preventing rollback attacks on silicon device firmware
US11570156B2 (en) 2020-07-02 2023-01-31 International Business Machines Corporation Secure pairing of devices

Citations (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4168396A (en) * 1977-10-31 1979-09-18 Best Robert M Microprocessor for executing enciphered programs
US4465901A (en) * 1979-06-04 1984-08-14 Best Robert M Crypto microprocessor that executes enciphered programs
US4797853A (en) * 1985-11-15 1989-01-10 Unisys Corporation Direct memory access controller for improved system security, memory to memory transfers, and interrupt processing
US4920483A (en) * 1985-11-15 1990-04-24 Data General Corporation A computer memory for accessing any word-sized group of contiguous bits
US4951249A (en) * 1986-10-24 1990-08-21 Harcom Security Systems Corp. Method and apparatus for controlled access to a computer system
US5081677A (en) * 1990-08-31 1992-01-14 International Business Machines Corp. Crypotographic key version control facility
US5144659A (en) * 1989-04-19 1992-09-01 Richard P. Jones Computer file protection system
US5421006A (en) * 1992-05-07 1995-05-30 Compaq Computer Corp. Method and apparatus for assessing integrity of computer system software
US5440713A (en) * 1992-05-29 1995-08-08 Industrial Technology Research Institute M-way N-port paged-interleaved memory system
US5464087A (en) * 1991-04-24 1995-11-07 Mars, Incorporated Transaction systems
US5491827A (en) * 1994-01-14 1996-02-13 Bull Hn Information Systems Inc. Secure application card for sharing application data and procedures among a plurality of microprocessors
US5497479A (en) * 1989-04-28 1996-03-05 Softel, Inc. Method and apparatus for remotely controlling and monitoring the use of computer software
US5561817A (en) * 1993-08-16 1996-10-01 Thermo King Corporation Method of securely controlling direct memory access (DMA) of a shared memory by a DMA device on an expansion board
US5564054A (en) * 1994-08-25 1996-10-08 International Business Machines Corporation Fail-safe computer boot apparatus and method
US5602536A (en) * 1985-10-16 1997-02-11 Supra Products, Inc. Data synchronization method for use with portable, microprocessor-based device
US5610980A (en) * 1995-02-13 1997-03-11 Eta Technologies Corporation Method and apparatus for re-initializing a processing device and a storage device
US5647017A (en) * 1994-08-31 1997-07-08 Peripheral Vision Ltd. Method and system for the verification of handwritten signatures
US5703952A (en) * 1992-12-30 1997-12-30 Telstra Corporation Limited Method and apparatus for generating a cipher stream
US5757919A (en) * 1996-12-12 1998-05-26 Intel Corporation Cryptographically protected paging subsystem
US5778316A (en) * 1993-11-01 1998-07-07 Telefonaktiebolaget Lm Ericsson Method and apparatus for selecting a control channel based on service availability
US5809230A (en) * 1996-01-16 1998-09-15 Mclellan Software International, Llc System and method for controlling access to personal computer system resources
US5825878A (en) * 1996-09-20 1998-10-20 Vlsi Technology, Inc. Secure memory management unit for microprocessor
US5841868A (en) * 1993-09-21 1998-11-24 Helbig, Sr.; Walter Allen Trusted computer system
US5887131A (en) * 1996-12-31 1999-03-23 Compaq Computer Corporation Method for controlling access to a computer system by utilizing an external device containing a hash value representation of a user password
US5893921A (en) * 1995-02-10 1999-04-13 International Business Machines Corporation Method for maintaining memory coherency in a computer system having a cache utilizing snoop address injection during a read transaction by a dual memory bus controller
US5895962A (en) * 1996-06-13 1999-04-20 Micron Technology, Inc. Structure and a method for storing information in a semiconductor device
US5912453A (en) * 1995-09-29 1999-06-15 International Business Machines Corporation Multiple application chip card with decoupled programs
US5918007A (en) * 1992-05-27 1999-06-29 International Business Machines Corporation Trusted personal computer system with limited accessibility
US5930824A (en) * 1997-02-04 1999-07-27 International Business Machines Corporation System and method for demand-base data recovery
US5935247A (en) * 1997-09-18 1999-08-10 Geneticware Co., Ltd. Computer system having a genetic code that cannot be directly accessed and a method of maintaining the same
US5940513A (en) * 1995-08-25 1999-08-17 Intel Corporation Parameterized hash functions for access control
US6021476A (en) * 1997-04-30 2000-02-01 Arm Limited Data processing apparatus and method for controlling access to a memory having a plurality of memory locations for storing data values
US6023510A (en) * 1997-12-24 2000-02-08 Philips Electronics North America Corporation Method of secure anonymous query by electronic messages transported via a public network and method of response
US6049612A (en) * 1997-03-10 2000-04-11 The Pacid Group File encryption method and system
US6052763A (en) * 1996-12-17 2000-04-18 Ricoh Company, Ltd. Multiprocessor system memory unit with split bus and method for controlling access to the memory unit
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US6116402A (en) * 1998-10-23 2000-09-12 Coinstar, Inc. Voucher coding for self-service coin discriminator
US6182217B1 (en) * 1997-03-03 2001-01-30 Siemens Aktiengesellschaft Electronic data-processing device and system
US6182142B1 (en) * 1998-07-10 2001-01-30 Encommerce, Inc. Distributed access management of information resources
US6226742B1 (en) * 1998-04-20 2001-05-01 Microsoft Corporation Cryptographic technique that provides fast encryption and decryption and assures integrity of a ciphertext message through use of a message authentication code formed through cipher block chaining of the plaintext message
US6230269B1 (en) * 1998-03-04 2001-05-08 Microsoft Corporation Distributed authentication system and method
US6289455B1 (en) * 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
US6311255B1 (en) * 1999-04-29 2001-10-30 International Business Machines Corporation System and method for selectively restricting access to memory for bus attached unit IDs
US20010044886A1 (en) * 1997-09-26 2001-11-22 Robert D. Cassagnol Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US20020013911A1 (en) * 1998-11-24 2002-01-31 Cordella Robert H. Compact hardware architecture for secure exchange of information and advanced computing
US20020032867A1 (en) * 1998-11-24 2002-03-14 Kellum Charles W. Multi-system architecture using general purpose active-backplane and expansion-bus compatible single board computers and their peripherals for secure exchange of information and advanced computing
US20020042882A1 (en) * 2000-10-10 2002-04-11 Dervan R. Donald Computer security system
US20020108045A1 (en) * 1999-01-22 2002-08-08 Steve Wells Preventing unauthorized updates to a non-volatile memory
US6609169B1 (en) * 1999-06-14 2003-08-19 Jay Powell Solid-state audio-video playback system
US20030200448A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Control function implementing selective transparent data authentication within an integrated system
US20030200454A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Initializing, maintaining, updating and recovering secure operation within an integrated system employing a data access control function
US20030200451A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Control function employing a requesting master id and a data address to qualify data access within an integrated system
US6775778B1 (en) * 1998-05-29 2004-08-10 Texas Instruments Incorporated Secure computing device having boot read only memory verification of program code
US20050050342A1 (en) * 2003-08-13 2005-03-03 International Business Machines Corporation Secure storage utility
US20050076255A1 (en) * 2003-10-03 2005-04-07 Bresniker Kirk Michael Rack equipment management system and method
US20050180572A1 (en) * 2004-02-18 2005-08-18 Graunke Gary L. Apparatus and method for distributing private keys to an entity with minimal secret, unique information
US20050233724A1 (en) * 2002-08-30 2005-10-20 Koninklijke Philips Electronics N.V. Version-programmable circuit module
US6971051B2 (en) * 2002-01-10 2005-11-29 Agilent Technologies, Inc. System and method of recovering from soft memory errors
US20060015754A1 (en) * 2004-07-15 2006-01-19 International Business Machines Corporation E-fuses for storing security version data
US7055038B2 (en) * 2001-05-07 2006-05-30 Ati International Srl Method and apparatus for maintaining secure and nonsecure data in a shared memory system
US7177424B1 (en) * 1999-06-22 2007-02-13 Hitachi, Ltd. Cryptographic apparatus and method
US7213155B2 (en) * 2000-07-31 2007-05-01 Sony Corporation Recording medium, recording and/or reproducing method for record medium, and recording and/or reproducing device for recording medium
US7657756B2 (en) * 2004-10-08 2010-02-02 International Business Machines Corporaiton Secure memory caching structures for data, integrity and version values

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0129065D0 (en) * 2001-12-05 2002-01-23 Philips Electronics Uk Ltd Method and apparatus for verifying the integrity of system data

Patent Citations (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4168396A (en) * 1977-10-31 1979-09-18 Best Robert M Microprocessor for executing enciphered programs
US4465901A (en) * 1979-06-04 1984-08-14 Best Robert M Crypto microprocessor that executes enciphered programs
US5602536A (en) * 1985-10-16 1997-02-11 Supra Products, Inc. Data synchronization method for use with portable, microprocessor-based device
US4797853A (en) * 1985-11-15 1989-01-10 Unisys Corporation Direct memory access controller for improved system security, memory to memory transfers, and interrupt processing
US4920483A (en) * 1985-11-15 1990-04-24 Data General Corporation A computer memory for accessing any word-sized group of contiguous bits
US4951249A (en) * 1986-10-24 1990-08-21 Harcom Security Systems Corp. Method and apparatus for controlled access to a computer system
US5144659A (en) * 1989-04-19 1992-09-01 Richard P. Jones Computer file protection system
US5497479A (en) * 1989-04-28 1996-03-05 Softel, Inc. Method and apparatus for remotely controlling and monitoring the use of computer software
US5081677A (en) * 1990-08-31 1992-01-14 International Business Machines Corp. Crypotographic key version control facility
US5464087A (en) * 1991-04-24 1995-11-07 Mars, Incorporated Transaction systems
US5421006A (en) * 1992-05-07 1995-05-30 Compaq Computer Corp. Method and apparatus for assessing integrity of computer system software
US5918007A (en) * 1992-05-27 1999-06-29 International Business Machines Corporation Trusted personal computer system with limited accessibility
US5440713A (en) * 1992-05-29 1995-08-08 Industrial Technology Research Institute M-way N-port paged-interleaved memory system
US5703952A (en) * 1992-12-30 1997-12-30 Telstra Corporation Limited Method and apparatus for generating a cipher stream
US5561817A (en) * 1993-08-16 1996-10-01 Thermo King Corporation Method of securely controlling direct memory access (DMA) of a shared memory by a DMA device on an expansion board
US5841868A (en) * 1993-09-21 1998-11-24 Helbig, Sr.; Walter Allen Trusted computer system
US5778316A (en) * 1993-11-01 1998-07-07 Telefonaktiebolaget Lm Ericsson Method and apparatus for selecting a control channel based on service availability
US5491827A (en) * 1994-01-14 1996-02-13 Bull Hn Information Systems Inc. Secure application card for sharing application data and procedures among a plurality of microprocessors
US5564054A (en) * 1994-08-25 1996-10-08 International Business Machines Corporation Fail-safe computer boot apparatus and method
US5647017A (en) * 1994-08-31 1997-07-08 Peripheral Vision Ltd. Method and system for the verification of handwritten signatures
US5893921A (en) * 1995-02-10 1999-04-13 International Business Machines Corporation Method for maintaining memory coherency in a computer system having a cache utilizing snoop address injection during a read transaction by a dual memory bus controller
US5610980A (en) * 1995-02-13 1997-03-11 Eta Technologies Corporation Method and apparatus for re-initializing a processing device and a storage device
US5940513A (en) * 1995-08-25 1999-08-17 Intel Corporation Parameterized hash functions for access control
US5912453A (en) * 1995-09-29 1999-06-15 International Business Machines Corporation Multiple application chip card with decoupled programs
US5809230A (en) * 1996-01-16 1998-09-15 Mclellan Software International, Llc System and method for controlling access to personal computer system resources
US5895962A (en) * 1996-06-13 1999-04-20 Micron Technology, Inc. Structure and a method for storing information in a semiconductor device
US5825878A (en) * 1996-09-20 1998-10-20 Vlsi Technology, Inc. Secure memory management unit for microprocessor
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US5757919A (en) * 1996-12-12 1998-05-26 Intel Corporation Cryptographically protected paging subsystem
US6052763A (en) * 1996-12-17 2000-04-18 Ricoh Company, Ltd. Multiprocessor system memory unit with split bus and method for controlling access to the memory unit
US5887131A (en) * 1996-12-31 1999-03-23 Compaq Computer Corporation Method for controlling access to a computer system by utilizing an external device containing a hash value representation of a user password
US5930824A (en) * 1997-02-04 1999-07-27 International Business Machines Corporation System and method for demand-base data recovery
US6182217B1 (en) * 1997-03-03 2001-01-30 Siemens Aktiengesellschaft Electronic data-processing device and system
US6049612A (en) * 1997-03-10 2000-04-11 The Pacid Group File encryption method and system
US6021476A (en) * 1997-04-30 2000-02-01 Arm Limited Data processing apparatus and method for controlling access to a memory having a plurality of memory locations for storing data values
US5935247A (en) * 1997-09-18 1999-08-10 Geneticware Co., Ltd. Computer system having a genetic code that cannot be directly accessed and a method of maintaining the same
US6438666B2 (en) * 1997-09-26 2002-08-20 Hughes Electronics Corporation Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US20010044886A1 (en) * 1997-09-26 2001-11-22 Robert D. Cassagnol Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US6023510A (en) * 1997-12-24 2000-02-08 Philips Electronics North America Corporation Method of secure anonymous query by electronic messages transported via a public network and method of response
US6230269B1 (en) * 1998-03-04 2001-05-08 Microsoft Corporation Distributed authentication system and method
US6226742B1 (en) * 1998-04-20 2001-05-01 Microsoft Corporation Cryptographic technique that provides fast encryption and decryption and assures integrity of a ciphertext message through use of a message authentication code formed through cipher block chaining of the plaintext message
US6775778B1 (en) * 1998-05-29 2004-08-10 Texas Instruments Incorporated Secure computing device having boot read only memory verification of program code
US6182142B1 (en) * 1998-07-10 2001-01-30 Encommerce, Inc. Distributed access management of information resources
US6116402A (en) * 1998-10-23 2000-09-12 Coinstar, Inc. Voucher coding for self-service coin discriminator
US20020013911A1 (en) * 1998-11-24 2002-01-31 Cordella Robert H. Compact hardware architecture for secure exchange of information and advanced computing
US20020032867A1 (en) * 1998-11-24 2002-03-14 Kellum Charles W. Multi-system architecture using general purpose active-backplane and expansion-bus compatible single board computers and their peripherals for secure exchange of information and advanced computing
US20020108045A1 (en) * 1999-01-22 2002-08-08 Steve Wells Preventing unauthorized updates to a non-volatile memory
US6311255B1 (en) * 1999-04-29 2001-10-30 International Business Machines Corporation System and method for selectively restricting access to memory for bus attached unit IDs
US6609169B1 (en) * 1999-06-14 2003-08-19 Jay Powell Solid-state audio-video playback system
US7177424B1 (en) * 1999-06-22 2007-02-13 Hitachi, Ltd. Cryptographic apparatus and method
US6289455B1 (en) * 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
US7213155B2 (en) * 2000-07-31 2007-05-01 Sony Corporation Recording medium, recording and/or reproducing method for record medium, and recording and/or reproducing device for recording medium
US20020042882A1 (en) * 2000-10-10 2002-04-11 Dervan R. Donald Computer security system
US7055038B2 (en) * 2001-05-07 2006-05-30 Ati International Srl Method and apparatus for maintaining secure and nonsecure data in a shared memory system
US6971051B2 (en) * 2002-01-10 2005-11-29 Agilent Technologies, Inc. System and method of recovering from soft memory errors
US20040083375A1 (en) * 2002-04-18 2004-04-29 International Business Machines Corporation Initializing, maintaining, updating and recovering secure operation within an integrated system employing a data access control function
US6851056B2 (en) * 2002-04-18 2005-02-01 International Business Machines Corporation Control function employing a requesting master id and a data address to qualify data access within an integrated system
US20030200451A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Control function employing a requesting master id and a data address to qualify data access within an integrated system
US20030200454A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Initializing, maintaining, updating and recovering secure operation within an integrated system employing a data access control function
US20030200448A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Control function implementing selective transparent data authentication within an integrated system
US7266842B2 (en) * 2002-04-18 2007-09-04 International Business Machines Corporation Control function implementing selective transparent data authentication within an integrated system
US20050233724A1 (en) * 2002-08-30 2005-10-20 Koninklijke Philips Electronics N.V. Version-programmable circuit module
US20050050342A1 (en) * 2003-08-13 2005-03-03 International Business Machines Corporation Secure storage utility
US20050076255A1 (en) * 2003-10-03 2005-04-07 Bresniker Kirk Michael Rack equipment management system and method
US20050180572A1 (en) * 2004-02-18 2005-08-18 Graunke Gary L. Apparatus and method for distributing private keys to an entity with minimal secret, unique information
US20060015754A1 (en) * 2004-07-15 2006-01-19 International Business Machines Corporation E-fuses for storing security version data
US7461268B2 (en) * 2004-07-15 2008-12-02 International Business Machines Corporation E-fuses for storing security version data
US7657756B2 (en) * 2004-10-08 2010-02-02 International Business Machines Corporaiton Secure memory caching structures for data, integrity and version values

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8098815B2 (en) * 2006-10-11 2012-01-17 Frank Rubin Device, system and method for cryptographic key exchange
US8090097B2 (en) * 2006-10-11 2012-01-03 Frank Rubin Device, system and method for cryptographic key exchange
US20080069345A1 (en) * 2006-10-11 2008-03-20 Frank Rubin Device, System and Method for Cryptographic Key Exchange
US20080069346A1 (en) * 2006-10-11 2008-03-20 Frank Rubin Device, System and Method for Cryptographic Key Exchange
US7907723B2 (en) * 2006-10-11 2011-03-15 Frank Rubin Device, system and method for fast secure message encryption without key distribution
US7912213B2 (en) * 2006-10-11 2011-03-22 Frank Rubin Device, system and method for fast secure message encryption without key distribution
US20070297614A1 (en) * 2006-10-11 2007-12-27 Frank Rubin Device, System and Method for Fast Secure Message Encryption Without Key Distribution
US20070214361A1 (en) * 2006-10-11 2007-09-13 Frank Rubin Device, System and Method for Fast Secure Message Encryption Without Key Distribution
US20110091036A1 (en) * 2008-06-06 2011-04-21 Telefonaktiebolaget Lm Ericsson (Publ) Cryptographic Key Generation
US8953793B2 (en) 2008-06-06 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) Cryptographic key generation
US8340288B2 (en) * 2008-06-06 2012-12-25 Telefonaktiebolaget Lm Ericsson (Publ) Cryptographic key generation
US9326142B2 (en) 2008-06-06 2016-04-26 Telefonaktiebolaget L M Ericsson (Publ) Cryptographic key generation
US20110167198A1 (en) * 2010-01-07 2011-07-07 Richard Soja Non-volatile storage alteration tracking
US8380918B2 (en) * 2010-01-07 2013-02-19 Freescale Semiconductor, Inc. Non-volatile storage alteration tracking
US20120159239A1 (en) * 2010-12-20 2012-06-21 Chon Peter B Data manipulation of power fail
US9043642B2 (en) * 2010-12-20 2015-05-26 Avago Technologies General IP Singapore) Pte Ltd Data manipulation on power fail
US8925078B2 (en) 2011-12-29 2014-12-30 Elwha Llc Systems and methods for preventing data remanence in memory
US8763148B2 (en) 2011-12-29 2014-06-24 Elwha Llc Systems and methods for preventing data remanence in memory
US9235726B2 (en) 2011-12-29 2016-01-12 Elwha Llc Systems and methods for preventing data remanence in memory
US8458804B1 (en) 2011-12-29 2013-06-04 Elwha Llc Systems and methods for preventing data remanence in memory
US9740638B2 (en) 2011-12-29 2017-08-22 Elwha Llc Systems and methods for preventing data remanence in memory
US10936771B1 (en) 2019-10-02 2021-03-02 Microsoft Technology Licensing, Llc Using a common fuse controller hardware design for different applications

Also Published As

Publication number Publication date
US7461268B2 (en) 2008-12-02
US20080175381A1 (en) 2008-07-24
US20060015754A1 (en) 2006-01-19

Similar Documents

Publication Publication Date Title
US7461268B2 (en) E-fuses for storing security version data
US7266842B2 (en) Control function implementing selective transparent data authentication within an integrated system
US8719595B2 (en) Semiconductor device including encryption section, semiconductor device including external interface, and content reproduction method
JP4447977B2 (en) Secure processor and program for secure processor.
US7761717B2 (en) Memory device with data security in a processor
KR100809977B1 (en) Initializing, maintaining, updating and recovering secure operation within an integrated system employing a data access control function
JP4646900B2 (en) Backward compatible secure processor and method for executing secure software
US8190912B2 (en) Program development method, program development supporting system, and program installation method
US8060925B2 (en) Processor, memory, computer system, and method of authentication
US20070297606A1 (en) Multiple key security and method for electronic devices
US8127144B2 (en) Program loader operable to verify if load-destination information has been tampered with, processor including the program loader, data processing device including the processor, promgram loading method, and integrated circuit
US20070186117A1 (en) Secure processor-based system and method
JPWO2002057904A1 (en) Control device with download function
TW200832427A (en) Virtual secure on-chip one time programming
US20070237325A1 (en) Method and apparatus to improve security of cryptographic systems
TWI775346B (en) System and method preventing rollback attacks
JP6518798B2 (en) Device and method for managing secure integrated circuit conditions
KR101954439B1 (en) Soc having double security features, and double security method for soc
KR101988404B1 (en) Soc having double security features, and double security method for soc
CN113486360B (en) RISC-V based safe starting method and system
JP2020149236A (en) Electronic apparatus and control method for electronic apparatus
CN114968117A (en) Memory protection system
JP2022051127A (en) Information processing apparatus and update processing method

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION