WO2010054369A1

WO2010054369A1 - Method and system for controling code execution on a computing device using recursive security protocol

Info

Publication number: WO2010054369A1
Application number: PCT/US2009/063861
Authority: WO
Inventors: William V. Oxford
Original assignee: Oxford William V
Priority date: 2008-11-10
Filing date: 2009-11-10
Publication date: 2010-05-14
Also published as: EP2340631A1; JP2012508529A; JP2015035224A; KR20110106849A; JP5636371B2

Abstract

Embodiments of systems and methods which provide highly specific control over the execution of general-purpose code block are disclosed. These embodiments may allow the exact circumstances under which a given code block is allowed to execute to be determined with specificity. Such a control mechanism may be coupled with embodiments of a data hiding system and method, based for example, on an ordered execution of a set of code segments implemented via recursive execution. When embodiments of these systems and methods are utilized together an unencumbered generality as well as a level of protection against attack that surpasses many other security systems may be obtained.

Description

METHOD AND SYSTEM FOR CONTROLING CODE EXECUTION ON A COMPUTING DEVICE USING RECURSIVE SECURITY PROTOCOL

TECHNICAL FIELD

[0001] This disclosure relates to a method for controlling arbitrary code execution on a general-purpose computer. Specifically, this disclosure relates to effective methods for linking the execution of code to a computing device to control the execution of the code. Even more particularly, this disclosure relates to controlling the execution of code in conjunction with the implementation of a recursive security protocol.

BACKGROUND

[0002] Computer viruses and other malicious software present a massive problem for the information technology industry. Since a general purpose computer can, by definition, run arbitrary code, it can be very difficult to maintain control over exactly which software is allowed to run, either in part or in whole, on a given general purpose computer platform and thus, it can be difficult to prevent the execution of malware or other types of undesirable software. There are a number of methods by which this level of control is currently attempted, but most efforts to isolate the processor from attack suffer from two fundamental problems: loss of generality in the processor platform or loss of performance. These losses stem from the basic issue of how to quickly and unequivocally distinguish between authorized and unauthorized usage modes.

[0003] A secondary, but related problem is that of copyright control. The vast majority of written, audio and visual works of art that are created today either begin or end up in digital format. One of the characteristics of digital data is that it can easily be substantially exactly duplicated. This property facilitates a wide variety of inexpensive distribution mechanisms, most of which are not easily controlled. The inherent inability to limit the distribution of digital content has had far-reaching implications on the field of copyright law over the last couple of decades. While certain systems and methods have been developed to control the copying and distribution of such duplicated data, one problem with these systems and methods is that they may be circumvented through the execution of certain types of software in conjunction with these systems and methods, for example, code which modifies the systems and methods, or obtains data utilized by such systems and methods.

[0004] Thus, there is a need to find systems and methods by which some amount of control over the execution of code on a general purpose computing device may be asserted, where by utilizing such systems and methods in conjunction with a security protocol the effectiveness of such a system may be enhanced.

SUMMARY

[0005] Embodiments of systems and methods which provide highly specific control over the execution of general-purpose code block are disclosed. These embodiments may allow the exact circumstances under which a given code block is allowed to execute to be determined with specificity. Such a control mechanism may be coupled with embodiments of a data hiding system and method, based for example, on an ordered execution of a set of code segments implemented via recursive execution. When embodiments of these systems and methods are utilized together an unencumbered generality as well as a level of protection against attack that surpasses many other security systems may be obtained.

[0006] In particular, in one embodiment, systems and methods for conditional control over code execution are disclosed along with systems and methods for obscuring data that is used in a particular computation, while nonetheless still allowing the use of that data. These systems and methods for control or obfuscation can be used in a large number of potential application areas, including the areas of security which may encompass, but are not limited to, the following: digital security, copyright control, conditional access, protection against undesirable computer viruses, etc. Specifically, embodiments may be utilized in conjunction with a recursive security protocol to augment such a security protocol.

[0007] Additionally, embodiments of systems are presented which embody these types of methodologies in computer systems, hardware, and software. It should be noted that the exact same hardware implementation could potentially be used to implement any one or combination of the entire range of solutions, depending on the requirements of the software.

[0008] These, and other, aspects of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the invention and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the invention without departing from the spirit thereof, and the invention includes all such substitutions, modifications, additions and/or rearrangements.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer conception of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore nonlimiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. The invention may be better understood by reference to one or more of these drawings in combination with the description presented herein. It should be noted that the features illustrated in the drawings are not necessarily drawn to scale.

[0010] FIGURE 1 depicts one embodiment of an architecture for content distribution.

[0011] FIGURE 2 depicts one embodiment of a target unit general purpose computing device.

[0012] FIGURE 3 depicts one embodiment of the creation of a compound key.

[0013] FIGURES 4A and 4B depict embodiments of the creation of digital signatures or their equivalents.

[0014] FIGURES 5A and 5B depict embodiments of the use of a compound key structure with a secured code block.

[0015] FIGURE 6 depicts one embodiment of the use of a compound message digest.

[0016] FIGURE 7A, 7B and 7C depict embodiments of a secured code block message.

[0017] FIGURE 8 depicts an embodiment of a decryption operation.

[0018] FIGURE 9 depicts one embodiment of the use of a compound key.

[0019] FIGURE 10 depicts one embodiment of the use of a compound key in the authorization of a candidate code block. [0020] FIGURE 11 depicts one embodiment of a decryption operation.

[0021] FIGURE 12 depicts one embodiment of the validation of a code block.

[0022] FIGURE 13 depicts one embodiment of a decryption operation performed using a recursive security protocol.

[0023] FIGURE 14 depicts one embodiment of the operation of code validation .

[0024] FIGURE 15 depicts one embodiment of a digital signature function block.

DETAILED DESCRIPTION [0025] The invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure. Embodiments discussed herein can be implemented in suitable computer- executable instructions that may reside on a computer readable medium (e.g., a HD), hardware circuitry or the like, or any combination.

^"0026^" Before discussing specific embodiments, embodiments of a hardware architecture for implementing certain embodiments are described herein. One embodiment can include one or more computers communicatively coupled to a network. As is known to those skilled in the art, the computer can include a central processing unit ("CPU"), at least one read-only memory ("ROM"), at least one random access memory ("RAM"), at least one hard drive ("HD"), and one or more input/output ("I/O") device(s) . The I/O devices can include a keyboard, monitor, printer, electronic pointing device (such as a mouse, trackball, stylist, etc.), or the like. In various embodiments, the computer has access to at least one database over the network.

;0027] ROM, RAM, and HD are computer memories for storing computer instructions executable (in other which can be directly executed or made executable by, for example, compilation, translation, etc.) by the CPU. Within this disclosure, the term "computer-readable medium" is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. In some embodiments, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.

^0028] At least portions of the functionalities or processes described herein can be implemented in suitable computer- executable instructions. The computer-executable instructions may be stored as software code components or modules on one or more computer readable media (such as nonvolatile memories, volatile memories, DASD arrays, magnetic tapes, floppy diskettes, hard drives, optical storage devices, etc. or any other appropriate computer-readable medium or storage device) . In one embodiment, the computer- executable instructions may include lines of complied C++, Java, HTML, or any other programming or scripting code.

^0029] Additionally, the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.

^0030] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, process, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present) .

^0031] Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of, any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: "for example," "for instance," "e.g.", "in one embodiment . "

^0032] As discussed above, it is desired to allow a processor to execute an arbitrary segment of code in a prescribed manner. This problem of control is compounded by the many varied methods by which even legitimate software can be manipulated to produce unintended or even malicious results. These methods of attack may include exploiting poorly written, but otherwise valid code by feeding bogus arguments as input to the routine in order to exploit input data corner cases or even other algorithmic deficiencies. Other possible avenues of attack include independently modifying the data that are stored in various processor registers (such as the stack pointer) or external memory locations that are referenced by otherwise legitimate code in a manner to produce improper or intentionally erroneous results. ^0033] There are a number of mechanisms by which this kind of control can be affected. These systems include both simple as well as complex schemes that attempt to protect the processor from this kind of unintended usage. One reasonably secure, but complex mechanism includes pre-encryption of a code segment prior to its execution. Once the code segment is loaded into the processor from memory, it must be decrypted under carefully controlled circumstances and then executed in a secure fashion (in other words, it must not be modified or tampered with between the decryption operation and the subsequent execution) . This mechanism suffers from a performance inefficiency that can be incurred because the processor must wait until the code segment in question is decrypted prior to being able to begin execution. This latency between the selection of a particular code segment to be executed and the actual post-decryption execution can cause many problems including, but not limited to, processor pipeline stalls and data path inefficiencies as well as providing another avenue for potential attacks (by somehow hijacking the code in between the decryption and the execution operations) .

;0034] This encrypted code mechanism also does nothing to protect the processor from the eventuality of a hacker who manages to properly decrypt (or who obtains a decrypted copy of) the ostensibly protected encrypted code segment. In that case, they could then run that unprotected code in a non- controlled manner, either on the target processor or on some other non-authorized processor. Thus, it is preferable to find a way to exercise control over exactly which code segments can be run on a particular processor or processors, irrespective of whether the code is distributed in the clear (i.e., in plaintext form) or in encrypted form. On the other hand, if the code that can be run on a particular processor is limited to some pre-selected subset, then the general- purpose nature of the processor itself may be violated. This could possibly have the effect of constraining the architecture in such a way that the processor becomes less general purpose and thus, much less flexible in its potential application space. There will always be a strong desire for maximally flexible general-purpose processor architectures, but it is exactly those processors that are most vulnerable to malware attacks.

^0035] Thus, there is a need for a method for control of code execution that is general-purpose enough to not depend on any particular processor architecture. It would also be useful if such a method would also not adversely impact either the object code density or the execution pipeline of the target processor. At the same time, is desirable that such systems and methods provide protection against unlicensed use of otherwise legitimate code segments on either an original target processor or some other non- intended target processor. Such a method would be a valuable tool in the battle for control over software viruses and malware as well as a uniquely powerful mechanism for protecting copyright in a world of digital content.

^0036] To that end, attention is now directed to embodiments of systems and methods which provide highly specific control over the execution of general-purpose code block, in turn, allowing a programmer to determine the exact circumstances under which a given code block is allowed to execute. These conditions may include (but are not limited to) such constraints as the individual device on which the code block is attempting to execute, the environment in which the code block is called, the time of execution, the order of execution as well as the number of times the code block has been called in a particular execution thread.

^0037] Such a control mechanism may be coupled with embodiments of a data hiding system and method, based for example, on an explicitly ordered execution of a set of called code segments implemented in one embodiment via recursive execution. When embodiments of these systems and methods are utilized together an unencumbered generality as well as a level of protection against attack that surpasses many other security systems may be obtained.

^0038] Before discussing embodiments in more detail it may helpful to give a general overview of an architecture in which embodiments of the present invention may be effectively utilized. FIGURE 1 depicts one embodiment of such a topology. Here, a content distribution system 101 may operate to distribute digital content (which may be for example, a bit stream comprising audio or video data, a software application, etc.) to one or more target units 100 (also referred to herein as endpoint devices) which comprise protocol engines. These target units may be part of, for example, computing devices on a wireline or wireless network or a computer device which is not networked, such computing devices including, for example, a personal computers, cellular phones, personal data assistants, media players which may play content delivered as a bitstream over a network or on a computer readable storage media that may be delivered, for example, through the mail, etc. As will be described later this digital content may compose or be distributed in such a manner such that control over the execution of the digital content may be controlled and security implemented with respect to the digital content.

^0039] FIGURE 2 depicts an architecture of one embodiment of a target unit that is capable of controlling the execution of the digital content or implementing security protocols in conjunction with received digital content. Elements of the target unit may include a set of blocks, which implement the protocol in a secure manner on a protocol engine of the target unit 100. It will be noted that while these blocks are described as hardware in this embodiment, software may be utilized to accomplish similar functionality with equal efficacy. It will also be noted that while certain embodiments may include all the blocks described herein other embodiments may utilize lesser or additional blocks.

^0040] The first of these blocks is a real-time clock or date/time register 102. This is a free-running timer that is capable of being set or reset by a secure interaction with a central server. Since the time may be established by conducting a query of a secure time standard, it may be more convenient to have this function be on-chip. Target unit 100 may also comprise random number generator 180 which may be configured to produce a sequence of sufficiently random numbers or which can then be used to supply seed values for a pseudorandom number generation system. This pseudo-random number generator can also potentially be implemented in hardware, software or in "secure" software.

^0041] One-Way Hash Function block 160 may be operable for implementing a hashing function substantially in hardware. Another portion of the target unit 100 may be a hardware- assisted encryption/decryption system 170, which uses the target unit's 100 secret keys or public/private keys (described later) to operate on encrypted messages in order to translate them into executable code blocks or on unencrypted data to transform it into an encrypted message. This decryption system 170 can be implemented in a number of ways. It should also be noted that this combination of a One-Way Hash Function and a subsequent encryption/decryption system may comprise a digital signature generator that can be used for the validation of any digital data, whether that data is distributed in encrypted or in plaintext form. The speed and the security of the entire protocol may vary depending on the construction of this block, so it may be configure to be both flexible enough to accommodate security system updates as well as fast enough to allow the system to perform real-time decryption of time-critical messages.

;0042] Keeping this in mind, it is not material to embodiments of a protocol exactly which encryption algorithm is used for this hardware block 170. In order to promote the maximum flexibility, it is assumed that the actual hardware is general-purpose enough to be used in a non-algorithmically specific manner, but there are many different means by which this mechanism can be implemented. It should be noted at this point that the terms encryption and decryption will be utilized interchangeably herein when referring to engines (algorithms, hardware, software, etc.) for performing encryption/decryption. As will be realized if symmetric encryption is used in certain embodiments, the same or similar encryption or decryption engine may be utilized for both encryption and decryption.

^0043] Another block is memory 110 where code that is to be executed can be stored. This is typically known as an Instruction Cache (I-Cache) . In some embodiments, an important characteristic of portions of this I-Cache 110 is that the data contained within certain blocks be readable only by CPU execution unit 120. In other words, this particular block of I-Cache memory 130 is execute-only and may not be read from, nor written to, by any software. This block of I-Cache will also be referred to as the "secured I-Cache" 130 herein. The manner by which code to be executed is stored in this secured I-Cache block 130 may be by way of another block which may or may not be depicted. Normal I-Cache 150 may be utilized to store code that is to be executed normally as is known in the art.

^0044] Additionally, in some embodiments, certain blocks may be used to accelerate the operation of a secure code block. Accordingly, a set of CPU registers 140 may be designated to only be accessible while the CPU 120 is executing secure code or which are cleared upon completion of execution of the secure code block (instructions in the secured code block 130 referred to as secure mode), or if, for some reason the a jump to any section of code which is located in the non-secure or "normal" I-Cache or other area occurs during the execution of code stored in the secured I-Cache 130 .

^0045] In one embodiment, CPU execution unit 120 may be configured to track which registers 140 are read from or written to while executing the code stored in secured code block 130 and then automatically clear these registers upon exiting the "secured execution" mode. This allows the secured code to quickly "clean-up" after itself such that only data that is permitted to be shared between two kinds of code blocks is kept intact. Another possibility is that an author of code to be executed in the secured code block 130 can explicitly identify which registers 140 are to be cleared.

^0046] Another potential manner for dealing with the "leaking" of data stored in registers 140 between secure and non-secure code segments is to identify a set of registers 140 which are to be used only when the CPU 120 is executing secured code. In one embodiment this may be accomplished utilizing a version of the register renaming and scoreboarding mechanism, which is practiced in many contemporary CPU designs. If the execution of a secured code block is treated as an atomic action (i.e., it is non-interruptible) may make this renaming and scoreboarding easier to implement.

^0047] Even though there may seem to be little possibility of the CPU 120 executing a mixture of "secured" code (code in the secured code block 130) and "unsecured code" (code in another location such as normal I-cache 150 or another location in memory), such a situation may arise in the process of switching contexts such as when jumping into interrupt routines, or depending on where the CPU 120 context is stored (most CPU's store the context in main memory, where it is potentially subject to discovery and manipulation by an unsecured code block) .

;0048] In order to help protect against this eventuality, in one embodiment another method which may be utilized for protecting the results obtained during the execution of a secured code block that is interrupted mid-execution from being exposed to other execution threads within a system is to disable stack pushes while a processor is operating in secured execution mode. This disabling of stack pushes will mean that a secured code block is thus not interruptable in the sense that, if the secured code block is interrupted prior to its normal completion, it cannot be resumed and therefore must be restarted from the beginning. It should be noted that in certain embodiments if the "secured execution" mode is disabled during a processor interrupt, then the secured code block may also potentially not be able to be restarted unless the entire calling chain is restarted.

^0049] Each target unit 100 may also have two sets of secret key constants 104; the values of neither of which are software- readable. The first of these keys (the primary secret key) may be organized as a set of secret keys, of which only one is readable at any particular time. If the "ownership" of a unit is changed (for example, the equipment containing the protocol engine is sold or its ownership is otherwise transferred) , then the currently active primary secret key may be "cleared" or overwritten by a different value. This value can either be transferred to the unit in a secure manner or it can be already stored in the unit in such a manner that it is only used when this first key is cleared. In effect, this is equivalent to issuing a new primary secret key to that particular unit when its ownership is changed or if there is some other reason for such a change (such as a compromised key) . A secondary secret key may be utilized with the target unit 100 itself. Since the CPU 120 of the target unit 100 cannot ever access the values of either the primary or the secondary secret keys, in some sense, the target unit 100 does not even "know" its own secret keys 104. These keys are only stored and used within the security block of the target unit's CPU 120.

^0050] Yet another set of keys may operate as part of a temporary public/private key system (also known as an asymmetric key system or a PKI system) . The keys in this pair are generated on the fly and may be used for establishing a secure communications link between similar units, without the intervention of a central server. As the security of such a system is typically lower than that of an equivalent key length symmetric key encryption system, these keys may be larger in size than those of the set of secret keys mentioned above. These keys may be used in conjunction with the value that is present in the on-chip timer block in order to guard against "replay attacks", among other things. Since these keys are generated on the fly, the manner by which they are generated may be dependent on the random number generation system 180.

^0051] In one embodiment, one method that can be used to affect a change in "ownership" of a particular target unit is to always use the primary secret key as a compound key in conjunction with another key 107, which we will refer to as a timestamp or timestamp value, as the value of this key may be changed (in other words may have different values at different times), and may not necessarily reflect the current time of day. This timestamp value itself may or may not be itself architecturally visible (i.e., it may not necessarily be a secret key) , but nonetheless it will not be able to be modified unless the target unit is operating in secured execution mode. In such a case, the consistent use of the timestamp value as a component of a compound key whenever the primary secret is used can produce essentially the same effect as if the primary secret key had been switched to a separate value, thus effectively allowing a "change of ownership" of a particular target endpoint unit without having to modify the primary secret key itself.

^0052] It may now be useful to go into more detail regarding the one-way hash function hardware of a target unit. Referring now to FIGURE 15, one embodiment of a one-way hash function block that can use the result of a digital signature operation generated in one iteration of a recursive security protocol as a seed value for the one-way hash function in a subsequent iteration is depicted. In one embodiment, the state of the target unit as far as it pertains to whether it is operating in secured execution mode or not can be reflected by the value of a hardware bit 1570 that will be referred to herein as the "Secured Mode Enabled" bit.

^0053] Here, the default state of this hardware bit may be cleared (i.e., the default state of the target processor is not to be operating in secured execution mode) . The interaction of this bit with the One-Way hash function hardware block 1561 in certain embodiments may be described in two parts. In the first (non-secured) case, all accesses to the Secret Hardware key 1540 are blocked, since the "Secured Mode Enabled" bit acts as a gatekeeper to only allow use of the Secret Hardware key when this hardware bit is set (for example to a "1", however it will also be noted that in certain architectures the bit may be considered "set" when it has a value of "0") . Also in this case, the output of the Digital Signature Register 1564 is fed back to form the input "Seed" 1510 of the One-Way Hash function 1561. Thus, while the processor is operating in this "non-secured execution" mode, the intermediate results of any of the oneway Hash function operations are fed back to form the seed for any subsequent one-way hash function operations. This allows a running checksum equivalent of the entire calling chain of a set of nested or concatenated functions to be kept. In the case where each code block that is attempted to be executed is first evaluated with this one-way hash function prior to it being allowed to execute it the entire calling chain of any given code block can be substantially unambiguously determined with this single mechanism.

^0054] Likewise, in the case where the "Secured Mode Enabled" bit is set (i.e., where the processor is operating in "Secured Execution mode") , the Secret Hardware Key is accessible (in other words, directly accessible or at least its value is able to be used in a calculation operation, even if its value is not directly accessible by the processor itself) . Additionally, when operating in Secured Execution Mode the output of the Digital Signature Register is not fed back to form the seed value for subsequent evaluations of the oneway hash function. The exact implementation of this Digital Signature generator block will be discussed in more detail at a later point. As can be seen then, in certain embodiments the entire calling chain of a particular code block can be validated prior to its secure execution without the need to utilize measures such as system-wide software or hardware validation (or attestation) operations. Note that, as in the case described earlier for the Timestamp Register, in certain embodiments this "Secured Mode Enabled" bit may or may not be architecturally visible to the processor, but its state may not be explicitly set by the processor. This hardware bit could be reset to a default value by calling a non-secured code segment, but in one embodiment, the only manner in which this bit can be set is through direct action on the part of the hardware. In the case where the bit is architecturally visible, it can be explicitly determined whether or not the processor is operating in secured execution mode. In the case where it is not architecturally visible, then the determination can nonetheless be made implicitly by evaluating some expression whose value somehow depends on the hardware secret key. It may now be useful to describe basic problems underlying subjects that may be germane to the control of code execution and the implementation of security protocols in more detail. Then it can be shown how to implement control over the execution of arbitrary-code on an arbitrary general purpose processor using embodiments of the hardware described above and how embodiments of these systems and methods may be effectively utilized with security protocols and system to construct an effective overall security system. Secret Key hiding

