WO2004006075A1 - 開放型汎用耐攻撃ｃｐｕ及びその応用システム - Google Patents

開放型汎用耐攻撃ｃｐｕ及びその応用システム Download PDF

Info

Publication number
WO2004006075A1
WO2004006075A1 PCT/JP2002/006955 JP0206955W WO2004006075A1 WO 2004006075 A1 WO2004006075 A1 WO 2004006075A1 JP 0206955 W JP0206955 W JP 0206955W WO 2004006075 A1 WO2004006075 A1 WO 2004006075A1
Authority
WO
WIPO (PCT)
Prior art keywords
code
key
central processing
processing unit
program
Prior art date
Application number
PCT/JP2002/006955
Other languages
English (en)
French (fr)
Inventor
Takahisa Hatakeyama
Hidefumi Muruyama
Keiichi Ushiwaka
Takayuki Hasebe
Naoaki Maeda
Atsuhiro Suga
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2002/006955 priority Critical patent/WO2004006075A1/ja
Priority to CNB028295870A priority patent/CN100354786C/zh
Priority to AU2002346316A priority patent/AU2002346316A1/en
Priority to JP2004519192A priority patent/JP4073913B2/ja
Priority to EP02743883A priority patent/EP1542112A4/en
Priority to US10/614,921 priority patent/US20040093505A1/en
Publication of WO2004006075A1 publication Critical patent/WO2004006075A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information

