US6961852B2 - System and method for authenticating software using hidden intermediate keys - Google Patents

System and method for authenticating software using hidden intermediate keys Download PDF

Info

Publication number
US6961852B2
US6961852B2 US10/464,884 US46488403A US6961852B2 US 6961852 B2 US6961852 B2 US 6961852B2 US 46488403 A US46488403 A US 46488403A US 6961852 B2 US6961852 B2 US 6961852B2
Authority
US
United States
Prior art keywords
loader
value
software
prefix
computer
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.)
Expired - Fee Related, expires
Application number
US10/464,884
Other versions
US20050010767A1 (en
Inventor
David Craft
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
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CRAFT, DAVID
Priority to US10/464,884 priority Critical patent/US6961852B2/en
Priority to KR1020057022399A priority patent/KR100896625B1/en
Priority to PCT/US2003/039809 priority patent/WO2005006109A2/en
Priority to EP03817468A priority patent/EP1636715A4/en
Priority to KR1020097005256A priority patent/KR100974161B1/en
Priority to AU2003300926A priority patent/AU2003300926A1/en
Priority to CNB2003801094646A priority patent/CN100424678C/en
Priority to CA2525376A priority patent/CA2525376C/en
Priority to TW093115949A priority patent/TWI315627B/en
Publication of US20050010767A1 publication Critical patent/US20050010767A1/en
Publication of US6961852B2 publication Critical patent/US6961852B2/en
Application granted granted Critical
Priority to IL172519A priority patent/IL172519A0/en
Adjusted expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/123Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices

Definitions

  • the present invention relates in general to a system and method for authenticating software. More particularly, the present invention relates to a system and method for using a master key and hidden intermediate keys located on a computer system for authenticating software.
  • Anti-piracy measures that have previously been employed include encrypting the software program. In this manner, the user is provided with a “key” for opening the software along with the encrypted software program. Only a user with the right key can decrypt the software. A challenge of this method, however, is that experienced hackers can analyze the memory containing the executable form of the decrypted code and create a non-encrypted version. The non-encrypted version can then be distributed to others who no longer need to use the “key” to open the software.
  • Another anti-piracy measure is to use a device, often called a “dongle,” that must be used in order for the software to operate.
  • the device includes a key that is checked by the software before the software will operate.
  • One challenge of this method is that users are often forced to have several devices that they must attach to computers prior to loading the software program.
  • Another challenge is that experienced hackers can read the key being provided by the attached device and create a copy of the device or provide the key value using another software program.
  • FIG. 1 is a block diagram showing how a hacker monitors a system bus to illegally copy program data in the prior art.
  • Computer system 100 includes system memory 110 and processing core 130 that are interconnected with system bus 125 .
  • System memory 110 is where software program and data 120 are stored, typically after being read from a nonvolatile storage area, such as a disk drive or a nonvolatile memory.
  • Protected area 130 is a packaged component that includes one or more central processing units (CPUs) 135 and a small amount of storage 140 that is used for program storage 145 and data storage 150 .
  • Storage 140 may include registers, RAM, and other types of memory.
  • the amount of storage 140 is typically far less than the amount of memory included in system memory 110 , and is usually insufficient to contain a complete working copy of the software program and data. This then requires the software code and data to reside in executable form in system memory 110 .
  • Encryption and authentication keys are generally more susceptible of being hacked by a hacker the more times the hacker is able to view the results of using the encryption or authentication keys.
  • the hacker is able to use algorithms and other techniques to identify an encryption key that remains constants. These algorithms and techniques tend to be more successful when the hacker has more results to analyze. What is needed, therefore, is a system and method for authenticating software using intermediate keys that are generated using a hidden algorithm that is performed on a hidden master key in order to limit the hacker's ability to analyze results based upon the master key.
  • a processing unit includes a read-only encryption key that is unique, random, and non-trivial.
  • Software is loaded into a system memory area from a non-volatile storage device.
  • the system memory area may include flash memory, read-only memory (ROM), random access memory (RAM) or any other type of storage.
  • Code images that reside in the system storage area include a prefix value and a suffix value.
  • the prefix value is combined with the master key from the processing unit to create a random value using a mathematical operation, such as an exclusive OR (XOR) operation.
  • the random number is used as the “seed” or starting value for the hashing algorithm, such as SHA-256.
  • the seed value is used as the initial result in the hashing algorithm.
  • Intermediate results from the hashing algorithm are stored in a secure memory area for use by programs, such as a software loader.
  • intermediate results can be mathematically combined with the master key so that the intermediate keys can be subsequently authenticated using the secure master key.
  • an exit function cleans up the memory area storing the intermediate keys so that no one is able to analyze the keys and hack the master key that is stored on the processing unit.
  • a “micro-loader” is stored in a protected area (i.e., ROM) of a semiconductor package along with a master key that is stored in a nonvolatile memory area in the semiconductor package.
  • the micro-loader is used to authenticate a more full-functioning software loader using the master key.
  • One or more intermediate keys resulting from the hashing algorithm that was performed on the full-functioning software loader are stored in a memory area (e.g., registers, nonvolatile memory, etc.) within the semiconductor package.
  • the full-functioning software loader uses the intermediate keys to authenticate other software modules.
  • the full-functioning software loader is authenticated using the master key, while other software modules are authenticated using intermediate keys that do not expose the master key.
  • the intermediate keys are erased from memory so that a hacker is unable to view the keys in his quest to discover the system's master key.
  • the full-function loader can be replaced by providing the computer systems with a new or upgraded version of the full-function loader along with the prefix and suffix values for the new version of the loader.
  • FIG. 1 is a block diagram showing how a hacker monitors a system bus to illegally copy program data in the prior art
  • FIG. 2 is a block diagram showing the present invention preventing copies from executing on other devices
  • FIG. 3 is a block diagram of a computing device capable of implementing the present invention.
  • FIG. 4 is a flowchart showing steps taken to initialize hardware with a protected master key that is inaccessible outside the processor core;
  • FIG. 5 are high level flowcharts showing steps taken to distribute devices and software to customers and for the customers to load software
  • FIG. 6 is a flowchart showing steps taken to distribute software with authentication data
  • FIG. 7 is a flowchart showing steps taken at the customer's device to load software authenticated using a master key
  • FIG. 8 is a flowchart showing steps taken to authenticate software based upon hash results
  • FIG. 9 is a system diagram showing a micro-loader used to load a software loader into a protected area of a processing unit
  • FIG. 10 is a flowchart showing hardware initialization with a micro-loader and master key written to a protected area of the processing core
  • FIG. 11 are high level flowcharts showing steps taken to distribute devices and software utilizing a micro-loader stored in a protected processing area and a loader which is authenticated by the micro-loader;
  • FIG. 12 is a flowchart showing steps taken to distribute the device with a micro-loader, loader, and authentication keys;
  • FIG. 13 is a flowchart showing steps taken to distribute software that is adapted to be loaded by a device using a micro-loader and a loader;
  • FIG. 14 is a flowchart showing steps taken to prepare a software image with authentication information for delivery to a customer
  • FIG. 15 is a flowchart showing steps taken by a customer's device to load software using authentication by a micro-loader and loader;
  • FIG. 16 is a flowchart showing steps taken to authenticate and load the loader software generating a secondary key
  • FIG. 17 is a flowchart showing steps taken to authenticate and load the software using a secondary key.
  • FIG. 1 is a block diagram showing how a hacker monitors a system bus to illegally copy program data in the prior art. See the background section, above, for details regarding the prior art.
  • FIG. 2 is a block diagram showing the present invention preventing copies from executing on other devices.
  • Computer system 200 includes system memory 205 and processing core 240 that are interconnected with system bus 201 .
  • System memory 205 is where software code and data 230 are stored, typically after being read from a nonvolatile storage area, such as a disk drive or a nonvolatile memory.
  • System memory may include flash memory 210 , read-only memory (ROM) 215 , and random-access memory (RAM) 220 .
  • the software image stored in system memory 205 includes prefix 225 and suffix 235 used to authenticate the software.
  • Protected area 240 is a packaged component that includes one or more central processing units (CPUs) 245 and a small amount of storage 255 that is used for program storage 260 and data storage 265 .
  • Storage 255 may include registers, PAM, and other types of memory. Because of size constraints of the protected area package, the amount of storage 255 is typically far less than the amount of memory included in system memory 205 .
  • Storage 255 also includes a small amount of nonvolatile memory 270 , such as nonvolatile RAM or programmable fuses (e-fuses). Master key 275 , used to authenticate software, is stored in the nonvolatile memory.
  • Master key 275 is designed to be a unique (per protected package), non-trivial and random number of sufficient length (i.e., 256 bits) to enable strong authentication. Because the master key is included in the protected package, the only way a hacker would be able to read the master key is by physically removing layers from the packaging in order to expose the value of the master key, destroying the protected area in the process. Thus, while the hacker could obtain the value of the master key in a particular machine, that machine would be destroyed by the hacker's process and the master key obtained would be different from the master keys stored on other machines.
  • Protected area 240 also includes loader 250 .
  • Loader 250 is a specialized process used to load software and authenticate it using master key 275 . Because both loader 250 and master key 275 are within protected package 240 , the master key is not transmitted over bus 201 or over any bus or communication line that exits the protected package.
  • a hacker uses a hacking, or snooping, tool 280 in order to attempt to copy the software program and data.
  • the hacker's snooping tool monitors the data, including the prefix value, the software code and data, and the suffix value that flows over the system bus from the system memory to the protected area (step 285 ) and copies the data (step 290 ), creating copy 295 .
  • the master key was never transmitted over the bus, the hacker was unable to obtain the master key value.
  • master key values are preferably unique, non-trivial, random numbers, the hacker's copy of the software will only operate on the computer system from which it was copied.
  • the copied data (prefix value, software code and data, and suffix value) will not operate on a different machine because the other machine has a different master key that will not work with the copy. See the description for FIG. 5 , below, for details on how the authentication process works using the prefix and suffix values.
  • FIG. 3 illustrates information handling system 301 which is a simplified example of a computer system capable of performing the computing operations described herein.
  • Computer system 301 includes processing unit 300 that is packaged in a semiconductor package and coupled to host bus 305 .
  • Protected processing unit includes one or more processors 391 , processor storage 392 used to load and execute software programs from main memory 308 , software loader 393 used to authenticate and load software programs, and locked nonvolatile memory area 394 which is used to store a master key that is only accessible from within processing unit 300 and is not transmitted across host bus 302 .
  • Processing unit 300 is connected to host bus 302 .
  • a level two (L2) cache memory 304 is also coupled to host bus 302 .
  • L2 level two
  • Host-to-PCI bridge 306 is coupled to main memory 308 , includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus 310 , processor 300 , L2 cache 304 , main memory 308 , and host bus 302 .
  • Main memory 308 is coupled to Host-to-PCI bridge 306 as well as host bus 302 .
  • Devices used solely by host processor(s) 300 such as LAN card 330 , are coupled to PCI bus 310 .
  • Service Processor Interface and ISA Access Pass-through 312 provides an interface between PCI bus 310 and PCI bus 314 . In this manner, PCI bus 314 is insulated from PCI bus 310 .
  • Devices, such as flash memory 318 are coupled to PCI bus 314 .
  • flash memory 318 includes BIOS code that incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions.
  • PCI bus 314 provides an interface for a variety of devices that are shared by host processor(s) 300 and Service Processor 316 including, for example, flash memory 318 .
  • PCI-to-ISA bridge 335 provides bus control to handle transfers between PCI bus 314 and ISA bus 340 , universal serial bus (USB) functionality 345 , power management functionality 355 , and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support.
  • RTC real-time clock
  • Nonvolatile RAM 320 is attached to ISA Bus 340 .
  • Service Processor 316 includes JTAG and I2C busses 322 for communication L2 cache 304 , Host-to-PCI bridge 306 , and main memory 308 providing a communications path between the processor, the Service Processor, the L2 cache, the Host-to-PCI bridge, and the main memory. Service Processor 316 also has access to system power resources for powering down information handling device 301 .
  • Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g., parallel interface 362 , serial interface 364 , keyboard interface 368 , and mouse interface 370 coupled to ISA bus 340 .
  • I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus 340 .
  • LAN card 330 is coupled to PCI bus 310 .
  • modem 375 is connected to serial port 364 and PCI-to-ISA Bridge 335 .
  • FIG. 3 While the computer system described in FIG. 3 is capable of executing the processes described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the processes described herein.
  • FIG. 4 is a flowchart showing steps taken to initialize hardware with a protected master key that is inaccessible outside the processor core. Processing commences at 400 whereupon a random, unique, non-trivial master key value is generated (step 405 ). At step 410 , processing attempts to write the generated master key value to a nonvolatile memory location in protected processor area 415 of the machine that is being initialized.
  • the protected processor area includes a nonvolatile memory, such as a programmable “e-fuse” array 420 .
  • the nonvolatile memory location to which the master key value is written is lockable so that once the master key value is written to the nonvolatile memory location and verified, the master key cannot be altered or removed.
  • Lock key bit 425 includes a bit that, once set, cannot be changed. If the lock key has been set, the path used to write to nonvolatile memory area 420 is made inoperative.
  • decision 435 branches to “no” branch 455 whereupon the lock key controlling access to the nonvolatile memory location is set (step 460 ), permanently locking the nonvolatile memory location.
  • the serial number of the machine being initialized is recorded along with the master key value (step 470 ) in secure database 480 .
  • Master key values are stored in a secure database (i.e., one that is protected using encryption and unable to be infiltrated by network hackers) so that hackers and other individuals do not gain access to the master key values which would allow the hacker to circumvent the software authenticity that is provided through the use of the master keys. Processing thereafter ends at 490 .
  • FIG. 5 are high level flowcharts showing steps taken to distribute devices and software to customers and for the customers to load software.
  • Distribute device processing commences at 500 whereupon the device (i.e., machine) is built with a unique master key stored in a locked nonvolatile memory location and a loader programmed to load and authenticate software based upon the master key (step 503 ).
  • the master key value and device identifier i.e., serial number
  • device 515 (with the included master key and loader) is shipped to a consumer.
  • Distribute device processing thereafter ends at 509 .
  • Consumer processing commences at 518 whereupon the consumer receives the device with the embedded master key (step 521 ).
  • the consumer orders software for the device by sending order form 527 to a software distributor or retailer.
  • Order form 527 may be electronic (i.e., an Internet order), paper based (i.e., a mailed form), a telephone order, or an order placed at a retail location.
  • Distribute software processing commences at 530 whereupon the software distributor receives the order along with the device identifier (i.e., serial number) of the consumer's device (step 533 ).
  • the master key value corresponding to the device is retrieved (step 536 ) from secure database 512 .
  • a prefix value is created based upon the retrieved master key (step 539 ). In one embodiment, an exclusive or (XOR) operation is performed between a random value and the retrieved master key to create the prefix value.
  • a hashing algorithm such as SHA-256, is “seeded” with the random number used to generate the prefix value (step 542 ). Seeding the hashing algorithm sets the initial result of the hashing algorithm to the seed value, whereupon the hashing algorithm uses the result along with a hash of all or a portion of the software code, to generate additional results.
  • a suffix value is then generated (step 545 ). In one embodiment, the final result from the hashing algorithm hashing the requested program code is XORed with the master key to create the suffix value.
  • a software image that includes the prefix value, the software code, and the suffix value is packaged together into software image 550 and delivered to the consumer (step 548 ). Distribute software processing thereafter ends at 551 .
  • the consumer receives the created software image at step 560 .
  • the user wishes to use the software, he installs and/or loads the software and invokes the software (step 563 ).
  • software is first installed by copying the software image to a nonvolatile storage device, such as a hard disk.
  • the software program is packaged onto a module that is inserted into the game console whereupon the software is automatically invoked.
  • the loader determines the seed value used in the hashing algorithm based upon the prefix value included in the software image and the master key (step 566 ).
  • the prefix value is XORed with the master key to generate the seed value.
  • the hashing algorithm e.g., SHA-256
  • the hashing algorithm is seeded with the seed value and hashes the software code included in the software image (step 569 ).
  • the final result from the hashing algorithm is retrieved (step 572 ).
  • An expected result value is generated using the master key to check the final result.
  • the expected result is generated by performing an exclusive OR operation on the suffix value read from the software image and the master key (step 575 ).
  • decision 578 A determination is made as to whether the result from the hashing algorithm is equal to the expected result (decision 578 ). If the values are equal, decision 578 branches to “yes” branch 581 whereupon the software code is loaded (i.e., executed) by the processor, at step 584 . On the other hand, if the values are not equal (indicating that the software has been altered or that the software is not being used on the device for which it was ordered), decision 578 branches to “no” branch 587 bypassing the loading operation shown in step 584 . Consumer processing thereafter ends at 590 .
  • FIG. 6 is a flowchart showing steps taken to distribute software with authentication data.
  • Distribution processing commences at 600 whereupon, at step 608 , order 604 is received for a particular software product.
  • Order 604 includes both the customer's unique device identifier, such as a serial number, along with an identifier corresponding to the requested software product.
  • the master key corresponding to the consumer's device is retrieved from secure master key data store 616 .
  • a prefix value is created based upon the master key at step 620 .
  • the prefix value is created by XORing a random number with the master key.
  • a hashing algorithm such as SHA-256, is seeded with a value based on the prefix value and the master key.
  • the hashing algorithm is seeded with the random number used to create the prefix value.
  • the hashing algorithm is seeded by storing the seed value (e.g., the random number) as the initial value of the hashing result (memory location 632 ).
  • the requested software is located in software library 640 .
  • the requested software is software module 648 .
  • the first block of software code is read from the requested software module 648 .
  • the block of software code that was read is passed to a hashing algorithm, such as SHA-256.
  • the hashing algorithm receives the block of software code and the seed value stored in result 632 .
  • the result of the hashing algorithm is stored in result 632 , overwriting the previous (seed) result value.
  • decision 664 A determination is made as to whether the end of file has been reached on the software code (decision 664 ). If the end of file has not been reached, decision 664 branches to “no” branch 668 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of data along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on software code 648 , whereupon decision 664 branches to “yes” branch 672 .
  • a suffix value is created based upon the master key corresponding to the device and the final result from the hashing algorithm.
  • the suffix value is created by XORing the final result from the hashing algorithm with the master key.
  • software image 688 is created by packaging the prefix value, the software code (i.e., software module 648 ) and the suffix value into the software image file and sending the software image file to the customer. Distribution processing thereafter ends at 695 .
  • FIG. 7 is a flowchart showing steps taken at the customer's device to load software authenticated using a master key.
  • the loader is a process embedded within a protected semiconductor package within the device.
  • the semiconductor package also includes one or more processors and the master key. In this manner, the loader is able to retrieve and use the master key without ever transmitting the master key across a system or memory bus outside of the protected semiconductor package.
  • Step 705 master key 720 corresponding to the device is retrieved from locked nonvolatile memory area 715 .
  • the locked nonvolatile memory area is a set of programmable fuses (e-fuses) that, after being successfully loaded with the master key during creation of the device, is locked by setting a lock bit that prevents the master key from being altered or removed.
  • prefix value 735 for the software module being loaded is retrieved from software image 732 stored on nonvolatile storage device 730 , such as a hard disk or nonvolatile memory, located outside of the protected semiconductor package.
  • Software image 732 includes prefix value 735 , software code 745 , and suffix value 750 .
  • a hashing algorithm such as SHA-256, is seeded with a value based on the prefix value and the master key.
  • the hashing algorithm is seeded with the random number used to create the prefix value.
  • the seed value is generated by XORing the master key and the prefix value.
  • the hashing algorithm is seeded by storing the seed value (e.g., the random number) as the initial value of the hashing result (memory location 765 ).
  • the first block of software code is read from the requested software module 745 .
  • the block of software code that was read is passed to a hashing algorithm, such as SHA-256.
  • the hashing algorithm receives the block of software code and the seed value stored in result 765 .
  • the result of the hashing algorithm is stored in result 765 , overwriting the previous (seed) result value.
  • decision 782 A determination is made as to whether the end of file has been reached on the software code (decision 782 ). If the end of file has not been reached, decision 782 branches to “no” branch 784 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of data along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on software code 745 , whereupon decision 782 branches to “yes” branch 786 .
  • FIG. 8 is a flowchart showing steps taken to authenticate software based upon hash results. This routine is called from predefined process 790 , shown in FIG. 7 .
  • the loader's check hash results processing commences at 800 whereupon, at step 805 , master key 815 is retrieved from nonvolatile memory area 810 that is included in the protected semiconductor package.
  • suffix value 840 for the software that is being loaded is retrieved.
  • the suffix value is part of software image 828 .
  • Software image 828 is stored in a storage area, such as system memory, outside of the protected semiconductor package.
  • the software image also includes prefix value 830 and software code 835 .
  • An expected result value is computed based upon the retrieved suffix value and the master key (step 845 ).
  • the expected result is generated by XORing the master key with the suffix value.
  • the actual result from the hashing operation (result 860 ) is retrieved from a memory location located inside of the protected semiconductor package. The actual result was previously generated using the processing shown on FIG. 7 .
  • the expected result is not the same as the actual result, either the software code was altered or the software was created for a different device with a different master key than the device from which the load request was issued. The loader's check hash results processing thereafter returns to the calling routine at 895 .
  • FIG. 9 is a system diagram showing a micro-loader used to load a software loader into a protected area of a processing unit.
  • Computer system 900 includes unprotected storage 905 , such as system memory, disk devices, and the like, and protected semiconductor package 955 that includes packaged semiconductor components that interconnect within the package without use of a bus. Unprotected storage 905 and protected semiconductor package 955 communicate with one another using one or more busses, 950 .
  • Unprotected storage 905 stores software loader image 910 and application program image 930 .
  • Each of these software images include a prefix value ( 915 and 935 , respectively), software code ( 920 and 940 , respectively), and a suffix value ( 925 and 945 , respectively).
  • Protected semiconductor package 955 includes one or more processors 960 , and storage 965 .
  • Storage 965 includes a read-only memory (ROM) of micro-loader code 970 .
  • the micro-loader is a scaled-down loader that is written to authenticate and load software loader 910 .
  • Software loader is a more robust loader that is designed to load application programs, such as application 930 .
  • micro-loader 970 is stored in read-only memory and, therefore, cannot be changed or altered without replacing the protected semiconductor package.
  • Software loader 910 is stored in alterable memory, such as a hard disk, and can therefore be updated if errors in the loader are found or when enhancements or other modifications to the loader are created.
  • Storage 965 also includes program storage 975 into which both software loader 910 and application program 930 are loaded, in storage areas 980 and 985 , respectively, in order to be executed by the processors. Storage further includes a memory location for storing intermediate keys 990 that are generated by the micro-loader while loading the software loader. Finally, storage 965 includes a locked nonvolatile memory 992 , such as programmable fuses (e-fuses). Nonvolatile memory 992 is inaccessible from outside the protected semiconductor package. Nonvolatile memory 992 is used to store master key 995 which is a unique, random, nontrivial value of a sufficient length (e.g., 256 bits). After the device is created and the master key is stored in the nonvolatile memory, the nonvolatile memory is locked, thereby preventing further operations from altering or removing the master key.
  • master key 995 is a unique, random, nontrivial value of a sufficient length (e.g., 256 bits).
  • FIG. 10 is a flowchart showing hardware initialization with a micro-loader and master key written to a protected area of the processing core.
  • Hardware initialization commences at 1000 whereupon, at step 1004 , a random, unique, nontrivial master key value is generated of a sufficient length (i.e., 256 bits). The generated master key is stored in memory location 1008 .
  • a prefix value is created based upon the generated master key and stored in memory location 1016 .
  • the prefix value is created by XORing the generated master key with another random number.
  • a hashing algorithm such as SHA-256, is seeded using a value based upon the prefix value, such as the random number used to generate the prefix value. The seed value is used as an initial result 1024 of the hashing algorithm.
  • the first block of software loader code is read.
  • the software loader code is the software loader that is loaded by the micro-loader.
  • the block of software code that was read is passed to a hashing algorithm, such as SHA-256.
  • the hashing algorithm receives the block of the software loader code and the seed value stored in result 1024 .
  • the result of the hashing algorithm is stored in result 1024 , overwriting the previous (seed) result value.
  • decision 1040 A determination is made as to whether the end of file has been reached on the software loader code (decision 1040 ). If the end of file has not been reached, decision 1040 branches to “no” branch 1042 which loops back to read the next block of software loader code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of software loader code along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on the software loader, whereupon decision 1040 branches to “yes” branch 1044 .
  • a suffix value is created based upon the master key and the final result resulting from the hashing algorithm and stored in memory location 1052 .
  • the master key and final result are XORed to create the suffix value.
  • the software loader image 1078 is created by packaging the loader code along with the prefix and suffix values and stored.
  • Software loader image 1078 is stored on nonvolatile storage device 1076 , such as a disk drive or nonvolatile memory, which is accessible from protected processing core 1064 and included in information handling system 1060 .
  • Protected processing core 1064 also includes micro-loader software, stored in ROM, that is programmed to use the master key to load and authenticate the loader code included in loader image 1078 .
  • the generated master key is written to nonvolatile memory 1070 located within protected processing core 1064 .
  • Nonvolatile memory 1070 is also locked using lock key 1072 . Locking the nonvolatile memory prevents any process from altering or removing the master key.
  • the unique identifier such as a serial number
  • the hardware being initialized is written to secure database 1088 along with the device's master key value and the version of the software loader (loader image 1078 ) that was stored on the device's nonvolatile storage device.
  • Hardware initialization processing thereafter ends at 1095 .
  • FIG. 11 are high level flowcharts showing steps taken to distribute devices and software utilizing a micro-loader stored in a protected processing area and a loader which is authenticated by the micro-loader.
  • Provider processing used to distribute devices and software, commences at 1100 .
  • the device is built with a unique master key included in a protected processor core area (predefined process 1110 , see FIG. 12 and corresponding text for processing details) and the master key value and device identifier written to secure database 1115 .
  • the device (device 1125 ) is shipped to a customer.
  • Consumer processing commences at 1130 whereupon, at step 1135 , the consumer receives the device that has a master key embedded in its protected processor core area.
  • the consumer orders software for the device and transmits order 1145 to a producer of the software.
  • the producer receives customer's order 1145 that includes the unique identifier, such as the device serial number.
  • the producer retrieves the master key value corresponding to the device from database 1115 in order to create software image 1170 (predefined process 1150 , see FIGS. 13 and 14 and corresponding text for processing details). Thereafter, producer processing ends at 1160 .
  • the consumer receives the software image corresponding to the ordered software at step 1175 .
  • the software loader is loaded by the micro-loader (predefined process 1180 , see FIGS. 15 and 16 and corresponding text for processing details).
  • the software loader loads and authenticates the software program (predefined process 1190 , see FIGS. 15 and corresponding text for processing details). Consumer processing thereafter ends at 1195 .
  • FIG. 12 is a flowchart showing steps taken to distribute the device with a micro-loader, loader, and authentication keys. The processing shown in FIG. 12 is called from predefined process 1110 shown in FIG. 11 .
  • Device creation processing commences at 1200 whereupon, at step 1205 , a unique, random, and nontrivial master key is generated and stored in memory location 1210 .
  • the master key is stored in a nonvolatile memory area located within protected area 1225 of the processor core within device 1220 . After the master key is stored, the nonvolatile memory area in the protected area is locked so that the master key cannot be altered or removed.
  • micro-loader program 1235 is stored in ROM in the processor core.
  • the micro-loader is unable to be read or altered from outside the protected area of the device.
  • another random number is generated.
  • a prefix value is calculated based upon the generated random number and the master key (step 1250 ). In one embodiment, the prefix is calculated by XORing the master key with the random number.
  • a hashing algorithm such as SHA-256, is seeded with the random number generated in step 1245 and software loader 1260 is hashed using the hashing algorithm.
  • a suffix value is then calculated, at step 1265 , by combining the result of the hashing algorithm with the master key.
  • the master key and the result from the hashing algorithm are XORed to create the suffix value.
  • loader image 1275 is created using the prefix value, the suffix value, and the loader code.
  • the loader image is stored in an unprotected area, such as a disk drive or other nonvolatile memory location, within device 1220 in an area accessible by the protected processor core.
  • the device identifier i.e., serial number
  • the device's master key value, loader version, and prefix value in secure database 1285 .
  • Device creation processing thereafter returns at 1295 .
  • FIG. 13 is a flowchart showing steps taken to distribute software that is adapted to be loaded by a device using a micro-loader and a loader. The processing shown in FIG. 13 is called from predefined process 1150 shown in FIG. 11 .
  • Software distribution processing commences at 1300 whereupon the master key, loader version, and loader prefix value corresponding to the customer's device are retrieved (step 1305 ) from secure database 1310 .
  • a hashing algorithm such as SHA-256, is seeded with a value based upon the loader prefix and the master key.
  • the seed value is created by XORing the master key with the loader prefix value.
  • the hashing algorithm is seeded by storing the seed value (e.g., the random number resulting from the XOR operation) as the initial value of the hashing result (memory location 1320 ).
  • a secondary key count is retrieved at step 1325 .
  • the secondary key count indicates the number of iterations of the hashing algorithm that are performed after which the current result is used as a secondary key value. For example, if the secondary key count is “10”, then after the hashing algorithm iterates 10 times, whatever result is in result memory area 1320 is used as a secondary key by the software loader.
  • a counter that is used to track the number of iterations is initialized to zero.
  • the first block of the loader code that is installed on the customer's device is read from memory area 1340 .
  • the counter is incremented to indicate that the hashing algorithm has been performed once and, at step 1350 , the block of code is processed using the hashing algorithm.
  • the hashing algorithm receives the block of software code and the seed value stored in result 1320 .
  • the result of the hashing algorithm is stored in result 1320 , overwriting the previous (seed) result value.
  • decision 1360 A determination is made as to whether the counter is equal to the secondary key count constant (decision 1360 ). If the counter has not yet reached the secondary key count, decision 1360 branches to “no” branch 1365 whereupon processing loops back to process the next block of loader code and increment the counter. This looping continues until the counter is equal to the secondary key count, at which point decision 1360 branches to “yes” branch 1370 .
  • the secondary key value is set to the current result resulting from a number of iterations of the hashing algorithm.
  • the software application such as an application program or game software, is then processed using the secondary key value (predefined process 1380 , see FIG. 14 and corresponding text for processing details). Processing thereafter returns to the calling procedure at 1395 .
  • FIG. 14 is a flowchart showing steps taken to prepare a software image with authentication information for delivery to a customer. The processing shown in FIG. 14 is called from predefined process 1380 shown in FIG. 13 .
  • Processing to create an image of the requested software commences at 1400 whereupon a random number is generated at step 1410 .
  • a prefix value is determined based upon the random number and the secondary key value (step 1420 , see FIG. 13 for a details on the creation of the secondary key value).
  • an exclusive or (XOR) operation is performed between the random value and the secondary key value to create the prefix value.
  • a hashing algorithm such as SHA-256, is seeded using a value based upon the prefix value, such as the random number used to generate the prefix value. The seed value is used as an initial result 1430 of the hashing algorithm.
  • the first block of software code 1438 requested by the user is read.
  • the block of software code that was read is passed to a hashing algorithm, such as SHA-256.
  • the hashing algorithm receives the block of the software code and the seed value stored in result 1430 .
  • the result of the hashing algorithm is stored in result 1430 , overwriting the previous (seed) result value.
  • decision 1450 A determination is made as to whether the end of file has been reached on the software code (decision 1450 ). If the end of file has not been reached, decision 1450 branches to “no” branch 1455 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of software code along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on the software code, whereupon decision 1450 branches to “yes” branch 1460 .
  • a suffix value is created based upon the secondary key and the final result resulting from the hashing algorithm.
  • the secondary key and final result are XORed to create the suffix value.
  • software image 1480 is created by packaging the software code along with the prefix and suffix values.
  • software image 1480 is sent to the customer, either on a nonvolatile medium, through the Internet, or in any other fashion. Processing thereafter returns to the calling routine at 1495 .
  • FIG. 15 is a flowchart showing steps taken by a customer's device to load software using authentication by a micro-loader and loader. The processing shown in FIG. 15 is called from predefined processes 1180 and 1190 shown in FIG. 11 .
  • the process of loading software on the customer's device commences at 1500 whereupon master key 1515 , located in a locked, nonvolatile storage area within the device's operating core is used to authenticate and load software loader image 1520 and generate secondary key 1525 ((predefined process 1510 , see FIG. 16 and corresponding text for processing details).
  • master key 1515 located in a locked, nonvolatile storage area within the device's operating core is used to authenticate and load software loader image 1520 and generate secondary key 1525 ((predefined process 1510 , see FIG. 16 and corresponding text for processing details).
  • decision 1570 A determination is made as to whether the software was authenticated (decision 1570 ). If the software was not authenticated, decision 1570 branches to “no” branch 1574 whereupon the secondary key values are removed (cleaned up) from processor core storage memory (step 1590 ). On the other hand, if the software was authenticated, decision 1570 branches to “yes” branch 1578 whereupon the software code is executed by the processor at step 1580 and the secondary keys are removed (cleaned up) from processor core storage memory at step 1590 . Processing thereafter returns to the calling routine at 1595 .
  • FIG. 16 is a flowchart showing steps taken to authenticate and load the loader software generating a secondary key. The processing shown in FIG. 16 is called from predefined processes 1510 shown in FIG. 15 .
  • Micro-loader processing used to authenticate and load the software loader commences at 1600 whereupon, in step 1605 , master key 1615 for the device is retrieved by the micro-loader from locked nonvolatile memory and the prefix value corresponding to software loader image 1610 is retrieved from a non-protected area (e.g., system memory).
  • a non-protected area e.g., system memory
  • a hashing algorithm such as SHA-256, is seeded with a value based upon the loader prefix and the master key.
  • the seed value is created by XORing the master key with the loader prefix value.
  • the hashing algorithm is seeded by storing the seed value (e.g., the random number resulting from the XOR operation) as the initial value of the hashing result (memory location 1625 ).
  • a secondary key count is retrieved at step 1630 .
  • the secondary key count indicates the number of iterations of the hashing algorithm that are performed after which the current result is used as a secondary key value. For example, if the secondary key count is “10”, then after the hashing algorithm iterates 10 times, whatever result is in result memory area 1625 is used as a secondary key by the software loader.
  • the secondary key count is retrieved from the locked nonvolatile memory area that is used to store the master key.
  • a counter that is used to track the number of iterations is initialized to zero.
  • the first block of the loader code that is installed on the customer's device is read from loader image 1610 .
  • the counter is incremented to indicate that the hashing algorithm has been performed once and, at step 1650 , the block of code is processed using the hashing algorithm.
  • the hashing algorithm receives the block of software code and the seed value stored in result 1625 .
  • the result of the hashing algorithm is stored in result 1625 , overwriting the previous (seed) result value.
  • decision 1660 branches to “no” branch 1662 whereupon processing loops back to process the next block of loader code and increment the counter. This looping continues until the counter is equal to the secondary key count, at which point decision 1660 branches to “yes” branch 1668 whereupon, at step 1669 , the secondary key value is set to the current result resulting from a number of iterations of the hashing algorithm.
  • decision 1670 A determination is made as to whether the end of the software loader file has been reached (decision 1670 ). If the end of the file has not been reached, decision 1670 branches to “no” branch 1672 whereupon processing loops back to process the next block of code from the software loader using the hashing algorithm. This looping continues until the end of file has been reached, at which point decision 1670 branches to “yes” branch 1674 .
  • the expected result is determined based upon the suffix value and the master key.
  • the expected result is calculated by XORing the master key with the suffix value.
  • a determination is made as to whether the result resulting from the hashing algorithm is equal to the expected result (decision 1680 ). If the result from the hashing algorithm is equal to the expected result, decision 1680 branches to “yes” branch 1685 whereupon the software loader is executed at step 1690 .
  • decision 1680 branches to “no” branch 1692 bypassing the execution of the software loading program. Processing thereafter returns to the calling routine at 1695 .
  • FIG. 17 is a flowchart showing steps taken to authenticate and load the software using a secondary key.
  • the processing shown in FIG. 17 is called from predefined processes 1550 shown in FIG. 15 after the secondary key has been determined using the processing shown in FIG. 16 .
  • processing used to authenticate and load software using a secondary key value commences at 1700 .
  • the secondary key value (determined using the processing shown on FIG. 16 and stored in a memory area within the protected processing core) is retrieved along with the prefix value for software image 1725 .
  • a hashing algorithm such as SHA-256, is seeded using a value based upon the prefix value, such as a random number that was used to generate the prefix value.
  • the seed value is used as initial result 1740 of the hashing algorithm.
  • an exclusive or (XOR) operation is performed between secondary key 1720 and the prefix value resulting in the random number that was originally used in creating the prefix value. This random number is used to seed the hashing algorithm.
  • the first block of the software code included in software image 1725 is read.
  • the block of software code that was read is passed to a hashing algorithm, such as SHA-256.
  • the hashing algorithm receives the block of the software code and the seed value stored in result 1740 .
  • the result of the hashing algorithm is stored in result 1740 , overwriting the previous (seed) result value.
  • decision 1765 A determination is made as to whether the end of file has been reached on the software code (decision 1765 ). If the end of file has not been reached, decision 1765 branches to “no” branch 1768 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of software code along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on the software code, whereupon decision 1765 branches to “yes” branch 1770 .
  • an expected result value is created using the suffix value from software image 1725 and secondary key value 1720 . In one embodiment, these two values are XORed to generate the expected result.
  • a determination is made as to whether the result resulting from the hashing algorithm is equal to the expected result (decision 1780 ). If the result from the hashing algorithm is equal to the expected result, decision 1780 branches to “yes” branch 1785 whereupon the software program is executed at step 1790 .
  • decision 1780 branches to “no” branch 1792 bypassing the execution of the software program. Processing thereafter returns to the calling routine at 1795 .
  • One of the preferred implementations of the invention is a client application, namely, a set of instructions (program code) in a code module that may, for example, be resident in the random access memory of the computer.
  • the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network.
  • the present invention may be implemented as a computer program product for use in a computer.
  • prefix and “suffix” to describe authentication values used herein does not imply that such values need to be located in any particular area relative to the corresponding software code. Rather, such terms are used to describe when the values are used in conjunction with the authentication process.
  • the prefix value is used to determine a seed value for the authentication process, while the suffix value is used to generate an expected result that is in turn compared with a result from the hashing algorithm.
  • the actual prefix and suffix values can be stored either along with their respective software modules, or can be stored separately in a location distinct and apart from the software module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Remote Sensing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)

Abstract

A processing unit includes a read-only encryption key. Loader code image is loaded into system memory from non-volatile storage. Loader code image includes a prefix value and a suffix value. The prefix value is combined with the master key from the processing unit to create a random value that is the seed for a hashing algorithm. The hashing algorithm uses the seed value with a signature formed from the blocks of code to form a result. During the hashing algorithm, intermediate key values are generated and stored in a memory area inaccessible by the user. The intermediate key values are used by the loader code after the loader has been authenticated and loaded. The loader combines one or more of the intermediate key values with prefix and suffix values that correspond to other software modules to authenticate the software, using a hashing algorithm, and load the software upon authentication.

Description

BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to a system and method for authenticating software. More particularly, the present invention relates to a system and method for using a master key and hidden intermediate keys located on a computer system for authenticating software.
2. Description of the Related Art
In our modern society, software is increasingly becoming one of the most valuable technologies. Software controls devices, such as appliances, automobiles, telephones, and especially computer systems. Computer systems exist in a variety of forms. These forms include traditional desktop and notebook computers, as well as pervasive computing devices such as mobile telephones, and personal digital assistants (PDAs). In addition, software is used for entertainment purposes, such as games designed for personal computers as well as games designed for specialized gaming devices.
Large amounts of time, money, and resources are dedicated towards creating software. Many companies derive all or most of their income from creating software. Software programs sold by these companies include customized software that is written for particular environment or client, as well as off-the-shelf software that is designed in written for larger group of users.
Because software is so valuable, and because computers make it easy to create an exact copy of a program, software piracy is widespread. Software pirates range from individual computer users to professionals who deal wholesale with stolen software. Software piracy exists in homes, schools, businesses, and governments.
Anti-piracy measures that have previously been employed include encrypting the software program. In this manner, the user is provided with a “key” for opening the software along with the encrypted software program. Only a user with the right key can decrypt the software. A challenge of this method, however, is that experienced hackers can analyze the memory containing the executable form of the decrypted code and create a non-encrypted version. The non-encrypted version can then be distributed to others who no longer need to use the “key” to open the software.
Another anti-piracy measure is to use a device, often called a “dongle,” that must be used in order for the software to operate. The device includes a key that is checked by the software before the software will operate. One challenge of this method is that users are often forced to have several devices that they must attach to computers prior to loading the software program. Another challenge is that experienced hackers can read the key being provided by the attached device and create a copy of the device or provide the key value using another software program.
FIG. 1 is a block diagram showing how a hacker monitors a system bus to illegally copy program data in the prior art. Computer system 100 includes system memory 110 and processing core 130 that are interconnected with system bus 125. System memory 110 is where software program and data 120 are stored, typically after being read from a nonvolatile storage area, such as a disk drive or a nonvolatile memory. Protected area 130 is a packaged component that includes one or more central processing units (CPUs) 135 and a small amount of storage 140 that is used for program storage 145 and data storage 150. Storage 140 may include registers, RAM, and other types of memory. Because of size constraints of the protected area package, the amount of storage 140 is typically far less than the amount of memory included in system memory 110, and is usually insufficient to contain a complete working copy of the software program and data. This then requires the software code and data to reside in executable form in system memory 110.
Even if the source of the software stored in system memory 110 is encrypted, the program and data must first be decrypted before it can be processed by the CPUs. A hacker may then use a hacking, or snooping, tool 170 in order to capture an executable form of the software program and data during this decryption process. The hacker's snooping tool monitors the decrypted data that flows over the system bus from the protected area to the system memory (step 175) and copies the data (step 180), creating illegal copy 190. Illegal copy 190 is not encrypted (even if the original program was encrypted) and can be executed on any computer system that is compatible with the software.
Encryption and authentication keys are generally more susceptible of being hacked by a hacker the more times the hacker is able to view the results of using the encryption or authentication keys. The hacker is able to use algorithms and other techniques to identify an encryption key that remains constants. These algorithms and techniques tend to be more successful when the hacker has more results to analyze. What is needed, therefore, is a system and method for authenticating software using intermediate keys that are generated using a hidden algorithm that is performed on a hidden master key in order to limit the hacker's ability to analyze results based upon the master key.
SUMMARY
A processing unit includes a read-only encryption key that is unique, random, and non-trivial. Software is loaded into a system memory area from a non-volatile storage device. The system memory area may include flash memory, read-only memory (ROM), random access memory (RAM) or any other type of storage. Code images that reside in the system storage area include a prefix value and a suffix value. The prefix value is combined with the master key from the processing unit to create a random value using a mathematical operation, such as an exclusive OR (XOR) operation. The random number is used as the “seed” or starting value for the hashing algorithm, such as SHA-256. The seed value is used as the initial result in the hashing algorithm. Software code that follows the seed value is read in blocks, such as 512 byte blocks. The hashing algorithm uses the seed value with a signature formed from the newly read block of code to form a result. This result is then used by the hashing algorithm along with the next block of code to form a new result. Processing loops through each block of code with read block producing a new intermediate result value. Finally, after the last block has been processed, the final result value will be left as the result of the complete hashing operation.
Intermediate results from the hashing algorithm are stored in a secure memory area for use by programs, such as a software loader. In addition, intermediate results can be mathematically combined with the master key so that the intermediate keys can be subsequently authenticated using the secure master key. When exiting the secure state, an exit function cleans up the memory area storing the intermediate keys so that no one is able to analyze the keys and hack the master key that is stored on the processing unit.
In one embodiment, a “micro-loader” is stored in a protected area (i.e., ROM) of a semiconductor package along with a master key that is stored in a nonvolatile memory area in the semiconductor package. The micro-loader is used to authenticate a more full-functioning software loader using the master key. One or more intermediate keys resulting from the hashing algorithm that was performed on the full-functioning software loader are stored in a memory area (e.g., registers, nonvolatile memory, etc.) within the semiconductor package. The full-functioning software loader uses the intermediate keys to authenticate other software modules. In this manner, only the full-functioning software loader is authenticated using the master key, while other software modules are authenticated using intermediate keys that do not expose the master key. When the full-functioning loader is finished analyzing a software module, the intermediate keys are erased from memory so that a hacker is unable to view the keys in his quest to discover the system's master key. In addition, while the micro-loader cannot be changed without modifying (i.e., replacing) the semiconductor package, the full-function loader can be replaced by providing the computer systems with a new or upgraded version of the full-function loader along with the prefix and suffix values for the new version of the loader.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
FIG. 1 is a block diagram showing how a hacker monitors a system bus to illegally copy program data in the prior art;
FIG. 2 is a block diagram showing the present invention preventing copies from executing on other devices;
FIG. 3 is a block diagram of a computing device capable of implementing the present invention;
FIG. 4 is a flowchart showing steps taken to initialize hardware with a protected master key that is inaccessible outside the processor core;
FIG. 5 are high level flowcharts showing steps taken to distribute devices and software to customers and for the customers to load software;
FIG. 6 is a flowchart showing steps taken to distribute software with authentication data;
FIG. 7 is a flowchart showing steps taken at the customer's device to load software authenticated using a master key;
FIG. 8 is a flowchart showing steps taken to authenticate software based upon hash results;
FIG. 9 is a system diagram showing a micro-loader used to load a software loader into a protected area of a processing unit;
FIG. 10 is a flowchart showing hardware initialization with a micro-loader and master key written to a protected area of the processing core;
FIG. 11 are high level flowcharts showing steps taken to distribute devices and software utilizing a micro-loader stored in a protected processing area and a loader which is authenticated by the micro-loader;
FIG. 12 is a flowchart showing steps taken to distribute the device with a micro-loader, loader, and authentication keys;
FIG. 13 is a flowchart showing steps taken to distribute software that is adapted to be loaded by a device using a micro-loader and a loader;
FIG. 14 is a flowchart showing steps taken to prepare a software image with authentication information for delivery to a customer;
FIG. 15 is a flowchart showing steps taken by a customer's device to load software using authentication by a micro-loader and loader;
FIG. 16 is a flowchart showing steps taken to authenticate and load the loader software generating a secondary key; and
FIG. 17 is a flowchart showing steps taken to authenticate and load the software using a secondary key.
DETAILED DESCRIPTION
The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined in the claims following the description.
FIG. 1 is a block diagram showing how a hacker monitors a system bus to illegally copy program data in the prior art. See the background section, above, for details regarding the prior art.
FIG. 2 is a block diagram showing the present invention preventing copies from executing on other devices. Computer system 200 includes system memory 205 and processing core 240 that are interconnected with system bus 201. System memory 205 is where software code and data 230 are stored, typically after being read from a nonvolatile storage area, such as a disk drive or a nonvolatile memory. System memory may include flash memory 210, read-only memory (ROM) 215, and random-access memory (RAM) 220. Unlike the prior art, the software image stored in system memory 205 includes prefix 225 and suffix 235 used to authenticate the software.
Protected area 240 is a packaged component that includes one or more central processing units (CPUs) 245 and a small amount of storage 255 that is used for program storage 260 and data storage 265. Storage 255 may include registers, PAM, and other types of memory. Because of size constraints of the protected area package, the amount of storage 255 is typically far less than the amount of memory included in system memory 205. Storage 255 also includes a small amount of nonvolatile memory 270, such as nonvolatile RAM or programmable fuses (e-fuses). Master key 275, used to authenticate software, is stored in the nonvolatile memory. Master key 275 is designed to be a unique (per protected package), non-trivial and random number of sufficient length (i.e., 256 bits) to enable strong authentication. Because the master key is included in the protected package, the only way a hacker would be able to read the master key is by physically removing layers from the packaging in order to expose the value of the master key, destroying the protected area in the process. Thus, while the hacker could obtain the value of the master key in a particular machine, that machine would be destroyed by the hacker's process and the master key obtained would be different from the master keys stored on other machines.
Protected area 240 also includes loader 250. Loader 250 is a specialized process used to load software and authenticate it using master key 275. Because both loader 250 and master key 275 are within protected package 240, the master key is not transmitted over bus 201 or over any bus or communication line that exits the protected package.
A hacker uses a hacking, or snooping, tool 280 in order to attempt to copy the software program and data. The hacker's snooping tool monitors the data, including the prefix value, the software code and data, and the suffix value that flows over the system bus from the system memory to the protected area (step 285) and copies the data (step 290), creating copy 295. However, because the master key was never transmitted over the bus, the hacker was unable to obtain the master key value. Because master key values are preferably unique, non-trivial, random numbers, the hacker's copy of the software will only operate on the computer system from which it was copied. Importantly, the copied data (prefix value, software code and data, and suffix value) will not operate on a different machine because the other machine has a different master key that will not work with the copy. See the description for FIG. 5, below, for details on how the authentication process works using the prefix and suffix values.
FIG. 3 illustrates information handling system 301 which is a simplified example of a computer system capable of performing the computing operations described herein. Computer system 301 includes processing unit 300 that is packaged in a semiconductor package and coupled to host bus 305. Protected processing unit includes one or more processors 391, processor storage 392 used to load and execute software programs from main memory 308, software loader 393 used to authenticate and load software programs, and locked nonvolatile memory area 394 which is used to store a master key that is only accessible from within processing unit 300 and is not transmitted across host bus 302. Processing unit 300 is connected to host bus 302. A level two (L2) cache memory 304 is also coupled to host bus 302. Host-to-PCI bridge 306 is coupled to main memory 308, includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus 310, processor 300, L2 cache 304, main memory 308, and host bus 302. Main memory 308 is coupled to Host-to-PCI bridge 306 as well as host bus 302. Devices used solely by host processor(s) 300, such as LAN card 330, are coupled to PCI bus 310. Service Processor Interface and ISA Access Pass-through 312 provides an interface between PCI bus 310 and PCI bus 314. In this manner, PCI bus 314 is insulated from PCI bus 310. Devices, such as flash memory 318, are coupled to PCI bus 314. In one implementation, flash memory 318 includes BIOS code that incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions.
PCI bus 314 provides an interface for a variety of devices that are shared by host processor(s) 300 and Service Processor 316 including, for example, flash memory 318. PCI-to-ISA bridge 335 provides bus control to handle transfers between PCI bus 314 and ISA bus 340, universal serial bus (USB) functionality 345, power management functionality 355, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Nonvolatile RAM 320 is attached to ISA Bus 340. Service Processor 316 includes JTAG and I2C busses 322 for communication L2 cache 304, Host-to-PCI bridge 306, and main memory 308 providing a communications path between the processor, the Service Processor, the L2 cache, the Host-to-PCI bridge, and the main memory. Service Processor 316 also has access to system power resources for powering down information handling device 301.
Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g., parallel interface 362, serial interface 364, keyboard interface 368, and mouse interface 370 coupled to ISA bus 340. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus 340.
In order to attach computer system 301 to another computer system to copy files over a network, LAN card 330 is coupled to PCI bus 310. Similarly, to connect computer system 301 to an ISP to connect to the Internet using a telephone line connection, modem 375 is connected to serial port 364 and PCI-to-ISA Bridge 335.
While the computer system described in FIG. 3 is capable of executing the processes described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the processes described herein.
FIG. 4 is a flowchart showing steps taken to initialize hardware with a protected master key that is inaccessible outside the processor core. Processing commences at 400 whereupon a random, unique, non-trivial master key value is generated (step 405). At step 410, processing attempts to write the generated master key value to a nonvolatile memory location in protected processor area 415 of the machine that is being initialized. The protected processor area includes a nonvolatile memory, such as a programmable “e-fuse” array 420. The nonvolatile memory location to which the master key value is written is lockable so that once the master key value is written to the nonvolatile memory location and verified, the master key cannot be altered or removed. Lock key bit 425 includes a bit that, once set, cannot be changed. If the lock key has been set, the path used to write to nonvolatile memory area 420 is made inoperative.
A determination is made as to whether the nonvolatile memory location to which the master key value is written has already been locked (decision 435). If the nonvolatile memory location has already been locked, decision 435 branches to “yes” branch 445 whereupon an error is returned indicating that the nonvolatile memory location has already been locked (step 445) and processing ends at 490.
On the other hand, if the nonvolatile memory location has not already been locked, decision 435 branches to “no” branch 455 whereupon the lock key controlling access to the nonvolatile memory location is set (step 460), permanently locking the nonvolatile memory location. The serial number of the machine being initialized is recorded along with the master key value (step 470) in secure database 480. Master key values are stored in a secure database (i.e., one that is protected using encryption and unable to be infiltrated by network hackers) so that hackers and other individuals do not gain access to the master key values which would allow the hacker to circumvent the software authenticity that is provided through the use of the master keys. Processing thereafter ends at 490.
FIG. 5 are high level flowcharts showing steps taken to distribute devices and software to customers and for the customers to load software. Distribute device processing commences at 500 whereupon the device (i.e., machine) is built with a unique master key stored in a locked nonvolatile memory location and a loader programmed to load and authenticate software based upon the master key (step 503). As shown in FIG. 4, the master key value and device identifier (i.e., serial number) are stored in secure database 512. At step 506, device 515 (with the included master key and loader) is shipped to a consumer. Distribute device processing thereafter ends at 509.
Consumer processing commences at 518 whereupon the consumer receives the device with the embedded master key (step 521). At step 524, the consumer orders software for the device by sending order form 527 to a software distributor or retailer. Order form 527 may be electronic (i.e., an Internet order), paper based (i.e., a mailed form), a telephone order, or an order placed at a retail location.
Distribute software processing commences at 530 whereupon the software distributor receives the order along with the device identifier (i.e., serial number) of the consumer's device (step 533). The master key value corresponding to the device is retrieved (step 536) from secure database 512. A prefix value is created based upon the retrieved master key (step 539). In one embodiment, an exclusive or (XOR) operation is performed between a random value and the retrieved master key to create the prefix value.
A hashing algorithm, such as SHA-256, is “seeded” with the random number used to generate the prefix value (step 542). Seeding the hashing algorithm sets the initial result of the hashing algorithm to the seed value, whereupon the hashing algorithm uses the result along with a hash of all or a portion of the software code, to generate additional results. A suffix value is then generated (step 545). In one embodiment, the final result from the hashing algorithm hashing the requested program code is XORed with the master key to create the suffix value. A software image that includes the prefix value, the software code, and the suffix value is packaged together into software image 550 and delivered to the consumer (step 548). Distribute software processing thereafter ends at 551.
Returning to consumer processing, the consumer receives the created software image at step 560. When the user wishes to use the software, he installs and/or loads the software and invokes the software (step 563). In some computing environments, software is first installed by copying the software image to a nonvolatile storage device, such as a hard disk. In another environment, often used with game consoles, the software program is packaged onto a module that is inserted into the game console whereupon the software is automatically invoked.
During the loading process, the loader (located in the protected area of the device) determines the seed value used in the hashing algorithm based upon the prefix value included in the software image and the master key (step 566). In one embodiment, the prefix value is XORed with the master key to generate the seed value. The hashing algorithm (e.g., SHA-256) is seeded with the seed value and hashes the software code included in the software image (step 569). The final result from the hashing algorithm is retrieved (step 572). An expected result value is generated using the master key to check the final result. In one embodiment, the expected result is generated by performing an exclusive OR operation on the suffix value read from the software image and the master key (step 575).
A determination is made as to whether the result from the hashing algorithm is equal to the expected result (decision 578). If the values are equal, decision 578 branches to “yes” branch 581 whereupon the software code is loaded (i.e., executed) by the processor, at step 584. On the other hand, if the values are not equal (indicating that the software has been altered or that the software is not being used on the device for which it was ordered), decision 578 branches to “no” branch 587 bypassing the loading operation shown in step 584. Consumer processing thereafter ends at 590.
FIG. 6 is a flowchart showing steps taken to distribute software with authentication data. Distribution processing commences at 600 whereupon, at step 608, order 604 is received for a particular software product. Order 604 includes both the customer's unique device identifier, such as a serial number, along with an identifier corresponding to the requested software product. At step 612, the master key corresponding to the consumer's device is retrieved from secure master key data store 616.
A prefix value is created based upon the master key at step 620. In one embodiment, the prefix value is created by XORing a random number with the master key. In step 628, a hashing algorithm, such as SHA-256, is seeded with a value based on the prefix value and the master key. In one embodiment, the hashing algorithm is seeded with the random number used to create the prefix value. The hashing algorithm is seeded by storing the seed value (e.g., the random number) as the initial value of the hashing result (memory location 632).
At step 636, the requested software is located in software library 640. In the example shown, the requested software is software module 648. At step 652, the first block of software code is read from the requested software module 648. At step 656, the block of software code that was read is passed to a hashing algorithm, such as SHA-256. At step 660, the hashing algorithm receives the block of software code and the seed value stored in result 632. The result of the hashing algorithm is stored in result 632, overwriting the previous (seed) result value.
A determination is made as to whether the end of file has been reached on the software code (decision 664). If the end of file has not been reached, decision 664 branches to “no” branch 668 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of data along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on software code 648, whereupon decision 664 branches to “yes” branch 672.
At step 676, a suffix value is created based upon the master key corresponding to the device and the final result from the hashing algorithm. In one embodiment, the suffix value is created by XORing the final result from the hashing algorithm with the master key.
At step 684, software image 688 is created by packaging the prefix value, the software code (i.e., software module 648) and the suffix value into the software image file and sending the software image file to the customer. Distribution processing thereafter ends at 695.
FIG. 7 is a flowchart showing steps taken at the customer's device to load software authenticated using a master key. The loader is a process embedded within a protected semiconductor package within the device. The semiconductor package also includes one or more processors and the master key. In this manner, the loader is able to retrieve and use the master key without ever transmitting the master key across a system or memory bus outside of the protected semiconductor package.
Processing commences at 700 whereupon a load request is received for a particular software component (step 705). At step 710, master key 720 corresponding to the device is retrieved from locked nonvolatile memory area 715. In one embodiment, the locked nonvolatile memory area is a set of programmable fuses (e-fuses) that, after being successfully loaded with the master key during creation of the device, is locked by setting a lock bit that prevents the master key from being altered or removed.
At step 725, prefix value 735 for the software module being loaded is retrieved from software image 732 stored on nonvolatile storage device 730, such as a hard disk or nonvolatile memory, located outside of the protected semiconductor package. Software image 732 includes prefix value 735, software code 745, and suffix value 750.
In step 755, a hashing algorithm, such as SHA-256, is seeded with a value based on the prefix value and the master key. In one embodiment, the hashing algorithm is seeded with the random number used to create the prefix value. In one embodiment, the seed value is generated by XORing the master key and the prefix value. The hashing algorithm is seeded by storing the seed value (e.g., the random number) as the initial value of the hashing result (memory location 765).
At step 770, the first block of software code is read from the requested software module 745. At step 775, the block of software code that was read is passed to a hashing algorithm, such as SHA-256. At step 780, the hashing algorithm receives the block of software code and the seed value stored in result 765. The result of the hashing algorithm is stored in result 765, overwriting the previous (seed) result value.
A determination is made as to whether the end of file has been reached on the software code (decision 782). If the end of file has not been reached, decision 782 branches to “no” branch 784 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of data along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on software code 745, whereupon decision 782 branches to “yes” branch 786.
A determination is made as to whether to software has been altered or whether the master key for which the software was created is different from the master key included in the device (predefined process 790, see FIG. 8 and corresponding text for processing details). Loader processing thereafter ends at 795.
FIG. 8 is a flowchart showing steps taken to authenticate software based upon hash results. This routine is called from predefined process 790, shown in FIG. 7.
The loader's check hash results processing commences at 800 whereupon, at step 805, master key 815 is retrieved from nonvolatile memory area 810 that is included in the protected semiconductor package. At step 820, suffix value 840 for the software that is being loaded is retrieved. The suffix value is part of software image 828. Software image 828 is stored in a storage area, such as system memory, outside of the protected semiconductor package. The software image also includes prefix value 830 and software code 835.
An expected result value is computed based upon the retrieved suffix value and the master key (step 845). In one embodiment, the expected result is generated by XORing the master key with the suffix value. At step 855, the actual result from the hashing operation (result 860) is retrieved from a memory location located inside of the protected semiconductor package. The actual result was previously generated using the processing shown on FIG. 7.
A determination is made as to whether the expected result is equal to the actual result (decision 870). If the expected result and the actual result are equal, decision 870 branches to “yes” branch 875 whereupon the software code is executed by the processor at step 880. On the other hand, if the results are not the same, decision 870 branches to “no” branch 885 whereupon an error is returned at step 890 and the software code is not executed. When the expected result is not the same as the actual result, either the software code was altered or the software was created for a different device with a different master key than the device from which the load request was issued. The loader's check hash results processing thereafter returns to the calling routine at 895.
FIG. 9 is a system diagram showing a micro-loader used to load a software loader into a protected area of a processing unit. Computer system 900 includes unprotected storage 905, such as system memory, disk devices, and the like, and protected semiconductor package 955 that includes packaged semiconductor components that interconnect within the package without use of a bus. Unprotected storage 905 and protected semiconductor package 955 communicate with one another using one or more busses, 950.
Unprotected storage 905 stores software loader image 910 and application program image 930. Each of these software images include a prefix value (915 and 935, respectively), software code (920 and 940, respectively), and a suffix value (925 and 945, respectively).
Protected semiconductor package 955 includes one or more processors 960, and storage 965. Storage 965 includes a read-only memory (ROM) of micro-loader code 970. The micro-loader is a scaled-down loader that is written to authenticate and load software loader 910. Software loader is a more robust loader that is designed to load application programs, such as application 930. In addition, micro-loader 970 is stored in read-only memory and, therefore, cannot be changed or altered without replacing the protected semiconductor package. Software loader 910, on the other hand, is stored in alterable memory, such as a hard disk, and can therefore be updated if errors in the loader are found or when enhancements or other modifications to the loader are created.
Storage 965 also includes program storage 975 into which both software loader 910 and application program 930 are loaded, in storage areas 980 and 985, respectively, in order to be executed by the processors. Storage further includes a memory location for storing intermediate keys 990 that are generated by the micro-loader while loading the software loader. Finally, storage 965 includes a locked nonvolatile memory 992, such as programmable fuses (e-fuses). Nonvolatile memory 992 is inaccessible from outside the protected semiconductor package. Nonvolatile memory 992 is used to store master key 995 which is a unique, random, nontrivial value of a sufficient length (e.g., 256 bits). After the device is created and the master key is stored in the nonvolatile memory, the nonvolatile memory is locked, thereby preventing further operations from altering or removing the master key.
FIG. 10 is a flowchart showing hardware initialization with a micro-loader and master key written to a protected area of the processing core. Hardware initialization commences at 1000 whereupon, at step 1004, a random, unique, nontrivial master key value is generated of a sufficient length (i.e., 256 bits). The generated master key is stored in memory location 1008.
In step 1012, a prefix value is created based upon the generated master key and stored in memory location 1016. In one embodiment, the prefix value is created by XORing the generated master key with another random number. In step 1020, a hashing algorithm, such as SHA-256, is seeded using a value based upon the prefix value, such as the random number used to generate the prefix value. The seed value is used as an initial result 1024 of the hashing algorithm.
At step 1028, the first block of software loader code is read. The software loader code is the software loader that is loaded by the micro-loader. At step 1032, the block of software code that was read is passed to a hashing algorithm, such as SHA-256. At step 1036, the hashing algorithm receives the block of the software loader code and the seed value stored in result 1024. The result of the hashing algorithm is stored in result 1024, overwriting the previous (seed) result value.
A determination is made as to whether the end of file has been reached on the software loader code (decision 1040). If the end of file has not been reached, decision 1040 branches to “no” branch 1042 which loops back to read the next block of software loader code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of software loader code along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on the software loader, whereupon decision 1040 branches to “yes” branch 1044.
At step 1048, a suffix value is created based upon the master key and the final result resulting from the hashing algorithm and stored in memory location 1052. In one embodiment, the master key and final result are XORed to create the suffix value. At step 1056, the software loader image 1078 is created by packaging the loader code along with the prefix and suffix values and stored. Software loader image 1078 is stored on nonvolatile storage device 1076, such as a disk drive or nonvolatile memory, which is accessible from protected processing core 1064 and included in information handling system 1060. Protected processing core 1064 also includes micro-loader software, stored in ROM, that is programmed to use the master key to load and authenticate the loader code included in loader image 1078.
At step 1080, the generated master key is written to nonvolatile memory 1070 located within protected processing core 1064. Nonvolatile memory 1070 is also locked using lock key 1072. Locking the nonvolatile memory prevents any process from altering or removing the master key.
At step 1084, the unique identifier, such as a serial number, of the hardware being initialized is written to secure database 1088 along with the device's master key value and the version of the software loader (loader image 1078) that was stored on the device's nonvolatile storage device. Hardware initialization processing thereafter ends at 1095.
FIG. 11 are high level flowcharts showing steps taken to distribute devices and software utilizing a micro-loader stored in a protected processing area and a loader which is authenticated by the micro-loader. Provider processing, used to distribute devices and software, commences at 1100. The device is built with a unique master key included in a protected processor core area (predefined process 1110, see FIG. 12 and corresponding text for processing details) and the master key value and device identifier written to secure database 1115. At step 1120, the device (device 1125) is shipped to a customer.
Consumer processing commences at 1130 whereupon, at step 1135, the consumer receives the device that has a master key embedded in its protected processor core area. At step 1140, the consumer orders software for the device and transmits order 1145 to a producer of the software.
Returning to producer processing, the producer receives customer's order 1145 that includes the unique identifier, such as the device serial number. The producer retrieves the master key value corresponding to the device from database 1115 in order to create software image 1170 (predefined process 1150, see FIGS. 13 and 14 and corresponding text for processing details). Thereafter, producer processing ends at 1160.
Returning to consumer processing, the consumer receives the software image corresponding to the ordered software at step 1175. When the consumer uses the device to load the software, the software loader is loaded by the micro-loader (predefined process 1180, see FIGS. 15 and 16 and corresponding text for processing details). Once the software loader has been loaded and authenticated, the software loader loads and authenticates the software program (predefined process 1190, see FIGS. 15 and corresponding text for processing details). Consumer processing thereafter ends at 1195.
FIG. 12 is a flowchart showing steps taken to distribute the device with a micro-loader, loader, and authentication keys. The processing shown in FIG. 12 is called from predefined process 1110 shown in FIG. 11.
Device creation processing commences at 1200 whereupon, at step 1205, a unique, random, and nontrivial master key is generated and stored in memory location 1210. At step 1215, the master key is stored in a nonvolatile memory area located within protected area 1225 of the processor core within device 1220. After the master key is stored, the nonvolatile memory area in the protected area is locked so that the master key cannot be altered or removed.
At step 1240, micro-loader program 1235 is stored in ROM in the processor core. The micro-loader is unable to be read or altered from outside the protected area of the device. At step 1245, another random number is generated. A prefix value is calculated based upon the generated random number and the master key (step 1250). In one embodiment, the prefix is calculated by XORing the master key with the random number.
At step 1255, a hashing algorithm, such as SHA-256, is seeded with the random number generated in step 1245 and software loader 1260 is hashed using the hashing algorithm. A suffix value is then calculated, at step 1265, by combining the result of the hashing algorithm with the master key. In one embodiment, the master key and the result from the hashing algorithm are XORed to create the suffix value. At step 1270, loader image 1275 is created using the prefix value, the suffix value, and the loader code. The loader image is stored in an unprotected area, such as a disk drive or other nonvolatile memory location, within device 1220 in an area accessible by the protected processor core.
At step 1280, the device identifier (i.e., serial number) is stored along with the device's master key value, loader version, and prefix value in secure database 1285. Device creation processing thereafter returns at 1295.
FIG. 13 is a flowchart showing steps taken to distribute software that is adapted to be loaded by a device using a micro-loader and a loader. The processing shown in FIG. 13 is called from predefined process 1150 shown in FIG. 11.
Software distribution processing commences at 1300 whereupon the master key, loader version, and loader prefix value corresponding to the customer's device are retrieved (step 1305) from secure database 1310. At step 1315, a hashing algorithm, such as SHA-256, is seeded with a value based upon the loader prefix and the master key. In one embodiment, the seed value is created by XORing the master key with the loader prefix value. The hashing algorithm is seeded by storing the seed value (e.g., the random number resulting from the XOR operation) as the initial value of the hashing result (memory location 1320).
A secondary key count is retrieved at step 1325. The secondary key count indicates the number of iterations of the hashing algorithm that are performed after which the current result is used as a secondary key value. For example, if the secondary key count is “10”, then after the hashing algorithm iterates 10 times, whatever result is in result memory area 1320 is used as a secondary key by the software loader. At step 1330, a counter that is used to track the number of iterations is initialized to zero.
At step 1335, the first block of the loader code that is installed on the customer's device is read from memory area 1340. At step 1345, the counter is incremented to indicate that the hashing algorithm has been performed once and, at step 1350, the block of code is processed using the hashing algorithm. At step 1355, the hashing algorithm receives the block of software code and the seed value stored in result 1320. The result of the hashing algorithm is stored in result 1320, overwriting the previous (seed) result value.
A determination is made as to whether the counter is equal to the secondary key count constant (decision 1360). If the counter has not yet reached the secondary key count, decision 1360 branches to “no” branch 1365 whereupon processing loops back to process the next block of loader code and increment the counter. This looping continues until the counter is equal to the secondary key count, at which point decision 1360 branches to “yes” branch 1370.
At step 1375, the secondary key value is set to the current result resulting from a number of iterations of the hashing algorithm. The software application, such as an application program or game software, is then processed using the secondary key value (predefined process 1380, see FIG. 14 and corresponding text for processing details). Processing thereafter returns to the calling procedure at 1395.
FIG. 14 is a flowchart showing steps taken to prepare a software image with authentication information for delivery to a customer. The processing shown in FIG. 14 is called from predefined process 1380 shown in FIG. 13.
Processing to create an image of the requested software commences at 1400 whereupon a random number is generated at step 1410. A prefix value is determined based upon the random number and the secondary key value (step 1420, see FIG. 13 for a details on the creation of the secondary key value). In one embodiment, an exclusive or (XOR) operation is performed between the random value and the secondary key value to create the prefix value. In step 1425, a hashing algorithm, such as SHA-256, is seeded using a value based upon the prefix value, such as the random number used to generate the prefix value. The seed value is used as an initial result 1430 of the hashing algorithm.
At step 1435, the first block of software code 1438 requested by the user is read. At step 1440, the block of software code that was read is passed to a hashing algorithm, such as SHA-256. At step 1445, the hashing algorithm receives the block of the software code and the seed value stored in result 1430. The result of the hashing algorithm is stored in result 1430, overwriting the previous (seed) result value.
A determination is made as to whether the end of file has been reached on the software code (decision 1450). If the end of file has not been reached, decision 1450 branches to “no” branch 1455 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of software code along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on the software code, whereupon decision 1450 branches to “yes” branch 1460.
At step 1470, a suffix value is created based upon the secondary key and the final result resulting from the hashing algorithm. In one embodiment, the secondary key and final result are XORed to create the suffix value. At step 1475, software image 1480 is created by packaging the software code along with the prefix and suffix values. At step 1490, software image 1480 is sent to the customer, either on a nonvolatile medium, through the Internet, or in any other fashion. Processing thereafter returns to the calling routine at 1495.
FIG. 15 is a flowchart showing steps taken by a customer's device to load software using authentication by a micro-loader and loader. The processing shown in FIG. 15 is called from predefined processes 1180 and 1190 shown in FIG. 11.
The process of loading software on the customer's device commences at 1500 whereupon master key 1515, located in a locked, nonvolatile storage area within the device's operating core is used to authenticate and load software loader image 1520 and generate secondary key 1525 ((predefined process 1510, see FIG. 16 and corresponding text for processing details).
A determination is made as to whether the loader was authenticated by the micro-loader (decision 1530). If the loader was not authenticated, decision 1530 branches to “no” branch 1535 and processing ends at 1540. On the other hand, if the loader was authenticated by the micro-loader, decision 1530 branches to “yes” branch 1545 whereupon the software requested to be executed by the customer (image 1560) is authenticated and loaded using the loader software and the secondary key value (predefined process 1550, see FIG. 17 and corresponding text for processing details).
A determination is made as to whether the software was authenticated (decision 1570). If the software was not authenticated, decision 1570 branches to “no” branch 1574 whereupon the secondary key values are removed (cleaned up) from processor core storage memory (step 1590). On the other hand, if the software was authenticated, decision 1570 branches to “yes” branch 1578 whereupon the software code is executed by the processor at step 1580 and the secondary keys are removed (cleaned up) from processor core storage memory at step 1590. Processing thereafter returns to the calling routine at 1595.
FIG. 16 is a flowchart showing steps taken to authenticate and load the loader software generating a secondary key. The processing shown in FIG. 16 is called from predefined processes 1510 shown in FIG. 15.
Micro-loader processing used to authenticate and load the software loader commences at 1600 whereupon, in step 1605, master key 1615 for the device is retrieved by the micro-loader from locked nonvolatile memory and the prefix value corresponding to software loader image 1610 is retrieved from a non-protected area (e.g., system memory).
At step 1620, a hashing algorithm, such as SHA-256, is seeded with a value based upon the loader prefix and the master key. In one embodiment, the seed value is created by XORing the master key with the loader prefix value. The hashing algorithm is seeded by storing the seed value (e.g., the random number resulting from the XOR operation) as the initial value of the hashing result (memory location 1625).
A secondary key count is retrieved at step 1630. The secondary key count indicates the number of iterations of the hashing algorithm that are performed after which the current result is used as a secondary key value. For example, if the secondary key count is “10”, then after the hashing algorithm iterates 10 times, whatever result is in result memory area 1625 is used as a secondary key by the software loader. In one embodiment, the secondary key count is retrieved from the locked nonvolatile memory area that is used to store the master key. At step 1635, a counter that is used to track the number of iterations is initialized to zero.
At step 1640, the first block of the loader code that is installed on the customer's device is read from loader image 1610. At step 1645, the counter is incremented to indicate that the hashing algorithm has been performed once and, at step 1650, the block of code is processed using the hashing algorithm. At step 1655, the hashing algorithm receives the block of software code and the seed value stored in result 1625. The result of the hashing algorithm is stored in result 1625, overwriting the previous (seed) result value.
A determination is made as to whether the counter is equal to the secondary key count constant (decision 1660).
If the counter has not yet reached the secondary key count, decision 1660 branches to “no” branch 1662 whereupon processing loops back to process the next block of loader code and increment the counter. This looping continues until the counter is equal to the secondary key count, at which point decision 1660 branches to “yes” branch 1668 whereupon, at step 1669, the secondary key value is set to the current result resulting from a number of iterations of the hashing algorithm.
A determination is made as to whether the end of the software loader file has been reached (decision 1670). If the end of the file has not been reached, decision 1670 branches to “no” branch 1672 whereupon processing loops back to process the next block of code from the software loader using the hashing algorithm. This looping continues until the end of file has been reached, at which point decision 1670 branches to “yes” branch 1674.
At step 1675, the expected result is determined based upon the suffix value and the master key. In one embodiment, the expected result is calculated by XORing the master key with the suffix value. A determination is made as to whether the result resulting from the hashing algorithm is equal to the expected result (decision 1680). If the result from the hashing algorithm is equal to the expected result, decision 1680 branches to “yes” branch 1685 whereupon the software loader is executed at step 1690. On the other hand, if the result resulting from the hashing algorithm is not equal to the expected result (indicating that either the loading program was altered or that the loading program found on the device is a different loading program than the one originally shipped with the device), then decision 1680 branches to “no” branch 1692 bypassing the execution of the software loading program. Processing thereafter returns to the calling routine at 1695.
FIG. 17 is a flowchart showing steps taken to authenticate and load the software using a secondary key. The processing shown in FIG. 17 is called from predefined processes 1550 shown in FIG. 15 after the secondary key has been determined using the processing shown in FIG. 16.
In FIG. 17, processing used to authenticate and load software using a secondary key value commences at 1700. At step 1710, the secondary key value (determined using the processing shown on FIG. 16 and stored in a memory area within the protected processing core) is retrieved along with the prefix value for software image 1725.
In step 1725, a hashing algorithm, such as SHA-256, is seeded using a value based upon the prefix value, such as a random number that was used to generate the prefix value. The seed value is used as initial result 1740 of the hashing algorithm. In one embodiment, an exclusive or (XOR) operation is performed between secondary key 1720 and the prefix value resulting in the random number that was originally used in creating the prefix value. This random number is used to seed the hashing algorithm.
At step 1750, the first block of the software code included in software image 1725 is read. At step 1755, the block of software code that was read is passed to a hashing algorithm, such as SHA-256. At step 1760, the hashing algorithm receives the block of the software code and the seed value stored in result 1740. The result of the hashing algorithm is stored in result 1740, overwriting the previous (seed) result value.
A determination is made as to whether the end of file has been reached on the software code (decision 1765). If the end of file has not been reached, decision 1765 branches to “no” branch 1768 which loops back to read the next block of software code and process the next block using the hashing algorithm. This time, the hashing algorithm uses the read block of software code along with the result from the prior hashing operation to hash the block of code. This looping continues until the end of file is reached on the software code, whereupon decision 1765 branches to “yes” branch 1770.
At step 1775, an expected result value is created using the suffix value from software image 1725 and secondary key value 1720. In one embodiment, these two values are XORed to generate the expected result. A determination is made as to whether the result resulting from the hashing algorithm is equal to the expected result (decision 1780). If the result from the hashing algorithm is equal to the expected result, decision 1780 branches to “yes” branch 1785 whereupon the software program is executed at step 1790. On the other hand, if the result resulting from the hashing algorithm is not equal to the expected result (indicating that either the software program was altered or that the software program found on the device was created for a different device using a different set of keys), then decision 1780 branches to “no” branch 1792 bypassing the execution of the software program. Processing thereafter returns to the calling routine at 1795.
One of the preferred implementations of the invention is a client application, namely, a set of instructions (program code) in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.
The use of the words “prefix” and “suffix” to describe authentication values used herein does not imply that such values need to be located in any particular area relative to the corresponding software code. Rather, such terms are used to describe when the values are used in conjunction with the authentication process. The prefix value is used to determine a seed value for the authentication process, while the suffix value is used to generate an expected result that is in turn compared with a result from the hashing algorithm. The actual prefix and suffix values can be stored either along with their respective software modules, or can be stored separately in a location distinct and apart from the software module.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.

Claims (33)

1. A computer implemented method for authenticating software, said method comprising:
authenticating a first computer file stored on a nonvolatile storage area accessible by a computer system, the authenticating of the first computer file performed by hashing the first software program using a master key value that is located in a nonvolatile memory of the computer system inaccessible to a user;
generating one or more intermediate key values during the hashing of the first software program;
storing the intermediate key values in a memory of the computer system inaccessible to the user; and
authenticating a second computer file stored on the nonvolatile storage area, the authenticating of the second computer file performed by hashing the second computer file using one or more of the intermediate key values.
2. The method of claim 1 wherein the first computer file is a loader software module, the authentication of the loader software module further comprising:
reading a prefix value and a suffix value from the nonvolatile storage area, the prefix and suffix values corresponding to the loader software module;
generating a seed value using the loader's prefix value and the master key value;
seeding the hashing algorithm used to authenticate the loader software module with the seed value;
generating an expected hash value using the loader's suffix value and the master key value;
retrieving a hash result resulting from the hashing of the loader software module; and
comparing the expected hash value with the hash result.
3. The method of claim 2 wherein the generation of the seed value is performed by calculating an exclusive OR value between the master key value and the prefix value.
4. The method of claim 2 wherein the authentication of the loader software module is performed by a micro-loader module.
5. The method of claim 4 wherein the micro-loader is stored on a read-only memory, and wherein the computer system's processor, the read only memory, the nonvolatile memory, and the memory are all packaged within a common semiconductor package.
6. The method of claim 5 wherein the loader software module, the suffix value, and the prefix value are each located on the nonvolatile storage area, wherein the nonvolatile storage area is outside of the common semiconductor package.
7. The method of claim 1 wherein the nonvolatile memory is a locked nonvolatile storage area included in a semiconductor package, the semiconductor package also including one or more processors.
8. The method of claim 1 further comprising:
erasing the intermediate key values following the authentication of the second computer file.
9. The method of claim 1 wherein the first computer file is a loader software module and the second computer file is a software program, the authentication of the software program further comprising:
reading a prefix value and a suffix value from the nonvolatile storage area, the prefix and suffix values corresponding to the software program;
generating a seed value using the software program's prefix value and one of the intermediate key values;
seeding the hashing algorithm used to authenticate the software program with the seed value;
generating an expected hash value using the software program's suffix value and the intermediate key value;
retrieving a hash result resulting from the hashing of the software program; and
comparing the expected hash value with the hash result.
10. The method of claim 9 wherein the authentication of the software program is performed by the software loader module after the software loader module has been authenticated and loaded.
11. The method of claim 9 wherein the generation of the seed value is performed by calculating an exclusive OR value between one of the intermediate key values and the software program's prefix value.
12. The method of claim 9 wherein a micro-loader is stored on a read-only memory, and wherein the computer system's processor, the read only memory, the nonvolatile memory, and the memory are all packaged within a common semiconductor package, the method further comprising:
invoking the micro-loader to authenticate the loader software module using the master key value, a loader prefix value, and a loader suffix value;
loading and invoking the loader software module in response to the loader software module being authenticated by the micro-loader, wherein the software program is authenticated by the loader software module using the software module's prefix and suffix values in combination with at least one of the intermediate key values; and
loading and executing the software program in response to the software program being authenticated by the loader software module.
13. An information handling system comprising:
a semiconductor package that includes one or more processors, a memory area, and a locked nonvolatile memory, wherein the locked nonvolatile memory includes a master key value and wherein the locked nonvolatile memory is inaccessible from outside the semiconductor package;
a system memory interconnected to the processors with a bus;
a software loader image comprising a loader prefix value, a software loader routine, and a loader suffix value, wherein the software loader routine is adapted to authenticate and load computer data files, wherein the software loader image is located outside of the semiconductor package; and
a micro-loader routine located within the semiconductor package which is also inaccessible from outside the semiconductor package, wherein the micro-loader is adapted to authenticate and load the software loader routine from the system memory by using the master key value and the software loader's prefix and suffix values and generate one or more intermediate key values that are stored in the semiconductor package's memory area.
14. The information handling system of claim 13 further comprising the system, wherein the micro-loader is enabled to:
read the prefix value and a suffix value from a nonvolatile storage area;
generate a seed value using the software loader's prefix value and the master key value;
seed a hashing algorithm used to authenticate the loader software module with the seed value;
generate an expected hash value using the loader's suffix value and the master key value;
retrieve a hash result resulting from the hashing of the loader software module; and
compare the expected hash value with the hash result.
15. The information handling system of claim 14 wherein, in order to generate the seed value, the micro-loader is further enabled to calculate an exclusive OR value between the master key value and the prefix value.
16. The information handling system of claim 13 wherein the locked nonvolatile memory is an array of programmable fuses.
17. The information handling system of claim 13 wherein the software loader routine is enabled to:
read a prefix value and a suffix value from the system memory, the prefix and suffix values corresponding to one of the computer data files;
generate a seed value using the software program's prefix value and one of the intermediate key values;
seed a hashing algorithm used to authenticate the computer data file with the seed value;
generate an expected hash value using the computer data file's suffix value and the intermediate key value;
retrieve a hash result resulting from the hashing of the computer data file; and
compare the expected hash value with the hash result.
18. The information handling system of claim 17 wherein the authentication of the computer data file is performed by the software loader routine after the software loader routine has been authenticated and loaded by the micro-loader.
19. The information handling system of claim 17 wherein, in order to generate the seed value, the software loader routine is enabled to calculate an exclusive OR value between one of the intermediate key values and the computer data file's prefix value.
20. The information handling system of claim 17 wherein, in order to authenticate and load one of the computer data files, the micro-loader is invoked and enabled to:
authenticate the software loader routine using the master key value, the loader prefix value, and the loader suffix value;
create and store the intermediate key values generated during the authentication of the software loader routine;
invoke the software loader routine in response to the software loader routine being authenticated by the micro-loader, wherein the software loader routine, upon being invoked, is enabled to:
authenticate the computer data file using the computer data file's prefix and suffix values in combination with at least one of the intermediate key values; and
load the computer data file in response to the computer data file being authenticated by the loader software module.
21. The information handling system of claim 20 wherein the computer data file is a software program and the software loader routine is further enabled to execute the software program after the software program is loaded.
22. A computer program product stored in a computer operable media for authenticating software, said computer program product comprising:
means for authenticating a first computer file stored on a nonvolatile storage area accessible by a computer system, the authentication of the first computer file performed by a means for hashing the first software program using a master key value that is located in a nonvolatile memory of the computer system inaccessible to a user;
means for generating one or more intermediate key values during the hashing of the first software program;
means for storing the intermediate key values in a memory of the computer system inaccessible to the user; and
means for authenticating a second computer file stored on the nonvolatile storage area, the authentication of the second computer file performed by a means for hashing the second computer file using one or more of the intermediate key values.
23. The computer program product of claim 22 wherein the first computer file is a loader software module, the authentication of the loader software module further comprising:
means for reading a prefix value and a suffix value from the nonvolatile storage area, the prefix and suffix values corresponding to the loader software module;
means for generating a seed value using the loader's prefix value and the master key value;
means for seeding the hashing algorithm used to authenticate the loader software module with the seed value;
means for generating an expected hash value using the loader's suffix value and the master key value;
means for retrieving a hash result resulting from the hashing of the loader software module; and
means for comparing the expected hash value with the hash result.
24. The computer program product of claim 23 wherein the generation of the seed value is performed by a means for calculating an exclusive OR value between the master key value and the prefix value.
25. The computer program product of claim 23 wherein the authentication of the loader software module is performed by a micro-loader module.
26. The computer program product of claim 25 wherein the micro-loader is stored on a read-only memory, and wherein the computer system's processor, the read only memory, the nonvolatile memory, and the memory are all packaged within a common semiconductor package.
27. The computer program product of claim 26 wherein the loader software module, the suffix value, and the prefix value are each located on the nonvolatile storage area, wherein the nonvolatile storage area is outside of the common semiconductor package.
28. The computer program product of claim 22 wherein the nonvolatile memory is a locked nonvolatile storage area included in a semiconductor package, the semiconductor package also including one or more processors.
29. The computer program product of claim 22 further comprising:
means for erasing the intermediate key values following the authentication of the second computer file.
30. The computer program product of claim 22 wherein the first computer file is a loader software module and the second computer file is a software program, the authentication of the software program further comprising:
means for reading a prefix value and a suffix value from the nonvolatile storage area, the prefix and suffix values corresponding to the software program;
means for generating a seed value using the software program's prefix value and one of the intermediate key values;
means for seeding the hashing algorithm used to authenticate the software program with the seed value;
means for generating an expected hash value using the software program's suffix value and the intermediate key value;
means for retrieving a hash result resulting from the hashing of the software program; and
means for comparing the expected hash value with the hash result.
31. The computer program product of claim 30 wherein the authentication of the software program is performed by the software loader module after the software loader module has been authenticated and loaded.
32. The computer program product of claim 30 wherein the generation of the seed value is performed by a means for calculating an exclusive OR value between one of the intermediate key values and the software program's prefix value.
33. The computer program product of claim 30 wherein a micro-loader is stored on a read-only memory, and wherein the computer system's processor, the read only memory, the nonvolatile memory, and the memory are all packaged within a common semiconductor package, the computer program product further comprising:
means for invoking the micro-loader to authenticate the loader software module using the master key value, a loader prefix value, and a loader suffix value;
means for loading and invoking the loader software module in response to the loader software module being authenticated by the micro-loader, wherein the software program is authenticated by the loader software module using the software module's prefix and suffix values in combination with at least one of the intermediate key values; and
means for loading and executing the software program in response to the software program being authenticated by the loader software module.
US10/464,884 2003-06-19 2003-06-19 System and method for authenticating software using hidden intermediate keys Expired - Fee Related US6961852B2 (en)

Priority Applications (10)

Application Number Priority Date Filing Date Title
US10/464,884 US6961852B2 (en) 2003-06-19 2003-06-19 System and method for authenticating software using hidden intermediate keys
CNB2003801094646A CN100424678C (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
PCT/US2003/039809 WO2005006109A2 (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
EP03817468A EP1636715A4 (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
KR1020097005256A KR100974161B1 (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
AU2003300926A AU2003300926A1 (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
KR1020057022399A KR100896625B1 (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
CA2525376A CA2525376C (en) 2003-06-19 2003-12-15 System and method for authenticating software using hidden intermediate keys
TW093115949A TWI315627B (en) 2003-06-19 2004-06-03 System and method for authenticating software using hidden intermediate keys
IL172519A IL172519A0 (en) 2003-06-19 2005-12-12 System and method for authenticating software using hidden intermediate keys

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/464,884 US6961852B2 (en) 2003-06-19 2003-06-19 System and method for authenticating software using hidden intermediate keys

Publications (2)

Publication Number Publication Date
US20050010767A1 US20050010767A1 (en) 2005-01-13
US6961852B2 true US6961852B2 (en) 2005-11-01

Family

ID=33563711

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/464,884 Expired - Fee Related US6961852B2 (en) 2003-06-19 2003-06-19 System and method for authenticating software using hidden intermediate keys

Country Status (9)

Country Link
US (1) US6961852B2 (en)
EP (1) EP1636715A4 (en)
KR (2) KR100896625B1 (en)
CN (1) CN100424678C (en)
AU (1) AU2003300926A1 (en)
CA (1) CA2525376C (en)
IL (1) IL172519A0 (en)
TW (1) TWI315627B (en)
WO (1) WO2005006109A2 (en)

Cited By (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093660A1 (en) * 2001-10-17 2003-05-15 Safa John Aram Software Loading
US20050010788A1 (en) * 2003-06-19 2005-01-13 International Business Machines Corporation System and method for authenticating software using protected master key
US20050198051A1 (en) * 2004-03-05 2005-09-08 Microsoft Corporation Portion-level in-memory module authentication
US20060026569A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Portion-level in-memory module authentication
US20060064593A1 (en) * 2004-09-21 2006-03-23 Dobranski Lawrence G Technique for preventing illegal invocation of software programs
US20060143454A1 (en) * 2004-05-27 2006-06-29 Silverbrook Research Pty Ltd Storage of multiple keys in memory
US20060161761A1 (en) * 2005-01-18 2006-07-20 Microsoft Corporation Systems and methods for validating executable file integrity using partial image hashes
US20060259579A1 (en) * 2005-05-11 2006-11-16 Bigfoot Networks, Inc. Distributed processing system and method
US20070005957A1 (en) * 2005-06-30 2007-01-04 Ravi Sahita Agent presence monitor configured to execute in a secure environment
US20070005992A1 (en) * 2005-06-30 2007-01-04 Travis Schluessler Signed manifest for run-time verification of software program identity and integrity
US20070016743A1 (en) * 2005-07-14 2007-01-18 Ironkey, Inc. Secure storage device with offline code entry
US20070044158A1 (en) * 2005-04-20 2007-02-22 Honeywell International Inc. Hardware key control of debug interface
US20070060373A1 (en) * 2005-09-12 2007-03-15 Bigfoot Networks, Inc. Data communication system and methods
US20070067620A1 (en) * 2005-09-06 2007-03-22 Ironkey, Inc. Systems and methods for third-party authentication
US20070078929A1 (en) * 2005-09-30 2007-04-05 Bigfoot Networks, Inc. Distributed processing system and method
US20070101434A1 (en) * 2005-07-14 2007-05-03 Ironkey, Inc. Recovery of encrypted data from a secure storage device
US20070162733A1 (en) * 2006-01-06 2007-07-12 Dell Products L.P. Secure CMOS
US20070179904A1 (en) * 2006-02-02 2007-08-02 Hofstee H P Apparatus and method for providing sealed storage in a data processing device
US20070211291A1 (en) * 2004-05-27 2007-09-13 Silverbrook Research Pty Ltd Method Of Storing Bit-Pattern In Plural Printer Cartridges
US20070211292A1 (en) * 2004-05-27 2007-09-13 Silverbrook Research Pty Ltd Method Of Storing Code Segements In Plural Printer Cartridges
US20070300031A1 (en) * 2006-06-22 2007-12-27 Ironkey, Inc. Memory data shredder
US20070300052A1 (en) * 2005-07-14 2007-12-27 Jevans David A Recovery of Data Access for a Locked Secure Storage Device
US20080016166A1 (en) * 2006-07-17 2008-01-17 Bigfoot Networks, Inc. Host posing network device and method thereof
US20080016236A1 (en) * 2006-07-17 2008-01-17 Bigfoot Networks, Inc. Data buffering and notification system and methods thereof
US20080082722A1 (en) * 2006-09-29 2008-04-03 Uday Savagaonkar Monitoring a target agent execution pattern on a VT-enabled system
US20080082772A1 (en) * 2006-09-29 2008-04-03 Uday Savagaonkar Tamper protection of software agents operating in a VT environment methods and apparatuses
US20080165959A1 (en) * 2006-02-16 2008-07-10 Samsung Electronics Co. Ltd. Encrypted data players and encrypted data player systems
US20080183861A1 (en) * 2007-01-26 2008-07-31 Bigfoot Networks, Inc. Communication Socket State Monitoring System and Methods Thereof
US20080189549A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Secure serial number
US20080235713A1 (en) * 2007-03-23 2008-09-25 Bigfoot Networks, Inc. Distributed Processing System and Method
US20080239954A1 (en) * 2007-03-26 2008-10-02 Bigfoot Networks, Inc. Method and system for communication between nodes
US20080289038A1 (en) * 2007-05-14 2008-11-20 Samsung Electronics Co., Ltd. Method and apparatus for checking integrity of firmware
US20090024872A1 (en) * 2007-07-20 2009-01-22 Bigfoot Networks, Inc. Remote access diagnostic device and methods thereof
US20090025073A1 (en) * 2007-07-20 2009-01-22 Bigfoot Networks, Inc. Client authentication device and methods thereof
US20090038017A1 (en) * 2007-08-02 2009-02-05 David Durham Secure vault service for software components within an execution environment
US20090125885A1 (en) * 2007-11-13 2009-05-14 Nagabhushan Gayathri Method and system for whitelisting software components
US20090141713A1 (en) * 2007-11-29 2009-06-04 Bigfoot Networks, Inc. Remote Message Routing Device and Methods Thereof
US20090210719A1 (en) * 2008-02-19 2009-08-20 Konica Minolta Holdings, Inc. Communication control method of determining whether communication is permitted/not permitted, and computer-readable recording medium recording communication control program
US20090276623A1 (en) * 2005-07-14 2009-11-05 David Jevans Enterprise Device Recovery
US20100011216A1 (en) * 2008-07-11 2010-01-14 Rosemount Inc. Method of providing secure tamper-proof acquired data from process instruments
US20100169666A1 (en) * 2008-12-31 2010-07-01 Prashant Dewan Methods and systems to direclty render an image and correlate corresponding user input in a secuire memory domain
US20110035513A1 (en) * 2009-08-06 2011-02-10 David Jevans Peripheral Device Data Integrity
US20110117984A1 (en) * 2008-06-27 2011-05-19 Shimabukuro Jorge L Authenticating components in wagering game systems
US8015606B1 (en) 2005-07-14 2011-09-06 Ironkey, Inc. Storage device with website trust indication
US8266378B1 (en) 2005-12-22 2012-09-11 Imation Corp. Storage device with accessible partitions
US8639873B1 (en) 2005-12-22 2014-01-28 Imation Corp. Detachable storage device with RAM cache
US8745365B2 (en) 2009-08-06 2014-06-03 Imation Corp. Method and system for secure booting a computer by booting a first operating system from a secure peripheral device and launching a second operating system stored a secure area in the secure peripheral device on the first operating system
WO2021257473A1 (en) * 2020-06-18 2021-12-23 Micron Technology, Inc. Authenticating software images
US20230027329A1 (en) * 2020-02-13 2023-01-26 Intel Corporation Cryptographic computing in multitenant environments

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7591021B2 (en) * 2003-09-05 2009-09-15 Microsoft Corporation Object model document for obfuscating object model therein
US7490245B2 (en) * 2004-07-24 2009-02-10 Lenovo (Singapore) Pte. Ltd. System and method for data processing system planar authentication
US20060020810A1 (en) * 2004-07-24 2006-01-26 International Business Machines Corporation System and method for software load authentication
JP2006050504A (en) * 2004-08-09 2006-02-16 Canon Inc Image processing device and method thereof
US7814330B2 (en) * 2005-08-01 2010-10-12 Oracle International Corporation Method and apparatus for facilitating multi-level computer system authentication
US7389426B2 (en) 2005-11-29 2008-06-17 Research In Motion Limited Mobile software terminal identifier
US8370928B1 (en) * 2006-01-26 2013-02-05 Mcafee, Inc. System, method and computer program product for behavioral partitioning of a network to detect undesirable nodes
US20080107275A1 (en) * 2006-11-08 2008-05-08 Mehdi Asnaashari Method and system for encryption of information stored in an external nonvolatile memory
US20080222733A1 (en) * 2007-03-08 2008-09-11 Ddtic Corporation, Ltd. Anti-pirate memory card
JP2009130882A (en) * 2007-11-28 2009-06-11 Oki Electric Ind Co Ltd Check value confirming method and apparatus
US8719585B2 (en) * 2008-02-11 2014-05-06 Nvidia Corporation Secure update of boot image without knowledge of secure key
WO2010098745A1 (en) * 2009-02-24 2010-09-02 Beyond Broadband Technology, Llc Cable television secure communication system for one way restricted access
US8577809B2 (en) * 2011-06-30 2013-11-05 Qualcomm Incorporated Method and apparatus for determining and utilizing value of digital assets
CN102663325A (en) * 2012-03-12 2012-09-12 苏州阔地网络科技有限公司 A method and system for binding of software and hardware
CN103237005A (en) * 2013-03-15 2013-08-07 福建联迪商用设备有限公司 Method and system for key management
CN103220271A (en) * 2013-03-15 2013-07-24 福建联迪商用设备有限公司 Downloading method, management method, downloading management method, downloading management device and downloading management system for secret key
US9424443B2 (en) 2013-08-20 2016-08-23 Janus Technologies, Inc. Method and apparatus for securing computer mass storage data
US9992171B2 (en) * 2014-11-03 2018-06-05 Sony Corporation Method and system for digital rights management of encrypted digital content
EP3040896A1 (en) * 2014-12-30 2016-07-06 Gemalto Sa Secure element
US9697359B2 (en) * 2015-04-15 2017-07-04 Qualcomm Incorporated Secure software authentication and verification
KR102538096B1 (en) * 2016-09-13 2023-05-31 삼성전자주식회사 Device and method of verify application
EP3509003B1 (en) * 2018-01-04 2021-04-21 Shenzhen Goodix Technology Co., Ltd. Method and apparatus to protect code processed by an embedded micro-processor against altering
KR102190727B1 (en) * 2018-12-27 2020-12-14 아주대학교산학협력단 Apparatus and method for detecting vulnerability of software
JP7253470B2 (en) * 2019-07-31 2023-04-06 株式会社デンソーテン Information processing equipment
US11782610B2 (en) * 2020-01-30 2023-10-10 Seagate Technology Llc Write and compare only data storage
TWI781544B (en) * 2020-03-31 2022-10-21 台灣積體電路製造股份有限公司 Integrated circuit device and method and system of generating a security key for an integrated circuit device
US11528135B2 (en) 2020-03-31 2022-12-13 Taiwan Semiconductor Manufacturing Company, Ltd. Integrated circuit (IC) signatures with random number generator and one-time programmable device
US11962693B2 (en) 2020-03-31 2024-04-16 Taiwan Semiconductor Manufacturing Company, Ltd. Integrated circuit (IC) signatures with random number generator and one-time programmable device
CN114553399B (en) * 2020-11-18 2022-10-11 澜起电子科技(上海)有限公司 Method and device for deriving chip built-in key

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2601795B1 (en) * 1986-07-17 1988-10-07 Bull Cp8 METHOD FOR DIVERSIFYING A BASE KEY AND FOR AUTHENTICATING A KEY THUS DIVERSIFIED AS HAVING BEEN PREPARED FROM A PREDETERMINED BASE KEY, AND SYSTEM FOR IMPLEMENTING IT
US5535276A (en) 1994-11-09 1996-07-09 Bell Atlantic Network Services, Inc. Yaksha, an improved system and method for securing communications using split private key asymmetric cryptography
WO1998007253A1 (en) * 1996-08-16 1998-02-19 Bell Communications Research, Inc. Accelerating public-key cryptography by precomputing randomly generated pairs
EP0881559B1 (en) * 1997-05-28 2003-08-20 Siemens Aktiengesellschaft Computer system for protecting software and a method for protecting software
US6760441B1 (en) 2000-03-31 2004-07-06 Intel Corporation Generating a key hieararchy for use in an isolated execution environment
CN1147793C (en) * 2001-05-30 2004-04-28 深圳市朗科科技有限公司 Semiconductor memory device
US6925557B2 (en) 2001-10-26 2005-08-02 International Business Machines Corporation Method and system for a clean system booting process

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Flip-chip interconnection technology for advanced thermal conduction modules Ray, S.K.; Beckham, K.; Master, R.; Electronic Components and Technology Conference, 1991. Proceedings., 41st May 11-16, 1991 Page(s): 772-778. *
Reducing radio energy consumption of key management protocols for wireless sensor networks Lai, B.-C.C.; Hwang, D.D.; Kim, S.P.; Verbauwhede, I.;Low Power Electronics and Design, 2004. ISLPED '04. Proceedings of the 2004 International Symposium on. *
The scalability of an object descriptor architecture OODBMS Yu, K.K.; Lee, B.S.; Olson, M.R.; Database Engineering and Applications, 1999, IDEAS '99. International Symposium Proceedings Aug. 2-4, 1999 Page(s): 370-377. *

Cited By (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7293266B2 (en) * 2001-10-17 2007-11-06 Simplex Major Sdn.Bhd Plurality of loader modules with a CO- ordinator module where selected loader module executes and each loader module execute
US20030093660A1 (en) * 2001-10-17 2003-05-15 Safa John Aram Software Loading
US20050010788A1 (en) * 2003-06-19 2005-01-13 International Business Machines Corporation System and method for authenticating software using protected master key
US20050198051A1 (en) * 2004-03-05 2005-09-08 Microsoft Corporation Portion-level in-memory module authentication
US7831838B2 (en) 2004-03-05 2010-11-09 Microsoft Corporation Portion-level in-memory module authentication
US20060143454A1 (en) * 2004-05-27 2006-06-29 Silverbrook Research Pty Ltd Storage of multiple keys in memory
US20070211291A1 (en) * 2004-05-27 2007-09-13 Silverbrook Research Pty Ltd Method Of Storing Bit-Pattern In Plural Printer Cartridges
US20070211292A1 (en) * 2004-05-27 2007-09-13 Silverbrook Research Pty Ltd Method Of Storing Code Segements In Plural Printer Cartridges
US20060026569A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Portion-level in-memory module authentication
US7644287B2 (en) * 2004-07-29 2010-01-05 Microsoft Corporation Portion-level in-memory module authentication
US20060064593A1 (en) * 2004-09-21 2006-03-23 Dobranski Lawrence G Technique for preventing illegal invocation of software programs
US7779269B2 (en) * 2004-09-21 2010-08-17 Ciena Corporation Technique for preventing illegal invocation of software programs
US20060161761A1 (en) * 2005-01-18 2006-07-20 Microsoft Corporation Systems and methods for validating executable file integrity using partial image hashes
US7577848B2 (en) * 2005-01-18 2009-08-18 Microsoft Corporation Systems and methods for validating executable file integrity using partial image hashes
US20070044158A1 (en) * 2005-04-20 2007-02-22 Honeywell International Inc. Hardware key control of debug interface
US7509250B2 (en) * 2005-04-20 2009-03-24 Honeywell International Inc. Hardware key control of debug interface
US20060259579A1 (en) * 2005-05-11 2006-11-16 Bigfoot Networks, Inc. Distributed processing system and method
US8167722B2 (en) 2005-05-11 2012-05-01 Qualcomm Atheros, Inc Distributed processing system and method
US9426207B2 (en) 2005-05-11 2016-08-23 Qualcomm Incorporated Distributed processing system and method
US20110231668A1 (en) * 2005-06-30 2011-09-22 Travis Schluessler Signed Manifest for Run-Time Verification of Software Program Identity and Integrity
US7669242B2 (en) 2005-06-30 2010-02-23 Intel Corporation Agent presence monitor configured to execute in a secure environment
US7953980B2 (en) * 2005-06-30 2011-05-31 Intel Corporation Signed manifest for run-time verification of software program identity and integrity
US20070005992A1 (en) * 2005-06-30 2007-01-04 Travis Schluessler Signed manifest for run-time verification of software program identity and integrity
US20070005957A1 (en) * 2005-06-30 2007-01-04 Ravi Sahita Agent presence monitor configured to execute in a secure environment
US9547772B2 (en) 2005-06-30 2017-01-17 Intel Corporation Secure vault service for software components within an execution environment
US9361471B2 (en) 2005-06-30 2016-06-07 Intel Corporation Secure vault service for software components within an execution environment
US8499151B2 (en) 2005-06-30 2013-07-30 Intel Corporation Secure platform voucher service for software components within an execution environment
US8601273B2 (en) 2005-06-30 2013-12-03 Intel Corporation Signed manifest for run-time verification of software program identity and integrity
US8335920B2 (en) 2005-07-14 2012-12-18 Imation Corp. Recovery of data access for a locked secure storage device
US8321953B2 (en) 2005-07-14 2012-11-27 Imation Corp. Secure storage device with offline code entry
US20070016743A1 (en) * 2005-07-14 2007-01-18 Ironkey, Inc. Secure storage device with offline code entry
US8015606B1 (en) 2005-07-14 2011-09-06 Ironkey, Inc. Storage device with website trust indication
US8505075B2 (en) 2005-07-14 2013-08-06 Marble Security, Inc. Enterprise device recovery
US20070101434A1 (en) * 2005-07-14 2007-05-03 Ironkey, Inc. Recovery of encrypted data from a secure storage device
US8438647B2 (en) 2005-07-14 2013-05-07 Imation Corp. Recovery of encrypted data from a secure storage device
US20090276623A1 (en) * 2005-07-14 2009-11-05 David Jevans Enterprise Device Recovery
US8381294B2 (en) 2005-07-14 2013-02-19 Imation Corp. Storage device with website trust indication
US20070300052A1 (en) * 2005-07-14 2007-12-27 Jevans David A Recovery of Data Access for a Locked Secure Storage Device
US20070067620A1 (en) * 2005-09-06 2007-03-22 Ironkey, Inc. Systems and methods for third-party authentication
US20070060373A1 (en) * 2005-09-12 2007-03-15 Bigfoot Networks, Inc. Data communication system and methods
US9455844B2 (en) 2005-09-30 2016-09-27 Qualcomm Incorporated Distributed processing system and method
US20070078929A1 (en) * 2005-09-30 2007-04-05 Bigfoot Networks, Inc. Distributed processing system and method
US8639873B1 (en) 2005-12-22 2014-01-28 Imation Corp. Detachable storage device with RAM cache
US8266378B1 (en) 2005-12-22 2012-09-11 Imation Corp. Storage device with accessible partitions
US8543764B2 (en) 2005-12-22 2013-09-24 Imation Corp. Storage device with accessible partitions
US20070162733A1 (en) * 2006-01-06 2007-07-12 Dell Products L.P. Secure CMOS
US20070179904A1 (en) * 2006-02-02 2007-08-02 Hofstee H P Apparatus and method for providing sealed storage in a data processing device
US8438658B2 (en) * 2006-02-02 2013-05-07 International Business Machines Corporation Providing sealed storage in a data processing device
US20080165959A1 (en) * 2006-02-16 2008-07-10 Samsung Electronics Co. Ltd. Encrypted data players and encrypted data player systems
US20070300031A1 (en) * 2006-06-22 2007-12-27 Ironkey, Inc. Memory data shredder
US20080016236A1 (en) * 2006-07-17 2008-01-17 Bigfoot Networks, Inc. Data buffering and notification system and methods thereof
US8874780B2 (en) 2006-07-17 2014-10-28 Qualcomm Incorporated Data buffering and notification system and methods thereof
US20080016166A1 (en) * 2006-07-17 2008-01-17 Bigfoot Networks, Inc. Host posing network device and method thereof
US8683045B2 (en) 2006-07-17 2014-03-25 Qualcomm Incorporated Intermediate network device for host-client communication
US20080082722A1 (en) * 2006-09-29 2008-04-03 Uday Savagaonkar Monitoring a target agent execution pattern on a VT-enabled system
US7802050B2 (en) 2006-09-29 2010-09-21 Intel Corporation Monitoring a target agent execution pattern on a VT-enabled system
US20080082772A1 (en) * 2006-09-29 2008-04-03 Uday Savagaonkar Tamper protection of software agents operating in a VT environment methods and apparatuses
US7882318B2 (en) 2006-09-29 2011-02-01 Intel Corporation Tamper protection of software agents operating in a vitual technology environment methods and apparatuses
US7908364B2 (en) 2007-01-26 2011-03-15 Bigfoot Networks, Inc. Method storing socket state information in application space for improving communication efficiency of an application program
US20080183861A1 (en) * 2007-01-26 2008-07-31 Bigfoot Networks, Inc. Communication Socket State Monitoring System and Methods Thereof
US20110296532A1 (en) * 2007-02-01 2011-12-01 Microsoft Corporation Secure serial number
US9292665B2 (en) 2007-02-01 2016-03-22 Microsoft Technology Licensing, Llc Secure serial number
US8732844B2 (en) * 2007-02-01 2014-05-20 Microsoft Corporation Secure serial number
US8001383B2 (en) 2007-02-01 2011-08-16 Microsoft Corporation Secure serial number
US20080189549A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Secure serial number
WO2008095193A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Secure serial number
US8255919B2 (en) 2007-03-23 2012-08-28 Qualcomm Atheros, Inc. Distributed processing system and method
US20080235713A1 (en) * 2007-03-23 2008-09-25 Bigfoot Networks, Inc. Distributed Processing System and Method
US20080239954A1 (en) * 2007-03-26 2008-10-02 Bigfoot Networks, Inc. Method and system for communication between nodes
US8687487B2 (en) 2007-03-26 2014-04-01 Qualcomm Incorporated Method and system for communication between nodes
US20080289038A1 (en) * 2007-05-14 2008-11-20 Samsung Electronics Co., Ltd. Method and apparatus for checking integrity of firmware
WO2008156848A1 (en) * 2007-06-19 2008-12-24 Ironkey, Inc. Recovery of data access for a locked secure storage device
US8499169B2 (en) 2007-07-20 2013-07-30 Qualcomm Incorporated Client authentication device and methods thereof
US20090025073A1 (en) * 2007-07-20 2009-01-22 Bigfoot Networks, Inc. Client authentication device and methods thereof
US8543866B2 (en) 2007-07-20 2013-09-24 Qualcomm Incorporated Remote access diagnostic mechanism for communication devices
US8909978B2 (en) 2007-07-20 2014-12-09 Qualcomm Incorporated Remote access diagnostic mechanism for communication devices
US20090024872A1 (en) * 2007-07-20 2009-01-22 Bigfoot Networks, Inc. Remote access diagnostic device and methods thereof
US8839450B2 (en) 2007-08-02 2014-09-16 Intel Corporation Secure vault service for software components within an execution environment
US20090038017A1 (en) * 2007-08-02 2009-02-05 David Durham Secure vault service for software components within an execution environment
US20090125885A1 (en) * 2007-11-13 2009-05-14 Nagabhushan Gayathri Method and system for whitelisting software components
US8099718B2 (en) 2007-11-13 2012-01-17 Intel Corporation Method and system for whitelisting software components
US20090141713A1 (en) * 2007-11-29 2009-06-04 Bigfoot Networks, Inc. Remote Message Routing Device and Methods Thereof
US9270570B2 (en) 2007-11-29 2016-02-23 Qualcomm Incorporated Remote message routing device and methods thereof
US20090210719A1 (en) * 2008-02-19 2009-08-20 Konica Minolta Holdings, Inc. Communication control method of determining whether communication is permitted/not permitted, and computer-readable recording medium recording communication control program
US9424712B2 (en) * 2008-06-27 2016-08-23 Bally Gaming, Inc. Authenticating components in wagering game systems
US20110117984A1 (en) * 2008-06-27 2011-05-19 Shimabukuro Jorge L Authenticating components in wagering game systems
US8255692B2 (en) * 2008-07-11 2012-08-28 Rosemount Inc. Method of providing secure tamper-proof acquired data from process instruments
US20100011216A1 (en) * 2008-07-11 2010-01-14 Rosemount Inc. Method of providing secure tamper-proof acquired data from process instruments
US8364601B2 (en) 2008-12-31 2013-01-29 Intel Corporation Methods and systems to directly render an image and correlate corresponding user input in a secure memory domain
US20100169666A1 (en) * 2008-12-31 2010-07-01 Prashant Dewan Methods and systems to direclty render an image and correlate corresponding user input in a secuire memory domain
US8745365B2 (en) 2009-08-06 2014-06-03 Imation Corp. Method and system for secure booting a computer by booting a first operating system from a secure peripheral device and launching a second operating system stored a secure area in the secure peripheral device on the first operating system
US8683088B2 (en) 2009-08-06 2014-03-25 Imation Corp. Peripheral device data integrity
US20110035513A1 (en) * 2009-08-06 2011-02-10 David Jevans Peripheral Device Data Integrity
US20230027329A1 (en) * 2020-02-13 2023-01-26 Intel Corporation Cryptographic computing in multitenant environments
WO2021257473A1 (en) * 2020-06-18 2021-12-23 Micron Technology, Inc. Authenticating software images
US11416621B2 (en) 2020-06-18 2022-08-16 Micron Technology, Inc. Authenticating software images
US11783045B2 (en) 2020-06-18 2023-10-10 Micron Technology, Inc. Authenticating software images

Also Published As

Publication number Publication date
AU2003300926A8 (en) 2005-01-28
KR20090045340A (en) 2009-05-07
CN1745377A (en) 2006-03-08
TWI315627B (en) 2009-10-01
TW200509636A (en) 2005-03-01
KR20060026024A (en) 2006-03-22
US20050010767A1 (en) 2005-01-13
IL172519A0 (en) 2006-04-10
EP1636715A2 (en) 2006-03-22
WO2005006109A2 (en) 2005-01-20
CN100424678C (en) 2008-10-08
KR100896625B1 (en) 2009-05-08
KR100974161B1 (en) 2010-08-04
EP1636715A4 (en) 2009-03-25
CA2525376C (en) 2014-02-04
AU2003300926A1 (en) 2005-01-28
WO2005006109A8 (en) 2005-09-29
WO2005006109A3 (en) 2005-03-03
CA2525376A1 (en) 2005-01-20

Similar Documents

Publication Publication Date Title
US6961852B2 (en) System and method for authenticating software using hidden intermediate keys
US7770021B2 (en) Authenticating software using protected master key
US6704872B1 (en) Processor with a function to prevent illegal execution of a program, an instruction executed by a processor and a method of preventing illegal execution of a program
US8417968B2 (en) Secure repository with layers of tamper resistance and system and method for providing same
US6411941B1 (en) Method of restricting software operation within a license limitation
KR100611687B1 (en) Multi-token seal and unseal
GB2404537A (en) Controlling access to data using software wrappers
WO2002001334A2 (en) System and method for interfacing a software process to secure repositories
US8607071B2 (en) Preventing replay attacks in encrypted file systems
US20050005103A1 (en) System and method for securing code and ensuring proper execution using state-based encryption
US20060112019A1 (en) System and method of authenticating licensed computer programs
KR101036701B1 (en) System for binding secrets to a computer system having tolerance for hardware changes
US7080249B1 (en) Code integrity verification that includes one or more cycles
US7197144B1 (en) Method and apparatus to authenticate a user's system to prevent unauthorized use of software products distributed to users
US6529603B1 (en) Method and apparatus to reduce the risk of observation of a secret value used by an instruction sequence
CN114357384A (en) Method for activating software based on authorization file, computing device and computer readable medium
US20060224894A1 (en) Methods, devices and computer programs for creating ciphertext, plaintext and a cryptographic key
Huang et al. A software licensing authorization scheme based on hardware component identifiers
JP3289656B2 (en) Program execution control method
Gustafsson et al. Trusted Computing & Digital Rights Management: Theory & Effects
Liu CSFS: a secure file system
WO2000075758A1 (en) Protection against unauthorized use of software products

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CRAFT, DAVID;REEL/FRAME:014212/0103

Effective date: 20030617

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.)

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20171101