[0056] The majority of commercial digital content delivery systems include some form of encryption or data hiding to try to protect the digital media data from being duplicated and distributed freely. In the vast majority of cases, the data hiding strategy is eventually proven to be a completely ineffective means of content protection. One of the main reasons that this hiding has proven unsuccessful is that the exact data that is to be protected from exposure must nonetheless be freely available for use by any authorized party. Thus, a set of seemingly contradictory requirements exists for the distribution of digital content.

[0057] In the case where the original digital content can be separately encrypted for all intended recipients and where only the intended recipient may actually make use of the distributed digital content then the security of the system can potentially be quite good. However, unless a number of specific conditions are met, the security of this kind of system can be shown to be deficient in several respects. First, such a system is less efficient in that it requires that the entire distributed data set must be re-encrypted separately for each intended recipient. Second, the distributor may need to ensure that no unauthorized decryption is possible on a general-purpose processor. Third, each individual receiving device must be unique in the sense that it must possess some attribute that cannot be easily duplicated on some other endpoint device (or emulated on a general-purpose processor) . If either of these last two conditions is violated, then this system is vulnerable to attack simply by intercepting both the individually encrypted data as well as the device-specific key that is associated with that data.

[0058] In fact, it can be shown that the security of such a system may be based on the security of the unique attribute of each of the receiving devices. This unique attribute is typically implemented using a secret key that is known only to the distributor and the authorized recipient. While, in principle, this kind of setup can be an effective security system, the requirement that the original digital content be separately encrypted for each recipient makes the actual implementation impractical for most purposes. If it is desired that the original digital content be encrypted once and identically distributed to all potentially authorized parties, the problem then reverts back to that of data hiding. These types of problems are known as the field of Broadcast Encryption.

^0059] One of the fundamental problems with a distributed secret data system of almost any kind is that, in the majority of cases, all of the messages and data that flow back and forth between the separate entities of the security system are usually transmitted in the open and are thus observable by eavesdroppers. Thus, any messages or data that are transmitted between the individual components of such a system should be encrypted to protect against interception by unauthorized parties. Another problem that must be addressed in such a system is the verification of the identity of both the transmitter as well as the receiver in any such secret data transmission. In the case where the two parties are not known to each other, a mutually trusted intermediary strategy is typically employed.

^0060] Additionally, however, once the secret data has arrived at its destination, an equally difficult problem that must be addressed is how to securely use that secret data in such a manner that it is not compromised. This precaution is usually necessary as it is also possible that even a legitimate endpoint may have its security compromised by providing it with false information. So, in addition to protecting against unauthorized discovery during distribution it is sometimes desired to protect the secret data from discovery by an otherwise authorized user of that secret data.

^0061] In one embodiment, such desired control may be implemented, using a simple time-dependent use of an architecturally hidden secret key or an encrypted object code block that must be decrypted in real time prior to execution. In the first case, the code block execution can be completely transparent to the control mechanism, which means that the execution speed should be minimally affected. In the latter case the code block to be run may be decrypted prior to execution, so there is most likely a concurrent loss of performance due to the latency of the decryption process. In this latter case, however, the object code may be relatively safe from disassembly and is thus potentially more difficult to subvert by would-be attackers. Embodiments discussed herein at a later point disclose systems and methods that can be implemented in a large continuum of possible solutions, ranging from a highly secure encrypted object code method to a relatively higher-performance, but nonetheless still quite secure selectively-available, secret key method.

;0062] In one embodiment, hiding the secret key from the user of such a secret key may be accomplished in a method similar to the Harvard Architecture memory space bifurcation. In this embodiment, however, the distinction may be made that a secret key may be used in an encryption/decryption calculation, but never actually directly read by the processor. This distinction may be enforced by limiting the encryption/decryption operations to those that are either implemented in hardware or are pre-determined software macros (also known as micro code), fixed at the design time of the hardware. For example, in the case where a hardware secret key may be used by any arbitrary code, even though it may not be able to be directly read by the processor, it can nonetheless be readily determined by simple calculations. Thus, it may be desired to specify that only security- related calculations may access the hardware secret key to differentiate such code segments from more general purpose, but less secure code blocks.

[0063] This distinction may be accomplished, in certain embodiments, utilizing validation methods substantially similar those described herein. If embodiments of the adaptive digital signature methods described earlier are utilized to determine whether or not the hardware secret key may be accessed, then it can be readily and reliably determined if the target processor is executing security- related calculations (i.e., calculations performed when the target processor is operating in "Secured Execution" mode) and those that are not secured. In addition, recursive methods substantially similar to those outlined earlier may be utilized to keep any intermediate key results hidden from discovery until the final calculations are completed and the fully decoded result is reported. Thus, embodiments described herein may have the ability to decode an encrypted digital bitstream without ever exposing the secret global key that is used to generate that same bitstream.

Code execution control

[0064] Methods for ensuring that a particular code segment is executed securely on a given processor have been widely studied for many years. Some of the earlier attempts to create secure code execution protection have included making modifications to the processor architecture in order to establish a set of "privileged" instructions. These privileged instructions were secured by designing the architecture such that these privileged instructions could only be executed when the processor was running in a particular mode, known as "supervisor" or "kernel" mode. This kind of bifurcation of the processor architecture has a number of drawbacks, including a potential loss of both processor generality as well as a potential degradation in performance. In addition to these drawbacks, such protective measures can often be bypassed by using specifically designed software calls to standard system routines in such a way as to take advantage of unexpected execution paths while the processor is executing in supervisor mode. Examples of such specifically designed malware attacks include so-called "stack overflow", "stack overrun" and "code injection" attacks.

^0065] A number of strategies have been devised in an attempt to help protect against these kinds of exploits, mostly based on various means of checksum verification or argument bounds checking. In the face of these kinds of protective measures, a variety of counter-counter-measures have evolved, including polymorphic viruses (i.e., self-modifying code) . Other strategies for exploiting processor weaknesses in the face of bounds-checking include simply bypassing the bounds- checking "supervisor" routine itself. This kind of exploit is also used quite often in circumventing various copyprotection systems. As it turns out, the strategy of hijacking the supervisor routine is not unique to the world of computer security and is not at all a new concept. In fact, this exact problem has analogs in a variety of applications and has been referenced as far back as Plato in his work "The Republic". The basic problem is that, in any given system, one can always identify some sort of a global supervisor, with whom the ultimate security or stability of a structure is entrusted. Such a concept of a global foundation for all subsequent security functionality is known in the contemporary study of security systems as the "Root-of-Trust".

;0066] More recently, there have been some attempts to protect a processor against supervisor routine attacks by limiting the memory segments out of which the processor is fetching instructions to be read-only in nature (this includes the so-called W^ΛX or "write-XOR-execute" approach) . The concept of splitting an otherwise general-purpose computer's memory space into data-based and code-based partitions can be shown to be a variation of the so-called "Harvard Architecture." This method has a certain performance penalty associated with the protection mechanism as well as a concurrent increase in memory utilization. Finally, it has also been shown recently that even these kinds of defenses can be circumvented by the use of so-called "return-based" programming exploits or even by simple memory-aliasing exploits, where two separate execution threads can reference the same block of memory in different modes (one in "data mode" and the other in "execution mode") . Another proposed means of protecting the execution thread of a processor from being hijacked includes the use of encrypted code blocks. In this method, the code segments to be executed are pre-encrypted and thus, non-readable (and perhaps even more importantly, non-alterable) prior to their loading into the processor. This method also has several weaknesses. First, the code segment itself may be protected, but the arguments are not necessarily provided with the same level of security. Thus, a completely legitimate and secure code segment can be nonetheless provided with bogus arguments from its calling routine that can cause it to behave in an unexpected fashion. Second, in some cases, the execution thread is not necessarily protected against the return-based programming attacks described above. Also, if the processor bus can be readily observed by the attacker, then the long-term observation of both correctly-executed (even though encrypted) code segments as well as the observation of exception faults caused by improperly encrypted code segments injected into the executable stream can help to reveal the encryption key using a modified dictionary attack methodology. Finally, the processor performance in such a system is necessarily severely degraded over similar, but non-encrypted code systems. This performance penalty can be caused by a number of issues, the most significant of which is the latency incurred by the requisite decryption of the code block between when it is fetched from memory and when it is available to be executed. Although most modern processors use a pipelining mechanism to attempt to increase the number of instructions that can be executed in parallel (by various means), a block of encrypted code cannot be read into such a pipeline until it has first been decrypted. In the case where the code branches frequently, the decryption process can potentially take much longer than the code execution itself, even with a hardware-assisted decryption.

^0068] Embodiments of the systems and methods described in this invention may allow the utilization of unencrypted code blocks, so the performance penalties associated with encrypted executables are thus less of an issue. However, in the case where the execution efficiency is not a substantial concern encrypted code blocks may still be utilized. Thus, embodiments disclosed herein may have both the efficiency of plaintext executables as well as the added security of encrypted code segments utilizing the same or similar methods and systems. In addition, embodiments of the security systems and methods described herein can be updated in-situ to address newly discovered security concerns as well as to add new functionality after an embodiment has already been deployed.

;0069] Embodiments of the invention may attain these advantages, among others, by ensuring that a "secured code segment" is validated prior to execution by means of a cryptographic hashing function. This validation may be accomplished, for example, by authenticating a message digest or digital signature created for such a secured code segment. In the case where the evaluation of this cryptographic hashing function occurs in conjunction with the encryption of the resulting message digest using a compound key structure as described earlier to form a digital signature, a particular code block can be uniquely associated with a specific target unit or processor. This process will be referred to herein as "secured code binding", based on the fact that in certain embodiments this secured code block can be cryptographically bound to a specific target unit using the compound key based digital signature.

^0070] Although executing such a hashing function may not be resource free, an advantage of this approach is that the secured code segment can be introduced into the execution pipeline prior to completing its cryptographic validation. Thus, the hashing function can potentially be evaluated in parallel with the execution of the secured code segment itself (in a manner similar to speculative branch execution) . In this embodiment, the results of the secured code segment may be utilized only if the resulting message digest is determined to be genuine. However, in another embodiment, the results of the secured code segment may be utilized in subsequent operations, but the results themselves may be different depending on whether or not the processor is operating in secured execution mode. This embodiment is substantially similar to the process described earlier for the evaluation of a compound key for use in a digital signature and can be generated by use of the hardware such as that depicted in FIGURE 15.

;0071] The use of cryptographic validation does not, however, preclude the use of encrypted code segments. In fact, the use of a message digest or digital signature of the correctly decrypted code (the secured code segment in its original state before applying any type of encryption) may provide an additional level of protection. This is due to the fact that the prospective attacker would have to have a- priori knowledge of the correctly decrypted code block in order to create a counterfeit message digest. Thus, if both the code segment validation as well as the encrypted code methods can be used at the same time, higher robustness against attack may be realized.

\0012] As may be also be realized, however, there are several methods by which such hashing validation could be bypassed, the simplest of which would be to subvert the hashing function itself. Even if it is assumed that this strategy is not possible with certain embodiments (by utilizing a hardware hashing function, for example) it still could be possible to attack the security of such an embodiment by providing an impostor code segment along with a properly validated message digest. Since many message digests are actually encrypted to form a digital signature, then on the surface, this attack strategy would seemingly prove difficult. However, even a digital signature mechanism could potentially be attacked, either by spoofing the public key lookup portion of the digital signature, and thus providing an artificial validation of the impostor digital signature or alternately, by a malicious subversion of the signature validation routine itself.

^0073] These limitations are overcome in embodiments of the systems and methods disclosed herein by doubly encrypting the message digest associated with the secured code segment; once with the (global) "author's" secret key and then once again with a secret key known only to the endpoint "manufacturer" (which may not actually be the original chip manufacturer, but may be a secondary level distributor, system integrator, service provider, etc.) and the particular endpoint device on which the code segment in question is to execute. The advantage of this embodiment is that, even if the aforementioned digital signature is shared between similar endpoint devices, it will only function correctly on its intended target unit since the secret keys of different target units will differ. Thus, any such digital signature can be transmitted and stored in the clear . ;0074] Embodiments of techniques of doubly encrypting a secret (which may be used in so-called "layered key" systems as well as in a recursive security system) may have certain issues, if it is incorrectly used. First, if the intermediate result of such a layered encryption process is intercepted, then this intermediate key can be used to bypass the higher level security on any and all such systems. Also, note that, in the "lowest layer" of such a layered system, this intermediate result is actually a "global" decryption key that, if discovered, can be used to bypass the entire security system for all substantially similar endpoint devices. This kind of "intercept" attack has occurred more than once by simply watching for any memory transactions during the decryption process and then examining all such memory locations for a potential global decryption key. The process of watching for all memory accesses during a decryption process may seem cumbersome at first, but it is almost certainly a more efficient attack strategy than the brute-force guessing of the value of such a secret key. A second potential weakness in a layered key system can be exploited by a variant of the replay attack. In the case where a layered key system's security is compromised and its keys must be updated, then the old (compromised) keys may still be used if the original system is either reset back to its former state or if its former state is cloned by an impostor unit.

^0075] These weaknesses may be addressed in embodiments discussed herein using what we will refer to as a "compound key", as opposed to a "layered key" structure. One of the main differences between a compound key and a layered key is that all segments of the former may be evaluated in a single monolithic pass. By contrast, in a layered key system, the "outermost" layer key can be evaluated first, returning the next innermost key (which is then used to as an argument to produce the next layer's key, and so on, until the entire key stack has been traversed) . The problem with this system is that the lower level keys can be intercepted and used later, effectively bypassing the outermost security layers. Thus, in such layered key embodiments the most important (in this case global) keys are those that are created and used last in the chain, where any additional (or more recent) layers of security are completely absent.

^0076] For this reason, a more robust manner to traverse such a security stack may be utilized such that the stack is traversed from the "inside out". This means that the most recent additions to the security chain are those that are executed first in sequence but are, in fact, located at the innermost layer of the security system. Accordingly, embodiments may be used to enforce such an "inside out" execution ordering. This particular ordering of code stack traversal can be accomplished by using a simple iterative approach, where the code loop first evaluates the current security level and then branches accordingly. However, in the iterative method, the intermediate results of the security system traversal can potentially be bypassed because, as noted earlier, the attacker could simply wait for the next lower level key to be exposed in a legitimate security system traversal and then use that intercepted key to clone a counterfeit "earlier" version of the system. Thus, embodiments of systems and methods are described that can not only enforce this "inside out" execution ordering, but also can protect intermediate results from being intercepted by malicious code or other well-known security system exploits.

^0077] Another major advantage when using such an "inside-out" security approach is that the entire sequence of calling arguments may be visible to the innermost layer (and thus, most recent version) of the security system. If this "inside out" execution sequence is implemented properly, then it can be seen that a correctly constructed bounds-checking mechanisms employed in such a system can have visibility over the entire calling chain. Thus, embodiments may have a built- in mechanism for performing a significant amount of the system attestation function without incurring any additional performance penalties most usually associated with such functionality .

^0078] Accordingly, certain embodiments may utilize a means to keep intermediate keys from being exposed to higher-level (and thus, less secure) security system routines as well as to ensure the proper security stack traversal method. One such method for achieving this is to use a recursive security structure, one embodiment of which is depicted in United States Patent Application No. 10/465,274, entitled "Method and System for a Recursive Security Protocol for Digital Copyright Control" by William V. Oxford filed June 19, 2003, which has since issued as United States Patent No. 7,203,844, on April 10, 2007, which is herby incorporated by reference for all purposes.

^0079] If embodiments of such recursive security protocols are utilized, certain advantages may be realized. First, the stack order traversal can be designed so that it must be evaluated from the "inside out". This means that the most recent security system additions are executed first and the system cannot be "started in the middle" (for example, as used in "return-based" programming exploits) . A second advantage of a recursive system is that the addition of any updates to the security system may not change the original calling arguments at the security system itself. Accordingly, it may be more difficult to spoof the security system by using a traditional replay-based attack mechanism. While it is certainly possible for embodiments disclosed herein to employ inline execution stack with reverse ordering in an iterative fashion, the iterative mechanism may be subject to interruption and thus, it may also be possible to create a situation where a partial evaluation of the security stack is performed. This would potentially allow for one or more intermediate results to be intercepted by outside observers. In an inside-out security system implemented through recursion as may be utilized by embodiments herein, intermediate results cannot be passed as an argument to the next level routine at any point; only the final results of the security system layer being currently executed are available to the next level up in the security system stack.

^0080] The compound key structure may also be protected from partial evaluation by tightly controlling accesses to a target unit's secret key in certain embodiments. For example, if the secret key is stored in an inaccessible memory location which is not architecturally visible, then it may only be accessed as a part of a particular security-related instruction or function. In certain embodiments this function or instruction is one that may not be easily reversed such as a non-trivial one-way transform. That way, even a counterfeit security system should not be able to reveal the value of the secret key. Consequently, by only letting the secret key be referenced indirectly as a part of a one-way function the secret key may be protected as the secret key can never be used by itself as a part of a mathematical operation, but only as a part of a hashing operation either alone or along with some other datum, where only the result of the hashing function may be observable.

^0081] Additional mechanisms to protect the secret key may also prove useful in certain embodiments. One such potential mechanism is the use of a compound key, where the target unit's secret key is tightly coupled to some other constraint or a set of additional operands. Examples of such secondary operand may include a separate secret key, a globally visible register (such as a timestamp or system version number), the message digest of the code that is accessing the secret key, etc. In embodiments of such a system, this last example could ensure that the secret key may only be accessed by a segment of code that is authorized to use that very same key. Furthermore, if the message digest is encrypted to form a digital signature and if the key that is used to encrypt that message digest is the secret key itself, then a circle of dependencies can be created that can ensure that the only method to access a secret key is by using a code segment that was authored by someone who already knew what that secret key was .

;0082] In this case, the use of a compound key structure allows us to validate the "authority" of a piece of code that requests use of the target unit's secret key before it is allowed to use that key. Recall that the difference between a "layered key" structure and a "compound key" structure is that in certain embodiments, the latter may be evaluated in an atomic fashion, which itself can be accomplished by recursive means. If it is attempted to assemble a similar structure using an iterative approach, as opposed to a recursive structure, then there may be a risk of exposing the intermediate results of the key evaluation process (and thus, potentially exposing the secret key) . This "exposure" may occur when secret keys (or their progenitors) are stored in publically available locations, such as general-purpose registers that are pushed out to main memory when an interrupt occurs (or even directly in memory itself) .

^0083] A potential security breakdown that may be addressed in certain embodiments is the protection of partial results when a security stack operation is interrupted in mid-evaluation and the state of the target unit's processor is then written out to main memory, where it is open to examination by outside observers. In one embodiment, to prevent this memory "exposure" heap pushes are disallowed while the processor is in secured execution mode. If that condition is enforced, then the recursive security protocol cannot be interrupted without losing its current state (since there are no intermediate arguments) . It should be noted that, in embodiments of a recursive security protocol, the entire security protocol has been traversed when the recursion has terminated and the processor is running in secured execution mode, so there may be no more pushes of any arguments onto the heap in any case other than an interruption. Thus, if a compound key evaluation is interrupted at any point, and if heap pushes are disallowed in secured execution mode, then the security system stack traversal may not be restarted in mid-execution (i.e., the calculation must restart from the beginning) . Thus, the recursive security protocol can be used in this manner to prevent any intermediate results from being stored on the system heap (and thus potentially exposed to unauthorized observers) . Of course, in certain embodiments it is possible to disable heap operations during an iterative security system evaluation and thus, effectively requiring that such an interrupted security system operation must be restarted from the beginning. However, such an iterative approach may not enforce all of the conditions that the recursive structure provides, such as the "inside out" execution ordering the protection against "return-based" programming exploits, the ability to add subsequent security layers in a manner that does not alter the calling arguments to the original function as well as the isolation of the intermediate results and the final function output results. The mechanism by which the security system recursion terminates and the processor is allowed to enter secured execution mode will be described in more detail.

Terminating the Recursion

[0084] In one embodiment, the recursion can be signaled to terminate when the message digest of a given code segment matches that supplied with the code segment itself. This methodology may be made more robust against attack if the message digest is calculated by means of a hardware hashing function. A digital signature may also be utilized in certain embodiments. A digital signature mechanism has the potential to provide at least two main attributes: 1) an assurance that the code segment has not been tampered with and 2) ready identification of the code segment author. However, in the case of embodiments where such a digital signature is cached in publicly visible or modifiable locations, additional security may be desired since the digital signature itself may be modified at any time and thus may not necessarily be genuine. Thus, in these types of embodiments, a public-key system may be used to validate the digital signature or a compound key structure (as described above) may be used to assure that the digital signature provided with the code segment in question was created by some party who was in possession of the target unit's secret key. For the latter case, the use of that compound key may also be limited to a single endpoint or some set of endpoints. Additionally, both the public-key as well as the compound key approaches may be utilized in tandem. In that manner, it can be guaranteed that both the code segment is genuine as well as that the code segment is intended for the recipient of the compound digital signature . It is also may be desired, in certain embodiments to validate the security mechanisms on the target unit. While a hardware-generated digital signature for any one segment of the security system on the target device may be utilized, in the case where the security system is recursive, a distinct digital signature can be substantially automatically generated as the security system itself is traversed. As mentioned earlier, once the execution of a recursive security protocol has terminated, the entire calling chain has been exposed. Thus, the innermost (and thus, most recent) portion of the security protocol has access to the entire environment in which it has been invoked, potentially including the calling arguments stored on the stack as well as other environmental variables that are stored in the system heap (or even elsewhere in memory) . This built-in system attestation mechanism is particularly efficient as well as robust against attack since it is evaluated concurrently with the traversal of the security protocol itself. ^0086] In one embodiment, then, a set of conditions that must be in place before the "execution phase" of the security system stack traversal may be specified. In one embodiment, these conditions can be expressed as an "intersection set" of all of the individually required security conditions. That way, when new security risks are discovered additional conditions which account for those risks may easily be put in place. These conditions can ensure that no portion of the security system will be allowed to execute until all of the conditions, both new and old, are met. This "intersection set" of the various security system conditions can be achieved through the use of a compound key structure mechanism as discussed above. If, for example, one of the components of such a compound key structure is based in part on a target unit's secret key, then this secret key can be considered as one of the "Roots-of-Trust" of the entire security system. Furthermore, if a hardware-based timestamp mechanism is utilized as one of the other components of the compound key, then the system can be better protected against replay attacks. There are a number of components in addition to the above that could be employed in certain embodiments to enforce other conditions. Such components include using a hardware-based hash calculation of the message digest of a code block as a part of the compound key in order to prevent the key from being properly evaluated if the code has been tampered with. In one embodiment, another such component may be a digital signature of some selected subset of the calling arguments of the code block to be executed, which could protect against stack overflow style attacks.