Definitions

  • the present invention relates to a technology for countering an attack that attempts to falsify information inside a device or retrieve secret information.
  • Landscape technology
  • DRM Digital Rights Management
  • examples of DRM include Sanyo Electric, Hitachi, and Fujitsu.
  • UDAC Universal Distribution with Access Control
  • DRM Read Only Memory
  • TRM conversion TRM conversion that is generally implemented in products for consumers is roughly divided into two methods: hardware TRM and software TRM. is there.
  • the hardware TRM is a TRM that has a structure in which confidential information cannot be read from the external terminals of the semiconductor, and has been specially coated and ultra-miniaturized. Hardware TRMs can be compared to software TRMs, and in particular can be referred to as “attack countermeasures”. Software TRM encrypts the code to be encrypted into a structure that is difficult to analyze, and then encrypts the code at the moment of execution. This is the TRM realized by decoding.
  • the conventional TRM has the following problems.
  • T RM can be used to extend the size of the area for recording license keys and CRLs (Certificate Revocation Lists), or to express content usage conditions in XrML (extensible rights Markup Language). Can not.
  • An object of the present invention is to solve the above problems and provide a TRM having versatility comparable to software TRM, but having security equivalent to hardware TRM.
  • a central processing unit includes: a first secret key that is secretly hidden; and an encryption unit that performs encryption and decryption.
  • the first secret key is a pair with a public key
  • the encrypting means decrypts the first license of the first program encrypted using the public key using the first secret key.
  • a code decryption key for decrypting the first program is obtained from the first license.
  • the code decryption key may be the same as the code encryption key used when encrypting the first program.
  • the first license may be embedded in the first program, or both may be distributed separately.
  • the secret key required to obtain the key for decrypting the first program is secretly recorded in the central processing unit, so that it is distributed and stored. There is no. Therefore, it is possible to solve the problem that the secret key is easily found by analyzing the program.
  • the central processing unit further includes a cache, and the encryption unit, when the encrypted block configuring the first program is output from the memory area to the cache, encrypts the encrypted block in cache units. It may be decrypted. Decrypt encrypted blocks in cache units and record in cache By doing so, it is possible to improve safety more than before.
  • the central processing unit may further include an attack-resistant buffer that cannot be referred to or falsified by a user, and the code decryption key may be recorded in the attack-resistant buffer. Since the key recorded in the attack-resistant buffer cannot be referenced or falsified by the user even in the kernel mode, the code decryption key can be stored safely.
  • the attack resistant buffer may further include external output inhibition information and cache lock information, and the external output inhibition information may output corresponding information in the attack resistant buffer to the outside of the attack resistant buffer.
  • the cache lock information indicates whether the corresponding information may be output to the outside of the cache.
  • the first program and the The transfer of the first license with another program may be managed. This makes it possible for the central processing unit to realize a non-duplicable Blipe Locker. Thus, for example, even when the movable licenses between a plurality of programs, it is possible to prevent illegal copying of that by the retransmission Osamu ⁇ license p
  • the first license includes an access condition when an execution process of the first program accesses a memory area, and an encryption block forming the first program is recorded. It may be configured to further include a translation lookaside buffer (TLB) for recording an address of the memory area and an access condition to the memory area, a memory management unit, a cache, and a processor core.
  • TLB translation lookaside buffer
  • the attack-resistant buffer is linked to the TLB, and the memory management unit acquires an access condition from the TLB to the memory area based on an address of a memory area for recording the encryption block. Further, from the attack-resistant buffer, And obtaining the code decryption key corresponding to the memory area.
  • the processor core determines whether access to the memory area is permitted from the execution process based on the access condition acquired by the memory management unit, and determines whether the access to the memory area is permitted. If it is determined that the execution process is permitted, the execution process accesses the memory area.
  • the encryption unit writes, into the cache, a code obtained by decrypting the encrypted block in the memory area using the code decryption key obtained by the memory management unit.
  • the memory area is associated with the attack-resistant buffer via the TLB, and a key for decrypting the block written in the memory area is obtained based on this correspondence. Further, access to the memory area is also controlled according to the access condition in TLB. Therefore, it is possible to safely control access to the memory area and load the cache into the cache.
  • the memory management unit when the memory area accessed from the execution process of the first program is switched from the first memory area to the second memory area, the memory management unit further includes: It is determined whether the acquired code decryption key corresponding to the first memory area matches the code decryption key corresponding to the second memory area. Then, the access to the second memory area may be executed, and if it is determined that they do not match, the access from the execution process to the second memory area may not be executed. As a result, the address being executed from one memory area to another memory area corresponding to another code decryption key different from the code decryption key corresponding to the memory area by an instruction such as Call, Jump, or Return. When moved, the other memory area cannot be accessed from the execution process. This allows one owner process to access another owner process's memory area. It is possible to prohibit access.
  • a different data encryption key is recorded in the attack-resistant buffer for each of the code encryption keys, and the encryption unit uses the data encryption key to encrypt data in the cache.
  • the data is recorded in the memory area associated with the data encryption key via the TLB, and the encrypted data is read out from the memory area and decrypted using the data encryption chain.
  • the data may be written to the cache. This makes it possible to safely perform operations such as saving data to the memory area or loading data to the cache.
  • the processor core when the work data obtained by executing the first code is used in the second code, the processor core may have an access right to a memory area for recording the work data.
  • the TLB is set so as to give the second code to the second code, and a code encryption key for encrypting the work data is used when the second code reads the work data from the memory area.
  • the anti-attack buffer may be set so that
  • the first code and the second code usually share the data encryption key.
  • the data obtained as a result of executing the first code can be read by the second code. Therefore, even when the central processing unit executes while protecting two or more softwares, it is possible to safely share the memory area as needed.
  • the central processing unit further includes: a register; and a register access control table for controlling access to the register, wherein the processor core uses the sealing flag in the register access control table to execute the registration.
  • the sealing and release of the register may be controlled. This allows the process If the data is stored in the register, it can be sealed so that the data stored in the register cannot be accessed from processes other than the currently executing process.
  • the encrypting means when recording the contents of the TLB on an external page table, the encrypting means attaches a signature to the contents to be recorded, and before taking in the contents of the page table into the TLB.
  • the encryption means may confirm that the signature is correct. This makes it possible to securely hold the contents of TLB in the page table.
  • the decoding unit when recording the contents of the attack-resistant buffer in an encryption key table in an external storage device, the decoding unit may encrypt the recorded content. Les ,. This makes it possible to safely store the contents of the attack resistant buffer in an external storage device.
  • the secret key used to create the signature of the contents of the TLB and the secret key used to encrypt the contents of the attack-resistant buffer are both generated by the processor in the central processing unit. It may be good.
  • the central processing unit is connected to another central processing unit, and the central processing unit obtains a session key by mutually authenticating with the other central processing unit.
  • the encryption means may encrypt the contents of the cache of the central processing unit using the session key and synchronously transfer the encrypted contents to the other central processing unit. This makes it possible to safely synchronize the contents in the cache in a multi CPU having a plurality of central processing units having the above configuration.
  • the encryption means decrypts the second license attached to the second program using the public key before executing the first program.
  • Secret used to encrypt the private key of A secret key encryption key may be obtained, and the second secret key may be decrypted using the obtained secret key encryption key.
  • the first program may be any software that requires TRM.
  • a trusted computing module a program for realizing an electronic wallet in the central processing unit, software for handling personal information, a virus check software implemented in the central processing unit, a plurality of central processing units Examples include a mobile agent that moves between devices, a robot control program, and a security program for an IC card.
  • central processing unit various forms are conceivable for the blocks constituting the first program, and the central processing unit may be provided with further means accordingly.
  • the block includes hash check necessity information indicating whether the hash value of the block needs to be checked, calculates the hash value of the block based on the hash check necessity information, And hash checking means for checking the hash value of the block based on the hash checking necessity information.
  • the block includes encryption necessity information indicating whether or not the block requires protection, and the block encrypts the block based on the encryption necessity information. It is also possible to further include a protection block selection unit that determines whether the output to the unit or the output as it is to the cache or the memory area.
  • a protection block selection means for selecting a block for each block the following may be performed.
  • the header of the execution file of the first program includes an encryption block bit map indicating a configuration of a block constituting the first program, and the protection block selecting unit performs processing based on the encryption block bitmap. It is determined whether to output the block to the encryption means or to output the block to the cache or memory area as it is.
  • a plurality of blocks constituting the first program is a repetition of a combination of a plaintext block and an encrypted block, and the number of consecutive plaintext blocks in the combination is And a code that specifies the number of consecutive encryption blocks.
  • the processor core determines whether to output the block to the encryption means or to output the block to the cache or memory area as it is.
  • the central processing unit may further include, between the cache and the memory, a cache line via the encryption unit and a cache line without the encryption unit. As a result, the processing speed can be increased.
  • a program for causing a central processing unit to perform a control for giving permission to execute a protection program wherein the protection program is encrypted with a code number key, and Correspondingly, there is a license that includes the code encryption key and is encrypted with a public key that is paired with a secret key that is secretly provided in the central processing unit.
  • the encryption means provided in the central processing unit decrypts the license using the secret key, thereby acquiring the code encryption key from the license, and using the code encryption key as the symbol means. Decrypting the protection program by the central processing unit.
  • This program can provide the same operation and effect as the processing performed by the central processing unit having the above configuration. Therefore, even with this program, the above problem can be solved. Also, the recording device that records the program can obtain the same operation and effect as the processing performed by the central processing unit having the above configuration by executing the program by the central processing unit. You can do it.
  • a software execution licensing method including, as a procedure, an operation performed by each unit constituting the central processing unit can also provide the same operation and effect as the processing performed by the central processing unit having the above configuration. It is.
  • a program executed by a computer comprising: a program encrypted by a code encryption key; and the code encryption key corresponding to the protection program.
  • a license encrypted by a public key that is paired with a secret key secretly provided by a central processing unit provided in a computer that is to execute the program, and the license is a program executed by the program.
  • the program is executed by the central processing unit using the code encryption key acquired from the license. Decrypted.
  • This program is software protected by the above-mentioned central processing unit, and when executed by a computer having the above-mentioned central processing unit, it is possible to obtain the same level of security as hardware TRM. . Further, the computer-readable recording medium that records the program also loads the program from the recording medium, and executes the program by a computer having the central processing unit. Similar functions and effects can be obtained.
  • a program generation device that generates a program to be executed on a computer including a central processing unit having the above configuration, comprising: input means for inputting a code object; The code object is divided into a plurality of blocks, a linker preprocessing means for adding a NOP instruction to each block, a linker means for address resolution, and each block is encrypted using a code encryption key. Protection code execution form generation means for generating a protection code execution form; and a license generation means for generating a license including the code encryption key and encrypted with a public key paired with the secret key.
  • the license is used by the central processing unit before the computer executes the protected code executable. And the encrypted code is decrypted by the encryption means using the secret key, and the protected code execution form is decrypted by the encryption means using the code encryption key obtained from the license. Special.
  • FIG. 1 is a diagram showing a basic package software usage relationship model t
  • FIG. 2 is a diagram showing a programming model.
  • FIG. 3 is a configuration diagram of a CPU realizing GT according to the first embodiment.
  • FIG. 4 is a diagram showing the configuration of fields in each row in TRB.
  • FIG. 5 is a diagram showing a configuration of an extension field of each row in TLB.
  • Figure 7 is a diagram showing the correspondence between the 'value of the field in the TLB and the access authority in the case of the Intel architecture.
  • FIG. 8 is a diagram showing the structure of the encryption key table.
  • FIG. 9 is a diagram illustrating an example of a signature scheme. .
  • FIG. 10 is a diagram showing the relationship between the TRB, TLB, encryption key table, and page table.
  • FIG. 11 is a diagram showing an example of a configuration of a field for storing a TRSS flag.
  • FIG. 12 is a diagram showing an example of the field configuration of each row of RACT.
  • FIG. 13 is a diagram illustrating an example of the field configuration of the RS SL register.
  • FIG. 14 is a diagram showing a policy for accessing data from the code execution process between the general virtual segment space and the attack-resistant segment space.
  • FIG. 15 is a diagram showing how the protection process operates on GT10.
  • FIG. 16 is a diagram for explaining GT authentication.
  • FIG. 17 is a diagram showing an access right and a licensed right that can be set for the GT license.
  • FIG. 18 is a flowchart showing a part of the GT authentication process described above.
  • FIG. 19 is a diagram showing an example of a protected code execution format when used as a super-distribution file format.
  • FIG. 20 is a diagram for explaining a procedure for loading and executing the protection code, and for saving and maintaining the protection data.
  • FIG. 21 is a diagram for explaining access control to a page where a protection code is recorded when the protection code is executed.
  • FIG. 22 is a flowchart showing access control to the protection code and the protection data performed by the processor core.
  • FIG. 23 is a flowchart relating to exception / interrupt processing.
  • FIG. 24 is a flowchart relating to the instruction processing.
  • FIG. 25 is a diagram for explaining the operation of the OS kernel 60 and GT when starting the protection code file.
  • FIG. 26 is a diagram for explaining a mechanism for accessing protected data from a process executing the protected code.
  • FIG. 27 is a diagram for explaining a procedure performed when a parent process calls another protection code module.
  • FIG. 28 shows a flowchart of a process performed by the OS module when calling another protection code module from the parent process.
  • Fig. 29 is a diagram showing a sequence example for preventing unauthorized access to the sealed register by the attack-resistant code return exception processing.
  • FIG. 30 is a diagram showing an example of a sequence at the time of protection context switching by the OS kernel.
  • FIG. 31 is a diagram illustrating an example of sharing a protected data area.
  • Figure 32 is a diagram for explaining the module authentication and the procedure for setting the protected data decryption key sharing procedure.
  • FIG. 34 is a diagram illustrating an example of a construction model of the DRM software module.
  • FIG. 35 is a flowchart (part 1) illustrating the processing performed by the media DRM.
  • FIG. 36 is a flowchart (part 2) illustrating the processing performed by the media DRM.
  • FIG. 37 is a flowchart (part 1) illustrating the processing performed by the decoder DRM.
  • FIG. 38 is a flowchart (part 2) illustrating the processing performed by the decoder DRM.
  • FIG. 39 is a flowchart (part 3) illustrating the processing performed by the decoder DRM.
  • FIG. 40 is a flowchart showing the processing performed by the playback application.
  • FIG. 41 is a diagram showing a method for maintaining and managing secret information.
  • FIG. 42 is a diagram showing a memory access method for license management.
  • FIG. 43 is a configuration diagram of a CPU that realizes the GT according to the second embodiment.
  • FIG. 44 is a diagram illustrating a structure of a block according to the second embodiment.
  • FIG. 45 is a diagram showing the structure of a block when ebim is 4.
  • FIG. 46 is a flowchart showing the processing performed by the protection block selector.
  • FIG. 47 is a flowchart showing the processing performed by the hash engine.
  • FIG. 48 is a flowchart showing the processing performed by the hash checker.
  • FIG. 49 is a diagram illustrating the NOP process.
  • FIG. 50 is a configuration diagram of a multi-CPU.
  • FIG. 51 is a diagram illustrating an example of a tool group that outputs a protected code execution format from a code object.
  • FIG. 52 is a diagram illustrating an example of a system configuration in which a GT is mounted on a personal computer or a workstation.
  • the present invention implements a general-purpose TRM function in the CPU, thereby making the CPU a general-purpose attack-container.
  • a CPU that implements the general-purpose TRM function according to the present invention is referred to as (“Generic TRM” and abbreviated as GT).
  • Figure 1 shows a usage model of the GT package realizing the GT and the GT basic package software executed by the CPU package.
  • GT basic package software can be divided into an application layer, a DRM layer, and a PKI library layer.
  • the application layer contains the applications to be protected (hereinafter referred to as protected applications).
  • the DRM layer includes a decoder DRM30 and a media DRM40.
  • the PKI library layer includes the PKI library 20.
  • the decoder DRM 30, media DRM 40 and PKI library 20 are part of the OS (Operation System).
  • OS Operating System
  • -License conversion function Conversion between MB (Media Base), PI (Protocol Independent), GT, etc.
  • each of the DRMs 30 and 40 is implemented as software, not hardware.
  • GT 10 is implemented as a CPU.
  • GT 10 CPU
  • Fig. 2 shows a programming model on the GT including modules other than the basic package shown in Fig. 1.
  • the OS includes an OS kernel 60 and a device driver 70 in addition to the PKI library 20, the decoder DRM30, and the media DRM40 described above.
  • the device driver 70 is software necessary for operating the peripheral hardware 60. Multiple applications, including protected applications 50 and unprotected applications, run on this OS. In other words, other applications running on the conventional CPU run on the GT10 along with the protection application using the DRM function.
  • the GT 10 is a versatile attack-resistant container that can execute applications that do not need general protection at the same time as protection applications.
  • the OS kernel 60 performs processing unique to the GT 10 (described later) such as register sealing when controlling memory switching and context switching in the GT 10.
  • processing unique to the GT 10 such as register sealing when controlling memory switching and context switching in the GT 10.
  • letting the ⁇ S kernel 60 perform those processes does not affect the security of GT10. In other words, even if there is a security hole in the OS kernel 60, it does not affect the safety 1 "life of protection by the GT 10.
  • the decoder DRM30, the media DRM40, and the encryption / decryption library in the PKI library 20 used by these DRMs, as well as the applications requiring TRM, are distributed and executed as GT protection codes protected on the GT 10. Need to be And these software modules need to be almost completely encrypted.
  • the software TRM has the property of being scalable but easily breakable.
  • the DRM software module protected by the GT 10 by adopting the DRM software module protected by the GT 10, it is possible to give the DRM software module the same strength as the hardware TRM.
  • hardware TRM does not have scalability and resources are limited.However, according to GT 10, GT10 is used for functional expansion because of the use of DRM software. There is no need to change the installed CPU, and it is possible to respond by upgrading the DRM software.
  • the DRM construction model is based on the UDAC-MB (Universal Distribution with Access Control-Media Base) UDAC_LA and UDAC-PI architectures and specifications.
  • GT 10 has a processor core 11, instruction cache 12, data cache 13, instruction MMU (Memory Management Unit) 14, data MMU 15, cryptographic engine 16, and RAM (Random Access Memory) 17 It is connected.
  • One of the features of the GT 10 according to the present invention is that it includes a cryptographic engine 16 for encrypting and decrypting a code block or a data block, and a code block encrypted using the cryptographic engine 16. After decrypting the data block, it is stored in the cache 12 or 13 inside the GT 10, and when the work data is output from the data cache 12 to the RAMI 7, the data is encrypted using the encryption engine 16 May be output from.
  • the data exchange between blocks in GT 10 will be described below.
  • the code block input from the RAMI 7 is identified as a code block to be protected by the processor core 11 and the instruction MMU 14 (hereinafter referred to as a protection code block) or a plaintext code block.
  • the data block input from the RAMI 7 is identified by the processor core 11 and the data MMU 15 as a data block to be protected (hereinafter, referred to as a protected data block) or a! / Plain text data block.
  • the protection code block and protection data block are sent to the No. 16 engine.
  • the address of the protection block transfer destination is specified for the instruction MMU 14 and the data MMU 15 to RAM 17 respectively.
  • the code block / data block output to the encryption engine 16 is decrypted and output to the instruction cache 12 and the data cache 13, respectively.
  • the key Kc used for decrypting the protected code block and the key Kd used for decrypting the protected data block are output from the processor core 11 to the No. engine 16.
  • the plaintext code block or the plaintext data block is output as it is to the instruction cache 14 or the data cache 15, respectively.
  • GT 10 in order to ensure the security of the protection code block and the protection data block, according to GT 10, when the work data is output from the data cache 13 to the RAM 7, at the exit of the data cache 13.
  • Encrypt work data For this purpose, first, the work data is output from the data cache 13 to the encryption engine 16, and the key Kd (the key used for decrypting the protected data block and the key used for decrypting the work data from the processor core 11). Is output to the cryptographic engine 16.
  • the encryption engine 16 encrypts the work data using the key Kd, and outputs the encrypted work data to a virtual memory area provided in the RAM 7 or the like. Furthermore, a random number may be added to the data block when encrypting.
  • a processor determines whether or not the data block is a data block to be protected based on a translation lookaside buffer (TLB) (not shown, described later). The determination is made by the core 11, and based on the result of the determination, it is determined whether or not to pass through the cryptographic engine 16 when addressing from the data cache function.
  • the keys Kc and Kd used for encryption and decryption of the encryption are obtained by decrypting the GT license by the cryptographic engine 16 in the GT 10, and the attack buffer (hereinafter referred to as TRB: Tamper Resistor Buffer) (not shown, described later).
  • the instruction MMU 14 and the data MMU 15 are shown as separate blocks in FIG. 3, but may be a single module. The same applies to the instruction cache 1 2 and the data cache 13.
  • the GT 10 does not have the instruction cache 12
  • a 1 AM area is provided in the block 10
  • all execution codes are decoded internally and saved in the internal RAM area before execution. Is also good. Thereby, the same security as the above configuration can be ensured.
  • the GT 10 does not have the data cache 13
  • a RAM area is provided inside the GT 10, and work data requiring protection is recorded in the RAM area inside the GT 10. Thereby, the same security as the above configuration can be ensured.
  • a cache line for a plaintext code block, a cache line for a plaintext data block, a cache line for decrypting a protected code block, and a protected data block are placed between the caches 12 and 13 and the RAM7.
  • a plurality of cache lines may be provided in parallel, such as a cache line for decoding and a cache line for decrypting a protected data block.
  • a register is provided in the processor core 11.
  • GT10 a mechanism called an anti-attack area was added to the conventional virtual memory area, and within this anti-attack area, multiple protection software could be executed without affecting the security risks of each other.
  • the processor core 11 includes an attack-resistant segment selector (hereinafter referred to as TRSS) flag, a register access control table (hereinafter referred to as RACT), and a register sealing status list register (hereinafter referred to as an RSSL register) (not shown). Shown).
  • TRSS attack-resistant segment selector
  • RACT register access control table
  • RSSL register register sealing status list register
  • the TRSS flag is recorded in a field in the segment specification register that specifies a segment in the virtual memory area.
  • the processor core 11 can determine, based on the TRSS flag, whether the virtual address indicated by the register is in the attack-resistant segment space or the general virtual segment space. Also, when executing multiple pieces of protection software, the processor core 11 uses RACT to seal and release registers so that processes other than the currently executing process cannot access the registers. Control. Also, information indicating whether the register is sealed or released is: Registered in the RSSL register. The details of the attack-resistant segment space and the attack-resistant area and the sealing and release of the registers will be described later.
  • GT 10 is realized using one TRM-converted CPU.
  • the GT 10 can TRM a DRM software module or other modules that require protection that run on the GT 10. Therefore, it is possible to reduce the cost of manufacturing hardware TRM, especially the development cost of the initial lot.
  • TRB TLB
  • TRSS register RACT
  • RSSL register RACT
  • the TRB holds a key Kc for decrypting a program code (concatenation of instructions) and a key Kd for encrypting and decrypting data. Note that Kd and
  • TRB has a structure in which the user cannot refer to the inside even if it is in the kernel mode.
  • the location where Kc and Kd are held in the TRB is identified by the Key ID, and the TLB also has a Key ID that identifies the location of the linked key.
  • TRB and TLB are linked using Key ID.
  • FIG. 4 shows a table of the fields in each row in the TRB.
  • each line in the TRB contains a validity flag p, an external output prohibition flag uo, a cache lock flag cl, key identification information k id, an encryption key, a licensed code key ackey, and an exception process.
  • a validity flag p an external output prohibition flag uo
  • a cache lock flag cl key identification information k id
  • an encryption key a licensed code key ackey
  • an exception process Contains fields such as address eadr. Also, the sizes of these fields are given as examples, and other optimal values can be set depending on the GT10 architecture and application.
  • the validity flag P is a flag indicating whether the TRB is valid or invalid. When ON (1), it indicates that the TRB is valid.
  • the external output prohibition flag uo indicates that the content of the row is output to the encryption key table. This flag indicates whether it is good. If it is on (1), it is not output to the encryption key table. However, even in this case, p, uo, cl, and kid necessary as management information may be output.
  • the default value of the external output prohibition flag uo is off (0), in which case the contents of that line are output to the encryption key table. In this case, it is necessary to synchronize the contents in the TRB with the contents in the encryption key table.
  • the encryption key table is a storage means for storing the contents of the TRB in GT10. The details of the encryption key table will be described later.
  • the cache lock flag cl indicates whether or not data in the attack resistant area specified by the key identification information kid is output to the outside of the cache. If the data is on (1), the data or code is cached. Is not output outside of If cl is on (1), GT 10 may have a function to switch between the following two modes.
  • the key identification information k id is information for identifying a key, and is used to link the TLB and the TRB.
  • the encryption key key is the value of the encryption / decryption key for encrypting / decrypting the code or data written on the page linked to the line.
  • the encryption key is, for example, a key of a common key (common key) encryption method. Kc and Kd are recorded in this field.
  • the licensed code key ackey is a decryption key for decrypting the execution code of the protection process that can access the linked page.
  • the protection process means a state in which the protection code is executed.
  • the page of the executable code is in the TRB
  • the line in the TLB that contains the same kid as the key identification information kid of the line, is specified using the page number, and the type of access right to the page is also specified in the line in the TLB.
  • the licensed code key ackey is a ⁇ sign link key on the other line and the own line. However, if all bits of ackey are '0', it indicates that all processes have been granted access rights using the GT license. If ACgt.
  • Ackey (the value of the ackey field (described later) of ACgt ') contains a value obtained by encrypting ackey with the public key KPgt (described later) (that is, the case of ACgt. Aef force S on) , The result of decryption is entered in TRB.ackey.
  • the exception handling address eadr indicates the head address of the exception handling code that occurs immediately before returning from a page with a different key to the page linked to the line in this TRB.
  • the exception handling address (eadr) does not include ACgt.
  • Eadr the value of the eadr field in ACgt.
  • Eadr the value of the eadr field in ACgt.
  • the code decryption key Kc and the data encryption / decryption key Kd stored in the key field are, for example, encryption keys of a symmetric key cryptosystem generated as random numbers. An encryption method with the same data length may be selected. The key may be generated using a random number generation algorithm, or may be generated using a thermal random number generation function in the GT 10 or the like. The latter is often more secure than the former.
  • Kc and Kd are GT licenses described later include. By executing the CPU instruction “Access Authorization Instruction (AUTHORIZE Instruction)” (described later) using the code decryption key Kc or data decryption key Kd and the GT license with the access right embedded as parameters, A value is set for each field in the TRB line linked to the TLB (described later).
  • the TLB manages addresses for storing protection codes and protection data, and access rights to pages.
  • Figure 5 shows a configuration table of the extension field of each row in the TLB.
  • each row in the TLB related to GT 10 includes, in addition to the fields of the conventional TLB, a validity flag p, an area identifier id, a physical page number ppn, a virtual page number vpn, an access right rights, Includes fields such as key identification information kid, encryption block identification method ebim, and digital signature sign.
  • the size of the field shown in FIG. 5 is given as an example, and can be set to another optimum value depending on the architecture and use of GT10.
  • the validity flag p indicates that TLB is valid.
  • the area identifier id is an identifier of a page area indicated by the relevant line in TLB.
  • the physical page number p pn indicates a physical page number.
  • the virtual page number vpn indicates a virtual page number.
  • the access right rights indicates the access right to the page indicated by the line.
  • the permission level pi indicates the level of permission to access the page
  • the permission ar indicates the type of access to the page.
  • the authority level pi and the access right ar are determined based on the value of each field of the TLB as shown in FIGS. 6 and 7, and are set in the TLB.
  • FIG. 6 shows the case of the FR architecture
  • FIG. 7 shows the case of the Intel architecture.
  • the aggressiveness flag tr indicates whether the page indicated by the row is within the aggressiveness segment space (described below), and if the aggressiveness flag tr is on (1), the page is aggressive. Indicates that the line is in the attack segment space and the corresponding line is in the TRB.
  • the debug mode flag df indicates whether debug mode is enabled or disabled. It is valid if the debug mode flag df is on (1).
  • the attack resistance flag tr and the debug mode flag df are on (1), the debug mode according to the value specified by the access right ar operates, and the meaning of each ar value is as follows: .
  • RWX key identification information kid is information that identifies a row (insertion) in TRB to link to key information in TRB. .
  • the encrypted block identification method ebim is information for identifying the encrypted code block or data block.
  • the digital signature signature sign is a digital signature of the field concatenated data obtained by concatenating the above-mentioned finoledos from vpn to ebim, and is generated by GT10.
  • the OS manages the value of the access authority of the line in the TLB insertion (line) indicating the area where the protection code and protection data are stored, only when TLB.tr described later is off.
  • the value of the access right is represented by about 3 bits.
  • a "attack-resistant flag tr" field is further provided in the TLB as a field indicating that the page is within the attack-resistant area.
  • the code execution state in which the attack resistant area can be used is referred to as “attack resistant mode”.
  • the protection code and the address to store the protection data are set in the TLB before using the page.
  • the access authority rights, the encryption block identification method ebim, and the licensed code key ackey are determined based on the GT access condition ACgt (described later) included in the GT license.
  • the code decryption key Kc or data encryption ⁇ The decryption key Kd and the GT license that embeds the access right are used as parameters to execute the CPU instruction “Access Permission Instruction” (described later), so that each protected page is included in the TLB line.
  • KeylD is specified in the key field, and the decryption key is set in the key field in the TRB line corresponding to each KeylD.
  • the TRB is stored in the GT 10, but it is assumed that the storage capacity provided in the GT 10 becomes full.
  • at least a part of the content of the TRB in the GT 10 is encrypted, and the encrypted content is recorded in an external storage device such as the RAMI 7 or a hard disk.
  • the externally recorded list of rows in the TRB is called an encryption key table.
  • the GT 10 manages the content of the TRB while recording it in the encrypted key table in the external storage device while encrypting the contents of the TRB, extracts the necessary information from the encryption key table, and decrypts it in the GT 10.
  • the key Ktrb used when encrypting or decrypting the contents of the TRB is, for example, a secret key of a symmetric key decoding method.
  • the encryption key table includes a validity flag p, an external output prohibition flag uo, key identification information kid, and a field for storing the contents of the decoded TRB.
  • TRB.p value of the validity flag p field in TRB
  • TRB.kid TRB. Key identification information
  • the encryption key table may be recorded from the RAMI 7 on a hard disk (not shown) and reused after the GT 10 is restarted.
  • the TRB encryption key Ktrb is maintained in a non-volatile memory such as a ferroelectric random access memory (FerAM) even after the power is turned off in the GT10 within the attack resistance area. It may be.
  • FerAM ferroelectric random access memory
  • the following methods can be considered as a method of synchronizing the encryption key table and the contents of the TRB, but the present invention is not limited to any of them.
  • GT 10 By setting the start address and the number of lines of the encryption key table (by executing a special instruction), GT 10 automatically synchronizes the table and TRB when necessary. In addition, flash instructions will be implemented in GT10 so that users can synchronize when necessary.
  • the content of TLB is recorded as a page table in an external storage device even in GT10 like general CPU, and the content of TLB in GT and the content of page table are synchronized. Be managed. Then, GT 10 may take in necessary information from the page table into GT 10 when necessary and use it.
  • TLB.tr the value of the tr field in the TLB
  • TLB.sign the value of the signature sign field in the TLB
  • GT 10 checks the signature attached to the content, and if the signature is incorrect, generates an illegal TLB signature exception (described later). , Disable (off) the validity flag (TLB.p) and attack resistance flag (TLB.tr) for the row.
  • FIG. 9 shows an example of a signature scheme.
  • GT 10 concatenates a fixed random number in GT 10 to data including TLB.vpn, TLB. Rights, TLB. Kid, and TLB. Ebim.
  • the concatenated data is hashed with SHA-1 and encrypted using the secret key Ktlb in GT10. This generates the signature TLB.sign You. If the content to be signed is less than 160 bits, for example, a random field as a padding may be added to the content.
  • TRB and TLB are held in GT10.
  • key identification information kid Kc used for decrypting a code block
  • Kd used for decrypting a data block and the like are recorded.
  • the TLB stores an area identifier id, key identification information kid, virtual page number vpn, physical page number ppn, access rights, and the like.
  • the area identifier id corresponds to the page in RAMI 7 where the code block data block is stored.
  • the contents of TRB and TLB are associated with each other by key identification information kid.
  • the processor core 11 may perform the access control judgment while synchronizing the contents of the cache, the TLB, and the TRB. More specifically, the contents of the protection code in the instruction cache 12 or the protection data in the data cache 13 are stored in the TLB row. Not only can it be linked to the virtual address (TLB. Vpn), but also to the pair of digital signature (TLB. Sign) values and virtual addresses in that TLB row. In this case, the processor core 11 determines the access control as a different page when the pair does not match.
  • the protected code and protected data can be accessed only from the code that executed the code on the virtual page having the key specified by the field (ackey). However, only when the code with the access right of X or P WX is executed, execution from all codes is permitted if the ackey value of the page is all 0s.
  • execution right (X) in GT means the right to execute an instruction code on an attack-resistant page having a value in TRB.
  • Ackey (ackey field of TRB). This right is granted to the opcode executed immediately before the opcode, and there are the following cases.
  • the instruction executed immediately before is a branch instruction such as CALL or JUMP.
  • GT10 checks whether the instruction code specified to be executed next is permitted to execute again. You have to make sure. This confirmation will be described later.
  • FIG. 11 shows an example of the configuration of a field for storing the TRSS flag.
  • GT 10 has a TRSS flag in the segment designation register of its virtual memory space. This flag is present for each of the code segment, data 'segment, and stack' segment.
  • the attacker's code segment selector (TRCSS: Tamper Resistant Code Segment Selector) and the attacker's data segment selector (TRDSS: Data Segment Selector (TRSSS: Tamper Resistant Stack Segment Selector). If the TRSS flag is on, the page is set in the attack-resistant space; if it is off, the page is set in the general virtual space.
  • TRCSS Tamper Resistant Code Segment Selector
  • TRDSS Data Segment Selector
  • FIG. 12 shows an example of the field configuration of each row of RACT.
  • RACT is provided in the attack-resistant module to realize the function of sealing and releasing registers.
  • Each row of R ACT includes fields such as register I Drid, seal flag seal, and licensed code key ackey.
  • Register IDrid is an ID that specifies a register. Seal flag, seal, indicates whether or not the register is being sealed. If on (1), the register is being sealed; if off (0), the register is open.
  • the unlicensed code key ackey is the same as the TRB ackey, and is the code page key of the process that is allowed to access the register.
  • the RS SL register is not an essential function for GT, but may be provided as an optional function.
  • the RS SL register stores information indicating the sealing state of each register.
  • FIG. 13 shows an example of the field configuration of the RS SL register.
  • RS SL The register has the same bit length as the number of registers that can be sealed, and each bit indicates the sealing state of the register corresponding to that bit. If the bit is on (1), it indicates that the register is sealed; if it is off (0), it indicates that the register is free. For example, if the first bit of the RSSL register is set to indicate the sealing state of register r1, and if the first bit is on, register r1 is sealed.
  • FIG. 14 shows the policy for accessing data from the code execution process between the general virtual segment space and the attack-resistant segment space.
  • the general virtual segment space is a space where data and codes that do not need to be protected are recorded.
  • the attack resistant segment space is a space where the protection data and protection codes are recorded.
  • Code executed in the attack-resistant segment space can access data in the general virtual segment space, but processes executed in the general virtual segment space cannot access data in the attack-resistant segment space.
  • the same policy as in the general temporary space is maintained as long as the license owner is the same in the attack-resistant ⁇ segment space.
  • the protection process in GT 10 is not affected by other processes.
  • the protection process has its own anti-attack pages and is generally managed by the OS.
  • FIG. 15 shows how the protection process operates on GT10.
  • a plurality of protection processes operate on GT 10 and each protection process generates a page in the attack-resistant area.
  • the work data is encrypted by the encryption engine 16 in the GT 10 and then stored in the attack-resistant area (virtual memory area). Therefore, it can be said that the range of the virtual hardware TRM expands and contracts to RAMI7 and hard disks, etc., and does not have a certain shape. For this reason, it can be said that the protection process generated and operated by GT 10 is operating in “Virtual Hardware Tamper Resistant Module (VHTRM)”. Therefore, according to GT 10, it is possible to solve the problem of resource limitation due to hardware TRM while having the same strength as hardware TRM.
  • VHTRM Virtual Hardware Tamper Resistant Module
  • the protection process can also move freely around the world's CPU (GT10) space (GRID calculation described later).
  • GT10 world's CPU
  • GRID calculation described later the protection process wearing VHTRM that withstands any attack and fulfills its mission and returns to the original GT 10 is anthropomorphized and is also called “Tamper Resistant Agent”. it can.
  • GT certificate retrieval command Store GT certificate command Instruction format: STR_GT—CERT (certNum, certAdr)
  • certNum The certificate number assigned locally within GT10. If there are N certificates, values from 0 to N-1 are valid.
  • startVPN First virtual page number in the attack resistant area
  • Operation Authenticates the GT license in the memory of the specified register, and links the code or data decryption key (Kc or Kd), kid, and ackey in the attack resistant area extracted from the GT license to the TLB in the attack resistant area.
  • Kc or Kd code or data decryption key
  • the “LB attack flag” (tr) and access rights (PR, X, PRW, PWX), ebim, kid, and sign are set in the TLB. If the setting is completed correctly, concatenate the input data, add its digital signature, and record it at the address specified by resultAdr. At this time, the concatenation of the input data is hashed, the result is encrypted using Kgt, and the result is adopted as a digital signature. An exception will be raised if the setting fails, such as when authentication fails or the TLB does not exist.
  • Access rights (specify ACgt. ar (described later))
  • startVPN First virtual page number of the attack resistant area
  • errorCode Occurs when the line corresponding to the input is not found in TLB or TRB, or when the range of the specified access right is wider than the already set access right.
  • errorCode The line corresponding to the address specified by staetAdr does not exist in TRB (not in attack-resistant mode). Or, there is no access right to the address. Behavior: Sets the specified startAdr to TRB.eadr (the eadr field in TRB) of the currently executing code page.
  • Input register registerList: Register list to be sealed (flag list). For a flag corresponding to each register, ON (1) indicates that the register is sealed, and OFF (0) indicates that the register is not sealed.
  • errorCode The specified register does not exist. Or, the register is already sealed.
  • registerList Register list to release seal
  • errorCode The specified register does not exist. Or, the register is free.
  • Operation Clears all register values in the specified range to 0 and releases the seal. Operation permission: All levels
  • Unauthorized area stack store instruction Store Stack to Unauthorized
  • registerList List of registers recorded on the stack. List of flags. When the flag corresponding to each register is ON (1), it indicates that the register is recorded on the stack, and OFF (0) indicates that it is not recorded.
  • registerList List of registers to be read from the stack
  • License deletion instruction Delete License comranad
  • kid An identifier assigned by the OS to manage the relationship between TLB and TRB.
  • Protection block start command Protected Block Start command Command format: PRT_BL0CK—START (encryption_flag)
  • encryption_flag On (1) indicates that the block is encrypted.
  • a specific bit position of the instruction data is set to a specific pattern, it is regarded as an encrypted block start instruction.
  • the specific bit string (about 7 bits) in this instruction is used to specify the length of the encoded block, and the unit for specifying the value is the same as the minimum instruction length that can be cached.
  • the maximum value that can be specified is the same as the maximum value of the cacheable length.
  • Other bytes of this instruction must contain random numbers. The beginning boundary of this instruction data must match the boundary of the instruction cache unit.
  • the protected code block start instruction becomes a Nop instruction of the same length after being decoded in GT10.
  • This instruction corresponds to the second embodiment (described later).
  • This command is used when Ktlb or Ktrb may be leaked.
  • the license information is encrypted and managed using TRB, it is impossible to decrypt the previous encrypted information after this command. In such a case, for example, it is necessary to perform processing such as encrypting with a different key and saving before refreshing. Details of usage examples will be described later.
  • the symmetric key decoding method implemented in the CPU and the encryption / decryption instruction of the public key encryption method are shown to the software developer as an instruction set, so that the hardware resource utilization efficiency is improved. Increase.
  • the CPU that implements GT 10 implements the following exception handling in addition to the conventional exception handling. Exception handling is roughly divided into exceptions related to attack-resistant page access rights, exceptions related to return to the attack-resistant area, register sealing-related exceptions, and hash-related exceptions. And so on. Hereinafter, each exception process will be described in order.
  • TLB.sign (the sign field in the TLB) does not match the signature contained in the block.
  • GT 10 automatically stops loading the TLB from the page table. Further, the validity flag (TLB.p) and the attack resistance flag (TLB.tr) of the corresponding row in TLB are turned off.
  • the range of the specified access right is wider than the access right granted by the AUTHORIZE instruction. If this exception occurs, GT 10 will automatically reject the access right setting instruction.
  • FIG. 16 shows a diagram explaining GT authentication.
  • GT certification involves creating software packages for the protection application 50, DRM 30 and 40, and cryptographic module (included in the PK I library 20).
  • the development maker, CApki for the PKI library module, CAdki for DRM, CAdrm for DRM, CAap for applications using DRM and CAgt for CA certifying GT are interposed.
  • the thin arrows indicate the data flow
  • the thick arrows indicate the embedding of the license or certificate in the software package.
  • the numbers in parentheses in FIG. 16 indicate the order of processing.
  • each TRM software shall be encrypted with a symmetric key encryption key generated by each TRM software developer in secret.
  • the generation and use of GT licenses are realized by the following system operations and program software execution licensing procedures.
  • the GT manufacturer passes the individual public key KPgt of the GT 10 to be commercialized to the GT-dedicated CA CAgt. Further, the GT maker embeds a secret key Kgt inside the GT 10.
  • the GT dedicated certificate authority CAgt issues a GT10 public key certificate Cgt to the GT manufacturer.
  • the public key certificate Cgt of GT 10 is signed with the class private key Kcgt, and the class public key KPcgt is released in the form of a certificate signed with the root private key Kagt of the certification authority CAgt dedicated to GT. It may be good. Also, the public key certificate Cgt may use either the individual key or the class key instead of using both. If there is no class key, the public key certificate Cgt may be directly signed with the root private key Kagt.
  • the GT maker copies the public key certificate Cgt and distributes it to the TRM software development maker.
  • each TRM software creates a protection code file by encrypting the developed software execution code using the key Kc.
  • each TRM software encrypts the key Kc using the public key KPgt of GT 10 extracted from the public certificate Cgt, and generates a (non-movable) GT license Lxx.
  • the structure of the GT license will be described later.
  • Each TRM software maker embeds the GT license Lxx in its software package so that the initiator of the S will put the GT license Lxx into GT10 before the software is executed.
  • GT 10 decrypts the GT license using the private key Kgt, which is a public key pair.
  • Kgt is a public key pair.
  • GT 10 certification is executed by each software developer in GT 10. This allows the software to run on GT10. Is allowed to do so. If you want to distribute software protected by GT as free software, you can use the class public key KPcgt to generate a GT license. If you want to make sure that the software protected by GT cannot be used on a specific GT10, you may use the individual public key KPgt to generate a GT license.
  • the GT 10 sets the key Kc extracted from the GT license and the access right (Access rights) to TRB and TLB in GT10. The user cannot see the Kc set in the TRB even in kernel mode (supervisor level / ring 0).
  • the GT license for granting the execution license to the GT 10 is embedded in the TRM software package, and the GT license is put into the GT 10 before the encrypted program code is executed. .
  • the GT 10 decrypts the GT license using the individual private key Kgt, extracts the decryption key Kc of the program code from the GT license, and outputs the decryption key Kc for each protection code to the TRB linked to the internal TLB. maintain.
  • the encrypted code is executed while being decrypted using the decryption key Kc.
  • the CAI for Modules for PK I Library Module CApki, CA for DRM CAdrm and CA for applications using DRM CAs for TRM software packages are composed of CAap, and the software processes of each package exchange protected data. Issue a certificate used to authenticate the data transfer destination package at the time.
  • the DRM CA may be used to authenticate the license transfer destination DRM.
  • the GT license may be inserted in the same file as the protected execution code, it is recommended to manage it as a file separate from the encrypted execution code in consideration of the convenience of package super distribution.
  • the license generation side obtains the certificate Cgt of the individual public key KPgt of the licensee G T (attack-resistant container) and generates a GT license using this. Certificate Cgt may be in X.509 compliant format.
  • the certificate Cgt of the individual public key KPgt is the class key KPcgt, and the certificate Ccgt of the class key KPcgt is used after checking the signature with the root public key KPagt of the certificate authority CAgt.
  • the format of the GT license generated by the license generation side is as follows.
  • a I I B Data binding. Indicates that data A and data B are linked.
  • Ks Session key (L number). Symmetric key (common key) A key for cryptography.
  • LicenselD License serial number.
  • the license generator generates a unique number for each license.
  • the ID of the license creator may be placed at the top, and the content ID may be placed at the middle.
  • ACgt GT access condition. Indicates the code / data usage conditions that can be enforced in the GT, and has the following fields.
  • ebira Encryption block identification method. It is copied to the TLB.ebim field shown in Figure 5. The meaning of each value has already been described as the TLB field.
  • aef Licensed code key encryption flag (ackey encryption flag). If on (l), it indicates that the licensed code key ackey is encrypted using the individual public key KPgt, and if off (0), the ackey value is directly entered into ACgt.
  • ackey ACkey field of ACgt.
  • ackey Licensed code key. A value obtained by encrypting the encryption key key or key key of the protected page, which stores the code of the process that can access the object decrypted with the encryption key Kc or Kd, with the individual public key KPgt.
  • the encryption key is encrypted with the individual public key KPgt, if the GT has multiple KPgts, add information that can further identify which KPgt is used.
  • the type of access right to the process is specified by ar.
  • Exception handling address This field is optional. This is the top address of the exception handling code that occurs immediately before returning to the page where the contents of this GT license are set from a page with a different key.
  • PRW Can read and write from the process specified by ackey
  • PWX Can read, write, and execute from the process specified by ackey uo: External output disable flag. If on (1), the TRB line that stores the key information of this license is not output (paged) to the encryption key table. The default for this flag is off (0), indicating that external output is possible.
  • Cache lock flag This is an optional function. If this flag is set, the data in the attack resistant area protected by this GT license will not go out of the cache. However, if ar does not include write permission (PR or X), this flag is invalid. The default value of this flag is off, indicating that external output is possible.
  • df Debug mode flag. If the df force is S on, the action according to the specification of ar is shown. See description for TLB. By turning on df of ACgt in the GT license, the protection code can be executed in debug mode. In addition, when selling a protected code file in a form such as super-distribution, the df may be turned off and sold.
  • CgtID KPgt's X.509 certificate identifier value. The value obtained by concatenating issuer and serialNumber.
  • CgtlDackey Optional.
  • Figure 17 shows a table of the access rights and licensed rights that can be set for the GT license.
  • Attack resistance flag In the attack resistance mode, the access right of the protected data or protected code area from the viewpoint of the process (code execution state) is selected from among the Figure 17 Is set to
  • the “designated code” in FIG. 17 is a code that can be decrypted with the key specified in the Key field or Ackey field in the relevant TRB line.
  • some CPUs do not have “executable only” authority but can specify both “executable only” authority and “read and execute” authority, such as FR.
  • the attack resistance authority can be expressed as PX and PRX, respectively.
  • both “PWX” and “PRW X” may specify the “writable” authority.
  • GT licenses are not transferable, they have no transfer function and no CRL (Certificates Revocation List) and LRL (License Revocation List). Since there is no need to control CRLs and LRLs, implementation on GT CPUs becomes easier. CRL control and LRL control of DRM are performed by OS or application. This makes it possible to maintain high resiliency and expandability.
  • the GT license may be generated using a class public key. Conversely, if you want to use the software only for a specific GT, you can use the public key corresponding to the GT individual key.
  • the GT 10 executes the access permission command (AHTH0RIZE command) to set a key and an access right in the TLB and the TRB based on the GT license.
  • AHTH0RIZE command access permission command
  • the GT 10 decrypts the GT license using the private key Kgt corresponding to the public key pair of the GT (S1). Subsequently, GT 10 determines whether or not the GT license has been successfully decrypted (S 2). 2: Normal), GT 10 searches the TLB of the specified virtual area (S3). If decryption was not successful (S2: abnormal), GT 10 generates a GT license authentication fault (S11), and proceeds to S16. In S16, GT 10 sets the error contents in resultAdr and returns to the main flow.
  • GT 10 determines whether or not the TRB has a free space (S5). If the specified virtual area cannot be obtained as a result of the search in S3 (S4: none), GT 10 generates an unallocated exception indicating that no memory is allocated (S12), and S16 Proceed to.
  • the GT 10 sets values in the uo, cl, kid, key, and ackey fields in the TRB based on the GT license (S5 6). If no TRB is available in S5 (S5: None), GT 10 outputs (pages out) some rows in the TRB to the encryption key table (S13). The GT 10 proceeds to S6 if the page-let succeeds (S14: success), and generates an encryption key table access fault if the page-let fails (S14: failure) (S1 5) Go to S16.
  • the GT 10 calculates the signature sign to be stored in the TLB (S7), and sets ar, (tr, df, kid, ebim, and sign in the TLB (S8). Generates a signature of the setting result (S9), sets the setting result and the signature generated in S9 in resultAdr (S10), and returns to the main flow.
  • the encrypted protected code file (executable form) has a structure in which a header is added to the head of the repeated structure of the protected code block and the plaintext code block. If the protection code file is a file that can be used for super distribution, the header of the file must include the following additional information:
  • ⁇ Content encryption method Required as a value that specifies the encryption method of the protection code. This value may include the length of the decryption key.
  • Figure 19 shows an example of a protected code execution format when used as a super-distribution file format.
  • the content of the protection code execution formula is stored as an element of the SCDF in a Super Content Distribution Format (SCDF) file.
  • SCDF Super Content Distribution Format
  • an encrypted protection code file is composed of a header, a protection code block, and a plaintext code block.
  • the protected code file is loaded into the RAM 7 at execution and copied to the instruction cache 12 on a block-by-block basis as predicted in GT10 (CPU). Of these, only the hit instruction is interpreted and executed by the processor core 11. As shown in FIG. 20, among the code blocks, the protected code block is recorded in the instruction cache 12 after being decoded by the decoding cache line.
  • protected data is transferred to RA by executing the protection code.
  • Ml7 When outputting to Ml7, it is output to an attack-resistant area set in advance as a virtual memory.
  • a key Kd of symmetric key cryptography for encrypting and decrypting protected data is associated with the attack-resistant area, and the key Kd is secretly maintained in the GT 10.
  • the key Kd is assigned as a different random number for each code decryption key Kc.
  • the protected data is temporarily recorded in the data cache 13 inside the GT 10 (CPU), and then encrypted and output to the RAMI 7.
  • the protection data on the RAMI 7 is decrypted inside the GT 10 (CPU) and recorded in the data cache 13, and the hit data is used by the processor core 11.
  • a decryption cache line for decrypting the encryption block and writing it to the instruction cache 12, encrypting the contents of the data cache 13 and attacking the RAMI 7.
  • cache lines There are three types of cache lines: a cryptographic cache line for writing to the area, and a plaintext cache line for writing a plaintext block to the instruction cache 12. This configuration can also speed up the processing.
  • the encrypted protected data can be saved in the RAMI 7 and the storage 18. That is, the attack resistant area can be expanded not only in the RAMI 7 but also in the storage 19 connected via the bus 18. Page access control>
  • the GT 10 obtains permission to execute the TRM program code, loads the code block constituting the protection code file into the RAMI 7, and decrypts and executes the protection code block.
  • access control to a page (instruction page or code page) for recording the protection code when executing the protection code will be described with reference to FIG.
  • arrows indicate the flow of data
  • numbers in parentheses indicate the order of processing, and correspond to step numbers in the following description.
  • Access control to the page where the protection code is recorded is performed as follows.
  • Instruction The MMU 14 reads a virtual address stored in a prediction instruction pointer (ip: instruction pointer).
  • the MMU 14 reads from the TLB the physical page number ppn corresponding to the virtual address, the attack resistance flag tr, and the access right ar in the attack resistance mode.
  • the instruction MMU 14 extracts the code decryption key (Kc) from the TRB.
  • the instruction MMU 14 specifies the address of the protection code block to be cached in the instruction cache 12 and the RAMI 7.
  • the protection code block is input from the RAMI 7 to the encryption engine 16.
  • the protection code block decrypted by the No. engine 16 is recorded in the instruction cache 12.
  • the processor core 11 reads the temporary address from the ip register.
  • the processor core 11 extracts the access right ar from the instruction MMU 14 and confirms the access right.
  • the processor core 11 reads out and executes the protection code block from the instruction cache 12 in which the contents of the virtual address are recorded.
  • the processor core 11 checks the following before reading the protection code block in step (11).
  • the encryption key (TRB.key) or licensed code key (TRB.ackey) of the page on which the protection code block to be executed next is recorded, and the code block executed immediately before is recorded.
  • the processor core 11 stops executing the instruction and generates an access right exception.
  • Access control to a page in which a protected data block is recorded will be described.
  • Access control to the protected data block is enforced by setting the contents of the GT license in TRB and TLB.
  • Access to protected data blocks is controlled according to the licensed code key ackey, encryption / decryption key Kd, and access right ar maintained in the TRB and TLB.
  • the processor core 11 stops accessing the protected data and generates an access right exception.
  • access control to the above-described protection code and protection data performed by the processor core 11 will be described in more detail with reference to FIG.
  • the processor core 11 waits for the occurrence of the exception Z interrupt event (S21).
  • the processor core 11 performs exception-interrupt processing (S35), and returns to S21.
  • Figure 23 shows the details of the exception II interrupt processing. The various exception processes shown in FIG. 23 have been described in detail in the above ⁇ exception process>, and thus description thereof will be omitted.
  • the processor core 11 determines whether or not an instruction page switch has occurred (S22).
  • the processor core 11 When the instruction page switching occurs (S22: Yes), the processor core 11 performs a process of determining whether or not the access right to the instruction page exists (S23). If the instruction page switching has not occurred (S22: none), the process proceeds to S28.
  • the processor core 11 executes the encryption key (TRB.key) or the licensed code key (TRB.ackey) of the page in which the protection code block to be executed next is recorded immediately before execution. Access to be executed next according to the access condition recorded in TLB.ar for the protection code block to be executed next that matches the encryption key (TRB.key) of the page where the code block recorded is recorded It is determined whether or not is permitted. If the above two conditions are satisfied, the processor core 11 determines that the code to be executed next has access to the switched instruction page (S24: Yes), and proceeds to S25. Otherwise (S24: none), the processor core 11 queues a page access fault exception (S27) and returns to S21.
  • TLB.ar the access condition recorded in TLB.ar for the protection code block to be executed next that matches the encryption key (TRB.key) of the page where the code block recorded is recorded
  • the processor core 11 sets the encryption key (TRB.key) of the page in which the protection code block to be executed next is recorded as the encryption key (TRB.key) of the page in which the code block executed immediately before is recorded. TRB.key), and then Then, the processor core 11 determines whether or not a value has already been set in the eadr field of the row in TRB corresponding to the page. If TRB.key does not match and the value is already set in the eadr field (S25: YES), the processor core 11 queues an anti-attack code return exception (S26) and proceeds to S21. Return. If TRB.key matches, or if no value is set in the eadr field '(S25: NO), proceed to S28.
  • TRB.key the encryption key of the page in which the protection code block to be executed next is recorded as the encryption key (TRB.key) of the page in which the code block executed immediately before is recorded. TRB.key
  • the processor core 11 reads the instruction from the instruction page and analyzes the instruction. Further, the processor core 11 checks whether or not the currently executed code has an access right to the register specified in the instruction (S29). If the code has the right to access the specified register (S29: Yes), the process proceeds to S30. If the code does not have access to the specified register (S29: none), the processor core 11 queues a sealed register access fault exception (S34) and returns to S21.
  • the processor core 11 determines whether or not the data page has been switched to the previous data page indicated by the register. If not switched (S30: none), execute the instruction (S33) and return to S21.
  • Figure 24 shows the details of the instruction execution process. The instructions shown in FIG. 24 have been described in detail in the section “Instruction Set” above, and thus description thereof will be omitted.
  • the processor core 11 performs a process of determining whether or not there is an access right to the data page (S31).
  • the process of S31 is the same as the case of the protection code described in S23, and thus the description is omitted.
  • the process proceeds to S33. Otherwise (S32: na Then go to S27.
  • the procedure to activate the protection code file is as follows.
  • the OS kernel 60 secures a virtual memory area and a physical memory area that are areas for loading protection code and protection data, and links the virtual memory and the physical memory area.
  • GT10 Based on the AUTHORIZE instruction from OS kernel 60, GT10 sets TRB to link to TLB.
  • GT10 Based on a code module call instruction such as CALL from the S kernel 60, GT10 sets the ip register. (If the call destination instruction is not hit, GT10 decodes the corresponding code block, Copy the decrypted code to the cache).
  • a code module call instruction such as CALL from the S kernel 60
  • GT 10 confirms the right to execute the instruction at the address specified by ip with the contents of TLB.ar (ar field in TLB). .
  • GT 10 reads, decodes, and executes the instruction (STR instruction in the figure) at the address specified by ip.
  • the protected data area is allocated before executing the protection code, and the initial value is also loaded from the protection code file. It is assumed that GT10 executes the AUTHORIZE instruction from OS 60, and it is assumed that access permission and access right setting to the protected data area have already been performed.
  • the protection code executes memory access instructions (such as STR and LDR).
  • GT 10 checks the access right information TLB.ar (ar field in TLB) in the line in TLB corresponding to the address to be accessed.
  • the protection code accesses the data of the page with the virtual page number that matches TLB.vpn (the vpn field in TLB). (If the data is not in the cache, the protection code decrypts the data from the physical page corresponding to the virtual page and copies it to the cache.)
  • the parent process secures a virtual area for storing the protection code module and a physical area corresponding to the virtual area by setting the TLB.
  • the parent process generates a TRB that links to the TLB by the access permission (AUTHORIZE) instruction, sets the code decryption key Kc, and sets the access condition in the TLB.
  • AUTHORIZE access permission
  • the parent process stores the secret information register being used in the stack area in the protected data area of the parent process. (If necessary, the stack data in the protected data cache is encrypted and recorded in the external memory.)
  • the parent process calls the protection code module using a CALL instruction or the like.
  • FIG. 28 shows a flowchart of the process performed by the OS kernel in the above procedure.
  • the attack area acquisition system call is called. It is.
  • the parent process notifies the OS kernel 60 of the required area size and the GT license.
  • the OS kernel 60 uses the list of registers used by the application as the The area stack store (STMEA—T0_UA) instruction is output to the processor core 11 (S91). This step S91 corresponds to step (3) in FIG.
  • the OS kernel 60 outputs a register release (RELEASE-REG) instruction using the list of registers used by the application as an input parameter to the processor core 11 (S92). This releases the specified register.
  • This S93 corresponds to step (4) in FIG.
  • the OS kernel 60 outputs a register sealing (SEAL_REG) instruction using the list of registers used by the OS as an input parameter to the processor core 11 (S93). If the parameters of these instructions are correct in S94 (S94: normal), these instructions are executed by the processor core 11, and the process proceeds to S95. If not (S94: illegal), proceed to S103.
  • SEAL_REG register sealing
  • the OS kernel 60 sets an entry of the area size specified by the parent processor in the page table (S95). If there is a resource in the attack resistance area for setting the area of the specified size (S96: Yes), the process proceeds to S97. If the resources of the attack resistance area are insufficient (S96: insufficient), the process proceeds to S103.
  • step S97 the OS kernel 60 sets the GT license, the set address and the page area in the input register, and outputs an access permission (AUTHORIZE) instruction to the processor core 11.
  • This step S97 corresponds to step (2) in FIG. If the instruction is executed normally (S99: normal), the process proceeds to S100. If the instruction could not be executed normally (S99: exception occurred), the process proceeds to S103.
  • the OS kernel 60 sets the result of the access permission (AUTHORIZE) command as return data. Thereafter, step (5) in Fig. 27 is performed, and the protection code module is called. Next, OS kernel 60 registers A release (RELEASE_REG) instruction is output to the processor core 11 to release the register used by the OS (S101). Finally, the OS kernel 60 outputs a licensed area stack load (LDMEA_FR0M_UA) instruction to the processor core 11, loads the stacked data into the register, and returns to the normal state. This step S95 corresponds to step (7) in FIG.
  • the OS kernel 60 sets the error details as return data in S103, and proceeds to S101.
  • GT10 sets the start address of the release / return exception to TRB before sealing the protection code register. Also, the protection code must include release / return exception processing so that the secret information recorded in the register will not be leaked by continuing execution with the register being released by an external interrupt. In return exception handling, GT 10 reconfirms that the register that was supposed to be sealed is sealed, and if the register is not sealed, reseal it. Must.
  • Figure 29 shows an example of a sequence for preventing unauthorized access to the sealed register by the attack-resistant code return exception handling.
  • Figure 29 shows the case where an exception occurs when the protection code returns after being suspended by an invalid code.
  • Fig. 2 9 In, a register seal (SEAL—REG rl) instruction was executed before the protection code was interrupted, but a register release (RELEASE-REG rl) instruction was executed during execution of the malicious code, so the seal was closed on return. The expected register is not sealed.
  • SEAL—REG rl register seal
  • RELEASE-REG rl register release instruction
  • Attack-resistant code return exception processing ends The process returns to the protection code.
  • the process is interrupted again by the malicious code, and the malicious code attempts to write the contents of register r1 used by the protection code to the general virtual area (MOV rl, [unprotectedArea]).
  • MOV rl general virtual area
  • MIV rl general virtual area
  • SEALED_REGISTER ACCESS—FAULT_EXCEPTION
  • GT 10 protects the secret data of the protection code upon recovery.
  • Figure 3 3 shows an example of the sequence when the OS context switches protection contexts.
  • Fig. 30 it is assumed that the protection context is switched from application 1 to application 2. Initially, register r1 used by application 1 is sealed. Thereafter, when switching the protection context, the OS module 60 executes the non-licensed area stack store (STMEA_T0—UA) instruction, and the value of the register r1 is encrypted with the data encryption / decryption key Kd. Is evacuated. Furthermore, the stacked register r1 is cleared to 0 by the register release (RELEASE_REG) instruction. When the register r1 is released, the process of the application 2 can use the register r1.
  • STMEA_T0—UA non-licensed area stack store
  • the OS kernel 60 executes the load non-licensed area stack (LDMEA- FROM-UA) instruction to decode the saved register value, Returned to r1. afterwards, Register r1 is resealed.
  • LMEA- FROM-UA load non-licensed area stack
  • OS kernel 60 calls an unprotected system call, it is necessary to switch the SP to an address in the general virtual space before calling it.
  • OS may record the return value of the system call in the general virtual area as before.
  • a GT license for sharing a stack area for storing a return value is passed as a parameter or the like.
  • the OS can share the attack resistant stack area with the application process by executing the AUTHORIZE command with the received GT license as a parameter.
  • FIG. 31 shows an example of sharing the protected data area.
  • FIG. 31 is a diagram illustrating a case where a player process and a decoder DRM process operate on GT10.
  • the data decoded by the decoder DRM process is written to a virtual page for the DRM process.
  • the decoded data is encrypted using the data No. key Kd and then recorded on the shared physical page in the RAM 7.
  • Data recorded on the shared physical page of RAM I 7 is recovered using the data decryption key Kd.
  • the player (playback application) process reads the data and plays it back.
  • the originating module must authenticate the destination module. After successful completion of the authentication, TLB and TRB must be set in GT10 so that the sharing destination module can use the encryption key Kd in the protected data area of the source module.
  • RN random number temporarily generated by the generating module
  • KPacra Root public key of certificate authority for software module
  • KPdp Public key of shared module
  • Kc2 code decryption key of the sharing destination module (1)
  • the generation module passes the random number temporarily generated to the sharing module.
  • the sharing destination module uses the ID of the virtual area generated by its own process, the value obtained by concatenating the value obtained by encrypting Kc2 with KPgt, and the random number, the digital signature of the data, and the secret key Add the corresponding public key certificate.
  • This certificate must be issued by a trusted third party, such as a PKI Library Certificate Authority (CApki), DRM Certificate Authority (CAdrm) or Application Certification Authority (CAap).
  • CApki PKI Library Certificate Authority
  • CAdrm DRM Certificate Authority
  • CAap Application Certification Authority
  • the sharing module passes the data generated in (2) to the generating module using general data sharing / inter-process communication.
  • the generating module checks the signature, and if it can confirm the validity, accepts the authorized code key Authorized Code Key, the access right 'PR' (read-only in attack-resistant mode), and the encryption 'decryption.
  • the access permission command (AUTHORIZE) is executed using the GT license in which the key Kd is embedded and the designated virtual area as parameters. In this description, it is assumed that the encryption / decryption key Kd AAMAA "is embedded in the GT license.
  • the contents of the GT license are set in the TRB ⁇ I line linked to the TLB of the sharing destination module.
  • the data read from the shared protected area by the sharing destination module is cached in a state where it is normally decrypted with the key Kd.
  • the access right PR to the physical page number “002” is set in the fourth line of the TLB, and the fourth line of the TRB corresponding to the line in the TLB is set.
  • the data key Kd AAAAAA is set in the Key field.
  • the protected data area (corresponding to the second line of the TLB) of the source module is used, and the sharing destination module uses the data key Kd AAAAAA. Can be decrypted and read You.
  • step (2) the shared module uses the public key of the generating module or a symmetric key cryptographic key encrypted with the public key to generate the transmitted message. Can be encrypted and passed to the originating module. As a result, this message cannot be decrypted by any other module.
  • the row where the ID is 2 and the row where the ID is 7 show an example where the protected area is shared.
  • Figure 33 shows the processing procedure when the attack resistant area sharing system call is invoked.
  • this procedure from S110 to S123, except that the input parameter at the time of the system call is the address of the head of the area instead of the area size, the procedure shown in Figure 28 (from S90 Since it is the same as S 103), the description is omitted.
  • the content reproduction (Player) application may obtain data from the decoder DRM 40 using the above-described local data sharing method, reproduce the data, and further edit the data.
  • the access conditions specified in the GT license must be complied with.
  • the playback application must generate these processes as GT protection codes.
  • a secure timer is required to enforce playback time and time limits on playback applications.
  • the construction of the secure timer may be realized as an independent hardware TOM outside of GT10.
  • the GT 10 can incorporate a crystal transmitter or the like, it may be constructed as attack-resistant software using the above-mentioned periodic interrupt interval setting command. In either case, assuming that the timer stops for some reason, it must have a function to synchronize with an external Trusted Secure Timer.
  • the decoder DRM30, the media DRM40, and the encryption and decryption libraries in the PKI library 20 used by these DRMs, as well as other applications that require TRM, are distributed as GT protection codes that are protected on GT10. Will be executed. These modules are protected in GT 10 by almost entirely encrypting them.
  • Figure 34 shows an example of the construction model of the DRM software module. This model assumes that the above four modules have been developed by different developers and have been encrypted with different code encryption keys key (Kc).
  • Kc code encryption keys key
  • a thin black arrow indicates the exchange of a license key that has been decrypted
  • a thin white arrow indicates an exchange of a decrypted license key
  • a thick black arrow indicates the encrypted content.
  • the thick white arrow indicates the exchange of the combined contents.
  • the numbers in parentheses indicate the order of the steps. The procedure for downloading, managing, and playing back content and its license key is described below with reference to FIG.
  • the encrypted license key and the encrypted content are recorded on a recording medium from a network such as the Internet via a downloader application.
  • the license key decrypted in the media DRM 40 is securely managed using the method described later, and is recorded on the recording medium in an encrypted state.
  • the re-encryption of the license key is performed using the PKI cryptographic library 20 protected by GT10.
  • the media DRM 40 takes out the license key from the recording medium and decrypts it.
  • the media DRM 40 authenticates the decoder DRM 30, encrypts the license key using the session key shared with the decoder DRM 30, and transfers the license key to the decoder DRM 30.
  • the sharing of the key and the sharing of the protected data in step (7) have been described in ⁇ Secure sharing of protected data area>.
  • the decoder DRM 30 requests the PKI encryption library 20 to perform a decryption process using the encrypted content extracted from the recording medium and the license key obtained from the medium DRM 40 as parameters.
  • the decrypted content is passed to the playback application such as Player via the shared protected data area.
  • the playback application plays the content.
  • the media DRM 40 executes an attack resistant authority setting (SETJTR-RIGHTS) instruction and a register sealing (SEAL-REG) instruction (S131 and S132). Subsequently, the media DRM 40 extracts the secret information embedded therein (S133). The media DRM 40 determines whether or not the GT license corresponding to the extracted confidential information is stored in the license DB that records the license (S134). If it is already stored in the license DB (S134: Yes), proceed to S136, and if it is not already stored in the license DB (S134: No), the media DRM40 licenses the GT license After setting to DB (S135), proceed to S136.
  • SETJTR-RIGHTS attack resistant authority setting
  • SEAL-REG register sealing
  • the media DRM40 provides attack-resistant data for license management. Create a data region. The processing of S136 will be described later in detail with reference to FIG.
  • attack resistant data area for license management could be created (S137: NORMAL), proceed to SI 38. If the attack resistant data area for license management could not be created (S137: ERROR), S Continue to 142.
  • the media DRM 40 initializes the attack-resistant data area for license management (S138), and waits for a license reception request, reproduction permission request, or termination request.
  • the media DRM 40 receives the license (S143), and returns to S139.
  • the media DRM 40 performs reproduction permission (S144), and returns to S139.
  • a termination request is received (S141: Yes)
  • a register release (RELEASE_REG) instruction is executed (S145), and the processing is terminated.
  • the media DRM 40 If the generation of the attack resistant data area for license management fails (S137: ERROR), the media DRM 40 outputs an error display to an output device (not shown) (S142), and proceeds to S145.
  • the media DRM 40 When generating the attack-resistant data area for license management, first, the media DRM 40 generates a GT license for the access right PRW using the code encryption key Kd (S151). Subsequently, the media DRM 40 calls the attack resistance area acquisition system call (S152). The processing of S152 is as described above.
  • the decoder DRM30 executes an attack-resistant authority setting (SET_TR-RIGHTS) instruction and a register sealing (SEALJREG) instruction (S166 and S166). Subsequently, the media DRM 40 extracts the secret information embedded therein (S163).
  • SET_TR-RIGHTS attack-resistant authority setting
  • SEALJREG register sealing
  • the decoder DRM30 generates a shared protected data area for the decrypted content (S164). This S 164 will be described later in detail with reference to FIG.
  • the decoder DRM30 waits until receiving one of a reproduction permission request, a reproduction request, and an end request.
  • the decoder DRM30 acquires a content license key from the media DRM40 (S170), and returns to S166.
  • the decoder DRM30 determines whether or not a license key for content has been acquired (S171). If the content key has been acquired (S171: acquired), the decoder DRM30 decrypts the encrypted block and performs processing to share the block (S173). Details of S173 will be described later with reference to FIG. Subsequently, the decoder DRM30 notifies the playback application of the return value (S174), and returns to S166. If the license key has not yet been acquired in the determination of S171 (S171: none), an error is displayed on the output device (not shown) (S172), and the process proceeds to S175. If an end request has been received (S168: Yes), the process proceeds to S175, where the decoder DRM30 executes a register release (RELEASE_REG) instruction and ends the processing.
  • RELEASE_REG register release
  • the decoder DRM30 uses an attack-resistant area acquisition system to acquire an attack-resistant area for recording the content decoded by the decoder DRM30. Call the call (S181). This processing has already been described.
  • the attack resistant area has been generated (S 182: NORMAL)
  • the process proceeds to S 184. If not (S182: ERROR), an error display is output to an output device (not shown) (S183), and the process returns to the main flow.
  • the decoder DRM30 causes the GT 10 to authenticate the PKI cryptographic library used to decrypt the encrypted content.
  • This authentication procedure is the same as the authentication procedure described with reference to FIG. 32 in ⁇ secure sharing of protected data area>.
  • S 185 NORMAL
  • S 185 ERROR
  • S186 an error message is output to an output device (not shown) (S186), and the process returns to the main flow.
  • the decoder DRM30 calls the attack resistance area sharing system call.
  • S188: NORMAL the processing in S184 is performed normally
  • the flow returns to the main flow.
  • S188: ERROR the processing in S184 is not performed normally
  • an error message is output to an output device (not shown), and the process returns to the main flow.
  • the decoder DRM30 determines whether or not the playback application has already been authenticated (S191). If it has already been authenticated (S191: already authenticated), proceed to S196. If not yet certified (S 191: uncertified), S 192 forces and S 195 are performed. This process is the same as S184 to S188 in FIG. 38, and thus the description is omitted. If an error occurs in the processing from S192 to S195 (ERROR in S193 and S195), an error display is output to an output device (not shown) (S198), and the flow returns to the main flow. I do. When S199 to S195 are performed normally, the playback application and the decoder DRM 30 share the attack resistant area, and the playback application reads the content written in the attack resistant area by the decoder DRM 30. Will be able to
  • the decoder DRM30 decrypts the encrypted content using the PKI encryption library 20.
  • the decrypted content is written to the shared attack resistant area. If the decryption has been performed normally (S197: NORMAL), the process returns to the main flow. If the decryption was not performed normally (S197: ERROR), the process proceeds to S198.
  • the reproduction application executes an attack-resistant authority setting (SET_TR_RIGHTS) instruction and a seal register (SEAL-REG) instruction (S201 and S202). Subsequently, the playback application extracts the secret information embedded in itself (S203). Next, the playback application requests the decoder DRM 30 for authentication (S204). Based on this authentication request, S 192 is performed.
  • SET_TR_RIGHTS attack-resistant authority setting
  • SEAL-REG seal register
  • the playback application waits for a playback request, another request, or a termination request. If the authentication is not successful (S205: ERROR), the playback application displays an error message. An output is made to an output device (not shown) (S 214), and the process proceeds to S 216.
  • the reproduction application When a reproduction request is received (S206: Yes), the reproduction application requests the decoder DRM 30 to decrypt the encrypted block (S210). If the return value from the decoder DRM30 is normal (S211: ORMAL), the playback application plays the block (S212). Until the reproduction of the content ends (S214: No), S210 to S212 are repeated. When the reproduction of the content ends (S 214: Yes), the process returns to S 206.
  • Figure 41 shows the method for maintaining and managing the secret information generated by the DRM code package developer, such as the secret key Kdrm corresponding to the public key of the public key cryptography for which the certificate was issued.
  • the secret key Kdrm corresponding to the public key of the public key cryptography for which the certificate was issued.
  • thin arrows indicate the flow of data
  • thick white arrows indicate embedding of a key or the like.
  • the numbers in parentheses indicate the order of processing, and correspond to the numbers of the procedures in the following description.
  • the private key (Kdrm, etc.) generated by the developer is encrypted with the key Kprd of the symmetric key cryptography generated by the developer in each case of class-individual and embedded in the package.
  • the GT-licensed Kprd and access condition 'PR' are embedded in the protection code in a form that can be read only in the attack-resistant mode.
  • the entire code is encrypted with Kc and protected as DRM.
  • Kc is encrypted with KPgt and entered into the DRM package as a DRM license.
  • this GT license is supplied to GT10 from VHTRM, and Kprd is read inside GT10.
  • Kprm is decrypted and used by Kprd.
  • This method can be used as a method for managing not only the DRM secret key but also the secret keys of other protection packages.
  • the management method of general information on protected content and UMC license may be inherited from UDAC-MB and UDAC-LA.
  • Figure 42 shows the memory access method for license management.
  • license secret information such as a content decryption key is recorded and managed in a protected data area in RAMI7.
  • the information in the protected data area may be stored as a file in storage / flash memory.
  • the data encryption key Kd may be stored in a general external storage device as a row of an encryption key table in a state of being encrypted with the TRB encryption key Ktrb. It is necessary to refresh the contents of Ktrb and Ktlb after a certain period of time in order to increase the attack resistance of Ktrb and Ktlb.
  • all license information must be backed up using a temporary key generated by the attack process. After Ktrb and Ktlb changes by refresh, rebuild the page table and encryption key table. All license information should be restored and restored in the reconstructed attack resistant area.
  • the CRL control function for each license may be included in the license management function described above.
  • the certificates of one DRM package are issued as many as the certificates that GT10 has. If the DRM package itself is revoked, all of those certificates will be revoked. When revoking a specific GT, only the so-called package certificate issued for that GT is revoked.
  • the GT license When super-distributing program contents and handling UDAC licenses, the GT license may be used as it is as a simplified super-distribution function without using DRM software. Also, it may be processed as UDAC-MB or PI license using DRM software built on GT. When using DRM software, of the UDAC-MB / PI license, only the basic access rights (PR, X, PRW, PWX) are converted to GT licenses in DRM and enforced using CPU access control instructions (AUTHORIZE). You. Other access conditions are forcibly processed in the GT-protected DRM.
  • PR, X, PRW, PWX basic access rights
  • the GT license is not transferred, but the license transfer function between DRMs can be realized.
  • Two running on the same GT Transfer licenses between DRM processes in the DRM process. ⁇ Licenses can be implemented through a shared attack area that is authenticated by secure sharing of protected data.Protocols such as UDAC-MB and UDAC-PI It may be realized by using.
  • UPL Unreplicatable Private Locker
  • the license transfer function the following UPL (Unreplicatable Private Locker) must be stored in the TRM in the license management secret information in order to prevent unauthorized copying due to retransmission attacks. Must be stored. If you want to realize this UPL only with GT, license management is performed in the attack resistant area where both TRB. Uo (value of uo field in TRB) and TRB.
  • UPL In order to implement UPL with TRM outside of GT, UPL needs to implement TRM authentication protocol such as UDAC-MB in UPL.
  • TRM authentication protocol such as UDAC-MB
  • An externally implemented Permanent UPL such as Secure Maraud C with UDAC can be used.
  • the code blocks and data blocks are plain text or plain text (ebim-0 or 1).
  • a block may be a combination of a ciphertext, a plaintext, and other information.
  • the GT 100 according to the second embodiment is In addition to the components related to the above, further, protection block selectors 101 and 104, a hash checker 102, and a hash engine 103 are provided.
  • the protection block selector 101 identifies whether the block is a code block or a data block output from the cache 11 or 12 based on the value of ebim. If the output block is a block to be protected, the protection block selector 101 outputs the block to the hash engine 103.
  • the hash engine 103 generates a hash of the block, and after the hash is generated, the cryptographic block 16 encrypts the block and outputs it to the RAM 7. On the other hand, if the block output from the cache 11 or 12 is not a block to be protected, the protection block selector 101 outputs the block to the RAM 7.
  • the protection block selector 104 identifies the code block or data block output from the RAM I 7 whether the block is an encrypted block or a plaintext block. If the output block is an encrypted proxy, that is, a protection block, the protection block selector 104 outputs the protection block to the encryption engine 16.
  • the cryptographic engine 16 decrypts the protection block and outputs the decrypted block to the hash engine 103.
  • the hash engine generates a hash of the block and outputs it to the hash checker 102.
  • the hash checker 102 checks the generated hash, and if the hash is correct, outputs the block to the cache 12 or 13. On the other hand, if the block output from the RAM 7 is not a protection block, the protection block selector 104 outputs the block to the cache 12 or 13.
  • protection block selectors 101 and 104 are provided in FIG. 43, the protection block selectors 101 and 104 are connected to one protection block selector. It may be configured as a collector. This makes it possible to reduce the size of the circuit.
  • the TLB shown in Figure 5 contains an ebim field.
  • the value of ebim is 0 or 1.
  • 2 to 7 are added as possible values of this ebim.
  • the structure of the block according to the value of ebim will be described.
  • Bit 0 encryption flag. If this flag is on, it indicates that the block is encrypted.
  • Bit 1 Protection block start identification code flag. When this flag is on, it indicates that the protected block start identification code is added to the block. When the individual flag is off, GT10 does not need to recognize the protection block opening identification code.
  • Bit 2 Hash addition ⁇ Confirmation flag. When this flag is on, GT 10 adds a hash to the data block when sweeping data out of GT 10. Also, when importing code or data into GT10, check the hash value added to the block. If this flag is off, the block does not need to be hashed or verified.
  • ebim values are set based on the value of the ebim field in the licensed code key ACgt included in the GT license, as in the first embodiment.
  • the structure of the protection code block and the structure of the protection data block may be the same. This makes it possible to improve the utilization rate of the circuit resources in the CPU.
  • a block generated by a developer or creator contains random numbers, general instructions and data, and if necessary, a hash. If ebim is 1 or 5, this block is encrypted to generate a protected block. If ebim is 2, 3, 6 or 7, after this block is decoded, the protection block head identification code is prepended in plaintext. A protection block is generated.
  • the protection block head identification code includes an encryption flag indicating whether the block is a protection block and a hash flag indicating whether a hash is added at the end of the block.
  • the protection block head identification code and the encrypted random number part constitute a protection block start instruction.
  • the protected block on RAM I 7 is decrypted in GT 10 to obtain plaintext general instructions and data. If ebim is 1 or 5, the random part / hash part is converted to a NOP (No OPeration) instruction so that the addresses of the code and data are not changed, and then converted to the instruction cache 12 or data cache 13. Loaded. If ebim is 1, the same as in the first embodiment is there. When ebim is 2, 3, 6, or 7, the protected block head identification code in addition to the random number part and hash part is converted to NOP (No OPeration) and then loaded into the instruction cache 12 or data cache 13. You.
  • NOP No OPeration
  • the structure of the protection block when the work data on the processor core 11 is encrypted is the same as the structure of the protection block when the block generated by the developer or the creator is encrypted.
  • Figure 45 shows the block structure when ebim is 4.
  • the block on the RAM has a structure in which a signature is added to plaintext code or plaintext data.
  • the signature is converted to a NOP instruction.
  • the signature may be a value obtained by encrypting a code or data hash (such as SHA-1) with the encryption key Kc or Kd. Note that Kc and Kd are specified in the GT license and set in the TRB No. key field (TRB.key).
  • the protection block selector 104 waits for a block load request from the RAMI 7 (external memory) (S221).
  • the protection block selector 104 reads the value of the ebim field in the row corresponding to the predicted block address from the TLB (S222).
  • the protection plot selector 104 determines whether or not the first bit of ebim is on (S223).
  • the first bit of ebim indicates whether or not the block has an open protection block command. If the first bit of ebim is on (S2 23: on), the protected block start instruction is added to the block.
  • the protection block selector 104 reads the protection block start instruction added to the head of the block (S224), and determines whether or not the encryption flag is on in the protection block start instruction (S22). Five) . If the encryption flag is on (S205: on), the process proceeds to S229. In S 229, the protection block selector 104 outputs the block to the cryptographic engine 16, and returns to S 201. In this case, the block is transferred to the cache 12 or 13 after being decrypted.
  • the protection block selector 104 further determines whether the second bit of ebim is on (S226). The second bit of ebim indicates whether the hash must be verified when transferring the block. If the second bit of ebim is on (S226: on), the process proceeds to S209. If the second bit of ebim is off (S226: off), the protection block selector 104 transfers the block to the cache 12 or 13 (S227).
  • the protection block selector 104 determines whether the zeroth bit of ebim is on. (S228). Bit 0 of ebim indicates whether the block needs to be encrypted. If the 0th bit of ebim is on (S228: on), the process proceeds to S229. If the 0th bit of ebim is off (S228: of ⁇ ), the protection block selector 104 further determines whether the second bit of ebim is on (S230). If the second bit of ebim is on If there is (S230: on), the process proceeds to S229.
  • the protection block selector 104 transfers the block to the cache 12 or 13 (S231), and S22 Return to 1. Next, the processing performed by the hash engine 103 will be described with reference to FIG.
  • the hash engine 103 waits for an event of a hash request to occur (S241). When the event occurs, the hash engine 103 reads the block for which the request for the hash was made (S242). Further, the hash engine 103 reads the ebim corresponding to the address of the block and determines whether or not the second bit of the ebim is on (S243). If the second bit of ebim is on (S 243: on), the hash engine 103 generates a hash of the block (S 244), and compares the block and the contents of the generated hash to the next. Transfer to the circuit block (S245) and return to S241. On the other hand, if the second bit of ebim is off (S 243: off), the hash engine 103 transfers the block to the next circuit block without generating a hash (S 246), and the process proceeds to S 24 Return to 1.
  • the hash checker 102 waits for an event of a hash request to occur (S 2 5 1). When an event occurs, the hash checker 102 reads the requested block (S252). Subsequently, the hash checker 102 reads the ebim corresponding to the address of the block and determines whether or not the second bit of the ebim is on (S253). If the second bit of ebim is on (S 2 53: on), the hash checker 102 checks the hash generated by the hash engine 103 and the hash added to the block. Is compared with the menu (S254).
  • the protection block selector selects a block based on ebim. Examples of methods other than this method are shown below.
  • the protection block selector reads this bitmap first and determines whether to output the block to the general line or to output the block to the decoding line.
  • Method 2) Set an area with a length equal to the product of the random number length and the number of blocks as a physical area dedicated to NOP.
  • Fig. 49 shows the processing of NOP by this method.
  • the protection code block or the protection data block in RAMI 7 is encrypted.
  • the protection code block or protection data block includes a protection block head identification code.
  • this protected code block or protected data block is decoded in GT 10
  • a random number, and a hash is obtained.
  • Data is recorded, and data at the virtual address where the NOP is to be recorded is not recorded. If the code accesses the NOP temporary address, the NOP is returned to the code.
  • the NOP stored in the virtual memory may be read from the OS or the like, or may not be read.
  • the fourth embodiment relates to a case where a protection process is operated in a CPU having two or more GTs 10 described above, that is, a multi-CPU.
  • Fig. 50 shows the configuration of a multi CPU with GT 10 and 0B 10B. As shown in Fig. 50, they are connected via GT10A, GT10B and RAMI ⁇ 1 bus. GT 10 ⁇ and GT 10 ⁇ each have a cache. If multiple threads are executed in parallel by GT 10 A and GT 10 B, prior to execution, GT 10 A and GT 10 B must be fully s ⁇ DCTP (Digital Transmission Content Protection), EiE (Full Authentication GT10A and GT10B use the session key Ksnp when exchanging confidential information, protection code, and protection data. GT 10 B can safely exchange Ktrb, Kc, Kd, etc. GT 10 A and GT 10 B encrypt the data in the cache using the session key Ksnp and transfer them synchronously with each other. Achieve synchronization of cache contents.
  • DCTP Digital Transmission Content Protection
  • EiE Full Authentication GT10A and GT10B use the session key Ksnp when exchanging confidential information, protection code, and protection data.
  • GT 10 B can safely exchange
  • Figure 51 shows an example of a tool group that outputs a protected code execution form from a code object.
  • Figure 51 shows an example of generating a protected code executable and a license, and then generating SCDF data through an SCDF generation tool for super-distribution of the executable.
  • the SCDF generation tool includes a linker preprocessing unit, a linker, a protected code execution format generation unit, and an SCDF generation unit.
  • the code object is divided into multiple blocks by the linker preprocessor, and a NOP instruction is added to each block.
  • the linker performs address resolution.
  • the protection code execution format generation unit generates a protection code execution format by encrypting each block using the code encryption key.
  • the GT license generation unit generates a license including the code encryption key and encrypted with a public key that is paired with the secret key.
  • GT10 To realize the protection by GT10, GT10 and DRM software module protected by GT10 are required. However, at the beginning, GT is not widely used, and 03 does not support the functions of 0, 10, so it is necessary to promote the following scenarios.
  • GT Global System for Mobile Communications
  • PDA Personal Digital Assistance
  • mobile phone including simple mobile phone
  • smart card etc.
  • IC cards, RF ID media, AV (Audio Visual) devices, GR ID calculation, robots, etc. will be described as examples.
  • FIG. 52 shows a system configuration example when GT 10 or 100 is mounted on a personal computer or a workstation.
  • the motherboard has GT 10 or 100 mounted.
  • the system controller includes a USB (Universal Serial Bus) controller, an IDE (Integrated Drive Electronics) controller, an IEEE 1394 controller, a video controller, an audio controller, and the like.
  • recording media such as a memory card for recording digital contents, an IC card, a magnetic disk, a magneto-optical disk, and a digital versatile disk include:
  • North Bridge is described as a system controller
  • USB and IDE are described as interfaces
  • IEEE 1394 is described as a serial bus, but this is not intended to limit the system configuration.
  • thermopile devices such as mobile phones Application explain about.
  • the mobile phone terminal authentication function can be realized with stronger security than the conventional method.
  • the function of exchanging SIM (Subscriber Identity Module) cards of mobile phones can be realized more safely by using software that exchanges protected data between mobile phones that implement GT.
  • the security function to be protected in the GT is simply added as firmware later, and the same level of additional hardware as the hardware TRM is added. IC cards with added security strength can be created. The security evaluation of the IC card only needs to be performed for the firmware added to the GT.
  • GT100 or 100 is mounted on security cards or modules such as IC cards and RFID modules, it is not necessary to apply TRM to each customized chip, and it is sufficient to implement TRM only for the CPU part. This makes it possible to implement a powerful media DRM at the hardware TRM level without specially incorporating a chip dedicated to decoding symbols. It is also possible to realize personal authentication, credit card functions, prepaid card functions, etc. with strong security at the hardware TRM level by simply adding software.
  • GT core control refers to a portion related to TRM, TLB, and the like. However, in this case, it is necessary to connect the CPU and the IC card with an ultra-high-speed bus.
  • GT protects agents from being fraudulent and fulfilling their mission while on the move Function can be realized.
  • GT can provide a secure movement function to VHTRM as an anti-attack agent.
  • VHTRM secure movement function
  • Integrity At the request of the GRID calculation, it was not possible to confirm or confirm whether the requested execution code was executed correctly using the correct CPU and the correct data. For this reason, there is no means to reliably check the requesting user, no matter what misconduct, or even if the requested computer contains a virus that rewrites the execution code.
  • Lopot CPU has a mechanism to execute only the code whose signature has been confirmed.
  • the CPU for the robot shall not exchange information with a high security level with a CPU without a certificate.
  • the service that collects personal information may not comply with the “Personal Information Protection Policy” presented to the service user. Even if policies can be exchanged by using P3P (Platform for Privacy Preference), there is no technology to enforce this.
  • P3P Planform for Privacy Preference
  • a GT is implemented in the CPU of the server that provides each service, and then the server is protected with GTs for server DRM software and server applications that handle personal information. Package as code.
  • access conditions can be set for the processes that execute software in the GT license. Therefore, until now, access Even if the server cannot be forcibly controlled from the outside, access conditions for application operation can be forcibly set.
  • GT with a sequential code signature verification function can counter such viruses.
  • the GT according to the second embodiment is mounted on the CPU, and the software (code and data) for checking the implementation code is protected by the GT.
  • G T CPU
  • G T CPU
  • Virus-checking software computes code hashes and verifies reputation before running each piece of code.
  • GTs can become the infrastructure of trusted ubiquitous computing as a secure general-purpose computing platform that can be used anytime, anywhere, by anyone.

Description

明細書 開放型汎用耐攻擊 C P U及びその応用システム 技術分野
本発明は、 機器内部の情報を改ざんしたり、 秘密情報を取り出したりしょう とする攻撃に対して対抗する技術に関する。 景技術
近年、 デジタルコンテンツの流通の促進に伴い、 著作権などのコンテンツに 係わる権利を保護する技術 （DRM : (Digital Rights Management) が提供 されている。 DRMの例として、 例えば、 三洋電機、 日立、 富士通の 3社が共 同 fe^Sした UDAC (Universal Distribution with Access Control) 力 S挙げ られる。
UDACのような DRMを実装する際、 コンテンツ保護のセキュリティを十 分なレベルにするためには、 利用者のシステムにおいて D RMを T RM (Tamper Resistant Module) とすることが重要である。 （以下、 DRMを T RMとすることを DRMの TRM化という。 ） 現在、 コンシユーマ向けの製 品で一般に実施される TRM化には、 大きく分けてハードウ ア TRM及びソ フトウエア TRMの 2つの方法がある。
ハードウユア TRMとは、 半導体の外部端子から秘密情報の読み出しなどが できない構造にし、 特殊コーティングゃ極微細化などを施すことによって実現 された TRMである。 ハードウエア TRMをソフトウエア TRMと比較して、 特に 「攻撃対抗容器」 と呼ぶこともできる。 ソフトウエア TRMとは、 暗号化 させたいコードを解析困難な構造にして暗号化し、 そのコードを実行の瞬間に 復号することによって実現された T RMである。
しかし、 従来の T RMには、 以下のような問題があった。
1 . ハードウェア T RMの問題
■ コンシユーマ向け用途ではコストを重視する関係上 D RMを半導体パッケ ージ化する必要があるが、 一つのチップに盛り込むことができるリソースには 限りがあるだめ、 多様な機能を提供することはできない。 ライセンスキーや C R L (Certificate Revocation List) を記録する領域の大きさを拡張したい 場合や、 コ ンテンツ利用条件を X r M L ( extensible rights Markup Language) で表現したい場合などには、 ハードウェア T RMでは対応できない。
·安全性を重視すると、 利用するプロセッサと記録媒体をすベてハードゥエ ァ T R M内に持つ必要があるが、 このため製造後に機能を拡張させることが困 難になっている。 また、 このことからソフトウェアが利用できる記録媒体が限 定されるため、 リソース消費が高い一般の （保護の必要がない） ソフトウェア を同時にプロセッサに実行させることは困難である。 また、 暗号鍵が異なる複 数の保護ソフトウェアを同時にプロセッサに実行させることも困難である。 つ まり、 ハードウェア T RMには汎用性がない。
■ コンテンツの種類の追加や D RMのバーシヨンアップごとに新たなチップ の開発し、 新たに半導体製造工程などのラインを起こすことが必要となるため 製造コストが大きくなる。
■互換性を持つ汎用 C P Uチップ上にそれぞれのソフトウエアを開発 '搭載 するだけで何種類もの機能を利用者に提供することによりスムーズなバグ修正 や機能拡張も実現してきた 「情報技術の逐次進化」 を阻害しかねなかった。
2 . ソフトウェア T RMの問題
-おおもとの秘密鍵は暗号化することができず、 どのように分散などして保 管してもソフトゥヱァ解析だけで容易に秘密鍵を見つけ出すことができる。 'ノヽ一ドウエア I C E (In Circuit Emulator) を用いれば実行内容をトレ ースすることにより、 秘密鍵を始めとする各種秘密情報を容易に見つけ出すこ とができる。 発明の開示
本発明の目的は、 上記問題を解決し、 ソフトウェア T RM並みの汎用性を持 ちつつも、 ハードウエア T RM並みの安全性を有する T RMを提供することで ある。
上記目的を達成するために、 本発明の 1態様によれば、 中央演算装置におい て、 秘密裏に隠された第 1の秘密鍵と、 暗号化及び復号を行う暗号手段とを備 え、 前記第 1の秘密鍵は、 公開鍵と対であり、 前記暗号手段は、 前記公開鍵を 用いて暗号化された第 1のプログラムの第 1のライセンスを前記第 1の秘密鍵 を用いて復号することにより、 前記第 1のライセンスから前記第 1のプロダラ ムを復号するためのコード復号鍵を取得するように構成する。 なお、 コード復 号鍵は、 第 1のプログラムを暗号化する際に使用されたコード暗号鍵と同じで あってもよレ、。 また、 第 1のライセンスは、 第 1のプログラムに埋め込まれる 事としてもよいし、 両者は別々に流通する事としても良い。
このように構成することにより、 前記第 1のプログラムを復号するための鍵 を得るために必要な秘密鍵は、 中央演算装置内に秘密裏に記録されているため、 分散されて保管されることはない。 従って、 プログラムを解析する事によって 秘密鍵が容易に発見されてしまうという問題を解決する事ができる。
また、 上記中央演算装置は、 キャッシュを更に備え、 前記暗号手段は、 前記 第 1のプログラムを構成する暗号化ブロックがメモリ領域から前記キヤッシュ に出力される際に、 キャッシュ単位で前記暗号化ブロックを復号する、 ことと してもよい。 キャッシュ単位で暗号化ブロックを復号し、 キャッシュに記録す ることにより、 従来より安全性を向上させることが可能となる。
さらに、 また、 上記中央演算装置は、 ユーザが参照したり改ざんしたりする ことができない耐攻擊バッファを更に備え、 前記コード復号鍵は、 前記耐攻擊 バッファに記録されることとしてもよい。 耐攻擊バッファ内に記録された鍵は、 カーネルモードであってもユーザが参照したり改ざんしたりする事ができない ため、 コード復号鍵を安全に保持することが可能となる。
ここで、 前記耐攻撃バッファは、 さらに、 外部出力禁止情報及びキャッシュ ロック情報を含み、 前記外部出力禁止情報は、 対応する前記耐攻撃バッファ内 の情報を前記耐攻撃バッファ外に出力しても良いか否かを示し、 前記キヤッシ ュロック情報は、 対応する情報をキャッシュ外に出力しても良いか否かを示し、 前記外部出力禁止情報及び前記キヤッシュロック情報に基づいて、 第 1のプ ログラム及び他のプログラムとの間における前記第 1のライセンスの移動は管 理されることとしてもよい。 これにより、 前記中央演算装置に、 複製不能ブラ ィペートロッカーを実現させる事が可能となる。 従って、 例えば、 複数のプロ グラム間においてライセンスを移動可能とする場合であっても、 再送攻擊によ るライセンスの不正コピーを防止することが可能となる p
また、 上記中央演算装置において、 前記第 1のライセンスは、 前記第 1のプ ログラムの実行プロセスがメモリ領域にアクセスする際のアクセス条件を含み、 前記第 1のプログラムを構成する暗号化ブロックが記録される前記メモリ領域 のア ドレスと前記メモリ領域へのァクセス条件とを記録する T L B (Translation Lookaside Buffer) と、 メモリ管理手段と、 キャッシュと、 プ 口セッサコアを更に備えるように構成してもよい。 この構成において、 前記耐 攻撃バッファは前記 T L Bとリンクされ、 前記メモリ管理手段は、 前記暗号化 プロックを記録するメモリ領域のァドレスに基づいて前記 T L Bから前記メモ リ領域へのアクセス条件を取得し、 さらに、 前記耐攻擊バッファから、 前記メ モリ領域に対応する前記コード復号鍵を取得する。 前記プロセッサコアは、 前 記メモリ管理手段が取得した前記アクセス条件に基づいて、 前記実行プロセス から前記メモリ領域へのアクセスを実行することが許可されているか否か判定 し、 前記メモリ領域へのァクセスを実行する事が許可されていると判定した場 合、 前記実行プロセスから前記メモリ領域へのアクセスを実行する。 前記暗号 手段は、 前記メモリ管理手段が取得した前記コード復号鍵を用いて前記メモリ 領域内の前記暗号化プロックを復号して得られたコードを前記キヤッシュに書 き込む。
メモリ領域は、 T L Bを介して耐攻撃バッファと対応付けられており、 その メモリ領域に書きこまれたブロックを復号するための鍵は、 この対応関係に基 づいて取得される。 さらに、 メモリ領域へのアクセスも、 T L B内のアクセス 条件に従って制御される。 従って、 安全にメモリ領域へのアクセス制御及びブ 口ックのキヤッシュへのロードを行うことが可能となる。
ここで、 前記第 1のプログラムの実行プロセスからアクセスされるメモリ領 域が、 第 1のメモリ領域から第 2のメモリ領域に切り替わった場合、 前記メモ リ管理手段は、 さらに、 前記耐攻撃バッファから取得された前記第 1のメモリ 領域に対応するコード復号鍵と、 前記第 2のメモリ領域に対応するコード復号 鍵とがー致するか否か判定し、 一致すると判定した場合、 前記実行プロセスか ら前記第 2のメモリ領域へのアクセスを実行し、 一致しないと判定した場合、 前記実行プロセスから前記第 2のメモリ領域へのアクセスを実行しない、 こと としてもよい。 これにより、 Call、 Jump または Return 等の命令によって、 あ るメモリ領域から、 そのメモリ領域に対応するコード復号鍵と異なる他のコー ド復号鍵が対応している他のメモリ領域に実行中ァドレスが移動した際には、 その実行プロセスから上記他のメモリ領域にはアクセスできないこととなる。 これにより、 あるオーナープロセスが、 他のオーナープロセスのメモリ領域へ アクセスすることを禁止することが可能となる。
さらにまた、 上記中央演算装置において、 前記耐攻擊バッファには前記コー ド暗号鍵ごとに、 異なるデータ暗号鍵が記録され、 前記暗号手段は、 前記デー タ暗号鍵を用いて前記キヤッシュ内のデータを暗号化した後、 前記 T L Bを介 して前記データ暗号鍵に対応付けられたメモリ領域に記録し、 前記メモリ領域 力、ら暗号化されたデータを読み出して前記データ暗号鏈を用いて復号した後、 前記キャッシュに書き込むこととしてもよい。 これにより、 データをメモリ領 域に退避させたり、 キャッシュにロードさせたりする操作を、 安全に行う事が 可能となる。
また、 上記中央演算装置において、 第 1のコードを実行することにより得ら れた作業データを第 2のコードで利用する場合、 前記プロセッサコアは、 前記 作業データを記録するメモリ領域へのアクセス権を前記第 2のコードに与える ように前記 T L Bを設定し、 且つ、 前記作業データを暗号化するためのコード 暗号鍵を、 前記第 2のコードが前記作業データを前記メモリ領域から読み出す 際に使用するように前記耐攻撃バッファを設定することとしてもよい。
これにより、 通常、 第 1のコードのコード暗号鍵と、 第 2のコードのコード 暗号鍵が異なる場合であっても、 第 1のコードと第 2のコードとがデータ暗号 鍵を共用することにより第 1のコードを実行した結果得たデータを第 2のコー ドが読み出す事が可能となる。 従って、 前記中央演算装置が 2以上のソフトゥ アを保護しながら実行する場合であっても、 必要に応じて安全にメモリ領域 を共有する事が可能となる。
また、 上記中央演算装置において、 レジスタと、 レジスタへのアクセス制御 を行うためのレジスタアクセス制御テーブルと、 を更に備え、 前記プロセッサ コアは、 前記レジスタアクセス制御テーブル内の封印フラグを用いて、 前記レ ジスタの封印及び解放を制御する、 こととしてもよい。 これにより、 プロセス がデータをレジスタに格納する場合には、 現在実行中のプロセス以外からレジ スタに格納されたデータにアクセスする事ができないように封印することが可 能となる。
また、 上記中央演算装置において、 前記 T L Bの内容を外部のページテープ ルに記録する際には、 前記暗号手段は、 記録する内容に署名を付与し、 前記ぺ ージテーブルの内容を前記 T L Bに取り込む前には、 前記暗号化手段は、 前記 署名が正しいことを確認する、 こととしてもよレ、。 これにより、 T L Bの内容 を安全にぺージテーブルに保持させる事が可能となる。
また、 上記中央演算装置において、 前記耐攻搫バッファの内容を外部記憶装 置内の暗号化キーテーブルに記録する際には、 前記喑号手段は、 記録する内容 を暗号化することとしてもよレ、。 これにより、 耐攻撃バッファの内容を外部記 億装置に安全に保持する事が可能となる。
なお、 T L Bの内容の署名を作成する際に使用される秘密鍵、 及び耐攻撃バ ッファの内容を暗号化する際に使用される秘密鍵は、 ともに、 中央演算装置内 のプロセッサによって生成されることとしてもよい。
また、 前記中央演算装置は、 他の中央演算装置と接続され、 前記中央演算装 置は、 前記他の中央演算装置と相互に認証を行う事にことによりセッション鍵 を取得し、 前記中央演算装置の前記暗号手段は、 前記セッション鍵を用いて前 記中央演算装置の前記キャッシュの内容を暗号化して、 前記他の中央演算装置 に同期転送する、 こととしてもよい。 これにより、 上記構成を有する中央演算 装置を複数有するマルチ C P Uにおいて、 キャッシュ内の内容を安全に同期さ せることが可能となる。
また、 上記中央演算装置において、 前記暗号手段は、 前記第 1のプログラム を実行する前に、 前記公開鍵を用いて第 2のプログラムに付加された前記第 2 のライセンスを復号する事により第 2の秘密鍵を暗号化する際に用いられた秘 密鍵暗号鍵を取得し、 さらに、 前記取得された秘密鍵暗号鍵を用いて前記第 2 の秘密鍵を復号する、 こととしてもよい。
また、 この際に、 前記第 2のライセンスには、 第 1のプログラムの実行プロ セスから読み出しのみ可であることを示すアクセス条件が付加されており、 前 記第 2の秘密鍵は、 前記第 1のプログラムの実行プロセスからの読み出しのみ 可能であることとしてもよい。 第 2の秘密鍵を第 1のプログラムの実行プロセ スからのみ読むことができないこととすることにより、 秘密情報を安全に維持 管理することが可能となる。
なお、 前記第 1のプログラムは、 T RM化が要求されるどのようなソフトゥ エアであってよい。 例えば、 第 1のプログラムとして、 トラステッドコンビュ 一ティングモジュール、 前記中央演算装置に電子財布を実現させるプログラム、 個人情報を扱うソフトウ ア、 前記中央演算装置の実装コードのウィルスチエ ックソフトゥ ア、 複数の中央演算装置間を移動する移動エージェント、 ロボ ットの制御プログラム、 I Cカード用のセキュリティプログラム等が挙げられ る。
また、 上記中央演算装置において、 前記第 1のプログラムを構成するブロッ クには様々な形態が考えられ、 それに応じて中央演算装置に更なる手段を備え る事としてもよい。
例えば、 ブロックは、 ブロックのハッシュ値の確認が必要であるか否かを示 すハッシュ確認要否情報を含み、 前記ハッシュ確認要否情報に基づいて、 前記 プロックのハッシュ値を算出し、 前記ブロックに付加するハッシュ手段と、 前 記ハッシュ確認要否情報に基づいて、 前記プロックの前記ハッシュ値を確認す るハッシュ確認手段と、 を更に備えることとしてもよい。
また、 例えば、 ブロックは、 ブロックが保護を必要とするか否かを示す暗号 化要否情報を含み、 前記暗号化要否情報に基づいて、 前記ブロックを前記暗号 手段に出力する力、 そのままキャッシュ又はメモリ領域に出力するか判定する 保護ブロック選択手段を、 更に備えることとしてもよい。
また、 プロックごとにプロックを選択する保護プロック選択手段の付加を低 減するために、 以下のようにしてもよレ、。
例えば、 第 1のプログラムの実行ファイルのヘッダは、 前記第 1のプログラ ムを構成するプロックの構成を示す暗号化プロックビットマツプを含み、 保護 ブロック選択手段は、 前記暗号化ブロックビットマップに基づいて、 前記ブ口 ックを前記暗号手段に出力するか、 そのままキャッシュ又はメモリ領域に出力 するか判定する。
また、 例えば、 第 1のプログラムのコードの先頭は、 前記第 1のプログラム を構成する複数のブロックが、 平文ブロックと暗号化ブロックの組合せの繰り 返しであり、 前記組合せにおいて平文プロックが連続する数及び暗号化プロッ クが連続する数を指定するコードであり、
プロセッサコアこのコードを実行することにより、 前記プロックを前記暗号 手段に出力するか、 そのままキャッシュ又はメモリ領域に出力するか判定する。 また、 上記中央演算装置において、 前記キャッシュとメモリの間に、 前記暗 号手段を介するキャッシュラインと、 前記暗号手段を介さないキャッシュライ ンと、 を更に備えることとしてもよい。 これれにより、 処理の高速化を図る事 ができる。
また、 本発明の他の態様として、 中央演算装置に保護プログラムを実行する 許諾を与える制御を行わせるプログラムであって、 前記保護プログラムは、 コ 一ド喑号鍵によって暗号化され、 保護プログラムに対応して、 前記コード暗号 鍵を含み、 且つ、 前記中央演算装置に秘密裏に備えられた秘密鍵と対になる公 開鍵によつて暗号化されたライセンスが存在し、 前記中央演算装置が前記保護 プログラムを実行する前に、 前記ライセンスを前記中央演算装置に投入し、 前 記中央演算装置に備えられた暗号手段に、 前記秘密鍵を用いて前記ライセンス を復号することにより、 前記ライセンスから前記コード暗号鍵を取得させ、 前 記喑号手段に、 前記コード暗号鍵を用いて前記保護プログラムを復号させる、 ことを含む処理を前記中央演算処理装置に実行させる、 ように構成する。
このプログラムは、 上記構成を有する中央演算装置によって行われる処理と 同様の作用 '効果を得ることができるものである。 従って、 このプログラムに よっても、 上記問題を解決する事ができる。 また、 上記プログラムを記録する 記録装置も、 上記プロダラムを上記中央演算装置によつて実行されることによ り、 上記構成を有する中央演算装置によって行われる処理と同様の作用 ·効果 を得ることができるものである。
また、 上記中央演算装置を構成する各手段によって行われる動作を手順とし て含むソフトウエア実行許諾方法も、 上記構成を有する中央演算装置によって 行われる処理と同様の作用 ·効果を得ることができるものである。
また、 本発明の更なる 1態様によれば、 コンピュータにおいて実行されるプ ログラムであって、 コード暗号鍵によって暗号化されたプログラムと、 前記保 護プログラムに対応して、 前記コード暗号鍵を含み、 且つ、 前記プログラムを 実行するべきコンピュータに備えられた中央演算装置が秘密裏に備える秘密鍵 と対になる公開鍵によつて暗号化されたライセンスが存在し、 前記ライセンス は、 前記プログラムが実行される前に前記中央演算装置に投入され、 前記中央 演算装置によって前記秘密鍵を用いて復号され、 前記プログラムは、 前記ライ センスから取得された前記コード暗号鍵を用いて、 前記中央演算装置によって 復号される、 ことを特徴とする。 このプログラムは、 上記中央演算装置によつ て保護されるソフトウエアであり、 上記中央演算処理装置を有するコンビユー タによって実行される事によって、 ハードウエア T RM並みの安全性を得るこ とができる。 また、 上記プログラムを記録する、 前記コンピュータによって読み取り可能 な記録媒体もまた、 その記録媒体からプログラムをロードし、 プログラムを上 記中央演算処理装置を有するコンピュータによって実行される事によって、 上 記プログラムと同様の作用■効果を得ることができる。
また、 本発明の更なる別の態様によれば、 上記構成を有する中央演算装置を 備えるコンピュータにおいて実行されるプログラムを生成するプログラム生成 装置であって、 コードオブジェクトを入力する入力手段と、 入力された前記コ ードォブジェクトを複数のブロックに分割し、 それぞれのブロックに N O P命 令を追加するリンカ前処理手段と、 アドレス解決を行うリンカ手段と、 コード 暗号鍵を用いて各プロックを暗号化することにより保護コード実行形式を生成 する保護コード実行形式生成手段と、 前記コード暗号鍵を含み、 前記秘密鍵と 対になる公開鍵によつて暗号化されたライセンスを生成するライセンス生成手 段とを備え、 前記ライセンスは、 前記コンピュータが前記保護コード実行形式 を実行する前に前記中央演算装置に投入され、 前記暗号手段によって前記秘密 鍵を用いて復号され、 前記保護コード実行形式は、 前記ライセンスから取得さ れた前記コード暗号鍵を用いて、 前記暗号手段によって復号される、 ことを特 ί敫とする。
このプログラム生成装置によって、 上記中央演算装置によって保護を受ける ことができない形式のコ一ドモジュールから、 上記中央演算装置によつて保護 を受けることが可能なプログラムを生成することが可能となる。 生成されたプ ログラムは、 上記中央演算処理装置を有するコンピュータによって実行される 事によって、 ハードウエア T RM並みの安全性を得ることができる。 図面の簡単な説明
図 1は、 基本パッケージソフトウエアの利用関係モデルを示す図である t 図 2は、 プログラミングモデル^示す図である。
図 3は、 第 1実施形態に係わる G Tを実現する C P Uの構成図である。
図 4は、 T R B内の各行のフィールドの構成を示す図である。
図 5は、 T L B内の各行の拡張フィールドの構成を示す図である。
図 6は、 FRアーキテクチャの場合について、 TLB内のフィールドの値と アクセス権限の対応を示す図である D
図 7は、 インテルアーキテクチャの場合について、 TLB内のフィールドの ' 値とアクセス権限の対応を示す図である。
図 8は、 暗号化キーテーブルの構造を示す図である。
図 9は、 署名方式の一例を示す図である。 .
図 10は、 TRB、 TLB, 暗号化キーテーブル及びページテーブルの関係 を示す図である。
図 1 1は、 TRS Sフラグを格納するフィールドの構成の一例を示す図であ る。
図 12は、 RACTの各行のフィールド構成の一例を示す図である。
図 1 3は、 RS S Lレジスタのフィールド構成の一例を示す図である。
図 14は、 一般の仮想セグメント空間と耐攻擊セグメント空間との間でコー ド実行プロセスからデータにアクセスする際のポリシーを示す図である。
図 1 5は、 GT 10上で保護プロセスが動作する様子を示す図である。
図 16は、 GTの認証を説明する図である。
図 1 7は、 GTライセンスに設定可能なアクセス権と被許諾権限を示す図で 図 18は、 上述の GT認証処理の一部を示すフローチャートである。
図 19は、 超流通ファイル形式として用いる場合の保護コード実行形式の一 例を示す図である。 図 2 0は、 保護コードのロードと実行手順、 及び保護データの退避と維持に ついて説明する図である。
図 2 1は、 保護コードを実行する際の保護コードを記録するページへのァク セス制御について説明する図である。
図 2 2は、 プロセッサコアによって行われる保護コード及び保護データへの アクセス制御を示すフローチャートである。
図 2 3は、 例外■割り込み処理にかかわるフローチャートである。
図 2 4は、 命令処理にかかわるフローチャートである。
図 2 5は、 保護コードファイルを起動する際における、 O Sカーネル 6 0及 び G Tの動作について説明する図である。
図 2 6は、 保護コードを実行するプロセスから保護データをアクセスするメ 力ニズムについて説明する図である。
図 2 7は、 親プロセスから他の保護コードモジュールを呼び出す際に行う手 順について説明する図である。
図 2 8は、 親プロセスから他の保護コードモジュールを呼び出す際に O S力 一ネルが行う処理のフローチャートを示す。
図 2 9は、 耐攻撃コード復帰例外処理による封印レジスタ不正アクセス防止 のためのシーケンス例を示す図である。
図 3 0は、 O Sカーネルによる保護コンテキスト切り替え時のシーケンスの 一例を示す図である。
図 3 1は、 保護データ領域の共有の一例を示す図である。
図 3 2は、 モジュールの認証、 並びに、 保護データ復号鍵共有手順の設定手 川貝について説明する図である。
図 3 3は、 耐攻撃領域共有システムコールを呼び出した際の処理を示すフロ 一チャートである π 図 34は、 DRMソフトウエアモジュールの構築モデルの一例を示す図であ る。
図 35は、 メディア DRMによって行われる処理を示すフローチャート （そ の 1) である。
図 36は、 メディア DRMによって行われる処理を示すフローチャート （そ の 2) である。
図 37は、 デコーダ DRMによって行われる処理を示すフローチャート （そ の 1) である。
図 38は、 デコーダ DRMによって行われる処理を示すフローチャート （そ の 2) である。
図 39は、 デコーダ DRMによって行われる処理を示すフローチャート （そ の 3) である。
図 40は、 再生アプリケーションによって行われる処理を示すフローチヤ一 トである。
図 41は、 秘密情報を維持■管理する方式を示す図である。
図 42は、 ライセンス管理のためのメモリアクセスの方式を示す図である。 図 43は、 第 2実施形態に係わる GTを実現する CPUの構成図である。 図 44は、 第 2実施形態におけるプロックの構造を示す図である。
図 45は、 ebimが 4である場合のブロックの構造を示す図である。
図 46は、 保護ブロックセレクタによって行われる処理を示すフローチヤ一 トである。
図 47は、 ハッシュエンジンによって行われる処理を示すフローチヤ一トで ある。
図 48は、 ハッシュチェッカによって行われる処理を示すフローチャートで ある。 図 49は、 NOPの処理について説明する図である。
図 50は、 マルチ CPUの構成図である。
図 51は、 コードォブジヱクトから保護コード実行形式を出力するツール群 の例を示す図である。
図 52は、 GTを、 パーソナルコンピュータ又はワークステーションに実装 した場合のシステム構成例を示す図である。 発明を実施するための最良の形態
本発明の実施形態について図面を参照しながら説明する。 なお、 同じ 装置等には同じ参照番号をつけ、 説明を省略する。
本発明は、 CPUに汎用 TRM機能を実装する事により、 CPUを、 汎用性 を有する攻擊対抗容器とする。 以下の説明において、 本発明に係わる汎用 TR M機能を実装する CPUを （"Generic TRM」 といい、 GTと略称する。
ぐ構成〉
GTの構成について説明する前に、 GTと、 その GTによって実行されるソ フトウェアの利用関係について説明する。 図 1に、 GTを実現する CPUパッ ケージとその C P Uパッケージによって実行される G T基本パッケージソフト ウェアの利用関係モデルを示す。
図 1に示すように、 GT基本パッケージソフトウェアは、 アプリケーション 層、 DRM層、 PK Iライブラリ層に分けることができる。 アプリケーション 層には、 保護されるアプリケーション （以下、 保護アプリケーションという） が含まれる。 DRM層には、 デコーダ DRM30及びメディア DRM40が含 まれる。 PKIライブラリ層には、 PK Iライブラリ 20が含まれる。 デコー ダ DRM 3 0、 メディア D RM40及び P K I ライブラリ 20は、 O S (Operation System) の一部である。 各基本ソフトゥヱァパッケージはそれぞれ次のような機能を持つ。 なお、 こ れらの機能は、 従来から知られているため説明は省略する。
PK Iライブラリ ：
-標準の PKIX (Public Key Infrastructure (X.509))ライブラリ
メディア DRM (Virtual Media DRM, Trusted Server DRMを含む） ：
• ライセンス生成 ·管理■削除 ·移動 ·複製の制御
■保護コンテンツ管理
- UDAC-MB/LB/PI認証 .ライセンス管理機能
- ライセンス変換機能： MB (Media Base) 、 PI (Protocol Independent) 、 GT間での変換など
デコーダ DRM：
■メディア DRMからのライセンス取得
■許諾ライセンス復号とコンテンツ復号鍵の維持
- コンテンツの復号、 汎用利用制御とアプリケーションへの安全な転送 ■利用制御機能拡張機能
図 1に示すように、 各 DRM30及び 40は、 ソフトウェアとして実現され、 ハードウェアとして実現されるのではない。 また、 GT 10は CPUとして実 現される。 GT 10 (CPU) は、 DRM30及び 40、 PK Iライブラリ 2 0及び保護アプリケーション 50を実行する。
図 2に、 図 1に示す基本パッケージ以外のモジュールを含めた GT上でのプ ログラミングモデルを示す。
図 2に示すように、 OSには、 上述の PK Iライブラリ 20、 デコーダ DR M30及びメディア DRM40に加えて、 OSカーネル 60及びデバイスドラ ィバ 70を備える。 デバイスドライバ 70は、 周辺ハードウェア 60を動作さ せるために必要なソフトウェアである。 保護アプリケーション 50及び保護されないアプリケーションを含む複数の アプリケーションは、 この OS上で動作する。 つまり、 GT 10上では、 DR M機能を用いた保護アプリケーションとともに、 従来の CPU上で稼動する他 のアプリケーションも稼動する。 このように、 GT 10は、 一般の保護の必要 がないアプリケーションを保護アプリケーションと同時に実行することが可能 な汎用性を有する耐攻擊容器である。
なお、 OSカーネル 60は、 従来の動作に加え、 GT 10において、 メモリ 管理及びコンテキストの切り替え制御の際に、 レジスタ封印等の GT 10に固 有の処理 （後述）を行う。 しかし、 それらの処理を〇 Sカーネル 60に行わせ ることは、 GT 10のセキュリティに影響を及ぼさない。 すなわち、 OSカー ネル 60にセキュリティホールが存在している場合であっても、 GT 10によ る保護の安全 1"生には影響はない。
デコーダ DRM30、 メディア DRM40及びこれらの D RMが用いる P K Iライブラリ 20内の暗号 '復号ライブラリ、 更には、 TRM化が必要なアブ リケーシヨンは、 GT 10上で保護される GT保護コードとして流通し、 実行 される必要がある。 そして、 これらのソフトウェアモジュールは、 ほぼ全文を 暗文にされる必要がある。
上述のように、 従来、 ソフトゥヱァ TRMには、 拡張性はあるが容易に破壊 できるという性質があった。 し力 し、 本発明によれば、 GT 10によって保護 される DRMソフトウェアモジュールを採用する事により、 DRMソフトゥェ ァモジュールにハードウエア TRM並みの強度を与える事を可能としている。 一方で、 ハードウェア TRMには拡張性が無く、 リソースも限られるという問 題があつたが、 GT 10によれば、 DRMソフトウェアを採用しているため、 機能的な拡張には、 GT 10を搭載する CPUに変更を加える必要は無く、 D RMソフトウエアのバージョンアップによって対応する事が可能である。 D RM構築モデルは、 UDAC— MB (Universal Distribution with Access Control-Media Base) U D A C _ L A、 UDAC- P Iそれぞれのァー キテクチャ及び仕様に従うこととしてもよレ、。
以下、 図 3を用いて、 第 1実施形態に係わる GTを実現する CPUの構成に ついて、 データのやり取りについて言及しながら説明する。
図 3に、 平文又は喑文のみからなるコードプロック或いはデータプロックを 想定した場合の （ebim=0， 1 のみをサポートする場合） 、 GT内部の回路ブロ ックの構成と回路プロック間のデータ交換モデルを示す。
GT 1 0は、 プロセッサコア 1 1、 命令キヤッシュ 1 2、 データキヤッシュ 1 3、 命令 MMU (Memory Management Unit) 14、 データ MMU 1 5、 暗号 エンジン 1 6を備え、 RAM (Random Access Memory) 1 7に接続されている。 本発明に係わる GT 10の特徴の 1つとして、 コードプロック又はデータブ ロックを暗号化したり、 復号したりする暗号エンジン 1 6を備え、 この暗号ェ ンジン 1 6を用いて暗号化されたコードブロックゃデータプロックを復号して から GT 10内部のキャッシュ 1 2又は 13に保持し、 データキャッシュ 1 2 から RAMI 7に作業データを出力する際には、 暗号エンジン 16を用いてそ のデータを暗号化してから出力することがある。 以下、 GT 10におけるブロ ック間のデータ交換について説明する。
まず、 RAMI 7から入力されたコードブロックは、 プロセッサコア 1 1及 び命令 MMU 14によって保護すべきコードブロック （以下、 保護コードプロ ックという） 又は平文コードブロックのいずれであるか識別される。 RAMI 7から入力されたデータブロックは、 プロセッサコア 1 1及びデータ MMU 1 5によって保護すべきデータブロック （以下、 保護データブロックという） 又 は平文データブロックの!/、ずれであるか識別される。
保護コ一ドブロック及び保護データブロックは喑号ェンジン 16に送信され るよう、 それぞれ命令 MMU 1 4及びデータ MMU 1 5から R AM 1 7に対し て保護ブロック転^先のアドレスの指定がされる。 暗号エンジン 1 6に出力さ れたコードブロックゃデータブロックは復号されて、 それぞれ命令キャッシュ 1 2やデータキャッシュ 1 3に出力される。 保護コードブロックを復号する際 に用いられる鍵 Kc及び保護データプロックを復号する際に用いられる鍵 Kdは、 プロセッサコア 1 1から喑号エンジン 1 6に出力される。 平文コードブロック 又は平文データブロックは、 そのまま、 それぞれ命令キャッシュ 1 4又はデー タキャッシュ 1 5に出力される。
また、 保護コードブロック及び保護データブロックの安全性を確保するため に、 G T 1 0によれば、 作業データをデータキャッシュ 1 3から R AM I 7に 出力する際に、 データキャッシュ 1 3の出口において作業データを暗号化する。 そのために、 まず、 データキャッシュ 1 3から作業データが暗号エンジン 1 6 に出力されるとともに、 プロセッサコア 1 1から作業データを暗号化するため の鍵 Kd (保護データブロックを復号する際に用いる鍵と同じ） が暗号エンジン 1 6に出力される。 暗号エンジン 1 6は、 その鍵 Kd を用いてその作業データ を暗号化し、 暗号化された作業データを R AM I 7等に設けられた仮想メモリ 領域に出力する。 さらに、 暗号化する際に、 データブロックに乱数を付加する こととしても良い。
なお、 データブロックを仮想メモリ領域に出力する際には、 そのデータプロ ックが保護されるべきデータブロックであるか否か、 T L B (Translation Look aside Buffer) (不図示、 後述） に基づいてプロセッサコア 1 1によつ て判断され、 判断結果に基づいて、 データキャッシュ機能からのアドレス指定 の際に暗号エンジン 1 6を通すかどうかが決定される。 また、 暗号化及び暗号 の復号に用いる鍵 Kc及び Kdは、 G T 1 0内の暗号エンジン 1 6が G Tライセ ンスを復号することによって得られ、 耐攻擊バッファ （以下、 T R B : Tamper Resistant Bufferという） （不図示、 後述） に格納されている。
命令 MMU 14とデータ MMU 1 5は、 図 3において、 別々のブロックとし て示されているが、 一つのモジュールにしてもよい。 命令キャッシュ 1 2とデ —タキヤッシュ 13についても同様である。
上記のように、 GT 1 0によれば、 キャッシュの出入り口で暗号化されたコ ードブロックやデータブロックをキャッシュ単位で復号する。 ところで、 CP
U内でコードを 1つずつ暗号化する場合、 2バイト程度の単位で行う必要があ る。 しカゝし、 十分な強度を得るためには現在の技術では 8バイト程度を暗号化 ブロックとすることが要求されるため、 2バイ ト程度の単位では十分な強度が 維持できない。 し力 し、 GT 10によれば、 RAMI 7からの暗号化されたコ 一ドプロックゃデータプロックを復号する際にはキャッシュ単位で復号して維 持する事により、 保護コードブロック及び保護データブロックを安全に守る事 が可能となる。
なお、 GT 1 0に命令キャッシュ 1 2が備えられない場合、 0丁 10内に1 AM領域を設け、 全ての実行コードを内部で復号して内部の RAM領域に保存 してから実行することとしてもよい。 これにより、 上記構成と同等の安全性を 確保する事ができる。 また、 GT 10にデータキャッシュ 1 3が備えられない 場合、 GT 10の内部に RAM領域を設け、 保護が必要な作業データを GT 1 0の内部の RAM領域に記録する。 これにより、 上記構成と同等の安全性を確 保する事ができる。
また、 従来、 CPU内の作業データを一時的に RAMに出力する際に、 秘密 にすべきデータが漏洩することがあった。 また、 そのデータの内容を監視する ことによって命令コードの推測を行うことによって、 C PU内に保持されてい る秘密鍵を推測することも可能であった。 しかし、 GT 10によれば、 データ キャッシュから作業データを RAMに出力する際に暗号化し、 キャッシュに復 活させる時にそのデータを復号する事としているため、 このような問題を回避 する事が可能となる。 .
なお、 キャッシュ 1 2及び 1 3と R AM I 7の間に、 平文のコードブロック 用のキャッシュライン、 平文のデータブロック用のキャッシュライン、 保護コ ードブロックを復号するためのキャッシュライン、 保護データブロックを喑号 化するためのキャッシュライン及び、 保護データブロックを復号するためのキ ャッシユラインのように、 複数のキャッシュライン並列に備える事としても良 い。 これにより、 G T 1 0による処理を高速化し、 保護コードブロック及び保 護データブロックの安全性を高めることが可能となる。
また、 図 3に示すように、 プロセッサコア 1 1内には、 レジスタが備えられ る。 G T 1 0によれば、 従来の仮想メモリ領域に、 耐攻撃領域という機構を 追加し、 この耐攻撃領域内では、 安全上のリスクが互いに影響することなく、 複数の保護ソフトウェアを実行する事を可能としている。 そのために、 プロセ ッサコア 1 1は、 耐攻擊セグメントセレクタ （以下、 T R S Sという） フラグ、 レジスタアクセスコントロールテーブル（以下、 R A C Tという） 及びレジス タ封印状態リストレジスタ (以下、 R S S Lレジスタという) を備える（不図 示） 。
T R S Sフラグは、 仮想メモリ領域内のセグメントを指定するセグメント指 定レジスタ内のフィールドに記録される。 プロセッサコア 1 1は、 T R S Sフ ラグに基づいて、 レジスタによって示される仮想アドレスが、 耐攻撃セグメン ト空間内であるのか、 一般の仮想セグメント空間内であるのかを判断する事が できる。 また、 複数の保護ソフトウェアを実行する際に、 現在実行中のプロセ ス以外のプロセスからレジスタにアクセスすることができないように、 プロセ ッサコア 1 1は、 R A C Tを用いて、 レジスタの封印及ぴ解放を制御する。 ま た、 さらに、 レジスタが封印されているの力解放されているのかを示す情報は、 R S S Lレジスタに登録される。 耐攻擊セグメント空間及び耐攻擊領域並びに レジスタの封印及び解放について詳しくは後述する。
このように、 GT 10は、 TRM化した 1ロッ トの C PUを用いて実現され る。 そして、 GT 10は、 GT 10上で動作する、 DRMソフトウェアモジュ —ル又はその他の保護を要するモジュールを TRM化することができる。 従つ て、 ハードウェア TRMを製造するコス ト、 特に初期ロッ トの開発コストを削 減する事が可能となる。
以下、 TRB、 TLB、 TRS Sレジスタ、 R A C T及び R S S Lレジスタ について順に説明する。
TRBは、 プログラムコード （インス トラクションの連結） を復号するため の鍵 Kc及びデータを暗号化 Z復号化する鍵 Kd等を保持する。 なお、 Kd及び
Kc を合わせてソフトウェア暗号鍵という事もある。 TRBは、 カーネルモード であってもユーザが内部を参照 -改ざんすることができない構造、 すなわち耐 攻撃構造をもつ。 TRB内で Kcや Kdを保持する位置の識別は Key IDによつ て行われ、 T LB内にもリンクした鍵の位置を識別する Key ID を持つ。 この
Key IDを用いて、 T R Bと T L Bをリンクさせる。
図 4に、 TRB内の各行のフィールドの構成表を示す。 図 4の表に示すよう に、 TRB内の各行は、 有効性フラグ p、 外部出力禁止フラグ uo、 キャッシュ ロックフラグ cl、 鍵識別情報 k id、 暗号鍵 key, 被許諾コード鍵 ackey及び例 外処理アドレス eadr 等のフィールドを含む。 また、 これらのフィールドのサ ィズは、 例としてあげたものであり、 GT 10のアーキテクチャや用途によつ て他の最適な値にすることが可能である。
有効性フラグ P は、 TRBが有効であるか無効であるかを示すフラグであり、 オン （1) である場合、 TRBが有効であることを示す。
外部出力禁止フラグ uoは、 その行の內容を暗号化キーテーブルに出力しても 良いか否かを示すフラグであり、 オン （1) である場合、 暗号化キーテーブル に出力されない。 但し、 この場合でも、 管理情報として必要な p、 uo、 cl及び kidは、 出力可能としてもよい。 外部出力禁止フラグ uoのデフォルト値は、 ォ フ （0) であり、 その場合はその行の内容は暗号化キーテーブルに出力される。 この場合、 TRB内の内容と暗号化キーテーブル内の内容とを同期させる必要 がある。 なお、 暗号化キーテーブルは、 GT 10内の TRBの内容を格納する 格納手段である。 暗号化キーテーブルについて詳しくは後述する。
キャッシュロックフラグ clは、 鍵識別情報 kidによつて指定された耐攻撃領 域内のデータがキャッシュの外に出力されるか否かを示し、 オン （1) である 場合、 そのデータ又はコードはキャッシュの外に出力されない。 なお、 clがォ ン（1)である場合、 次の 2つのモードを切り替える機能を更に GT 10に備え る事としても良い。
(a) CPU内蔵キャッシュまでし力 f呆護データを出さないモード
(b) 外部 （三次） キャッシュまで保護データを平文で記録するモード (a) は保護データを記録する領域を少なくし、 暗号 '復号処理をしないこ とで処理性能を上げる必要がある場合にも利用することができる。 （b) は処 理性能向上を期待できる力 保護強度のレベルは落ちることとなる。
鍵識別情報 k id は、 鍵を識別する情報であり、 TLBと TRBをリンクさせ るために用いられる。
暗号鍵 key は、 そのラインにリンクするページに書き込まれたコード又はデ ータを暗号化 ·復号するための暗号 ·復号鍵の値である。 暗号鍵は、 例えば、 对称鍵 （共通鍵） 暗号法の鍵である。 このフィールドに Kcや Kdが記録される。
被許諾コード鍵 ackey は、 リンクするページにアクセス可能な保護プロセ スの実行コードを復号するための復号鍵である。 ここで、 保護プロセスとは、 保護コードが実行された状態をいう。 その実行コードのページは、 TRB内の 行の鍵識別情報 kidと同じ kidを含む T L B中の行で、 ページ番号を用いて指 定され、 そのページへのアクセス権の種類も T L B中の行で指定される。 通常、 被許諾コード鍵 ackey は、 他の行及び自行の喑号鏈 key である。 ただし、 ackeyの全ビットが' 0' であれば、 すべてのプロセスが、 G Tライセンスを用 いてアクセス権を許諾されたことを示すものとする。 また、 ACgt. ackey (ACgt ' の ackeyフィールド（後述) の値） に ackeyを公開鍵 KPgt (後述） で暗号化さ れた値が入っている場合 （つまり、 ACgt. aef 力 S on の場合） には、 これを復号 した結果が TRB. ackeyに入る。
例外処理ァドレス eadrは、 keyが異なるページからこの T R B内の行にリン クしたページに復帰する直前に発生する例外処理コードの先頭ァドレスを示す。 例外処理ァドレス（eadr)は、 ACgt. eadr (ACgt内の eadrフィールドの値） が含 まれない AUTHORIZE命令により TRB内に行が設定された時点では、 デフォルト 値として全ビットに' 0'が設定される。 保護プロセスへの復帰時等に、 「耐攻 擊コード復帰例外アドレス不正例外」 が発生した際には、 そのプロセスの実行 を停止し、 当該 TRB の有効性フラグ (p)を off にしなければならない。 なお、 将来、 データページごとにアクセス例外を設ける必要がある場合には、 TRB. eadr (T R B内の eadr フィーノレドのィ直） は、 TRB. ackey (TRB 内の ackey フィールドの値） で暗号化されたコードの実行時に実行する例外処理コードの ァドレスとして定義することもできる。
鍵 key フィールドに格納されるコード復号鍵 Kc及びデータ暗号化■復号鍵 Kdは、 例えば、 乱数として生成する対称鍵暗号方式の暗号鍵であり、 G T 1 0 において、 暗号■復号の前と後でデータ長が同じになる暗号方式を選択するこ ととしてもよい。 鍵を乱数生成アルコリズムを用いて生成しても良いし、 G T 1 0内の熱乱数発生機能などを用いて生成してもよい。 前者の生成法より後者 の生成法の方が安全である場合が多い。 Kc及び Kdは、 後述の G Tライセンス に含まれる。 コード復号鍵 Kc又はデータ復号鍵 Kd と、 アクセス権等を埋め込 んだ G Tライセンスをパラメタとして C P Uインストラクション 「アクセス許 諾命令 （AUTHORIZE命令） 」 （後述） を実行する事により、 耐攻撃領域内の T L B (後述） にリンクされた T R B行内の各フィールドに値が設定される。
T L Bは、 保護コード及ぴ保護データを格納するアドレス並びにページへの アクセス権を管理する。 図 5に、 T L B内の各行の拡張フィールドの構成表を 示す。 図 5に示すように、 G T 1 0に係わる T L B内の各行は、 従来の T L B が持つフィールドに加え、 有効性フラグ p、 領域識別子 id、 物理ページ番号 ppn、 仮想ページ番号 vpn、 アクセス権限 rights、 鍵識別情報 kid、 暗号化プロ ック識別方式 ebim及びデジタル署名 sign等のフィールドを含む。 なお、 ァク セス権限 rightsフィールドは、 権限レベル Pl、 アクセス権 ar、 耐攻撃性フラ グ tr、 デバッグモードフラグ df に分けられる。 これらのすべてのフィ一ルド は G T 1 0内ではこの耐攻撃領域内になければならない。 また、 図 5において 示されたフィールドのサイズは、 例としてあげたものであり、 G T 1 0のァー キテクチャや用途によって他の最適な値にすることが可能である。
有効性フラグ pは、 T L Bが有効であることを示す。
領域識別子 idは、 T L B内の当該行が示すページ領域の識別子である。
物理ページ番号 ppnは、 物理ページ番号を示す。 仮想ページ番号 vpnは、 仮 想ページ番号を示す。
アクセス権限 rights は、 その当該行が示すページへのアクセス権限を示す。 権限レベル pi はページにアクセス可能な権限のレベルを示し、 アクセス権 ar は、 ページへのアクセス権の種類を示す。 権限レベル pi及びアクセス権 arは、 図 6及び図 7に示すようにして T L Bの各フィールドの値に基づいて決定され、 T L Bに設定される。 なお、 図 6は、 F Rアーキテクチャの場合を示し、 図 7 は、 インテルアーキテクチャの場合を示す。 耐攻擊性フラグ tr は、 当該行が示すページが耐攻擊セグメント空間内 （後 述） 内にあるか否かを示し、 耐攻擊性フラグ tr がオン （1 ) であれば、 その ぺージは耐攻撃セグメント空間内にあり、 その行に対応する行が T R B内にあ ることを示す。 耐攻撃性フラグのオン ·オフは G T 1 0の認証時に行われる。 デバッグモードフラグ df は、 デバッグモードが有効であるのか無効である のを示す。 デバッグモードフラグ df がオン （1 ) であれば、 有効である。 耐 攻撃性フラグ tr とデバッグモードフラグ df がオン （ 1 ) である場合、 ァクセ ス権 arで指定された値に応じたデバッグモ一ドが動作し、 各 arの値の意味は 以下のようになる。
(a) P Rの場合、 全プロセスから読み出しのみ可能： R
(b) Xの場合、 全プロセスからの読み出しと実行が可能： R X
(c) P RWの場合、 全プロセスからの読み出しと書き込みが可能： RW
(d) P WXの場合、 全プロセスからの読み睿きと実行が可能： RWX 鍵識別情報 kid は、 T R B内の鍵情報にリンクするために T R B内の行 (insertion) を識別する情報である。
暗号化ブロック識別方式 ebim は、 暗号化されているコードブロック又はデ 一タブロックを識別する情報である。
a ) ebitn= 0の場合、 ブロックは平文である。
b ) ebim= 1の場合、 ブロックは喑文である。 （デフォルト値であり、 ebim フィールドが省略されている場合、 ebim= 1として扱われる）
デジタノレ署名 signは、 上述の vpnから ebimまでのフィーノレドを連結したフ ィールド連結データのデジタル署名であり、 G T 1 0が生成する。
保護コ一ド及び保護データが格納される領域を示す T L Bインサーシヨン (行） 内ラインのアクセス権限の値は、 後述の TLB. tr がオフの場合に限り、 O Sが管理する。 従来通り、 本発明でもアクセス権限の値は 3ビット程度で表 現される力 本発明によれば、 さらにページが 「耐攻撃領域内にあることを示 すフィールドとして 「耐攻擊性フラグ tr」 フィールドを TLBに設ける。 また、 この耐攻擊領域を利用可能なコード実行状態を 「耐攻撃モード（Tamper Resistant Mode)」 と呼ぶものとする。
保護コードぉよび保護データを格納するアドレスはそのぺージを利用する前 に TLBに設定される。 アクセス権限 rights 及び暗号化ブロック識別方式 ebim、 被許諾コード鍵 ackey は、 G Tライセンスに含まれる G Tアクセス条件 ACgt (後述） に基づいて、 決定される。
コード復号鍵 Kc又はデータ暗号 ·復号鍵 Kdと、 アクセス権とを埋め込んだ GTライセンスをパラメタとして C PUインス トラクション 「アクセス許諾命 令」 （後述） を実行する事により、 TLB行内に、 保護ページごとに KeylDが 指定され、 各 KeylDに対応する TRB行内の keyフィールドに復号鍵が設定さ れる。
以下、 TRB及び TLBが格納される場所について説明する。
TRBは、 GT 10内に格納されるが、 GT 10に備えられた記憶容量がー 杯になる場合が想定される。 この場合、 GT 10内の TRBの内容の少なくと も一部を暗号化し、 暗号化された内容を RAMI 7やハードディスク等の外部 記憶装置に記録する。 この外部に記録された TRB内の行のリストを暗号化キ 一テーブルという。 そして、 GT 1 0は、 TRBの内容を暗号化した状態で外 部記憶装置内の喑号ィヒキーテーブルに記録しながら管理し、 必要な情報を暗号 化キーテーブルから取り出して GT 10内で復号して利用する。 TRBの内容 を暗号化したり復号したりする際に用いられる鍵 Ktrb は、 例えば、 対称鍵喑 号法の秘密鍵である。 この暗号鍵 Ktrb は、 GT 1 0の入力電源が落ちたり、 GT 10がリセットされたりした場合であっても、 継続して維持されることが 望ましい場合がある。 以下、 図 8を用いて暗号化キーテーブルの構造について説明する。 図 8に示 すように、 暗号化キーテーブルには、 有効性フラグ p、 外部出力禁止フラグ uo、 鍵識別情報 kid及び喑号化された TRBの内容を格納するフィールド等が含ま れる。
図 8に示すように、 暗号化キーテーブルに記録する際、 各行にヘッダとして 平文のままの TRB.p (TRB中の有効性フラグ p フィールドの値） と平文のま まの TRB. kid (TRB中の鍵識別情報 kid フィールドの値） を付加する。 これ により、 OS (スーパーバイザモード） によって暗号化キーテーブルを管理す ることが可能となるが、 Key ID以外の暗号化されている内容は参照も改ざんも できないこととなる。 TRB内のフィーノレドのうち、 p と kid とは平文の状態 で特定レジスタなどからみえてもよい。
TRBの内容を外部記録装置に記録する際には、 他の保護データプロックと 同様にデータキャッシュ 13の暗号化ラインを通して行う。 また、 図 8に示す ように、 TRBの各行を暗号化する際には行の先頭に乱数を付加してから暗号 ィ匕しなければならない。 これにより、 Kc (コードの喑号鍵） を指定したソフ ト ウェア開発者が故意に TRB中の暗号鍵 key フィールドの値を何度も入れなお して、 平文と喑文のペアを大量に生成することにより、 容易に TRBを暗号化 する暗号鍵 Ktrbを解読することを防止する。
さらに、 暗号化キーテーブルを RAMI 7から不図示のハードディスクに記 録しておき、 GT 10の再起動後に再利用することとしてもよい。 特にハード ウェア TRMレベルの強度をもつソフトウエア DRMを構築するために喑号鍵 Ktrb で暗号化されたままの Kd (データ暗号化鍵） をハードディスクやフラッ シュメモリなどに保存し管理する必要がある場合もあることから、 TRBの暗 号鍵 Ktrb は、 G T 1 0の電源切断後も耐攻撃領域内で F e R AM (Ferroelectric Random Access Memory) 等の不揮発性メモリなどに維持し続 けてもよい。
暗号化キーテーブルと T R Bの内容の同期方式にはつぎのような方式が考え られるが、 本 明がそのいずれかに限定されるものではない。
(a) 暗号化キーテーブルへの TRBの内容の書き出しと暗号化キーテープ ルから TRBへの再取り込みは特定のレジスタへの RW命令などを介して行う。
(b) 暗号化キーテーブルの先頭アドレスと行数を設定する （特別なインス トラクシヨンを実行する） ことにより、 必要になった際に GT 10が自動的に テーブルと TRBの同期をとる。 また、 ユーザが必要な時に同期がとれるよう にフラッシュインストラクシヨンを GT 10に実装する。
—方、 T LBの内容は、 一般の C PUと同様に GT 1 0でも、 外部記憶装置 にページテーブルとして記録し、' GT内の T LBの内容とページテーブルの内 容とは同期させて管理される。 そして、 GT 10は、 必要な情報を必要な時に ページテーブルから GT 10内に取り込んで利用することとしてもよい。
以下、 T LBとページテーブルの間での内容の受け渡しについて説明する。 T L Bの内容をページテーブルに記録させる際には、 TLB.tr (TLB内の tr フィールドの値） がオンの場合、 GT 10は、 TLB.sign (TLB内の署名 sign フィールドの値） を生成し、 記録させたい内容につける。 そして、 ページテー ブル内の内容を GT内の T L Bに取り込む際には、 GT 10は、 内容に付され ている署名を確認し、 署名が正しくなければ、 TLB署名不正例外 （後述） を 発生させ、 その行の有効性フラグ （TLB.p) と耐攻擊性フラグ （TLB.tr) を無 効 （オフ） にする。
図 9に署名方式の一例を示す。 図 9に示すように、 まず、 GT 1 0は、 TLB.vpn、 TLB. rights, TLB. kid及ぴ TLB. ebimを含むデータに GT 10内の固 定の乱数を連結する。 続いて、'連結されたデータを SHA-1 でハッシュし、 GT 10内の秘密鍵 Ktlbを用いて暗号化する。 これにより署名 TLB. signを生成す る。 署名を付す対象となる内容が 160 ビットに満たない場合、 例えば埋め草と しての乱数フィールドをその内容に追加する事としてもよい。
以下、 図 10を用いて、 TRB、 TLB、 暗号化キーテーブル及びページテ 一プルの関係について説明する。
図 10に示すように、 TRB及び TLBは、 GT 10内に保持される。 TR Bには、 鍵識別情報 kid、 コードブロックを復号する際に用いられる Kc及びデ 一タブロックを暗号ィヒ .復号する際に用いられる Kd等が記録される。 TLB には、 領域識別子 id、 鍵識別情報 kid、 仮想ページ番号 vpn、 物理ページ番号 ppn、 アクセス権限 rights等が格納される。 領域識別子 id は、 コードブロッ クゃデータブロックが格納されている RAMI 7内のページに対応する。 また、 T R Bと T L Bの内容は、 鍵識別情報 kidによって対応付けられている。
T R Bの内容を暗号化キーテーブルに記録する場合、 その内容に乱数を追加 してから暗号鍵 Ktrb を用いて暗号化する。 暗号化キーテーブルの内容を GT 10内に取り込む場合、 暗号鍵 Ktrb を用いてその内容を復号する。 一方、 T LBの内容をページテーブルに記録する場合、 GT 10は、 暗号鍵 Ktlb を用 いてその内容に基づく署名 TLB. signを生成し、 その内容に追加する。
続いて、 GT 10内のキャッシュと、 TLBと、 TRBとの同期について説 明する。 上記のように、 丁し：8ゃ丁1 8には、 ページに記録された保護コード や保護データへのアクセス制御に関する情報が記録されている。 そこで、 同じ 仮想アドレスをもつ 2つの TLBをハードウェアまたはソフトウエアで偽装す ることにより、 保護コード又は保護データにアクセスしょうとする攻撃が考え 得る。 このような攻撃に対処するため、 GT 10において、 プロセッサコア 1 1は、 キャッシュと T LBと TRBの内容の同期を取りながら、 アクセス制御 の判断を実施することとしてもよい。 より具体的には、 命令キャッシュ 1 2内 の保護コード又はデータキャッシュ 1 3内の保護データの内容は、 TLB行の 仮想ァ ド レス （TLB. vpn)だけでなく 、 その T L B行のデジタル署名 (TLB. sign) の値と仮想アドレスのペアにリンクすることとしてもよレ、。 この 場合、 プロセッサコア 1 1は、 このペアが不一致の際には異なるページとして アクセス制御の判断をおこなう。
このように、 GT ライセンスにアクセス許可保護コードのコード復号鍵 (Key) を被許諾コード鍵 (Authorized Code Key)として埋め込んでおくことで、 保護 領域にアクセス可能な保護コードを指定することができる。 そして、 T R Bの
Authorized Code Key フィーノレド（ackey)で指定された Keyをもつ仮想ページ上 のコードを実行したコードからのみ保護コ一ド及び保護データにアクセス可能 とする。 ただし、 アクセス権が Xまたは P WX のコードを実行する場合に限 り、 そのページの ackey の値がすべて 0であれば、 すべてのコードからの実行 を許諾するものとする。
ページ Aの ackeyとして指定された鍵に一致する keyの値をページ Bが持つ とき、 ページ B上の保護コードの実行状態をここではページ A (上のコード Z データ） の 「オーナープロセス（Owner Process)」 と呼ぶ。
なお、 G Tにおける実行権 （X) とは、 TRB. ackey (T R Bの ackeyフィール ド） に値を持つ耐攻撃ページ上の命令コードを実行する権利を意味する。 この 権利はその命令コードのひとつ手前で実行された命令コードに対して与えられ るもので、 つぎのようなケースがある。
( a ) ひとつ手前で実行された命令のあとに現在実行すべき命令とが続いて いる場合。
( b ) ひとつ手前で実行された命令が CALLや JUMPなどの分岐命令である場 合。
特に前の命令と次の命令の仮想ページが異なる場合、 G T 1 0は、 あらため て次に実行することを指定された命令コードが実行を許諾されているかどうか を確認しなければならない。 この確認、については後述する。
続いて TRS Sフラグについて説明する。 図 1 1に、 TRS Sフラグを格納 するフィールドの構成の一例を示す。 G T 10はその仮想メモリ空間のセグメ ント指定レジスタに、 TR S Sフラグを持つ。 このフラグはコード ·セグメン ト、 データ 'セグメント、 スタック 'セグメントのそれぞれに対して存在し、 それぞれ耐攻擊コードセグメントセレクタ（TRCSS: Tamper Resistant Code Segment Selector)、 耐攻撃データセグメ ン トセレクタ （TRDSS: Tamper Resistant Data Segment Selector)、 而す攻擊スタックセグメントセレクタ (TRSSS: Tamper Resistant Stack Segment Selector)と呼ぶ。 TR S Sフラグ がオンである場合、 ページは耐攻擊空間内に設定され、 オフである場合、 ぺー ジは一般の仮想空間内に設定される。
続いて、 RACTについて説明する。 図 12に、 RACTの各行のフィール ド構成の一例を示す。 GT 1 0によれば、 レジスタの封印と解放の機能を実現 するために、 耐攻擊モジュール内に R ACTを備える。 R ACTの各行は、 レ ジスタ I Drid、 封印フラグ seal及び被許諾コード鍵 ackey等のフィールドを 含む。
レジスタ I Drid は、 レジスタを指定する I Dである。 封印フラグ seal、 レ ジスタが封印中であるか否かを示し、 オン （1) である場合レジスタは封印中 であり、 オフ （0) である場合レジスタは解放されている事を示す。 非許諾コ ード鍵 ackeyは、 T R Bの ackey と同様であり、 レジスタへのアクセスが許可 されているプロセスのコードページの鍵 keyである。
続いて、 R S S Lレジスタについて説明する。 RS S Lレジスタは、 GTに 必須の機能ではないが、 オプション機能として備えることとしてもよい。 RS S Lレジスタは、 各レジスタの封印状態を示す情報を格納する。 図 13に RS S Lレジスタのフィールド構成の一例を示す。 図 13に示すように、 RS S L レジスタは封印可能なレジスタの数と同じビット長を有し、 各ビットは、 その ビットに対応するレジスタの封印状態を示す。 ビットがオン （1 ) である場合、 当該レジスタが封印されていることを示し、 オフ （0 ) である場合、 当該レジ スタが解放されていることを示す。 例えば、 R S S Lレジスタの第 1ビッ トが レジスタ r 1の封印状態を示すように設定されている場合に、 第 1ビットがォ ンであれば、 レジスタ r 1は封印されていることを意味する。
続いて、 耐攻撃セグメント空間及び耐攻撃領域について説明する。 上述のよ うに、 T L B内の耐攻擊性フラグ tr がオン （1 ) であるページは、 耐攻擊セ グメント空間内に含まれる耐攻撃領域である。 また、 このページに対応するセ グメント指定レジスタ内の行において、 T R S Sフラグはオンである。 耐攻擊 領域内のページには、 保護データが格納される。 図 1 4に、 一般の仮想セグメ ント空間と耐攻擊セグメント空間との間でコード実行プロセスからデータにァ クセスする際のポリシーを示す。 一般仮想セグメント空間は、 保護をする必要 がないデータ及びコードが記録される空間であり、 耐攻撃セグメント空間は保 護データ及び保護コードが記録される空間である。
耐攻撃セグメント空間で実行されるコードから一般仮想セグメント空間内 のデータにアクセスすることはできるが、 一般仮想セグメント空間で実行され るプロセスから耐攻撃セグメント空間内のデータにアクセスはできない。 また、 ユーザレベル空間とスーパーバイザレベル空間とのアクセス制御関係は、 耐攻 - 擊セグメント空間内でもライセンスオーナーが同じであれば、 一般仮 空間に おける場合と同じポリシーが維持される。
また、 耐攻撃空間内であっても、 ライセンスオーナーが異なる保護コード及 び保護データの領域間では、 相互にアクセスすることができない。 ただし、 後 述の耐攻撃領域共有機能を用いることで、 相互アクセスを可能にすることがで きる。 ' 上述のアクセスポリシーにより、 GT 10における保護プロセスは、 他のプ ロセスからの影響を受けない。 GT 10において、 保護プロセスは自身が生成 した耐攻撃ページを持ち、 一般に OSによって管理される。
図 15に、 GT 10上で保護プロセスが動作する様子を示す。 図 15に示す ように、 GT 1 0上では、 複数の保護プロセスが動作し、 それぞれの保護プロ セスは耐攻擊領域内にページを生成する。 作業データは、 GT 10内の暗号ェ ンジン 1 6によって暗号化されてから耐攻擊領域 （仮想メモリ領域） に格納さ れる。 従って、 仮想ハードウェア TRMの範囲は、 RAMI 7やハードデイス ク等までも伸び縮みし、 一定の形を持たないといえる。 このため、 GT 10が 生成し動作する保護プロセスは 「仮想ハードウェア TRM (Virtual Hardware Tamper Resistant Module ： VHTRM)」 内で動作しているということができる。 故に、 GT 10によれば、 ハードウェア TRM並みの強度を持ちつつも、 ハー ドウユア T RMに伴うリソースの制限という問題を解消することが可能となる。 また、 保護プロセスは、 世界中の CPU (GT 10) 空間を自在に移動する ことも可能である （後述の GR I D計算） 。 このように、 どのような攻撃にも 耐え、 自分の使命を果たして元の GT 10に帰ってくる VHTRMを纏った保 護プロセスを擬人化して 「耐攻撃エージェント（Tamper Resistant Agent)」 と 呼ぶこともできる。
<ィンストラクションセット〉
次に、 GT 10に与えられるインストラクションセットについて説明する。 まず、 GTを実装する CPUが、 従来の CPUのインストラクションセット に加えて、 GT 10としての機能を実現するために備える基本命令について説 明する。 基本命令には、 以下の （1) から （9) がある。 以下、 各命令につい て順に説明する。
( 1 ) G T証明書取り出し命令： Store GT certificate command 命令形式： STR_GT— CERT (certNum, certAdr)
入力レジスタ ：
certNum： GT 10内でローカルに割り当てられた証明書番号。 N枚の証明 書があれば、 0から N-1までの値が有効となる。
certAdr：証明書の内容を書き込むァドレス
出力 （例外処理） ：
errorCode：指定した番号の証明書がない場合などに設定される。
動作： certNum で指定された証明書を GT 10内から取り出し、 certAdr で 指定されたァドレスに書き出す。
動作可能権限：全レベル
(2) ,クセス百午fe命令： Access authorization command
命令形式： AUTHORIZE (licenseAdr, resultAdr, startVPN, numOfVP, kid) 入力レジスタ ：
licenseAdr : GTライセンス （後述） を格納したアドレス
resultAdr：結果を格納するァドレス
startVPN：耐攻撃領域の先頭仮想ページ番号
numOfVP：連続する耐攻撃領域のページ数
kid： OSが TLBと TRBの関係を管理するために割り当てる識別子 出力：
result： [GTライセンス || startVPN | | numOfVP] || 以上の署名] が resultAdrに記録される。
errorCode (例外処理） ：認証が失敗した場合などに設定される。
動作：指定レジスタのメモリ上にある GTライセンスを認証し、 GTライセ ンスから取り出した耐攻擊領域のコード又はデータ復号鍵 key (Kc又は Kd)、 kid、 ackey を耐攻撃領域内の TLBにリンクする TRBに設定する。 さらに、 T L Bに 「而ォ攻撃フラグ」 （tr)とアクセス権 （PR， X, PRW, PWX) 、 ebim、 kid 及び sign を設定する。 正しく設定が完了すれば、 入力データを連結してその デジタル署名を付加し、 resultAdr で指定されたアドレスに記録する。 このと き、 入力データの連結をハッシュし、 結果を Kgt を用いて暗号化し、 その結果 をデジタル署名として採用する。 認証が失敗した場合や T L Bが存在しない場 合など、 設定が失敗した場合には例外を発生させる。
動作可能権限：スーパーバイザレベル （権限レベル 0 ) のみ
( 3 ) 而敏擊権限設定命令： Set Tamper Resistant Rights command 命令形式： SET— TR— RIGHTS (rights, startVPN, nuraOfVP)
入力レジスタ ：
rights： アクセス権 （ACgt. ar (後述） を指定）
startVPN：耐攻擊領域の先頭仮想ページ番号
numOfVP：耐攻擊領域のページ数
出力 （例外処理） ：
errorCode：入力に対応する行が T L B又は T R Bにない場合、 又はすで に設定されているアクセス権よりも指定されたアクセス権の範囲が広い場合な どに発生。
動作： startVP及び NnumOfVPで指定された仮想領域が耐攻擊空間である場合、 その領域の T L Bに、 rights で指定されたアクセス権を設定する。 ただし、 rightsで指定されたアクセス権は、 すでに T L Bに設定されているアクセス権 の範囲でなければならない。
動作可能権限：スーパーバイザレベル （権限レベル 0 ) のみ
( 4 ) 耐攻撃例外ァ ドレス設定命令 ： Set Tamper Resistant Exception command
命令形式： SET— TR_EXCEPTI0N (startAdr) 入力 （イミ一ディエイトまたは直接アドレッシングのみ） ： startAdr： T R Bに設定する耐攻擊空間内の仮想ァドレス。 レジスタ解 除 -復帰例外などのジャンプ先として指定する。 なお、 封印したいレジスタの 使用前に startAdr を秘匿して実行する必要があることから、 レジスタは入力 パラメタとして利用できない。
出力 （例外処理） ：
errorCode： staetAdr で指定されたァドレスに対応する行が T R B内に存 在しない （耐攻搫モードではない） 。 又はそのアドレスへのアクセス権がない。 動作：指定された startAdr を現在実行中のコードページの T R B . eadr ( T R B内の eadrフィールド） に設定する。
動作可能権限：全レベル
( 5 ) レジスタ封印命令： Seal Register command
命令形式： SEAL_REG (registerList)
入力レジスタ ： registerList：封印するレジスタ一覧 （フラグリス ト） 。 各レジスタに対応したフラグについて、 オン （1 ) でレジスタを封印すること を示し、 オフ （0 ) で封印しないことを示す。
出力 （例外処理） ：
errorCode：指定したレジスタが存在しない。 または、 そのレジスタはす でに封印済である。
動作：指定したレジスタには、 本命令を出したプロセス （コード実行状態） コードページの暗号鍵 Kc と同じ鍵を持つコードページのプロセス以外からァ クセスできなくなる。 本命令の実行によって、 対応するレジスタの RACT. ackey (RACTの ackeyフィールド） に、 本命例を実行したコ一ドを暗号化した keyの 値を記録する。
動作可能権限：全レベル ( 6 ) レジスタ角放命令： Release Register command
命令形式： RELEASE_REG (registerList)
入力レジスタ ：
registerList：封印を解放するレジスタ一覧
出力 （例外処理） ：
errorCode：指定したレジスタが存在しない。 または、 そのレジスタは解 放済である。
動作：指定した範囲のレジスタの値をすベて 0にクリアし、 封印を解除する。 動作可能権限：全レベル
( 7 ) 非許諾領域スタックス トァ命令 ： Store Stack to Unauthorized
Area command
命令形式： STMEA— T0—UA (registerList)
入力：
registerList ： スタックに記録されるレジスタの一覧。 フラグのリスト。 各レジスタに対応したフラグがオン （1 ) の場合、 そのレジスタをスタックに 記録することを示し、 オフ （0 ) で記録しないことを示す。
出力 （例外処理） ：
errorCode： registerListでキ旨定されたレジスタが封印されていない。
動作：スタックポインタが、 許諾されていない耐攻擊領域を示す場合でも、 指定されたレジスタの RACT. ackey ( R A C T内の ackeyフィールド） の値がそ の領域に対応する T R B . ackey ( T R B内の ackey フィールド） に一致すれば、 指定されたレジスタがスタックポインタの位置に記録される。
動作可能権限：全レベル
( 8 ) 非許諾領域スタックロード命令： Load Stack from Unauthorized Area command 命令形式： LDMEA一 FR0M_UA (registerList)
入力：
registerList：スタックから読み出すレジスタ一覧
出力 （例外処理） ：
errorCode：指定レジスタが封印されている。
動作：スタックポインタが耐攻擊領域を示す場合、 指定されたレジスタの RACT. ackey にスタックポインタの領域の T R B . ackey のィ直がコピーされ、 指 定されたレジスタの RACT. seal (R A C T内の sealフィールド） がオン （1) に設定される。 さらに、 指定されたレジスタにスタックポインタの位置のデー タがロードされる。
動作可能権限：全レベル
(9) ライセンス削除命令： Delete License comranad
命令形式： DELETE_LICENSE(kid)
入力：
kid： OSが TLBと TRBの関係を管理するために割り当てた識別子で、
AUTHORIZE命令のパラメタとして用いた値。
出力 （例外処理） ：
errorCode： kidが誤っている場合、 又は削除に失敗した場合等に設定され る。
動作：指定された kid の TRB及びそれにリンクするすべての TLBが削除 され、 対応するページテーブルと暗号化キーテーブルの有効性フラグもオフに 設定される。 また、 それらの TLBが示していた仮想領域のキャッシュロック も解除される。
動作可能権限：スーパーバイザレベル （権限 0レベル） のみ
上述の （1) から （9) までの基本命令に加えて、 性能や機能の向上のため の拡張命令として、 （1 0 ) から （1 5 ) までの命令等が考えられる。 以下、 順に拡張命令について説明する。
( 1 0 ) 保護プロック開始命令： Protected Block Start command 命令形式： PRT_BL0CK— START (encryption_f lag)
入力 （直接パラメタ） ：
encryption_flag： オン （ 1 ) ならブロックが暗号化されていることを示 す。
動作：
命令データの特定のビット位置が特定パターンにセットされていれば暗号 化ブロック開始命令とする。 本命令内の特定ビット列 （7ビット程度） は喑 号化ブロックの長さを指定するために用いられ、 値を指定する単位は、 キヤ ッシュ可能なインストラクシヨン長の最小値と同じとする。 また指定可能な 最大値はキヤッシュ可能な長さの最大値と同じとする。 本命令のその他のバ ィトには乱数を入れなければならない。 本命令データの先頭の境界は命令キ ャッシュ単位の境界に一致しなければならない。
乱数の長さがセキュリティ上十分でない場合は、 この命令を 2つ以上連続 する。 連続した場合、 最後の本命令以外はブロック長の値に 0が入る。
保護コードブロック開始命令は、 G T 1 0内で復号された後、 同じ長さの Nop命令となる。
TLB. ebimの第 2ビットがオンの場合、 プロックに含まれるハッシュまたは 署名 （平文の場合） をチェックしなければならない。 ハッシュまたは署名の 位置は、 例えばブロックの末尾とする。 ブロックがハッシュや署名を含まな い場合は、 ハッシュ非実装例外を発生させる。
なお、 この命令は、 第 2実施形態 （後述） に対応する。
( 1 1 ) T R B暗号鍵リフレツシュ命令： Refresh TRB Key command 命令形式： REFRESH— TRB一 KEY
入出力レジスタ ： なし
動作： TRBを外部に記録する際にはかならず用いる対称暗号法の喑号鍵 Ktrb とページテーブルの署名確認に用いる暗号鍵 Ktlb を新たな乱数値に置き 換える。
この命令は、 Ktlbや Ktrb が漏洩する可能性がある場合などに使用する。 た だし、 TRBを用いてライセンス情報などを暗号化して管理していた場合、 こ の命令後は以前の暗号化情報を復号できなくなるので、 注意が必要。 このよう な場合には例えば、 リフレッシュの前に別の鍵で暗号化して退避しておくなど の処理が必要になる。 利用例の詳細は後述。
(12) 保護領域のキャッシュを優先する命令：
保護データの暗号 ·復号速度を重視する場合に利用する。
(1 3) プロセス間で漏洩しな！/、熱乱数生成命令：
(14) 内蔵暗号'復号コマンド
GT 10を実現のために C PU内部に実装した対称鍵喑号法や公開鍵暗号法 の暗号化■復号命令をインストラクシヨンセットとしてソフトウェア開発者に 見せることにより、 ハードゥエァリソース利用効率が高まる。
(15) 定期割り込み間隔設定コマンド
GT内蔵水晶発信機が発生する内部割込みの間隔を設定する。 外部の信頼で きる時計と安全に同期するセキュアクロックを耐攻撃プロセスとして実現する 場合に用いることができる。
<例外処理 >
GT 10を実現する CPUは、 従来の例外処理に加え、 次のような例外処理 を実装する。 例外処理には、 大きく分けて、 耐攻擊ページアクセス権関連例外 と、 耐攻撃領域復帰関連例外と、 レジスタ封印関連例外と、 ハッシュ関連例外 等とがある。 以下、 順に各例外処理について説明する。
•耐攻擊耐攻擊ページアクセス権関連例外
(1) 証明書指定誤り
この例外処理は指定した番号あるいは識別情報の GT 証明書 （Cgt) がない場 合に発生する。
(2) GTライセンス認証フォールト
この例外処理は G Tライセンスの認証に失敗した場合に発生する。
(3) 耐攻擊空間ページフォールト
TLB内の耐攻撃性フラグ trがオフ （耐攻撃モードではない） または、 その ページに対応する行が T R B内に無いのに耐攻擊領域へのアクセス命令を実行 しょうとした。
(4) TLB署名不一致例外
TLB. sign (TLB内の signフィールド） の値が、 ブロックに含まれる署名と 一致しない。 本例外が発生した場合、 GT 10は自動的に当該 TLBのページ テーブルからのロードを停止する。 さらに、 T L B内の対応する行の有効性フ ラグ （TLB.p) 及び耐攻撃性フラグ （TLB.tr) をオフにする。
(5) アクセス権不正拡大例外
AUTHORIZE命令で許可されたアクセス権よりも指定されたアクセス権の範囲が 広い。 本例外が発生した場合、 GT 10は自動的にアクセス権設定命令を拒否 する。
(6) 暗号化キーテーブルアクセスフォールト
この例外は、 TRB中に存在しない kidその他の検索キーを指定した場合、 又は TRBのページァゥトに失敗した場合に発生する。
(7) ライセンス削除フォールト
この例外は、 ライセンスの削除に失敗した場合に発生する。 -耐攻擊領域復帰関連例外
( 8 ) 耐攻擊コード復帰例外
： RETURN一 TO— TAMPER— RESISTANT一 CODE— EXCEPTION
call, jump又は return によって、 一般の仮想領域又は耐攻擊領域からコー ド復号鍵 Kc が異なる耐攻擊領域に実行中アドレスが移動した際には、 必ず耐 攻撃コード復帰例外が発生する。 この例外の処理において、 移動先耐攻擊領域 の例外アドレスである TRB. eadr ( T R B内の eadr フィールド） の内容が確認 され、 そのフィールドに例外アドレスが存在する場合、 プロセッサコアは、 そ の例外アドレスにアクセスする。 例外アドレスが存在しない場合には、 当該 T R B行が削除され、 耐攻擊コード復帰例外ァドレス不正例外が発生する。
( 9 ) 耐攻擊コ一ド復帰例外ァドレス不正例外
この例外は、 耐攻擊コード復帰例外アドレスで指定された空間が、 耐攻擊空 間に存在しない場合に発生する。 保護プロセスへの復帰時等に本例外が発生し た際には、 そのァドレスに対応する T R B内の行の有効性フラグ（p)をオフに し、 〇Sなどによって指定されたアドレスへ強制的にジャンプする。
- レジスタ封印関連例外
( 1 0 ) レジスタ封印済例外
この例外は、 指定されたレジスタが既に同じ Kcを持つコードにより封印済み である場合に発生する。
( 1 1 ) レジスタ解放済例外
この例外は、 指定レジスタが封印されていない場合に発生する。
( 1 2 ) 封印レジスタアクセスフォールト
： SEALED— REGISTER— ACCESS_FAULT_EXCEPTION
この例外は、 指定されたレジスタが既に Kc が異なる他のコードによって封 印済みである場合に発生する。 -ハッシュ関連例外
(1 3) ハッシュ非実装例外
この例外は、 GT 10がハッシュ生成機能やチェック機能を実装していない 場合に発生する。
( 14 ) ハツシュ不一致例外
この例外は、 &丁 10カ 保護コード又は保護データをキャッシュする際に ハッシュ値の不一致が生じた場合に発生する。
<動作>
以下、 GT 10によって行われる処理について説明する。
<GTの認証〉
まず、 GT 10の認証手順について説明する。 なお、 以下の説明において、 PK Iの内容の理解を前提としている。
図 16に、 GTの認証を説明する図を示す。 図 1 6に示すように、 GTの認 証には、 保護アプリケーション 50、 DRM30及び 40、 暗号モジュール (PK Iライブラリ 20に含まれる) の各ソフトウェアパッケージを作成する 各開発メーカー、 GT 10を作成する開発メーカー、 PK Iライブラリモジュ ール用認証局 CApki、 DRM用認証局 CAdrm、 D RMを利用するアプリケーシ ョン向け認証局 CAap及び GTを認証する認証局 CAgtが介在する。 図 16にお いて、 細い矢印は、 データの流れを示し、 太い矢印は、 ソフトゥ アパッケ一 ジへのライセンス又は証明書の埋め込みを示す。 また、 図 1 6中の括弧中の数 字は処理の順番を示す。 また、 各 TRMソフトウェアは、 各 TRMソフトゥェ ァ開発メーカーが秘密裏に生成した対称鍵暗号方式の暗号鍵で暗号化されてい るものとする。
GTライセンスの生成と利用は次のような各システム運用とプログラムソフ トウエア実行許諾手順によって実現される。 (1) GTメーカーは製品化する GT 10の個別公開鍵 KPgt を GT専用の 認証局 CAgt に渡す。 さらに、 GTメーカーは、 GT 10内部には秘密鍵 Kgt を埋め込む。
( 2 ) G T専用の認証局 CAgtは、 G T 10の公開鍵証明書 Cgtを G Tメー カーに発行する。 なお、 GT 10の公開鍵証明書 Cgt は、 クラス秘密鍵 Kcgt で署名され、 クラス公開鍵 KPcgt は、 GT専用の認証局 CAgt のルート秘密鍵 Kagtで署名された証明書の形で公開されていることとしてもよい。 また、 公開 鍵証明書 Cgt において個別鍵とクラス鍵の双方を用いるのではなく、 いずれか 一方を用いることとしてもよい。 クラス鍵がない場合、 公開鍵証明書 Cgt はル ート秘密鍵 Kagtで直接に署名されることとしてもよい。
(3) GTメーカーは、 公開鍵証明書 Cgt をコピーし、 TRMソフトウェア 開発メーカーに配布する。
(4) 各 TRMソフトウェアの開発メーカーは、 開発したソフトウェア実行 コードを鍵 Kc を用いて暗号化することにより、 保護コードファイルを作成す る。
(5) 各 TRMソフトウェアの開発メーカーは、 公開証明書 Cgt から取り出 した G T 10の公開鍵 KPgtを用いて鍵 Kcを暗号化し、 （移動不可能な） G T ライセンス Lxxを生成する。 GTライセンスの構造については後述する。
(6) 各 TRMソフトウェアメーカーは、 ソフトウェアが実行される前に〇 Sのイニシエータ一が GTライセンス Lxx を GT 10に投入するように、 GT ライセンス Lxxをそのソフトウエアパッケージに埋め込む。
(7) 各ソフトウエアの実行直前にその GTライセンスが GT 10に投入 される。 GT 10は、 公開鍵のペアにあたる秘密鍵 Kgt を用いて、 GTライセ ンスを復号する。 つまり、 GT 10内で各ソフトウェア開発メーカーによる G T 10の認証が実行される。 これにより、 GT 10上でそのソフトウェアを実 行することが許諾される。 GTで保護されるソフトウエアをフリーソフトゥェ ァ等にして流通させたい場合には、 GTライセンスを生成するためにクラス公 開鍵 KPcgt を用いる事としてもよレ、。 また、 GTで保護されるソフトウェアを 特定の GT 10以外で使用できないようにしたい場合は、 GTライセンスを生 成するために個別公開鍵 KPgtを用いる事としてもよい。
(8) GT 1 0は、 GTライセンスから取り出した鍵 Kc とアクセス権 (Access rights) を GT 10内の T R B及び T L Bに設定する。 ユーザは、 たとえカーネルモード （スーパーバイザレベル/リング 0) でも、 TRBに設 定された Kcを参照することはできない。
このように、 TRMソフトウェアパッケージには、 GT 10に実行許諾を与 えるための GTライセンスが埋め込まれ、 暗号化されたプログラムコードが実 行される前にその G Tライセンスは、 GT 10に投入される。 GT 10は、 個 別秘密鍵 Kgt を用いて GTライセンスを復号し、 その GTライセンスからプロ グラムコードの復号鍵 Kc を取り出し、 内部の TLBにリンクした TRBに、 保護コードごとにその復号鍵 Kc を維持する。 GT 10において、 暗号ィ匕され たコードは復号鍵 Kcを用いて復号されながら実行される。
PK Iライブラリモジュール用認証局 CApki、 DRM用認証局 CAdrm と DR Mを利用するアプリケーション向け認証局 CAap から構成される TRMソフト ウェアパッケージ向け認証局は、 各パッケージのソフトウエアプロセスが保護 データを交換する際にデータ転送先パッケージを認証するために利用する証明 書を発行する。 また、 これらのうち DRM用認証局はライセンス転送先 DRM の認証に用いられることしてもよい。
ここで示した 4種類の認証局はすべて異なる運用にすることでコンテンッ (情報） 流通ビジネスのリスクが軽減することが可能となるが、 そうした運用 は必須ではない。 なお、 PK Iライブラリ 20、 デコーダ DRM30及びメデ ィァ D RM 4 0を含めて 1つの O Sとして評価し、 この O S製品全体に対して G Tライセンスを生成し、 また公開鍵証明書を発行することとしてもよい。 また、 G Tライセンスを保護実行コードと同じファイルに挿入することとし てもよいが、 パッケージ超流通の便を考慮すると、 暗号化された実行コードと 別のファイルとして管理することを推奨する。
次に、 G Tライセンスの構造について説明する。
ライセンス生成側はライセンス許諾先 G T (耐攻撃容器） の個別公開鍵 KPgt の証明書 Cgt を取得し、 これを用いて G Tライセンスを生成する。 証明書 Cgt は X. 509準拠の形式としてもよい。 個別公開鍵 KPgtの証明書 Cgtはクラス鍵 KPcgtで、 また、 クラス鍵 KPcgtの証明書 Ccgtは認証局 CAgtのルート公開鍵 KPagtで署名チェックした後、 利用される。 ライセンス生成側が生成する GTラ ィセンスの形式は以下のとおりである。
LicenselD | | ACgt. ar | |
E (KPgt, Ks ) I I E ( Ks, Key I I LicenselD ACgt I ] Is )
CgtID I I CgtlDackey | | else
-こで、 各フィールドの意味は次のとおりである。
E (K, D) ：データ Dを鍵 Kで暗号化した結果
A I I B：データ連結。 データ Aとデータ Bが連結していることを示す。 Ks :セッション鍵 ほ L数） 。 対称鍵 （共通鍵） 暗号法の鍵。
Key： コード復号鍵 Zデータ暗号化■復号鍵。 Kc/Kd。
LicenselD： ライセンスシリアル番号。 ライセンス生成側がライセンスご とにユニークな番号を生成する。 上位にライセンス生成者の ID を入 れ、 中位にコンテンツの IDを入れることとしてもよい。 ACgt : G Tアクセス条件。 G T内で強制可能なコード/データの利用条件 を示し、 次のフィールドを持つ。
ebira：暗号化プロック識別方式。 図 5に示す TLB. ebim フィールドにコ ピーされる。 各値の意味は T L Bのフィールドとして説明済みである。 aef ：被許諾コード鍵喑号化フラグ（ackey encryption flag)。 on (l)な ら被許諾コード鍵 ackeyが個別公開鍵 KPgtを用いて暗号化されて いることを示し、 off (0)なら ackey の値がそのまま ACgt. ackey (ACgtの ackeyフィールド） に入っていることを示す。
ackey：被許諾コード鍵。 暗号鍵 Kc又は Kdで復号されたォブジェクト にアクセスが可能なプロセスのコードが記録されている保護ページ の暗号鍵 keyまたは喑号鍵 keyを個別公開鍵 KPgtで暗号化した値。 個別公開鍵 KPgt で暗号鍵 key を暗号化する場合で、 GT が複数の KPgtを持つ場合には、 さらにどの KPgtを用いているかを識別でき る情報を付加する。 なお、 そのプロセスへのアクセス権の種類は、 arで指定される。
eadr :例外処理アドレス。 このフィールドはオプションである。 keyが異 なるページからこの G Tライセンスの内容が設定されたぺ一ジに復 帰する直前に発生する例外処理コ一ドの先頭ァドレスである。
ar :基本アクセス権。 次のような値をとる。 詳細は図 1 7に示す。
(a) PR： ackeyで指定されたプロセスからの読み出しのみ可能
(b) X： ackeyで指定されたプロセスからの読み出しと実行が可能
(c) PRW： ackey で指定されたプロセスからの読み出しと書き込み が可能
(d) PWX： ackey で指定されたプロセスからの読み書きと実行が可 能 uo：外部出力禁止フラグ。 on (1)ならこのライセンスのキー情報を格納 した T R B行は暗号化キーテーブルに出力（ページァゥト） されな レ、。 このフラグのデフォルトはオフ（0)であり、 外部に出力可能で あることを示す。
cl：キャッシュロックフラグ。 ォプション機能である。 このフラグが才 ンである場合、 この G Tライセンスで保護を指定された耐攻撃領域 のデータはキャッシュの外に出ない。 伹し、 ar が書き込み権を含 まない （PR 又は X である） 場合には、 本フラグは無効となる。 こ のフラグのデフォルト値は、 オフであり、 外部に出力可能である事 を示す。
df ：デバッグモードフラグ（Debug mode Flag)。 df 力 S on なら、 ar の指 定に応じた動作を示す。 T L Bについての説明参照。 なお、 G Tラ ィセンス内の ACgtの df をオンにする事により、 保護コードをデバ ッグモードで実行する事ができる。 また、 超流通など形態で保護コ ードファイルを販売する場合には、 df をオフにして販売すること としてもよい。
CgtID： KPgtの X. 509証明書の識別子値。 issuer と serialNumberを連結 した値。
CgtlDackey：ォプション。 ackeyを暗号化した KPgtの X. 509証明書の識別 子値。 issuerと serialNumberを連結した値。 ACgt. aefが off の場合 には省略。 また、 CgtIDと同値の場合にも省略可能。
Is：その他の情報
図 1 7に、 G Tライセンスに設定可能なアクセス権と被許諾権限の表を示す。 耐攻撃性フラグ耐攻撃モードの際、 プロセス （コード実行状態） からみた保護 データ又は保護コード領域のアクセス権は、 図 1 7の中から選択され、 T L B に設定される。 なお、 図 1 7における 「指定コード」 とは、 当該 TRB行内の Key フィールド又は Ackey フィールドで指定された鍵で復号可能なコードをい 。
また、 図 17において、 「実行のみ可能」 な権限がないが、 FRなど、 「実 行のみ可能」 な権限と 「読み出しと実行が可能」 な権限の両方を指定できる C PUもある。 その場合の耐攻撃権限は、 それぞれ、 P X及び PR Xと表現する 事ができる。 同様に、 「書き込みが可能」 な権限についても PWX及び PRW Xの両方が指定できることとしても良い。
GTライセンスは、 移動不可を条件としているため、 移動機能や CR L (Certificates Revocation List：証明書失効リスト） 及び LRL (License Revocation List： ライセンス失効リス ト） をもたない。 CRLや LRLを制 御する必要がないため、 GTの C PUへの実装が容易になる。 DRMの CRL 制御及び LRL制御は OS又はアプリケーションにて行われる。 これにより、 高レ、拡張性を維持する事が可能となる。
また、 上述のように、 ソフトウェア TRMをフリーソフトウェア等にしたい 場合、 GTライセンスの生成にはクラス公開鍵を用いることとしても良い。 ま た、 逆に、 特定の GTのみにソフトウェアを利用させたい場合には、 GT個別 鍵に対応する公開鍵を用いることとしても良レ、。
以下、 図 18を用いて、 上述の GT認証処理における （8) の手順について 詳しく説明する。 GT認証処理において、 GT 1 0は、 アクセス許諾命令 (AHTH0RIZE命令） を実行することにより、 G Tライセンスに基づいて T L B 及び T R Bに鍵 Keyやアクセス権等を設定する。
そのために、 まず、 GT 10は、 GTの公開鍵のペアにあたる秘密鍵 Kgt を 用いて GTライセンスを復号する （S 1) 。 続いて、 GT 10は、 正常に GT ライセンスを復号できたか否か判定し （S 2) 、 正常に復号できた場合 （S 2:正常） 、 GT 10は、 指定仮想領域の TLBを検索する （S 3) 。 正常に 復号できなかった場合（S 2 ：異常） 、 GT 10は、 GTライセンス認証フォ 一ルトを発生し （S 1 1) 、 S 1 6に進む。 S 1 6において、 GT 10は、 ェ ラー内容を resultAdrに設定し、 メインフローに復帰する。
S 3において TLBを検索した結果、 指定仮想領域が得られた場合 （S4 ： 正常） 、 GT 10は TRBに空きがあるか否か判定する （S 5) 。 S 3の検索 の 果、 指定仮想領域が得られなかった場合 （S 4 ：なし） 、 GT 10は、 メ モリが割り当てられていない旨を示す未割り当て例外を発生し （S 12) 、 S 16に進む。
S 5において TRBの空きがあった場合 （S 5 ：あり） 、 GT 10は、 GTラ ィセンスに基づいて、 TRB内の uo、 cl、 kid、 key, ackey の各フィーノレドに 値を設定する （S 6) 。 S 5において、 TRBの空きが無かった場合 （S 5 ： なし） 、 GT 10は、 TRB内の一部の行を暗号化キーテーブルに出力 （ぺー ジアウト） する （S 1 3) 。 GT 10は、 ページァゥトに成功した場合 （S 1 4 ：成功） S 6に進み、 ページァゥトに失敗した場合 （S 14 ：失敗） 、 暗号 化キーテーブルアクセスフオールトを発生させた後 (S 1 5) 、 S 16に進む。
S 6の後、 GT 10は、 TLBに格納する署名 sign を算出し （S 7) 、 ar、（ tr、 df、 kid、 ebim及び signを T LBに設定する （S 8) 。 続いて、 GT10 は、 設定結果の署名を生成し （S 9) 、 設定結果と S 9で生成した署名とを resultAdrに設定し （S 10) 、 メインフローに復帰する。
<保護コードファイルの構造〉
以下、 保護コードファイルの構造について説明する。 暗号化がほどこされた 保護コードファイル (実行形式） は、 保護コードブロックおよび平文コードブ ロックの繰り返し構造の先頭にヘッダを付カ卩した構造を持つ。 また、 保護コー ドファイルを超流通に利用可能なファイルとする場合、 そのファイルのヘッダ には、 さらに次のような情報が入る必要がある。
' コンテンツ I D ：保護コードの暗号を解くためのコンテンツ復号鍵を持つ G Tライセンスとのリンク情報として必要である。
■ コンテンツ暗号方式：保護コードの暗号化方式を特定する値として必要で ある。 この値は復号鍵の長さを含むこととしてもよい。
図 1 9に、 超流通ファイル形式として用いる場合の保護コード実行形式の一 例を示す。 図 1 9において、 S C D F (超流通コンテンツ形式： Super Content Distribution Format) フアイノレに、 保護コード実 开式の内容が、 S C D Fの要素として格納されている。
く保護コードのロード及び実行並びに保護データの退避と維持 >
以下、 図 2 0を用いて、 保護コードのロードと実行手順、 及び保護データの 退避と維持について説明する。
上述のように、 暗号化が施された保護コードファイルは、 ヘッダ、 保護コー ドブロック及び平文コードブロックで構成される。 保護コードファイルは実行 の際に R AM I 7にロードされ、 G T 1 0 ( C P U) 内での予測に従いブロッ クごとに命令キャッシュ 1 2にコピーされる。 このうち、 ヒットした命令のみ がプロセッサコア 1 1で解釈され、 実行される。 図 2 0に示すように、 コード ブロックのうち、 保護コードブロックは、 復号キャッシュラインで復号されて から命令キャッシュ 1 2に記録される。
図 2 0では、 命令キャッシュ 1 2と R AM I 7の間に、 暗号ブロックを復号 して命令キャッシュ 1 2に書き込む復号キャッシュライン及び、 平文ブロック を命令キヤッシュ 1 2に書き込む平文キヤッシユラインの 2種のキヤッシユラ インが備えられている。 このように複数のキャッシュラインを備えることによ り、 処理を高速ィ匕することが可能である。
また、 図 2 0に示したように、 保護コードの実行によって保護データを R A Ml 7に出力する際には、 あらかじめ仮想メモリとして設定された耐攻擊領域 に出力する。 耐攻擊領域には、 保護データを暗号化および復号するための対称 鍵暗号法の鍵 Kdが関連付けられ、 その鍵 Kdは秘密裏に GT 10内に維持され ている。 鍵 Kdは、 コード復号鍵 Kcごとに異なる乱数として割り当てられる。 保護データは一旦 GT 10 (CPU) 内部のデータキャッシュ 13に記録され たのち、 暗号化されてから RAMI 7に出力される。 また、 RAMI 7上の保 護データは、 GT 10 (CPU) 内部で復号されてデータキャッシュ 1 3に記 録され、 そのうちヒットしたものがプロセッサコア 1 1で利用される。
図 20では、 データキヤッシュ 1 3と RAM 1 7の間に、 暗号プロックを復 号して命令キャッシュ 12に書き込む復号キャッシュライン、 データキヤッシ ュ 1 3の内容を暗号化して RAMI 7·内の耐攻搫領域に書き込む暗号キヤッシ ユライン、 及び、 平文プロックを命令キャッシュ 12に書き込む平文キヤッシ ユラインの 3種のキヤッシュラインが備えられている。 この構成によっても処 理を高速化することが可能である。
なお、 暗号化された保護データを RAMI 7力、らストレージ 18内に退避さ せることが可能である。 つまり、 耐攻撃領域は RAMI 7内のみならず、 バス 1 8を介して接続されたストレージ 1 9内にまでも拡張することが可能である。 くページアクセス制御 >
以上のようにして、 GT 10は、 TRMプログラムコードを実行する許諾を 得て、 その保護コードファイルを構成するコードブロックを RAMI 7にロー ドすると、 保護コードブロックを復号して実行する。 以下、 保護コードを実行 する際の保護コードを記録するページ （命令ページ又はコードページ） へのァ クセス制御について図 21を用いて説明する。 図 21において、 矢印は、 デー タの流れを示し、 括弧内の数字は、 処理の順番を示し、 以下の説明における手 順の番号に対応する。 保護コードを記録するページへのアクセス制御は次のように行われる。
( 1 ) 命令 MMU 14が、 予測命令ポィンタ（ip: instruction pointer)に 記憶されている仮想ァドレスを読み出す。
(2) 命令 MMU14は、 仮想アドレスに対応する物理ページ番号 ppn と耐 攻撃フラグ tr と耐攻撃モードのアクセス権 arを T LBから読み取る。
(3) 耐攻擊フラグが on の場合、 命令 MMU 14は、 TRBからコード復 号鍵 (Kc)を取り出す。
(4) 命令 MMU14は、 暗号エンジン 16に Kcを設定する。
(5) 命令 MMU14は、 キャッシュすべき保護コードブロックのアドレス を命令キャッシュ 12と RAMI 7に指定する。
(6) RAMI 7から保護コードブロックを暗号エンジン 16に投入する。
(7) 喑号エンジン 16で復号された保護コードブロックは、 命令キヤッシ ュ 1 2に記録される。
( 8 ) 命令ボインタが記憶する仮想ァドレスが予測命令ボインタに一致した 場合 （つまりキャッシュヒットした場合） 、 プロセッサコア 1 1は ip 用レジ スタから TRS Sフラグを読み出し、 次の手順に進む。 一方、 キャッシュヒッ トしなかった場合、 上述の（2)の手順に戻る。
(9) プロセッサコア 1 1は、 ip用レジスタから仮 アドレスを読み出す。
( 10) プロセッサコア 1 1は、 命令 MMU 14からアクセス権 ar を取り 出し、 アクセス権を確認する。
(11) プロセッサコア 1 1は、 仮想アドレスの内容が記録された命令キヤ ッシュ 12内から保護コードブロックを読み出して実行する。
なお、 手順 （1 0) において、 実行する命令を記録する命令ページが切り替 わった時には、 プロセッサコア 1 1は、 手順 （1 1) で保護コードブロックの 読み出しを行う前に、 以下を確認する。 (a) 次に実行する保護コードプロックが記録されているページの暗号鍵 (TRB. key)または被許諾コード鍵 （TRB. ackey)が、 直前に実行したコードブロ ックが記録されているぺージの喑号鍵 (TRB. key)と一致すること
(b) 次に実行する保護コードブロックについての TLB.ar に記録されたァ クセス条件と、 次に実行するアクセスとが合致すること
(a) 及ぴ （b) の少なくともいずれかが不一致の場合には、 プロセッサコ ァ 1 1は命令の実行を停止し、 アクセス権例外を発生させる。
次に、 保護データブロックが記録されているぺージへのアクセス制御につい て説明する。 保護データプロックへのアクセス制御は、 GTライセンスの内容 が TRB及ぴ TLBに設定されることによって強制される。 保護データブロックへ のアクセスは TRB及び TLBに維持されている被許諾コード鍵 ackey、 暗号 ·復 号鍵 Kd、 アクセス権 arに従って制御される。
上述の保護コードブロックの場合のアクセス制御手順と、 実行中の保護プロ セスによる保護データブロックへのアクセス制御手順は、 同様である。 また、 上記の手順 （1 0) において、 実行する命令を記録するページが切り替わった とき、 及ぴアクセスされる保護データを記録するぺージが切り替わったときに は、 保護データへのアクセスを実行する前に、 プロセッサコア 1 1は、 次の点 を確認する。
(a) アクセスされる保護データを記録するぺージの暗号鍵 (TRB. key)また は被許諾コード鍵 （TRB. ackey)が実行コードを記録するページの暗号鍵
(TRB. key)と一致すること
(b) アクセスされる保護データを記録するページのアクセス権 （TLB.ar) と、 次に実行するアクセスとが合致すること
(a) 及び （b) の少なくともいずれかが不一致の場合には、 プロセッサコ ァ 1 1は、 保護データへのアクセスを中止し、 アクセス権例外を発生させる。 以下、 図 22を用いてプロセッサコア 1 1によって行われる上述の保護コー ド及ぴ保護データへのアクセス制御について、 より詳しく説明する。
まず、 プロセッサコア 1 1は、 例外 Z割り込みイベントの発生を待つ (S 2 1) 。 例外/割り込みイベントが発生すると、 プロセッサコア 1 1は、 例外 - 割り込み処理を行い （S 35) 、 S 21に戻る。 なお、 例外■割り込み処理に ついて詳しくは図 23に示す。 図 23に示される各種例外処理については、 上 記 <例外処理 >において詳しく説明したため、 説明を省略する。
例外/割り込みイベントが発生しない場合 （S 21 ：なし） 、 プロセッサコ ァ 1 1は、 命令ページ切り替えが発生したか否か判定する （S 22) 。
命令ページ切り替えが発生した場合 (S 22 ：あり） 、 プロセッサコア 1 1 は、 命令ページへのアクセス権の有無を判断する処理を行う （S 23) 。 命令 ページ切り替えが発生していない場合 （S 22 ：なし） 、 S 28に進む。
S 23の判断処理において、 プロセッサコア 1 1は、 次に実行する保護コー ドブロックが記録されているページの暗号鍵 (TRB. key)または被許諾コード鍵 (TRB.ackey)が、 直前に実行したコードブロックが記録されているページの暗 号鍵 (TRB. key)と一致し、 且つ、 次に実行する保護コードブロックについての TLB. arに記録されたアクセス条件によつて次に実行するアクセスが許可されて いるか否か判定する。 上記 2つの条件を満たす場合、 プロセッサコア 1 1は、 次に実行するコードには、 切り替わった命令ページへのアクセス権があると判 断し （S 24 :あり） 、 S 25に進む。 そうでない場合 （ S 24 ：なし） 、 プ 口セッサコア 1 1は、 ページアクセスフォールト例外をキューイングし （S 2 7) 、 S 21に戻る。
S 25において、 プロセッサコア 1 1は、 次に実行する保護コードブロック が記録されているページの暗号鍵 (TRB. key)が、 直前に実行したコードブロッ クが記録されているページの暗号鍵（TRB. key)と一致するか否か判定し、 さら に、 プロセッサコア 1 1は、 そのページに対応する TR B内の行の eadr フィ 一ルドに既に値が設定されているか否か判定する。 TRB.key がー致せず、 且つ eadrフィールドに既に値が設定されている場合 （S 25 ： YES) 、 プロセッ サコア 1 1は、 耐攻撃コード復帰例外をキューイングし （S 26) 、 S 21に 戻る。 TRB.keyがー致するか、 又は eadrフィールドに値が設定されていない場 合'（S 25 ： NO) 、 S 28に進む。
S 28において、 プロセッサコア 1 1は、 命令ページから命令を読み出して、 その命令を解析する。 さらに、 プロセッサコア 1 1は、 現在実行されているコ 一ドが、 命令の中で指定されたレジスタへのアクセス権を有するか否か確認す る （S 29) 。 そのコードが指定されたレジスタへのアクセス権を有する場合 (S 29 :あり） 、 S 30に進む。 そのコードが指定されたレジスタへのァク セス権を有しない場合 （S 29 ：なし） 、 プロセッサコア 1 1は、 封印レジス タアクセスフォールト例外をキューイングし （S 34) 、 S 21に戻る。
S 30において、 プロセッサコア 11は、 レジスタで示されたデ一タぺージ 力 前のデータページと切り替わっているか否か判定する。 切り替わつていな い場合 （S 30 ：なし） 、 命令を実行し （S 33) 、 S 21にもどる。 なお、 -命令実行処理について詳しくは図 24に示す。 図 24に示される命令について は、 上記くインス トラクションセット〉において詳しく説明したため、 説明を 省略する。
データページが切り替わっていると判定した場合 (S 30 ：あり） 、 プロセ ッサコア 1 1は、 そのデータページへのアクセス権の有無を判断する処理を行 う （S 31 ) 。 S 31の処理は、 S 23で説明した保護コードの場合と同様で あるので説明を省略する。 S 31の判断の結果、 プロセッサコア 1 1は、 次に 実行されるコードには、 切り替わったデータページへのアクセス権があると判 断する場合 （S 3 2 ： あり） 、 S 33に進む。 そうでない場合 （ S 32 ：な し） 、 S 27に進む。
<保護ソフトウェアの起動 >
次に、 図 25を用いて、 GT 10上で保護されるソフトウェア、 つまり保護 コードファイルを起動する際における、 〇 Sカーネル 60及び GT 10の動作 について説明する。 図 25において、 細い矢印がデータのリンクを示し、 太い 矢印がデータの流れを示す。 また、 括弧内の数字は、 処理の順番を示し、 以下 の説明における手順の番号に対応する。
保護コードフアイルを起動する手順は、 以下のとおりである。
(1) OSカーネル 60は、 TLBを設定することにより、 保護コード及ぴ 保護データをロードする領域となる仮想メモリ領域及び物理メモリ領域を確保 し、 仮想メモリと物理メモリ領域とをリンクさせる。
(2) OSカーネル 60力 らの AUTHORIZE命令に基づいて GT10は、 TL Bにリンクする TRBを設定する。
(3) 〇Sカーネル 60からの CALL などのコードモジュール呼び出し命令 に基づいて、 GT10は、 ip レジスタを設定する （呼び出し先インストラクシ ヨンにヒットしない場合、 GT 10は該当するコードブロックを復号し、 復号 されたコ一ドをキャッシュにコピーする) 。
(4) GT 1 0は、 ip で指定されたアドレスの命令を実行する権利を TLB. ar (T L B内の arフィールド） の内容で確認する。 .
(5) 命令を実行する権利を確認できた場合、 GT 10は、 ipで指定された アドレスの命令 （図では STR命令） を読み出し、 デコードし、 実行する。
く保護データへのアクセス〉
次に、 図 26を用いて、 GT保護コードを実行するプロセスから保護データ にアクセスするメカニズムについて説明する。 この例では、 保護データ領域は 保護コード実行前に確保され、 保護コードファイルから初期値もロードされて いることを前提としている。 また、 O S 6 0からの AUTHORIZE命令を GT 1 0 が実行する事により、 保護データ領域へのアクセス許諾とアクセス権設定は、 既に行われているものとする。
以下、 例として、 命令" STR r0， [rl]〃を実行する （レジスタ r Oの値が示す 内容をレジスタ r 1の値が示すァドレスに書き込む命令） 場合について、 保護 プロセスが保護データにアクセスする手順と、 それに対応する GT 1 0の動作 について説明する。 図 2 6において、 矢印や括弧内の数字の意味は、 図 2 5と 同様である。
( 1) 保護コードは、 メモリアクセス命令 (STRや LDRなど）を実行する。 (2) GT 1 0は、 アクセスするアドレスに対応する TL B内の行中のァク セス権情報 TLB. ar (T L B内の arフィールド） を確認する。
(3) 保護コードは、 TLB.vpn (TL B内の vpn フィールド） に一致する仮 想ページ番号を持つページのデータにアクセスする。 （なお、 データがキヤッ シュにない場合、 保護コードは、 その仮想ページに対応する物理ページからデ 一タを復号してキャッシュにコピーする。 ）
<保護プロセスからの保護モジュールの呼び出し >
次に、 保護プロセスから保護モジュールを呼び出す手順について説明する。 保護プロセスから他の保護コードモジュール （D L L (Dynamic Link Library) など） を起動する場合には、 次の 2ケースがある。
(a) 呼び出される保護コードモジュールのコード復号鍵 Kc 、 そのモジ ユールを呼び出す保護プロセス （以下、 親プロセスという） のコード復号鍵と 同じケース
(b) 呼び出される保護コードモジュールのコード復号鍵 KG が親プロセス のコード復号鍵と異なるケース
(b) の場合に、 保護親プロセスから他の保護コードモジュールを呼び出す 際に行う手順は図 27に示すようになる。 図 27においても、 矢印や括弧内の 数字の内容は、 図 25と同様である。 なお、 図 27において、 保護コードモジ ュールは DLLとなっているが、 これは一例に過ぎない。
(1) 親プロセスは、 TLBの設定などにより、 保護コードモジュールを口 ードするための仮想領域と、 その仮想領域に対応する物理領域を確保する。
(2) 親プロセスは、 アクセス許諾 （AUTHORIZE) 命令により TLBにリン クする TRBを生成してコード復号鍵 Kc を設定し、 TLBにアクセス条件を
HXAh f" 。
(3) 親プロセスは、 利用している秘密情報用レジスタを、 その親プロセス の保護データ領域内のスタック領域に格納する。 （必要に応じ、 保護データキ ャッシュ内のスタックデータは暗号ィヒされて外部メモリに記録される。 ）
(4) 親プロセスは、 レジスタ解放 （RELEASE_REG)命令を実行する。
(5) CALL命令などにより、 親プロセスは、 保護コードモジュールを呼び出 す。
(6) 親プロセスは、 レジスタ封印（SEAL_REG)命令を実行する。
(7) 呼び出しが返った場合、 親プロセスは、 退避したスタックをもとのレ ジスタに復帰させる。
図 28に、 上記手順において O Sカーネルが行う処理のフローチャートを示 す。
図 27の手順の （1) において親プロセスが、 保護コードモジュールをロー ドするための仮想領域と、 その仮想領域に対応する物理領域を確保することを 要求すると、 耐攻撃領域取得システムコールが呼び出される。 この要求の際、 親プロセスは、 必要となる領域のサイズと、 GTライセンスを O Sカーネル 6 0に通知する。 このシステムコールにおいて、 まず、 OSカーネル 60は、 ァ プリケーシヨンが利用しているレジスタの一覧を入力パラメタとする非許諾領 域スタックストア （STMEA— T0_UA) 命令をプロセッサコア 1 1に出力する （S 91) 。 この S 91は、 図 27の手順 （ 3 ) に対応する。
続いて、 OSカーネル 60は、 アプリケーションが利用しているレジスタの 一覧を入力パラメタとするレジスタ解放 （RELEASE一 REG) 命令をプロセッサコ ァ 1 1に出力する （S 92) 。 これにより、 指定されたレジスタが解放される。 この S 93は、 図 27の手順 （4) に対応する。
O Sカーネノレ 60は、 O Sが利用しているレジスタの一覧を入力パラメタと するレジスタ封印 （SEAL_REG) 命令をプロセッサコア 1 1に出力する （S 9 3) 。 S 94において、 これら命令のパラメタが正しい場合 （S 94 :正常） 、 これらの命令はプロセッサコア 1 1によって実行され、 S 95に進む。 そうで ない場合 （S 94 ：不正） 、 S 103に進む。
S 95において、 OSカーネル 60は、 親プロセッサによって指定された領 域サイズのエントリをページテーブルに設定する （S 95) 。 指定されたサイ ズの領域を設定するための耐攻擊領域のリソースがあった場合 （S 96 ： ぁ り） 、 S 97に進む。 耐攻擊領域のリソースが不足していた場合 （S 96 ：不 足） 、 S 103に進む。
S 97において、 OSカーネル 60は、 GTライセンスと、 設定したァドレ ス及びページ領域を入力レジスタに設定し、 アクセス許諾 （AUTHORIZE) 命令 をプロセッサコア 1 1に出力する。 この S 97は、 図 27の手順 （2) に対応 する。 プロセッサコア 1 1力 正常に命令を実行した場合 （S 99 :正常） 、 S 100に進む。 正常に命令を実行できなかった場合 （S 9 9 ：例外発生） 、 S 103に進む。
S 100において、 OSカーネル 60はアクセス許諾 （AUTHORIZE) 命令の 結果を返却データとして設定する。 この後、 図 27の手順 （5) が行われ、 保 護コードモジュールが呼び出される。 続いて、 OSカーネル 60は、 レジスタ 解放 （RELEASE_REG) 命令をプロセッサコア 1 1に出力し、 O Sが使用してい るレジスタを解放させる （S 1 0 1 ) 。 最後に、 O Sカーネル 6 0は、 被許諾 領域スタックロード （LDMEA_FR0M_UA) 命令をプ口セッサコア 1 1に出力し、 スタックされていたデータをレジスタにロードさせ、 通常状態に復帰する。 こ の S 9 5は、 図 2 7の手順 （ 7 ) に対応する。
なお、 パラメタの不正、 リソースの不足及び例外が発生した場合、 S 1 0 3 において、 O Sカーネル 6 0はエラー内容を返却データとして設定し、 S 1 0 1に進む。
<耐攻擊コ一ドの復帰時の例外処理 >
call, jump又は return等の命令によって、 一般の仮想領域又は耐攻擊領域 からコード復号鍵 Kc が異なる耐攻撃領域に実行中アドレスが移動した際には、 耐攻撃コード復帰例外が発生する。 この例外処理の中で、 次の 2つの処理を実 施する必要がある。
( a ) レジスタ封印の確認と、 レジスタを解放済みの場合の封印の再設定。 ( b ) 耐攻撃セグメントセレクタの値の確認と、 必要に応じた再設定。
G T 1 0は、 保護コードのレジスタ封印の前に、 解除■復帰例外の先頭ァド レスを T R Bに設定する。 また、 外部からの割り込みによってレジスタが解放 されたまま実行を継続することによって、 レジスタに記録した秘密情報が漏洩 することがないよう、 保護コードは解除 ·復帰例外処理を含む必要がある。 こ の解除.復帰例外処理において、 G T 1 0は、 封印したはずのレジスタが封印 されているかを再度確認し、 レジスタが封印されていなければ、 封印しなおす 力 \ 保護コードの実行を中止するかしなければならない。
図 2 9に、 耐攻撃コード復帰例外処理による封印レジスタ不正アクセス防止 のためのシーケンス例を示す。 図 2 9において、 保護コードが不正なコードに よって一時中断された後に復帰する際に、 例外が発生した場合を示す。 図 2 9 において、 保護コードを中断する前にレジスタ封印 （SEAL— REG rl) 命令が実 行されているが、 不正コードの実行中にレジスタ解放 （RELEASE一 REG rl) 命令 が実行されたため、 復帰時に封印したはずのレジスタが封印されていない。
図 2 9に示す耐攻擊コード復帰例外のシーケンスの最初の 3行は以下のとお りである。
TST RSSL. rlss, rlssBit
BNE chk— seg
SEAL一 REG rl
この 3行は、 保護コードが利用するレジスタ r 1の封印状態を R S S Lレジ スタ内のレジスタ r 1に対応するビット rlss の値を調べる事により確認し、 r 1が封印されていない場合、 r 1を封印しなおす処理を示す。
また、 不正なコードが割り込み等によってプロセスを奪い、 データゃスタツ クの T R S Sフラグをオフ （0 ) に設定する可能性もある。 T R S Sフラグが オフになっているにもかかわらず保護コ一ドが継続されると、 耐攻撃領域では なく一般仮想領域に保護データを書き込んでしまうことになる。 このような事 態を防止するために、 耐攻擊コード復帰例外処理において、 ip (命令ポインタ、 C P Uによっては PC (プログラムカウンタ） ともいう） が示す仮 アドレスご との耐攻撃データ Zスタックセグメントセレクタの再設定を行う必要がある。 図 2 9に示す耐攻擊コ一ド復帰例外のシーケンスにおける 4行目から 6行目は 以下のとおりである。
ch_seg CMP ip, trSegmentHead
BMI ret
ORR trdss, trdss, trBit
この 3行が、 ipが示す仮想ァドレスごとの耐攻撃データ スタックセグメン トセレクタの再設定を行う処理を示す。 耐攻撃コード復帰例外処理が終了する と、 プロセスは保護コードに復帰する。 なお、 図 2 9のシーケンスの最後にお いて、 不正なコードによって再度プロセスが中断され、 不正なコードが保護コ 一ドが利用するレジスタ r 1の内容を一般仮想領域に書き込もうとしている (MOV rl， [unprotectedArea] ) 。 しかし、 耐攻擊コード復帰例外処理におい て、 レジスタ r 1は封印しなおされているため、 封印レジスタアクセスフォー ルト （SEALED_REGISTER— ACCESS— FAULT_EXCEPTION) が発生している。
このように、 耐攻擊コード復帰例外のシーケンスによって、 G T 1 0は、 復 帰時に保護コードの秘密データを守っている。
<保護コンテキストの切り替えの管理 >
以下、 耐攻擊ユーザプロセスから O Sカーネルプロセスへのコンテキス ト切 り替えがおこり、 全レジスタがスタックに退避されるケースを想定する。 図 3 〇に、 O Sカーネルによる保護コンテキスト切り替え時のシーケンスの一例を 示す。
図 3 0において、 アプリケーション 1からァプロケーション 2に保護コンテ キストを切り替えると仮定している。 当初、 アプリケーション 1が利用するレ ジスタ r 1は、 封印されている。 その後、 保護コンテキストを切り替える際に、 O S力一ネル 6 0は、 非許諾領域スタックス トア （STMEA_T0— UA) 命令を実行 することにより、 レジスタ r 1の値はデータ暗号 ·復号鍵 Kd で暗号化されて から退避される。 さらに、 スタックされたレジスタ r 1は、 レジスタ解放 (RELEASE_REG) 命令により 0クリアされる。 レジスタ r 1が解放されること により、 アプリケーション 2のプロセスがレジスタ r 1を利用することが可能 になる。
その後、 保護コンテキストが元のプロセスにもどる際に、 O Sカーネル 6 0 は非許諾領域スタックロード （LDMEA— FROM— UA) 命令を実行することにより、 退避されていたレジスタの値が復号されて、 レジスタ r 1に戻される。 その後、 レジスタ r 1は再度封印される。 コンテキスト切り替えの際に、 このような保 護コンテキスト管理によって、 封印レジスタを含めたレジスタの維持、 復帰を 保障することは O Sカーネル 6 0の処理として位置付けられる。
なお、 O Sカーネル 6 0が非保護システムコールを呼び出す際は、 SPを一般 仮想空間のアドレスに切り替えてから呼び出すなどの工夫が必要である。 O S は従来通り、 システムコールの戻り値を一般仮想領域に記録すればよい。
一方、 O Sカーネル 6 0が保護システムコールを呼び出す際には、 戻り値を 格納するスタック領域を共有するための G Tライセンスをパラメタなどとして 渡す。 O Sは受け取った G Tライセンスをパラメタとして AUTHORIZE コマンド を実行することで、 耐攻擊スタック領域をアプリケーションプロセスと共有す ることができる。
<保護データ領域の安全な共有〉
上記において、 耐攻撃空間内のプロセス同士であっても、 ライセンスオーナ 一が異なるコード及びデータの領域間では、 相互にアクセスすることができな いと説明した。 しかし、 以下の耐攻撃領域共有機能を用いることで、 G T 1◦ で保護され、 互いに異なるコード復号鍵 Kc を持つソフトウェアパッケージ、 ライブラリ、 オブジェクト及びプロセス等の保護コードモジュール間で、 保護 データを安全に交換できるようにすることができる。
図 3 1に保護データ領域の共有の一例を示す。 図 3 1は、 G T 1 0上でプレ ーャプロセス及ぴデコーダ D RMプロセスが動作している場合を説明する図で ある。
デコーダ D RMプロセスによってデコードされたデータは、 D RMプロセス 用の仮想ページに書き込まれる。 このデコードされたデータは、 データ喑号鍵 Kdを用いて暗号化された後、 R AM I 7内の共有物理ページに記録される。 R AM I 7の共有物理ページに記録されたデータはデータ復号鍵 Kd を用いて復 号されて、 D RMプロセス用の仮想ページに書き込まれる。 プレーヤ （再生ァ プリケーション） プロセスはそのデータを読み出して再生する。
以下、 このような保護データの共有を設定する手順について詳しく説明する。 まず、 保護データを共有するために、 共有されることになる保護データ領域 を生成した生成元モジュールとその保護データ領域を生成元モジュールと共有 する共有先モジュールを想定する。
生成元モジュールと共有先モジュールとがパッケージとして異なっている (すなわち Kc が異なる） にもかかわらず、 共有先モジュールが生成元モジュ ールの保護データ領域を読み出すことができるようにするためには、 図 3？に 示すようにして、 生成元モジュールは共有先モジュールを認証しなければなら ない。 その認証が正常に完了できた上で、 G T 1 0内部において、 生成元モジ ユールの保護データ領域の暗号鍵 Kd を共有先モジュールが利用できるように T L Bおよび T R Bが設定されなければならない。
以下、 図 3 2に沿って、 モジュールの認証、 並びに、 保護データ復号鍵共有 手順の設定手順について説明する。 図 3 2において、 括弧内の数字は、 処理の 順番を示し、 以下の説明における手順の番号に対応する。 また、 図 3 2中の各 記号の意味は次のとおりである。
RN：生成元モジュールが一時的に生成した乱数
KPacra： ソフトゥヱァモジュール向け認証局のルート公開鍵
Kacm： ソフトウエアモジュール向け認証局のルート秘密鍵
Kdp：共有先モジュールの秘密鍵
KPdp：共有先モジュールの公開鍵
C (KPdp, Kacm) ：共有先パッケージの公開鍵証明書
Kcl :生成元モジュールのコード復号鍵
Kc2 :共有先モジュールのコード復号鍵 ( 1) 生成元モジュールが共有先モジュールに一時的に生成した乱数を渡す。
(2) 共有先モジュールが、 自身のプロセスが生成した仮想領域の I Dと Kc2を KPgtで暗号化した値と乱数とを連結したデータに、 そのデータのデジタ ル署名と署名に用いた秘密鍵に対応する公開鍵の証明書とを付加する。 この証 明書は PKI ライブラリ用認証局（CApki)、 DRM用認証局（CAdrm)あるいはアプリ ケージョン向け認証局（CAap)などの信頼できる第三者が発行したものでなけれ ばならない。 なお、 この説明では、 証明書には、 復号鍵 Kc="YYYYYY"が KPgtで 暗号化されているとする。
(3) 共有先モジュールは、 （2) で生成したデータを、 生成元モジュール に一般のデータ共有/プロセス間通信などを利用して渡す。
(4) 生成元モジュールは、 署名をチェックし、 その正当性を確認できた場 合、 受け付けた被許諾コード鍵 Authorized Code Key とアクセス権' PR' (耐 攻撃モードで読み出し専用） と暗号 '復号鍵 Kd を埋め込んだ GTライセンス と指定仮想領域をパラメタとして、 アクセス許諾命令 (AUTHORIZE)を実行する。 なお、 この説明では、 暗号■復号鍵 Kd AAMAA"が GTライセンスに埋め込ま れているとする。
(5) アクセス許諾命令を実行した結果、 共有先モジュールの TLBにリン クした TRB^Iの行に、 GTライセンスの内容が設定される。 これにより、 共 有先モジュールが共有保護領域から読み出すデータは、 鍵 Kd で正常に復号さ れた状態でキヤッシュされる。
この結果、 図 32に示す例によれば、 TLBの 4行目には、 物理ページ番号 〃002"へのアクセス権 PR"が設定され、 この T L B内の行に対応する TR Bの 4行目には、 データ鍵 Kd AAAAAA"が Key フィールドに設定される。 これによ り、 生成元モジュールの保護データ領域 （TLBの 2行目に対応） を、 共有先 モジュールが、 データ鍵 Kd AAAAAA を用いて復号して読み出す事が可能とな る。
なお、 異なるモジュール間で相互認証を行う場合には、 手順 （2 ) において 共有先モジュールは、 生成元モジュールの公開鍵または公開鍵で暗号化した対 称鍵暗号法の鍵で、 生成した送信メッセージを暗号化して、 生成元モジュール に渡せばよい。 これにより、 このメッセージは生成元モジュール以外では復号 できないこととなる。
なお、 図 1 0に示す T L B内で、 I Dが 2である行と I Dが 7である行は、 保護領域を共有した場合を例として示したものである。
図 3 3に、 耐攻撃領域共有システムコールを呼び出した際の処理の手順を示 す。 この手順 （S 1 1 0から S 1 2 3 ) は、 システムコール時の入力パラメタ が領域サイズの代わりに領域の先頭のァドレスであることをのぞいて、 図 2 8 に示す手順 （S 9 0から S 1 0 3 ) と同様であるため、 説明を省略する。
なお、 コンテンツ再生（Player)アプリケーションは、 上述のローカルデータ 共有方式を用いてデコーダ DRM 4 0からデータを得て、 これを再生し、 さらに 編集することとしてもよい。 編集し、 その結果を記録する場合には、 G Tライ センスにおいて指定されたアクセス条件に従わなければならない。 また、 再生 アプリケーションはこれらの処理を G T保護コードとして生成しなければなら ない。
再生時間や期限の制限を再生アプリケーシヨンに強制するためにはセキュア タイマーが必要である。 セキュアタイマーの構築は、 G T 1 0の外に独立した ハードウェア TOM として実現することしてもよい。 または、 G T 1 0が水晶発 信機などを内蔵することが可能である場合、 上述の定期割り込み間隔設定コマ ンドを用いて耐攻擊ソフトウエアとして構築することとしてもよい。 いずれの 場合も、 タイマーがなんらかの理由で停止する場合を想定すると、 外部の Trusted Secure Timerと同期をとる機能を持つ必要がある。 <DRMソフトウェア構築モデル >
以下、 DRMソフトウェアモジュールの構築モデルに説明する。 デコーダ D RM30、 メディア DRM40及びこれらの D RMが用いる P K Iライブラリ 20内の暗号 .復号ライブラリ、 更には、 TRM化が必要なその他のアプリケ ーシヨンは、 GT 10上で保護される GT保護コードとして流通し、 実行され る。 これらのモジュールは、 ほぼ全文を暗文とすることにより GT 10で保護 される。
図 34に、 DRMソフトウェアモジュールの構築モデルの一例を示す。 この モデルでは、 上記 4つのモジュールが異なる開発メーカーで開発され、 異なる コード暗号鍵 key (Kc)で暗号化されていることを想定している。 図 34におい て、 細い黒矢印は、 喑号ィ匕されたライセンスキーのやり取りを示し、 細い白矢 印は、 復号されたライセンスキーのやり取りを示し、 太い黒矢印は、 暗号化さ れたコンテンツのやり取りを示し、 太い白矢印は、 複合されたコンテンツのや り取りを示す。 括弧内の数字は、 手順の順番を示す。 以下、 図 34に沿って、 コンテンツとそのライセンスキーのダウンロード、 管理、 再生手順について説 明する。
( 1) インターネット等のネットワークからダウンローダアプリケーション を介して、 暗号化ラィセンスキー及び暗号化コンテンツは記録媒体に記録され る。
(2) ライセンスキーは暗号化された状態で、 ダウンローダーを介してメデ ィァ DRM40に転送される。
(3) メディア DRM40内で復号されたライセンスキーは、 後述の方法を用 いて安全に管理され、 暗号化された状態で記録媒体に記録される。 ライセンス キーの再暗号化は GT 10で保護された PKI 暗号ライブラリ 20を用いて実施 される。 (4) ユーザの再生要求があった場合、 メディア DRM 40は記録媒体からラ ィセンスキーを取り出し、 復号する。
(5) メディア DRM 40はデコーダ DRM 30を認証し、 デコーダ DRM 30と共 有するセッションキーを用いてライセンスキーを暗号ィ匕してデコーダ DRM30 に転送する。 なお、 この鍵の共有及び手順 （7) の保護データの共有について は <保護データ領域の安全な共有 >において説明した。
( 6 ) デコーダ DRM 30は記録媒体から取り出した暗号化コンテンツと、 メ ディア DRM40から得たライセンスキーとをパラメタとして PKI 暗号ライブラ リ 20に復号処理を依頼する。
(7) 復号されたコンテンツは共有保護データ領域を介して Player など再 生アプリケーシヨンに渡される。
(8) 再生アプリケーションがコンテンツを再生する。
以下、 図 35から図 40を用いて、 上述の手順をより詳しく説明する。
まず、 図 35及び図 36を用いて、 メディア DRMによって行われる処理に ついて説明する。
まず、 メディア DRM40は、 耐攻撃権限設定 （SETJTR一 RIGHTS) 命令及び レジスタの封印 (SEAL— REG) 命令を実行する (S 1 31及び S 1 32) 。 続い て、 メディア DRM40は、 自身に埋め込まれた秘密情報を取り出す （S 1 3 3) 。 メディア DRM40は、 取り出された秘密情報に対応する GTライセン スが、 ライセンスを記録するライセンス DBに格納されているか否か判定する (S 1 34) 。 既にライセンス DBに格納されている場合 （S 1 34 ：あり） 、 S 1 36に進み、 まだライセンス DBに格納されていない場合 （S 1 34 ：な し） 、 メディア DRM40は、 その GTライセンスをライセンス DBに設定し た後 （ S 135 ) 、 S 136に進む。
S 1 36において、 メディア DRM40は、 ライセンス管理用の耐攻撃デー タ領域を生成する。 S 1 36の処理について、 詳しくは、 図 36を用いて後述 する。
ライセンス管理用の耐攻擊データ領域を生成できた場合 （S 1 3 7 ： NORMAL) 、 S I 38に進み、 ライセンス管理用の耐攻撃データ領域を生成でき なかった場合 （S 1 37 ： ERROR) 、 S 142に進む。
S 1 38において、 メディア DRM40は、 ライセンス管理用の耐攻撃デー タ領域を初期化し （S 1 38) 、 ライセンス受信要求、 再生許諾要求又は終了 要求を待つ。 ライセンス受信要求を受けた場合 （S 1 39 ：あり） 、 メディア DRM40はライセンスを受信して （S 143) 、 S 1 39にもどる。 再生許 諾要求を受けた場合、 メディア DRM40は再生許諾を行い （S 144) 、 S 1 39にもどる。 終了要求を受けた場合 （S 141 ： あり） 、 レジスタ解放 (RELEASE_REG) 命令を実行し （S 145) 、 処理を終了する。
ライセンス管理用の耐攻撃データ領域の生成に失敗した場合 （S 1 37 ： ERROR) 、 メディア DRM40は、 エラー表示を出力装置（不図示） に出力し (S 142) 、 S 145に進む。
次に、 図 36を用いて、 図 35の S 1 36について説明する。 ライセンス管 理用耐攻撃データ領域を生成する際、 まず、 メディア DRM40は、 コード暗 号鍵 Kd を用いてアクセス権 PRW の GTライセンスを生成する （S 1 51) 。 続いて、 メディア DRM40は、 耐攻擊領域取得システムコールを呼び出す (S 152) 。 S 1 52の処理については、 上記のとおりである。
耐攻擊領域を取得する際にエラーが生じなかった場合 （S 1 53 ：なし） 、 途中に生成された署名を確認し （S 154) 、 署名が正しければ （S 1 55 ： 一致） 、 正常にメインフローに戻る。 耐攻撃領域を取得する際にエラーが生じ た場合 （S 1 53 ： あり） 、 又は、 署名が正しくない場合 （S 1 5 5 ：不一 致） 、 エラーをメインフローに返す。 次に、 図 37から図 39を用いて、 デコーダ DRMによって行われる処理に ついて説明する。 まず、 デコーダ D RM 3 0は、 耐攻撃権限設定 (SET_TR— RIGHTS) 命令及びレジスタの封印 （SEALJREG) 命令を実行する （S 1 6 1及び S 1 62) 。 続いて、 メディア DRM40は、 自身に埋め込まれた 秘密情報を取り出す （S 1 63) 。
さらに、 デコーダ DRM30は、 復号されたコンテンツ用の共有保護データ 領域を生成する （S 1 64) 。 この S 1 64について、 詳しくは図 38を用い て後述する。
S 1 64の処理が正常に行われた場合 （S 1 65 ： NORMAL) 、 デコーダ DR M30は、 再生許諾要求、 再生要求及び終了要求の何れかを受けるまで待つ。
5164の処理が正常に行われなかった場合 （S 1 6 5 ： ERROR) 、 デコーダ DRM30は、 出力装置 （不図示） にエラーが生じた旨を表示し （S 1 69) 、
5175に進む。
再生許諾要求を受けた場合 （S 1 66 ：あり） 、 デコーダ DRM30は、 メ ディア DRM40からコンテンツのライセンスキーを取得し （S 1 70) 、 S 1 66に戻る。
再生要求を受けた場合 （S 167 ：あり） 、 デコーダ DRM30は、 コンテ ンッのライセンスキーを取得済みであるか否か判定する （S 1 71) 。 コンテ ンッキーを取得済みである場合 （S 171 ：取得済） 、 デコーダ DRM30は 暗号化ブロックを復号し、 そのブロックを共有する処理を行う （S 173) 。 S 173についいて詳しくは図 39を用いて後述する。 続いて、 デコーダ DR M30は、 再生アプリケーションに返却値を通知し （S 1 74) 、 S 1 66に 戻る。 S 1 7 1の判定において、 まだライセンスキーを取得していない場合 (S 1 71 ：なし） 、 出力装置 （不図示） にエラー表示を行い （S 172) 、 S 175に進む。 終了要求を受けた場合 （S 168 :あり） 、 S 175に進み、 デコーダ DR M30は、 レジスタ解放 （RELEASE_REG) 命令を実行し、 処理を終了する。
次に、 図 38を用いて、 図 37の S 1 64について詳しく説明する。 復号さ れたコンテンツ用の共有保護データ領域を生成するために、 まず、 デコーダ D RM30は、 デコーダ DRM30によってデコードされたコンテンツを記録す るための耐攻擊領域を取得するために耐攻撃領域取得システムコールを呼び出 す （S 18 1) 。 この処理については既に説明した。 耐攻擊領域が生成できた 場合 （ S 1 82 ： NORMAL) 、 S 1 84に進む。 そうでない場合 （ S 1 82 ： ERROR) 、 エラー表示を出力装置 （不図示） に出力させ （S 1 83) 、 メイン フローに復帰する。
S 184において、 デコーダ DRM30は、 GT 10に、 暗号化されたコン テンッを復号するために用いる PK I暗号ライブラリを認証させる。 なお、 こ の認証手順は、 <保護データ領域の安全な共有 >において、 図 32を用いて説 明した認証手順と同様である。
S 1 84の認証が正常に行われた場合 （S 185 ： NORMAL) 、 S 1 87に進 む。 S 184の認証が正常に行われなかった場合 （S 185 ： ERROR) 、 エラ 一表示を出力装置 （不図示） に出力させ （S 1 86) 、 メインフローに復帰す る。
S 187において、 デコーダ DRM30は、 耐攻搫領域共有システムコール を呼び出す。 S 1 84の処理が正常に行われた場合 （S 188 ： NORMAL) 、 メ インフローに復帰する。 これにより、 デコーダ DRM30と PK Iライブラリ 力 S、 耐攻擊領域に書きこまれた保護データを共有することができるようになる。 S 1 84の処理が正常に行われなかった場合 （S 188 ： ERROR) 、 エラー表 示を出力装置 （不図示） に出力させ、 メインフローに復帰する。
次に、 図 39を用いて、 図 37の S 1 73についてより詳しく説明する。 ま ず、 デコーダ DRM30は、 再生アプリケーションは既に認証されているか否 か判定する （S 1 91) 。 既に認証されている場合 （S 19 1 ：認証済） 、 S 1 96に進む。 まだ認証されていない場合 （S 1 91 ：未認証） 、 S 1 92力、 ら S 195が行われる。 この処理は、 図 38の S 184から S 188と同様で あるため、 説明を省略する。 S 1 92から S 195の処理においてエラーが発 生した場合 （S 1 93及び S 1 95で ERROR) 、 エラー表示を出力装置 （不図 示） に出力させ （S 1 98) 、 メインフローに復帰する。 S 1 92から S 1 9 5が正常に行われた場合、 再生アプリケーションとデコーダ DRM 30とは耐 攻撃領域を共有し、 再生アプリケーションは、 デコーダ DRM30によって耐 攻撃領域に書きこまれたコンテンツを読み出すことができるようになる。
S 196において、 デコーダ DRM30は、 暗号化されたコンテンツを P K I暗号ライブラリ 20を用いて復号する。 復号されたコンテンツは、 共有化さ れた耐攻撃領域に書き込まれる。 復号が正常に行われた場合 （S 1 9 7 ： NORMAL) 、 メインフローに復帰する。 復号が正常に行われなかった場合 （S1 97 : ERROR) 、 S 1 98に進む。
次に、 図 40を用いて、 再生アプリケーションによって行われる処理につい て説明する。
まず、 再生アプリケーションは、 耐攻撃権限設定 （SET_TR_RIGHTS) 命令及 びレジスタの封印 (SEAL— REG) 命令を実行する (S 20 1及び S 202) 。 続 いて、 再生アプリケーションは、 自身に埋め込まれた秘密情報を取り出す （S 203) 。 続いて、 再生アプリケーションは、 デコーダ DRM30に認証を要 求する （S 204) 。 この認証要求に基づいて、 上記 S 192が行われる。
認証が正常に行われた場合 （S 205 ： NORMAL) 、 再生アプリケーションは、 再生要求、 その他の要求又は終了要求を受けるのを待つ。 認証が正常に行われ なかった場合 （S 20 5 ： ERROR) 、 再生アプリケーションは、 エラー表示を 出力装置 （不図示） に出力させ （S 214) 、 S 216に進む。
再生要求を受けた場合 （S 206 ：あり） 、 再生アプリケーションは、 デコ ーダ DRM 30に暗号ブロックを復号するよう要求する （S 210) 。 デコー ダ DRM30からの返却値が正常な場合 （S 21 1 ： ORMAL) 、 再生アプリケ ーシヨンは、 そのブロックを再生する （S 21 2) 。 コンテンツの再生が終了 するまで （S 2 14 : No) 、 S 210から S 2 12は繰り返される。 コンテ ンッの再生が終了すると （S 214 : Ye s) 、 S 206にもどる。
再生要求以外の要求を受けると （S 207 :あり） 、 再生アプリケーション はその要求を実行し （S 208) 、 S 206にもどる。 終了要求を受けると (S 20 9 ： あり） 、 再生アプリケーションは GT 1 0にレジスタ解放
(RELEASE— REG) 命令を実行させ （S 216) 、 処理を終了する。 - <秘密情報の管理 >
証明書を発行された公開鍵暗号法の公開鍵に対応する秘密鍵 Kdrm など、 DRM コードパッケージ開発者が生成する秘密情報を維持■管理する方式を図 41に 示す。 図 41において、 細い矢印はデータの流れを示し、 太い白矢印は、 鍵等 の埋め込みを示す。 また、 括弧内の数字は処理の順番を示し、 以下の説明にお ける手順の番号に対応する。
特に公開鍵証明書に対応する秘密鍵は、 CRLの指定時などに、 特定の GT と 特定の DRM のセットのみを停止する必要性から、 本方式を用いる必要がある。 本方式の手順はおおよそつぎのようになる。
(1) 開発者が生成した秘密鍵 （Kdrmなど） は、 クラス -個別いずれの場合 も開発者が生成した対称鍵暗号法の鍵 Kprd で暗号化され、 パッケージ内に埋 め込まれる。
(2) GTライセンス化された、 Kprd とアクセス条件' PR' とは、 耐攻擊モ —ドでのみ読み出し可能な形態で保護コード内に埋め込まれる。 (3) コード全体は、 Kcで暗号化され DRMとして保護パッケージ化される。
(4) Kcは KPgtで暗号化され、 DRMライセンスとして DRMパッケージに入 れられる。
(5) DRM実行時に VHTRMからこの GTライセンスは GT 10に投入され、 G T 10内部で Kprdが読み出される。
(6) Kprdで Kdrmは復号され、 利用される。
これにより、 開発者が指定した GT上の指定プロセス以外のプロセスは、 秘 密鍵 Kdrm を読むことができなくなる。 特定の GTが破られた場合には、 破ら れた GTの公開鍵暗号法の公開鍵証明書のみを失効すればよい。 従って、 同じ DRM 向けのものでも、 他の GT向けの証明書 （Cdrm2) は正当に利用することが できる。
本方式は DRM の秘密鍵のみでなく、 他の保護パッケージの秘密鍵を管理する 方法としても利用できる。
く UD ACライセンス管理〉
保護コンテンツと UMC ライセンスに関する一般情報の管理方式は、 UDAC-MB および UDAC- LA の方式を引き継ぐことしてもよレ、。 図 42にライセンス管理の, ためのメモリアクセスの方式を示す。
図 42に示すように、 コンテンツ復号鍵などのライセンスの秘密情報は、 R AMI 7内の保護データ領域に記録されて管理される。 その保護データ領域内 の情報は、 ファイルとしてストレージゃフラッシュメモリなどに記憶されるこ ととしてもよい。 秘密情報を記録する際にデータ暗号鍵 Kdで暗号^ iすること により、 CPU (GT 10) の再起動時にもライセンスの秘密情報が安全に保 護された状態で利用できる。 このデータ暗号鍵 Kdは TRB暗号鍵 Ktrbで暗号 化された状態で、 暗号化キーテーブルの行として一般の外部記憶装置に保持さ れることしてもよい。 なお、 Ktrb と Ktlb の耐攻擊能力を高めるためには、 一定の期間を置いて Ktrb と Ktlb の内容をリフレッシュする必要がある。 リフレッシュの前にはラ ィセンス情報をすベて、 耐攻擊プロセスが生成した一時キーで暗号化してバッ クアップしなければならない。 リフレッシュによる Ktrb及び Ktlb変更のあと に、 ページテーブルと暗号化キーテーブルを再構築する。 全ライセンス情報を 復^:し、 再構築した耐攻撃領域にリストァすればよい。
上記の秘密鍵管理が前提として C R Lの管理を行う事も可能である。 また、 ライセンスごとの CRL制御機能は上記のライセンス管理機能内に持つこととし ても,よい。 1つの DRMパッケージの証明書は、 G T 1 0が持っている証明書の 数だけ発行されることを原則とする。 DRMパッケージ自体を失効する場合には それらの証明書のすべてが失効される。 また特定の GT を失効する場合には、 その GT用に発行した D謂パッケージ証明書のみが失効される。
プログラムコンテンツを超流通し、 UDAC ライセンスを扱う場合、 DRM ソフト ウェアを利用せず、 簡易版超流通機能として、 GT ライセンスをそのまま利用し てもよい。 また、 GT上に構築した DRM ソフトウエアを用いて、 UDAC- MBや PI ライセンスとして処理してもよい。 DRM ソフトウェアを用いる場合、 UDAC - MB/PI ライセンスのうち、 基本アクセス権（PR， X， PRW, PWX)のみは DRM 内で GT ライセンスに変換し、 CPU のアクセス制御命令（AUTHORIZE)を用いて強制す る。 その他のアクセス条件については、 GT保護 DRM内で強制処理を行う。
当然ながら、 UDACのみでなく、 今日のソフトウェア TRMを用いた各社の DRM も GT保護化することで、 ハードウェア TRM レベルの耐攻撃性を持つことがで さる。
ぐ変形例 >
上記において、 G Tライセンスは移動しない事として説明したが、 DRM間の ライセンス移動機能の実現する事も可能である。 同じ G T上で実行される 2つ の D RMプロセス間でのライセンス移動 ·許諾は、 く保護データの安全な共有 >で認証された共有耐攻擊領域を介して実現することとしてもよいし、 UDAC- MBや UDAC-PIなどのプロトコルを利用して実現する事としても良い。 伹し、 ラ ィセンスの移動機能を実装する場合、 再送攻撃による不正コピーを防止するた めには、 T RM内に、 以下の UPL (Unreplicatable Private Locker：複製不能 プライベートロッカー）にライセンス管理用秘密情報を格納しなければならな い。 この UPLを GTのみで実現したい場合には、 TRB. uo (T R B内の uoフィー ルドの値） および TRB. cl (T R B内の cl フィールドの値） を両方とも onにし た耐攻撃領域にライセンス管理用秘密情報を格納することでこれが可能になる。 ただし、 GTの電源を切断後も UPLを用いて管理しているライセンスを維持す る必要がある場合には、 ライセンス管理用秘密情報を格納する UPL の領域だけ でも不揮発性記憶素子にし、 Permanent UPL (半永久 UPL) にする必要がある。 耐攻擊空間の一部を Permanent UPL に割り当てる方法については、 ここでは特 定しない。
GTの外部に TRM化した UPLを実現するためには、 UPLは UDAC- MBなどの TRM 認証プロトコルを UPL 内に実装する必要がある。 外部に実現する Permanent UPLとしては UDACを実装した Secure匪 Cなどを利用することができる。
次に、 第 2実施形態について説明する。 第 1実施形態において、 コードプロ ック及びデータブロックは、 平文又は喑文であった （ebim- 0又は 1 ) 。 第 2 実施形態によれば、 ブロックは、 暗文及び平文更には他の情報の組合せであつ てもよい。
以下、 図 4 3を用いて第 2実施形態に係わる G Tを実現する C P Uの構成に ついて説明する。
なお、 図 4 3において、 図 3に示す第 1実施形態と同様の部分は省略されてい る。 図 4 3に示すように、 第 2実施形態に係わる G T 1 0 0は、 第 1実施形態 にかかわる構成に加えて、 さらに、 保護ブロックセレクタ 1 0 1及び 1 0 4、 ハッシュチェッカ 1 0 2、 及びハッシュエンジン 1 0 3を備える。
保護ブロックセレクタ 1 0 1は、 キヤッシュ 1 1又は 1 2から出力されるコ 一ドブロック又はデータブロック力 保護されるべきブロックであるか否かを ebimの値に基づいて識別する。 出力されたブロックが保護されるべきブロック である場合、 保護ブロックセレクタ 1 0 1は、 そのブロックをハッシュェンジ ン 1 0 3に出力する。 ハッシュエンジン 1 0 3はそのプロックのハッシュを生 成し、 ハッシュが生成された後に、 暗号ブロック 1 6はそのプロックを暗号化 し、 R AM I 7に出力する。 一方、 キャッシュ 1 1又は 1 2から出力されたブ ロックが保護されるべきプロックではない場合、 保護ブロックセレクタ 1 0 1 は、 そのブロックを R AM I 7に出力する。
また、 保護ブロックセレクタ 1 0 4は、 R AM I 7から出力されるコードブ 口ック又はデータブロック力 暗号化されているブロックであるのか平文のブ 口ックであるの力識別する。 出力されたブロックが暗号化されているプロシク、 つまり保護ブロックである場合、 保護ブロックセレクタ 1 0 4は、 その保護プ ロックを暗号エンジン 1 6に出力する。 暗号エンジン 1 6は、 その保護ブロッ クを復号し、 復号されたプロックをハッシュエンジン 1 0 3に出力する。 ハツ シュエンジンは、 そのプロックのハッシュを生成し、 ハッシュチェッカ 1 0 2 に出力する。 ハッシュチェッカ 1 0 2は、 生成されたハッシュを確認し、 ハツ シュが正しい事を確認できた場合、 そのブロックをキャッシュ 1 2又は 1 3に 出力する。 一方、 R AM I 7から出力されたブロックが保護ブロックではない 場合、 保護プロックセレクタ 1 0 4は、 そのプロックをキャッシュ 1 2又は 1 3に出力する。
なお、 図 4 3において、 保護ブロックセレクタ 1 0 1及ぴ 1 0 4を備えるこ ととしたが、 保護ブロックセレクタ 1 0 1及び 1 0 4を 1つの保護ブロックセ レクタとして構成することとしてもよい。 これにより、 回路を小型化すること が可能となる。
次に、 第 2実施形態に係わる TLB内のフィールドについて説明する。 図 5 に示す TLBには、 ebim フィールドが含まれる。 第 1実施形態によれば、 この ebim の値は 0又は 1であった。 第 2実施形態によれば、 この ebim の取りうる 値として、 更に 2から 7が追加される。 以下、 ebimの値に応じるブロックの構 造について説明する。
a) ebim=0の場合、 平文のみ （ダミーライセンス、 第 1実施形態と同様） b) ebim= lの場合、 暗文のみ （第 1実施形態と同様）
c) ebim= 2の場合、 保護プロック開始識別コード使用
d) ebim=3の場合、 同上かつ暗号化ブロックのみ
e) ebim==4の場合、 署名付平文ブロックのみ。
キャッシュロード時署名確認必須
f ) ebim= 5の場合、 ハッシュ付暗号ィヒ保護ブロックのみ。
復号後ハッシュ確認必須
g) ebim=6の場合、 保護ブロック開始識別コード使用。
署名/ハッシュ確認必須
h) ebim== 7の場合、 同上かつ暗号化ブロックのみ。 ハッシュ確認必須 すなわち、 本フィールドの各ビットは、 次のような意味を持つ。
ビット 0 ：暗号化フラグ。 このフラグがオンである場合、 ブロックが暗号化 されている事を示す。
ビット 1 ：保護プロック開始識別コードフラグ。 このフラグがオンである場 合、 ブロックに保護ブロック開始識別コードが付加されていることを示す。 個 フラグがオフである場合、 GT 1 0は、 保護ブロック開 台識別コードを認識す る必要はない。 ビット 2 ：ハッシュ付加 ·確認フラグ。 このフラグがオンである場合、 デー タを G T 1 0の外に掃出する際に、 G T 1 0は、 そのデータブロックにハツシ ュを付加する。 また、 コードやデータを G T 1 0内に取り込む際には、 ブロッ クに付加されたハッシュ値を確認する。 このフラグがオフである場合、 ブロッ クにハッシュを付加したり確認したりする必要はない。
これらの ebim の値は、 第 1実施形態と同様に、 G Tライセンスに含まれる 被許諾コード鍵 ACgt内の ebimフィールドの値に基づいて設定される。
次に、 図 4 4を用いて第 2実施形態におけるプロックの構造について説明す る。 G T 1 0によれば、 保護コードブロックと保護データプロックの構造を同 じ形式にしても良い。 これにより、 C P U内の回路リソースの利用率を向上さ せることが可能となる。 図 4 4に示すように、 開発者や創作者によって生成さ れたブロックは、 乱数、 一般命令やデータを含み、 必要な場合さらにハッシュ を含む。 ebimが 1又は 5である場合、 このブロックが暗号化されることにより、 保護ブロックが生成される。 ebimが 2、 3、 6又は 7である場合、 このプロッ クが喑号化された後に、 保護ブロックへッド識別コードが平文で先頭に付加さ れることにより。 保護ブロックが生成される。 保護ブロックヘッド識別コード は、 プロックが保護プロックであるか否かを示す暗号化フラグ及び、 ブロック の最後にハッシュが付加されているか否かを示すハッシュフラグを含む。 保護 プロックへッド識別コード及び暗号化された乱数部分は、 保護プロック開始命 令を構成する。
R AM I 7上の保護ブロックは、 G T 1 0内で復号されることにより、 平文 の一般命令やデータが取得される。 ebimが 1又は 5である場合、 乱数部分ゃハ ッシュ部分は、 コードやデータのアドレスがかわらないように、 N O P (No OPeration) 命令に変換されてから、 命令キャッシュ 1 2又はデータキヤッシ ュ 1 3にロードされる。 なお、 ebimが 1である場合は、 第 1実施形態と同じで ある。 ebimが 2、 3、 6又は 7である場合、 乱数部分、 ハッシュ部分に加えて 保護ブロックヘッド識別コードも、 NOP (No OPeration) に変換されてから、 命令キャッシュ 12又はデータキャッシュ 1 3にロードされる。
なお、 プロセッサコア 1 1上の作業データ等を暗号化した場合の保護ブロッ クの構造も、 開発者又は創作者によって生成されたブロックを暗号化した場合 の保護プロックと同様の構造である。
図 45に、 ebimが 4である場合のブロックの構造を示す。 図 45に示すよう に、 ebimが 4である場合、 RAM上のブロックは、 平文のコード又は平文のデ ータに署名が付加された構造となっている。 命令キャッシュ 1 2又はデータキ ャッシュ 1 3上にブロックをロードする際には、 署名は NOP命令に変換され る。 なお、 署名は、 コード又はデータのハッシュ (SHA— 1など） を暗号鍵 Kc又は Kdで暗号化した値とすることとしてもよい。 なお、 Kc及び Kdは、 G Tライセンスで指定され、 TRBの喑号鍵フィールド （TRB.key) に設定され ている。
次に、 第 2実施形態に係わる GTによって行われる処理について説明する。 基本的な動作は、 第 1実施形態と第 2実施形態とは同様であるため、 以下の説 明において、 第 2実施形態において更に付加された構成によつて行われる処理 に重点をおいて説明する。
まず、 図 46を用いて、 保護ブロックセレクタ 104によって行われる処理 について説明する。
まず、 保護ブロックセレクタ 104は、 RAMI 7 (外部メモリ） からブロ ックのロード要求が出されるのを待つ （S 22 1 ) 。 RAMI 7からブロッ クのロード要求が出されると （S 221 :要求） 、 保護ブロックセレクタ 10 4は、 予測されるブロックのアドレスと対応する行の ebim フィーノレドの値を TLBから読み込む （S 222) 。 保護プロッセレクタ 1 04は、 ebimの第 1ビットがオンであるか否か判定す る （S 2 23) 。 ebimの第 1ビットは、 ブロックに保護プロック開台命令が付 加されているか否かをしめす。 ebim の第 1ビットがオンである場合 （S 2 2 3 ： o n) 、 そのブロックには保護ブロック開始命令が付加されている。 保護 ブロックセレクタ 1 04は、 そのブロックの先頭に付加されている保護ブロッ ク開始命令を読み出し （S 2 24) 、 その保護ブロック開始命令において暗号 化フラグがオンであるか否か判定する （S 22 5) 。 暗号化フラグは、 暗号化 フラグがオンである場合 （S 20 5 : o n) 、 S 229に進む。 S 2 2 9にお いて、 保護ブロックセレクタ 1 04は、 そのブロックを暗号エンジン 1 6に出 力し、 S 20 1に戻る。 この場合、 そのブロックは、 復号された後にキヤ シ ュ 1 2又は 1 3に転送される。
暗号化フラグがオフである場合 （S 2 2 5 ： o f f ) 、 保護ブロックセレク タ 1 04は、 さらに、 ebimの第 2ビットがオンであるか否か判定する （S 22 6) 。 ebimの第 2ビットは、 そのブロックを転送する際にハッシュの確認が必 要であるか否かを示す。 ebim の第 2ビットがオンである場合 （S 2 2 6 ： o n) 、 処理は S 20 9に進む。 ebim の第 2ビットがオフである場合 （S 22 6 ： o f ί ) 、 保護ブロックセレクタ 1 04はそのブロックをキヤッシュ 1 2 又は 1 3に転送する （S 22 7) 。
S 2 2 3の判定において、 ebimの第 1ビットがオフである場合 （S 2 2 3 ： o f f ) , 保護ブロッセレクタ 1 04は、 更に ebim の第 0ビットがオンであ るか否か判定する （S 228) 。 ebimの第 0ビットは、 そのブロックを暗号化 することが必要であるか否かを示す。 ebimの第 0ビットがオンである場合 （S 2 28 ： o n) 、 処理は S 22 9に進む。 ebimの第 0ビットがオフである場合 (S 2 28 ： o f ί ) 、 保護ブロックセレクタ 1 04は、 さらに ebim の第 2 ビットがオンであるか否か判定する （S 2 30) 。 ebimの第 2ビットがオンで ある場合 （S 2 30 ： o n) 、 処理は S 22 9に進む。 ebim の第 2ビットがォ フである場合 （S 23 ◦ ： o f f ) 、 保護ブロックセレクタ 1 04は、 そのブ 口ックをキャッシュ 1 2又は 1 3に転送し （S 23 1) 、 S 2 2 1に戻る。 続いて、 図 4 7を用いて、 ハッシュエンジン 1 0 3によって行われる処理に ついて説明する。
まず、 ハッシュエンジン 1 0 3は、 ハッシュ要求のイベントが発生すること を待つ (S 24 1 ) 。 ィベントが発生すると、 ハッシュエンジン 1 0 3は、 ノヽ ッシュの要求が行われたブロックを読み込む （S 242) 。 さらに、 ハッシュ エンジン 1 0 3は、 そのブロックのアドレスと対応する ebim を読み込み、 そ の ebim の第 2ビットがオンであるか否か判定する （S 243) 。 ebim の第 2 ビットがオンである場合 （S 24 3 : o n) 、 ハッシュエンジン 1 0 3は、 そ のブロックのハッシュを生成し （S 244) 、 そのブロックと生成したハツシ ュの内容を次の回路ブロックに転送し （S 24 5) 、 S 24 1に戻る。 一方、 ebimの第 2ビットがオフである場合 （S 24 3 ： o f f ) 、 ハッシュエンジン 1 03は、 ハッシュを生成しないでそのブロックを次の回路プロックに転送し (S 246) 、 処理は S 24 1に戻る。
続いて、 図 48を用いて、 ハッシュチェッカ 1 02によって行われる処理に ついて説明する。
まず、 ハッシュチェッカ 1 0 2は、 ハッシュ要求のイベントが発生する事を 待つ （S 2 5 1) 。 イベントが発生すると、 ハッシュチェッカ 10 2は、 要求 が行われたブロックを読み込む （S 25 2) 。 続いて、 ハッシュチェッカ 1 0 2は、 そのブロックのアドレスと対応する ebimを読み込み、 その ebimの第 2 ビットがオンであるか否か判定する （S 25 3) 。 ebimの第 2ビットがオンで ある場合 (S 2 5 3 ： o n) 、 ハッシュチェッカ 1 0 2は、 ハッシュエンジン 1 03によって生成されたハッシュと、 そのブロックに付加されているハツシ ュとを比較する （S 2 5 4 ) 。 比較の結果、 2つのハッシュが一致しない場合 ( S 2 5 4 ：不一致） 、 プロセッサコア 1 1に、 ハッシュ不一致例外が発生し たことを通知し （S 2 5 5 ) 、 S 2 5 1に戻る。 2つのハッシュが一致した場 合 （S 2 5 4 ：—致） 、 ハッシュチェッカは、 そのブロックを次の回路ブロッ クに転送し （S 2 5 6 ) 、 S 2 3 1に戻る。
次に、 第 2実施形態の変形例について説明する。 第 2実施形態では、 ebimに 基づいて、 保護ブロックセレクタは、 ブロックを選択するとして説明した。 こ の方式以外の方式を以下に例示する。
1 . 実行ファイルのヘッダに暗号化プロックビットマップを埋め込む方法。 保護プロックセレクタは、 このビットマップを先に読み込んで、 ブロックを一 般ラインに出力する力、 復号ラインに出力するかを判断する。
2 . コードの先頭を平文にし、 この先頭のコードにおいて、 何ブロックの平 文のあと、 何ブロックの保護コードがきてこれを繰り返すかを指定し、 G T 1 0 0は、 最初にこのコード （インストラクション） を実行する。 このコードは、 途中で変更することも可能である。 この方式によれば保護コードブロックセレ クタの機能を縮小できる。 アドレスの卞位ビットだけで、 保護コードをセレク トすることができれば、 さらにセレクタの機能を縮小させることが可能になる。 次に、 第 3実施形態について説明する。 第 1及ぴ第 2実施形態によれば、 保 護コードや保護データがキャッシュ内に入る時には、 乱数を変換した結果とし て得られた N O Pがキャッシュライン長ごとに存在することになる。 これによ り、 キャッシュ内のリソースを無駄に使用するという問題が生じる。 第 3実施 形態は、 その問題を解決する技術にかかわる。 第 3実施形態によれば、 以下の 方法 1から 3によってキャッシュのリソースを有効に利用することを可能とな る。
方法 1 ) 乱数長とブロック数の積に、 仮想領域長を加算した長さを、 物理領 域長とする。 （仮想領域長 +乱数長 Xプロック数 =物 領域長） 。 RAMI 7 上に仮想ページの大きさにはみ出す部分を持つことにより、 はみ出した部分、 つまり乱数を変換した NOPが、 キヤッシュ内に記録されないようにする。 方法 2) 乱数長とブロック数の積に等しい長さを持つ領域を、 NOP専用の 物理領域として設定する。
方法 3) キャッシュ内に NOPを記録しない。 図 49に、 本方法による NO Pの処理を示す。 図 49に示すように、 RAMI 7における、 保護コードブロ ック又は保護データブロックは、 暗号化されている。 なお、 場合によっては、 保護コードブロック又は保護データプロックは、 保護プロックへッド識別コー ドを含む。 この保護コードブロック又は保護データブロックが GT 10内で復 号されると、 一般命令 （又は一般データ） 、 乱数及びハッシュを含むブロック が得られるが、 キャッシュ内には、 このうちの一般命令又は一般データが記録 され、 NOPが記録されるべき仮想アドレスのデータは記録されない。 コード が NOPの仮 ¾|アドレスにアクセスした場合、 NOPをコードに返す。 なお、 仮想メモリに記憶される NOPを OS等から読むことができるようにしても良 いし、 読むことができないようにしても良い。
次に、 第 4実施形態について説明する。 第 4実施形態は、 上記において説明 した GT 1 0を 2以上備える CPU、 つまりマルチ CPUにおいて保護プロセ スを動作させる場合に係わる。
マルチ C PUで保護プロセスを動作させる場合、 以下のような場合に備える 必要がある。
1. コード復号鍵 Kc を 1つだけ持つ保護プロセスが、 複数のスレッ ドを複 数の C P U上で平行に実行する場合
2. スヌープ機能による保護コードや保護データなど、 キャッシュ内容の自 動同期に対応する。 図 50に、 GT 1 0 及び0丁 10 Bを備えるマルチ CPUの構成をしめす。 図 50に示すように、 GT 10 A、 GT 10 B及び RAMI Ί 1 バスを介し て接続されている。 GT 10 Α及び GT 10 Βは、 それぞれキャッシュを備え る。 複数のスレツドを GT 10 A及び GT 10 Bによって並行に実行する場合、 実行に先立つて、 G T 1 0 A及び G T 1 0 Bは、 D C T P (Digital Transmission Content Protection) の完全 s≤、EiE (Full Authentication; 等の 相互認証を行う事によってセッション鍵 Ksnp を得る。 GT 10A及び GT 1 0 Bは、 秘密情報、 保護コード及び保護データを交換する場合、 セッション鍵 Ksnpを用いる。 これにより、 GT 10 A及び GT 10 Bは Ktrbや Kc、 Kd等を 安全に交換することが可能となる。 GT 10 A及び GT 10 Bは、 セッション 鍵 Ksnp を用いてキャッシュ内のデータを暗号化し、 互いに同期転送すること により、 キャッシュ内容の同期を実現する。
次に、 第 4実施形態について説明する。 従来のコンパイラやアッセンブラを 用いて作成したプログラムコードオブジェクトは、 GT保護関連の情報を持た ない。 これを図 5 1に示すような方式で GTでの保護コード実行形式、 さらに SCDF (超流通コンテンツ开式： Super Content Distribution Format) に変換 することができる。
図 51に、 コードオブジェクトから保護コード実行形式を出力するツール群 の例を示す。 図 5 1では、 保護コード実行形式とライセンスを生成し、 さらに 実行形式を超流通実施のために SCDF生成ツールを通して SCDFデータを生成す る例を提案している。
図 51に示すように、 SCDF生成ツールは、 リンカ前処理部、 リンカ、 保 護コード実行形式生成部、 及び S CD F作成部を備える。 まず、 コードォブジ ェクトは、 リンカ前処理部によって、 複数のブロックに分割され、 それぞれの ブロックに NOP命令が追加される。 続いて、 リンカは、 アドレス解決を行う。 さらに、 リンカの後、 保護コード実行形式生成部は、 コード暗号鍵を用いて各 ブロックを暗号化することにより保護コード実行形式を生成する。 一方、 GT ライセンス生成部は、 前記コード暗号鍵を含み、 前記秘密鍵と対になる公開鍵 によって暗号化されたライセンスを生成する。
次に、 第 5実施形態について説明する。 GT 10による保護を実現するため には、 GT 10と、 GT 10で保護される DRMソフトウェアモジュールとが 必要である。 しかし当初は GTも普及しておらず、 03も0丁 10の機能をサ ポートしていないため、 次のようなシナリオで普及を推進する必要がある。
(1) 当初はソフトウェア TRM により、 CPU拡張部分のハードウェア命令ェ ミュレータを開発し、 従来の C PU向けの DRMソフトウエアをエミュレート する。 これにより、 従来の C PU向けの DRMソフトウェアも、 GT 10上で 保護ソフトウェアとして稼動することが可能となる。
(2) DRM部分は既存 DRMモジュールを流用する。
(3) OSが GT 10の機能をサポートするまでは耐攻撃空間管理、 保護コ ンテキスト切り替え管理や DRMなどを〇 Sパッケージの外に持つ必要がある。 また、 当初はアプリケーションとデコーダ DRMは一つのパッケージにし、 Kc 及び Kdは同じとすることとしてもよい。
以下、 上記各実施形態において説明した GTの応用例について、 第 6実施形 態から第 12実施形態として説明する。
GTの応用例について様々な例が挙げられるが、 ここでは、 例として、 パー ソナノレコ ンピュータ、 ワークステーショ ン、 P DA (Personal Digital Assistance) 、 携帯電話 （簡易型携帯電話を含む） 、 スマートカード等の I C カード、 RF I Dメディア、 AV (Audio Visual) 機器、 GR I D計算、 ロボ ット等を例として挙げ、 これらについて説明する。
まず、 第 6実施形態として、 パーソナ コンピュータ及びワークステーショ ンへの GTの応用について説明する。 図 52に、 GT 1 0又は 100を、 パー ソナルコンピュータ又はワークステーションに実装した場合のシステム構成例 を示す。 図 52に示すように、 マザ一ボードに GT 10又は 100が搭載され ている。 システムコントローラには、 USB (Universal Serial Bus) コント ローラ、 I DE (Integrated Drive Electronics) コン卜ローラ、 I EEE 1 394コントローラ、 ビデオコントローラ及びオーディォコントローラ等が内 蔵されている。
図 52において、 デジタルコンテンツを記録するメモリカード、 I Cカード、 磁気ディスク、 光磁気ディスク、 デジタル多用途ディスク等の記録媒体には、
T 10又は 100上で保護されるモジュールである。 このように構成すること により、 特別に暗号 '復号専用チップを組み込むことなく、 GTをコンビユー タに採用することにより、 ハードウェア TRMと同じく らい強力に、 デジタル コンテンツを保護することが可能となる。 なお、 図 52において、 システムコ ントローラとして North Bridge が記載され、 インタフェースとして U S Bや I DEが記載され、 シリアルバスとして I EEE 1394が記載されているが、 システム構成を限定する趣旨ではない。
さらに、 ソフトウェア開発 '追加のみで、 個人認証、 TCPA、 電子財布、 個人 情報保護、 Trusted GRID Computingなどをハードウエア TRMと同程度に強力な セキュリティレベルで実現する。
また、 GT保護ソフトウエアとして作成された電子投票ソフトウエアを P C 等にロードする事により、 P Cから電子投票を行うことが可能となる。 また、 GT保護ソフトウェアとして作成されたファイル管理ソフトウェアを PC等に ロードする事により、 セキュアファイルシステムを構成することが可能となる c 次に、 第 7実施形態として、 PDAや携帯電話等のモパイル機器への応用に ついて説明する。
PCの TCPA (Trusted Computing Platform Alliance)機能についは、 従来方式 では別途特別なハードウェア装置を PC に接続する必要があつたが、 GT を P C に搭載すれば、 その PC上のソフトウエアで開発することのみで、 この機能を 実現できる。
携帯電話の端末認証機能も、 同様に従来方式より強力なセキュリティ強度で 実現できる。 例えば、 携帯電話の S I M (Subscriber Identity Module) カー ドを交換する機能は、 G Tを実装する携帯電話間で保護データを交換するソフ 小ウェアを用いる事により、 より安全に実現される。
携帯電話や P D A (Personal Digital Assistance) などのモバイル製品に G Tを適用する場合にも、 特別に喑号■復号専用チップを組み込むことなく、 ハードウェア TRM レベルの強力なコンテンツ保護を実現することができる。 さらに、
もちろん、 ソフトウェアを追加すれば、 携帯電話や P DAに、 個人認証機能、 クレジットカード機能、 プリペイドカード機能、 個人情報保護、 機能などを与 える事ができ、 これらの機能はハードウェア TRM と同等の強力なセキュリティ レベルで実現される。
次に、 第 8実施形態として I Cカードや RFID モジュールなどのセキュリテ ィカードゃモジユーノレへの応用について説明する。
I Cカードについては従来の方式では I Cカード内のセキュリティ機能を力 スタマイズするごとに TRM化を施した個別のチップ生産を行う必要があった。 しかも、 個別のチップごとにハードウェア TRMの評価基準について審査を行う 必要があった。
し力 し、 本実施形態によれば、 G Tに保護すべきセキュリティ機能を後から ファームウェアとして追加するだけで、 ハードウェア TRM と同等のレベルの追 加セキュリティ強度を持つ I Cカードを作成することができる。 I Cカードの セキュリティ評価についても、 G Tに追加したファームウェアについてのみ実 施すればよい。
I Cカード、 RFIDモジュールなどのセキュリティカードやモジュールに G T 1 0又は 1 0 0を実装すれば、 カスタマイズしたチップごとに TRM化を施す必 要はなく、 CPU部分のみ TRM化を施しておけばよい。 これで特別に喑号'復号 専用チップなどを組み込むことなく、 ハードウェア TRM レベルの強力なメディ ァ DRM を実現できる。 なお、 ソフトウェア追加のみで個人認証機能、 クレジッ トカード機能、 プリペイドカード機能などをハードウエア TRM レベルの強力な セキュリティで実現することも可能である。
さらに、 CPU と比較して GTの寿命が短い場合に、 GT のコア制御部分のみを 交換できることとしてもよい。 なお、 G Tコア制御とは、 T RM、 T L B等に かかわる部分をいう。 伹し、 この場合、 CPU と I Cカードを超高速バスで接続 する必要がある。
次に、 第 9実施形態として A V機器への応用について説明する。
G Tを A V機器に搭载する場合、 カスタマイズしたチップごとに TRM化を施 す必要はなく、 C P U部分のみ TRM化を施しておけばよい。 これで特別に喑 号 ·復号専用チップを組み込むことなく、 ハードウェア TRM と同程度の強度を 持つ強力な DRM を実現することができる。 また、 さらに、 A V機器に G Tに加 えて、 ソフトウェアを追加することにより個人認証、 オンライン課金機能など を A V機器に与える事も可能である。 これらの機能も、 ハードウェア TRM と同 程度の強度で実現することができる。
続いて、 第 1 0実施形態として、 移動エージェント保護への応用について説 明する。 '
G Tは、 エージェントが移動先で、 不正に耐えて使命を全うするための保護 機能を実現することができる。 つまり、 G Tは、 耐攻撃エージェントとして、 VHTRM に対して安全な移動機能を提供することができる。 移動エージェントを 耐攻撃化することにより、 第 1 1実施形態において説明する GRID計算への GT 適用時と同様のセキュリティ機能を実現することができる。
続いて、 第 1 1実施形態として G R I D計算への応用について説明する。
G R I D計算やネットワークエージェントでは、 従来、 以下の問題があった。
1 . 完全性（Integrity) ： GRID計算の依頼先において、 依頼した実行コード が正しい CPUで、 正しいデータを用いて、 正しく実行されているかどうかを確 認、することはできなかった。 そのため、 依頼先ユーザがどのような不正を働い たとしても、 また依頼先の計算機に実行コードを書き換えるウィルスが入った どしても、 確実に確認する手段がなかった。
2 . 秘匿（Confidentiality) ：計算の依頼先において、 コードやデータの漏 洩ゃ不正コピーが発生する怖れがあった。
3 . 課金 (Accounting) ：計算の依頼先において、 課金処理の不正や CPU利用 量データの改ざんが行われる怖れがあつたため、 課金処理や課金データの完全 性を保証する必要があつた。
4 . 上記の問題を解決するためにソフトウェア T RMを用いると、 処理が格 段に遅くなつてしまうため、 処理速度を重視する GRID 計算の要件には見合わ なくなってしまっていた。 し力、も、 計算機に関する特定の知識があればソフ ト ウェア T RMを容易に破ることができた。
このような問題があるため、 GRID計算の依頼先として、 一般のパーソナルコ ンピュータゃワークステーションを積極的に利用することはできなかった。 しかし、 G Tを実装した C P U上で稼動する保護コードとして、 計算依頼先 で実行されるソフトウェアを開発することにより、 以下が実現されるため、 上 記問題が解決される。 1 . 安全な C P U (G T ) の認証と実行コード改ざん防止保護
2 . 計算処理改ざん防止機能
3 . 安全な課金
4 . 実行コードの不正コピー、 不正利用の防止
5 . 計算依頼先選択の最適化
6 . 信頼の必要なものは TRMのレベルと証明書の発効日などを指定できるよ うにする。
第 1 2実施形態として、 ロボットへの応用について説明する。
人間や動物の作業や動作を肩代わりする自律型ロボットの研究やその発表が 盛んであるが、 その安全性についての検討もさらに重要になってくる。 これま では単なる情報処理装置としての計算機がウィルスなどにのつとられる脅威で あつたが、 物理的に移動し、 その用途によっては人間の力をも凌駕するロボッ トが同様の事態になることを想定する必要がある。 しかし、 ロボットに以下の 機構を備える事により、 このような問題を解決することが可能となる。
1 . ロポット用の危険な部品の CPU にすベて GT を実装し、 ロボット認定機 関が発行した証明書が入っていることとする。
2 . ロポット用の CPUは署名が確認できたコードしか実行しない機構を持つ。
3 . ロボット用の CPUは証明書のない CPUとはセキュリティレベルの高い情 報交換をしないこととする。
4 · 「殺人 ·傷害禁止ルール」 を GT保護ソフトウェアとして実現し、 認定 機関が発行した証明書の秘密鍵を埋め込む。
5 . 「殺人■傷害禁止ルール」 実現ソフトウエアをルールに従って利用した アプリケーションのみに認定機関が発行した証明書の秘密鍵を埋め込む。
6 . ロボットの全入力処理と危害を与えうる動作処理のプログラムコードす ベてから、 このルールエンジンを利用するようにし、 全体を GT保護化する。 2002/006955
94
7 . プログラムコ一ドにはかならずデジタル署名を付加して置くようにする。 コードを実行する前に、 署名チェックを行うようにし、 実行許諾のない場合は 停止する。
8 . 統合ソフトウェア全体を GT保護化する。
これにより、 ロボットを凶悪犯化するウィルスや中央制御機能改ざんなどに 対抗することが可能となる。
次に、 第 1 3実施形態として、 個人情報保護への応用について説明する。
今日、 に NETJ のような万人からの信頼を獲得した個人情報管理サービスが 多くの個人情報を管理しており、 他のサービスは、 自サービスを提供するため に必要な個人情報およびそれらの統計情報程度しか得ることができない。 従つ て、 これらのサービスは、 営業戦略上の顧客統計情報を獲得したり、 広告メー ルサービスを提供したりするためには、 特定の個人情報管理サービスを利用す る必要がある。 このような状況におけるセキュリティ上の課題は次のようなも のである。
1 . 個人情報を回収するサービスが、 サービス利用者に提示した 「個人情報 保護ポリシー」 に従わない可能性がある。 P3P ( Platform for Privacy Preference：プライバシー制御のための基盤） を用いるなどにより、 ポリシー を交換できたとしてもこれを強制する技術はない。
2 . 個人情報を扱うサービスにおいて、 個人情報を処理する従業員自身が不 正な個人情報漏洩を行う可能性がある。
これら問題を解決するために、 本実施形態によれば、 各サービスを提供する サーバの CPU に G Tを実装し、 その上でサーバに、 個人情報を扱うサーバ DRM ソフトウエアやサーバアプリケーシヨンを G T保護コードとしてパッケージ化 する。 上述のように、 G Tライセンスには、 ソフトウェアを実行するプロセス に対してアクセス条件を設定する事ができる。 従って、 これまで、 アクセス制 御を外部から強制する事ができなかったサーバに対しても、 アプリケーション 操作におけるアクセス条件を強制する事ができるようになる。
これにより、 一般消費者に対して、 信頼できる個人情報管理サービスを提供 することができるようになる。 さらに、 サービスサイ トへの個人情報の積極的 な提供を促し、 利用者の要求に従ったサイト間の積極的な個人情報交換を可能 とする事により、 広告 '営業活動と消費活動をより活性化することが可能とな る。
次に、 第 1 4実施形態として、 ウィルス対抗手段への応用について説明する。 従来のゥィルス対抗手段では、 ソフトゥヱァのデジタル署名チェック機能と ウィルスチェックソフトウェアを併用している。 しかしこの方式では、 最新の ウィルスが、 署名チェック機能またはウィルスチェックソフトが起動するまで に動作する実行ファイルを書き換えることによる攻撃に対しては無力である。 コード署名逐次確認機能を持つ G Tであれば、 このようなウィルスに対抗で きる。 そのためには、 C P Uに第 2実施形態に係わる G Tを搭載し、 実装コー ドチェックのためのソフトウェア （コードとデータ） を G Tで保護する。 そし て、 ブートからウィルスチェックソフトウェアが起動されるまでコード署名を G T ( C P U) が逐次確認する。 その上で、 ウィルスチェックソフトウエアを G Tの耐攻擊モードで実行する。 ウィルスチェックソフトウェアは、 各コード を実行する前にコ一ドのハッシュを計算したり、 著名を確認したりする。
これにより、 新種ウィルスに対抗できなかったシステム上のセキュリティホ ールを壊滅することができる。 なお、 コード署名チェック機能については、 既 に説明した。
このように、 G Tをウィルス対抗手段に採用することにより、 従来の方式に 比較して格段に強度の高いウィルス対抗ソフトを実現することができる。
以上、 G Tの様々な応用例について説明した。 このように、 G Tを搭載した CPU を採用することにより、 情報セキュリティ上の脅威により抑制されてきた 各種先端的情報技術の社会基盤への適用が、 促進されることが期待できる。 例 えば、 次のような産業上の技術革新が期待できる。 .
1 . コンテンツ保護の強度的及び機能的問題で積極的に PC に提供されなか つたコンテンツが積極的にインターネットに流され、 また各種 P2P (Person to
Person)技術を用いて積極的に超流通が促進される。
2 . 利用者認証、 電子財布などへの応用により、 一般の情報機器のみを利用 した買い物がソフトウェアの追加だけで安全にできる。 これにより、 インター ネットでのお買い物を恐れていた利用者も買い物をするようになる。 売る側も 安心してサイトに品物を置いて販売できるようになり、 市場がひろがり、 グロ 一バルなィンターネット販売ビジネスを促進する。
3 . 強力な個人情報保護機能の実現により、 個人情報を安心して積極的に売 り込むことによるインターネットを介した広告活動と消費活動のさらなる活性 化を期待できる。
4 . 見ず知らずの CPUの利用を恐れたり、 無償で CPUを貸し出す不公平感に より積極的に計算パワーを提供できなかったりしていた GRID計算を積極的に 活用できるようになる。 これにより、 一般の共用 CPUの利用効率が 10倍程度 以上には向上すると考えられる。.従って、 単純に計算すれば、 各コンピュータ の処理速度が、 ローカルな CPUだけで計算していた時に比較し、 平均して 10 倍程度以上の速さが期待できる。 あるいは、 必要な計算に世界の CPU利用を集 中できるようになる。
5 . ソフトウェア部品の 「超流通」 とネットワークを越えた自律協調型分散 開発を目標とする 「超流用（Superappropriation)」 を強力なウィルス対抗とモ ジュール利用料 P2P課金のセキュリティで促進する。
6 . GTによる安全性の保障が、 強力な実用ロボットの社会への浸透を積極的 02 006955
97 に促進させる。
さらに将来、 GTはいつでもどこでもだれにでも利用できる安全な汎用計算処 理基盤として、 高信頼ユービキタスコンピューティング （Trusted ubiquitous computing) のインフラにもなることができる。
以上、 本発明の実施形態について説明したが、 本発明は上述した実施形態に 限定されるものではなく、 他の様々な変更が可能である。

