JP2013084294A - Method and system for recursive security protocol for digital copyright control - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system and method using a recursive security protocol to protect digital data.SOLUTION: The system and method may include a step for encrypting a bit stream with a first encryption algorithm, and a step for associating a first decryption algorithm with the encrypted bit stream. Next, an obtained bit stream may be encrypted by a second encryption algorithm so as to generate a second bit stream. Then, the second bit stream is associated with a second decryption algorithm. The second bit stream may be decrypted by an intended receiver by using a relation key.

Description

(Cross-reference of related applications)
No. 60 / 390,180 (named “Recursive Security Protocol System and Method for Digital Copy Control”, filed June 20, 2002, patent application “William V. Ox”). No. 10 / 465,274 (named “Method and System for a Recursive Security Protocol for Digital Copyright Control”, filed June 19, 2003, Applicant “William V. Oxford” “Method and System for a Recursive Security Protocol for igital Copyright Control ", filed on February 23, 2007, related to the applicant" William V.Oxford "). All applications cited in this paragraph are hereby incorporated by reference in their entirety.

(Technical field of the invention)
The present invention relates generally to the protection of digital content, and more specifically to the protection of digital data through the use of encryption. More specifically, the present invention relates to protecting digital content with a recursive security protocol that provides both superior security and flexibility over currently utilized methods.

(Background of the Invention)
Past copyright law implementations, whether printed books or recorded discs or tapes, relied on the difficulty of copying several physical objects. To be precise, it has always been possible for an individual to duplicate such an object, but considering either the time or opportunity costs of transferring information contained in a physical object to another, Was not economically feasible. Also, copies based on this process have tended to be of lower quality than the original. However, with the advent of digital storage of information, this cost balance has been confused.

  The value of a copyrighted work is not necessarily infused into the physical object containing the creation, but rather in the information that makes up the work itself. Thus, when the machine cost of copying a work is negligibly small (as is the case with many current digital media streams), the copyright protection process must deal with the problem in a new way. In essence, all creations that can be encapsulated in digital form are subject to this concern at some point.

  Even if it may be impractical to copy a given large digital data stream at this point, the cost of copying and storing such a data stream is the cost of transmitting those data over long distances. Like, it is always falling. Digital storage also makes it possible to make perfect copies that do not deteriorate over time or through repeated use. As such, the lifetime of these vast datasets can potentially overcome their economic feasibility, at which point whether the stream supports free distribution. Regardless, it is much less important. This length of feasibility places an upper limit on the amount of security that is appropriate for use in controlling access to data.

  The current state of the art in digital security algorithms is described in Patent Document 1, Patent Document 2, Patent Document 3, Patent Document 4, which is fully included in the present specification through careful reading of online information, It can be easily collected through various publications and patents that discuss this subject matter, including US Pat.

Prior art systems utilize several basic operational categories of digital data encryption and decryption techniques. These categories are based on the use of the security algorithm itself and are independent of the actual mechanism for encrypting or decrypting the actual data. These well-known techniques, as well as the widely described classifications and techniques, are as follows. One-way hashing mechanism and / or message digest message authentication system digital signature private key encryption system public key encryption system The means by which these techniques are used in a given security system is known as a security protocol. Note that the security protocol is independent of the actual underlying mechanism on how the various functions are performed. As such, even perfectly secure encryption algorithms may potentially be used inside security protocols that compromise overall security in a way that breaks the secure aspects of encryption technology. As a result, the overall security of any given security system depends not only on the relative strength of the underlying security technologies, but also on how these security technologies are used. Past attempts to implement security systems have made (artificial) distinctions between the various types of bitstreams that are protected.

US Pat. No. 6,327,652 US Pat. No. 6,330,670 U.S. Patent Application Publication No. 20020013772 US Pat. No. 6,226,742 US Pat. No. 6,101,605

David Lie, et al. , "Architical Support for Copy and Tamper-Resistant Software Software, Proc

  Thus, there is a need for a recursive security protocol that may utilize industry standard security techniques and other types of security standards to better and efficiently protect digital content.

  Disclosed are systems and methods for security protocols that may utilize various encryption techniques to better protect digital content. These systems and methods allow users to make backup copies of the original data as desired, but may still require the copyright owner's permission to use such copies, Allows any bitstream (such as an audio / video stream or other digital data such as a software application) to be encoded. In many embodiments, the bitstream is encrypted and the result is associated with a decryption algorithm. In turn, this combination is encrypted, and the result of this second encryption results in a second bitstream, which in turn is associated with a second decryption algorithm.

  In addition, a system is presented that embodies these types of methodologies with computer systems, hardware, and software suitable for implementing these security protocols.

  In some embodiments, each bitstream is decrypted using an associated decryption algorithm and one or more keys.

  In another embodiment, these keys may reside on the server, or the keys may reside in hardware on the target machine.

  In yet other embodiments, these keys are contained in a key data structure.

  Still other embodiments include a key list data structure that contains one or more key data structures.

  A more specific embodiment includes this key list data structure residing on a central server.

  In another set of embodiments, a message digest is used to determine whether the encrypted bitstream is authentic.

In other similar embodiments, a message digest is used to determine if the decrypted bitstream is authentic.
For example, the present invention provides the following items.
(Item 1)
A method for a recursive security protocol to protect digital content,
Encrypting the bitstream with a first encryption algorithm;
Associating a first decryption algorithm with the encrypted bitstream;
Encrypting both the encrypted bitstream and the first decryption algorithm with a second encryption algorithm to yield a second bitstream;
Associating a second decryption algorithm with the second bitstream;
Including the method.
(Item 2)
Further comprising decrypting the first bitstream and the second bitstream by the first associated decryption algorithm and the second associated decryption algorithm, wherein the decryption is accomplished by a target unit The method according to Item 1.
(Item 3)
The method of item 2, wherein the decrypting is performed using a key associated with each decryption algorithm.
(Item 4)
Item 4. The method of item 3, wherein the key resides in the hardware of the target unit or the key is retrieved from a server.
(Item 5)
Item 5. The method of item 4, wherein the key is contained in a key data structure.
(Item 6)
6. The method of item 5, wherein the key data structure also contains a time stamp and a countdown value.
(Item 7)
6. The method of item 5, wherein the key data structure is encrypted using a temporary key or a primary secret key.
(Item 8)
8. The method of item 7, wherein the key data structure is contained within a key list data structure.
(Item 9)
9. The method of item 8, wherein the target unit maintains a copy of the key list data structure.
(Item 10)
10. The method of item 9, further comprising encrypting the key list data structure using the temporary key or the primary secret key.
(Item 11)
4. The method of item 3, wherein each encryption algorithm is a symmetric key system or an asymmetric key system.
(Item 12)
4. The method of item 3, further comprising associating a first message authentication code (MAC) or a first digital signature with each encrypted bitstream.
(Item 13)
13. The method of item 12, further comprising generating the first MAC or first digital signature using a hashing function and a public key.
(Item 14)
14. The method of item 13, further comprising verifying that each encrypted bitstream is authentic.
(Item 15)
Validating each encrypted bitstream is
Generating a second MAC or second digital signature;
Comparing the second MAC or second digital signature with the first MAC or first digital signature;
The method according to item 14, further comprising:
(Item 16)
16. The method of item 15, further comprising verifying the decrypted bitstream.
(Item 17)
17. A method according to item 16, wherein verifying the decrypted bitstream is performed using a third MAC or a third digital signature.
(Item 18)
18. The method of item 17, further comprising returning an encrypted version of the key to the server.
(Item 19)
A system for a recursive security protocol that protects digital content,
Encrypting the bitstream with a first encryption algorithm;
Associating a first decryption algorithm with the encrypted bitstream;
Encrypting both the encrypted bitstream and the first decryption algorithm with a second encryption algorithm to yield a second bitstream;
Associating a second decryption algorithm with the second bitstream;
A system that is operable for.
(Item 20)
The first associated decryption algorithm and the second associated decryption algorithm are further operable to decrypt the first bitstream and the second bitstream, the decryption being performed by a target unit 20. A system according to item 19, achieved by:
(Item 21)
21. The system of item 20, wherein the decrypting is performed using a key associated with each decryption algorithm.
(Item 22)
Item 22. The system of item 21, wherein the key resides in hardware of the target unit or is retrieved from a server.
(Item 23)
24. The system of item 22, wherein the key is contained in a key data structure.
(Item 24)
24. The system of item 23, wherein the key data structure also contains a time stamp and a countdown value.
(Item 25)
24. The system of item 23, wherein the key data structure is encrypted using a temporary key or a primary secret key.
(Item 26)
26. The system of item 25, wherein the key data structure is contained in a key list data structure.
(Item 27)
27. The system of item 26, wherein the target unit maintains a copy of the key list data structure.
(Item 28)
28. The system of item 27, further operable to encrypt the key list data structure using the temporary key or the primary secret key.
(Item 29)
Item 22. The system of item 21, wherein each encryption algorithm is a symmetric key system or an asymmetric key system.
(Item 30)
28. The system of item 21, further operable to associate a first message authentication code (MAC) or a first digital signature with each encrypted bitstream.
(Item 31)
32. The system of item 30, further operable to generate the first MAC or first digital signature using a hashing function and a public key.
(Item 32)
32. The system of item 31, wherein the system is further operable to verify that each encrypted bitstream is authentic.
(Item 33)
Validating each encrypted bitstream is
Item 32 further comprising generating a second MAC or second digital signature and comparing the second MAC or second digital signature with the first MAC or first digital signature. The system described in.
(Item 34)
34. A system according to item 33, further operable to verify the decrypted bitstream.
(Item 35)
35. The system of item 34, wherein verifying the decrypted bitstream is performed using a third MAC or a third digital signature.
(Item 36)
36. The system of item 35, further operable to send an encrypted version of the key back to the server.
(Item 37)
Encrypting the bitstream with a first encryption algorithm;
Associating a first decryption algorithm with the encrypted bitstream;
Encrypting both the encrypted bitstream and the first decryption algorithm with a second encryption algorithm to yield a second bitstream;
Associating a second decryption algorithm with the second bitstream;
A software system or computer program for a recursive security protocol that protects digital content, containing instructions that can be translated for.
(Item 38)
Further translatable to decrypt the first bitstream and the second bitstream by the first associated decryption algorithm and the second associated decryption algorithm, the decryption being accomplished by a target unit 38. The software system or computer program according to item 37.
(Item 39)
40. The software system or computer program of item 38, wherein the decrypting is performed using a key associated with each decryption algorithm.
(Item 40)
40. The software system or computer program of item 39, wherein the key resides in the hardware of the target unit or is retrieved from a server.
(Item 41)
41. The software system or computer program according to item 40, wherein the key is contained in a key data structure.
(Item 42)
42. The software system or computer program of item 41, wherein the key data structure also contains a time stamp and a countdown value.
(Item 43)
42. The software system or computer program of item 41, wherein the key data structure is encrypted using a temporary key or a primary secret key.
(Item 44)
44. The software system or computer program according to item 43, wherein the key data structure is contained in a key list data structure.
(Item 45)
45. A software system or computer program according to item 44, wherein the target unit maintains a copy of the key list data structure.
(Item 46)
46. A software system or computer program according to item 45, further translatable to encrypt the key list data structure using the temporary key or the primary secret key.
(Item 47)
40. A software system or computer program according to item 39, wherein each encryption algorithm is a symmetric key system or an asymmetric key system.
(Item 48)
40. The software system or computer program of item 39, further translatable to associate a first message authentication code (MAC) or a first digital signature with each encrypted bitstream.
(Item 49)
49. The software system or computer program of item 48, wherein the software system or computer program is further translatable to generate the first MAC or first digital signature using a hashing function and a public key.
(Item 50)
50. The software system or computer program of item 49, wherein each encrypted bitstream is further translatable to verify that it is authentic.
(Item 51)
Validating each encrypted bitstream is
Generating a second MAC or second digital signature;
Comparing the second MAC or second digital signature with the first MAC or first digital signature;
The software system or computer program of item 50, further comprising:
(Item 52)
52. The software system or computer program of item 51, wherein the software system or computer program is further translatable to verify the decrypted bitstream.
(Item 53)
53. The software system or computer program of item 52, wherein verifying the decrypted bitstream is performed using a third MAC or a third digital signature.
(Item 54)
54. A software system or computer program according to item 53, wherein the encrypted version of the key is further translatable for returning to the server.

  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. However, it is to be understood that the following description is given by way of illustration and not limitation, while showing various embodiments of the invention and numerous specific details thereof. Many substitutions, modifications, additions and / or rearrangements may be made within the scope of the present invention without departing from the spirit thereof, and the invention includes all such substitutions, modifications, additions, And / or including relocation.

The drawings accompanying and forming a part of this specification are included to illustrate certain aspects of the present invention. The invention and the clearer concepts of the components and operation of the system provided by the invention will become more readily apparent by referring to the exemplary and therefore non-limiting embodiments illustrated in the drawings. In the figure, the same 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.
FIG. 1 is a block diagram of an embodiment of a security protocol engine. FIG. 2 is a representation of an embodiment of a decryption key data structure. FIG. 3 is a diagram of an embodiment of a security protocol encryption and distribution process. FIG. 4 is a diagram of a decryption and loading process for an embodiment of a security protocol. FIG. 5 is a diagram of one embodiment of a security protocol encryption / decryption process. FIG. 6 is a display of an embodiment of a key list data structure. FIG. 7A is a diagram of an embodiment of a temporary key ownership transfer procedure. FIG. 7B is a diagram of an embodiment of a temporary key ownership transfer procedure.

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

  Attention is now directed to systems and methods for security protocols aimed at protecting digital content. These security protocols support the concept of identity tracking that can be used with any digital content and is usually associated with traditional watermarking schemes without requiring the actual digital content to be modified. You can also Because these protocols are based on the premise that all digital bitstreams are equal, they can even be used in a recursive manner to control access to updates of the protocol itself. In other words, whether the data is protected media streams, executable code that needs to play those streams, or encrypted executable code that needs to play those streams, Whether the executable code, the key used with the decryption code, etc. need to decrypt the encrypted code that needs to play those streams, the protocol distinguishes the type of digital data do not do. Only the digital nature of these data is important to the protocol. Thus, because the nature and / or use of digital data is not related to the security protocol, the protocol can protect itself.

  This capability means that the security protocol can be updated (eg, to repair a recently discovered security hole) without requiring a change in the hardware on which it is operating, even during execution. The “older” security system is “included” as part of the newer security system (ie, the old protection “packaging” is never added to add a new, safer level of protection for the entire system. You don't have to remove it). Thus, the entire system is encapsulated in the latest and most secure encryption and / or access control system. Not only can new keys be added, but completely new security and / or encryption algorithms can be added to the top of existing systems as well.

  This flexibility allows the protocol to support a number of business models, including time-limited rentals, pay-per-view, multiple versioning, machine-dependent license revocation, and permanent transfer of ownership from one user to another.

  Although copyrighted software applications are utilized in the exemplary embodiments, the same method and system can be used to provide security for any bitstream, including video, audio data, source, and object code, It will be understood by those skilled in the art.

The basic functions that the security protocol embodiments are designed to provide include (but are not limited to) the following:
Fair use ("time shift", "space shift", and archive backup)
Temporary transfer of incremental upgrade ownership Permanent transfer time of ownership Limited access Use limited access (number of times used)
Device specific license revocation data or stream specific license revocation As noted above, the primary mechanism for protection of intellectual property contained in copyrighted work (at least for modern copyright control systems) is simple. It is access control. However, if such a mechanism is avoided, even the protection afforded by the most sophisticated access control mechanisms is of little value. This is not to say that access control is a useless mechanism, but that by itself is not a full security system. The fact that a large number of copyrighted media streams are freely available for public consumption on the Internet is evidence of the fact that such a security system can almost always be avoided. This type of access control also makes it more difficult to establish a mechanism to make a backup copy of a legally purchased copyrighted work that is necessary if the original is at risk of being destroyed. Thus, the security protocol described herein does not require any kind of access control system to be useful.

  The security protocol described is dedicated to controlling the representation of copyrighted work, not the digital data that makes up the work itself. As such, a protocol is a digital data that is used to encapsulate a copyrighted work or other digital data that is used to describe how the work is interpreted. Does not distinguish. As a result, the protocol can even be used to encapsulate other security protocols.

(Basic operation description :)
Security protocol embodiments are designed to allow one software author to have a high degree of confidence that their code is protected from being broken by those who attempt to copy or misappropriate the algorithm. Is done. They are also designed to protect this code from modification by anyone attempting to alter its functionality. One of the ways in which these key characteristics can be implemented in other general purpose computing systems is discussed in the following section. Additional assets generated as a by-product of these two main functions are the conditions under which the software can be run (ie, when, how, and on which machine or machines) Is the ability to control. The first of these functions may be achieved by adding an anti-tamper timer element to the system. The other is achieved by means of implementing a secure data structure that is used to indicate the desired condition that must be met to execute the block code in question. Since this data structure is not hardware specific, it can be used in a variety of ways and can be modified by updating the software used to interpret it. Discuss the hardware-specific features used to implement the protocol more efficiently and give examples of how these features can be used to support the protocol. Finally, it shows how the protocol can be used to protect copyrighted works.

  An embodiment of a security protocol relies on the ability to encrypt a block of code in such a way that it can only be decrypted by its intended recipient. This is a well-understood problem and the basis for many industry standard encryption algorithms. However, the fact that the core of the protocol is useful if it can fit within a (relative) small range of a typical on-chip instruction cache (I-cache), and the fact that it can operate in a semi-autonomous manner, such as There are two additional factors that should be considered for use with security protocol embodiments. In other words, it is useful if the protocol is small and does not require the use of a central security server for normal daily operations.

(hardware:)
The elements of the security protocol system may include a set of hardware blocks that implement the protocol in a secure manner on a protocol engine (also known as a “target unit”) 100. A general block diagram of an example of a device capable of executing this security protocol is shown in FIG. These blocks do not need to be put into hardware for the protocol to work correctly, but devices that include all of the hardware elements listed below can implement the protocol with minimal overhead. Become.

  The first of these hardware blocks is the real time clock 102. This is a free running timer that can be set or reset by a secure interaction with the central server. This is not a completely mandatory block, but it is more convenient to make this feature on-chip because time may be established by doing a secure time standard query. This has something to do with time-dependent software licenses, examples of such are given in later sections of this document.

  Another hardware element is a block of memory 110 that can store code to be executed on-chip. This is typically known as an I-cache, but in some embodiments, an important characteristic of each portion of the I-cache 110 is that the data contained in a block is stored in the CPU execution unit 120. Be readable only by. In other words, this particular block of I-cache memory 130 is dedicated to execution and cannot be read or written by any software. This special section of the I-cache is referred to as a “protected code block” 130. The manner in which the executed code is actually stored in this protected I-cache block 130 may be via another hardware element.

  In addition, there are other categories of possible “enhancements” that can be used to enhance the operation of secure code blocks. One of these is accessible only while the CPU 120 is executing secure code and / or upon completion of execution of a secure code block (or for some reason the execution unit is “normal” The ability to specify a set (partial) of CPU registers 140 to be erased (if jumped to any section of code from the I-cache). What may happen to the process of switching contexts when jumping to an interrupt routine, even though it may not seem possible for CPU 120 to execute a mixture of "protected" code and "unprotected code" And where the CPU 120 context is stored (most CPUs store the context in main memory where it is potentially subject to discovery at a later point in time by an unprotected code block) Must be considered.

  Another possibility (other than requiring the author of the protected code block to explicitly identify which register 140 is to be erased) is to have it done automatically. This keeps track of which registers 140 are read or written while the CPU execution unit 120 is executing inside the protected code block and then automatically at the end of the “safe” mode. It will be erased. This allows the protected code to “wipe” itself quickly so that only data that is allowed to be shared between the two types of code blocks remains intact. The “automatic” process may be potentially safer than the “explicit” procedure, but it allows code authors to share information between protected and unprotected code blocks. It may make the desired case more complicated.

  Another potential scheme for dealing with "leakage" of register stored data between safe and unsafe code segments is only used when CPU 120 is executing protected code Identifying a unique set of registers. For some CPU architectures with a large general purpose register set 140, this may seem terribly expensive at first. However, by using a modified version of the register renaming and scoreboard structure that is practiced on many modern CPUs, it does not require a tremendous amount of overhead (ie, a physically different set). The same effect can be achieved (without the silicon overhead involved in implementing the "safe" register). These issues are easy to address when treating protected code block execution as an atomic action (ie not interruptible), but this convenience comes at the cost of performance and potential overall code complexity. There is a case. Note that the “protected” portion 130 of the I-cache does not necessarily require a different data path to the CPU than the “regular” portion 150 of the I-cache. In fact, the two can be completely synonymous.

  A one-way hash function block 160 is also shown. It is possible to build an engine that can implement 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. The trade-off between the hardware and software implementation of this function block is discussed below.

  Another part of the target unit 100 uses the target unit's 100 private key and public / private key (discussed below) to affect the encrypted message to translate into an executable code block. It may be a wear assisted decryption system 170. The decryption system 170 can be implemented in a number of ways. Because the overall protocol speed and security can depend on the structure of this block, it is flexible enough to accommodate security system updates and allows the system to perform real-time code updates It should be fast enough.

  With these two constraints in mind, it is not important for the protocol which encryption algorithm is used for this hardware block 170. In order to facilitate maximum flexibility, the actual hardware is general enough to be used in a non-algorithm specific manner, but there are many different means by which this mechanism can be implemented. It is assumed.

  It should also be noted that there is an on-chip random number generator 180 shown in the block diagram with a dotted line. This block is optional. In addition, it can be replaced by a suitable on-chip method that produces an array of sufficient random numbers that can be used to provide seed values for a pseudo-random number generation system using software. This pseudo-random number generator can also potentially be implemented in hardware or “secure” software. Of course, the trade-off of the same principle of system flexibility using software compared to hardware implementation also applies here. However, if the target device 100 must generate a random number, it will not occur frequently with this protocol, so if this particular function is not hardware accelerated, it may affect the overall performance. Low.

(Secret key :)
Each protocol engine (“target” unit) 100 may have two sets of secret key constants 104 stored on-chip, neither of which is software readable. The first of these keys (the primary secret key) may actually be organized as a set of secret keys, only one of which is readable at any particular time. If the “ownership” of a unit is changed (eg the device containing the chip is sold or transferred), the primary secret key currently in operation is “erased” or overwritten with a different value Also good. This value can either be transferred to the unit in a secure manner or can already be stored in the unit in a manner that is only used when this first key is erased. . In effect, this will issue a new primary secret key to that particular unit when its ownership changes or if there is some other reason for such a change (such as a failed key) It is equivalent to a step. The only other place where this primary secret key value is stored is on the central server in the licensing authority.

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

  The secondary secret key may only be known to the target unit 100 itself (and thus not known to the licensing authority). In a sense, the target unit 100 does not even “know” its own secret key 104 because the CPU 120 of the target unit 100 has no access to the value of either the primary or secondary secret key. These keys are stored and used only within the security block of the CPU 120 of the target unit 100. It is a combination of both of these secret keys that enhances the overall security of the target unit. How they are used is described below.

  Another set of keys may operate as part of a temporary public / private key system (also known as an asymmetric key system or PKI system). This pair of keys 108 is generated on-the-fly and used to establish a secure communication link between similar units without central server interference. Since the security of such systems is typically lower than symmetric key encryption systems of equivalent key length, these keys 108 must be larger in size than the set of private keys 104 described above. Don't be. These keys 108 may be used in conjunction with values present in the on-chip timer block. Since these keys are generated on the fly, the manner in which they are generated depends on some kind of random number generation system 180. Finally, it should be noted that care must be taken to ensure that the generated key 108 is not included in the so-called “weak” key category. The particular set of keys that are considered “weak” depends on the particular encryption algorithm used.

(Operation details :)
The manner in which the embodiments of the security protocol operate includes system initialization, secure code generation and mass distribution, secure code loading and execution, configuration of key list data structures, temporary license transfer, permanent license transfer, system ownership transfer, It can be categorized into several different processes, such as license revocation and security system update. Each of these will be discussed in turn. However, it should be noted that the example below is chosen for the purpose of simplifying the discussion and is not necessarily the most efficient (or not the only) scheme that can implement this protocol.

(System initialization)
This is a step in which the 104 secret key of the target unit 100 is set to some initial value. This procedure can be accomplished in one of several locations for either of the two private keys, but either the serial number 106 or the private key 104 is changed for logistic reasons. The possibility should be the last step of the assembly process. If the serial number 106 of the unit 100 is stored off-chip, this procedure is most likely performed at the time of final assembly. If the unit serial number 106 is stored on-chip, it is most practical to perform this procedure at the end of the chip manufacturing process (ie, after the chip has been packaged), so post-production or burn-in By-products have the opportunity to sort out parts that don't work. In this way, the amount of data that must be kept safe is minimized. Since the security of the entire protocol may be based on the security of the secret key 104 of the unit 100, the initialization procedure should be undertaken when physical security is possible.

  The primary secret key should be initialized (or “burned” into the device) in a different procedure than that used to provide the secondary secret key. In practice, this secondary key is known at some point (because it is programmed into the unit at some point in the manufacturing process), but once it is stored on the target device 100, where is the unit with which it is associated? Should not be recorded. For audit purposes, a complete set of secondary secret key values, regardless of knowing which part holds which key (for testing randomness of distribution or for some other reason) May be potentially desired to be inspected. However, in order to maintain the secure nature of the system, the device that programs this secondary secret key into the unit is a means of associating the secondary secret key with either the first secret key or the serial number 106 of the target device 100. It is desirable to never have Also, both of these secret keys 104 should be implemented in a tamper-proof manner for the reasons described below. The order in which these two secret keys 104 are initialized is not important. After the initialization procedure described in the exemplary embodiment, the only location (other than on the actual chip) where the serial number 106 of the target device 100 and their associated primary secret key 104 are jointly located is the license authority. Should be on a secure server at 510.

(Safe code generation and mass distribution)
In one example scenario, assume that developer 520 wishes to produce an application to work under this protocol that can reasonably be run on a specific device without fear of disassembly. Each registered developer 520 can use a signed message authentication that can be used to communicate with the licensing authority server 510 and to authenticate any encrypted code blocks issued by the developer. It has a public / private key pair that is used to authenticate every message that is used to create a code (typically called a digital signature or MAC).

  After the application is debugged, it is encoded using application specific encryption algorithms and keys known only to the original developer. This application specific algorithm and key can be either an asymmetric (secret) key system or a system using an asymmetric (PKI) key. At the end of the block of encrypted code, the developer uses the private key of their issued public / private key pair (thus forming a unique digital signature for the encrypted code block) A digital signature (or MAC) signed by 520 is attached. Either the digital signature or the original MAC encrypted to form the digital signature and the corresponding code-specific ID number may be provided to the licensing authority. Application developer 520 may also choose to provide an appropriate decryption key as well (the trade-off of this decision is discussed in a later section of this document).

  Note that if the application specific algorithm is asymmetric encryption, it does not necessarily have to be encrypted using the same issued PKI key pair used to generate the message authentication code. However, the MAC stored at the end of the code block should be generated using a known hashing algorithm and must be signed using one of the developer's issued public keys. Must (thus forming a digital signature). This allows the target to verify the authenticity of the MAC using a known hashing function and public key.

  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 comprises a time stamp 230 and an associated mask value 240. The second contains a “countdown value” 250. The mask value 240 is used in conjunction with the other two fields 230, 250 to determine when the key is valid. An example of this structure is shown in FIG. 2 (but there are numerous means by which this same functionality can be implemented). Note also that the exact number of bits allocated to each of the fields is not protocol related.

  Note that the timestamp value 230 can be used in several ways, depending on the bit pattern stored in the timestamp mask 240 field. The timestamp mask 240 value allows the developer 520 to select some timestamp digits that are ignored when making a comparison with the current time of the target unit 100. However, as an example, assuming that the minimum resolution supported by the timestamp field 230 is 1 second, it starts from the time stored in the timestamp field 230 by masking the lower 5 bits of the timestamp data 230. A specific key data structure 210 can be generated that is valid only when used over the course of approximately 32 seconds. The overall functionality of the security protocol does not depend on the actual resolution of the least significant bits of the timestamp field 230.

  There may be other bits associated with the mask field 240, some of which may be used to indicate whether the key is valid before or after the value specified in the timestamp 230. Yet another mask field 240 bits can be used to indicate how the timestamp 230 and the “countdown” value 250 are associated. For example, this is because the intention of the application developer 520 is to limit the use of the software to a certain number of iterations either before or after a certain date, rather than simply relating to a certain date and time window. Useful if there is. Of course, the protocol is very flexible in this respect because any combination of these conditions can be constructed. In addition, additional flags can be included in this data structure to indicate other characteristics, such as how many legal copies of the key may be simultaneously distributed from the original target unit 100 to others. This is useful when multiple copy licenses are desired, such as found in digital libraries.

  A flow diagram representing one embodiment of the encryption process can be seen in FIG. 3 on the next page. Note that there is no substantial difference in the process used to distribute a digital media stream or software application (such as decryption instructions used to interpret the media stream). In any case, there are a number of different options for distributing the encrypted code blocks 310, 320 either via an online server or on a serialized disk (such as a standard DVD). In the latter case, the developer 520 can choose to pre-register (or not) the individual serial numbers of the mass-produced disks with the use permission authority 510. In doing so, the serial number can be permanently attached to the disc, either by burning into a burst cutting area (in the case of a DVD) or by inkjet imprinting in the case of a standard CD. Note that the developer 520 cannot embed these serial numbers in the data area of the CD or DVD because the same serial numbers are duplicated in all of the mass produced disks. This is another potential way to distribute a disc with an individual serial number if some type of blending formula is used and one part of the disc is mass produced and another part can be written once . In any case, machine-readable serial numbers are certainly preferred because they are less prone to errors in the registration process.

  If the developer 520 chooses not to authorize the use of the media serial number with the license authority 510, there may be some other scheme that can associate the proper encryption key with the application or media stream file. Accordingly, application developer 520 may register either a code-specific ID or an associated media serial number. In the former case, the application can be freely distributed (ie, not related to a specific publication format and media).

  In the case of an individual serial number mechanism, end-user privacy is maintained because the licensing authority 510 does not have an indication of which application (or media stream) is associated with which serial number. When developer 520 registers an application ID (or media stream ID) with its associated key, licensing authority 510 can know which applications or media streams are “owned” by a particular end user. It is. On the other hand, this potential lack of privacy is offset by the added convenience and cost savings that developers 520 do not need to manufacture and distribute physical media. Note that the term “physical media” does not necessarily mean a disc. This function can be similarly achieved by using a printed manual (or even a simple registration form) with an individual serial number sticker attached. All that is required is that the developer 520 must produce some physical object with a unique serial number that is purchased by the end user. The purpose of this serial number is to act as a “proof of purchase” and / or a software registration number. The following section discusses how this serial number is used in the protocol.

  For the example shown in FIG. 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 protocol requirement that this should be the case, either or both of the encrypted code blocks 310, 330 can be distributed online or by pressing a disc. However, in the case of a digital media stream, there is a high possibility that the media stream itself is an order of magnitude larger than the two blocks 310 and 320. Therefore, in that case, it makes the most sense to achieve at least this block distribution in the mass produced disk format. In many cases, such as to fit the accompanying encrypted code block 320 (which contains instructions on how to decrypt the first block) as well as the primary encrypted code block There may be enough room on the disc. It should also be noted that neither of the two datasets has the basic requirement that it must be distributed online because it cannot be changed after publication. As such, they are both well suited for distribution mechanisms using mass-produced disks. Having both on the same disk makes it easier to associate one with the other in a unique manner.

(Safe code loading and execution)
If the distribution mechanism is via an actual disc, the consumer can purchase the disc containing the application in exactly the same way as a traditional software purchase. Of course, the end user cannot run the encrypted code block that has not been modified on the processor of the “target” unit 100. When the user tries to run the application on the machine, the CPU 120 loads the encrypted software block and verifies that the code block in question is authentic with the software developer's public key. Use a digital signature ("signed" MAC) stored at the end of This is the case when the first hardware modification to another general purpose CPU 120 may begin to work. The process for loading and decrypting such a block of protected code is shown in FIG.

  In order to verify that the hashing function is calculated correctly (and that the comparison between the generated message digest and the “real” message digest is valid), the CPU 120 is in a safe manner. This hashing function must be executed. Thus, the hashing function may either be generated directly by the decoder hardware, or the hashing function itself must be calculated using a block of “safe” code and its behavior Cannot be tampered with by other “unsafe” programs.

  In the case of hashing with software, this block of secure code should be considered as part of the security system of unit 100, and as such, a secure block between unit 100 and licensing authority 510. Note that it may only be possible to download to the player via a transaction. Interestingly, the establishment of a “safe” hashing function can be achieved via the same protection protocol described herein. This recursive behavior on the front side of the security system allows a software version of this protocol to be extremely flexible (and therefore updatable) in its encryption / decryption architecture. .

  If message digest computation is fixed in hardware, some degree of security can potentially be gained, but this comes at the expense of flexibility. If a dedicated hardware block is used to generate the hash value, some vulnerability in the hashing algorithm is discovered at some point after the chip is manufactured (or if there is some bug in its implementation) At that time there is no opportunity to deal with the problem after the fact. This does not mean that some kind of hardware acceleration (such as a programmable S-Box structure) of a hashing function using software cannot be used to accelerate the process. In that case, however, the hardware should ideally be sufficiently versatile to support a wide variety of one-way hashing functions.

  However, the security of this protocol ultimately relies on the lowest level functionality provided as part of this secure code loading procedure. Sub-functions (such as secret keys or primitive operations used in hashing functions) are combined together in different ways to produce higher functionality such as signed message digests. In turn, these higher function blocks are used to provide higher utilities such as identity verification. This process of building higher functions on top of more primitive layers is known as building a “trust chain”. The flexibility of the system is to establish that security-related functions can be modified as low as possible within this hierarchy. However, at some point, the basic primitive operations on which this chain is based must be atomic in nature (ie, this is functionality that must be implemented in hardware). The exact selection of this point in the hardware data granularity is largely implementation details, and the overall operation of the protocol is independent of this aspect given the above conditions.

  Once the encrypted code block 310 is loaded into the memory space 110 of the target 100 and the message digest is calculated, the result is then stored in the digital code stored with the encrypted code 310 by the developer's public key. It is compared with the message digest calculated by decrypting the signature 340. If the two match, the target unit 100 is authentic with the encrypted code block 310 (or at least the code was distributed by the developer 520 whose public key was used to decrypt the digital signature). Can be convinced.

  At this point, the target 100 sends a secure message to the licensing authority 510 requesting a copy of the decryption key that is used in conjunction with the recently validated encrypted code block 310. As part of setting up a secure connection with the licensing authority 510, the target unit 100 generates a temporary public / private key pair (the public part of which is supplied to the licensing authority 510 server). Details of the key exchange procedure are well known and the exact mechanism by which this is accomplished need not be detailed in this discussion. In any case, because the overall network traffic between the target unit 100 and the central server at the licensing authority 510 consists of several key transfers, a code specific ID, and a MAC stored with it, Note that it is limited to reasonably small data sets.

  Assuming that the code-specific ID is recognized by the licensing authority 510, whether the application author has already provided an “unencrypted” copy of the decryption key requested by the licensing authority 510 Depending on how, there may be two possible action policies. If the developer 520 has not provided such information to the licensing authority 510, the central server will copy the temporary public key of the target device 100 to the application developer's server 520 (as well as the ID specific to the code in question). Is transmitted. At that point, the developer's server 520 may grant a license authorization with a message containing the requested decryption key (encrypted with the target's temporary public key) and a message digest generated from the properly decrypted code. Respond to 510 server. Thus, only the target device 100 can decrypt the message to obtain the decryption key, and the license authority 510 cannot access the decryption key in an unencrypted form.

  The message digest can be pre-computed and stored on the server of the license authority 520, but the fact that it may be provided by the developer 520 during the transaction is in the unlikely event that a hashing function (generates a message digest) Potentially used in case that changes). Should this happen, the developer 520 provides the license authority 510 with an updated version of the message digest of the decrypted code either before or after the actual transaction with the target device 100. There is a need to. Developer 520 must provide this information because license authority 510 should never have access to the original (decrypted) code. As mentioned above, the amount of network traffic between the license authority 510 server and the developer 520 server is still very small. The encrypted key received from developer 520 is then encrypted once more with the primary secret key of target device 100 prior to transmission from licensing authority 510 to the target.

  If the application developer 520 wishes to be “out of the loop” for the transaction between the license authority 510 and the target device 100, simply the unencrypted (unencrypted) form of the associated cipher A copy of the decryption key and the associated MAC for the decrypted code block (its value must be updated each time the hashing algorithm is changed) can be provided to the licensing authority 510. Thus, the central server at the licensing authority 510 can act autonomously and does not need to establish a communication link to the developer's server 520 to fulfill the key request from the target unit. However, this is a potential security risk for developers if the “unencrypted key” information is compromised.

  In this case, the unencrypted key is still encrypted both before transmission with the temporary public key of the target device 100 (as described above) and again with the target primary secret key. At this point, the target device 100 has the proper decryption key in double encrypted form. If the license authority 510 does not access unencrypted application-specific key 550 information, the secret key for each unit 100 should be known only to the license authority 510 and the private key for transmission is the target Since it is known only by 100, it should not be possible for anyone other than the intended target device 100 to replicate this key data in an unencrypted form.

  However, at this point, the encoded decryption key that the target 100 receives from the application developer 520 is still securely stored in a state that is visible to anyone at the target 100 (eg, stored in flash ROM, Or backup to hard drive). The problem is that the target device 100 must also store a copy of the temporary private key along with the encoded decryption key transmitted from the licensing authority 510. If someone in the licensing authority 510 gains access to these two data by any means, it has been decrypted (provided that it may also have access to the primary secret key of the target device 100 as well) It is potentially possible to reconstruct application specific keys 550.

  This is the point at which the secondary secret key of the target device 100 begins to be used. Recall that the secondary secret key is unknown to anyone other than the target unit 200. Thus, once a temporary private key is used to decrypt the key supplied to the target 100 from the licensing authority 510, it re-encrypts the application specific key prior to its use (and / or storage). The secondary secret key is used.

  The target can then use the application specific (unencrypted) key to decrypt the code block (or media stream). Thus, the only two places where the application code exists in unencrypted form are inside the “protected” portion of the original developer 520 itself and the I-cache 110 of the target device 100 ( It can only be executed there and can never be written back to memory in unencrypted form). This allows privacy between the user and the licensing authority 510. In other words, license authority 510 may not know what the user has a license for (a major privacy issue), but unit 100 is damaged, stolen, or inoperable. In some cases, it is still possible to act as a storage location (or backup) for the user's key list.

  As a check to verify that the decryption process was performed correctly, the message digest of the properly decrypted code is compared with the digital signature transferred from the original developer 520 to the target unit 100 through the licensing authority 510. Is done. As described above, this digital signature is created by encrypting a message digest of an unencrypted code block with the application developer's private key. Alternatively, this digital signature can also be encrypted again by developer 520 using another temporary public key 530 provided to licensing authority 510 when the connection is established. In any case, the correct message digest can be decrypted by the target device 100 by decrypting the digital signature with the developer's public key. If it matches the hash of this message digest decrypted code block, the code is considered authentic and can run on the target 100. This message digest may then be re-encrypted with the secondary key 540 of the target unit 100 for storage with the re-encrypted application-specific key 550. The overall flow of the key encryption / decryption process is outlined in FIG. 5 below.

  The final step in this procedure is that a newly encrypted version of the application specific key 560 is retransmitted to the licensing authority 510 server for storage purposes. This retransmission serves several purposes. First, it is a confirmation that the target device 100 has successfully decoded the code block. Second, the licensing authority 510 is encrypted in order to handle the end user suffering some catastrophic data failure and neglecting to make their own backup copy of the access key. You must have a copy of the key 560. The license authority 510 can then serve as a backup storage facility for any particular user. Yet another reason for this measure is to address the case where the owner of a particular target device 100 changes from one user to another or desires to upgrade the target device 100. This kind of permanent transfer of ownership can involve the transfer of all authorized application keys for that unit 100 (in which case nothing is done other than registering the unit under the name of the new owner). Need not be) However, if the user wishes to transfer the permanent ownership of the key data from the first device to the second device, this is a secure transaction between both the licensing authority 510 and the target device 100. May be achieved using.

  Other information that the target device 100 returns to the license authority 510 server is the message digest of the newly updated key list data structure 610 of the target device 100. This is a confirmation of the newly updated key list data 610 structure and to verify the equivalence of the key list data structure 610 associated with the specific target device 100 on the licensing authority 510 server and the target device 100. Also used for. The exact structure of this data structure is described in the following section. Also, the following sections discuss how the permanent transfer of ownership of a particular key or set of keys is achieved.

  At this point, it should be noted that the process outlined above is not the only way in which a protocol can be used to transfer an application specific key 550 from developer 520 to target device 100. For example, an 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 server of developer 520 and the license authority 510 server to contribute device specific encryption information to the transaction. There are numerous mechanisms that can operate this protocol in a secure manner, and the example discussed above is just one of these. However, what is common is that all three parties must work together to ensure that the key data transferred to the target 100 is only available to that target device 100. is there.

  Note that the key structure can be configured to have two pieces, a hardware specific part as well as an application specific part. It is not a requirement that these two pieces are completely inseparable. If so (cannot be separated), the above-mentioned characteristics are obtained. However, if there is a way to make key fragments operable independently, a comprehensive set of copies can be enabled and restrictions that can be independent of the actual code or actual target device 100 can be used. In other words, any developer 520 can publish an application or media stream that has no distribution restrictions but cannot be read and only executed. This can be useful if the licensing authority 510 wants to send a security system update that works on all devices regardless of the manufacturer. Another example of this is broadcasting a publicly available media stream while still maintaining copyright control of the stream. Similarly, publishers can distribute applications that run on only one specific target device 100 or set of devices that anyone can read and / or copy. This can be useful, for example, for sending the message “Update this particular class of devices”. Another possible application is to send an application that runs anywhere and has no restrictions on distribution. This is similar in nature to the step of issuing source code (ie open source) for a particular application. Different classes of security enabled by separable H / W specific and S / W specific key structures are illustrated in Table 1.

（キーリストデータ構造の構成）
特定の標的デバイス１００に許諾されているアプリケーションまたはメディア特有のキーのリストを含有する、データ構造６１０は、貴重な物品であり、所有者によってバックアップされることが可能となるべきである。個別キーは、（上記のような）標的の２次秘密キーで暗号化されるため、リストは、キーが許諾されるユニットにとって有益であるのみである。しかしながら、このデータ構造６１０が改ざん、破損、および／または完全な損失の恐れがないことを確認できる必要がある。損失したキーリストデータ構造６１０の場合、前述のように、使用許諾権限５１０から、その特定の標的デバイス１００に対するキーリスト６１０の新しいコピーを要求することによって、データ構造６１０全体を回復することができる。キーリストデータ構造６１０に一時的変更が行われた場合（そのようなシナリオの理由をこの後の項で論議する）、プロトコルは、一時的であるような変更を識別するための手段に適応してもよい。最終的に、キーリストデータ構造６１０の真正性、適時性、および有効性を立証するための何らかの一義的な機構を含む。

(Structure of key list data structure)
A data structure 610 containing a list of application or media specific keys that are licensed to a particular target device 100 is a valuable item and should be able to be backed up by the owner. Since the individual key is encrypted with the target's secondary secret key (as described above), the list is only useful for the unit to which the key is granted. However, it should be possible to verify that this data structure 610 is not subject to tampering, corruption, and / or complete loss. In the case of a lost key list data structure 610, the entire data structure 610 can be recovered by requesting a new copy of the key list 610 for that particular target device 100 from the licensing authority 510 as described above. . If a temporary change is made to the key list data structure 610 (the reason for such a scenario is discussed in a later section), the protocol adapts to a means for identifying such a change that is temporary. May be. Finally, it includes some unique mechanism for verifying the authenticity, timeliness, and validity of the key list data structure 610.

  With these requirements in mind, a secure key list data structure 610 can be constructed that shows all of these qualities in a manner like that shown in FIG. 6 on the next page. As an example, the example shown below is not the only way that such a data structure can include all of the desired properties. Nevertheless, the particular data structure illustrated in FIG. 6 actually meets all of the basic requirements of the protocol.

  In the above diagram, there are some basic rules to keep in mind. First, the top-level encryption of the key list data structure 610 should be performed with the primary secret key of the target device 100. There are several reasons for using this particular key, but the main problem is that if the local copy of this data structure must be repaired, the licensing authority 510 is independent of the target device 100. In addition, it must be able to reproduce the encrypted form of this data structure. If any other key is used to encrypt this data structure (eg, the target's secondary secret key, etc.), when the target 100 needs to change the data structure (the key is listed) As when added), the entire list must be transferred to the license authority 510 for backup purposes. This can greatly increase the amount of network traffic that must be returned to the licensing authority 510 and is not necessarily the most efficient use of channel bandwidth.

  Also, this key list data structure 610 is preferably used for storing security system related keys in addition to storing license keys specific to standard applications or media streams. This data structure can be played by the licensing authority 510, so if it is desired to update the security software running on the target device 100, the same key list data structure 610 can be used for both functions. Both safer and more efficient (in terms of code storage requirements for the target device 100).

  A second problem is that the encrypted version of the key list data structure 610 includes a message digest of the original key list data structure 610. Note that although each individual key is encrypted, other parts of the list itself are not separately encrypted when the message digest is calculated. After the message digest calculation, the entire key list data structure 610 (including the message digest) is encrypted with a key value and algorithm identified by the top (or master) key. This is done to prevent malicious third parties from tampering with the list, calculating a new message digest, and then substituting the modified list for the authentic list. Once the key list data structure 610 is read into the memory space of the target unit 100, the authenticity and validity of the key list itself in the same manner that MAC is used for any other secure encrypted code block. This (decrypted) message digest is used to verify The fact that all elements other than the individual key are only encrypted with the master key allows the list to be examined (and maintained) without having to access any key other than the top key Means. Also, the key list inventory can be compiled with only a single pass through the decryption block.

  A third principle of interest is that the individual application code or media stream specific key can be large enough to accommodate the individual key for each target device 100. If the code or media stream is distributed via a mass produced disc, this means that the application developer 520 needs to issue a new code specific ID along with the individual decryption key. This may not be very efficient in terms of trying to minimize the amount of data that has to be transferred between all parties involved in the licensing process, but it tracks the compromised decryption key Add functionality to the protocol, including but not limited to the ability to This is also discussed in the following sections dealing with key revocation.

  The next issue to note is that the header of the key list data structure 610 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 the master key 620 for the rest of the key list data structure 610 itself. Therefore, as long as this key can be used to determine management of the rest of the list, the same principles of operation can be applied. This includes time dependency management of the security system of the target device 100. Therefore, the target unit 100 is forced to update its security system at predetermined intervals, which is an extremely powerful concept.

  There is also the possibility that the key list can contain multiple sections, each with its own master key 620 (list header) and thus with its own independent encryption mechanism. Like any other key, the list header contains a code-specific ID field that can point to an encrypted code block that is used to interpret the key list data structure 610. The entire list can then be contained in yet another master list, including its own master key (another list header). Accordingly, the entire key list data structure 610 can be recursively defined. As described above, this recursive property can be used to update the security system by creating a new key list data structure 610 to address the shortcomings of previous versions of the same data structure. Because the entire list security is contained within the “outermost” (or latest) security layer, the security of the entire key list data structure 610 is always based on the latest iteration of the security software.

  Thus, the recursive nature of the key list data structure 610 is a powerful feature. It is also because the exact implementation of the data structure discussed in the previous section is not the most important. The description provided above is merely an example that includes features that are the minimum part of functionality required to make the recursive nature of the protocol work.

  Regardless of how it is structured, the key list 610 may be maintained and / or updated under some common circumstances. These situations include (but are not limited to) when the state of one or more of the keys contained in the list is modified. There are several basic mechanisms that can transfer ownership of a particular key 210 from one unit to another, and these are discussed in the following sections. However, in any case, the mechanism by which the revised key list is maintained is divided into two categories: those that require the interference of licensing rights 510 and those that can be performed independently. Can do.

  One of the main operational concepts on which this protocol is based is to minimize the amount of network traffic required between the central server of the licensing authority 510 and the individual target unit 100. Accordingly, any temporary changes to the key list data structure 610 (for reasons explained below) should be able to be maintained independently by the target unit 100. The main reason for this is that these changes are more obvious than permanent changes in the device's security system (always should be achieved only by interaction between the target device 100 and the licensing rights). It also happens frequently.

  In any case, there must be some mechanism that allows the target device 100 to track the current state of the master key list data structure 610 in a unique manner. This can be accomplished by having two “master” lists. The first of these two lists (referred to as the permanent key list) is maintained by the licensing authority 510. This list relates to “permanent” ownership of the application-specific key associated with the target unit 100 in question. The second list is equally important, but relates to a temporary modification of the “permanent” key list data structure 610. Note that these modifications can either be added to the list or removed from the list. There are no necessary differences in the implementation of the data structures of the two lists themselves, the main differences occur depending on how they are used. It is desirable that there should be some way for either one or the other of these lists to recover the target unit 100 from a lost event. This loss may be due to some catastrophic failure or if the information contained in one of the lists is somehow corrupted (either maliciously or maliciously). obtain. The implications of such a “key list corruption” event are discussed in the following sections. Although it is necessary to be able to repair the permanent list by connection with the license authority, it is not necessary (even undesirable) that the license authority 510 can recover the temporary key list of a particular target device 100. There are many reasons for this view, but the main reason is that the temporary key list is likely to be updated much more frequently than the permanent key list, and the central licensing authority 510 and the target unit 100 It is desirable to keep the amount of network traffic required between and the absolute minimum. Nevertheless, it may be potentially desirable for a number of reasons (some of which will be discussed later) that the licensing authority 510 can make modifications to the temporary key list of a particular target 100. In this case, it would be desirable to encrypt this list using the primary secret key of the target device 100 (known to the licensing authority 510).

  As mentioned above, the integrity of both of the key list data structure 610 can be verified by using a signed message digest (digital signature) that is stored with the list itself. The implementation of the secure code mechanism used to generate this message digest is described in the previous section and the procedure need not be repeated again. A procedure for recovering the permanent key list data structure 610 in the event of loss and / or corruption has also been described. The only remaining issues that must be addressed are how to interpret the time-dependent part of the temporary key list data structure 610, and what if the temporary key list is somehow unavailable. To deal with.

(Temporary license transfer)
This is one of the sections of the security protocol where the use of the timestamp field 230 is important. As described above, the temporary key list data structure 610 is constructed in exactly the same manner as the permanent key list of the target device 100. However, there are some differences between the two. The first difference is that the temporary key list can potentially be encrypted with any one of the target unit's 100 private keys. Under normal conditions, it is not necessary for the licensing authority 510 to be able to reconstruct this data structure, so it is irrelevant which of the keys is used to encrypt it. . However, if this list was also encrypted using the primary secret key of unit 100, it would potentially be useful for licensing authority 510. The reason for this has to do with license revocation, and the situation is discussed in the following sections.

  The second (and most important) distinction between the temporary and permanent key lists is that a copy of the timestamp value 230 associated with the temporary key list data structure is also stored within the target device 100. This register is not software readable and is part of the security block, so it can only be overwritten by secure code. The value in this register is used to determine what to do if the temporary key list data structure is somehow lost and / or corrupted. The procedure is discussed later in this section.

  Yet another distinction between a temporary key list and a permanent key list is that the target unit 100 can (temporarily) transfer ownership of a particular key from the permanent list to the temporary list of the unit 100, whichever A device (operating simultaneously) also cannot transfer ownership of a particular key from its temporary key list to any other key list. This of course includes not only the temporary key list of other units, but also the permanent key list unique to the target 100 as well. This means that only the permanent owner can determine who (and when) will be able to “borrow” any particular key. Note, however, that this “lending” period can be indefinite (and this transaction can be performed without having to contact the licensing authority). This “permanent lending” feature is equivalent to the standard “copy once” functional requirement that is part of the most modern digital copyright control information (CCI) system.

  The procedure for transferring “key ownership” is somewhat similar to the procedure for borrowing a copy of a book from a library. When a “borrower 720” requests a temporary use of a specific application-specific key 550 from a permanent owner (“lender 710”), the lender 710 first asks for the use of a specific key for the duration of the key borrowing negotiation process. Produce an updated temporary key list for yourself, prohibit. This action prohibits two or more borrower 720 units from requesting the same key. The presence of a “borrowed key” on the lender unit 710's temporary key list is effectively used as a semaphore to control access to any particular key. However, the initial amount of time that the key is placed at the “limit” should be limited to a relatively short period of time. This is to prevent the borrower 720 device from requesting access to a particular key for a long period of time and then illegally monopolizing the use of the particular key, thereby preventing the transaction from being completed for any reason. This relatively short borrowing negotiation stage timeout also helps counter malicious devices that may be trying to mount the equivalent of a “denial of service” attack on lender unit 710. In fact, the lender unit 710 can optionally request from a device that is not on its “approved borrowers” list, or in the unlikely event that any one of these units is too many requests within a certain period. You can ignore the request if you try to do this. The exact length of time that this temporary block is placed on the key is not critical, but should be long enough to allow any given borrowing procedure to be completed. This period can be extended during high network traffic or latency. A detailed flow diagram depicting the temporary “key borrowing” procedure is shown in FIG.

  If two copies of a given key can be borrowed at the same time, a temporary key on lender device 710 to indicate how many copies of the given key are borrowed at any one time Note that the appropriate fields in the list can be used. Once borrower 720 and lender 710 negotiate a specific borrowing period for a given key, lender 710 sends an encrypted copy of key 740 to borrower 720. This encryption is performed using a temporary secret key 730 known only to the lender device 710. The borrower 720 then confirms the correct receipt of the encrypted key (using a message digest calculated from the encrypted message) and the lender 710 determines the “lending period” of the borrowed key. Extend and send temporary private key 730 to borrower device 720. The maximum duration of this lending process is not critical to the operation of the protocol, and there are some tradeoffs that must be made in selecting this value. These specific issues are repeated later in this section. In the above example, it is assumed that the “borrower 720” and “lender 710” devices can negotiate the actual length of the borrow period for each key, but this is certainly not a protocol requirement.

  Just prior to the time when either the borrower 720 or the lender 710 is updated, a copy of the timestamp value 230 associated with the new temporary list is stored on the target 100 in a non-volatile manner. At that point, the encrypted version of the temporary key list data structure can be safely written to memory (or onboard NVRAM, flash ROM, or some other 750 backup file on some hard disk, etc. Stored in some other more permanent location). Since the temporary key list is potentially read and updated much more frequently than the permanent key list, it is desirable that this list should be quickly accessible to the target unit, so the access latencies are compared. It is recommended that this list be stored in at least one short place (but not the actual requirement of the protocol). On the other hand, it is possible that the only place where this list is stored is some volatile storage medium (such as DRAM), as power failures can potentially cause a loss of functionality of the unit 100 over an indeterminate amount of time. Not recommended. This problem will be described in detail later in this section.

  When the borrowing period for a particular key expires, both the borrower 720 and the lender 710 device can independently update their temporary key list database. Therefore, it is not a requirement that the borrower 720 is in contact with the lender 710 unit to “return a particular key to circulation”. This is a major convenience factor when the borrower 720 and lender 710 devices are far apart. Of course, the security of this operation may depend on a very close correlation between the on-chip clocks used to generate and control the key timestamp records. The time / date clock must therefore be an integral part of the security system and as such should be able to be overwritten by transactions with the central server. In addition, the clock is designed to be robust enough to resist tampering when a malicious user attempts to modify the internal timestamp value 230, and to survive normal system power failures. It must be. Because it is not impossible to assume that this clock is battery-powered and that the battery can be removed or run out of battery over time, the system potentially It should be designed in such a way that it can be resumed and reset by interaction.

  Thus, a situation has been described in which ownership of a key 550 specific to a particular application can be temporarily transferred from one unit to another. At the end of the “lending period”, both the “borrower 720” and “lender 710” units may update their temporary key list data structure to reflect the “return” of the key to the original owner. it can. Note that this procedure can be performed independently on both units and therefore does not require interaction between the two devices.

  Here, one or more of the temporary key list data structures must be dealt with if damaged or / and lost while one or more keys are “borrowed” or “lending”. On the “lender 710” unit side, when a key is borrowed, the first thing it does is determine the end of the “lending” period. This value is clearly constructed by adding the duration of the loan period to the value of the current time / date field. This time / date value is then compared to the value 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, the new value is overwritten instead of the old value. Since this same process is used on the “borrower 720” side, the result is that, for any given target unit, the temporary key list timestamp is always stored as part of the temporary key list for a particular unit 100. The latest one of the time stamps.

  If the temporary key list of unit 100 is lost or tampered with, both the temporary key list and the permanent list will be invalid until this "latest timestamp" value expires. At that point, the unit can then start again using the permanent key list and can begin the process of rebuilding a new temporary key list.

  Thus, if the temporary list of devices has been tampered with or deleted, the unit is effectively disabled until the timeout period expires. While this timeout procedure may appear to be unnecessarily restrictive, any failure that occurs as a result of some malicious activity or during the transfer of a key from one unit to another (power failure or Avoid the potential problem of multiple copies of any particular application specific key that exists due to network connectivity outages, etc.). Also, the possibility of some such effects as a result of tampering with the temporary key list data structure should help prevent practice.

  In this regard, there are a number of optional additional features that can be used to enhance the operation of the protocol. One such possible option is a signature generated from either (or both) of the encrypted key list data structures 610 into a value stored in the on-chip security section of the target unit. Is to add a signed message digest (digital signature). The MAC value resulting from the decryption of the digital signature can be used to quickly verify the validity of any of the particular key lists without having to go through the entire decryption process. However, the problem with multiple nested key lists is that it is possible that this decryption procedure must be performed multiple times at some point in order to ultimately produce an unencrypted key. It means high, so that these digital signatures are stored on-chip is not critical to the operation of the protocol.

  Another enhancement possibility is to store a pair of on-chip timestamp 230 values rather than just one. An additional time stamp 230 may be used to indicate the earliest (next) time at which the temporary key list must be updated. This makes it easier for the target device 100 to determine when it needs to revise its temporary key list, since there is no need to constantly check the list (which involves going through the decryption process). This feature is very useful, but again is not a basic requirement for a unit to be able to run this protocol. However, if a system containing this second timestamp is implemented, it raises the possibility of confusion if the two timestamps are “out of sync” for some reason. One such example that comes to mind is when there is a power failure that occurs immediately after one such timestamp is written, but before the second is updated.

  The final issue to be addressed is what is the minimum and maximum limits for these temporary key list timestamp values. On the other hand, a larger limit on the maximum “temporary lending period” may allow a user to transfer the use of a particular data application (or media stream) from one unit to another over a reasonably long period of time. This is potentially useful if the user wishes to transfer ownership of the media stream from the “home unit” to the portable unit. Having a long “borrowing period” allows the user to take a portable unit (with its associated temporary key) for a long trip without having to contact the original “lender” unit 710 It becomes possible. The disadvantage of a long “borrow” period is that if something happens to the temporary key list data structure on the original unit, that unit is potentially invalid for a long period of time.

  This last issue also points out a potential danger to the target unit 100 if one malicious code can set the value of the on-chip timestamp register to some uncertain value. This could potentially be equivalent to invalidating the target of the attack, so the value of this timestamp register should only be able to be written by a “safe” code block. Again, since each unit has a different set of secret keys, the discovery of the secret key data 104 for one particular unit 100 is the other, except when a malicious device effectively disguises a legitimate unit. Should not cause interest in the unit. This mode of attack will be discussed in the following sections dealing with the issues related to identity verification.

(Permanent license transfer)
Many of the elements of this procedure were discussed in previous sections of this document. FIG. 5 shows the basic process in which a unique key is permanently transferred from one unit to another. In many respects, this procedure is essentially similar to the procedure for temporary transfer of key ownership, as described in the section immediately preceding this section.

  The main difference between the two procedures is that the permanent transfer is a simpler process than the temporary transfer, and the permanent key ownership transfer procedure takes advantage of the interaction between the licensing authority 510 and the target unit 100. It may be. The reason why the permanent transfer process is simpler is the fact that it does not require borrowing period negotiation, which is a prerequisite in the temporary key borrowing procedure. The reason that the permanent transfer function utilizes the interaction between the license authority 510 and the target unit 100 is due to the fact that the updated key list data structure must be reconstructed at both ends of the transaction. Is.

  Permanent license transfers typically occur through interaction with the licensing authority 510, so there is a record of which application or media stream specific key belongs to which target unit. As mentioned above, this is the case when the key list of the target unit 100 must be repaired after some catastrophic data loss situation, or when ownership of a particular target unit 100 is transferred to a different entity. is necessary. This interference on the licensing authority 510 side is also necessary if the permanent ownership of a particular key is transferred from one target unit 100 to another. The ability of an owner to resell an asset originally purchased from another entity is known as a “first sale right” and the protocol described herein supports this particular function. Is important.

  Another important aspect of the fact that the permanent key list of the target unit 100 is maintained by the licensing authority 510 is that the unit 100 is somehow proven to be compromised, or the key is compromised. The main body has the ability to revoke any or all of the license keys of the individual target unit 100. Because there is a possibility of giving every target unit 100 a unique list of keys (as described above), the licensing authority 510 may also provide an opportunity to track the source of the compromised key. In such situations, this protocol may perform the function normally associated with the “watermark” feature, but without the disadvantages of traditional watermarking (such as the possibility that the watermark adversely affects the quality of the media stream).

  Even though it may not seem true, application code or media stream specific ID information is generated from the application developer 520 and the licensing authority 510 allows any particular application or media stream and its license owner to The privacy of the digital content owner is still maintained by this process, since it does not necessarily have enough information to allow associations between them. The ability to protect user privacy is also an important aspect of this protocol.

  The final issue to note about the permanent key transfer process is that it is actually possible to achieve all of the same functions that a permanent key transfer performs by temporary key license transfer. However, since maintaining the security system of the target unit 100 is a function that should be ideally controlled by a central secure server, it is necessary to install such a mechanism somewhere in the chain. Also, the fact that the central server can serve as a buffer between the copyright owner and the target unit 100 is very useful if the user is concerned about maintaining privacy. Finally, the licensing authority 510 also has the appeal of being able to act as a central backup storage mechanism for the permanent key list of a particular target unit 100, excluding this function from the temporary key transfer mechanism.

(System ownership transfer, license revocation, and security system update)
There are several different means by which one or more of the licenses (or keys) of the target unit 100 may be revoked. The simplest method is to simply update the target 100 primary secret key. At this point, the target 100 becomes inaccessible to its permanent key list and therefore must start the process of creating a new one. If the primary private key is not used in the encryption process for the temporary key list data structure, this temporary key list will still remain, even if the permanent key list may otherwise be inaccessible. Note that it can be accessed. This point was mentioned earlier in the description of the encryption process for the temporary key list. For this reason, it is probably best to use the primary secret key of the target unit 100 as the encryption key for both permanent and temporary key list data structures 610.

  If the ownership of the target unit 100 changes from one individual to another, the simplest way to accomplish this ownership change is to set the primary secret key of the unit 100 to some new value. However, if this occurs before the original owner has the opportunity to recover all of the permanent keys from the target, the license is lost. If the original owner wishes to transfer ownership of the associated permanent key list along with the target unit, other than changing the ownership information associated with the specific device (stored in the licensing rights) In addition, nothing needs to be done to the target unit 100.

  Another manner in which license revocation can occur is when the master key for a particular target unit 100's permanent key list “expires”. This situation can potentially be catastrophic because updates to the unit 100 security system are stored as part of the permanent key list.

  Although it is potentially possible to recover from this remote location, it requires that the target 100 require a completely new “trust chain” that is thoroughly constructed. In this situation, the core of the newly initialized security system must be based solely on calculations that can be verified as being able to operate atomically on a portion of the target 100. This therefore eliminates the use of any hashing functions that required even a minimal amount of other general purpose code (which could potentially be suspicious). Fortunately, this situation can be avoided by the simple matter of always keeping a permanent core of code fragments that is verifiable and secure as part of the permanent key list data structure 610.

  Yet another manner of license revocation can occur if the licensing authority 510 chooses to ignore certain keystrokes in the target unit 100's permanent or temporary key list. This can be used when a security system upgrade is required or when a particular target unit 100 is identified as having an unauthorized copy of a particular application or media stream. Since the target unit 100 typically maintains its own key list data structure 610, this procedure involves a greater amount of network traffic between the licensing authority 510 and the target unit than usual.

  Nonetheless, such a procedure is a target-specific custom version that is designed to find and invalidate corrupted keys and / or replace old software with updated versions. This can be accomplished by forcing device 100 to revise the security system software. Of course, this procedure can only be triggered when the target device 100 initiates a connection with the central server of the licensing authority 510. Under normal circumstances, it cannot be guaranteed that any particular target unit 100 will begin contacting the licensing authority 510 according to any particular schedule. Fortunately, the target device 100 in question must connect to the licensing authority 510 (either directly or indirectly) to authorize any new additions to its permanent key list, so any The key revocation action can be accomplished as part of a new key authorization procedure. It is also possible that the aforementioned “security system timeout” mechanism can be used to support this “list monitoring” action. However, this is not a requirement for this protocol, and it is likely that such a system will violate the privacy rights of the user.

(Other concerns :)
Although not necessarily part of the protocol itself, there are still a number of issues that must be addressed in the process of creating a particular system that can properly implement the protocol described herein. . Some of these issues depend on the actual process or device implementation, others are largely application specific. Since this information is closely tied to the proper configuration of the preferred target device 100, some of these issues are discussed in the following sections.

(Limit on the number of units that can interact)
If the copyright owner wishes to limit the total number of devices that the primary target can temporarily transfer ownership to, this is a limited number of publications that may be in effect at any point in time. / May be accomplished by establishing a private key pair. Note that this differs from the case described in the previous section where multiple copies of the same application-specific key were simultaneously “lending”. Other scenarios are possible, in which case the list of devices that can “borrow” any of the application-specific keys from a particular target device 100 is limited to a set of serial numbers. Can do. License authority 510 can manage such an “approved borrower” list in exactly the same manner in which the security system of target unit 100 is managed. Thus, the licensing authority 510 may limit, for example, a set of serial numbers on the “approved borrower” list to those who have the same ownership information as the original target device 100.

(Problems of secret key discovery and identity verification)
If the primary secret key for a particular player is discovered by physical disassembly and chip mold inspection, this should not compromise the security of any other device because each device has a different set of secret keys Absent. However, if the primary key for a particular player is somehow compromised, it is potentially possible for an unauthorized device to impersonate a legitimate target unit. If this problem remains undetected, there is a possibility that an unauthorized device equipped with this knowledge could compromise any of the application-specific decryption keys issued to that particular target unit . Since the serial number of the target unit 100 must first be registered in order for the licensing authority 510 to issue a decryption key to the device, the problem for this purpose is that Limited to legitimate target unit 100 limitations.

  However, if both of the unit's 100 private keys 104 are discovered by such a process, the application-specific license granted to that unit based on the examination of a previously backed up copy of the encrypted key list digest. It may be possible to compromise all security of the key. For this reason, both primary and secondary secret keys should be implemented on the target chip in a “tamper-proof” manner so that attempts to discover the values of these keys will result in loss of key data. is there.

  Although there are numerous means by which this tamper-proof feature can be implemented on the target device 100, the exact implementation of such is not critical to the protocol described herein. If a “secret key loss” situation occurs through some non-malicious act of user negligence (or abuse), the legitimate user will cause the application-specific key of the damaged unit 100 to be transferred to a new device. It should be possible to return the damaged unit to a licensing authority 510 that can be arranged. However, if the original target device 100 does not work, the transfer of the key to the new target device 100 must be accompanied by a transaction with the application developer 520 (at least used primarily unencrypted). Note that (for keys that were not supplied to licensing authority 510).

  However, a device that was able to deceive another genuine target unit 100 would trick an unsuspecting legitimately licensed device and take ownership of one or more of its application-specific keys. Note that it could be possible to temporarily abandon or suspend the operation (as described above). If the latter occurs, there is the possibility of having an “illegal unit” that can then invalidate all of the units that attempted to borrow the key. If the former occurs, any number of application or media specific keys can potentially be compromised.

  Thus, limiting the number of potential “licensed borrowers” for a particular target unit 100 to a list that can only be supplied to legitimate units using secure updates from the licensing authority 510 server. The concept previously discussed is good. In the former case, this can be overridden by a hacker who has no other suspicion as the owner of the unit, disassembling the functional unit to gain access to its private key, unless the unit actually belongs to the hacker in the first place To prevent having a legitimate device. In the latter case, this limits the transfer of applications or media-specific keys to only those devices that were properly licensed at some point in time and that were properly registered with the licensing rights. Nevertheless, a determined hacker can still purchase a legitimate unit, reveal it, somehow gain access to the private key data, and then use this information to pretend to be a legitimate device .

  Therefore, there remains the problem of how to detect this type of impersonation event. The only successful strategy for defeating extremely funded enemies of this nature is to design the system so that the potential gain is not worth the effort required, at least in terms of cost tradeoffs It is.

  There are several ways to try to prove the authenticity of other unknown devices with which you are communicating. However, the most successful way to prove that a device is what it claims is to focus on the characteristics that make this device unique from other devices. For special purpose devices, such as those described herein, for a special purpose device such as a digital cryptanalysis mechanism, to properly execute the security protocol and to calculate the correct result based on a given set of input variables Is the ability of the device. However, since the security protocol described herein is based on known algorithms, this is achieved by any general purpose computing device, considering that there is sufficient time to complete the calculation. obtain. In fact, if the secret key information that makes the device unique is somehow compromised, this problem becomes a potential problem for any device based on publicly available technology. Therefore, in the face of disassembly and chip mold inspection, it ultimately depends on the lesson that the private key information stored on-chip for all legitimate target devices must remain secret. There must be.

  Requirements such as the ability to correctly find verifiable MAC values within a certain amount of time can certainly be added to the target identification and verification process. By requiring the final MAC value to be encrypted multiple times, the procedure can be made more difficult. Thus, an attacker is legitimate in that he is required to have access to (more general) computational resources, which are usually much more expensive than simply purchasing a legitimate copy of the license. The ability to mimic a device can potentially be limited. In the case of a media stream player, it may also include the ability to correctly decode a portion of one or more of the media streams that the player is designed to adapt face up.

  However, in any case, the whole process of digital copyright protection is a Turing problem. Therefore, given sufficient time and resources, any digital copyright protection scheme can be defeated by a determined enemy. This is, of course, even unrelated to the fact that access to private key information is definitely a great advantage for an attacker. The ability to prevent the unit's private key from being compromised is therefore an important part of this security protocol.

(Conclusion :)
The above copyright protection protocol is unique in several ways. The first is the fact that it does not attempt to prohibit users from having the ability to make backup copies of legally purchased applications or media-specific key data. Second, this protocol does not differentiate between any kind of digital data, thus allowing security protocols to be updated as easily as data streams that are designed to protect. . Third, this protocol allows users to temporarily transfer ownership of their application or media specific keys to another unit capable of executing the protocol. This protocol also provides the ability for the licensee to achieve a permanent transfer of ownership from one target unit 100 to another. This last feature allows the consumer to realize a legal “first sale right” under this protocol.

  In fact, one of the fundamental differences between the protocols described herein and other copy protection schemes is that the security of this system controls the ability to access a particular data set. It does not depend, but rather relies on the ability to control the act of expressing the ideas contained within the data set.

  In the foregoing details, 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 present 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 the present invention.

  Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, benefits, benefits, solutions to problems, and any components that generate or make any benefit, advantage, or solution significant, essential, or essential to any or all claims It is not interpreted as a unique feature.

Claims (1)

Invention described in the specification.

Images