^0087] In the case where the code segment has other constraints on its execution, such as time stamp or usage-related limitations, in certain embodiments, further terms can be added to the compound digital signature to ensure that those constraints are also properly enforced. It should be noted that this same mechanism can also be used to force specific multiple iterations through the various security stack layers by enforcing the proper code branching within each layer of the system, based on the correct evaluation of the intermediate security tokens.

^0088] As we have described above, embodiments of a recursive security system are advantageous in certain embodiments where it is desired to ensure that all of the conditions are in place prior to beginning to evaluate a security token. A recursive system with its ability to enforce of inside-out security stack traversal and limits on the visibility of intermediate results can thus provide an enhanced robustness against external attack as well as flexibility when it is desired to add more constraints on the security system evaluation in a minimally disruptive fashion.

^0089] It should be noted here, that the recursive traversal of the security system stack does not necessarily equate to a recursive form for the overall algorithmic flow. Thus, the logical flow of the security system and that of the code threads that are making use of the system's security system may be completely distinct.

^0090] Additionally, in certain embodiments by including a set of functions to specify how the digital signature is modified as a particular code segment is parsed, the flexibility of how the digital signature is used may be increased. For example, if a code segment is allowed to pass the digital signature through the parsing process unchanged after the first iteration, then that code segment can be validated without having to specify in advance how many times the security system cycles through that particular code block. Similarly, it could be specified that the digital signature would be reset to a known "seed" state as a particular code segment is encountered. Thus, simply by supplying a single unique number (which can be stored in the clear) a unique variation of how many times and in what order the various portions of the security system are traversed may be specified. In fact, such a code validation process can be used to implement a variety of useful functions and thus, this technique does not necessarily have to be limited to the exclusive use of the security system itself.

;0091] In the case where the proper digital signature is supplied with generic code (code which may or may not be related to the implementation of security) the manner in which that particular block of code will execute on a specific target unit may be quite specifically controlled. This is a very powerful mechanism that can be used for securely distributing generic code to a set of target devices. This method of distribution may be, for example, effectively applied to free or paid upgrades to applications or to manage the spread of software viruses and other undesirable malware. In this latter embodiment, a recursive security system could be used to validate each and every code block that is a candidate for execution on a target device. Thus, a malware application or even a polymorphic viral attack on previously authenticated code segments could be prevented from executing.

;0092] In order to provide the ability to incorporate hardware dependencies into the security system evaluation, in certain embodiments, a hardware-implemented version number may be utilized as one of the compound components of the digital signature evaluation. If the hardware version number is updated each time the security system is modified (and if that update is secure), then it can be ensured that the security system is matched to the target unit on which it is executing. Note that this is distinct from the time-stamping mechanism described earlier, although the two may be used together in a compound key evaluation to protect against replay attack scenarios or other violations.

^0093] If we use a hardware-derived checksum, such as a JTAG signature, for example, as a part of our compound key structure, then the hardware implementation itself may be authenticated. This kind of mechanism could then ensure that the software and hardware are a matched pair and that the hardware is itself authentic (or has not been tampered with) . Furthermore, if the JTAG signature that is used as a part of the compound key evaluation is not directly observable (for example, it is taken from a point in the scan chain where its state is neither externally visible nor architecturally visible), then the difficulty of mounting a potential attack based on cloning the hardware can be increased many fold. This strategy can be made effective, for example, if the device's individual serial number is included in this scan chain .

^0094] It should be noted here that, from the processor's perspective, in essence, there may be no logical difference between an encrypted code block (which is not directly executable) and an "outdated" code block, which might have possibly been executable at one time, given the correct digital signature matching, but is no longer executable, because its digital signature is no longer valid. This scenario may occur, for example, because the target device's timestamp register has been changed or, alternately, if the target device's hardware has been modified in some unauthorized manner.

^0095] Thus, in the case where a particular code block is replaced with an updated version (even though both are potentially executable) , in one embodiment, a simple but yet effective method for accomplishing this could be to first replace the decryption key pointer for the code block in question with a new pointer that leads to a means for replacing the old version of the code block with the updated version and then to update the target endpoint device's timestamp register. Here, the updated timestamp register value may invalidate all of the previous digital signatures that were generated using the old value and may thus entail that the entire security system be revamped (ideally in a secure manner) to bring it up to date and to replace the old digital signatures (or keys) with new key/digital signature values and updated functionality. This is a very powerful (and potentially very far-reaching) mechanism that can be easily affected with a single change to the value stored in the endpoint device's timestamp register. In this case, care should be taken that the endpoint timestamp register value does not get changed in an insecure or reckless manner. One embodiment of such a forced update scenario may be referred to as logically equivalent to adding a layer of encryption to an otherwise directly executable code block (simply by forcing a single digital signature mismatch) .

Secured Mode and Secured Code Binding

[0096] In an embodiment where the system utilizes one of the architecturally invisible secret keys as described above, the code that makes use of such a key must be designed in a manner such as to prevent these secret keys from being compromised. As mentioned earlier, we can use a secured code binding mechanism to prevent the correct execution of an otherwise legitimate code block on a particular endpoint device when it is used in an unauthorized manner.

[0097] In one embodiment, this secured code binding is based on the requirement that the result of applying a specific kind of hashing function to a candidate code segment must match a specially pre-determined message digest provided with that code segment before that code segment is allowed to execute. This hashing function may be applied after a candidate code segment is called, but before it is allowed to execute. Once this hashing function has been initiated, any writes to that particular memory space comprising the candidate code segment may be either disabled or ignored. If the candidate code segment is located on the same chip as the CPU execution unit, such as in the CPU's instruction cache, then this may be easily implemented. However, in a multiprocessor system, where an I-cache may be shared between more than one processor residing on the same chip, for example, this may not be as straightforward to implement as it may seem on the surface. Another potential method to prevent the code from being modified after the message digest has been computed is to configure the system such that any attempted writes to that memory space that occur after the hashing function has been initiated will cause a processor interrupt. As described above, this may reset the processor's secure execution mode to its default initial "not secure" mode. Another response to such an intrusion might be to cause the secured execution thread to be terminated with an error by initiating a memory segmentation fault, for example.

^0098] If the calculated message digest of a candidate code segment matches the pre-determined message digest received with the candidate code segment, then the candidate code segment is allowed to execute in what is termed "Secured Mode" or "Secured Execution Mode". As described earlier, only code that is operating in Secured Mode can utilize the architecturally invisible secret key. If a particular code segment is not operating in Secured Mode, then the secret key(s) are disabled and any reference to one of them will return some other value (such as zero) .

^0099] In certain embodiments, the hashing function utilized used in calculating the message digest for the candidate code segment may have certain properties. The first property is that the hashing function may be implemented in the hardware of the target unit. This means that this function cannot be completely replaced by some other, (perhaps subverted) version of this original hardware hashing function. It should be noted that this hashing function may be supplemented by a refined version (or even a conditioned outright replacement) of the original function when desired. In one embodiment, the method for replacing the hardware hashing function with a refined version would be substantially similar to the procedure described earlier that is used to insert new layers into the security system, through a recursive definition of the security system's structure. However, it should be noted that in this case, even though the new hashing function could replace the original function for the purposes of all subsequent security system operations, this new hashing function itself may still rely on the original hardware hashing function as the foundation of its root of trust. Thus, the use of the term "conditioned outright replacement". In one embodiment, the original hardware-based root of trust may remain constant. This may be desirable in that it can be very difficult to undermine such a hardware-based security system. However, if a shortcoming in the original hardware hashing function is found after the target device has been deployed in the field; such a shortcoming can potentially be contained by using the original hashing function in a single application, where the calling arguments can be effectively limited . A second property of the hardware hashing function is that it may use the architecturally invisible secret key as its seed value. Thus, even given the same input arguments, the message digest result of such a hardware hashing function can differ from unit to unit. This difference can be exploited in that it could result in a unique message digest for each and every target unit. This property is similar in concept to that of a digital signature, but it does not necessarily require the addition of a separate encryption/decryption block to the hardware hashing function. Since the candidate code segment is then constrained to execute (at least in Secured Mode) only on units where the hardware-produced message digest matches that which is distributed with the candidate code segment a circular dependency has been created. This circular dependency means that only code whose message digest has been created with the secret key of the correct target unit can actually make use of this same secret key. This property substantially impairs the ability for a would-be attacker to create a code segment which would be allowed to execute in secured mode on a target device.

^0101] The mechanism described above is termed "Secured Code Binding", since a code segment can be "bound" to a particular target device (or even to a specific set of endpoint devices) . As mentioned earlier, in the case where an executing block of secured code is interrupted, then the context is not saved and thus, the execution of this code segment must either be abandoned or restarted from the beginning. Also, once the execution of a code segment in secured mode is interrupted, the processor may no longer operate in secured mode and any access to the architecturally invisible secret key(s) may be cut off until the processor returns to secured mode. In certain embodiments, any off-chip store operations may also be controlled, or prohibited while the processor is operating in secured mode.

;0102] As discussed, in certain embodiments, each target unit may have a unique set of architecturally invisible secret keys. In other embodiments, however, some subset of these keys may be common to a number of identical devices. Thus, a particular code segment can be bound to a particular class of endpoint devices with a common subset of keys, while still protecting this set of architecturally invisible secret keys that are held in common between such devices. The combination of the hardware hashing function and one or more architecturally invisible secret keys may thus provide the basis for a chain of trust for a highly effective and robust recursive security protocol.

;0103] Implementation details of the various embodiments will now be further described using the attached figures. Note that, in all of these examples, the term "Digital Bitstream" refers to a generic collection of digital data and thus, this term may be used interchangeably with the words Digital Content, Code Block or Digital Data Set. In the case of the Code Block term, the referenced data can be further assumed to represent an executable file, an executable script or even an algorithmic description or block of pseudocode.

^0104] FIGURE 3 depicts one embodiment of the creation of a compound key for digital content. This compound key 310 may be created by applying encryption engine 320 to a global content key 330 (which may be provided or determined by the owner or author of the digital content) utilizing an endpoint specific hardware key 340, which may be an architecturally invisible secret key (as discussed above) associated with a particular endpoint device (target unit) . The resulting compound key, which is specific both to the particular endpoint and the digital content may be transmitted and stored to, and stored in that clear, on an endpoint device to which the compound key is provided.

^0105] FIGURE 4A depicts one embodiment of the creation of a secured digital data block structure. In this embodiment, the digital data block 410 may not be encrypted, but a digital signature 420 is formed by encrypting the message digest calculated by the Hashing Function 430 from the digital data block with one or more tokens 440 or450. These tokens may be either secret keys or publicly available data, such as a timestamp. Note that the methods employed to encrypt the data passing through the encryption engine (s)

460 and 461 may or may not be identical. In the case where a secret key is used as one of the encryption keys, then it may be more difficult to forge the Digital Signature without knowledge of that secret key value. It is also instructive to note that the order of the encryption operations 460 and

461 are not relevant to the overall security of the result, but the resulting Digital Signature 420 will be different if the order of the operations is changed.

^0106] FIGURE 4B depicts an alternate embodiment of the creation of a secured code block data structure. In this case, a secret key 470 is appended to a digital data block 471 to form an overall message 480. As before, it is not necessarily relevant to the robustness of the resultant security whether this appending action places the secret key 470 before or after the original digital data set 471, but the end result will differ if the order is changed. Note also that, to ensure security, secret key 470 should not be published along with the original digital data set 471. Therefore, the published data set would be restricted to just the digital data set 471 rather than the entire data structure 480. This entire data structure 480 is then run through a hashing function 430, in essentially the same manner as shown before with respect to FIGURE 4A. In this embodiment, however, the final output 490 has many of the characteristics of the digital signature 420 shown in FIGURE 4A, but may not require the use of encryption engine (s) 460 or 461. Thus, the result 490 of this operation will be referred to as a digital signature equivalent. It should be noted that this digital signature equivalent 490 is unique (assuming that the hashing function 430 is properly constructed) for each unique overall data structure 480. Thus, if the secret key 470 is shared only by the author of the digital data set 471 and the consumer of that digital data set (the endpoint device or target device) , then only these two parties should be able to recreate the same correct digital signature equivalent 490. In this case, digital data block 471 may be considered to be "bound" to that secret key 470 (and thus, to the target device) . FIGURE 5A depicts one embodiment of how a security system such as that described herein may be used to cryptographically bind an encrypted data block 510 to a specific decryption engine code block 562 and then to bind that combination 530 to a specific endpoint 's hardware secret key 523 using a digital signature 524 that is calculated by means of hashing function 540 and an encryption engine 561. Note that, in this example, the Public Key 522 (which is constructed by encrypting the message digest 521 of the Decryption Engine Code Block 562 with the Global Content Secret Key 520) is publicly distributed along with the original encrypted data block 510 as a single concatenated data set 530. The act of creating a digital signature 524 from the message digest of the combined message 530 (which comprises the original encrypted data block 510 combined with the Public Key 522) ensures that only the properly authorized endpoint devices are able to decrypt the original encrypted data block 510, and not only that, but that this decryption process can only be accomplished by using the prescribed method of Decryption Engine 562. Note that more constraints can be easily added to the decryption authorization procedure by adding more components to the encryption engine chain 560 (such as a multi-term compound encryption, for example) . FIGURE 5B depicts a variation of the embodiment shown in Figure 5A. In this embodiment, the author of a particular encrypted message 511 can be unambiguously authenticated, but only on a specific endpoint device. Here, the original encrypted data block 511 is cryptographically bound to a specific decryption routine 562, as described above. At this point, it can further be specified that decryption routine 562 is an asymmetric encryption engine, where the input may be the author's secret private key 525, and the output would only be correctly decrypted using the author's public key. The message digest 527 of asymmetric encryption routine 562 is appended along with digital signature 526 to the original encrypted digital data 511 to form an overall data structure 531. Data structure 531 can then be cryptographically bound to a specific endpoint device by using that endpoint device's secret key 523, hashing function 544 and encryption engine 561 to form digital signature 528. With this embodiment, it can be ensured that the encrypted message 511 is genuine and its author is known as well as the fact that the author is in possession of the hardware secret key 523. It should be noted here that the term author as used herein does not necessarily mean the originator of data but may also refer to a licensor, distributor, or another type of entity which wishes to distribute or otherwise communicate such data. One example where this particular chain of trust can be of significant use is in the case where the endpoint device's security system is to be updated using a secured code block (which would be contained in encrypted form in the original data block 511) . FIGURE 6 depicts one embodiment of utilizing a cascaded hashing method in order to control the execution of a secured code block 620. In this case there are two independent code blocks 610, 620. In this example, the first code block (secured code block 610) includes an embedded subroutine call to the second routine (secured code block 620) . Thus, the message digest 630 computed by the hashing function 640 for secured code block 610 is dependent on the reference to secured code block 620 that is contained inside secured code block 610. This message digest 630 then links the two secured code blocks together from the perspective of secured code block 610. Next, the message digest 650 may be constructed for code block 620 using hashing function 670. However, in order to tie the message digest 650 to both secured code block 620 as well as its calling parent routine (in this case, secured code block 610), the original message digest 630 may be used as a seed to the message digest 650 that is computed by hashing function 670. Recall that such a seed value can be implemented in many ways, but one such method is to simply concatenate the original message digest 630 to the second digital data set (for example, in this case secured code block 620) to form an overall message 660. Overall message 660 is then run through hashing function 670 (which can either be identical to hashing function 640 or it can be some other independent hashing function) to form a second message digest 650, which is thus dependent on both secured code block 620 as well as the original message digest 630 (which is itself dependent on both secured code blocks 610 and 620) . As we noted in the discussion of FIGURE 4B, the order of these concatenated elements 620 and 630 may be important to the resulting message digest 650, but in the case of hashing function 670, the order of the elements comprising the overall message 660 may have no substantive impact on the security of hashing function 670.

[0110] This second message digest 650 can then be used in a manner substantially similar to that described above to ensure that secured code block 620 may only be executed correctly if it is called from code block 610. Note that code block 620 may actually be an exact duplicate (or equivalent reference) of code block 610, which would make this an embodiment of a recursive system. The only difference between the two instantiations of the same code block may be the particular message digest that is appended to the code block in order to form the secured code block message digest.

[0111] In this particular embodiment, note that we have not used any secret keys, so this type of structure can be used without specificity to enforce the proper execution order on any endpoint device that is using the same overall security system as described herein. Also, as before, a similar example may be constructed where the execution of either of the secured code blocks 610 or 620 is additionally constrained to a certain specific endpoint device or set of devices by utilizing a compound key-based digital signature structure or its equivalent in place of message digests 630 or 650 respectively.

[0112] FIGURE 7A depicts embodiments of the construction of a secured code block message. In one embodiment, the Encrypted Digital Data Set 711 has been encrypted using an encryption algorithm that is identified by pointer 720. The data structure 730 is formed by a concatenation of Digital Data Set 711 and Pointer 720. The message digest 750 of data structure 730 is generated by hashing function 740. This arrangement allows the cryptographic binding of an encrypted data set and its associated decryption routine. ;0113] In the second embodiment, an additional term is added to the concatenated data structure 731, namely the pointer 721 to the decryption key 760. It should be noted that this key 760 is not necessarily a hardware-based secret key as is depicted in this particular embodiment. In fact, the key 760 that is pointed to by pointer 721 may even be itself a data structure, as will be discussed in the description of FIGURE 7C below. Otherwise, this embodiment is substantially similar to previously described embodiments. Encrypted Digital Data set 711 is created as a result of using encryption engine 770 and one or more keys 760 operating on the original unencrypted data set 710. The message digest 751 is generated using Hashing Function 741 on the concatenated data structure 731. In this case, there is now a mechanism for cryptographically associating the unencrypted data set 710 with both the encryption engine 770 as well as the unique key 760 that can be used to recreate the unencrypted data set 710 from the encrypted data set 711. As with previous embodiments, additional terms may be added to the encryption chain in order to cryptographically bind the entire structure to a specific set of conditions that are to be satisfied on a given endpoint device and its unique secret hardware key 760. It is worth noting that the format and encryption status (i.e., is it encrypted or not) of the digital data sets 710 and 711 may not be relevant to this process, since these details can be inferred from the pointers 720,721.

;0114] With this in mind, FIGURE 7B depicts one possible embodiment for a basic generalized format for a Universal Cryptographic Data Structure that can thus be used in a recursive security system. Embodiments of this structure may be simple and powerful, and can be implemented as a simple linked list of three basic elements; a generic data block 712, a decryption pointer 720 and a decryption key pointer 721. The overall linked list is bundled together in a data structure 732. By using a linked list, it can easily be seen that the ordering of the elements in the concatenated data structure 732 may not be relevant to its function, although it may have an impact on the operation or evaluation of the data structure. Another interesting aspect of using a generic (for example, not predefined) data block structure and a linked list format is that the three elements 712, 720 and 721 also do not necessarily have to be ordered linearly or even contiguously. Thus, one embodiment may comprise an auxiliary data structure 713 that includes some other independent, but perhaps related, data that is stored in conjunction with the overall data structure 732. One embodiment of this concept might be to locate the actual decryption engine code block 771, such as that which is pointed to by pointer 720 inside the auxiliary data structure 713 of FIGURE 7. Another such example could be to store the actual key value that is specified by pointer 721 inside this auxiliary data block.

;0115] In both of these cases, the actual data contained in such auxiliary data blocks may be used in the process of generating a message digest or a digital signature as depicted variously in the embodiment examples presented in FIGURES 4A, 4B, 5A, 5B, 6 and 7A. As has been noted in this disclosure, the ordering of the various data fields stored in a concatenated data set may have an impact on the resulting message digest (or digital signature), if the hashing function is properly designed.