Claims

請求の範囲
1 . プログラムを実行する中央演算装置であって、
プロックの暗号化及び暗号化プロックの復号を行う暗号手段を備え、 前記中央演算装置には、 第 1の秘密鍵が秘密裏に隠され、
前記暗号手段は、 前記第 1の秘密鍵と対になった公開鍵を用いて暗号化され た第 1のプログラムの第 1のライセンスを、 前記第 1の秘密鍵を用いて復号す ることにより、 前記第 1のライセンスから前記第 1のプログラムを構成する暗 号化プロックを復号するためのコード復号鍵を取得する、
ことを特徴とする中央演算装置。
2 . キャッシュを更に備え、
前記暗号手段は、 前記第 1のプログラムを構成する暗号化ブロックがメモリ 領域から前記キヤッシュに出力される際に、 キヤッシュ単位で前記暗号化プロ ックを復号する、
ことを特徴とする請求項 1に記載の中央演算装置。
3 . ユーザが参照したり改ざんしたりすることができない耐攻擊バッファを 更に備え、
前記コ一ド復号鍵は、 前記耐攻撃バッファに記録される、
ことを特徴とする請求項 1又は 2に記載の中央演算装置。
4 . 前記第 1のライセンスは、 前記第 1のプログラムの実行プロセスがメモ リ領域にアクセスする際のアクセス条件を含み、
前記中央演算装置は、 前記第 1のプログラムを構成する暗号化ブロックが記 録される前記メモリ領域のアドレスと前記メモリ領域へのァクセス条件とを記 録する T L B (Translation Look aside Buffer) と、
メモリ管理手段と、 キヤッシュと、
プロセッサコアを更に備え、
前記 T L Bと前記耐攻擊バッファはリンクされ、
前記メモリ管理手段は、 暗号化プロックを記録するメモリ領域のァドレスに 基づいて前記 T L Bから前記メモリ領域へのアクセス条件を取得し、 さらに、 前記耐攻撃バッファから、 前記メモリ領域に対応する前記コード復号鍵を取得 し、
前記プロセッサコアは、 前記メモリ管理手段が取得した前記アクセス条件に 基づいて、 前記実行プロセスから前記メモリ領域へのアクセスを実行すること が許可されているか否か判定し、 前記メモリ領域へのアクセスを実行する事が 許可されていると判定した場合、 前記実行プロセスから前記メモリ領域へのァ クセスを実行し、
前記暗号手段は、 前記メモリ管理手段が取得した前記コード復号鍵を用いて 前記メモリ領域内の前記暗号化プロックを復号して得られたコ一ドを前記キヤ ッシュに書き込む、
ことを特徴とする請求項 3に記載の中央演算装置。
5 . 前記コード復号鍵と、 前記暗号化ブロックを暗号化する際に用いられた 暗号鍵は同一の鍵である、
ことを特徴とする請求項 4に記載の中央演算装置。
6 . 前記第 1のプログラムの実行プロセスからアクセスされるメモリ領域が、 第 1のメモリ領域から第 2のメモリ領域に切り替わつた場合、
前記メモリ管理手段は、 さらに、 前記耐攻撃バッファから取得された前記第 1のメモリ領域に対応するコ一ド復号鍵と、 前記第 2のメモリ領域に対応する コード復号鍵とがー致するか否か判定し、 一致すると判定した場合、 前記実行 プロセスから前記第 2のメモリ領域へのアクセスを実行し、 一致しないと判定 した場合、 前記実行プロセスから前記第 2のメモリ領域へのアクセスを実行し ない、
ことを特徴とする請求項 4又は 5に記載の中央演算装置。
7 . 前記第 1のライセンスは、 前記第 1のプログラムに埋め込まれている、 ことを特徴とする請求項 1乃至 6のいずれかに記載の中央演算装置。
8 . 前記耐攻擊バッファには前記コード復号鍵ごとに、 異なるデータ暗号鍵 が記録されており、
前記暗号手段は、 前記キヤッシュ内のデータを前記メモリ領域に記録する際 には、 前記データを前記データ暗号鍵を用いて暗号化した後、 前記 T L Bによ つて前記データ暗号鍵に対応付けられた前記メモリ領域に記録し、 前記メモリ 領域内の喑号ィヒされたデータを読み出す際には、 読み出された前記データを前 記データ暗号鍵を用いて復号した後、 前記キヤッシュに書き込む、
ことを特徴とする請求項 4乃至 7のいずれかに記載の中央演算装置。
9 . 第 1のコードを実行することにより得られたデータを第 2のコードで利 用する場合、 前記プロセッサコアは、 前記データを記録するメモリ領域へのァ クセス権を前記第 2のコードに与えるように前記 T L Bを設定し、 且つ、 前記 データを暗号化するためのデータ暗号鍵を、 前記第 2のコードが前記データを 前記メモリ領域から読み出す際に使用するように前記 T L B及び前記耐攻擊バ ッファを設定する、
ことを特徴とする請求項 8に記載の中央演算装置。
1 0 . レジスタと、
レジスタへの了クセス制御を行うためのレジスタアクセス制御テーブルと、 を更に備え、
前記プ口セッサコアは、 前記レジスタアクセス制御テーブル内の封印フラグ を用いて、 前記レジスタの封印及び解放を制御する、 ' ことを特徴とする請求項 4乃至 9のいずれかに記載の中央演算装置。
1 1 . T L Bの内容を外部記憶装置内のページテーブルに記録する際には、 前記暗号手段は、 記録する内容に署名を付与し、
前記ページテーブルの内容を前記 T L Bに取り込む前には、 前記暗号手段は、 前記署名が正しいことを確認する、
ことを特徴とする請求項 4乃至 1 0のいずれかに記載の中央演算装置。
1 2 . 前記耐攻擊バッファの内容を外部記憶装置内の暗号化キーテーブルに 記録する際には、 前記暗号手段は、 記録する内容を暗号化する、
ことを特徴とする請求項 3乃至 1 1のいずれかに記載の中央演算装置。
1 3 . 前記中央演算装置は、 他の中央演算装置と接続され、
前記中央演算装置は、 前記他の中央演算装置と相互に認証を行う事にことに よりセッション鍵を取得し、 前記中央演算装置の前記暗号手段は、 前記セッシ ョン鍵を用いて前記中央演算装置の前記キャッシュの内容を暗号化して、 前記 他の中央演算装置に同期転送する、
ことを特徴とする請求項 1乃至 1 2のいずれかに記載の中央演算装置。
1 4 . 前記暗号手段は、 前記第 1のプログラムを実行する前に、 第 2のプロ グラムに付加された前記第 2のライセンスを前記公開鍵を用いて復号する事に より第 2の秘密鍵を暗号ィヒする際に用いられた秘密鍵暗号鍵を取得し、 さらに、 前記取得された秘密鍵暗号鍵を用いて前記第 2の秘密鍵を復号する、
ことを特徴とする請求項 1乃至請求項 1 3のいずれかに記載の中央演算装置。
1 5 . 前記第 2のライセンスには、 前記第 1のプログラムの実行プロセスか ら読み出しのみ可であることを示すアクセス条件が付加されており、
前記第 2の秘密鍵は、 前記第 1のプログラムの実行プロセスからの読み出し のみ可能である、
ことを特徴とする請求項 1 4に記載の中央演算装置。
1 6 . 前記第 2の秘密鍵は、 データ暗号鍵によつて暗号化されてメモリ領域 に記録される、
ことを特徴とする請求項 1 4又は 1 5に記載の中央演算装置。
1 7 . 前記耐攻擊バッファは、 さらに、
対応する前記耐攻擊バッファ内の情報を前記耐攻撃バッファ外に出力しても 良いか否かを示す外部出力禁止情報と、
対応する情報をキャッシュ外に出力しても良いか否かを示すキヤッシュ口ッ ク'隋幸 とを記録し、
前記外部出力禁止情報及び前記キヤッシュロック情報に基づいて、 第 1のプ 口グラム及び他のプログラムとの間における前記第 1のライセンスの移動は管 理される、
ことを特徴とする請求項 3乃至 1 6のいずれかに記載の中央演算装置。
1 8 . 前第 1のプログラムは、 トラステッドコンピューティングモジュール である、
ことを特徴とする請求項 1乃至 1 7のいずれかに記載の中央演算装置。
1 9 . 前記第 1のプログラムは、 前記中央演算装置に電子財布を実現させる プログラムである、
ことを特徴とする請求項 1乃至 1 7のいずれかに記載の中央演算装置。
2 0 . 前記第 1のプログラムは、 個人情報を扱うプログラムである、 ことを特徴とする請求項 1乃至 1 7のいずれかに記載の中央演算装置。
2 1 . 前記第 1のプログラムは、 前記中央演算装置の実装コードのウィルス チェックプログラムである、
ことを特徴とする請求項 1乃至 1 7のいずれかに記載の中央演算装置。
2 2 . 前記第 1のプログラムは複数の中央演算装置間を移動する移動エージ ェントである、 ことを特徴とする請求項 1乃至 1 7のいずれかに記載の中央演算装置。
2 3 . 前記第 1のプログラムを構成するブロックは、 前記ブロックのハツシ ュ値の確認が必要であるか否かを示すハッシュ確認要否情報を含み、
前記ハッシュ確認要否情報に基づいて、 前記プロックのハッシュ値を算出し、 前記ブロックに付加するハッシュ手段と、
前記ハッシュ確認要否情報に基づいて、 前記プロックの前記ハッシュ値を確 認するハッシュ確認手段と、 .
を更に備えることを特徴とする請求項 1乃至 2 2のいずれかに記載の中央演
2 4 . 前記第 1のプログラムを構成するブロックは、 前記ブロックが保護を 必要とするか否かを示す暗号化要否情報を含み、
前記暗号化要否情報に基づいて、 前記プロックを前記暗号手段に出力するか、 そのままキャッシュ又はメモリ領域に出力するか判定する保護ブロック選択手 段を、
更に備えることを特徴とする請求項 1乃至 2 3のいずれかに記載の中央演算
2 5 . 前記第 1のプログラムの実行ファイルのヘッダは、 前記第 1のプログ ラムを構成するブロックの構成を示す暗号化ブロックビットマップを含み、 前記暗号化プロックビットマップに基づいて、 前記プロックを前記暗号手段 に出力する力 \ そのままキャッシュ又はメモリ領域に出力するか判定する保護 プロック選択手段を、
更に含むことを特徴とする請求項 1乃至 2 3のいずれかに記載の中央演算装
2 6 . 前記第 1のプログラムのコードの先頭は、 前記第 1のプログラムを構 成する複数のブロック力 平文ブロックと暗号化ブロ Vクの組合せの繰り返し であることを指定し、 且つ、 前記組合せにおいて平文ブロックが連続する数及 び暗号化プロックが連続する数を指定するコードであり、
前記コードを実行することにより、 前記プロセッサコアは、 前記ブロックを 前記暗号手段に出力するか、 そのままキャッシュ又はメモリ領域に出力するか 判定する、
更に含むことを特徴とする請求項 1乃至 2 3のいずれかに記載の中央演算装
2 7 . 前記キャッシュとメモリの間に、
前記暗号手段を介するキャッシュラインと、
前記暗号手段を介さないキャッシュラインと、
を更に備えることを特徴とする請求項 2乃至 2 6のいずれかに記載の中央演
2 8 . 請求項 1乃至 2 7のいずれかに記載の中央演算装置を有することを特 徴とするコンピュータ。
2 9 . 請求項 1乃至 2 7のいずれかに記載の中央演算装置を有することを特 徴とする I Cカード。
3 0 . 前記第 1のプログラムは、 前記 I Cカードのセキュリティ機能を実現 するプログラムである、
ことを特徴とする請求項 2 9に記載の I Cカード。
3 1 . 前記中央演算装置は、 ロボットに搭載され、
前記第 1のプログラムは、 前記ロボットを制御する制御プログラムである、 ことを特徴とする請求項 1乃至 2 7のいずれかに記載の中央演算装置。
3 2 . 中央演算装置に保護プログラムを実行する許諾を与える制御を行わせ るプログラムであって、
前記保護プロダラムは、 コード暗号鍵によつて暗号化され、 前記保護プログラムに対応して、 前記コード暗号鍵を含み、 且つ、 前記中央 演算装置に秘密裏に備えられた秘密鍵と対になる公開鍵によって暗号化された ライセンスが存在し、
前記中央演算装置が前記保護プログラムを実行する前に、 前記ライセンスを 前記中央演算装置に投入し、
前記中央演算装置に備えられた暗号手段に、 前記秘密鍵を用いて前記ライセ ンスを復号することにより、 前記ライセンスから前記コード喑号鍵を取得させ、 前記喑号手段に、 前記コード喑号鍵を用いて前記保護プログラムを復号させ る、 .
ことを含む処理を前記中央演算処理装置に実行させるプログラム。
3 3 . 中央演算装置に、 保護プログラムを実行する許諾を与える制御を行わ せるプログラムを記録する記録装置であって、 .
前記保護プログラムは、 コ一ド暗号鍵によつて暗号化され、
前記保護プログラムに対応して、 前記コード暗号鍵を含み、 且つ、 前記中央 演算装置に秘密裏に備えられた秘密鍵と対になる公開鍵によって暗号化された ライセンスが存在し、
前記中央演算装置が前記保護プログラムを実行する前に、 前記ライセンスを 前記中央演算装置に投入し、
前記中央演算装置に備えら得た暗号手段に、 前記秘密鍵を用いて前記ライセ ンスを復号することにより、 前記ライセンスから前記コード喑号鍵を取得させ、 前記暗号手段に、 前記コード暗号鍵を用いて前記保護プログラムを復号させ る、
ことを含む処理を前記中央演算装置に実行させるプログラムを記録する記録 3 4 . 中央演算装置に、 保護プログラムを実行する許諾を与えるプログラム 実行許諾方法であって、
前記保護プログラムは、 コード喑号鍵によって暗号化され、
前記保護プログラムに対応して、 前記コード暗号鍵を含み、 且つ、 前記中央 演算装置に備えられた秘密鍵と対になる公開鍵によって暗号化されたライセン スが存在し、
前記中央演算装置は、 前記保護プログラムを実行する前に、 前記ライセンス を取得し、
前記中央演算装置は、 前記秘密鍵を用いて前記ライセンスを復号することに より、 前記ライセンスから前記コード暗号鍵を取得し、
前記中央演算装置は、 前記コード暗号鍵を用いて前記保護プログラムを復号 する、
ことを含むことを特徴とするプロダラム実行許諾方法。
3 5 . コンピュータにおいて実行されるプログラムコードであって、
前記プログラムコードは、 コ一ド暗号鍵によつて暗号化され、
前記プログラムコードに対応して、 前記コード暗号鍵を含み、 且つ、 前記プ ログラムコードを実行するべきコンピュータに備えられた中央演算装置が秘密 裏に備える秘密鍵と対になる公開鍵によつて暗号化されたライセンスが存在し、 前記ライセンスは前記プログラムコードが実行される前に前記中央演算装置 に投入され、
前記中央演算装置によつて前記秘密鍵を用いて前記ライセンスが復号され、 前記プログラムコードは、 前記ライセンスから取得された前記コ一ド喑号鍵 を用いて、 前記中央演算装置によって復号される、
ことを特徴とするプログラム。
3 6 . コンピュータにおいて実行されるプログラムコードを記録する、 前記 コンピュータによつて読み取り可能な記録媒体であって、 -前記プログラムコードは、 コ一ド暗号鍵によつて暗号化され、
前記プログラムコードに対応して、 前記コード暗号鍵を含み、 且つ、 前記プ 口グラムコードを実行するべきコンピュータに備えられた中央演算装置が秘密 裏に備える秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、 前記ライセンスは前記プログラムコードが実行される前に前記中央演算装置 に投入され、
前記中央演算装置によって前記秘密鍵を用いて前記ライセンスが復号され、 前記プログラムコードは、 前記ライセンスから取得された前記コード暗号鍵 を用いて、 前記中央演算装置によって復号される、
ことを特徴とするプログラムを記録する記録媒体。
3 7 . 秘密裏に隠された秘密鍵と、 暗号化及び復号を行う暗号手段とを備え る中央演算装置を備えるコンピュータにおいて実行されるプログラムを生成す るプログラム生成装置であって、
コードオブジェクトを入力する入力手段と、
入力された前記コードオブジェクトを複数のブロックに分割し、 それぞれの ブロックに N O P命令を追加するリンカ前処理手段と、
ァドレス解決を行うリンカ手段と、
各プロックをコード暗号鍵を用いて暗号化することにより保護コード実行形 式を生成する保護コード実行形式生成手段と、
前記コード暗号鍵を含み、 前記秘密鍵と対になる公開鍵によって暗号化され たライセンスを生成するライセンス生成手段とを備え、
前記ライセンスは、 前記コンピュータが前記保護コ一ド実行形式を実行する 前に前記中央演算装置に投入され、 前記暗号手段によって前記秘密鍵を用いて 復号され、
前記保護コード実行形式は、 前記ライセンスから取得された前記コード暗号 鍵を用いて、 前記暗号手段によって復号される. ことを特徴とするソフトウェア生成装置。
PCT/JP2002/006955 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム WO2004006075A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/JP2002/006955 WO2004006075A1 (ja) 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム
CNB028295870A CN100354786C (zh) 2002-07-09 2002-07-09 开放型通用抗攻击cpu及其应用系统
AU2002346316A AU2002346316A1 (en) 2002-07-09 2002-07-09 Open type general-purpose attack-resistant cpu, and application system thereof
JP2004519192A JP4073913B2 (ja) 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム
EP02743883A EP1542112A4 (en) 2002-07-09 2002-07-09 UCT RESISTANT TO OPEN-TYPE UNIVERSAL ATTACKS, AND ASSOCIATED APPLICATION SYSTEM
US10/614,921 US20040093505A1 (en) 2002-07-09 2003-07-09 Open generic tamper resistant CPU and application system thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2002/006955 WO2004006075A1 (ja) 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム

