This application is based upon and claims priority from prior Japanese Patent Application No. 2007-047178, filed on Feb. 27, 2007, the entire contents of which are incorporated herein by reference.
The embodiment relates to a system having a processor, and more specifically, to a secure processor system capable of preventing an unauthorized code from being executed, a secure processor for constructing such a system, and a method of controlling a secure processor system.
In a system that uses a processor, its operation can be defined by programs, and therefore, the system is more flexible in design and operation compared to a system in which all of the components are comprised of hardware, and a variety of kinds of function can be easily realized. Due to this advantage, processors are now mounted in various computers, such as a personal computers etc., and various information devices, such as PDAs (Personal Digital Assistant), mobile phones, information home electronic appliances, etc.
In this configuration, programs are stored in a rewritable external storage medium (for example flash ROM) 6 in order for the processor to carry out desired operations. However, such a configuration is very vulnerable to an outside deciphering, for example, the physical removal of ROM 6, ie., if the internal processing program is highly sensitive, ie., management of copyright, secure processing can not be ensured in the system, and as a result, such a system cannot be realized.
As networks become more developed, information devices will more likely be connected to a network, or networks, and mail and other data will become more frequently transmitted and received via networks, and programs will also be more frequently downloaded via networks. In such circumstances, the danger of infection by a computer virus via a network etc., and unauthorized access has increased recently, and therefore, the security of programs executed by computers and mobile information terminals is more important as networks become more widely used.
Various systematic measures, such as encryption of data, user authentication, etc., are used in order to secure a robust information device comprising a processor. However, recently, the security of software and processors has become important in order to cope with the spread of computer viruses and unauthorized access, in addition to the security of systems.
For example, the connection of various processor-incorporated devices, such as mobile phones, information home electronic appliances, etc., to a network increases the possibility that these devices are exposed to the same risks as personal computers etc. Unauthorized access becomes active by the execution of an executable code with malicious intent in its terminal. Because of this, it is necessary to prevent codes with malicious intent and undesired codes from being executed in the processor. However, at present, the countermeasures on the processor side to prevent codes with malicious intent from being executed are not sufficient and there is a problem in that no safety software execution environment is provided.
In order to solve this problem, recently, a secure processor has been studied. A secure processor makes it impossible to read data directly by encrypting data handled outside the processor and providing access protection to the inside. For example, data and command codes are encrypted and stored in a main storage device or a secondary storage device and when the processor executes the command, the encrypted command codes are decrypted and stored in a cache memory, and then executed.
The present applicants have disclosed such a secure processor in Japanese Unexamined Patent Publication (Kokai) No. 2006-18528 (JP2006-18528A).
Then, between the core 11 and the encryption processing block 12, commands and data are exchanged and control of keys for encryption is carried out, and between core 11 and code authentication processing block 13, an authentication interface is provided. Further, encryption processing block 12 and code authentication processing block 13 access a main memory 17 and code authentication block 13 accesses a secondary memory 18.
In the secure processor disclosed in JP2006-18528A, the CPU unique key hold register 15 cannot be accessed from the outside. After determining a CPU unique key, the user (system manufacturer) of the secure processor notifies the manufacturer of the CPU unique key and the manufacturer sets the notified CPU unique key to CPU unique key hold register 15 when manufacturing the processor. Then, the manufacturer and the user keep the CPU unique key under strict surveillance to prevent it from leaking to the outside. The secure processor will not operate with programs other than the program correctly encrypted using the CPU unique key. Therefore, even if the program is changed with malicious intent by a third party with malicious intent who does not know the CPU unique key, it is impossible to cause the secure processor to operate in an unauthorized manner.
Although the secure processor described in JP2006-18528A is functional, the system itself as well as its hardware and software are required to be modified considerably from conventional systems. In other words, there is a problem in that it is difficult to maintain compatibility with conventional systems. When providing a very secure processor, an increase in cost of the compatibility has to be accepted to a certain degree, however, it is desired that the processor minimize the amount of modification and transitional cost from the conventional systems.
Further, as described above, it is necessary to keep the CPU unique key under strict surveillance by the manufacturer and user, however, keeping under strict surveillance requires extra expense and it is necessary for the manufacturer who keeps a number of user's CPU unique keys to keep the CPU unique key for each chip, resulting in a heavy burden. When the manufacturer has to manage a number of CPU unique keys all together, the leak out of user's CPU unique keys causes a simultaneous leak out of many keys resulting in user's systems becoming infecting with a virus. Because of this, the cost to keep the CPU unique key affects manufacturing cost and increases the price of a secure processor.
From this standpoint, it is desirable to maintain a certain security level as a secure processor even if the manufacturer and the user of the secure processor do not know each other encryption information. This not only removes the need for a manufacturer to manage a user's encryption, but also brings about an advantage of to a user that there is no longer the possibility of encryption from the manufacturer from leaking.
A first object of the embodiment is to realize the security of processor processing by the addition of minimum modules and minimize the influence on existing systems.
A second object of the embodiment is to provide items, such as unique information for each chip, which affect manufacturing cost, by a substitutive means and realize it at a low cost. Specifically, the object is to remove the need for a manufacturer and user to know the encryption information of each other and the management of the encryption information.
According to an aspect of an embodiment, a secure processor system having a secure processor having a core that executes a instruction code, an encryption key hold part that holds a processor key, and an encryption processing part that encrypts or decrypts data input/output to/from the core with the processor key, and a memory that stores the data input/output to/from the core is provided. The encryption key hold part of the secure processor having a hardware register that holds a hardwired encryption key that cannot be rewritten or read, and a write only register that stores a encryption key for instruction to be input and holds the stored encryption key for instruction so that it cannot be read. The encryption key hold part outputs the hardware encryption key held in the hardware register as the processor key when the processor is activated, and after the command encryption key is written to the write only register, outputs the command encryption key held in the write only register as the processor key.
The features and advantages of the embodiment will be more clearly understood from the following description taken in conjunction with accompanying drawings, in which:
a and 5B are diagrams showing a dataflow when creating an encryption ROM;
An embodiment is explained below with reference to the drawings.
According to the embodiment, the key transformation program is encrypted using a same key of hardware encryption key that cannot be rewritten and only the authorized key transformation program can change the processor key from the hardware encryption key to the encryption key for instruction the user sets arbitrarily. In this manner, by activating with a hardware encryption key that cannot be accessed from software and transforming it into an arbitrary encryption key for instruction, an encryption key for instruction for each user can be set without the need to use the hardware encryption key unique to the chip. In this configuration, the key transformation program, the encryption key for instruction, and the processing program are stored in the memory for encryption that provided by the user, and therefore, it is only required for the secure processor to add the encryption processing part 24 and the encryption key hold part 25 to the conventional configuration (
According to the embodiment, the manufacturer supplies only the data of the key transformation program encrypted with the hardware key to the user and it is not necessary for the user to know the hardware key itself. In addition, the user only determines a command encryption key arbitrarily and stores it in the encryption memory and it is not necessary to inform the manufacturer of the encryption key for instruction. Provided the hardware encryption key does not leak out, it is possible to ensure the correct execution of both the key transformation program encrypted with the hardware encryption key and the program encrypted with the command encryption key after being changed. Further, information about the encryption is encrypted and stored in the memory (ROM) and it is very difficult to analyze it alone.
Therefore, it is possible for the manufacturer to use a hardware key common to a plurality of users and there is no need of management because the manufacturer does not know the encryption key for instruction of each user, and thus the management of the encryption key is very easy. In addition, because the manufacturer does not know the command key, there is no possibility of the leak of the command key from the manufacturer and the user can further improve the security.
It is desirable that the encryption key for instruction (encryption setting information) 32 be RSA (Rivest Shamir Adleman). The manufacturer determines a setting information secret key and a public key for RSA encryption and supplies the public key to the user. The command encryption key (encryption setting information) 32 that the user has determined arbitrarily is encrypted with the public key for RSA encryption and stored in the memory for encryption 30. The RSA-encrypted encryption key for instruction 32 is decrypted with the setting information secret key and the decrypted encryption key for instruction is set in the write only register 27. Because the encryption key for instruction is RSA-encrypted, decryption of it is very difficult. In this configuration, the user is not likely to know the setting information secret key.
It is desirable that the encryption processing part carry out encryption and decryption using AES encryption. This is because the amount of data of the key transformation program and the control program is large and high-rate processing is required.
In contrast to this, it is desirable that the encryption key for instruction be RSA-encrypted as described above. This is because encryption and decryption of the encryption key for instruction are carried out separately, high confidentiality is required, and the target of encryption is only the encryption key for instruction and therefore the amount of data is small.
The setting information secret key can be stored in the secure processor; however, it may also be possible to add it to the key transformation program and supply the data from the manufacturer to the user, which is the key transformation program including the setting information secret key encrypted with the hardware encryption key. Because the setting information decryption key is encrypted, the user cannot know the setting information decryption key also in this case. The user stores the key transformation program including the setting information decryption key in the memory. When the secure processor is activated, the key transformation program is decrypted with the hardware encryption key as described above, and therefore, the setting information decryption key is extracted therefrom and the RSA-encrypted command encryption key is decrypted.
Further, it may also be possible to store the electronic signature generated by the user. The program to verify the electronic signature may be provided in the secure processor 20 or in the memory for encryption 30. In this configuration, the creator (user) of the program encrypted with the encryption key for instruction creates a signature public (verification) key in advance and informs the manufacturer of it, and the electronic signature created by the creator (user) of the program is verified with the signature public key and thereby the function of confirming the validity of the program encrypted with the encryption key for instruction can be added. The signature public key is for verifying the electronic signature and even if the signature public key leaks out, it is not possible to generate an authorized signature using the key. When the command public key leaks out, it is possible to create an unauthorized program using an unauthorized key, however, unauthorized execution can be prevented by the signature verification.
It is desirable that the electronic signature be carried out by the RSA scheme for the same reason as that for the command encryption key.
The signature public key is an encryption key the user sets independently and if it is stored in the secure processor, the need arises to manufacture the secure processor for each user, and this is undesirable. Therefore, it is desirable that the signature public key also be encrypted with the hardwired key in the key transformation program and stored.
The manufacturer informs the user of the setting information public key and the user informs the manufacturer of the signature public key, and the manufacturer supplies to the user the data, which is encrypted by the hardwired encryption key and contains the key transformation program including the setting information secret key and the signature public key. The user creates ROM data by combining the encrypted data with the encryption key for instruction encrypted with the setting information public key, the electronic signature, and the control program encrypted with the command encryption key. Because the data supplied to the user from the manufacturer is encrypted, the user cannot know the setting information secret key. In addition, the manufacturer cannot know the signature secret key the user has determined.
In the configuration in which an electronic signature is verified, it may also be possible to provide a function of connecting the connection detection signal of the debugger to the encryption processing part and terminating the command decryption processing when the debugger is detected. Due to this, it is possible to protect the program from the attack using the fact that the command decrypted for execution exists in the CPU core 21 and in this state, the information in the CPU core 21 is taken out using the debugger.
Further, in the extraction (decryption) processing of the encryption key for instruction, the authentication of the authorized user authentication code may be included in addition to the processing of the encryption key for instruction. In this configuration, it is possible to add the function of determining an authorized user by, after adding an authorized user authentication code to the encryption key for instruction that only the creator of the program encrypted with the encryption key for instruction can set, carrying out encryption of the public key in the RSA scheme, and storing the authorized user authentication code in the register.
Further, it may also be possible to provide a register capable of being accessed by the debugger and of storing a value to be compared with the authorized user authentication code and a function of canceling the decryption termination processing when the value matches with the authorized user code. In this configuration, it is possible to provide an environment that can be used even when the debugger is connected only to the creator of the program encrypted with the encryption key for instruction.
The above configuration may be such that the (built-in) ROM 23 connected to the processor core 21 without the interposition of the encryption processing means 24 and which records a program for determining the encryption state of the memory for encryption 30 is provided. In this configuration, the built-in ROM 23 includes the encryption state determination program and thereby verification whether the memory for encryption ROM 30 is mounted is enabled, and at the same time, the processor configuration may be made common to both purposes of encryption and non-encryption.
Further, it is desirable that the memory for encryption 30 is a nonvolatile memory that can be rewritten, such as a flash ROM etc., and the memory for encryption 30 is provided inside or outside the secure processor 20. In this configuration, it is possible to easily change the activation settings using external data by describing the identifier of encryption state in a specific region of the external memory because whether or not it is an encryption program can be determined.
Further, the hardware register 26 that stores the hardwired encryption key can store, for example, a plurality of hardwired encryption keys and may have a configuration in which arbitrary key can be selected from among the plurality of keys. In this configuration, a plurality of hardwired encryption keys can be selected with arbitrary numbers and it is possible to continue the manufacture of the secure processor by selecting a new number when the hardwired encryption key leaks out.
According to the embodiment, the encryption key of the secure processor is transformed from a hardwired encryption key that cannot be rewritten into an encryption key for instruction which the user arbitrarily determines with a key transformation program encrypted with the hardware encryption key, and therefore, it is possible for the user to set the encryption key of the secure processor independently without the need to inform the manufacturer and the maintenance of the secret of the encryption key is easy. In addition, the key transformation program and the encryption key for instruction can be stored in the external memory and it is possible to realize a configuration that can be easily added to a general processor while modules to be added to the processor are minimized and production cost is kept low by integrating the transformation of the hardwired encryption key into an arbitrary key and the encryption processing hardware into a single block.
Further, if the command encryption key is RSA-encrypted, it is difficult to know the command encryption key from the outside and the keeping of the secret of the command encryption key is put under stricter surveillance.
Furthermore, authentication of a program is carried out with an electronic signature and the command encryption key is prevented from being set when any falsification is detected, thereby the security and reliability of the system including the secure processor can be further improved.
The external ROM 34 includes, for example, a rewritable flash ROM etc., and internally stores a ROM header (Encrypted ROM Identifier) 41, a key transformation program 43, RSA-encrypted data 49, and a control program 54. The ROM header (Encrypted ROM Identifier) has header data 42. The key transformation program 43 has AES-encrypted data 44. The AES-encrypted data 44 has a key transformation program 45 AES-encrypted with a hardwired encryption key and the key transformation program 45 AES-encrypted with the hardwired encryption key has a key transformation program main body 46, a second RSA public key 47, and a first RSA secret key 48. The RSA-encrypted data 49 has first RSA-encrypted data 50 and second RSA-encrypted data 52, and the first RSA-encrypted data 50 has encryption setting information 51 and the second RSA-encrypted data 52 has authentication-related information 53. The first RAS-encrypted data 50 and the second RSA-encrypted data 52 are encrypted with different encryption keys. The control program 54 has AES-encrypted data 55 AES-encrypted with the command encryption key and an AES-encrypted control program 56 is included therein. The AES-encrypted control program 56 has a control program main body 57 and other user data 58.
In the encryption processing part 24, with the processor key output from the encryption key hold part 25, the data in the direction of output is AES-encrypted and the data in the direction of input is subjected to the AES decryption processing, respectively. Because of this, the data in the external ROM is encrypted. In the present embodiment, the hardware encryption key inside the chip of the secure processor 20 is not different from each another and is commonly used for chips, and thus reduction in manufacturing costs can be achieved. According to this constitution, the key is common to the users of the processor and although it is possible to prevent deciphering by a third party, the secret information between users cannot be protected. In the present embodiment, therefore, the hardware encryption key of the chip is used only for encrypting a key transformation program created by the manufacturer and the hardwired encryption key information is not distributed to anyone except for the manufacturer.
The manufacturer of the chip of the secure processor 20 selects one from among a plurality of (HW) hardwired encryption keys (D1) and determines a hardwired (HW) encryption key 61 for AES encryption common to each chip, and the hardware encryption key 61 is kept under strict surveillance so as not to be leaked to the outside. In addition, the manufacturer prepares the key transformation program main body 46 that stores a command key read from the external ROM 34 in the writable ROM 27. Further, the manufacturer determines a setting information encryption key 62 including a first RSA secret key 63 and a first RSA public key 64, and the first RAS secret key 63 is kept under strict surveillance so as not to be leaked to the outside and the first RSA public key 64 is supplied to the user.
On the other hand, the user generates the encryption setting information 51 including a command encryption key 60 for AES encryption and the control program 53. Further, the user determines a signature key 65 including a second RSA secret key 66 and a second RSA public (verification) key 67, and the second RSA secret key 66 is kept under strict surveillance so as not to be leaked to the outside and the second RSA public key 67 is supplied to the manufacturer.
The manufacturer generates a counter value (D2) in a CTR mode of which program size corresponds to the selected hardware encryption key. This is encrypted in an ECB mode (D3) and encrypted counter data (D4) is generated. Then, the data integrating the key transformation program main body 46, the first RSA secret key 63, and the first RSA public key 67 supplied from the user is AES-encrypted with the hardware encryption key 61 in an encryption tool 68. Specifically, encryption processing is completed by calculating the exclusive-OR (XOR) (D8) of the data and the data of the key transformation program (D5) and thus the encrypted key transformation program 43 is generated. The key transformation program 43 is generated for each user. Then, the ROM header 41 created based on the HW key number that specifies the used hardware encryption key is combined with the key transformation program 43 AES-encrypted in the encryption tool 68, and supplied to the user as program data. The key transformation program 43 includes first RSA secret key 63 and second RSA public key 67 in the AES-encrypted form.
The user creates RSA-encrypted encryption setting information 75 by RSA-encrypting the encryption setting information 51 including the encryption key for instruction 60 for AES encryption with the first RSA public key 64 in an RSA encryption part 72. Further, an electronic signature 76 is created by RSA-encrypting data, which is hash-processed RSA-encrypted encryption setting information 75 with the second RSA secret key 66 in a signature generation part 73. Then, in an AES encryption part 74, a control program 77 AES-encrypted with the encryption key for instruction 60 is created using the encryption key for instruction 60 by encrypting, as D14, D15, and D16, using the counter data and the command encryption key included in the information and subjecting them to the XOR (D18) operation with the data D17 of the control program. The above processing is carried out using an encrypted data creating tool 71. Then, the RSA-encrypted encryption setting information 75, the electronic signature 76, and the AES-encrypted control program 77 created as above are combined with the program data including the ROM head 41 and the key transformation program 43 supplied from the manufacturer and written to the external ROM 34. In this manner, the external ROM is completed.
In steps S21 and S22, the second RSA public key 68 for signature verification is supplied from the user side to the manufacturer side and the manufacturer obtains the second RSA public key 67. In other words, the exchange of the second RSA public key 67 is carried out.
In steps S13 and S23, the first RSA public key 64 for encryption setting information is supplied from the manufacturer side to the user side and the user obtains the first RSA public key 64. In other words, the exchange of the first RSA public key 64 is carried out.
On the manufacturer side, in step S14, encrypted binary data, which is the AES-encrypted data including the key transformation program 46, the first RSA secret key 63, and the second RSA public key 67, is generated. The encrypted binary data cannot be decrypted on the user side.
On the other hand, the user side creates setting information and RSA-encrypts it with the first RSA public key 64 obtained from the manufacturer, and creates a control program and encrypts it with the command encryption key, and further generates an electronic signature in step S24.
In step S15, the manufacturer supplies the encrypted binary data generated in step S14 to the user and the user can obtain the encrypted binary data.
In step S25, the user creates the external ROM 34 by combining the obtained encrypted binary data, the encrypted setting information created in step S24, the encrypted control program, and the electronic signature.
Then, the user manufactures a system by combining the secure processor supplied from the manufacturer, the external ROM 34 created as described above, and other components.
As described above, only the second RSA public key for signature verification is supplied to the manufacture from the user, and therefore, it is not likely that the manufacturer can obtain the command encryption key the user has determined independently. In addition, only the first RSA public key for encrypting setting information and the encrypted binary data are supplied to the user from the manufacturer, and therefore, it is not likely that the user can obtain the hardware key and the first RSA secret key the manufacturer has determined independently.
There may be the case where it is necessary to modify the control program for some reason on the user side after the external ROM for encryption is created as shown in
In step S31, the user creates a new control program and AES-encrypts it with the encryption key for instruction, and RSA-encrypts it with the first RSA public key 64 created previously and combines it with the setting information and the electronic signature, and creates the external ROM by combining it with the encrypted binary data supplied previously from the manufacturer in step S32.
The encrypted data stored in the external memory 34 for encryption is described as above. Because the stored contents of the external ROM 34 consist of three parts and each of them is encrypted, it is possible to construct a structure that cannot be deciphered by third parties or the users of the processor. Although the common key encryption processing of the processor key (the hardwired key and the encryption key) is described with the AES system as a representative system and the public key encryption system for encrypting setting information and authenticating signature is described with the RSA system as a representative system, any equivalent system may be used. The encryption key for instruction for encrypting the control program created by the user is encrypted with the first RSA public key; however, in the RSA encryption system, the public key differs from the secret (decryption) key, and therefore, it is not likely that the user will know the secret key even if the public key is revealed to the user, and the user alone can encrypt the command encryption key for the defined control program. Due to this, the user can carry out encryption of the program without explicitly notifying the command encryption key, which is confidential information, to the manufacturer.
Next, the internal configuration of the secure processor 20 that processes such encryption data will be explained below. First, the basic operations of the secure processor 20 will be explained. The secure processor 20 executes the key transformation program 43 encrypted with the hardwired encryption key 61 stored in the ROM 26 in the chip while decrypting it by the encryption processing part 24 supplied with the in-chip hardwired encryption key, and in the key transformation program 43, the encryption key for instruction 60 for the control program encrypted with the first RSA public key 64 is extracted and is set in the writable ROM 27. Due to this, the encryption processing part 24 is set so that it encrypts and decrypts with the encryption key for instruction 60. In this manner, key transformation is carried out so that the control program 54 created by the user of the secure processor 20 can be decrypted correctly. After the key transformation, the encryption processing part 24 decrypts the encrypted control program 54 and thus correct execution is enabled.
Next, the dataflow in the encryption processing part 24 will be explained. When the read of the external ROM 34 from the CPU core 21 and decryption processing are carried out, the setting of the processor key information is done in advance. When the key transformation program described above is executed for the encryption key hold part 25, the setting is not necessary, or a HW key number that specifies which key is selected from among several keys is set. Similarly, in the encryption determination part 86, information on whether the target address is encrypted is set in the encryption determination part 86. After these settings, a read command for the external ROM 34 is transmitted from the CPU core 21 to the encryption processing part 24 via the internal bus 22. The bus determination part 85 transmits the determination direction whether it is the target of encryption and the key setting direction, respectively, to the encryption determination part 86 and the encryption key hold part 25 and each block transmits the encryption determination result and the key information to the common key arithmetic unit 87. The common key arithmetic unit part 87 carries out decryption processing of the information based on the address information based on the information and the activation signal from the bus determination part 85. After the decryption processing, the operation result is transmitted to the completion determination of decryption processing part 88. In parallel with this, a read command is issued to the external ROM 34 via the bypass control part 84 and the external address/command bus. As a result of this command, data is received from the external ROM 34 after a fixed time elapses, and in the completion determination of decryption processing part 88, and after the processing of the data of the external ROM 34 and the processor key operation processing are synchronized with each other, the operation is carried out and the result is returned to the CPU core 21 via the processing bus and the internal bus. The operation in the completion determination of decryption processing part 88 is carried out in the CTR mode.
The encryption determination part 86 has a decryption activation register 91, a debugger detector circuit 92, an authorized user authentication data hold part 93, an authentication comparison value hold part 94, a comparator 95 that compares the value of the authorized user authentication data hold part 93 with the value of the authentication comparison value hold part 94, a descramble register 96, an encryption region specifying register 97, and a decryption operation control part 98. These are described later.
When power is turned on in step S41, the activation program recorded in the built-in ROM 23 is processed. In step S42, the program in the built-in ROM 23 first reads the header data 42 in the external ROM 34. In the header data 42, information as to whether or not it is an encryption ROM and information about the arrangement of each data when it is an encryption ROM are recorded in plain text as described in the ROM header 41 in
Subsequently, in step S45, the memory decryption function is activated by setting it to the decryption activation register 91. This brings about a state in which read is possible while decrypting the data in the external ROM 34. After that, the program branches into the key transformation program 43. The key transformation program 43 is a program created by the chip manufacturer and encrypted with the hardwired encryption key specified by the encryption key number described above. After branching, the program starts the processing of the key transformation. In the key transformation processing, first in step S46, the RSA-encrypted data part is read and decrypted. The RSA-encrypted data part includes the encryption setting information 51, which is information about hardware setting encrypted in the RSA scheme, and the authentication-related information 53, which is the information 51 subjected to the electronic signature. The verification key (the second RSA public key) for signature verification and the RSA secret key (the first RSA secret key) for decryption are held in advance in the key transformation program 43 as described above.
The signature part of the RSA-encrypted data part read in step S45 is first verified. In step S46, the verification result is determined and if it is determined that the signature has been falsified, the procedure proceeds to step S47 and error processing, that is, execution stop processing is carried out. When not changed with malicious intent, the RSA-encrypted data part in the external ROM 34 is read in step S48 and the encryption setting information 51 is decrypted from the RSA-encoded data part in step S49. The encryption setting information 51 includes an authorized user authentication code, encryption region specification, encryption counter, and command encryption key, and after inverse transformation processing D10 is carried out by hardware based on the information, each data is reflected in the hardware. When the ROM data is created, the encryption setting information 51 is generated through the scramble processing D10 and the RSA encryption processing D11 in
Returning to
The embodiment provides a secure processor capable of ensuring the security of the operation in the form that can be added easily to already existing systems.
The embodiment can be applied to a secure processor in which data to be input/output to/from the CPU core is encrypted.
Number | Date | Country | Kind |
---|---|---|---|
2007-047178 | Feb 2007 | JP | national |