;0116] It will be apparent then, that a similar block structure may also be used to secure the keys that are utilized in certain embodiments. FIGURE 7C depicts one embodiment of such a secured data block 733 which comprises only keys. Here, a data block may comprise a list of device specific keys 714, 715, 716 (or others, as desired) . In this example, any of these keys may have been created using (for example) a secret key of an endpoint device 760, and an endpoint device timestamp register 790, which were encrypted using encryption engines 771 and 772 respectively. As was the case in earlier descriptions of such operations from a perspective of the security system's robustness, there is no requirement that encryption engines 771 and 772 should be distinct or even different and there may no fundamental limit to a certain number of these encryption operations in the encryption chain and, while the order of these operations may matter to the resulting compound keys, there is no requirement for a particular order for the encryption operations. One other feature of note in this case is that the key list pointer element 721 of the concatenated key list data structure 733 may point to yet another concatenated key list data structure 734. Since both of these data structures are of the same universal cryptographical format as depicted in FIGURE 7B, the key list data structure can be formed in a recursive manner. Accordingly, the keys 733 for use in embodiments of such in a recursive security system may be protected in the same manner and using the same structures as any other data to which embodiments of such a security protocol may be applied and similarly, these protected keys may also be decrypted and authenticated on an endpoint device in the same manner as other data secured by embodiments of the systems and methods disclosed herein. Turning now to FIGURE 8, one embodiment of how a compound key may be utilized to decrypt encrypted content is depicted. This decryption operation may occur in "secured mode", as described above. Here, content 810 may be provided to an endpoint device along with a compound key 830 where the content has been initially encrypted using a global content key. The compound key 830 may be created as described above in FIGURE 3. Accordingly, when the encrypted content 810 is received at an endpoint device it may be received with an associated compound key 830. Executing in secured mode, such that the secret key 840 at the device may be accessed, the compound key 830 may be decrypted inside of secured code block 860 to yield the global content key. The global content key may be used, in turn, inside secured code block 860 to decrypt the original encrypted content 810 to yield decrypted content 880.

^0118] FIGURE 9 depicts one embodiment of how a secret key may be utilized to verify that a code block is authorized to run on a particular endpoint device before execution. Candidate code block 910 for execution may be provided to an endpoint device or may be obtained by decrypting encrypted digital content which was received (for example, as depicted earlier in FIGURE 8) . Additionally, the endpoint device may receive a corresponding digital signature 920 corresponding to the candidate code block 910. This digital signature 920 may comprise a message digest created from a code block (for example, by hashing that code block) which has been encrypted using the endpoint device hardware specific secret key 930. Thus, to verify whether the candidate code block 910 may be executed, an authentication operation may be implemented in secured mode whereby the candidate code block 910 is hashed to create a message digest (912) . This message digest 912 can then be encrypted using the endpoint device hardware specific key 930 of the endpoint device (which may be accessible because the verification is occurring in secured mode) to create a digital signature that is compared with the originally supplied digital signature 920 in step 914. If this digital hardware-generated digital signature matches the received digital signature 920 corresponding to the candidate code block 910, then the candidate code block 910 may be considered verified and may be deemed executable, otherwise an exception error may occur (step 916) .

^0119] FIGURE 10 is a block diagram of one embodiment of how a code block may be allowed to run on a particular endpoint processor (under prescribed circumstances) in "secured execution" mode. In this particular case, the pre-computed digital signature 1030 (which can also be referred to as an endpoint-specific decryption key) of the code block 1011 is constructed using the message digest of the code block and encrypting it with one or more of the following: the secret key 1040 of an authorized target endpoint device, the most recent timestamp value 1041 of the authorized target endpoint device, or one or more of any number of constraining conditions as described earlier (not shown in this particular embodiment) .

^0120] It should also be noted that any one of these terms could also be pre-conditioned by applying a masking function to a subset of the term itself. For example, if a number of the least significant bits of the timestamp field are masked off (and thus may not be considered in the calculation of the digital signature) , then the effective granularity of that timestamp value can be easily controlled on a code-segment by code-segment basis without any changes in the hardware. This same principle can be applied to any number of the terms that are used in the calculation of the digital signature in certain embodiments.

;0121] As with the key list data structure depicted in FIGURE 7, the concatenated digital data set 1010 that contains code block 1011 also includes at least one decryption pointer 1012 and at least one decryption key or key list pointer 1013. Also as described before, either one of these may refer to an external data structure (such as the Endpoint Specific Digital Key or Digital Signature 1030) or to an embedded data structure that is wholly contained within the concatenated data set 1010.

;0122] For purpose of describing the embodiment shown in FIGURE 10, it will be assumed that code block 1011 is not encrypted (and is thus potentially executable on the endpoint device target processor) . In this case, the decryption pointer may be null, since there is no further decryption required for the code block 1011 prior to its use. When the code block is not encrypted, as it is in this case, then its corresponding decryption key (pointer) 1013 may point to the associated endpoint or hardware-specific digital signature 1030. Thus, embodiments of data structures and methods such as those depicted earlier in FIGURES 4A, 4B, 5A and 5B may be used to enforce a wide variety of authentication, cryptographic binding or other constraints on the use of an unencrypted data set such as depicted in block 1011.

^0123] In the case where the endpoint specific digital signature

(or decryption key) 1030 points only to the hardware secret key 1040 or alternately, only to the hardware secret key 1040 and the endpoint device timestamp register 1041, then we can determine that the security system related calls have reached the "bottom" of the calling chain and that there will be no further calls to additional layers of the security system in this particular calling chain. Thus, the security system recursion has "terminated" at this point. This recursion termination condition is detected by hardware block 1050, which acts as a "gatekeeper" to selectively allow or deny access to the value of the endpoint specific hardware secret key 1040, and then only as an input component to a cryptographic function that uses output of the hardware hashing function block 1061. In the example shown in FIGURE 10, the hardware specific secret key 1040 and the (message digest) output of hardware hashing function block 1061 are used as input arguments to encryption engines 1062 and 1063.

^0124] Finally, if the output of encryption engine 1063 (which is a digital signature of the original concatenated data structure 1010) then matches the value of digital signature 1030 that was supplied, the "Secured Mode Enabled" hardware bit 1070 is then set. This condition indicates that the candidate code block 1011 that was loaded into the endpoint hardware I-Cache 1020 is now authorized to execute in "Secured" mode. Note that there is no physical change to the candidate code block 1011 that resides in I-cache 1020, nor is there any change to the I-cache 1020 itself. The only thing that has changed at this point is the value of the "Secured Mode Enabled" hardware bit 1070.

^0125] FIGURE 11 depicts one embodiment of a decryption operation which may be performed by a recursive security system. This decryption operation may use a compound key to validate a secured code block that is to be used in the process of decrypting or otherwise manipulating and making use of distributed content. As described above, an endpoint device may receive a data structure 1110 containing encrypted content 1111, a pointer 1112 to a decryption engine 1120 (or the decryption engine itself) and a pointer 1113 to an Endpoint-Specific Compound key 1130 (as discussed earlier with respect to FIGURE 9) . Before it is allowed to execute in secured mode, the compound decryption engine 1140 pointed to, or received, will be authenticated. This authentication may be accomplished by calculating the message digest 1122 of the compound decryption engine 1140 code block using the hashing function 1121 resident in the endpoint device. Note that, although the hashing function 1121 is depicted as being a hardware block in this example, this hashing function 1121 may be, for example, a secured software code block that can be used in place of the endpoint device's built-in hardware hashing function, as was discussed earlier. In this case, however, the software version of the hashing function may still ultimately depend on the built-in hardware hashing function for authentication or authorization purposes, so the eventual root of trust in this case still resides with the endpoint 's built-in hardware hashing function block 1121.

^0126] The message digest 1122 generated by this hashing block 1121 may then be compared in step 1123 against a pre-computed message digest 1150 that corresponds to the decryption engine 1140. This pre-computed message digest 1150 may for example, have been provided to the endpoint device in a secure fashion, or pre-computed and stored on the endpoint device itself. If the message digests match, then the compound decryption engine 1140 may be allowed to execute on the endpoint device (step 1125) . If the message digests are not substantially identical, then an invalid code exception may occur (step 1126) .

\0121] If however, the message digests are substantially identical, the processor of the endpoint device may then enter secured execution mode to execute the code contained in the compound decryption engine 1140. The first part of this compound decryption engine 1141 may be accomplished utilizing the endpoint device's hardware-specific secret key 1131 to generate the global content specific key from the compound key (step 1132) . The second decryption operation 1142 may then use the intermediate result generated by decryption operation 1141 in order to generate the decrypted content 1152 from the encrypted content 1110, using the obtained global content specific key. It should be noted here that while decryption engine 1140 is depicted as a pair of decryption algorithms (1141 and 1142), it may encompass any fewer or greater number of cascaded decryption stages such that the final result of the operation of the various individual components (1141, 1142, etc.) of secured code block 1140 applied to the original encrypted data set 1110 will produce the desired decrypted content result 1152. It should also be noted that any two of these various individual decryption components may be either the same or different algorithms.

;0128] In certain embodiments, it may additionally be desired to layer further security thus, in some embodiments, a compound key may be formed from the pre-computed message digest using an endpoint device specific hardware key and an endpoint specific timestamp value, in substantially the same manner as was depicted earlier with respect to FIGURES 4A, 7C and 10. ;0129] FIGURE 12 depicts one embodiment of the implementation of a recursive security protocol at an endpoint device. Specifically, one embodiment of the use of a set of compound keys for the validation of a secured code block as well as for the actual decryption /or other use of a distributed digital bitstream is depicted. This embodiment is similar to the embodiment depicted in FIGURE 11 in many aspects so only those aspects of the embodiment that are different will be concentrated on with respect to FIGURE 12. A message 1210 comprising encrypted content 1211 may be received including a pointer 1212 to a decryption engine 1240 (or the decryption engine itself), a content specific compound key 1231 (as discussed with respect to FIGURE 8) and an endpoint and time stamp specific compound key 1232. The encrypted content 1211 can be loaded into memory at the endpoint device and the pointer 1212 to decryption engine 1240 may also be loaded into memory (for example, the instruction cache or secured portion of the instruction cache at the endpoint device) . The decryption engine 1240 pointed to will then be authenticated. This authentication may be accomplished by computing the message digest of the encryption engine 1240 using the hashing function 1221 that is resident in the endpoint device, in a substantially similar manner as was described with respect to FIGURE 11.

^0130] In this example, the hardware-generated message digest may then be encrypted using an encryption engine, which may be implemented either in hardware or in software on the endpoint device, and which comprises one or more cascaded compound encryption engine stages 1224, 1225, etc. that operate on the computed message digest and one or more of the hardware specific keys or registers, such as the endpoint device hardware specific secret key 1270 or the value of the endpoint device timestamp register 1260. The resulting compound digital signature 1226 that is generated may correctly correspond to the decryption engine code block 1240 and may also thus be cryptographically bound to the specific endpoint device (by using one or more encryption stages 1224, 1225 and the various secret or public variables or constants such as 1260 and 1270) . As was discussed earlier, this generated digital signature may optionally be further encrypted (using either the same or different encryption engines) and other constraining variables or constants in order to further limit the applicability of this compound digital signature. Also, in the case where it is desired to extend the application of the code block 1240 that is associated with this digital signature 1232 beyond a single unique endpoint unit, for example, one or more of the encryption stages may be optionally limited in order to broaden the field of potential generated compound digital signature matches.

;0131] The generated compound digital signature 1226 may then be compared in step 1223 against the endpoint and time stamp specific compound digital signature 1232 corresponding to that encryption engine 1240 which may have been originally provided to the endpoint device (for example, by a licensing authority as a part of the endpoint code licensing process at a prior point) . Note that the data structure may be identical whether this token 1232 is a digital signature or a key, so the terms "key" and "digital signature" may possibly be used interchangeably in those cases.

;0132] If the compound digital signatures 1226 and 1232 are substantially identical, the processor of the endpoint device may then be allowed to run the code contained in the decryption engine code block 1240 in secured execution mode. When running in secured execution mode, the decryption engine 1240 may then make use of the endpoint device's hardware key 1270 to generate the global content-specific key from the device-specific compound key 1231 using decryption engines 1241 or 1242. The global content-specific key may thus be an intermediate result and accordingly may never be cached or otherwise made visible to any software or hardware entities other than the compound decryption engine code block 1240. This global content-specific key is then used, by way of decryption engine 1243 to generate the final decrypted content 1250 from the original encrypted content 1211.

^0133] If, however, the generated digital signature 1226 does not substantially match the supplied digital signature 1232, then there may be several possible reasons why the mismatch may have occurred, including the case where attempts to make use of decryption engine code block 1240 are made by unauthorized parties. However, another possible reason for a mismatch may be the case where the software for decryption engine has been updated (and the endpoint's timestamp register has likewise been incremented or otherwise changed) . In this case, the two digital signatures may not match and it may be checked in step 1281 if the encryption engine code 1240 is either itself encrypted (for example) or otherwise in need of replacement. Recall that embodiments discussed herein may be effectively utilized for a recursive security protocol, thus in many cases encryption algorithms (which may be pointed or included with encrypted content) may themselves be encrypted, these encrypted encryption algorithms themselves encrypted, etc. As such, if the generated endpoint and time stamp specific compound key 1226 for an encryption algorithm and the received endpoint and time stamp specific compound key 1232 do not match it may be the case that at least one more layer of indirection or encryption has been utilized.

;0134] As mentioned earlier, the concept of adding a layer of encryption to a particular executable code block can be logically equivalent with the act of replacing an outdated version of a particular code block with a newer version of that code block. Accordingly, it can be determined if the decryption engine 1240 is itself either encrypted or otherwise in need of replacement (as indicated in step 1282), as indicated by examining one or more of the following tokens associated with that code block: the endpoint and timestamp specific compound digital signature 1232, the code block's decryption pointer (not shown) or the code block's decryption key pointer (also not shown) . In one example, if the code block's 1240 associated decryption pointer points to a null value, it would indicate that the encryption engine 1240 is not encrypted or otherwise outdated and thus, an exception error may result (step 1283), since the generated digital signature 1226 and the supplied digital signature 1232 are not substantially identical but there may be no other recourse for replacing the code block with a different version that may possibly produce the correct digital signature. If, however, the decryption engine code block's 1240 decryption pointer points to another code block; either another (possibly updated) encryption engine (not shown) or some other code block, then this new code block may be loaded and the authentication steps above applied to this next encryption engine (in other words, another layer of recursion may be introduced) . This recursive execution mechanism may continue until it is determined that a match between an generated endpoint and time stamp specific compound digital signature 1226 and the supplied endpoint and time stamp specific compound digital signature 1232 occurs (at step 1227) or that it is determined that there is no match and the decryption engine 1240 itself is not encrypted, at which point an exception error may occur (step 1283) . If it is determined that a generated endpoint and time stamp specific compound digital signature 1226 and the supplied endpoint and time stamp specific compound digital signature 1232 match, then the recursion is terminated and may be unwound. This may entail the authentication and execution of each of the code blocks that were encountered and saved on the stack during the initial forward pass through the overall recursive calling chain. It should be noted that some or perhaps even all of these code blocks may not necessarily be encryption or decryption engines. In any case, each of these code blocks may be authenticated while the processor of the target endpoint device operates in secured execution mode.

^0136] This execution may be better explained with reference to FIGURE 13, which depicts one embodiment of a decryption operation that may be performed by a recursive security system. As described, an endpoint device may receive a message 1310 that may contain, among other things, encrypted content 1312 along with a content specific compound key 1316 (as discussed with respect to FIGURE 8), a pointer 1313 to an decryption engine data structure 1320 or the decryption engine itself, if it is embedded in the original message 1310 and a key list pointer 1314, that may point to a key or key list data structure 1318. As discussed earlier, this data structure may include a key or key list 1316 or a digital signature 1317. The decryption engine data structure 1320 may, in turn, contain an encrypted code block 1321, a subsequent decryption pointer 1322 associated with the encrypted (or alternately, obsolete and in need of replacement) decryption code block 1321 and an associated decryption key list pointer 1323. The subsequent decryption pointer 1322 may point to a final decryption code block data structure 1330, which has structure substantially similar to that of decryption code block data structure 1320, except that, in the case of data structure 1330, the decryption code block 1331 is not itself in encrypted form.

^0137] The operation of the embodiment as depicted in FIGURE 13 can be explained as follows. Encrypted Content data structure 1310 is loaded into the endpoint processor's memory space in anticipation of decrypting the encrypted content 1312 contained within. Since the data structure 1310 contains a decryption pointer 1313, the associated decryption engine code block data structure 1320 is located and read into memory. Since this subsequent data structure 1320 also contains a decryption pointer 1322the decryption engine code block data structure 1330 associated with pointer 1322 is then located and loaded into memory. For data structure 1330, the embedded decryption pointer 1332 in this example is determined to be a null pointer, so the target endpoint device's security system is thus able to determine that the current decryption recursion chain has terminated (as discussed, for example, in FIGURE 10) and thus, the decryption engine 1331 that was just read into memory as a part of data structure 1330 may contain an unencrypted (and thus potentially executable) code block.

^0138] Since it can be determined that digital content 1331 is a code block and not data (by the manner in which it was called) , then it can also be determined that the key list data structure 1338 that is pointed to by the decryption key list pointer 1333 (which was read into memory as a part of data structure 1330) may contain a digital signature 1337 (in addition to a compound key 1336) . It should also be noted that the key list data structures in this example (1318, 1328 and 1338) may be implemented using the universal cryptographic data structure as depicted earlier with respect to FIGURE 7B . Thus, the order of the arguments in these key list data structures 1318, 1328 and 1338 is not necessarily fixed and they may therefore be interpreted at runtime as the data structures themselves are traversed. In fact, it should be noted that these key list data structures (1318, 1328 and 1338) may themselves include references to further decryption or subsequent interpretation by incorporating supplementary decryption pointers and key list pointers within any or all of these key list data structures (1318, 1328 and 1338) themselves, although this particular option was not pictured in the embodiment of FIGURE 13 for the sake of simplicity.

^0139] It can further be determined that at least one of the key pointers 1336 in the key list data structure 1338 corresponds to a reference to the endpoint's hardware secret key 1392. This reference to the endpoint's hardware secret key 1392 may be accomplished either explicitly by pointing to an appropriately reserved memory location (a location that may be specified in the processor's architecture, even though it may never be directly read by the processor and thus, not directly architecturally visible) or implicitly, by using some specially reserved value for the pointer. In either case, this reference may implemented using various means, but an example one such embodiment may be to equate the value of "0" (as distinct from the value of "null") in the key list data structure to a reference to the endpoint's hardware secret key 1392. The fact that at least one part of the key list data structure refers to the endpoint's hardware secret key 1392 may further indicate that the decryption engine code block 1331 is intended to run in secured execution mode on the target endpoint device's processor. Thus, the output of hardware-based digital signature generator block 1390 is compared with the value stored in data structure 1337. In the case where the two values substantially match, then the processor is allowed to enter secured execution mode.

[0140] It should be noted here that hardware-based digital signature generator block 1390 (the details of one embodiment of which will be presented more comprehensively with respect to FIGURE 15) may, in one embodiment, comprise one or more software-based elements, but may also incorporate at least one hardware-based security component, either directly or indirectly, as discussed earlier. That hardware component is the hardware-based hashing function that has been referenced in many of the earlier descriptions contained herein, and which comprises the overall target endpoint unit's security system root of trust.

[0141] At this point, then, decryption engine code block 1331 is allowed to run in secured execution mode, which allows the endpoint processor to potentially make use of the endpoint's hardware device-specific secret key 1392 as a part of a security-related computation (as has been described earlier herein) . In the case where the processor was not operating in secured execution mode, then the value of secret key 1392 would not be available for use in such a security related computation. This concept is depicted with respect to FIGURE 13 as hardware access control block 1343, which will only allow the value of secret key 1392 to pass through to subsequent use (for example in decryption engine code block 1331) if the processor is running in secured execution mode. In addition, it can be seen that one of the input parameters to hardware access control block 1343 is the output of access control block 1341. In this manner, the state of hardware access control block 1343 (which is effectively the "secured execution mode enabled" indicator for decryption code block 1321) is dependent on the fact that decryption code block 1331 was also running in secured execution mode. This may be indicated by the state of the "secured execution mode enabled" indicator for decryption code block 1331 (for example, the output of hardware access control block 1341) . This dependency constrains the ability of decryption engine code block 1321 to be able to run in secured execution mode only if decryption code block 1331 was also running in secured execution mode. In an essentially identical manner, the output of hardware access control block 1343 is used as one of the inputs to hardware access control block 1345, which is the "secured execution mode enabled" indicator for decryption code block 1311. Thus the mechanism that allows the "secured execution mode enabled" bit to be propagated back up the calling chain in the reverse direction, for the purposes of authorizing the preceding parent code blocks to run in secured execution mode only if they are both authenticated properly (as will be explained in more detail with respect to FIGURE 14) and if they are supplied with authentic decryption results from properly authorized portions of the security chain from lower down in the recursive calling chain. Note that, as described earlier, any one of several conditions may cause any of the "secured execution mode enabled" bits to be reset to a "non-secured" default state (and thus, potentially require the entire security chain to be restarted) . Such conditions may include a processor interrupt or a subsequent digital signature comparison mismatch. Although these hardware access control blocks 1341, 1343 and 1345 are depicted as separate entities for purposes of clarity in FIGURE 13, it can be seen that they may, in fact, be embodied in a single hardware unit (such as that described with respect to FIGURE 15), whose output is thus fed back as one of its own input terms. Ultimately, the output of the highest-level or final "secured execution mode enabled" bit in the overall chain (in this embodiment, the output of hardware access control block 1345) may be used as part of a control mechanism to enable or disable some externally-visible output for the target device (such as an audio or video output enable, for example) . The action of decryption engine code block 1331 in step 1370 is to replace or otherwise supplement the data set stored in the decryption engine code block portion 1321 of data structure 1320 with an updated and/or properly executable version of the original data. This action may be accomplished utilizing the original data that was stored in 1321 and decrypting it with one or more decryption keys that are stored in or pointed to by key list data structure 1328. Alternately, as was discussed earlier, the action 1370 of decryption engine code block 1331 may be to either replace the decryption code block 1321 with an updated version or even to execute directly in place of decryption engine code block 1321. In any case, decryption engine code block 1331 may first operate using various input data, including (in this embodiment) the value contained in the target endpoint device's timestamp register 1394, the target endpoint device's hardware-specific secret key 1392 (as modified by passage through hardware access control 1342) and endpoint and timestamp-specific compound digital key 1326. In the case where decryption engine code block 1331 is then subsequently operating as a direct replacement of decryption engine code block 1321, it may then utilize a second set of input data (for example in this embodiment, the value contained in the target endpoint device's timestamp register 1394, the target endpoint device's hardware-specific secret key 1392 (as modified by passage through hardware access control 1344) and endpoint and timestamp-specific compound digital key 1316. A further action of the updated decryption engine code block 1321 in step 1371 is to replace or otherwise interpret the original encrypted content data 1312 in order to produce the desired output data 1380. This action may be accomplished utilizing the original data that was stored in 1312 and decrypting it with one or more decryption keys that are stored in or pointed to by key list data structure 1318. Since the actions of both decryption engine code blocks 1321 and 1331 are similar in nature, is should be evident that any of the options detailed earlier in the description of the operation of decryption engine code block 1331 are equally applicable to the operation of the updated version of decryption engine code block 1321. Also, in the case of the operation of decryption engine code block 1321, it should be noted that in some embodiments, the associated hardware access control block 1344 is distinct from hardware access control block 1342. The actions of these two hardware access control blocks 1342 and 1344, however are similar in nature in that their purpose is to enable or disable the use of the target endpoint device's hardware-specific secret key 1392 by their associated decryption engines 1331 or 1321 respectively and thus in other embodiments may not be distinct . ;0145] Finally in all of the operations depicted in the embodiment of FIGURE 13 described above, the use of the target endpoint device's timestamp register 1394 is essentially similar to those examples described earlier herein for other embodiments. Thus, it follows that the value stored in register 1394 may be used as an additional element in the generation of the various compound keys and/or digital signatures that are employed in the different authorization and decryption operations described in the particular embodiment depicted in FIGURE 13.