Publications (1)

Publication Number Publication Date
WO2004006075A1 true WO2004006075A1 (ja) 2004-01-15

Family

ID=30022632

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2002/006955 WO2004006075A1 (ja) 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム

Country Status (6)

Country Link
US (1) US20040093505A1 (ja)
EP (1) EP1542112A4 (ja)
JP (1) JP4073913B2 (ja)
CN (1) CN100354786C (ja)
AU (1) AU2002346316A1 (ja)
WO (1) WO2004006075A1 (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007158618A (ja) * 2005-12-02 2007-06-21 Ricoh Co Ltd 画像処理装置、暗号モジュールのプロセス化方法
JP2008520130A (ja) * 2004-11-10 2008-06-12 エッチ セリンフレウンド、リチャード 光学的マシン固定方法およびシステム
JP2008533629A (ja) * 2005-03-21 2008-08-21 フォートレスウェア インコーポレイテッド 安全な仮想プロジェクトルームを作るための方法及びシステム
JP2009104380A (ja) * 2007-10-23 2009-05-14 Ihi Corp ロボット不正使用防止装置およびロボット不正使用防止方法
JP2009528596A (ja) * 2006-02-23 2009-08-06 クゥアルコム・インコーポレイテッド 信頼コードグループ
JP2011181107A (ja) * 2011-06-09 2011-09-15 Fujitsu Semiconductor Ltd セキュアプロセッサ用プログラム
US8468364B2 (en) 2006-02-22 2013-06-18 Fujitsu Semiconductor Limited Secure processor
JP2013179453A (ja) * 2012-02-28 2013-09-09 Nippon Telegr & Teleph Corp <Ntt> 計算機システムおよび計算方法
JP2015043221A (ja) * 2008-06-12 2015-03-05 メタフォリック リミテッドＭｅｔａｆｏｒｉｃ Ｌｉｍｉｔｅｄ コンピュータプログラムコードを保護する方法
JP2016006681A (ja) * 2013-03-31 2016-01-14 インテル・コーポレーション セキュアエンクレーブページキャッシュのための進歩したページング能力を提供するための命令および論理
WO2022085420A1 (ja) * 2020-10-19 2022-04-28 ソニーグループ株式会社 情報処理装置および方法、並びに情報処理システム
CN114785514A (zh) * 2022-03-23 2022-07-22 国网上海能源互联网研究院有限公司 一种用于工业物联化终端应用许可授权的方法及系统

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1276363C (zh) * 2002-11-13 2006-09-20 深圳市朗科科技有限公司 借助半导体存储装置实现数据安全存储和算法存储的方法
JP3880933B2 (ja) * 2003-01-21 2007-02-14 株式会社東芝 耐タンパマイクロプロセッサ及びキャッシュメモリ搭載プロセッサによるデータアクセス制御方法
JP4338989B2 (ja) * 2003-02-20 2009-10-07 パナソニック株式会社 メモリデバイス
JP4624732B2 (ja) * 2003-07-16 2011-02-02 パナソニック株式会社 アクセス方法
US8060756B2 (en) * 2003-08-07 2011-11-15 Rao G R Mohan Data security and digital rights management system
US7500264B1 (en) * 2004-04-08 2009-03-03 Cisco Technology, Inc. Use of packet hashes to prevent TCP retransmit overwrite attacks
US7475431B2 (en) * 2004-06-10 2009-01-06 International Business Machines Corporation Using security levels to improve permission checking performance and manageability
JP3810425B2 (ja) * 2004-12-16 2006-08-16 松下電器産業株式会社 改竄検出用データ生成方法、および改竄検出方法及び装置
US7757301B2 (en) * 2004-12-21 2010-07-13 Seagate Technology Llc Security hardened disc drive
US7818585B2 (en) * 2004-12-22 2010-10-19 Sap Aktiengesellschaft Secure license management
JP4667108B2 (ja) * 2005-04-11 2011-04-06 パナソニック株式会社 データ処理装置
JP4698285B2 (ja) * 2005-05-19 2011-06-08 富士通株式会社 情報処理装置、情報処理方法及びコンピュータプログラム
US8234505B2 (en) * 2006-01-20 2012-07-31 Seagate Technology Llc Encryption key in a storage system
US8214296B2 (en) * 2006-02-14 2012-07-03 Microsoft Corporation Disaggregated secure execution environment
JP2007304847A (ja) * 2006-05-11 2007-11-22 Megachips Lsi Solutions Inc メモリ装置
US8788829B2 (en) 2006-08-17 2014-07-22 Aol Inc. System and method for interapplication communications
US9860274B2 (en) 2006-09-13 2018-01-02 Sophos Limited Policy management
US20080244275A1 (en) * 2007-03-30 2008-10-02 Motorola, Inc. Instruction Transform for the Prevention and Propagation of Unauthorized Code Injection
US20100088528A1 (en) * 2007-05-03 2010-04-08 Radu Sion Method and apparatus for tamper-proof wirte-once-read-many computer storage
TWI371691B (en) * 2007-12-16 2012-09-01 Infortrend Technology Inc Storage controller for handling data stream and method thereof
US8438385B2 (en) * 2008-03-13 2013-05-07 Fujitsu Limited Method and apparatus for identity verification
KR101511380B1 (ko) * 2008-05-22 2015-04-10 삼성전자주식회사 Ｓｒｍ 장치간의 안전 정보 교환 시스템 및 방법
US20090313171A1 (en) * 2008-06-17 2009-12-17 Microsoft Corporation Electronic transaction verification
CN101587523B (zh) * 2009-07-02 2012-04-18 飞天诚信科技股份有限公司 保护软件的方法和装置
US8799411B2 (en) * 2010-05-28 2014-08-05 Arvato Digital Services Canada, Inc. Method and apparatus for providing enhanced streaming content delivery with multi-archive support using secure download manager and content-indifferent decoding
US8856504B2 (en) * 2010-06-07 2014-10-07 Cisco Technology, Inc. Secure virtual machine bootstrap in untrusted cloud infrastructures
US20120331303A1 (en) * 2011-06-23 2012-12-27 Andersson Jonathan E Method and system for preventing execution of malware
US9009855B2 (en) * 2011-09-11 2015-04-14 Microsoft Technology Licensing, Llc Generating developer license to execute developer application
WO2013077788A1 (en) * 2011-11-23 2013-05-30 Gunnebo Gateway Ab Method of booting a control unit in an electronic article surveillance system and control unit forming part of such a system
AU2012372254A1 (en) * 2012-03-09 2014-07-17 Sony Corporation Information processing device, information storage device, information processing stystem, information processing method, and program
EP2653992A1 (en) 2012-04-17 2013-10-23 Itron, Inc. Microcontroller configured for external memory decryption
US20130298155A1 (en) * 2012-05-03 2013-11-07 Rawllin International Inc. Video personal identification code for video on demand services
MX2014014102A (es) * 2012-05-25 2015-01-26 Koninkl Philips Nv Metodo, sistema y dispositivo para proteccion contra ingenieria inversa e/o intrusion con programas.
US9275223B2 (en) * 2012-10-19 2016-03-01 Mcafee, Inc. Real-time module protection
GB2508052A (en) * 2012-11-18 2014-05-21 Nds Ltd Glitch resistant device
US8995658B2 (en) * 2013-02-13 2015-03-31 Honeywell International Inc. Physics-based key generation
CN103607279B (zh) * 2013-11-14 2017-01-04 中国科学院数据与通信保护研究教育中心 基于多核处理器的密钥保护方法及系统
US20150269357A1 (en) * 2014-03-20 2015-09-24 Adobe Systems Incorporated Method and apparatus for digital rights management that is file type and viewer application agnostic
US10223289B2 (en) 2015-07-07 2019-03-05 Qualcomm Incorporated Secure handling of memory caches and cached software module identities for a method to isolate software modules by means of controlled encryption key management
JP6872129B2 (ja) * 2015-11-27 2021-05-19 ソニーグループ株式会社 情報処理装置、情報処理方法、受信装置、および受信方法
FR3069935A1 (fr) * 2017-08-01 2019-02-08 Maxim Integrated Products, Inc. Dispositifs et procedes de protection de propriete intellectuelle de logiciel pour des plates-formes integrees
US10885213B2 (en) * 2017-09-12 2021-01-05 Sophos Limited Secure firewall configurations
US11151266B2 (en) * 2017-12-06 2021-10-19 International Business Machines Corporation Secure data storage and access during transition operations
US10592697B1 (en) * 2017-12-12 2020-03-17 John Almeida Virus immune computer system and method
CN108920188B (zh) * 2018-07-03 2021-04-27 中国人民解放军国防科技大学 一种扩展寄存器堆的方法及装置
KR102435253B1 (ko) * 2020-06-30 2022-08-24 에스케이하이닉스 주식회사 메모리 컨트롤러 및 그 동작 방법
US11755476B2 (en) 2020-04-13 2023-09-12 SK Hynix Inc. Memory controller, storage device including the memory controller, and method of operating the memory controller and the storage device
US20220100822A1 (en) * 2020-09-29 2022-03-31 International Business Machines Corporation Software access through heterogeneous encryption
US11409846B2 (en) * 2021-01-14 2022-08-09 Safelishare, Inc. User controlled trusted and isolated computing environments

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0383132A (ja) * 1989-08-28 1991-04-09 Fujitsu Ltd ソフトウェア保護制御方式
JP2000260121A (ja) * 1999-03-05 2000-09-22 Toshiba Corp 情報再生装置および情報記録装置
JP2001230770A (ja) * 2000-02-14 2001-08-24 Toshiba Corp マイクロプロセッサ
JP2001318787A (ja) * 2000-05-08 2001-11-16 Toshiba Corp マイクロプロセッサ、これを用いたマルチタスク実行方法、およびマルチレッド実行方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7225333B2 (en) * 1999-03-27 2007-05-29 Microsoft Corporation Secure processor architecture for use with a digital rights management (DRM) system on a computing device
US7270193B2 (en) * 2000-02-14 2007-09-18 Kabushiki Kaisha Toshiba Method and system for distributing programs using tamper resistant processor

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0383132A (ja) * 1989-08-28 1991-04-09 Fujitsu Ltd ソフトウェア保護制御方式
JP2000260121A (ja) * 1999-03-05 2000-09-22 Toshiba Corp 情報再生装置および情報記録装置
JP2001230770A (ja) * 2000-02-14 2001-08-24 Toshiba Corp マイクロプロセッサ
JP2001318787A (ja) * 2000-05-08 2001-11-16 Toshiba Corp マイクロプロセッサ、これを用いたマルチタスク実行方法、およびマルチレッド実行方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1542112A4 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008520130A (ja) * 2004-11-10 2008-06-12 エッチ セリンフレウンド、リチャード 光学的マシン固定方法およびシステム
JP2008533629A (ja) * 2005-03-21 2008-08-21 フォートレスウェア インコーポレイテッド 安全な仮想プロジェクトルームを作るための方法及びシステム
JP2007158618A (ja) * 2005-12-02 2007-06-21 Ricoh Co Ltd 画像処理装置、暗号モジュールのプロセス化方法
US8468364B2 (en) 2006-02-22 2013-06-18 Fujitsu Semiconductor Limited Secure processor
US8788840B2 (en) 2006-02-22 2014-07-22 Fujitsu Semiconductor Limited Secure processor
JP2009528596A (ja) * 2006-02-23 2009-08-06 クゥアルコム・インコーポレイテッド 信頼コードグループ
JP2009104380A (ja) * 2007-10-23 2009-05-14 Ihi Corp ロボット不正使用防止装置およびロボット不正使用防止方法
JP2015043221A (ja) * 2008-06-12 2015-03-05 メタフォリック リミテッドＭｅｔａｆｏｒｉｃ Ｌｉｍｉｔｅｄ コンピュータプログラムコードを保護する方法
JP2011181107A (ja) * 2011-06-09 2011-09-15 Fujitsu Semiconductor Ltd セキュアプロセッサ用プログラム
JP2013179453A (ja) * 2012-02-28 2013-09-09 Nippon Telegr & Teleph Corp <Ntt> 計算機システムおよび計算方法
JP2016006681A (ja) * 2013-03-31 2016-01-14 インテル・コーポレーション セキュアエンクレーブページキャッシュのための進歩したページング能力を提供するための命令および論理
WO2022085420A1 (ja) * 2020-10-19 2022-04-28 ソニーグループ株式会社 情報処理装置および方法、並びに情報処理システム
CN114785514A (zh) * 2022-03-23 2022-07-22 国网上海能源互联网研究院有限公司 一种用于工业物联化终端应用许可授权的方法及系统
CN114785514B (zh) * 2022-03-23 2023-11-14 国网上海能源互联网研究院有限公司 一种用于工业物联化终端应用许可授权的方法及系统

Also Published As

Publication number Publication date
JP4073913B2 (ja) 2008-04-09
EP1542112A4 (en) 2008-04-09
CN1668990A (zh) 2005-09-14
US20040093505A1 (en) 2004-05-13
CN100354786C (zh) 2007-12-12
EP1542112A1 (en) 2005-06-15
JPWO2004006075A1 (ja) 2005-11-04
AU2002346316A1 (en) 2004-01-23

Similar Documents

Publication Publication Date Title
JP4073913B2 (ja) 開放型汎用耐攻撃ｃｐｕ及びその応用システム
Smith et al. Building a high-performance, programmable secure coprocessor
JP4689945B2 (ja) リソースアクセス方法
JP4689946B2 (ja) 安全なデータを使用して情報処理を実行するシステム
US7516331B2 (en) Tamper-resistant trusted java virtual machine and method of using the same
US20020083318A1 (en) Method and system for software integrity control using secure hardware assist
US20050060568A1 (en) Controlling access to data
JP5636371B2 (ja) 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム
Chen et al. Certifying program execution with secure processors
US6871192B2 (en) System and method for preventing unauthorized use of protected software utilizing a portable security device
JP2015511050A (ja) プロセス作業セット隔離のための方法およびシステム
WO2003090021A2 (en) Security framework for protecting rights in computer software
CN103221961A (zh) 包括用于保护多用户敏感代码和数据的架构的方法和装置
KR100755708B1 (ko) 임시 라이센스를 사용하여 컨텐츠를 임시로 사용하는 방법및 장치
KR20200099041A (ko) 블록체인 기반 콘텐츠 이용 권한 관리 장치 및 방법
US20190044709A1 (en) Incorporating software date information into a key exchange protocol to reduce software tampering
Mana et al. A framework for secure execution of software
Carelli et al. Securing Soft IP Cores in FPGA based Reconfigurable Mobile Heterogeneous Systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004519192

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2002743883

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 20028295870

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2002743883

Country of ref document: EP