;0146] FIGURE 14 depicts one embodiment of how a recursive calling chain may be traversed and terminated and how a processor may be allowed to enter into secured execution mode using a message-digest based authentication of one or more embedded code blocks. In this embodiment, the operation of two candidate code blocks 1412 and 1422 may be explained, both of which may be contained within universal cryptographic data structures (1411 and 1421 respectively) as was discussed earlier with respect to FIGURE 7B.

;0147] Notice that the code block data structure 1421 is represented twice in FIGURE 14. This duplication was illustrated to represent separate iterations for the sake of clarity, although it should be noted that this is exactly the same data structure in both instances. One difference that may be noticed, however, is in the key list data structures 1428 and 1438 that are pointed to by the instances of key list pointer 1421. Even though the value of key list pointer 1421 does not vary between the two instances shown in this figure, the values contained within (or pointed to by) key list data structure 1428 may change between the two iterations, and so this detail is indicated by renumbering the data structure (and its various components) from 1426, 1427 and 1428 to 1436, 1437 and 1438 respectively. The fact that this structure is renumbered does not necessarily indicate that the actual location of the data structure has moved, just that its contents may have changed. Likewise, the hardware hashing function 1480 is also depicted multiple times in this figure, for the same reason of increased clarity. Finally, note that neither of the two candidate code blocks 1412 or 1422 are encrypted, and so their associated decryption pointers 1416, 1426 and 1436 may be all null pointers.

^0148] In this embodiment, a call to candidate code block 1412 may be initiated. In the same manner as has been described previously, the code block data structure 1411 may be read into memory and its message digest 1441 may be computed by means of hashing function 1480 (which may be realized either wholly or partially in hardware, as was described previously) . However, in this embodiment, the hashing function may be given an initial seed value 1440 (which may, or may not, be set to all zeroes) . As was discussed earlier, this hashing function seed value feature may be implemented using one of a number of methods, but in this embodiment the seed value 1440 is known and the method by which it affects the message digest output 1441 of hashing function block 1480 is both repeatable and deterministic.

;0149] Once the result 1441 of the hashing function is generated, the processor can begin executing the code contained in code block 1412. In the embodiment shown in FIGURE 14, where both the decryption pointer 1413 and the values of both of the locations 1416 and 1417 (which are contained inside key list data structure 1418) that is pointed to by the key list pointer 1414 are all null, then code block 1412 may not be designed to run in secured execution mode and therefore does not require the use of any of the target endpoint unit's security hardware features. The processor thus begins to execute the instructions contained within code block 1412 until it reaches an embedded subroutine call that points to code block 1422.

^0150] At that point, code block data structure 1421 is loaded into memory and the process of generating the next message digest 1442 is repeated by the hashing function block 1480. In this particular instance, however, the hashing function seed value may no longer be the initial seed value 1440, but rather the previously generated result 1441. Thus, the value of message digest 1442 can be seen to be deterministically dependent on the message digest of both code blocks 1411 and 1421. However, as in the previous case, the values of decryption pointer 1423 and those contained in the key list data structure 1428 pointed to by key list pointer 1424 may still be null, so the processor continues on in non-secured execution mode as before.

;0151] At some later point, the processor encounters another subroutine call, but in this example, code block 1422 contains a recursive call (for example, a subroutine call to itself) . It should be noted that in certain embodiments, such a recursive calling structure is illustrative only and correct operation of the target endpoint device's security system may be achieved by other means, for example, be ensuring that any calls to the security system are contained within a single layer of code. However, as soon as multiple levels of the security system are to be traversed, then the recursive calling form may be relatively more secure, as detailed earlier, and may be effectively utilized to implement a security system in conjunction with the depicted embodiment .

;0152] In any case, when the processor encounters the subroutine call embedded inside code block 1422 (which references itself), then the code block data structure 1421 is once again loaded into memory (for example, in most contemporary systems, the data structure 1421 may be loaded to a different physical location the second time it is fetched) and the hashing function 1480 calculates the new message digest 1443. Notice that this new message digest 1443 is dependent on the initial message digest seed value 1440, message digest 1441 (of code block 1412) as well as the message digest of two separate iterations of code block 1422.

^0153] Also note that this second time, the key list pointer points to a new data structure 1438, that contains a non-null digital signature value 1437. This non-null value is an indicator to the security system that this iteration of code block 1422 contains a reference to the target endpoint hardware specific security system. Thus, in this embodiment, in order for such a reference to operate properly, the processor must enter secured execution mode at some point. Thus, the digital signature 1443 generated when code block data structure 1421 was most recently loaded into memory may then be compared to the digital signature 1437 contained within key list data structure 1438. In the case where the two values are found to be substantively similar in step 1491, then the target endpoint processor is allowed to enter secured execution mode. If, however, the two digital signature values 1437 and 1443 do not match (and given that digital signature 1437 is known to be non-null at this point), then the result of step 1492 is to direct the processor to execute the appropriate exception error handler portion 1470 of the security system.

;0154] FIGURE 15 depicts one embodiment of how a digital signature generator block 1560 may be implemented in hardware in order to support the features detailed above. The embodiment depicted in FIGURE 15 shows a hardware implementation of functionality similar to the functionality of the digital signature generator block depicted in FIGURE 10 and which will support the functional features that were described in operational detail, for example, with respect to FIGURES 11, 12, 13 and 14.

^0155] The hashing function seed register 1510 may comprise a similar functionality as that labeled as block 1440 of FIGURE 14 and it may be operable to hold the initial value that is fed to hashing function block 1561. The output of hashing function block 1561 is fed as one of the inputs to the first stage 1562 of a compound encryption engine. The other input to encryption engine 1562 is the output of the target endpoint device's timestamp register 1541. The resulting output of the first stage encryption engine 1562 is then supplied as one of the inputs to the second stage encryption engine 1563. The other input to second stage encryption engine 1563 is the output of secured execution mode access point 1566.

^0156] Access point 1566 is operable to pass through the value of the target endpoint 's hardware specific secret key 1540 only when the target endpoint device is either running in secured execution mode or when the "recursion terminated" condition is detected, as was detailed earlier with respect to FIGURE 14. The resulting output value from second stage encryption engine 1563 is then stored in digital signature register 1564, for use in comparing this generated digital signature with the digital signatures that are supplied with the candidate code blocks (as referenced, for example, in the descriptions of FIGURES 9, 10, 11, 12 13 and 14) .

;0157] The output of digital signature register 1564 is gated by access point 1565, whose action is to pass through the value of digital signature register 1564 when the target endpoint device is not running in secured execution mode. The output of access point 1565 is then fed back to the input of the hashing function seed register 1510 in order to create the cascaded message digest feature that was detailed in the description with respect to FIGURE 14. When the target endpoint device is running in secured execution mode, then the input to the hashing function seed register 1510 is not dependent on the value of digital signature register 1564 and can thus either be set to some initial value (as detailed in the description with respect to FIGURE 14) or by some other means (for example, such as a processor write to a specific memory location) .

^0158] In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth. Accordingly, the specification, appendices and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of invention, notwithstanding the use of any restrictive terms.

^0159] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component (s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

Claims

WHAT IS CLAIMED IS:

1. A method for controlling the execution of code on an endpoint device comprising: receiving a first bitstream at a device; obtaining a first key corresponding to the first bitsteam, wherein the first key was created by hashing the first bitstream and encrypting the hashed first bitstream; authenticating the first bitstream using hardware at the device operable to access a first secret key specific to the device which is stored in the hardware of the device and is accessible when the device is executing in secure mode, wherein authenticating the first bitstream comprises: hashing the first bitstream; generating a second key by encrypting the hashed first bitstream, wherein the encryption of the hashed first bitstream is done in the hardware of the device and the hardware attempts to access the first secret key specific to the device and uses the result of the access in the encryption; comparing the generated second key with the first key; and if the second key and the first key match, executing the first bitstream on the processor in secured mode.

2. The method of claim 1, wherein the first bitstream comprises a first encryption engine, and executing the first bitstream comprises decrypting encrypted digital content associated with the first bitstream using the first encryption engine and the first secret key specific to the device and the execution of the first bitstream is done in secure mode.

3. The method of claim 2, wherein if the second key and the first key do not match: determining if the first bitstream is encrypted and if the first bitstream is encrypted: obtaining a second bitstream; authenticating the second bitstream using the hardware at the device operable to access the first secret key specific to the device which is stored in the hardware, wherein authenticating the second bitstream comprises: obtaining a third key corresponding to the second bitsteam, wherein the third key was created by hashing the second bitstream and encrypting the hashed second bitstream; hashing the second bitstream; generating a fourth key by encrypting the hashed second bitstream, wherein the encryption of the hashed second bitstream is done in the hardware of the device and the hardware attempts to access the first secret key specific to the device and uses the result of this access in the encryption; comparing the generated fourth key with the third key; and if the fourth key and the third key match, executing the second bitstream on the processor in secured mode.

4. The method of claim 3, wherein the hashing of the second bitstream utilizes the second key generated from the first bitstream as a seed value.

5. The method of claim 3, wherein the second bitstream comprises a second encryption engine, and executing the second bitstream comprises decrypting both the first bitstream and the encrypted digital content with the second encryption engine using the first secret key specific to the device, wherein the execution of the second bitstream is done in secure mode.

6. The method of claim 5, wherein the authentication of the second bitstream and execution of the second bitstream is done before the execution of the first bitstream.

7. The method of claim 6, further comprising authenticating the first bitstream after the execution of the second bitstream and before the execution of the first bitstream.

8. The method of claim 7, wherein the first bitstream, second bitstream, encrypted digital content, first key and third key were received in a message, the message generated by: encrypting the digital content with the first encryption engine of the first bitstream; generating the first key by hashing the first bitstream and encrypting the hashed first bit stream with the first secret key specific to the device; associating the first key, first bitstream and encrypted digital content; encrypting the associated the first key, first bitstream and encrypted digital content with the second encryption engine of the second bitstream; generating the third key by hashing the second bitstream and encrypting the hashed second bit stream with the first secret key specific to the device; associating the first decryption algorithm with the first encrypted bitstream; and associating the third key, second bitstream and encrypted associated first key, first bitstream and encrypted digital content.

9. A system for controlling the execution of code, comprising: a device, comprising: a processor; first hardware for storing a first secret key; second hardware operable to: access the first secret key when the processor is executing in secured mode, and implement an encryption algorithm using the first secret key a computer readable storage media comprising instructions executable by the processor for: receiving a first bitstream at the device; obtaining a first key corresponding to the first bitsteam, wherein the first key was created by hashing the first bitstream and encrypting the hashed first bitstream; authenticating the first bitstream using the second hardware at the device wherein authenticating the first bitstream comprises: hashing the first bitstream; generating a second key by encrypting the hashed first bitstream, wherein the encryption of the hashed first bitstream is done in the second hardware of the device and the second hardware attempts to access the first secret key specific to the device and uses the result of the access in the encryption; comparing the generated second key with the first key; and if the second key and the first key match, executing the first bitstream on the processor in secured mode.

10. The system of claim 9, wherein the first bitstream comprises a first encryption engine, and executing the first bitstream comprises decrypting encrypted digital content associated with the first bitstream using the first encryption engine and the first secret key specific to the device and the execution of the first bitstream is done in secure mode.

11. The system of claim 10, wherein if the second key and the first key do not match the instructions are further operable for: determining if the first bitstream is encrypted and if the first bitstream is encrypted: obtaining a second bitstream; authenticating the second bitstream using the second hardware at the device operable to access the first secret key specific to the device which is stored in the first hardware, wherein authenticating the second bitstream comprises: obtaining a third key corresponding to the second bitsteam, wherein the third key was created by hashing the second bitstream and encrypting the hashed second bitstream; hashing the second bitstream; generating a fourth key by encrypting the hashed second bitstream, wherein the encryption of the hashed second bitstream is done in the second hardware of the device and the second hardware attempts to access the first secret key specific to the device and uses the result of this access in the encryption; comparing the generated fourth key with the third key; and if the fourth key and the third key match, executing the second bitstream on the processor in secured mode.

12. The system of claim 11, wherein the hashing of the second bitstream utilizes the second key generated from the first bitstream as a seed value.

13. The system of claim 11, wherein the second bitstream comprises a second encryption engine, and executing the second bitstream comprises decrypting both the first bitstream and the encrypted digital content with the second encryption engine using the first secret key specific to the device, wherein the execution of the second bitstream is done in secure mode.

14. The system of claim 13, wherein the authentication of the second bitstream and execution of the second bitstream is done before the execution of the first bitstream.

15. The system of claim 14, wherein the instructions are operable for authenticating the first bitstream after the execution of the second bitstream and before the execution of the first bitstream.

16. The system of claim 15, wherein the first bitstream, second bitstream, encrypted digital content, first key and third key were received in a message, the message generated by: encrypting the digital content with the first encryption engine of the first bitstream; generating the first key by hashing the first bitstream and encrypting the hashed first bit stream with the first secret key specific to the device; associating the first key, first bitstream and encrypted digital content; encrypting the associated the first key, first bitstream and encrypted digital content with the second encryption engine of the second bitstream; generating the third key by hashing the second bitstream and encrypting the hashed second bit stream with the first secret key specific to the device; associating the first decryption algorithm with the first encrypted bitstream; and associating the third key, second bitstream and encrypted associated first key, first bitstream and encrypted digital content,

17. A computer readable media, comprising instructions executable by a processor for controlling the execution of code on an endpoint device, including instructions executable for: receiving a first bitstream at a device; obtaining a first key corresponding to the first bitsteam, wherein the first key was created by hashing the first bitstream and encrypting the hashed first bitstream; authenticating the first bitstream using hardware at the device operable to access a first secret key specific to the device which is stored in the hardware of the device and is accessible when the device is executing in secure mode, wherein authenticating the first bitstream comprises: hashing the first bitstream; generating a second key by encrypting the hashed first bitstream, wherein the encryption of the hashed first bitstream is done in the hardware of the device and the hardware attempts to access the first secret key specific to the device and uses the result of the access in the encryption; comparing the generated second key with the first key; and if the second key and the first key match, executing the first bitstream on the processor in secured mode.

18. The method of claim 17, wherein the first bitstream comprises a first encryption engine, and executing the first bitstream comprises decrypting encrypted digital content associated with the first bitstream using the first encryption engine and the first secret key specific to the device and the execution of the first bitstream is done in secure mode.

19. The computer readable media of claim 18, wherein if the second key and the first key do not match the instructions are further operable for: determining if the first bitstream is encrypted and if the first bitstream is encrypted: obtaining a second bitstream; authenticating the second bitstream using the hardware at the device operable to access the first secret key specific to the device which is stored in the hardware, wherein authenticating the second bitstream comprises: obtaining a third key corresponding to the second bitsteam, wherein the third key was created by hashing the second bitstream and encrypting the hashed second bitstream; hashing the second bitstream; generating a fourth key by encrypting the hashed second bitstream, wherein the encryption of the hashed second bitstream is done in the hardware of the device and the hardware attempts to access the first secret key specific to the device and uses the result of this access in the encryption; comparing the generated fourth key with the third key; and if the fourth key and the third key match, executing the second bitstream on the processor in secured mode.

20. The computer readable media of claim 19, wherein the hashing of the second bitstream utilizes the second key generated from the first bitstream as a seed value.

21. The computer readable media of claim 19, wherein the second bitstream comprises a second encryption engine, and executing the second bitstream comprises decrypting both the first bitstream and the encrypted digital content with the second encryption engine using the first secret key specific to the device, wherein the execution of the second bitstream is done in secure mode.

22. The computer readable media of claim 21, wherein the authentication of the second bitstream and execution of the second bitstream is done before the execution of the first bitstream.

23. The computer readable media of claim 22, further comprising authenticating the first bitstream after the execution of the second bitstream and before the execution of the first bitstream.

24. The computer readable media of claim 23, wherein the first bitstream, second bitstream, encrypted digital content, first key and third key were received in a message, the message generated by: encrypting the digital content with the first encryption engine of the first bitstream; generating the first key by hashing the first bitstream and encrypting the hashed first bit stream with the first secret key specific to the device; associating the first key, first bitstream and encrypted digital content; encrypting the associated the first key, first bitstream and encrypted digital content with the second encryption engine of the second bitstream; generating the third key by hashing the second bitstream and encrypting the hashed second bit stream with the first secret key specific to the device; associating the first decryption algorithm with the first encrypted bitstream; and associating the third key, second bitstream and encrypted associated first key, first bitstream and encrypted digital content.

APPENDIX A

;0001] The invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.

^0002] Attention is now directed to systems and methods for security protocols intended to protect digital content. These security protocols are useable for any digital content, and can also support the concept of identity tracing that is normally associated with a traditional watermarking scheme without requiring that the actual digital content be altered. Since these protocols are based on the premise that all digital bit streams are equal, it can even be used in a recursive fashion in order to control access to updates to the protocol itself. In other words, the protocol makes no distinction between types of digital data, whether the data be media streams to be protected, the executable code required to play those streams, the encrypted executable code required to play those streams, the executable code required to decrypt the encrypted code required to play those streams, the keys to be used along with the decryption code, etc., etc. The digital nature of these data is all that is important to the protocol. Thus, since the nature and/or use of the digital data are of no concern to the security protocol, the protocol is capable of protecting itself.

^0003] This capability means that the security protocol can be updated (to fix recently discovered security holes, for example) without requiring any changes to the hardware on which it is running, even during execution. The "older" security system is "subsumed" as a part of the newer security system (i.e., you never have to strip the old protection "wrapper" away in order to add a new, potentially more secure, level of protection to the entire system) . Thus, the entire system is encapsulated in the latest, most secure encryption and/or access control system. Not only may new keys be added, but entirely new security and/or encryption algorithms can be added on top of existing systems as well.

;0004] This flexibility allows the protocol to support a number of business models, including Time-limited Rental, Pay-per- View, Multiple Versioning, Machine-dependent License Revocation and Permanent Transfer of Ownership from one user to another.

^0005] Though a copyrighted software application is utilized in an exemplary embodiment, it will be understood by those skilled in the art that the same methods and systems can be used to provide security to any bit stream whatsoever, including text, video and audio data, source and object code, etc.

^0006] The basic functions which embodiments of the security protocol are designed to provide include (but are not limited to) the following:

Fair Use ("Time shifting", "Space Shifting" and archival backups)

Incremental Upgrades

Temporary Transfer of Ownership Permanent Transfer of Ownership

Time-Limited Access

Usage-limited Access (Number of Times used)

Device-specific License Revocation

Data or Stream-specific License Revocation

^0007] For many security systems, one of the primary mechanisms for protection of the intellectual property contained in a copyrighted work is simple access control. However, if such a mechanism is ever bypassed, then the protection afforded by even the most sophisticated access control mechanism is of very little value. This is not to say that access control is a useless mechanism, but simply that it is not a total security system in and of itself. The fact that a number of copyrighted media streams are freely available for public consumption on the internet is testimony to the fact that such security systems can almost always be bypassed. This kind of access control also makes it more difficult to establish a mechanism to make backup copies of legally purchased copyrighted works, which is a necessity if the original is ever in danger of being destroyed. Thus, the security protocol described herein does not require any sort of access control system in order to make it useful.

^0008] The security protocols described concentrate on controlling the expression of the copyrighted work, not on the digital data that make up the work itself. As such, the protocol makes no distinction between digital data that is used to encapsulate a copyrighted work or other digital data that is used to describe how that work is to be interpreted. As a result, the protocol can even be used to encapsulate other security protocols.

Basic Operational Description:

;0009] Embodiments of the security protocol are designed to enable the author of a piece of software to have a high degree of confidence that their code is protected from disassembly by those who would like to copy or otherwise misappropriate its algorithm. They are also designed to protect this code from modification by those who would attempt to alter its functionality. One of the methods by which these primary characteristics can be implemented in an otherwise general purpose computing system is discussed in a following section. An additional property, which occurs as a byproduct of these two primary functions, is the ability to control the conditions under which the software can be run (i.e., when and how and on which machine or machines the code is allowed to be executed) . The first of these functions may be accomplished by adding a tamper-resistant timer element to the system. Others are accomplished by means of implementing a secure data structure, which is used to indicate the desired conditions, which must be met in order to execute the code block in question. Since this data structure is not hardware specific, it can be used in a variety of ways and is able to be modified by updating the software that is used to interpret it. Hardware specific features utilized to implement the protocol more efficiently are discussed, and examples of how these features can be put to use in order to support the protocol are given. Finally, we will show how the protocol can be used to protect a copyrighted work.

Embodiments of the security protocol depend on the ability to encrypt a digital bitstream in such as way as to only allow it to be decrypted by its intended recipient. This is a wellunderstood problem and is the basis of a large number of industry-standard encryption algorithms. However, there are two additional factors which should be considered for use with embodiments of the security protocol: the fact that it is helpful if the core of the protocol is able to be fit in the (relatively) small confines of a typical on-chip Instruction Cache (I-Cache) and the fact that it be capable of running in a semi-autonomous manner. In other words, it is useful if the protocol is small and does not require the use of a central security server for normal day-to-day operation.

Hardware :

;0011] Turning now to FIGURE 1, an example overall block diagram of a device that is capable of executing this security protocol is shown. Elements of the security protocol system may include a set of hardware blocks, which implement the protocol in a secure manner on a protocol engine (also known as a "target unit") 100. These blocks are not required to be cast in hardware in order for the protocol to operate correctly, however, a device that includes all of the hardware elements described below will be capable of implementing the protocol with a minimum of overhead.

^0012] The first of these hardware blocks is a real-time clock 102. This is a free-running timer that is capable of being set or reset by a secure interaction with a central server. Although this is not a completely essential block, since the time may be established by conducting a query of a secure time standard, it would be more convenient to have this function be on-chip. This has to do with time-dependent software licenses and examples of such will be given in a later section of this document.

^0013] Another hardware element is a block of memory 110 where code that is to be executed can be stored on-chip. This is typically known as an Instruction Cache (I-Cache), but in some embodiments an important characteristic of portions of this I-Cache 110 is that the data contained within certain blocks be readable only by CPU execution unit 120. In other words, this particular block of I-Cache memory 130 is execute-only and may not be read from nor written to by any software. We will refer to this special section of I-Cache as the "secured code block" 130. The manner by which code to be executed is actually deposited in this secured I-Cache block 130 may be by way of another hardware elements.

;0014] Additionally, there are other categories of possible "enhancements", which can be used to accelerate the operation of a secure code block. One of these is the ability to designate a (sub) set of CPU registers 140 which are either only accessible while the CPU 120 is executing secure code and/or which are cleared upon completion of execution of the secure code block (or if, for some reason the execution unit jumps to any section of code which is located in the non-secure or "normal" I-Cache. Even though there may seem to be no possibility of the CPU 120 executing a mixture of "secured" code and "unsecured code", one must always consider what can happen in the process of switching contexts when jumping into interrupt routines, and where the CPU 120 context is stored (most CPU's store the context in main memory, where it is potentially subject to discovery at a later point by an unsecured code block) .

^0015] Another possibility (other than requiring the author of the secured code block to explicitly identify which registers 140 are to be cleared) is to have it done automatically. This would be where the CPU execution unit 120 keeps track of which registers 140 are read from or written to while executing inside a secured code block and then automatically clears them upon exiting the "secure" mode. This allows the secured code to quickly "clean-up" after itself such that only those data that are permitted to be shared between the two kinds of code blocks are kept intact. The "automatic" process may potentially be more secure than the "explicit" procedure, but it may make more complicated the case where the code author wishes to share information between secured and non-secured code blocks.

^0016] Another potential manner for dealing with the "leaking" of register-stored data between secure and non-secure code segments is to identify a unique set of registers which are to be used only when the CPU 120 is executing secured code. For some CPU architectures with large general purpose register sets 140, this might at first seem prohibitively expensive. However, the same effect could be accomplished without requiring an inordinate amount of overhead (i.e., without the silicon overhead involved in implementing a physically distinct set of "secure" registers) by using a modified version of the register renaming and scoreboarding mechanism, which is practiced in many contemporary CPU designs. If we treat the execution of a secured code block as an atomic action (i.e., it is non-interruptible) , then these issues are easier to deal with, but this convenience may come at the price of performance and potential overall code complexity. Note that the "secured" portion of the I- Cache 130 does not necessarily require a different data path to the CPU as the "normal" portion of the I-Cache 150. In fact, the two can be completely synonymous.

;0017] A One-Way Hash Function block 160 is also depicted. It is possible to construct an engine that will be able to execute embodiments of the security protocol without having to implement this functionality in hardware. However, a hardware accelerator for certain parts of the hashing algorithm is certainly a desirable feature. Tradeoffs between hardware and software implementations of this functional block are discussed later.

^0018] Another portion of the target unit 100 may be a hardware— assisted decryption system 170, which uses the target unit's 100 secret keys and public/private keys (described later) to operate on encrypted messages in order to translate them into executable code blocks. This decryption system 170 can be implemented in a number of ways . The speed and the security of the entire protocol may be dependent on the construction of this block, so it should be both flexible enough to accommodate security system updates as well as fast enough to allow the system to perform real-time decryption of time-critical messages. ^0019] Keeping those two constraints in mind, it is not material to the protocol exactly which encryption algorithm is used for this hardware block 170. In order to promote the maximum flexibility, it is assumed that the actual hardware is general-purpose enough to be used in a non-algorithmically specific manner, but there are many different means by which this mechanism can be implemented.

^0020] Also note that there is an on-chip Random Number Generator 180 shown in the block diagram in dotted lines. This block is optional. Additionally, it can be replaced by a suitable off-chip method of producing a sequence of sufficiently random numbers, which can then be used to supply seed values for a software-based pseudo-random number generation system. This pseudo-random number generator can also potentially be implemented in hardware or in "secure" software. Of course, the same principle trade-off between the flexibility of a software-based system versus a hardware implementation applies in this case as well. However, since the case where the target device 100 must generate a random number is not a frequent occurrence in this protocol, it is not likely to have an impact on overall performance if this particular function is not hardware-accelerated.

Secret Key:

;0021] Each protocol engine ("target" unit) 100 may have two sets of secret key constants 104 that are stored on-chip; the values of neither of which are software-readable. The first of these keys (the primary secret key) can actually be organized as a set of secret keys, of which only one is readable at any particular time. If the "ownership" of a unit is changed (e.g., the equipment containing the protocol engine is sold or its ownership is otherwise transferred) , then the currently active primary secret key may be "cleared" or overwritten by a different value. This value can either be transferred to the unit in a secure manner or it can be already stored in the unit in such a manner that it is only used when this first key is cleared. In effect, this is equivalent to issuing a new primary secret key to that particular unit when its ownership is changed or if there is some other reason for such a change (such as a compromised key) . The only other place where this primary secret key value (or set of values) is stored is on a central server at a licensing authority.

;0022] The primary secret key may be associated with a particular target unit's 100 serial number 106 in the central server's database. The serial number 106 can be stored anywhere on the target device 100, may be software accessible and has no other relationship to the primary secret key. Any updates to the operational aspects of the unit (such as updating the security system) may be accomplished by using the primary secret key. If the value of this key is' not known by any parties other than the target unit 100 and the licensing authority, it cannot be used for any secure transactions that do not involve a link through a secure central server. However, since the security of this primary key is of paramount importance, it should be used only when absolutely necessary. Thus, it probably should not be used, for example, to encrypt the communications link for secure transactions between the central licensing authority's server and the target unit. This link can be secured using a standard key exchange protocol using a temporary key, which is generated on the fly, in accordance with currently accepted standard practice.

;0023] The secondary secret key may be known only to the target unit 100 itself (and thus, not to the licensing authority) . Since the CPU 120 of the target unit 100 cannot ever access the values of either the primary or the secondary secret keys, in some sense, the target unit 100 does not even "know" its own secret keys 104. These keys are only stored and used within the security block of the target unit's CPU 120. It is the combination of both of these secret keys that enhances the overall security of the target unit. We will describe how they are used later on.

^ 0024] Yet another set of keys may operate as part of a temporary public/private key system (also known as an asymmetric key system or a PKI system) . The keys in this pair are generated on the fly and are used for establishing a secure communications link between similar units, without the intervention of a central server. As the security of such a system is typically lower than that of an equivalent key length symmetric key encryption system, these keys must be larger in size than those of the set of secret keys mentioned above. These keys may be used in conjunction with the value that is present in the on-chip timer block in order to guard against "replay attacks", among other things. Since these keys are generated on the fly, the manner by which they are generated in dependent on some sort of a random number generation system 180. Finally, it should be noted that care must be taken to ensure that the generated keys should not be contained in the class of so-called "weak" keys. The specific set of keys that are considered "weak" are dependent on the specific encryption algorithm used.

Operational Details:

^ 0025] The manner in which embodiments of the security protocol operate can be broken down into several discrete processes: System Initialization, Secure Code Generation and Mass Distribution, Secure Code Loading and Execution, Key list data structure Construction, Temporary License Transfer, Permanent License Transfer, System Ownership Transfer, License Revocation and Security System Updates. Each of these is discussed in turn. It should be noted, however, that the examples described below are chosen for the purposes of simplicity of discussion and are not necessarily the most efficient (nor are they the only) manner in which this protocol can be implemented. System Initialization

;0026] This is the step in which the target unit's secret keys 104 are set to some initial value. This procedure can be accomplished in one of several locations (for either of the two secret keys, but for logistical reasons, it should be the final step in the assembly process where either the serial number or the secret key can possibly be changed. In the case where the unit's 100 serial number is stored off- chip, then this procedure is most likely performed at the point of final assembly. If the serial number 106 for the unit is stored on-chip, then it would be most practical to carry out this procedure at the last point in the chip manufacturing process (i.e., after the chip has been packaged) , so that any postproduction or burn-in fall out has had a chance to winnow out the non-functional parts. This way, the amount of data that must be kept secure is minimized. Since the security of the entire protocol may be based on that of the unit's secret keys 104, the initialization procedure should be undertaken at a point where physical security is possible.

;0027] The primary secret key should be initialized (or "burned" into the device) in a different procedure than the one that is used to supply the secondary secret key. Although, in practice, this secondary key will be known at some point (since it is programmed into the unit at some point during the manufacturing process), the unit with which it is associated should not be recorded anywhere once it is stored on the target device 100. For auditing purposes, it may potentially be desirable for the total set of secondary secret key values to be examined independent of knowing which parts hold which keys (to test for randomness of the distribution, or for some other reason) . In order to maintain the secure nature of the system, however, it is desirable that the device which programs this second secret key into the unit never have any means of associating the secondary secret key to either the first secret key or to the target device serial number 106. Also, both of these secret keys should be implemented in a tamper-proof manner, for reasons, which are described later. It is not material in which order these two secret keys are initialized. Following the initialization procedure described in the exemplary embodiment, the only location (other than on the actual chip) where the target devices' serial number 106 and their associated primary secret keys are co-located should be on the secure server at the licensing authority.

Secure Code Generation and Mass Distribution

^0028] Referring briefly to FIGURE 5, in an example scenario, let us suppose that a developer 520 wishes to produce an application to run under this protocol, which will be reasonably immune from disassembly and can only be executed on a specific device. Each registered developer 520 will have a public key / private key pair which is used to authenticate any messages which they use to communicate with the licensing authority's server as well as to create signed Message Authentication Codes or MACs (typically referred to as digital signatures) which can be used to authenticate any published code block or other bitstream.

^0029] After an application is debugged, it is encoded using an application-specific encryption algorithm and key(s), which are known only to the original developer. This application— specific algorithm and key(s) can either be a symmetric (secret) key system or an asymmetric (PKI) key-based system. Attached to the end of the encrypted block of code is a MAC, which is then signed by the developer 520 using the private key of their published public key/private key pair (which thus forms an unambiguous digital signature for the encrypted code block) . Either the digital signature or the original MAC and the corresponding Code specific ID number may be supplied to the licensing authority. The application developer 520 may also choose to supply the appropriate decoding key(s) as well (we will discuss the tradeoffs of this decision in a later section of this document) .

^0030] Note that if the application-specific algorithm is an asymmetric encryption system, it does not necessarily need to be encrypted using the same published PKI key pair that is used to generate the signed Message Authentication Code (the digital signature) . However, the MAC that is stored at the end of the code block should be generated using a known hashing algorithm and must also be signed using one of the developer's published public keys (thus forming the digital signature) . This allows the target to verify the authenticity of the MAC using a known hashing function and a known public key.

^0031] Moving now to FIGURE 2, all application-specific encryption key data structures 210 may contain a number of extra fields (in addition to the decryption key itself 220) . One of these fields may comprise a timestamp 230 and an associated mask value 240. The second may contain a "countdown value" 250. The mask value 240 may be used in conjunction with the other two fields 230, 250 in order to determine when the key is valid. It should also be noted that it is not relevant to the protocol exactly how many bits are allocated to each of the fields.

^0032] Note that the timestamp value 230 can be used in several ways, depending on the bit pattern that is stored the in timestamp mask 240 field. The timestamp mask 240 value allows the developer 520 to select some subset of the timestamp figure that is ignored when performing the comparison with the target unit's 100 current time. As an example, however, if we assume that the smallest resolution which is supported by the timestamp field 230 is one second, then by masking out the lower five bits of the timestamp data 230, a particular key data structure 210 can be generated which is only valid when used over the course of approximately 32 seconds starting at the time which is stored in the timestamp field 230. The overall functionality of the security protocol is not dependent on the actual resolution of the lowest order bit of the timestamp field 230.

^0033] There may be other bits that are associated with the mask field 240, some of which can be used to indicate whether the key is valid before or after the value specified in the timestamp 230. Yet another mask field 240 bit can be used to indicate how the timestamp 230 and the "count-down" values 250 are associated. For example, this would be useful in the case where the intent of the application developer 520 was to limit the use of the software to a certain number of iterations either prior to or after a certain date, rather than simply tied to a certain date and time window. Of course, any combination of these conditions can be constructed, so the protocol is quite flexible in this regard. In addition, further flags can be included in this data structure to indicate other properties, such as how many legal copies of the keys may be simultaneously distributed from the original target unit 100 to others. This would be useful in the case where a multiple-copy license were desired, such as is seen in a digital library, for example.

^0034] A flow diagram representing one embodiment the encryption process can be seen in FIGURE 3. Note that there is no substantive difference between the process that would be used to distribute a digital media stream or a software application (such as the decryption instructions used to interpret that media stream) . In either case, there are a couple of different options for distributing the encrypted code block(s) 310, 320; either via an online server or on serialized discs (such as a standard DVD) . In the latter case, the developer 520 can then choose to pre-register the individual serial numbers of the mass-produced discs with the licensing authority 510 (or not) . If so, the serial numbers could be permanently affixed to the discs either by burning them into the Burst Cutting Area (in the case of a DVD) or by ink-jet imprinting (in the case of a standard CD) . Note that the developer 520 cannot embed these serial numbers into the data area of the CD or DVD, since the same serial number would be replicated on all of the mass- produced discs. If some sort of a hybrid format were used, where part of the disc could be mass-produced and another portion written once, then this would be another potential method of distributing the discs with individual serial numbers. In any case, a machine-readable serial number is certainly preferable, since it is less prone to errors during the registration process.

^0035] If the developer 520 chooses not to register the media serial number with the licensing authority, then there may be some other manner by which the proper encryption key(s) can be associated with the application or media stream files. Thus, the application developer 520 may either register the code-specific ID or an associated media serial number. In the former case, then the application can be distributed freely (i.e., not tied to a specific release format and media) .

^0036] In the case of the individual serial number mechanism, the privacy of the end user is maintained, since the licensing authority 510 has no need to know (and potentially no indication of) which application (or media stream) is associated with which serial number (s) . In the case where the developer 520 registers an application ID (or a media stream ID) along with its associated key(s), then it is possible for the licensing authority 510 to know which application ( s) or media streams are "owned" by a particular end user. On the other hand, this potential lack of privacy is counterbalanced by the additional convenience and cost savings of not requiring the developer 520 to manufacture and distribute physical media. Note that the term "physical media" does not necessarily mean a disc. This function could be accomplished just as well by using a printed manual (or even a simple registration form) with an individual serial number sticker attached to it. All that is required is that the developer 520 must produce some object with a unique serial number, which is supplied to the end user. The purpose of this serial number is to act as a bitstream registration number. We will discuss how this serial number is used in the protocol in a following section.

^0037] For the example shown in FIGURE 3, both the encrypted software application (or media stream) 310 and the machine dependent decryption software 330 are distributed using the same mechanism. It is not a requirement of the protocol that this should be the case and either or both of the encrypted code blocks 310, 330 can be distributed on-line or by pressing a disc. It should be noted, however, that in the case of a digital media stream, the media stream itself is most likely the larger of the two blocks 310, 330 by several orders of magnitude. Thus, in that case, it makes the most sense to effect the distribution of at least this block in a mass-produced disc format. In many cases, there may be enough room on such a disc to fit the companion encrypted code block (the one which contains the instructions of how to decode the first block) as well as the primary encrypted code block. It should also be noted that neither of the two data sets would be likely to undergo any changes after publication, so there is no fundamental requirement that they must be distributed online. As such, they are both well-suited to a mass-produced disc based distribution mechanism. Having both of them on the same disc also makes it easier to associate one with the other in an unambiguous fashion .

Secure Code Loading and Execution

^0038] In the case where the distribution mechanism is accomplished via an actual disc, the consumer can purchase the disc containing the application in exactly the same manner as a traditional software purchase. Of course, the end-user would not be able to run the encrypted code block unmodified on the processor of the "target" unit. When the user attempts to run the application on their machine, the CPU 120 loads the encrypted software block and uses the digital signature (the "signed" MAC) stored at the end of the code block along with the software developer's public key to verify that the code block in question is genuine. This is where the first hardware modification to an otherwise general purpose CPU 120 may come into play. The process for loading and decrypting such a block of secured code is shown in FIGURE 4.

^0039] In order to make sure that the hashing function is computed correctly (and furthermore, that the comparison between the generated message digest and the "real" message digest is valid), the CPU 120 must perform this hashing function in a secure manner. Thus, the hashing function must either be generated directly by the hardware of the decoder unit or the hashing function itself must be computed using a block of "secure" code, the operation of which cannot be tampered with by an otherwise "non-secure" program.

;0040] Note that in the software-based hash case, this block of secure code should be considered as a part of the unit's 100 security system and, as such, may only be able to be downloaded to the player via a secure transaction between the unit 100 and the licensing authority 510. Interestingly enough, the establishment of a "secure" hashing function can be accomplished via the same secure protocols described herein. This recursive behavior for all aspects of the security system is what enables a software-based version of this protocol to be extremely flexible (and thus, updateable) in its encryption/decryption architecture.

^0041] If the message digest calculation is fixed in hardware, we can potentially gain some degree of security, but this comes at the expense of flexibility. If a dedicated hardware block is used to generate the hash value, and then some weakness in the hashing algorithm is discovered at some point after the chip is manufactured (or if there is some bug in its implementation), then there is no opportunity to address the problem after the fact. That is not to say that we cannot use some kind of hardware acceleration of the software-based hashing function (such as a programmable S-Box structure) in order to speed up the process. However, in that case, the hardware should ideally be sufficiently general purpose to support a large variety of one-way hashing functions.

^0042] It should be noted, however, that the security of this protocol is ultimately dependent on the lowest-level function that is provided as a part of this secure code loading procedure. The low level features (such as a secret key or a primitive operation which is used in a hashing function) are combined together in different ways to produce higher level functionality, such as a signed message digest. In turn, these higher level functional blocks are used to provide even higher level utilities, such as identity verification. This process of building higher-level functions on top of more primitive layers is known as building a "Chain of Trust". The flexibility of the system lies in placing the point at which the security related functions can be modified as low as possible within this hierarchy. However, at some point, the fundamental primitive operation(s) upon which this chain is based must be atomic in nature (i.e., this is the minimum level of functionality which must be implemented in hardware) . The exact choice of this point of hardware granularity is, for the most part, an implementation detail, and the overall operation of this protocol is not dependent on this aspect, given the conditions above.

^0043] Once the encrypted code block 310 is loaded into the target's memory space 110, and the message digest is calculated, the result is then compared with a message digest which is calculated by decrypting the digital signature 340 which was stored along with the encrypted code 310 with the developer's public key. If the two are a match, then the target unit 100 can be certain that the encrypted code block 310 is genuine (or at least that the code was distributed by the developer 520 whose public key was used to decrypt the digital signature) .

;0044] At this point, the target 100 then sends a secure message to the licensing authority 510 requesting a copy of the decryption key(s), which will be used in concert with the recently verified encrypted code block. As a part of setting up the secure connection with the licensing authority, the target unit 100 generates a temporary public/private key pair (the public portion of which is supplied to the licensing authority 510 server) . The details of the key exchange procedure are well known and we need not go into the exact mechanism by which this is accomplished in this discussion. In any case, it should be noted that the overall network traffic between the target unit 100 and the central server at the licensing authority 510 is limited to a reasonably small data set since it consists of a couple of key transfers, the code-specific ID and the MAC which was stored along with it.

^0045] Assuming that the code-specific ID 260 is one that the licensing authority 510 recognizes, there may be two possible courses of action, depending on whether or not the application author has already provided the licensing authority 510 with a "clear" copy of the requested decryption key(s) . In the case where the developer 520 has not provided the licensing authority 510 with such information, then the central server transmits a copy of the target device's temporary public key (as well as the code- specific ID 260 in question) to the application developer's server. At that point, the developer's server responds to the licensing authority 510 server with a message containing the requested decryption key(s) (encrypted with the target's temporary public key) and a message digest generated from the properly decrypted code. In this manner, only the target device 100 can decrypt the message to obtain the application-specific decryption key(s) and the licensing authority 510 will not ever have access to the decryption key(s) in clear form.

;0046] Although the message digest can be pre-computed and stored on the licensing authority's server, the fact that it may be provided by the developer 520 during the transaction is of potential use if the hashing function (which is used to generate the message digest) should ever change. If this should happen, the developer 520 would need to provide updated versions of the decrypted code message digests to the licensing authority 510 either prior to or during the actual transaction with the target device 100. The developer 520 must provide this information since the licensing authority 510 should never have access to the original (decrypted) code. As before, the amount of network traffic between the licensing authority's server and the developer's server is still quite small. The encrypted key that was received from the developer 520 is then encrypted yet again with the target device's primary secret key prior to transmission from the licensing authority 510 to the target. This second encryption could actually be carried out on the developer's side as a part of the other transaction, but in that case, the developer would potentially have access to the target unit's primary key (unless both keys were somehow combined) , which would pose potential loss of privacy issues for the end user.

;0047] Note that in the case where the application developer 520 wishes to stay "out of the loop" for transactions between the licensing authority 510 and the target device 100, they can simply provide the licensing authority 510 with a copy of the relevant decryption key(s) in clear (unencrypted) form and the associated MAC for the decrypted code block (the value of which must be updated each time the hashing algorithm is changed) . Thus, the central server at the licensing authority 510 would be able to act autonomously and would not be required to establish a communications link to the developer's server in order to fulfill a key request from a target unit 100. However, this poses a potential security risk to the developer, should this "clear key" information ever be compromised, either intentionally or unintentionally by the Licensing Authority.

;0048] The flow diagram for the whole key encryption/decryption process is outlined in FIGURE 5. In this case, the clear key would still be encrypted prior to transmission (as above) with both the target device's temporary public key and then again with the target's primary secret key. At this point, the target device 100 has the proper decryption key in a doubly encrypted format. In the case where the licensing authority 510 does not have access to the application specific key 550 information in the clear, then it should not be possible for anyone other than the intended target device 100 to be able to reproduce this key data in clear form, since the secret key for each unit 100 should only be known to the licensing authority 510, and the private key for the transmission is known only by the target 100.

;0049] At this point, however, the encoded decryption key(s) which the target 100 receives from the application developer 520 cannot yet be stored safely in the open at the target 100 (e.g. in a flash ROM or backed up on a hard drive) . The problem is that the target device 100 would also have to store a copy of the temporary private key along with the encoded decryption key(s), which were transmitted from the licensing authority 510. If someone at the licensing authority 510 were to then gain access to these two pieces of data by some means, then they would potentially be able to reconstruct the decrypted application specific key 550 (given that they might have access to the target device 100' s primary secret key as well) .

^0050] This is the point where the target device's secondary secret key comes into use. Recall that this secondary secret key is not known to anyone other than the decryption unit of the target unit. Thus, once the temporary private key is used to decrypt the key, which was supplied to the target 100 from the licensing authority, the secondary secret key is used to re-encrypt the application-specific key prior to its use (and/or archival) .

^0051] The target can then use the application specific (clear) key 550in order to decrypt the code block (or media stream) . Thus, the only two places where the application code exists in clear form are at the original developer 520 itself and inside the "secured" portion of the target device's I-Cache 110 (where it can only be executed and can never written back out to memory in clear form) . This allows privacy between the user and the licensing authority 510. In other words, the licensing authority 510 does not have to know what it is that the user has a license to (an enormous privacy advantage) , but it is still able to act as a repository (or backup) for the user's key list in the case where their unit 100 is damaged or stolen or otherwise rendered inoperable.

^0052] As a check to verify that the decryption process has been performed correctly, the message digest of the properly decrypted code is then compared with the message digest generated by decrypting the digital signature, which was forwarded from the original developer 520 through the licensing authority 510 to the target unit 100. As was mentioned earlier, this digital signature is created by encrypting the message digest of the unencrypted code block with the application developer's private key. Alternately, this digital signature can also be encrypted again by the developer 520 using another temporary public key 530, . which was supplied to the licensing authority 510 when the connection was established. In any case, the correct message digest can then be decoded by the target device 100 by decrypting the digital signature with the developer's public key. If this message digest matches the MAC of the decrypted code block, then the code is considered to be genuine and it is allowed to run on the target 100. This message digest may then be re-encrypted with the target unit's secondary key 540 for archival along with the re-encrypted application specific key 550.

^0053] The final step in this procedure is that the newly encrypted (with the target device's secondary key 540) version of the application specific key 560 is retransmitted back to the licensing authority 510 server for archival purposes. This transmission serves a few purposes. First, it is an acknowledgement that the target device 100 was able to properly decrypt the code block. Second, it is necessary for the licensing authority 510 to have a copy of this encrypted key 560 in order to deal with the case where the end user suffers some sort of catastrophic data failure and they have neglected to make their own backup copy of their access keys. The licensing authority 510 can then act as a backup storage facility for any particular user. Yet another reason for this procedure is in order to deal with the case where a particular target device 100 changes ownership from one user to another or if the user wishes to upgrade their target device 100. This kind of permanent transfer of ownership can involve the transferal of all of the licensed application keys for that unit 100 (in which case, there is nothing which needs to be done other than re-registering the unit under the new owner's name) . However, if the user wishes to transfer permanent ownership of their key data from the first to the second device, then this may be accomplished by means of a secure transaction between the licensing authority 510 and both of the target devices.

^0054] The other piece of information that the target device 100 transmits back to the licensing authority 510 server is the message digest of the target device's newly updated key list data structure 610 (as depicted in FIGURE 6) . This is both an acknowledgement of the newly updated key list data 610 structure and is also used to verify the equivalence of the key list data structure 610 associated with that particular target device 100 on the licensing authority 510 server and on the target device 100. The exact construction of this data structure will be described in the following section. We will also discuss methods by which permanent transfer of ownership of a particular key or set of keys is accomplished in a later section.

^0055] It should be noted at this point that the process outlined above is not the only manner in which the protocol can be used to transfer the application specific key 550 from the developer 520 to the target device 100. For example, the actual key transfer transaction can involve a direct connection only between the target 100 and the application developer 520. However, in that case, a connection must be established between the developer's server and the licensing authority's server in order to contribute the device specific encryption information to the transaction. There are a number of mechanisms by which this protocol can be made to work in a secure fashion, and the example discussed above is just one of these. However, the common thread is that all three parties must act together in order to ensure that the key data, which is transferred to the target 100, is only useable for that target device 100.

^0056] Note that the structure of a key can be set up to have two pieces: a hardware-specific part as well as an application— specific part. It is not a requirement that these two pieces be completely inseparable. If they are inseparable, then we get the properties exactly as discussed earlier. If, however, there is a way to make the key pieces independently operable, then we can enable a global set of copy and use restrictions that could be independent of the actual code or of the actual target device 100. In other words, any developer 520 could publish an application or media stream which had no restrictions on distribution, but which could not be read; only executed. This could be useful in the case where the licensing authority 510 wanted to send out a security system update that would run on all devices, regardless of the manufacturer. Another example of this would be the broadcast of a publicly available media stream while still maintaining control over the copyrights to that stream. Similarly, a publisher could distribute an application, which anyone could read and/or copy, but which would only execute on one specific target device 100 or set of devices. This could be useful for sending out an "update this specific class of device" message, for example. Another possible application is to send out an application, which would run everywhere and had no restrictions on distribution. This would be similar in nature to publishing the source code for a particular application (i.e. open source distribution) . The different classes of security which are enabled by a separable H/W-specific and S/W- specific key structure are illustrated in Table 1.

Software or Application-Specific key segment

"Locked" * "Unlocked" **

"Locked" Hardware-Specific key segment

"Unlocked" '

* i e , Locked to a specific serial number ** i e , will work anywhere (or to a range of numbers)

Table 1. Separable hardware-specific and application- specific key structure

Key list data structure Construction

Looking now at FIGURE 6, the data structure 610 containing the list of application or media-specific keys, which are licensed to a particular target device 100 is a valuable commodity and, as such, it should be able to be backed up by the owner. Since the individual keys are encrypted with the target's secondary secret key (as described above), the list is only useful to the unit to which the keys are licensed. However, we need to be able to make sure that this data structure 610 is secure from tampering, corruption and/or outright loss. In the case of a lost key list data structure, the entire data structure 610 can be recovered by requesting a new copy of the key list for that particular target device 100 from the licensing authority 510, as was described earlier. In the case where a temporary change has been made to the key list data structure (we will discuss the reason for such a scenario in the section following this one) , then the protocol may accommodate a means for identifying such a change as being temporary. Finally, we include some tamper-resistant mechanism for validating the authenticity, timeliness, and validity of the key list data structure 610.

^0058] With these requirements in mind, we can construct a secure key list data structure 610 that exhibits all of these qualities in a manner like that which is shown in FIGURE 6. As always, the example shown is not the only method by which all of the desired properties can be included in such a data structure. Nonetheless, the particular data structure illustrated in FIGURE 6 does, in fact, fulfill all of the basic requirements of the protocol.

^0059] There are a few basic precepts that should be noted in the diagram above. The first is that the top-level encryption of the key list data structure 610 must be performed with the target device's primary secret key. There are a couple of reasons for using this particular key, but the main issue is that the licensing authority 510 must be able to regenerate the encrypted form of this data structure independently of the target device 100 in the case where the local copy of this data structure must be restored. If any other key is used to encrypt this data structure (such as the target's secondary secret key, for example) , then when the target needs to make a change to the data structure (as is the case when a key is added to the list), the entire list must be transferred to the licensing authority 510 for backup purposes. This could potentially greatly increase the amount of network traffic that must be transmitted back to the licensing authority 510 and is not necessarily the most efficient use of the channel bandwidth.

^0060] Also, it is desirable that this key list data structure 610 be used for the storage of security system-related keys, in addition to being used for the storage of standard application or media stream specific license keys. Since this data structure is able to be regenerated by the licensing authority 510, in cases where it is desirable to update the security software which runs on the target device 100, it would be both more secure and more efficient (from the standpoint of code storage requirements on the target device 100) if the same key list data structure 610 could be used for both functions.

;0061] The second issue is that the encrypted version of the key list data structure 610 includes a message digest of the original key list data structure 610. It should be noted that although each of the individual keys are encrypted, other pieces of the list itself are not separately encrypted at the point when the message digest is calculated. Following the message digest calculation, the entire key list data structure 610 (including the message digest) is then encrypted with the key value and algorithm that are identified by the top-level (or master) key. This is done in order to prevent a malicious third party from tampering with the list, calculating a new message digest and then substituting the modified list for the genuine one. When the key list data structure 610 is read into the memory space of the target unit 100, this (decrypted) message digest is used to verify the authenticity and validity of the key list itself in the same manner as the way that a MAC is used for any other secure encrypted code block. The fact that all of the elements other than the individual keys are only encrypted with the master key means that the list can be traversed (and the list maintained) without having to have access to any keys other than the top-level key. Also, a key list inventory can be compiled with only a single pass through the decryption block.

^0062] A third principle which is of interest is that the individual application code or media stream specific keys can be made large enough to accommodate individualized keys for each target device 100. In the case where the code or the media stream is distributed by way of a mass-produced disc, this would mean that the application developer 520 would need to issue a new code-specific ID along with the individual decryption key(s) . Although this may be less efficient from the standpoint of trying to minimize the amount of data which must be transferred between all of the parties involved in the licensing process, it does add functionality to the protocol, including (but not limited to) the ability to track compromised decryption keys. We will also discuss this in a later section dealing with key revocation .

^0063] The next issue of note is that the key list data structure 610 header shares the same set of characteristics as the application specific keys that make up the rest of the list. In fact, the header can be thought of as a master key 620 for the rest of the key list data structure 610 itself. Thus, the same principles of operation can be applied as far as how this key can be used to determine the management of the rest of the list. This includes time-dependent management of the security system of the target device 100. Thus, the target unit 100 can be forced to update its security system at pre-determined intervals, which is an extremely powerful concept all by itself.

;0064] The possibility also exists that the key list could contain a number of sections, each with its own master key 620 (list header) and thus with its own independent encryption mechanism. As with any other key, the list header contains a code specific ID field 260, which can point to an encrypted code block that is used to interpret the key list data structure 610. The whole list could then be contained within yet another master list, which includes its own master key (which is yet another list header) . Thus, the entire key list data structure 610 can be recursively defined. As before, this recursive property can be used to update the security system by creating new key list data structures to address shortcomings of previous versions of the same data structure. Since the security of the whole list is contained within the "outermost" (or most recent) security layer, then the security of the entire key list data structure 610 is always based on the latest iteration of the security software .

^0065] Thus, the recursive property of the key list data structure 610 is a compelling feature. It is also the reason that the exact implementation of the data structure, which was discussed in an earlier section, is not of great significance. The description provided above was simply an example that included the features that are the minimal subset of functionality required to make the recursive nature of the protocol work.

^0066] Independently of how it is structured, the key list 610 may be maintained and/or updated under several common circumstances. These circumstances include (but are not limited to) the case where the status of one or more of the keys contained in the list is modified. There are a few basic mechanisms by which the ownership of a particular key 210 can be transferred from one unit to another and we will discuss these in later sections. In any case, however, the mechanism by which the revised key list is maintained can be split into two classes: those which require the intervention of the licensing authority 510 and those which can be carried out independently. ^0067] One of the primary operating concepts upon which this protocol is based is one of reducing to a minimum the amount of required network traffic between the central server of the licensing authority 510 and the individual target units. Thus, any temporary changes to the key list data structure 610 (the reasons for which we will describe below) should be able to be maintained independently by the target unit 100. The main reason for this is that these changes would ostensibly occur more frequently than permanent changes to the device's security system (which should always only be accomplished by an interaction between the target device 100 and the licensing authority 510) .

^0068] In any case, there must be some mechanism by which the target device 100 can keep track of the current state of the master key list data structure in an unambiguous manner. This can be accomplished by having two "master" lists. The first of these two lists (which we will call the permanent key list) is maintained by the licensing authority 510. This list is concerned with the "permanent" ownership of the application specific keys that are associated with the target unit 100 in question. The second list is of equal importance, but it is that which is concerned with temporary modifications to the "permanent" key list data structure. Note that these modifications can either be additions to the list or they can be deletions from the list. There are no necessary differences in the implementation of the data structures of the two lists themselves; the main differences occur in how they are maintained. It is desirable that there should be some way for the target unit 100 to recover from the event where the data from one or the other of these lists is either lost. This loss can be due to some catastrophic failure or due to the case where the information contained within one of the lists is somehow corrupted (either innocently or maliciously) . We will discuss the implications of such "key list corruption" events in a later section. Although it is necessary that the permanent list can be restored by a connection with the licensing authority, it is not necessary (or even desirable) for the licensing authority 510 to be able to recover a particular target device's temporary key list. There are many reasons for this position, but the main reason is that the temporary key list is most likely updated much more frequently than the permanent key list and we wish to keep the amount of required network traffic between the central licensing authority 510 and the target units to an absolute minimum. Nonetheless, it may be potentially desirable for the licensing authority 510 to be able to make modifications to a particular target's temporary key list for several reasons (some of which we will discuss later) . In this case, it would be desirable to have this list encrypted using the target device's primary secret key (which is known to the licensing authority 510) .

^0069] As mentioned earlier, the integrity of both of the key list data structures can be verified by using the signed message digest (the digital signature) , which is stored along with the list itself. The implementation of the secure code mechanism, which is used to generate this message digest, was described in an earlier section and we do not need to go over the procedure again. We have also already described the procedure for recovering the permanent key list data structure 610 in the case of loss and/or corruption. The only remaining issues that must be addressed are how to interpret the time-dependent portion of the temporary key list data structure and how to deal with the case where a temporary key list is somehow rendered unusable.

Temporary License Transfer

^0070] This is one of the sections of the security protocol where the use of the timestamp field 230 is of prime importance. As discussed earlier, the temporary key list data structure is constructed in exactly the same manner as is the target device's permanent key list. However, there are a couple of differences between the two. The first difference is that the temporary key list can potentially be encrypted with either one of the target unit's secret keys 104. Since it is not necessary that the licensing authority 510 be able to reconstruct this data structure under normal circumstances, it is ostensibly not relevant which of the target unit's keys is used to encrypt it. However, it would potentially be of use to the licensing authority 510 if this list were also encrypted using the target unit's primary secret key. The reason for this has to do with license revocation and that situation will be discussed in a later section.

^0071] A second (and more important) distinction between the temporary and the permanent key lists is that a copy of the timestamp value 230 which is associated with the most recent temporary key list data structure is also stored inside the target device 100 (i.e. on-chip) . This register is not software readable and is only able to be overwritten by secure code, as it is a part of the security block. The value in this register is used to determine what to do in the case where the temporary key list data structure is somehow lost and/or corrupted. We will discuss that procedure later on in this section.

^0072] Yet another distinction between a temporary key list and a permanent key list is that a target unit 100 is able to (temporarily) transfer ownership of a particular key from its permanent list to another unit's 100 temporary list, but no (correctly operating) device is able to transfer ownership of a particular key from its temporary key list to any other key list. This includes, of course, not only other units' temporary key lists, but also the target's 100 own permanent key list as well. This means that only the permanent owner can decide which devices are allowed (and when they are allowed to) "borrow" any particular key. Note, however, that this "loan" period can be made indefinite (and this transaction can be carried out without the necessity of contacting the licensing authority) . This "permanent loan" feature is equivalent to the standard "Copy Once" functionality requirement that is part of most modern digital Copyright Control Information (CCI) systems.

^0073] Turning now to FIGURE 7, a detailed flow diagram depicting the temporary "key checkout" procedure is shown. The "key ownership" transfer procedure is somewhat similar to the procedure of checking a copy of a book out from a library. When the "borrower 720" requests the temporary use of a particular application specific key 550 from the permanent owner (the "lender" 710), then the lender 710 first generates an updated temporary key list for itself which prohibits the use of that particular key for the duration of the key checkout negotiation process. This action prohibits more than one borrower 720 unit from requesting the same key. The presence of the "checked out key" on the temporary key list of the lender unit 710 is effectively used as a semaphore to control access to any particular key. However, the initial amount of time that the key is placed "on restriction" should be limited to a relatively short period. This is to prevent the case where a borrower 720 device requests access to a particular key for a long period of time and then is unable to complete the transaction for some reason from unfairly monopolizing the use of a particular key. This relatively short checkout negotiation phase timeout also helps in the battle against the malicious device, which may be attempting to mount the equivalent of a "denial of service" attack against the lender unit 710. In fact, the lender unit 710 can optionally ignore requests from devices which are not on its "approved borrower" list or if any one of those units should try to make too many requests within a certain time period. The exact length of time that this temporary block is placed on the key is not important, but it should be long enough to allow any given checkout procedure to go to completion. In times of high network traffic or latency, this period could be extended.

;0074] Note that in the case where more than one copy of a given key is allowed to be simultaneously checked out, the appropriate fields within the lender device's 710 temporary key list can be used to indicate how many copies of a given key are checked out at any one point in time. Once the borrower 720 and the lender 710 have negotiated a specific checkout period for a given key, then the lender 710 sends an encrypted copy of the key 740 to the borrower 720. This encryption is carried out using a temporary secret key 730, which is known only to the lender device 710. When the borrower 720 then acknowledges the accurate receipt of the encrypted key (by means of a message digest which is calculated from the encrypted message) , then the lender 710 extends the "loan period" of the checked out key and then sends the temporary secret key 730 to the borrower device 720. The maximum duration of this loan process is not important to the operation of the protocol and there are some tradeoffs that must be made in the choice of this value. We will go over those particular issues later on in this section. In the example discussed above, we assume that the "borrower 720" and the "lender 710" devices are able to negotiate the actual length of the checkout period on a key- by-key basis, although this is certainly not a requirement of the protocol.

Just prior to the point where the temporary key list of the either the borrower 720 or the lender 710 is updated, a copy of the timestamp value 230 associated with this new temporary list is stored in a non-volatile fashion on the target 100. At that point, an encrypted version of the temporary key list data structure can be safely written out to memory (or stored in some other, more permanent location, such as on-board NVRAM, Flash ROM or even out to a backup file on some hard disk 750. Since the temporary key list is potentially read from and updated on a much more frequent basis than the permanent key list, it is desirable that this list should be quickly accessible to the target unit, so it is recommended (although it is not an actual requirement of the protocol) that this list be stored in at least one location where the access latency is relatively short. On the other hand, it is recommended that the only place where this list is stored is not some volatile storage medium (such as DRAM), since a power failure could potentially cause the loss of the unit's 100 functionality for an indeterminate amount of time. We will go into details about this issue later on in this section.

^0076] When the checkout period time for a particular key has expired, both the borrower 720 and the lender 710 devices can update their respective temporary key list databases independently. Thus, it is not a requirement that the borrower 720 be in contact with the lender 710 unit in order to "return a particular key to circulation". This is a major convenience factor in the case where the borrower 720 and the lender 710 devices are widely separated. Of course, the security of this operation may depend on a very tight correlation between the on-chip clocks that are used to generate and control the key timestamp records. Thus, the time/date clock must be an integral part of the security system and, as such, should be able to be overwritten by a transaction with the central server. Also, the clocks must be designed to be robust enough to resist tampering in the case where a malicious user tries to modify the internal timestamp value 230 and also to be able to survive normally occurring system power failures. Since it is not inconceivable that this clock is battery powered and that the battery could get removed or it could go dead over time, the system should be designed in such a way that the clock could potentially be restarted and reset by a secure interaction with the licensing authority.

^0077] Thus; we have described a situation where the ownership of a particular application specific key 550 can be temporarily transferred from one unit to another. At the end of the "loan period", both the "borrower 720" and the "lender 710" units can update their temporary key list data structures to reflect the "return" of the key to its original owner. Note that this procedure can be carried out independently on both units and thus does not require any interaction between the two devices.

;0078] We now must deal with the case where one or the other of the temporary key list data structures is corrupted and/or lost while one or more keys are "checked" out or "on loan". On the side of the "lender 710 " unit, when any keys are checked out, the first thing that it does is to determine the end of the "loan" period. This value is obviously constructed by adding the duration of the loan period to the value of the current time/day field. This time/date value is then compared with the value that is stored on chip as a result of the last time the device's temporary key list was updated. If the new value is greater (later) than the old value, then the new value is overwritten in place of the old one. On the "borrower 720" side, this same process is used, so that the result is that in any given target unit, the temporary key list timestamp is always the latest of any of the timestamps which are stored as a part of that particular unit's 100 temporary key list.

^0079] If a unit's 100 temporary key list is lost or otherwise improperly modified, then both the temporary key list and the permanent list are disabled until the point where this "latest timestamp" value has expired (effectively, a "timeout" period) . At that point, then the unit can go back to using the permanent key list and can begin the process of reconstructing a new temporary key list.

^0080] Thus, if a device's temporary list is ever tampered with or deleted, then the unit is effectively rendered inoperative until the timeout period has expired. While this timeout procedure may seem unnecessarily restrictive, it avoids the potential problem of multiple copies of any particular application specific keys ever existing as a result of some malicious act or because of some glitch (such as a power outage or a network connection going down) which may occur during the transfer of a key from one unit to another. Also, the potential for such severe repercussions as a result of tampering with the temporary key list data structure should help to discourage the practice by all but the more sophisticated attackers.

;0081] There are a number of optional additional features, which could be used to enhance the operation of the protocol in this regard. One such possible option is to add a signed message digest (digital signature) generated from either (or both) of the encrypted key list data structures to the values that are stored in the target units' on-chip security section. The MAC value resulting from the decryption of the digital signature could be used to quickly verify the validity of any particular key list without having to go through the entire decryption process. However, the issue of multiply nested key lists means that it is entirely likely that this decryption procedure must be performed multiple times at some point in order to finally produce an unencrypted key, so it is not critical to the operation of the protocol that these digital signatures be stored on- chip .

^0082] Another possibility for an enhancement is to store a pair of on-chip timestamp values rather than just one. The additional timestamp could be used to indicate the earliest (next) time when the temporary key list must be updated. This would make it easier for the target device 100 to decide when it needs to revise its temporary key list, since it would not have to constantly check over the list (which involves going through the decryption process) . Although this feature would be very useful, again, it is not a fundamental requirement in order for a unit to be able to execute this protocol. If a system that contains this second timestamp is implemented, however, it does bring up a potential for confusion in the case where the two timestamps get "out of sync" for some reason. One such example, which comes to mind, is the case where there is a power glitch that occurs at the point immediately after one such timestamp is written, but before the second one is updated.

^0083] The final issue that should be addressed is the matter of what the minimum and maximum limits are for the values of these temporary key list timestamps. On one hand, a larger limit for the maximum "temporary loan period" could allow the user to transfer the use of a particular data application (or media stream) from one unit to another unit for a reasonably long period. This would potentially be of use in the case where a user wished to transfer ownership of a media stream from their "home unit" to a portable unit. Having a long "checkout period" would allow the user to take the portable unit with them (along with its associated temporary keys) on a lengthy trip without requiring that they be in contact with the original "lender" unit 710. The downside of a long "checkout" period is that if anything should ever happen to the temporary key list data structure on the original unit, then that unit would be potentially disabled for a long time.

;0084] This last issue also points out a potential danger for the target unit 100 in the case where a piece of malicious code is able to set the value of the on-chip timestamp register to some indeterminate value. This could potentially be tantamount to disabling the target of the attack, and thus, the value of this timestamp register should only be able to be written by a "secure" code block. Again, since each unit will have a distinct set of secret keys, the discovery of one particular unit's secret key 104 data should not be a cause for concern for any other unit, except in the case where a malicious device is able to effectively masquerade as a legitimate unit. This mode of attack is discussed in a later section, which deals with issues related to Identity Verification .

Permanent License Transfer ^0085] Many of the elements of this procedure have been discussed in earlier sections of this document. The basic process by which a specific key is permanently transferred from one unit to another was shown earlier in FIGURE 5. In many ways, this procedure is essentially similar to that of the temporary transfer of key ownership as described in the section immediately preceding this one.

^0086] The main differences between the two procedures are that the permanent transfer is a simpler process than the temporary transfer and that the permanent key ownership transfer procedure should utilize an interaction between the licensing authority 510 and the target unit 100. The reason that the permanent transfer process is simpler lies in the fact that it does not require the checkout time period negotiations that are prerequisites in the temporary key checkout procedure. The reason that the permanent transfer function utilizes an interaction between the licensing authority 510 and the target unit 100 is due to the fact that the updated key list data structure must be able to be reconstructed at both ends of the transaction.

^0087] Since a permanent license transfer usually occurs by means of an interaction with the licensing authority 510, there is a record of which application or media stream specific keys belong to which target units. As was described earlier, this is necessary in the case where the target unit's 100 key list must be restored after some catastrophic data loss situation or in the case where the ownership of a particular target unit 100 is transferred to a different entity. This intervention on the part of the licensing authority 510 is also necessary in the case where the permanent ownership of a specific key is transferred from one target unit 100 to another. This ability of the owner to re-sell an asset, which was originally purchased from another entity, is known as the "right of first sale" and the ability for the protocol described herein to support this particular functionality is of importance. ^0088] Another important aspect of the fact that the target unit's 100 permanent key list is maintained by the licensing authority 510 is that this body has the ability to revoke any or all of an individual target unit's 100 license keys in the event that it is proven that the unit 100 has somehow been compromised or if one of the keys has been identified as having been compromised. Since the potential exists to give a unique list of keys to each and every target unit 100 (as was described above) , there could also provide an opportunity for the licensing authority 510 to track the source of any compromised keys. In such a situation, this protocol could fulfill the functionality that is normally associated with that of a "watermark" feature, but without the drawbacks of the traditional watermark process (such as the potential of the watermark to have an adverse effect on the quality of the media stream) .

^0089] Even though it may not seem to be the case, the digital content owner's privacy is still maintained by this process, since the application code or media stream specific ID information originates with the application developer 520 and the licensing authority 510 does not necessarily have enough information to be able to make the association between any particular application or media stream and its licensed owner. This ability to protect the users' privacy is also an important aspect of this protocol.

^0090] The final issue that should be noted about the permanent key transfer process is that it is, in fact, possible to accomplish all of the same functions that the permanent key transfer performs with a temporary key license transfer. However, the maintenance of the target units ' security system is a function which should ideally be controlled by a central secure server, so it is necessary to have such a mechanism in place somewhere in the chain. Also, in the case where the user is concerned about maintaining their privacy, the fact that the central server can act as a buffer between the copyright holder and the target unit 100 is of great utility. Finally, there is also the appeal that the licensing authority 510 is able to act as a central backup storage mechanism for a particular target unit's 100 permanent key list that sets this functionality aside from the temporary key transfer mechanism.

System Ownership Transfer, License Revocation and Security System Updates

^0091] There are several different means by which one or more of a target unit's 100 licenses (or keys) may be revoked. The simplest method is that of simply updating the target's 100 primary secret key. At this point, the target 100 would then be unable to access its permanent key list and thus, it would have to begin the process of creating a new one. Note that in the case where the primary secret key was not used in the encryption process for the temporary key list data structure, then this temporary key list could potentially still be accessed, even though the permanent key list might be otherwise inaccessible.

;0092] This point was mentioned earlier in the description of the encryption process for the temporary key list. For this reason, it is probably the best idea to use the target unit's 100 primary secret key as the encryption key for both the permanent and the temporary key list data structures.

^0093] In the case where the ownership of the target unit 100 changes from one individual to another, then the simplest manner to effect this ownership change is to set the unit's 100 primary secret key to some new value. However, if this occurs before the original owner has the opportunity to recover all of their permanent keys from the target, then they will lose their licenses. In the case where the original owner wishes to transfer the ownership of the associated permanent key list along with the target unit, then nothing need be done to the target unit 100 except to change the ownership information that is associated with that particular device (which is stored at the licensing authority 510 ) .

;0094] Another manner by which license revocation can occur is if the master key for a particular target unit's 100 permanent key list "expires". Since updates to the unit's 100 security system are stored as a part of the permanent key list, this situation could potentially have disastrous repercussions.

^0095] Although it would potentially be possible to recover from this predicament, it would require that the target 100 would need to have an entirely new "chain of trust" built from the ground up. In this situation, the core of the newly initialized security system would have to be based only on those computations that can be verified as being able to run atomically on some part of the target 100. Thus, this would preclude the use of any hashing function that required even the smallest amount of otherwise general-purpose code (which could potentially be suspect) . Fortunately, this situation can be avoided by the simple matter of always keeping a permanent core of verifiably secure code fragments as a part of the permanent key list data structure which does not expire. This is, itself a security risk, however, for reasons discussed above, so the contents of this permanent code core should be limited as much as possible.

^0096] Yet another manner of license revocation can occur if the licensing authority 510 chooses to override a particular key entry in a target unit's 100 permanent or temporary key lists. This could be used in the case where if a security system upgrade is required or in the case where a particular target unit 100 has been identified as having an unlicensed copy of a particular application or media stream. Since the target unit 100 normally maintains its own key list data structure, this procedure will involve a larger than normal amount of network traffic between the licensing authority 510 and the target unit. Thus, this course of action should be reserved for extreme cases. ^0097] Nonetheless, such a procedure can be accomplished by forcing the target device 100 in question to revise its security system software with a target-specific custom version that is designed to search for and disable the disputed key and/or then replace the older software with an updated version. Of course, this procedure can only be set in motion at the point when the target device 100 initiates a connection with the licensing authority's central server. Under normal circumstances, it cannot be guaranteed that any particular target unit 100 will initiate contact with the licensing authority 510 on any particular schedule. Fortunately, the target device 100 in question must connect with the licensing authority 510 (either directly or indirectly) in order to authorize any new additions to its permanent key list, so any key revocation actions can be accomplished as a part of the new key licensing procedure. It is also possible that the "security system timeout" mechanism mentioned earlier could be used to support this "list policing" action. However, it is not a requirement for this protocol that this is the case and it is likely that such a system would result in an erosion of the users' privacy rights.

Other Concerns :

^0098] There are a number of issues, which are not necessarily part of the protocol itself, but nonetheless must be addressed in the process of creating a practical system that is able to properly execute the protocol described herein. Some of these issues are dependent on the implementation of the actual processor device and others are mostly specific to the application. Since this information is germane to the proper construction of a suitable target device 100, we will discuss some of these issues in the following section.

Limits on the number of units which can interoperate

^0099] In the case where the copyright holder wishes to limit the total number of devices to which the primary target is able to temporarily transfer ownership, this may be accomplished by means of establishing a limited number of public/private key pairs that may be active at any one time. Note that this is different than the case where multiple copies of the same application specific key(s) were simultaneously "on loan", which was described in an earlier section. Other scenarios are possible, where the list of devices which are able to "check out" any of the application specific keys from a particular target device 100 can be limited to a certain set of serial numbers. The licensing authority 510 can administer such an "approved borrower" list in exactly the same manner that the target unit's 100 security system is managed. Thus, the licensing authority 510 could, for example, limit the set of serial numbers on the "approved borrowers" list to those who have the same ownership information as the original target device 100. Another possible solution to this problem is to require that any "borrower" device 720 be validated as an "authorized" borrower by presenting credentials (such as a signed certificate) to the lender which can be verified only by decrypting the certificate with the central Licensing Authority's 510 public key. This scenario would also, of course, involve the ability for the Licensing Authority 510 to revoke such a certificate in the case where a particular unit has been determined to be compromised. One well- understood method by which this certificate revocation process can be accomplished is via a regularly-published "revocation list".

Secret Key Discovery and Identity Verification Issues

If the primary secret key for a particular player is discovered by means of physical disassembly and chip die examination, then this should not compromise the security of any other device, since each device will have a distinct set of secret keys 104. However, if the primary key for a particular player were somehow compromised then it is potentially possible for an unlicensed device to masquerade as a legitimate target unit. In the case where this problem went undetected, the possibility exists that an unlicensed device armed with this knowledge could compromise any of the application specific decryption keys that were issued to that particular target unit. Since the target unit's 100 serial number 106 would have to have been registered in order for the licensing authority 510 to issue decryption keys to the device in the first place, the problem on this end would ostensibly be limited to the imitation of an otherwise legitimate target unit 100 by an unlicensed device .

;00101] If both of a unit's 100 secret keys were discovered by means of such a process, however, it is possible that it would be possible to compromise the security of all of the application specific keys which were licensed to that unit, based on an examination of previously backed up copies of the encrypted key list digests. For this reason, both the primary and the secondary secret keys should be implemented on target chip in a "tamper-proof" manner such that any attempt to discover the value of these keys results in the loss of the key data.

; 00102] There are a number of means by which this tamper-proof feature could be implemented on the target device 100, but the exact implementation of such is not of consequence to the protocol described in this document. If a "secret key loss" situation were to occur through some innocent act of negligence (or abuse) on the part of the user, the legitimate user should be able to return their damaged unit to the licensing authority 510 who could arrange to have the damaged unit's application specific keys transferred to a new device. It should be noted, however, that in the case where the original target device 100 is nonfunctional, the transfer of the keys to a new target device 100 must involve a transaction with the application developer 520 (at least for those keys which were not supplied to the licensing authority 510 in the clear in the first place) .

^00103] It should be noted, however, that a device which was able to impersonate an otherwise genuine target unit 100 could ostensibly be able to trick an unsuspecting legitimately licensed device into temporarily relinquishing ownership of one or more of its application-specific keys or into suspending operation (as was discussed earlier) . If the latter were to occur, then the possibility exists of having a "rogue unit" which could disable all of the units that attempted to borrow a key from it. If the former were to occur, then any number of application or media specific keys could potentially be compromised.

^00104] Thus, the concept discussed earlier of limiting the number of potential "licensed borrowers" for a particular target unit 100 to a list which was only able to be supplied to the legitimate unit by means of a secure update from the licensing authority 510 server is a prudent one. In the former case, this will prevent the owners of otherwise unsuspecting units from having their legitimate devices disabled by a hacker who takes apart a functional unit to gain access to its secret keys unless that unit actually belonged to them in the first place. In the latter case, this will limit the transfer of application or media specific keys to only those devices that were at one point licensed devices that were properly registered with the licensing authority. Nonetheless, the determined hacker could still purchase a legitimate unit, crack it open and somehow gain access to its secret key data and then use this information to masquerade as a legitimate device.

^00105] So, the issue remains of how to try to detect this kind of an impersonation event. The only successful strategy to defeat an extremely well financed opponent of this nature is to design the system such that the potential gain is not worth the effort required, at least from a cost-tradeoff standpoint . ^00106] There are several means of attempting to prove the authenticity of an otherwise unknown device with which one is communicating. However, the most successful method for proving that a device is, in fact, what it claims to be is to focus on the characteristics that make this device unique from other devices. In the case of a special purpose apparatus, such as a digital decryption mechanism, such as that described by this document, it would be the ability for the device to properly execute the security protocol and to calculate the correct result based on a given set of input variables. Since the security protocol described herein is based on publicly known algorithms, however, this could ostensibly be accomplished by any general purpose computing device, given that is has enough time to complete the computation. In fact, this issue will be a potential problem for any device that is based on publicly available technology, if the secret key information that makes the device unique is somehow compromised. Thus, we must ultimately rely on the precept that the secret key information which is stored on-chip for all of the legitimate target devices must remain secret, even in the face of disassembly and chip die inspection.

;00107] We can certainly add requirements to the target identification and verification process such as the ability to correctly come up with a verifiable MAC value within a certain amount of time. We could make the procedure even harder by requiring that the final MAC value be encrypted multiple times. Thus, we could potentially limit the ability of the attacker to imitate a legitimate device in that they would be required to have access to (more general) computational resources that would normally be much more expensive than the cost of simply purchasing legitimate copies of the licenses themselves. In the case of a media stream player, we could also include the ability to correctly decode a portion of one or more of the media streams which the player is ostensibly designed to accommodate .

^00108] In any case, however, the whole process of digital copyright protection is a Turing problem. Thus, given sufficient time and resources, any digital copyright protection scheme can possibly be defeated by the determined opponent. This is even independent, of course, of the fact that access to the secret key information would definitely be a big advantage to the would-be attacker. The ability to keep a unit's secret keys from being compromised is therefore an important part of this security protocol.

Conclusions :

^00109] The copyright protection protocol described above is unique in several ways. First is the fact that it does not attempt to prohibit the user from having the ability to make backup copies of their legally purchased application or media specific key data. Second, this protocol does not make a distinction between any kinds of digital data and thus, allows the security protocol to be updated as easily as the data streams that it is designed to protect. Third, this protocol allows the user to temporarily transfer ownership of their application or media specific key(s) to another unit that is capable of executing the protocol. Also, this protocol also provides the ability for the licensee to effect a permanent transfer of ownership from one target unit 100 to another. This last property allows the implementation of the consumer's legal "right of first sale" under this protocol.

^00110] In fact, one of the fundamental differences between the protocol described in this document and other copy protection schemes is that the security of this system depends not on controlling the ability to access a particular data set, but rather on the ability to control the act of expressing the ideas contained within that data set . 100111] In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of invention.

;00112] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component (s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

FIG. 1

210

APPLICATION-SPECIFIC DECRYPTION KEY DATA STRUCTURE

CODE OR MEDIA STREAM SPECIFIC ID (STORED IN THE CLEAR) -260

TIMESTAMP TIMESTAMP VALUE (STORED IN THE CLEAR) v230 MODIFIER FLAGS

TIMESTAMP MASK VALUE (STORED IN THE CLEAR) v240

COUNT-BASED MODIFIER FLAGS ITERATION COUNT (STORED IN THE CLEAR)

^250

FIG. 2

INTO TARGET'S CPU'S BLOCK. BY IS COMPARED ARE EQUAL, THEN AND IS IN SECURE MODE.

6/7 FIG. 7

FIG. 7A

FIG. 7B

7/7

FIG. 7B

J)¹¹BORROWER¹¹ AND "LENDER" DEVICES SET UP SECURE COMMUNICATIONS CHANNEL USING TEMPORARY PKI KEY PAIRS TO EFFECT SECURE TEMPORARY SECRET KEY EXCHANGE PROCESS. "BORROWER" DEVICE REQUESTS ONE OR MORE APPLICATION OR MEDIA STREAM SPECIFIC KEYS ALONG WITH A REQUESTED "LOAN DURATION" FOR EACH OF THE REQUESTED KEYS FROM THE "LENDER" DEVICE.

J)¹¹LENDER" DEVICE DETERMINES THAT IT IS IN CURRENT POSSESSION OF THE CORRESPONDING KEY(S) BY SEARCHING THROUGH ITS PERMANENT AND TEMPORARY KEY LIST DATA STRUCTURES. IF SO, THEN IT PLACES THE REQUESTED KEY(S) ON ITS TEMPORARY KEY LIST AS HAVING BEEN "CHECKED OUT" FOR A SHORT PERIOD OF TIME (THE "CHECKOUT NEGOTIATION TIMEOUT PERIOD") AND THEN RESPONDS TO THE "BORROWER" UNIT WITH AN ENCRYPTED LIST CONTAINING THE AVAILABLE KEY(S) ALONG WITH THEIR CORRESPONDING "LOAN EXPIRATION TIMES". THE VALUE USED FOR ENCRYPTING THIS KEY LIST IS A TEMPORARY SECRET KEY WHICH IS GENERATED ON THE FLY BY THE "LENDER" UNIT. THE NEW KEY EXPIRATION PERIOD IS BASED ON THE LESSER OF THE REQUESTED "LOAN DURATION" PERIOD AND THE MAXIMUM LOAN DURATION ALLOWED BY THE "BORROWER" UNIT.

T)¹¹BORROWER" UPDATES ITS INTERNAL KEY LIST TIMEOUT REGISTER TO REFLECT THE NEW LOAN EXPIRATION TIMES (IF NECESSARY). "BORROWER" THEN ACKNOWLEDGES THE RECEIPT OF THE ENCRYPTED KEY LIST AND OF THE NEGOTIATED "LOAN DURATION(S)" BY RETURNING A MESSAGE DIGEST CALCULATED FROM THE ENCRYPTED KEY LIST RECEIVED IN STEP 2.

J)¹¹LENDER" DEVICE EXTENDS THE "CHECKOUT PERIOD" FOR EACH OF THE REQUESTED KEYS AND THEN SENDS THE TEMPORARY SECRET KEY WHICH IT USED IN STEP 2 TO ENCODE THE KEY LIST TO THE "BORROWER" DEVICE.

J)¹¹BORROWER" USES THE SECRET KEY TO DECRYPT THE KEY LIST MESSAGE RECEIVED IN STEP 2 AND THEN UPDATES ITS TEMPORARY KEY LIST DATA STRUCTURE.

J)UPON EXPIRATION OF EACH OF THE TEMPORARY KEYS, BOTH UNITS

UPDATE THEIR TEMPORARY KEY LISTS AND KEY LIST TIMEOUT REGISTERS.