JP2002526822A - Apparatus for providing a security processing environment - Google Patents

Abstract

(57) Abstract An apparatus for providing a secure processing environment is disclosed. In one embodiment, the device includes a read / write memory for storing the encrypted information. It also includes a processor, an encryption device and an authentication device. The encryption device is in communication with the read / write memory and is configured to receive encrypted information therefrom and convert the encrypted information into decrypted information. Is returned to memory for subsequent use by the processor. The authentication device authenticates the decrypted information before it is used by the processor, and authenticates this information again before the encryption device encrypts it again.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to the security of programmed devices, and in particular,
Apparatus for providing a secure environment for processing confidential data and / or confidential program steps such as software.

[Prior art]

The price of data and / or programmed instructions (eg, software) often depends on the general availability of the interested public. For example, if information in the form of data or programmed instructions is made available free of charge on the Internet, few people pay for what is readily available for free, so the market price of that information is Plummets to zero. Accordingly, it has long been known to be desirable to maintain security of data and / or programmed instructions for all but the purchaser who paid for sensitive information.

There are a number of situations where the concept of value derived from information by limiting access to the information is exploited. For example, it is based on the premise that conditional access broadcast networks such as cable television networks, and in recent years direct satellite broadcast networks restrict access to broadcasted information to paying subscribers. Recently, the idea of restricting access to broadcast data has been raised by Hugh Network Systems, Inc.
The C (TM) product has been extended to the computer networking context. The DirectPC (trade name) product broadcasts the requested information via a satellite to the requesting computer device (typically, a personal computer) as a means for promoting information distribution from the Internet.

[0003] Most such broadcast systems use one or more encryption techniques to control access to the broadcasted information. For example, most of such systems use one or more keys to encrypt broadcast data based on a mathematical algorithm, and this mathematical algorithm uses Without knowledge of the keys used, unless you spend a considerable amount of time,
Decryption of the data has been very difficult. Here, the literature (Schneier, Applied Cryptography, (Second Ed. 1996)) in which the entire literature is referred to is a data encryption standard (Frequently used for encrypting broadcast information). A description of many such cryptographic techniques is included, including a description of the (DES) algorithm.

[0004] The need to protect information security is not limited to the broadcast environment alone. For example, from a commercial perspective, there are many applications where it is important to maintain the confidentiality of information because it is processed locally by a personal computer. For example,
In some applications, it is desirable to allow processing of sensitive data while maintaining the security of that data with respect to the outside world. This is merely an example and is not limiting. To give another example, in some instances, secure execution of a programmed instruction (eg, software) within a processor may prevent access to the decrypted instruction itself from outside the processor. Preferably it is possible.

[0005] Various devices have been developed for maintaining information security. However, the confidential information protected by these devices is often of very high commercial value, and is often used by intrusion techniques (sub), commonly referred to as "hackers".
-culture) is also evolving. These individuals have taken the commercial value of confidential information
They spend a significant amount of time trying to break or “hack” the security measures of these devices. Hackers have varying degrees of success in performing these actions. Therefore, there is a need for an improved and more flexible apparatus for providing a secure environment for information processing that provides a higher level of security for hackers than known devices. Further, there is a need for a device that overcomes the memory limitations inherent in sensitive devices and whose software can be upgraded in the field.

[0006] It is a well-known assumption of generally accepted cryptography that confidentiality must exist entirely within the key of the system. In other words, for a device that is considered confidential, it must be impossible for an attacker who has access to all information about the system except the key to decrypt the encrypted information in a reasonable amount of time. Therefore, key material security is of paramount importance in devices that provide a secure environment.

[0007] Thus, in general, devices for at least one of encrypting, decrypting, and maintaining the security of information comprise a type of sensitive memory that stores keying material and other possibly highly sensitive data. Contains. To control access to the keying material, it is often required to restrict access to the sensitive memory to trusted software and / or hardware components. In particular, it is often necessary to limit the times, persons, and environments in which the memory storing the key material can be addressed.

[Problems to be solved by the invention]

One problem with restricting access to memory is that it can be tested. Another problem is to limit access to field deployment units while still allowing initial programming at the factory. It is often required to have full read / write access to the memory to check that the memory is working properly before releasing the device into the field. Further, such access typically must occur after the device is fully or almost fully configured. As a result, such devices often include a test mode, in which the device determines that it is in test mode when a certain state or event occurs, and allows full read / write access to the memory. If a hacker can trick a device containing key material and put it into test mode, it will have decent access to the stored key material, thereby completely jeopardizing the security of the device .

In some prior art methods, one or more mode bits stored in a memory, or an anti-fuse device, etc., indicate whether the memory contains sensitive data, and whether the memory is in a test mode. At least one of them is specified. This mode bit may be configured as a simple checksum on the data in memory. In other words, the mode bits may be set equal to some data stored in memory or some mathematical function of all data. Using any of the traditional methods for defining mode bits, if a hacker changes the state of the mode bits, it is possible to put the memory into a test mode, whereby the key material that the memory contains Is completely at risk. Thus, there is provided an improved method and apparatus for determining and determining whether sensitive memory is contained in the memory, independent of the mode bits stored in the memory or the checksum value stored in the memory. It is desirable.

[Means for Solving the Problems]

According to a feature of the present invention, there is provided an apparatus for providing a secure processing environment. The apparatus communicates with a read / write memory for storing information, a first processor for cooperating with the read / write memory, reading information therefrom and writing information thereto, and a read / write memory. Encryption device. The encryption device selectively decrypts the encrypted information to generate decrypted information and provides the decrypted information to a read / write memory for subsequent use by a first processor. It is configured to Further, the device includes an authentication device that authenticates the decrypted information before the processor uses it.

In some embodiments, the authentication device re-authenticates the decrypted information received from the read / write memory, and the encryption device converts the decrypted re-authenticated information into the re-encrypted information. It is configured to selectively encrypt. In such embodiments, the encryption device optionally reads / re-encrypts the re-encrypted information.
It may be returned to the write memory and subsequently exported to the storage device, or optionally directly again to the encrypted information. Also, in such an embodiment, the encryption device may re-encrypt the decrypted re-authenticated information, thus resulting in a mask different from the original encrypted form such that it masks the modified information. Is preferred. In such embodiments, the encryption device uses key cycling and / or whitening key cycling to mask the modification information.

In some embodiments, the authentication data used to re-authenticate the decrypted information before re-encrypting it is read / write memory for later use in authenticating the decrypted information. Is stored.

[0011] In some embodiments, the first processor has a kernel (core) operating mode and a user operating mode, wherein the kernel mode and the user mode define separate security cells. In such an embodiment, the first processor preferably executes the non-secure software in the user operation mode and executes the confidential software in the kernel operation mode.

[0012] In some embodiments, the apparatus comprises a second processor. The second processor communicates with the encryption device and the read / write memory, thereby initiating selective decryption and re-encryption of the information stored in the read / write memory. In some such embodiments, the encryption device includes an authentication device.

In some embodiments, the apparatus further comprises a non-volatile memory, and logic for controlling access to data contained in the non-volatile memory, wherein the logic is non-volatile memory And selectively analyzing the properties unique to the accessed data to determine whether the data contained in the non-volatile memory contains confidential data. In some such embodiments, the logic circuit identifies data blocks in the accessed data having predetermined characteristics, counts the identified data blocks, and thresholds the count. By comparing with the value, it is determined whether or not the data contained in the non-volatile memory includes confidential data. In some such embodiments, each data block includes a bit and the predetermined property may include a predefined logic state. Alternatively, each data block may include a plurality of bits and the predetermined property may include a binary value falling within a range of binary values.

In some embodiments using non-volatile memory as described above, a key separation circuit is provided that connects the logic circuit directly to the encryption device. In some such embodiments, the non-volatile memory stores the key, and a key separation circuit supplies the key to the encryption device. In any of the above embodiments, a logic circuit,
The key separation circuit and the encryption device preferably define a closed system.

[0015] In some embodiments, the non-volatile memory, the first processor, the read / write memory, and the encryption device are embedded on an integrated circuit. In such embodiments, the integrated circuit includes pins for connecting the device to an external device, and the device selectively uses the pins to avoid exposing sensitive information outside a secure environment. It further includes at least one of a silencing circuit for disabling (disabled) and a watchdog circuit configured to monitor the integrated circuit for tampering.

In some embodiments, the apparatus includes a memory management device for maintaining a plurality of security cells in cooperation with the first processor.

In some embodiments, the encryption device includes an encryption module.

In any of the above embodiments, authentication may be performed by authenticating the encrypted information before decryption.

In any of the above embodiments, the encrypted information may include encrypted processor instructions and / or encrypted data.

[0020] In any of the above embodiments, the encrypted information may be segmented into sections. In such embodiments, the segments are preferably independently encrypted and authenticated.

According to another feature of the present invention, an integrated circuit for providing a secure processing environment is provided for use by an external memory. The device includes a volatile memory having a storage capacity less than the storage capacity of the external memory. The apparatus includes an import / export means for selectively importing and exporting encrypted information between an external memory and a volatile memory, and encrypted information received from the volatile memory in a secure environment. To generate decrypted information by decrypting the decrypted information, and encrypting the decrypted information again in the confidentiality environment to obtain encrypted information. Further, the apparatus includes a processor for processing the decrypted information in the secure environment. The processor cooperates with the import / export means to selectively import and export the decrypted information between the external memory and the volatile memory to avoid exceeding the second storage capacity.

In some embodiments, the encryption means has a first form if the encrypted information corresponding to the decrypted information was imported from an external memory, and the external memory If the corresponding decrypted information remains unchanged, the information is encrypted to have a second form different from the first form. In some such embodiments, the encryption means comprises:
Decrypting the encrypted information using the first whitening key and encrypting the decrypted information using a second whitening key different from the first whitening key. In some such embodiments, the apparatus comprises a cryptographically strong pseudo-random number generator that generates the second whitening key.

In some embodiments, the device comprises means for authenticating the decrypted information in a secure environment. In some such embodiments, the means for authenticating authenticates the information decrypted after importing from the external memory and re-authenticates the decrypted information before encrypting and exporting to the external memory.

According to one aspect of the present invention, there is provided a method of tamper checking an integrated circuit to perform a secure operation. The method performs a built-in self-test on one or more elements of the integrated circuit to detect an event and determine whether a tamper has occurred, and if the built-in self-test indicates that a tamper has occurred. Includes imposing restrictions on one or more operations of the integrated circuit.

In some embodiments, the method also includes maintaining the processor associated with the integrated circuit in a reset state such that the predefined memory storing the key material cannot be accessed. Releasing the processor from the reset state if any of the elements pass the built-in self-test and holding the processor in the reset state if one or more elements fail the built-in self-test.
In some such embodiments, the one or more elements include predefined memory and / or logic circuits.

In any of the above embodiments, the detected event may include a reset event.

BEST MODE FOR CARRYING OUT THE INVENTION

Other features and advantages are inherent in the device as claimed and disclosed and will become apparent to those skilled in the art from the following detailed description and the accompanying drawings. FIG. 1 schematically illustrates an apparatus 10 constructed in accordance with the teachings of the present invention in one available environment, i.e., on a DirectPC ™ module 12 used in a personal computer (not shown). Is shown in As will be described in more detail below, device 10 is configured to provide a secure environment for processing sensitive information. The term "information" as used consistently in this description and the appended claims refers to data, programmed instructions (e.g., software, firmware), or both. Although the device 10 can be used in a DirectPC ™ product, those skilled in the art will appreciate that the device 10 is not limited to use in any particular environment or for any particular application. . Conversely, the depicted apparatus 10 can be used in any application or environment that benefits from the increased processing security it provides without departing from the scope of the present invention. . For example, it is particularly useful in smart card applications. Further, while device 10 is shown in FIG. 1 as being configured as an application specific integrated circuit (ASIC), those skilled in the art will readily recognize that device 10 need not be configured as an integrated circuit. There will be.

As described below, the device 10 shown is a secure environment in which sensitive information content can be decrypted, processed, and re-encrypted without being exposed outside the device 10. Is configured to provide. (Used here “
"Decrypted" means that one or more encryption layers have been removed. As will be appreciated by those skilled in the art, "decrypted information" as used herein is optionally still encrypted. But may be one or more steps closer to a completely decrypted form, for example, the VersaCrypt environment introduces another cryptosystem, such as encrypted RSA decrypted data. Or in the course of being decrypted according to another cryptosystem.) In one aspect, the device 10 shown is exposed outside a confidential environment where sensitive information is secured. In some cases, this security is achieved by ensuring that it is always encrypted, and whenever decrypted sensitive information is available on the device 10, it can be implemented by an external device. Security means are operated to prevent access to the device 10.

In some applications, it is, of course, desirable to export the decrypted information from device 10 while maintaining the confidentiality of the process and keys used to decrypt the information. For example, in a software metering application used to meter access to a database, it is desirable to provide the decrypted content of the database to authorized users once they have been properly charged.
In such an application, device 10 provides a secure environment for decryption of data hiding the keying material used and processes performed during decryption.

While the device 10 shown is very effective in conditional data access applications such as television subscriber broadcasting systems, the maximum capabilities of the device 10 are more complete in conditional software access applications. Used for In such an application, the device 10 shown decrypts, executes, and re-encrypts sensitive software (or firmware) information without exposing the decrypted instructions to outside the secure environment. can do. The encrypted software (or firmware) may optionally be stored on the device 10 or may be stored external to the device 10 due to memory constraints, and may be selectively stored on the device 10 as needed. May be imported (collectively or in segments). In either case, as described below, because the device 10 shown has a large on-board processing capacity, execution of the decrypted software (or firmware) can be performed in a completely secure environment. Can be done. As a result, sensitive software (or firmware) may be easily modified or pirated for use by unauthorized entities or to induce non-conformant behavior. Can not.

Execution of the encrypted software (or firmware) causes the device 10
Outputs information to an external device (eg, monitor, printer, storage device, etc.) in a form that can be read by a user, but the software that generates the output information is typically stored in a secure environment provided by device 10. Not exposed to the outside (of course, without instructions in software (or firmware) executed to export instructions in decrypted form). Thus, software (or firmware) security is always maintained by the device 10 shown.
As explained below, the valid result of this feature of the device 10 shown is that the licensed software (e.g., based on usage that is tailored to the amount of time the software (or firmware) is actually used) Firmware (or firmware) can perform software (or firmware) metering that can be charged. For example, the depicted apparatus 10 can be configured to monitor the amount of time that any portion of the software (or firmware) is maintained in a decrypted form. The data collected by this monitoring can be used to charge a license fee for software (or firmware) use. This method of licensing software (or firmware) contrasts sharply with the traditional method, where one-time licensing fees are charged without upgrades.

To store programmed instructions that define some of the operations of the device 10 (ie, a “secured kernel”), the device 10 stores the non-volatile memory 14 (FIG. 2).
). The secured kernel is responsible for managing resources within the device 10. It enforces many of the security restrictions described below. Although the codes stored in non-volatile memory 14 are preferably unencrypted, those skilled in the art will recognize that encrypted information (eg, data or programmed instructions) may be stored without departing from the scope of the present invention. It will be appreciated that it can be stored in non-volatile memory 14. It is understood that non-volatile memory 14 can be configured in a number of ways without departing from the scope of the present invention, however, in the preferred embodiment, a read only memory (ROM) storing programmed instructions. It is constituted by. As will be described below, the device 10 can be individually encrypted Versacrypt (V) encrypted using a triple key with whitening, Triple DES-CBC.
ersaCrypt) Runs secure software that is preferably segmented into applets.

To process information and control the operation of the device 10, the device 10 includes a processor 16 (see FIG. 2). As described in further detail below, one of the processors 16
One function is to implement more than one security cell. The first of the security cells, referred to herein as kernel mode cells, is implemented whenever sensitive sensitive information is accessed, processed, and made available on the internal bus of device 10. Preferably. The second security cell is referred to herein as a user mode cell and is implemented when access to sensitive data is not allowed. When kernel mode is enabled, processor 16
It places no restrictions on access to hardware and software resources within. It also prevents external pins of the device 10 from exposing sensitive information indicating at least one of the operation being performed by the device 10 and the information being processed by the device 10, as described below. When the user mode is implemented, the processor 16 imposes an increased level of restriction on the operation within the device 10;
There are no restrictions on what is externally visible. However, as described below, certain hardware implementation restrictions are preferably maintained in both security cells.

The device 10 further comprises a volatile read / write memory 18 for temporarily storing information to be processed by the device 10. The read / write memory 18 is addressable by the processor 16 so that the processor 16 can both read information contained in the memory 18 and write information to the memory 18 as needed. is there. As will be described in detail below, in operation, the encrypted information to be processed by the device 10 is first stored in a read / write memory.
Written on 18. Thus, in one role, read / write memory 18 functions as a storage area for encrypted information.

In order to perform the encryption function, the device 10 comprises an encryption means for decrypting the encrypted information into decrypted information and re-encrypting the decrypted information into encrypted information. I have it. Both of these functions are performed in a secure environment.
As will be appreciated by those skilled in the art, the encryption means may be configured in many different ways without departing from the scope of the present invention. For example, the encryption means can be constituted by an encryption device 20, such as a dedicated hardware circuit or a processor executing software or firmware. Further, those skilled in the art will appreciate that encryption device 20 may be configured to perform at least one of a variety of well-known encryption techniques and algorithms without departing from the scope of the present invention. Will do. In this preferred embodiment, the encryption device 20 is constituted by a dedicated hardware circuit 20, here called an encryption module, which, depending on the requirements of the application, (1) triple key, triple DES- CBC encryption and decryption (triple key, triple data encryption standard / electronic codebook mode encryption / decryption), (2) triple key, triple DES external CBC (triple key, triple data encryption by external encryption block chaining) (Standard) encryption and decryption, and (3) DVB (Digital Video Broadcasting) descrambling.

As shown in FIG. 2, the encryption device 20 is in communication with the read / write memory 18. In operation, the encrypted information written to the read / write memory 18 is transferred to the encryption device 20 for decryption as needed. Thereafter, the decrypted information is written from encryption device 20 to read / write memory 18 for subsequent use by processor 16.

In order to prevent hackers from modifying the code or sensitive data to what they intended, the encryption device 20 may be used until the decrypted information is authenticated.
It is important that the information decrypted by the processor 16 is not allowed to be processed by the processor 16. Therefore, the device 10 includes the authentication device 22. Although it will be appreciated by those skilled in the art that the authentication device 22 can use any of a large number of authentication algorithms to authenticate the decrypted information, in the preferred embodiment, Uses a secret key to authenticate the information in C
Perform BC-MAC (Encrypted Block Chain Message Authentication Code) algorithm. As will be appreciated by those skilled in the art, such authentication requires the expected MAC value information for each section of encrypted information that must be separately authenticated. As further described below, in a preferred embodiment,
The requested MAC value may be read at start-up read / write memory 18 while another load time scheme may be used without departing from the scope of the present invention.
Will be imported to The authentication device uses the MAC value from memory 18 to perform CBC-MAC authentication on all decrypted information prior to use by processor 16.

The contents of the read / write memory 18 may have been updated by the processor 16 or another means during the execution of the VersaCrypt applet. If the decrypted information has been re-encrypted and exported (as described below), the authenticator 22 replaces the decrypted information currently present in the read / write memory 18 with the new information for that information block. It is important to re-authenticate by generating a CBC-MAC value. The new CBC-MAC value is written to read / write memory 18 for subsequent use in authenticating the information block if the information needs to be decrypted and reused in the future. Re-authentication is necessary, at least in some examples, for processor 16 to change the content of the information decrypted during processing. Due to the change in the content of the decrypted information, the information block will have (with a high probability) different CBC-MAC values,
If the CBC-MAC value is not updated by re-authentication, the authentication device 22 cannot authenticate the information if a call to the updated information is needed in the future.
As will be appreciated by those skilled in the art, there are many possible ways to confirm that the certified version is in fact the most recent exported version. Any other such verification method can be used without departing from the scope of the present invention.

After re-authentication, the encryption device 20 re-encrypts the decrypted and authenticated information in the read / write memory 18 into re-encrypted information.

As will be appreciated by those skilled in the art, in many applications, the amount of encrypted information to be processed by the device 10 will exceed the internal memory capacity of the device 10. To enable device 10 to operate in such an environment, device 10 selectively imports and exports encrypted information between an external device, such as memory 24, and read / write memory 18. Import / export means for the user. However, those skilled in the art will recognize that the encrypted information may be transmitted by a run or one network connection to a hard drive or another storage medium or communication device via an internal bus in the system without departing from the scope of the present invention. It will be appreciated that it can be imported and exported. External memory 24
Is preferably larger than the storage capacity of the read / write memory 18. Import / export means cooperates with processor 16 to import encrypted blocks of information from external memory 24 as needed. When the encrypted information is imported into the read / write memory 18, the encryption
Decrypted by 20 and authenticated by authentication device 22. Thereafter, the processor 16 can process the decrypted information. When the processor 16 finishes the information block (at least in the near future), the decrypted information (with any processing changes performed) is re-authenticated by the authentication device 22 and re-encrypted by the encryption device 20. And exported to the external memory 24 by the import / export means.

Those skilled in the art will appreciate that the import / export means may be configured in a number of ways without departing from the scope of the present invention, but in the illustrated embodiment it may be more than one. And a bus having external connections.

As will be appreciated by those skilled in the art, in applications where the encrypted information is stored in external memory 24, unless precautions are taken, a hacker may be concerned with the modified block and the time at which the block was modified. The information can be recognized and this information can be used in a statistical attack. Such information could potentially help hackers trying to infringe the copyright of the encrypted information. To avoid this, the encryption device 20 of the device 10 is preferably configured to perform key cycling on the whitening key.

In essence, whitening performs a mathematical operation (such as an exclusive OR operation) to combine whitening keys with information blocks, effectively further enhancing the key material. The whitening process can be performed on the encrypted information block and the corresponding decrypted information block (ie, both before and after encryption occurs). The advantages of using this technique in the illustrated device 10 are:
The encrypted information block always looks different when exported (from a previous import / export sequence), whether or not the content of the decrypted information has changed. In other words, in the device 10 shown, the encryption device 20 is configured to decrypt and re-authenticate information in its secure form provided by the device 10 with its original encrypted form. It is re-encrypted differently, thereby masking modification information as to whether the content of the decrypted information has been modified. Therefore, the encryption device 20 has the first form when the encrypted information corresponding to the decrypted information is imported from the external memory 24, and when the encrypted information is exported to the external memory 24, Even if the corresponding decrypted information remains unchanged, the information is encrypted so as to have a second form different from the first form. Because of this technique, the attacker is not given the possibility of a known attack on the ciphertext because the original text of the ciphertext is not known, and the attacker is denied control of the ciphertext original text, so the adaptively selected ciphertext is denied. Does not give the possibility of a textual attack. The attacker cannot perform a statistical attack on the whitening key when it is changed by each export operation, and thus the key life is short enough. In this regard, of course, other methods may be used including, for example, key cycling of the DES key or package transfer.

To ensure that a whitening effect is provided for substantially every import / export operation performed on a given block of information,
The encryption device 20 is configured to perform key cycling on the whitening key. In particular, the encryption device 20 is configured to use a new whitening key for each section of information that it encrypts. Thus, when a previously exported block of encrypted information has been imported from external memory 24, the whitening key used in the previous import / export cycle is used by encryption device 20 in the decryption process. Thereafter, when that same block of information is exported, the encryption device 20 performs the whitening part of the encryption process using the new whitening key.

As will be appreciated by those skilled in the art, in order to efficiently decrypt information blocks whitened by a whitening key, the encryption device 20 must have a whitening key. Since a new whitening key is preferably used for each block of exported encrypted information, storing the whitening key internally will quickly drain the device 10 from memory resources. In order to avoid such a result, in this preferred embodiment, the encrypted version of the whitening key is written to a predetermined position in the corresponding whitened encrypted information block. Rare, encrypted and whitened information blocks are exported and stored in external memory 24. Thus, when the encrypted information block is imported, the encryption device 20 searches for the whitening key from a known predetermined position in the block and uses the whitening key in the decryption process. Obviously, since the encrypted whitening key is inside a block, it is covered by authentication with the rest of the block. In the embodiment shown, the whitening key is stored external to the device 10 to conserve memory resources, but those skilled in the art will recognize that the whitening key may be mapped in a manner that maps the stored whitening key to the exported information block. It will be appreciated that by internally storing in the device 10 (as was done with the authentication information described above) the level of security can be increased. Such a whitening key management method can of course be used without departing from the technical scope of the present invention.

As will be appreciated by those skilled in the art, in the embodiment shown, a power failure occurs because the CBC-MAC value for the exported information block is stored in volatile read / write memory 18. CBC-MAC value in memory 18 will be lost if a reset condition occurs. CBC-M
If the AC value is lost, the authentication device 22 will not be able to authenticate when re-importing the exported information block, and an error condition will occur unless precautions are taken. For these situations, those skilled in the art will recognize that if permanent storage, such as a fault-tolerant system, is not provided for the modified CBC-MAC value, the original encrypted information block will be preserved. The original CBC at startup
-It will be understood that it must be used with the MAC value. As mentioned above, in the device 10 shown, the CBC-MAC values for the original form of the encrypted information block are stored permanently in an external memory (e.g., ROM 142 of FIG. 3). Read / write memory 18 is loaded as part of the startup process. Thus, whenever the device 10 is reset, the CBC-MAC values in the read / write memory 18 are also restored to their original values. As a result, in the embodiment shown, the process always starts with the original encrypted information block to ensure that the process starts from a well-known trusted state.

As will be appreciated by those skilled in the art, the above CBC-MAC value processing method naturally implies that previous modifications to the encrypted information are lost. However, this does not mean that the result of the previous operation is necessarily lost. Alternatively, the non-volatile memory stored data modified during previous use of the device 10 can be stored in permanent storage remote from the device 10 and imported as needed. This non-volatile memory can store information in an encrypted or decrypted form depending on the application. If stored in an encrypted format and / or an authenticated format, the authentication information for such information is stored internally by some non-volatile memory, or the device 10
Must be stored in some non-volatile memory outside of the device and imported as needed, but internal storage is preferred.

The device 10 shown comprises a triple key with a whitening algorithm,
All of the information blocks encrypted by the Triple DES-CBC are encrypted. In a preferred embodiment, a hierarchical structure of keys is used. The information block is
It is encrypted by Triple DES using the session key as a decryption key. Therefore, the session key is needed to decrypt any of the information blocks processed by the system. To get the session key, you have to access the master key. To get the master key, you have to access the device key. In this way, it is of utmost importance to maintain the security of the device key in protecting the service environment created by the device 10 from hackers. As will be described in detail below, the unencrypted form of the device, master and session keys are only available in the encryption device 20 and the key facility of the encryption device. They are preferably always inaccessible by the processor 16. Preferably, the device key is stored in a scrambled form and the key is protected by a spreading checksum process as described herein.

As used herein, “DK” refers to a device key, “MK” refers to a master key, “SK” refers to a session key, and “EMK” refers to an encrypted master key (ie, "ESK" indicates an encrypted session key (that is, a session key encrypted with the master key).

As mentioned above, a major security problem of the device 10 is to preserve the security of the keys used in the device 10. The key must be stored somewhere in the memory of the device 10. However, it is highly likely that hackers will attempt to read key material from its memory to defeat a secure secure environment. Accordingly, it is inevitable to include a device for controlling access to sensitive data, such as keying material stored within device 10.

FIG. 3 shows a more detailed block diagram of the device 10. As shown in the figure, the apparatus 10 comprises a device 30 including a non-volatile memory 32 for storing data and means for controlling access to data contained in the memory 34. ing. The non-volatile memory 32 stores the EEPR in the device 30 shown.
OM is configured. However, one of ordinary skill in the art will readily appreciate that other types of memory devices may be used for this purpose without departing from the scope of the invention. Similarly, the control means may be constituted by a logic circuit 34 such as a hardware circuit including a number of logic gates configured to perform a predefined function when a predefined state occurs. However, one of ordinary skill in the art will readily appreciate that logic 34 may be implemented in numerous ways without departing from the scope of the invention. For example, in a preferred embodiment, logic circuit 34 is configured by programmed processor 16.

The logic circuit 34 is configured to access the memory 32 and determine whether at least a portion of the data contained in the memory 32 contains sensitive data. Logic 34 determines this by analyzing the properties specific to the data. In particular, in the device 10 shown, the logic circuit 34 identifies and counts any data block in the memory 32 having predetermined characteristics. It then compares the number of counted data blocks to a threshold. Logic 34 uses the result of this comparison to indicate the presence or absence of sensitive data in memory 32.

As a more specific example, the data stored in memory 32 is represented by a series of bits, each bit having a logic state of “1” or “0”, as is usually the case. You. In the device 10 shown, the logic circuit 34 has a logic state "1".
Is configured to count the number of bits in the memory having Thereafter, the counted number is compared with a predetermined threshold number. If the comparison indicates that the number of bits in the memory 32 having the logic state "1" exceeds the threshold number, the logic circuit 34 indicates that sensitive data is stored in the memory, Restrict access to. If the comparison indicates that the bit in memory 32 having logic state "1" is below the threshold number, then the logic circuit
Numeral 34 indicates that no confidential data exists, and the restriction imposed on access to the memory 32 is released. This process of identifying and counting data blocks having predetermined characteristics and comparing the counted blocks to a threshold is referred to herein as a "spread checksum process."

It is important to note that whether sensitive data is present in memory 32 is determined based on the unique properties of the data in memory 34 itself. In contrast, in the prior art, a determination as to whether sensitive data is present in memory was often made by reading the state of one or more flag bits stored in memory. In such prior art devices, the flag bit is set to a first state when confidential data does not exist, and is set to a second state when confidential data exists. These prior art methods require that a complete lock / unlock decision on memory be made with a relatively small number of bits (sometimes only one).
And that these bits do not constitute a real indication of the protected data or its presence. Hackers often attempt to take advantage of these prior art methods by changing the state of the flag bits, for example, by damaging the memory or inducing a false read. If the hacker succeeds in changing the state of the flag bit, it will be convinced that such sensitive data does not exist in these prior art devices when the sensitive data is actually stored in memory, thereby causing the sensitive data to be lost. Can be accessed.

In the device 30 shown, in sharp contrast, there are no flag bits that control the locking and unlocking decisions. Thus, any damage or alteration of the contents of a small portion of memory 32 is not sufficient to unlock the device. Instead, if a suitably low threshold is selected, the state of almost all data in memory 32 must be changed to convince logic 34 that no sensitive data is present. Further, since the data used to identify the presence of the sensitive data is the sensitive data itself, by changing the state of this data sufficient to unlock the memory 32, it is stored in the memory 32 Preferably, substantially all sensitive data is destroyed. In other words, memory
A change in a property that is unique enough to cause the logic circuit 34 to determine that there is no sensitive data stored in 32 destroys the data in memory 32. As a result, if the threshold is properly set for the application, there must be insufficient sensitive data in memory for a successful attack. In other words, the determination of sensitive data is not related to some artificial metric, but to the existence of the sensitive data itself.

As will be appreciated by those skilled in the art, the spread checksum process described above can be implemented in whole memory 32 or in memory 32 without departing from the scope of the invention.
May be performed for any part of Further, those skilled in the art will appreciate that the threshold can be set to any desired value without departing from the scope of the present invention, but is preferably set to a relatively low level. There will be. Ideally, the threshold is set to 1 so that all sensitive data must be destroyed before the device is unlocked. However, a compromise must be made between security and testability in selecting a threshold to enable testing. In practice, in the device shown, the controlled portion of memory 32 is 3K bits and the threshold is set to 64 bits. Those skilled in the art will appreciate that the threshold can be set to any desired level without departing from the scope of the present invention. The threshold is preferably selected based on a determination of what is an acceptable level of disclosure that does not unacceptably compromise system security.

Further, those skilled in the art will recognize that while the data block counted by logic circuit 34 in the illustrated device 10 is a bit having a logic state “1”, this logic circuit 34 is within the scope of the present invention. Without deviating, counting bits having a logic state "0" or within a predetermined range of binary values (e.g., 0
It will be appreciated that it can be configured to count data blocks that include a plurality of bits having certain properties, such as a binary value (between 0000010 and 00010001).

The inherent tension that exists in the devices 10, 30 shown is a trade-off between security needs and testability and initial programmability. In particular, as mentioned above, it is important to control access to the repository of keying material (ie, memory 32) used to decrypt / encrypt blocks of information, It is important that the memory 32 can be tested if the device 10 is sold and returned after use in the field. Testing often requires reading and writing to memory 32. Therefore, the ability to perform a test is inconvenient for protecting the confidentiality of the data stored in the memory 32.

In the device 10 shown, testing can be performed only after the spread checksum test described above indicates that sensitive data is not present in memory 32.

For returned devices etc. already programmed with confidential data,
The test can only be performed by first erasing the memory 32. Accordingly, the apparatus 10 comprises means for triggering the erasure of the memory 32 by a controlled process described below.

The erasure method can also be used as a tamper response if desired by the application.

To prevent hackers from accessing sensitive data in memory 32 by triggering a partial erase of the memory (eg, triggering an erase and then immediately powering down the device) Logic circuit 34 responds to the erase trigger by replacing the data block originally stored in memory 32 with an intermediate data block having one or more intermediate values before erasing memory 32 to its final state. 32 are configured to be erased. This intermediate value ensures that the number of data blocks with unique properties stored in memory 32 remains at a level indicated by logic circuit 34 indicating the presence of sensitive data until all sensitive data is destroyed. To be selected. Logic circuit 34 erases memory 32 to a final state by replacing the intermediate data block stored in the memory with a final data block having one or more final values.

In particular, in the devices 10 and 30 shown, the logic circuit 34 erases the memory 32 in three stages. In a first step, logic circuit 34 writes the first intermediate value to a first group of locations in memory 32. In a second stage, logic circuit 34 writes the second intermediate value to a second group of locations in memory 32. In a third step, logic circuit 34 writes the final value to both first and second groups of locations in memory 32. The first intermediate value is the memory value after erasure of memory 32 is completed after or during the first phase.
Preferably, the counted number of data blocks having unique properties in 32 is selected to indicate the presence of sensitive data. In other words, the intermediate values are selected to be non-sensitive data with unique properties. Each half of the sensitive information should have unique properties to ensure that either half is sufficient to classify the information as sensitive under the spread checksum process Selected. This is chosen because when bulk erasure is performed, some memory will be in an undefined state that could incorrectly classify the device as not containing sensitive information. The unique properties of each half must exceed the threshold significantly to prevent misclassification in the case of some degradation of volatile memory. In a preferred embodiment, at least 96 in each half
Must be set. The randomly generated key material is unbiased (u
This is not an unreasonable undue limit, since it is easy to satisfy this number. In the device 10 shown, the first and second intermediate values are the same. They are set to the hexadecimal value 0x55. Also, in the device 10 shown, the first stage is performed by writing the hexadecimal value 0x55 to all even addresses in the memory 32, and the second stage is performed by writing all the odd addresses in the memory 32. This is done by writing the hexadecimal value 0x55 to the address, and the last step is done by writing the hexadecimal value 0x00 to all the addresses in the memory 32. However,
One skilled in the art can select another value for at least one of the first intermediate value, the second intermediate value, and the final value without departing from the technical scope of the present invention; It will be appreciated that and / or more or less erase steps can be used. It is well known that hackers sometimes try to read the contents of memory by various physical attacks. To prevent these techniques from being used to defeat the security methods used to maintain the confidentiality of the contents of memory 32, various security methods (eg, protection layers
Can be physically mounted on 32. ) Can be used.

As will be appreciated by those skilled in the art, the spread checksum procedure described above
It can be used to determine the security state of the memory 32 or a system containing the memory. If the spread checksum process indicates the presence of sensitive data, the memory 32 is determined to be in a first security state. If no sensitive data is present, the memory 32 is determined to be in a second security state.
In the device 10 shown, testing of the memory 32 is only possible when the memory 32 is in the second security state.

As mentioned above, the device 10 shown has at least two security cells,
That is, a kernel mode cell and a user mode cell are used. Processor 16
It is preferable to operate non-secure software in user mode and to operate confidential software in kernel mode. For many applications, two security cells are sufficient. However, in some cases it is preferred to have more than two security cells. For example, it is desirable to be able to multitask among a number of secret tasks, and to provide protection between two or more cells running software simultaneously (eg, different conditional access systems from different vendors). It is also desirable to prevent the compromise of one cell from sacrificing all of the system.

As shown in FIG. 2, the illustrated apparatus 10 optionally implements multiple security cells in separate address spaces, and secures secure internal memory 18 and external memory SDRAM 24. A memory management device 38 that facilitates paging on demand between the two. In the embodiment shown, the memory manager 38 is configured as a co-processor to assist the processor 16 in allocating memory resources among multiple security cells as needed. In this application, each page is a separately and independently encrypted and authenticated block. In addition, some or all of the security cells can operate in user mode to provide limited access to internal secure secure peripherals, but still remain secure secure It will be understood that the environment has a good environment. Those skilled in the art will appreciate that numerous devices can be configured to perform the functions of memory management without departing from the scope of the present invention. In particular, this function can be easily implemented by a standard memory management device.

As shown in FIG. 3, the processor 16 includes an R3000A MIPS RISC CPU (million instrument) forming the center of an R3904 chip manufactured by Toshiba.
ctions per second Reduced Instruction Set Computer Central Processing Un
it). As shown in FIG. 3, the nonvolatile memory 14 stores R
The non-volatile memory 32 is preferably formed by an EEPROM, the read / write memory 18 is preferably formed by a volatile data memory (DMEM), and the encryption device 20 is preferably formed by an OM. And the authentication unit 22 is configured with the same dedicated hardware circuitry to take advantage of the performance advantages of the hardware encryption unit and because most block encryption units are compatible with secret hashes . However, at least one of the encryption device 20 and the authentication device 22 can be configured by software without departing from the technical scope of the present invention. If the security requirements of the device require a hash larger than the block size of the encryption device,
The combination with the authentication device 22 may not be an acceptable compromise. Processor
The 16 communicates with the ROM 14, the logic circuit 34 and the DMEM 18 via a 32-bit general purpose bus 40 (GBUS), and in some applications, the general purpose bus 40 transfers the encrypted information section to the DMEM 18 and the SDRAM 24 as described above. It also operates as an import / export means for importing and exporting between and.

To control the movement of information blocks between the DMEM 18 and the encryption device 20 and share the encryption device 20 with satellite transfer function in the application of FIG.
Further comprises a second processor 42. As shown in FIG.
The processor 42 communicates with the encryption device 20 (configured in the device 10 as shown by the encryption module 20), and also via the bus 44 the read / write memory 18 (in the illustrated implementation). In the form, it is communicating with DMEM). The second processor 42 is configured to initiate decryption and re-encryption of the information blocks stored in DMEM 18. In the embodiment shown, the second processor
42 is configured by a sequencer. The presence of sequencer 42 and its connection to encryption device 20 in the disclosed embodiment is dependent on the intended use (FIG. 1) and is not required for a successful implementation of the present invention.

In the device 10 shown, the sequencer 42 has a peer to the processor 16
). To facilitate the delivery of instructions from processor 16 to sequencer 42, device 10 includes an instruction memory (IMEM) 46. In operation, if the processor 16 needs to request the sequencer 42 to perform a task, it writes the necessary instructions to the IMEM 46 and sends a control signal to the sequencer 42 to indicate that the instruction is present in the IMEM 46. Thereafter, the sequencer 42 reads this instruction from the IMEM 46 and executes it.

As described above, the device 10 authenticates the decrypted information before execution by the processor 16 and re-authenticates the information before encryption by the encryption device 20. Is provided. In the device 10 shown, the authentication device 22 is constituted by an encryption device 20.

As also mentioned above, the encryption device 20 uses a whitening key used to ensure that the re-encrypted information blocks always differ from what they were before they were decrypted. Is preferably configured to perform key cycling. To generate a new whitening key that is unique to the key cycling process, the device 10 uses a cryptographically strong pseudo-random number generator (CSPR).
It has an entropy source 48 that is used to continuously re-seed (NG). In order to take advantage of the performance advantages of the existing hardware encryption device 20, the encryption device 20 constitutes a CSPRNG. As shown in FIG. 3, entropy source 48 is in communication with sequencer 42 and encryption module 20 via bus 44. Sequencer 42 generates a new random number when requested and delivers the random number to encryption module 20 for use by the CSPRNG in generating a whitening key for use in the re-encryption process. It is configured to require an entropy source 48.

As also mentioned above, some of the keys used in the triple key, triple DES algorithm are stored in the memory 32. Ensure that these keys are only available in encryption device 20 and memory 32, and that the keys are not accessible by processor 16, sequencer 42, or any of the software / firmware they execute. The device 10 is provided with a key separation circuit 50, which connects the logic circuit 34 to the encryption device 20 to load the basic keys of the key hierarchy. I have.
In particular, in the device 10 shown, the key separation circuit 50 provides the necessary key material with E
A mechanism is provided for supplying the encryption module 20 from the EPROM 32. Memory 32 to ensure that the key cannot be accessed by another system component (hardware, software or firmware)
, The logic circuit 34, the key separation circuit 50, and the encryption module 20 constitute a closed system.

As also mentioned above, the state of the external pins may cause access to the secured internal peripheral device to prevent sensitive information from being exposed outside the secured secure environment. It is forcibly set in a predetermined state. For this,
Apparatus 10 includes one or more silence mode silencing circuits 52. The silence mode silencing circuit 52 is preferably configured as a hardware circuit that includes logic gates, which pre-configure external pins except after detecting that a bus cycle is not an access to sensitive data. Set to a defined state (like three states). This detection can be based on the address appearing on the bus. In this way, both access to internal sensitive data and the bus inactive state are masked. As a result, the attacker is rejected for information on statistical attacks based on details such as execution flow, instruction execution time, or data access order. Versacrypt Software Description For security, a secured kernel needs to impose various restrictions on which a real-time operating system (RTOS) can be used by the device 10. The following list contains the requirements / restrictions that the RTOS must meet: Context switching--secure kernel (runs on RISC54 (16))
Performs the actual context switch (ie, switch between tasks), but only if it is explicitly required to do so. Both preemptable and nonpreemptive context switching are supported. 2. Versacrypt Context Switching Assistance--The RTOS is expected to set a flag to indicate when a Versacrypt applet has run long enough to allow another Versacrypt applet to run. The final decision is made by the secure kernel if such an operation is currently disabled, based on whether another versacrypt applet is executable.

[0073] 3. System Startup--A secured kernel is integrally associated with the system startup process. If the RTOS has any requirements regarding the initial state, its load source, or its load method,
It can be configured by the Versacrypt bootstrap applet, which is part of the secure kernel startup.

[0074] 4. Kernel Mode--The secure kernel and versacrypt (ie, encrypted software running in the secure environment provided by device 10) solely use the kernel mode of the processor. This means: (a) Interrupt handling--all interrupts are handled by the secured kernel and then sent to a user-supplied handler table;
(B) System call--API to secure kernel is by Syscall instruction. The RTOS may not execute a system call with a Syscall (system call) instruction. (C) Error processing--events such as bus errors are not sent to the RTOS. (D) Address Map--Because all insecure peripherals are mapped into the user address space, the secured kernel does not become a bottleneck in accessing them.

[0075] 5. Low memory globals-A small amount (less than 256 bytes) of global variables are used to communicate between the user software and the secured kernel. If the RTOS has low memory globals, they must be consistent with these.

[0076] 6. Source Code for RTOS--The RTOS must be modified to run on a secure kernel.

FIG. 4 shows the relationship between the various classes of software running on the MIPS processor 54 (16). The difference between this model and the more traditional model is that certain functions need to perform a secure kernel. These functions include (1) access to hardware controlled for security, (2)
) All functions that must be taken for security, such as dispatching the interrupt handling device, and (3) communication with the Versacrypt environment to have a clear and secure interface. The Versacrypt applet has direct access to the real-time operating system and application software, both through variable access and subroutine calls, but is restricted to communicating with a secure kernel API.

Although most system calls are executed with interrupts disabled, those that are expected to have longer execution times can be interrupted as part of the caller's task. Execute in a state where proactive access is prohibited. This is a security requirement because the number of kernel contexts available in internal memory 18 is limited. This ability to disable preemption is performed for a limited period of time by the secure kernel. It can also be used by the Versacrypt applet if necessary, but its use is avoided because of its impact on real-time performance.

Also, when returning from an interrupt or when performing a context switch that supports the versacrypt export / import operation, a small number of cycles are performed secretly. This code is executed with interrupts enabled to minimize the impact on interrupt latency (same interrupt mask as before the interrupt was dispatched). The time required is short enough compared to the overhead of context switching to kernel tasks, and thus has a modest impact on system performance, but there is a significant difference in the performance of the Versacrypt export / import operation.

All kernel mode software runs from one real-time operating system task. It is shared by the secured kernel, all versatile applets, and any user functions called for kernel-mode software. All of them share a common task because there is only one (at most) Versacrypt applet that can actually be imported and executed at a time. In order to be able to support them as multiple tasks, real-time operating systems require a large number of versacrypt applets marked as executable, but context switching to exported versacrypt applets is required. As soon as they are received, they block and remain there until an export / import operation can be performed. This causes versatile thrashing unless the real-time operating system scheduler is significantly modified. The part of the secure kernel that executes in this task is the export / import software (the execution of which is always mutually exclusive with the execution of the versacrypt) or the system call that executes as part of the calling task Respond to User functions are always operating on demand by a versacrypt or secured kernel, and thus are logically part of performing a task. Since the user function is a synchronous call, the caller must wait for its termination. Export / run time is like sending a message that another task can block
If it is expected to be long enough to take into account the import operation, another approach should be taken. The secured kernel performs support for synchronous calls between kernel software and user functions. The important point of this is that a secure transfer between the two modes takes place and the state of the kernel is protected.

If the secured kernel is not feasible, the tick will be one tick
The call of the RTOS routine is kept asleep during ()). This includes the time when one versacrypt applet is not running and the time when it is performing a versacrypt export / import operation. This may result in an initial delay of up to one tick until the execution of the versacrypt request or the start of the versecrypt export / import operation to load the requested applet. it can.

The sequencer code (executed from IMEM 46) is divided into kernel and user segments. The kernel segment is further divided into permanently loaded sections, which provide system functions and a second section over which another kernel sequencer applet is overwritten as needed.

The use of VersaCrypt is intended to satisfy soft real-time requirements. It cannot meet hard real-time requirements due to the long (milliseconds) time required to perform export / import operations. Although it cannot guarantee the low latency due to this context switch time, in the disclosed embodiment, this uses a small percentage of system resources for export / import operations, while using tens of seconds per second. Can support what you need. If most requests contain only one Versacrypt applet, the export / import operation is bypassed and thousands (or more) requests per second can be processed. R that takes seconds to finish
It is also worthless to be able to extend the time required to process some of these requests, such as SA key operation, depending on the length of the key.

The application interface to VersaCrypt is through a simple API that allows multiple requests for the same or multiple VersaCrypt applets to be queued, with each VersaCrypt applet assigned to a separate queue. To be put into These requests are processed asynchronously to the caller, and a user-supplied callback function is executed when finished to process the result, or the callback is blocked by the caller's task (b
lock) can be notified of possible events.

If the encryption device 20 supports multiple key sizes, ie, a single DES operation, an interlock must be present to protect against the increasing attack on triple DES keys. . Even when a key hierarchy is used, it is important to authenticate any encrypted keys before trusting them.

It is generally accepted that security is more secure when the device generates its own key than when the key is injected externally. If the device has sufficient ability to generate its own key material, it is more secure than is known outside the device for a limited period of time. What is never known cannot be leaked. Those who do not go outside cannot be intercepted. The device 10 is capable of executing software in a manner not observable from the outside and has a hardware random number generator (RNG 48). Self key generation is one example of a class of operations that it is designed to perform. This ability is very important when encrypting a secured device with a key when the physical security of the factory cannot be maintained.

In one possible method of self-encryption, device 10 requires three secrets to generate its own keying material. The first secret is the shipping key (software export / import EMK, triple key, triple DES) programmed at the ASIC factory. The second secret is an ESK (triple key, triple DES) with an associated versacrypt applet, all of which are provided at the second factory. The third secret is, for example, an RSA secret key (mass) for the key server.

The key server is preferably located at a third physically secure site called a vault. To generate a key on device 10, (
Hardware such as 1) key server 120 and (2) "test jig" 122 (see FIG. 5) is required. Key server 120 is located in vault 124.
The key server 120 is configured as a personal computer (PC) having software dedicated to network connection and execution of the device 10 '. Satellite I / F94,
Optionally connected to a hardware random source 126 to access more entropy during key generation. The keying material for this adapter 10 'must be unique so that if any other adapter is compromised at the site of use, the security of the key server 120 will never be compromised. Key server
Preferably, 120 is isolated from network 128 by firewall 132.

The test jig 122 is provided in the second factory. In the disclosed embodiment, test jig 122 comprises a PC (personal computer) that is connected to each device 10 when it is programmed. The test jig 122 is connected to the key server 120 by a certain network interface 128. The satellite I / F 94 of the device 10 also includes a hardware random source 130 for the same reason.
Is optionally connected to It is also the network 132 by the firewall 132
8 may optionally be segregated.

In the following, the programming of the device 10 loaded in the test jig 122 will be described.
FIG. 6 shows the steps of this programming process. In FIG.
The actions that occur in the programmed adapter 10 are shown on the left, the actions that occur in the key server 120 are shown on the right, and the communication between the key server 120 and the test jig 22 is at the center of this diagram. It is represented by an arrow.

The device 10 boots safely from an external ROM, as described below in a start-up operation. The following operations are all from the Versacrypt applet. All communications are between the Versacrypt applet in the key server 120 and the Versacrypt applet in the device 10 programmed in the test jig 122. All data stored on the disk of the key server 120 is preferably encrypted and protected from danger / virus on the key server 120.

The first applet is not actually known to the public, but
The hardware random source 130 is used to update the random seed material. To maximize the effect of external random bits, the seed material is updated a specific number of times. Thereafter, the programmed device 10 generates a triple key, a triple DES session key, which is encrypted with the public key of the key server 120 and uses the network interface of the test jig 122 for the key server 120. Sent to

The key server 120 confirms that it is communicating with the device 10 by checking the source IP address. It also knows that it is communicating with device 10 because the source used the public key. The key server 120 verifies that it has not seen this session key before (or at the last specified number of applications) to protect against repeated data attacks or a contaminated and degraded random source 130. After decrypting the session key with its private key, all subsequent communications between the programmed device 10 and the key server 120 are encrypted with this session key (O-CBC) and are verified. The SHA hash of They also provide protection from repeated data attacks,
It contains the unique serial number and packet type assigned to this device 10.

The key server 122 then sends a random number from the key server source 126 (which is considered more secure) to the device 10 to update the seed material in the device 10. It can also be any assigned configuration, such as a serial number,
And send software export / import MK.

The device 10 knows that it is communicating with the key server 120 because the responding entity must know the secret key to get the session key. The device 10 updates the random seed material based on the random number received from the key server 120 and generates the new 512 byte EEPROM image (content described below). The device 10 also generates any other sensitive data that may be needed for the application. The device then sends the RSA public keys to key server 120, which signs them in database 134, stores them, and returns the signed key.

The device 10 then sends to the key server 120 any sensitive information that may need to be shared for operational or legal reasons. Thereafter, key server 120 records the received escrow material and instructs device 10 to commit its configuration. Finally, the device 10 responds by reprogramming its internal EEPROM 32 and notifying the test jig 122 of its success, so that the test jig 122 can begin processing the next device 10. .

From the above description, those skilled in the art can break the security of key generation by accessing the public key, and the chip factory and the second factory need to collude. You will understand that. Even with access to these three secrets, the system is still immune from external attacks.

The EEPROM 32 preferably includes the following data blocks. Applications requiring additional EEPROM include at least one of an insecure external EEPROM, an external EEPROM encrypted (and internally authenticated) with a device specific key, and a larger internal EEPROM 32. May optionally be used.

[0099]

(Equation 1)

Configuration Details for Secure Kernel The primary purpose of the secure kernel is to provide a versacrypt environment, but in order to do this, start-up, interrupt handling, Must be involved in context switching, system calls, exception handling, alert condition handling, and versacrypt management operations. [Startup] At startup, the secure kernel performs the following sequence of operations. This sequence is shown in a flowchart in FIG.

A. Test Equipment Reset / NMI Cause Register The reset / NMI cause register is the hardware used to detect the cause of any reset / NMI condition that could be caused by an alarm. If it contains an alert condition (block 144), on reset or NMI, the software disables certain internal peripherals. This operation is to stop an operation that generates an additional alarm or interferes with error processing. If debugging is enabled (block 148), execution moves to a routine outside of the internal ROM to make information about the cause available. However, system operation cannot continue (block 150). Otherwise, if this is a stand-alone product (ie, a set-top box without an external processor), as shown at the location of EEPROM 32 (block 152), device 10 performs a self-reset operation (block 152). 154). This allows for recoverable errors,
The device 10 continues to operate without user intervention. Of course, in the case of an unrecoverable error, the device 10 will continue to reboot indefinitely, so that no cause is easily recognizable. Prior to a self-reset, the cause must be written to a well-known location, so that if necessary, the cause can be diagnosed by a logic analyzer. If the device 10 is not a stand-alone device (ie, a second external processor) (block 152), all operations stop, the memory is not cleared, and the cause code is made available (PCI 80, external). Chip 10 waits for an external reset (via a visually visible bus activity and LED 140) (block 156).

B. Diagnostic boot and hardware initialization Hardware with minimal importance or safety is initialized. If there is no alarm condition (block 144), some hardware is initialized and all processor registers and internal memory (IMEM 46 and DMEM 18) and some global variables are cleared (block 164), thus performing, in particular, a bulk erase function. If so, the data from the previous application will not be published.

C. EEPROM Operation When bulk erase is triggered, the three-stage bulk erase operation described above is used. The 3K section of EEPROM 32 is read and a density of one is calculated. If the density of ones is below the threshold of 64 (block 170), it is assumed that no key material is present and testing or initial programming can be performed. In such a situation, a security circuit is disabled (block 172). If a fixed pattern (used to detect the presence of external ROM 142) is present (block 174), then jump to external ROM 142 (block 176). If the external ROM 142 is not present (block 174), the device 10 locks up, but at least the external test pins are available (block 178).

If the spread checksum process indicates that sensitive data is present in memory 32 (block 170), the checksum in the restricted block of EEPROM 32 is calculated (block 182). If the checksum is incorrect, a fatal error occurs (block 184). The device 10
Due to the deterioration of the EEPROM 22 or the tamper of the device 10,
Lock up. If the checksum is correct (block 182), the EEPROM
Various hardware configurations are set based on the values retrieved from 32 (block 186).

D. Delay A relatively small (nominally 1 second) delay then occurs (block 186).
). This delay serves a number of purposes. Most importantly, it takes a long time each time an attacker repeatedly performs (for many types of automatic attacks) unnoticed by the user during a long system reboot.

E. Security or Critical Hardware Initialization Certain global variables are initialized (block 186). In preparation for loading the versacrypt bootstrap, the permanently loaded sequencer applet of the secured kernel and its dummy user sequencer applet are
Loaded at 46, sequencer 42 is started (block 186). Also, a dummy user RISC code is loaded. Dummy applets and RISC so that the loading of the Versacrypt bootstrap applet uses the same code used under normal operation, rather than maintaining a second version used only for system startup. The code loads. The normal kernel, sequencer, and RISC code for importing the Versacrypt applet assumes that user code is present and interacts with it.
The kernel sequencer applet is expected to be called by the user background and
This must have a foreground handler (part of the chip's satellite transfer function) to follow. The kernel RISC code continues to relinquish control to the RTOS, waiting for sequencer 42 to terminate. Certain user nubs must be present to handle these functions.

F. Loading Versacrypt Bootstrap Applet An attempt is made to load the Versacrypt Bootstrap Applet from either the external ROM 142 or the PCI bus 78. All versatile bootstrap applets, even from a 32-bit external ROM 142, are copied into DMEM 18 before execution. The external ROM 142 can be used to boot the system without using the PCI bus 78 for performing tests, diagnosing returned devices, debugging, and the like. Its presence can be detected by the first half of the pattern, which is well known with a fixed offset (block 188). If external ROM 142 is not present (block 188), device 10 attempts to boot over PCI bus 78 (block 190). In particular, it first waits for the SCB to be set (going non-zero) from the PCI host (block 190). It then reads the block specified in SCB into SDRAM. If the first half of the pattern does not match (block 192), a fatal error occurs (block 192).
Block 194), control returns to block 146. If a match occurs (block 192
), The serial number of the device 10 from the EEPROM 32 and the software export /
The import EMK index is rewritten into the SCB after offset 8 (block 196). If the second half of the pattern does not match (block 198), a fatal error occurs (block 200).

Unlike the other versatile applets, the bootstrap applet runs in an interrupt disabled state. This is because it is part of system startup and it may be necessary to explicitly reset some external devices before stopping the interrupt notification, but it has been kept confidential. It is beyond the technical scope of the kernel. This Versacrypt applet is believed to handle bootstrap loading of the actual boot image. This simplifies the secure kernel, allows the boot image format to be tailored to a particular application, and will likely change if new requirements are discovered. Part of this operation involves initializing certain well-defined locations in memory that handle secured functions such as the Versacrypt Applet.

The typical operation of the Versacrypt bootstrap applet is: (1) initialize the Versacrypt environment, load the Versacrypt applet and authentication information, and (2) load the user software and tamper check it. (3) initializing the CSPRNG, (4) initializing various security and user variables used to control the configuration of the secure kernel for system use, and (5) (2) To control the transfer to the user mode code in the interrupt disabled state. All registers are cleared. Interrupts are disabled. This is because interrupts may need to be explicitly tested on some external devices before turning off interrupt notification as part of system startup, but this is not possible with secure kernel technology. Out of range. Registers are cleared, protecting sensitive material possibly left in them during system startup. User software must initialize certain well-defined locations in memory that handle non-secure functions such as interrupt handlers and stacks. [Interrupt Processing (and Context Switching)] FIG. 8 shows a process of dispatching an interrupt handler and returning from an interrupt. A. Interrupt Handling All interrupt handlers are executed in user mode by the user provided with a table of handlers. Return from interrupt is by system call. There is a separate interrupt stack (as required for Versacrypt,
Also, therefore, each task does not need to allocate enough stack space for nested interrupts), but needs to allocate additional bytes of stack space used for context switching when each task is defined. There is.

[0110] For various reasons, contexts are saved on the stack. A preemptive context switch is thereby simplified when triggered from a timer interrupt routine that should have already saved the partial context on the stack. The secure kernel is the logical place where this should occur, because the user routine must be working on registers saved by the interrupt handling portion of the secure kernel. The secured kernel must also have this function for versacrypt, and it actually runs fast. This is because the internal ROM 14 is faster than the external SDRAM 24 executed by the user code. Placing context on the stack is very convenient. That's because, like versacrypt, all tasks must have their own stack. Also, in this scheme, the secured kernel does not need any information in the underlying RTOS task control blocks or other data structures. It is only necessary that the saved stack pointer be saved in the task control block. Context changes to the secure kernel save the remaining registers (for user code) on the stack, switch the stack pointer, and restore the full context (as always done for versacrypt) Only).

B. Interrupt Stack For system security, when enabled (or when a system call is made), the user mode code must have a user space stack and the kernel mode code must have a kernel space stack. Must have. Further, kernel mode code cannot be run in an interrupt enabled state from an interrupt handler. These requirements exist because, under these circumstances, the current context may need to be saved on the stack. If the user has a kernel stack, it can be used to access kernel space resources when this user's context is saved. If the kernel has a user stack, his security is likely to be compromised by interrupt routines that can read and modify his saved context. Finally, a limitation from the interrupt routine for kernel mode is that it limits the number of kernel contexts that must be stored in DMEM 18 simultaneously.

A secured kernel has a number of contexts that it must maintain. Each versacrypt applet has one context on its own stack, whether encrypted with DMEM 18 (only for the currently loaded versacrypt applet) or external SDRAM 24. . The secured kernel must also have a second context used during export / import operations. It also has a third context for handling system calls that are not preemptable to minimize system interrupt latency, but are executed in an interrupt enabled state due to the time they take to execute. ing. These system calls require a context for each task that is otherwise making a system call at the same time,
Because of the large number of contexts required in MEM 18, they must be unpredictable. This third context is also used in case of returning from an interrupt or performing a context switch, secretly cycling to assist the versacrypt export / import operation.

When the kernel mode (versacrypt applet or secured kernel) code is running, the system returns to the interrupt routine before passing control.
Save and clear all registers (this protects and hides sensitive data). This results in an interrupt latency of 4-5 microseconds (not including periods of interrupt disabled state, such as most system calls or bus usage by DMA). Since real-time software must be able to withstand this long interrupt latency and simplify the writing of interrupt handlers, the kernel places a partial context on the stack when user code is interrupted. Will be saved. This is still faster than kernel mode, but must be more than sufficient for interrupt handling.

C. Context Switch Upon return from an interrupt, the secured kernel checks some global variables that have been used to indicate that a proactive context switch is needed. This is the address where the stack pointer should be stored (perhaps the offset into the task control block for the task at this point),
Where a new stack pointer can be loaded to restore context (
Probably the address of the next task's task control block). When this preemption occurs, it saves the remaining context on the stack (for user tasks) and restores the complete context from that stack (as it always does for the kernel).

D. Versacrypt Support The secured kernel has certain limitations associated with the Versacrypt export / import operations, such as copying blocks of memory and scheduling the kernel sequencer applet when performing a context switch, before returning from an interrupt. (Using a limited amount of time). This can delay the preemptable context switch by a small amount, but should not significantly affect system performance. Since these operations are performed in an interrupt enabled state, there is no interrupt latency. There is a single kernel task that will execute user routines for the kernel or will be shared between the Versacrypt applet and the secured kernel. The saved stack pointer is a false value (all 1s)
And does not publish the actual value, nor does it allow user software to change it. The actual stack pointer is DMEM
It is stored in 18 or encrypted in external SDRAM 24 for exported versacrypt applet. This single task gives the Versacrypt applet a low priority, but it has a large delay in any case associated with exporting the old applet with its data and importing the new applet with its data. Is the cause.
There is only one task for every kernel task. This is because there is only one versatile applet that can be executed at a time, the other being encrypted in the external memory 24, and a secure kernel instead of another task. Is to be executed.

Regarding the speed of execution, if the running applet is loaded at this point, it will not be exported and imported again, but will run as it is. If the data segment to be loaded requested by the applet is loaded by the currently executing applet, this data segment is exported and re-imported, simplifying the secured kernel.

To support proactive Versacrypt scheduling, RT
The OS must set the global flag to request a versatile swap. This can easily be done from the RTOS timer interrupt routine.

The algorithm used to perform Versacrypt scheduling is:
Check the VC swap each time it performs a context switch to a kernel task in kernel mode. (1) if a versacrypt swap is requested, (2) if there is another versacrypt applet waiting in the versacrypt execution queue, (3) if versacrypt swapping is enabled, Instead of running the decision verse crypto applet, an export / import operation is started. Most of the operations involved in export / import operations deal with loading kernel sequencer applets and scheduling their execution. The sequencer can perform the actual encryption and authentication.
Since these operations can be completed in a short time, when returning from an interrupt and performing context switching, a cycle for performing these operations is secretly performed. The remaining operations take a long time to complete, so they are executed from the kernel task. These operations copy the block between the DMAM 18 and the SDRAM 24 and flush the cache. Due to this method, there are three additional round robin schedule delays associated with the Versacrypt swap. These three schedule delays are caused by (1) DMEM18 after exporting and starting import.
(2) Check applet import, flush instruction cache, start data segment import, (3)
Used to check data segment import, flush data cache and start applet execution.

E. Verscrypt export / import The purpose of the Verscrypt control block is to store the Verscrypt applet and data segments in external memory, manage user Verscrypt calls, and maintain the Verscrypt execution queue. Applets are treated as special cases of data segments in order to take advantage of the common routines in the secured kernel.

The format of the versatile control block in the external memory 24 is shown below:

(Equation 2)

The device 10 uses whitening to strengthen the key material. This is because a large amount of ciphertext is given to the attacker by the export process. It also changes all data every time a block is exported,
This means that no information is given to the hacker as to what data is changing or how long it took for the action. It also protects the known ciphertext original from attack, since the beginning of every Versacrypt applet is fairly constant. Finally, it also protects the adaptively selected ciphertext from attack, in which hackers pass values to the device 10 so that they are exported immediately after the applet loads its parameters. Can be selected.

Optionally, the versacrypt can change its key material for each versacrypt export to further enhance security and limit key life.

The device 10 also protects against long-term data attacks, which are similar to repeated data attacks on the network. In this attack, the old value of the versacrypt block is later given again by limiting the number of versacrypt blocks so that the checksum for each block is maintained in DMEM 18 and can be compared at load time. The limit on the versacrypt block (applet + sub-applet + data segment) is 32 blocks in the device 10 shown, ie 256 bytes.

F. Versacrypt Block ID The Versacrypt Block ID can be any 16-bit value other than the 0 reserved value. The only limitation is that the bottom 5 bits of the ID must be unique for a given system. This is because they are used as indexes into the various tables of the Versacrypt block.

G. Versacrypt Block Types Three different types of versacrypt blocks, namely data segments,
Versacrypt applet and Versacrypt sub-applet exist. Data segments are used to store data that can be shared between versacrypt applets. They may be exported / imported by the Versacrypt applet and are not usable by user code. The Versacrypt applet is a user-callable Versacrypt function. They are invoked via a system call that inserts a call control block into a queue in the Versacrypt control block and inserts a Versacrypt applet (if not already present) into the Versacrypt execution queue. . Versacrypt sub-applets are versacrypt applets, except that they are only called by another versacrypt applet and are not called directly by the user. They have a large export / import delay, but are used to segment large applets into smaller sections.

In many instances, the term versacrypt applet is used to refer to both the versacrypt applet and the versacrypt subapplet. The actual differences will depend on the intent of those who call them, as explained below. The Versacrypt applet is called as a subroutine that uses the regular C calling convention and must observe standard C register usage. Those stack pointers are initialized at the end of the applet's block and have their parameters available. The Versacrypt applets, like any other C function, will have some of the non-temporary registers they used will be used to store the Versacrypt linkage information.
You have to save them.

H. Versacrypt Data Segment Data Segment imports and exports data segments,
It is managed by the Verscrypt applet via four system calls to create and delete data segments. The Versacrypt applet may have eight data segments loaded at the same time and must explicitly unload them (except for the parameters for the Versacrypt sub-applet) at the end. When they are loaded (imported), their format is the same as in external memory (area tamper-checked by the data), except that they are not encrypted.

It is not reasonable to keep executable instructions in the Versacrypt data segment, and the instruction cache is not flushed when the Versacrypt data segment is imported.

A data segment can be created and initialized at construction and set to be loaded into the boot image by the applet so that no initialization code is required in the applet. It is also possible to have the applet automatically load its data segment, so they do not need to be explicitly loaded and unloaded, they are known to load at well-known addresses .

If multiple versatile applets are trying to access the same data, the versatile applet can handle any semaphore for shared access to the data in the data segment. They can use the Disabled Versacrypt Prefetchable flag for this function if it does not adversely affect the Versacrypt scheduling.

I. Versacrypt Applet The Versacrypt applet is invoked only via system calls. This system call is a call to the versatile applet in the queue CB
And if this is the first entry, add the Verscrypt applet to the end of the Verscrypt run queue. The scheduler shares the CPU 54 (16) among many tasks, one of which is a single kernel task. The kernel task then shares its cycle between the user function, the secured kernel, and all versacrypt applets that are ready to run. Since the Versacrypt applet is preemptive, a single applet (such as RSA) that runs for a long time prevents another user task or execution of the Versacrypt applet from being maintained. When the Versacrypt applet is entered, it has the call CB as its only parameter.

Any real task, such as the Versacrypt applet, is broken down into insecure user tasks that invoke the secured Versacrypt applet. For example, the conditional access software can have a user portion (including an interrupt handler to communicate with the smart card) that makes a versacrito call to generate requests for the smart card and process the results from the smart card. There is. The user part can also handle message passing, signaling equipment and, if necessary, periodic calls. Versacrypt cannot hide external events that allow secured tasks to be involved, but must instead hide the handling of events.

J. Versacrypt Sub-Applet The Versacrypt sub-applet is exactly the same as the regular applet, but is used to decompose the Versacrypt applet beyond the memory limit.
They can be called through kernel-only system calls and cannot be called directly by user software. When they are called by the Versacrypt applet (or sub-applet), the calling block and sub-applet begin execution. If the sub-applet is already running when it is called, an alert is triggered (this pre-empts the sharing of routines between applets and in most cases some type of recursion). Sub applets are non-reentrant. The caller must use ParmID (
(Which is the ID of the data segment) and when the Versacrypt sub-applet is entered, it has a pointer to this data segment as its only parameter. Data segments are used to send parameters and return results.

K. Context Switching Check The confidential kernel performs the following checks whenever it switches context to a single kernel task (see FIG. 9): If the bar crypt prefetch possible request flag is set, the use prohibited bar crypt prefetch possible flag is cleared, and the bar crypt execution queue is not empty, (a) the use prohibited bar crypt prefetch possible flag is set and (b) export To save the current stack pointer, (c) load the secure kernel export / import stack pointer, and (d) enable interrupts (block 210). At this point, the secured kernel task is executing to perform the export / import operation.

If the applet is currently loaded (block 212) and is not the desired applet (block 214), it is exported. In particular, if the applet has not finished executing (block 216), it is added to the end of the execution queue (block 218). For each data segment being loaded, and thus for the applet itself: (a) a random whitening value is generated for export, (b) the MAC is calculated and stored in DMEM 18;
c) The block is encrypted by whitening, and (d) the encrypted, whitened applet is copied from DMEM 18 to SDRAM 24 (block 220). The next applet is removed from the top of the Versacrypt execution queue (block 222).

If the applet has not been loaded at this point (block 212), it is imported (block 222). In particular, the imported applet and its respective data segments are (a) copied from the SDRAM 24 to the DMEM 18, (b) decrypted by whitening, and (c) M for the decrypted block.
The AC is calculated and compared to the values in the table in DMEM 18, (d) the flags are checked (ie, to make sure the block is of the expected type, etc.), and (e) the imported applet is If it is a sub-applet that is not currently running, the first data segment in the table is replaced with that parameter, so it is loaded, and (f) the validity of the data segment map for the applet and sub-applet Checked, (g) Flush instruction and data cache.

On the other hand, if the applet has just started (blocks 214 and 224), its context is initialized: (i) its saved stack pointer is set; (ii) its parameters are Call CB (
(Iii) set in the data segment (for sub-applet) or data segment (for sub-applet) and (iii) its return register ($ 31) points to code in the kernel secured to handle applet termination (This also requires saving the calling CB (for the applet) or the calling applet ID (for the sub-applet)) and (iv) its flag is updated (ie,
It is running) (block 226).

Regardless of whether the situation is one of the three above (ie, the applet is currently loaded, the applet is not currently loaded, or the applet is loaded and has just started) , Control then disables interrupts; restores the saved stack pointer; clears the disabled versatile preemptable flag and the versatile preemptable request flag (block
228).

Thereafter, control restores the kernel context and enters kernel mode. [If there is no executable versatile appletch, this is a loop that keeps the RTOS call asleep for one tick. L.]. Data section format of Versacrypt applet The following shows the format of the data section of the Versacrypt applet:

(Equation 3)

M. Versacrypt Applet Call Control Block Format The purpose of the Versacrypt Applet Call Control Block (Call CB) is to have a well-defined interface for making user requests for Versacrypt. This invocation CB allows asynchronous requests, so that the user software can queue a large number of requests without having to wait for the relatively slow scheduling of the versatile applet. Because of the large number of security issues at the interface between two tasks operating at different security levels, this simplified interface minimizes areas where certain types of security issues are likely to occur. Help.

The following shows the format of the user versus applet call control block:

(Equation 4)

Tamper Check In addition to the various tamper check features described above, apparatus 10 further performs a method of tamper checking an integrated circuit. The method is performed upon detection of a reset event. If such an event is detected, processor 54 (16)
It is held in a reset state so that M32 cannot be accessed. EE
PROM 32 cannot be accessed when processor 54 (16) is held in the reset state. This is because the processor must start accessing all EEPROMs. In the device 10 shown, all possible circuits, including memory, are tested by BIST (Built-In Self Test).
Processor 54 (16) is held in reset during the execution of these tests. Processor 54 (16) is released from reset only if each of the devices under test passes the BIST test. If any of the tested elements fail each of those tests, the device 10 is considered tamped and the processor 54 (16) is in the reset state so that no further instructions are executed. , No boot-up occurs and therefore no sensitive information is disclosed.

Since the processor 54 (16) is held in the reset state during this process, additional equipment must be provided to implement this tamper checking method.
In the embodiment shown, the tamper checking method comprises a watchdog circuit.
88 (see FIG. 3). In this manner, the tamper check method is preferably performed by hardware, and is preferably performed every time a reset state occurs.

Those skilled in the art will use other events as triggers (eg, periodically occurring events) in addition to resets used as BIST test triggers, without departing from the scope of the present invention. You will understand that it is possible. If a periodic event is used as a trigger, the device preferably tests isolated elements that may be affected. Further, those skilled in the art will readily appreciate that in addition to (or instead of) holding the processor in a reset state, alternative tamper response characteristics can be used without departing from the scope of the present invention. Will understand. Further, the processor may be used to initiate and / or execute a test without departing from the scope of the present invention.

Attention should be paid to the following details regarding preferred embodiments of the invention. First, in a preferred embodiment, device 10 is configured in a single semiconductor die.

In a preferred embodiment, the processor 16 will also have a kernel operating mode that prohibits user software from accessing sections of the address space and performing privileged operations. Third, all bus masters except the processor 16, the DMA, must have a limited view. Preferably, no external bus master can be used.

In addition, the address map must be defined so that all secured peripherals fall within the kernel address space and all other peripherals fall within the user address space. Further, as will be appreciated by those skilled in the art, the system may include any desired standards or application-specific peripherals without departing from the scope of the invention.

Further, as will be appreciated by those skilled in the art, over preferred embodiments,
Adversary is set for all external resources and user-supplied parameters.
Such resources should be expected to change without notification at unpredictable times as a result of an attack. Legitimate access should be considered as providing information for statistical attacks. All addresses must be checked for validity before use, and all values must be copied to internal memory before at least one of authorization and use.

While specific examples of the invention have been described herein, the scope of the invention is not limited thereto. On the contrary, the invention covers all features that fall within the scope of the appended claims on a practical or equivalent principle.

[Brief description of the drawings]

FIG. 1 is a schematic diagram of an apparatus constructed in accordance with the teachings of the present invention in one available environment.

FIG. 2 is a schematic diagram of the apparatus of FIG.

FIG. 3 is a more detailed schematic diagram of the device of FIGS. 1 and 2;

FIG. 4 is a schematic diagram of a software architecture used in the device.

FIG. 5 is a schematic diagram of an exemplary system for programming a device.

FIG. 6 is a ladder diagram showing the programming of the EEPROM of the device.

FIG. 7 is a flowchart showing a start-up operation of the device.

FIG. 8 is a flowchart illustrating an interrupt handling process used by the device.

FIG. 9 is a flowchart illustrating a process used by the device to exchange applets between external memory and DMEM.

──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, GH, GM, HR, HU, ID, IL, IS, JP, KE, KG, KP , KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, UZ, VN, YU, ZW Court 1 (72) Inventor Cropper, David S. United States, Maryland 211771 Mount Airy, Leafy Hollow Circle 1012 (72) Inventor Weber, Sandra Jay United States, Pennsylvania 15226 Pittsburgh, Brookline Boulevard 1431 (72) Inventor Bouts, Brandon E United States, Maryland 20814 Bethesda, Brist Square lanes 9803 F-term (reference) 5B017 AA07 BA07 CA15 5B076 FC08 5J104 AA08 AA34 NA02 PA14

Claims (42)

[Claims] A read / write memory for storing information, a first processor for reading information therefrom and writing information thereto in cooperation with the read / write memory, communicating with the read / write memory, An encryption device configured to selectively decrypt encrypted information into decrypted information, and a first processor configured to provide the decrypted information to a read / write memory for later use. An apparatus for providing a secure processing environment, comprising: an authentication device for authenticating the decrypted information before being used by the first processor. 2. The authentication device re-authenticates the decrypted information received from the read / write memory, and the encryption device selectively encrypts the decrypted and re-authenticated information to re-encrypt. The apparatus of claim 1, wherein the apparatus is configured to be information. 3. The apparatus of claim 2, wherein the encryption device returns the encrypted information to the read / write memory for later export to the storage device. 4. The apparatus of claim 2, wherein the encryption device re-encrypts the decrypted and re-authenticated information differently from its original encrypted form to mask the modification information. 5. The apparatus according to claim 4, wherein the encryption device uses key cycling to mask the modification information. 6. The apparatus of claim 4, wherein the encryption device uses a whitening process to mask modification information, the whitening process uses a whitening key, and the whitening key is rotated. 7. The authentication data used to re-authenticate the information decrypted before re-encryption is read / written for later use in authenticating the decrypted information.
3. The apparatus of claim 2, wherein the apparatus is stored in a write memory. 8. The apparatus according to claim 2, further comprising an external memory for selectively storing the re-encrypted information. 9. The apparatus of claim 1, wherein the first processor has a kernel operating mode and a user operating mode, and defines a security cell separate from the kernel mode and the user mode. 10. The apparatus of claim 9, wherein the first processor executes unsecured software in a user mode of operation and executes secure software in a kernel mode of operation. 11. A second processor in communication with the encryption device and the read / write memory, thereby selectively initiating decryption and re-encryption of information stored in the read / write memory. The apparatus of claim 1 wherein: 12. The device according to claim 11, wherein the encryption device includes an authentication device. 13. The apparatus of claim 1, wherein the encrypted information includes encrypted processor instructions. 14. The apparatus according to claim 1, wherein the encrypted information includes encrypted data. 15. The apparatus of claim 1, wherein the encrypted information is segmented into sections. 16. The method of claim 1, wherein each section is independently encrypted and authenticated.
An apparatus according to claim 5. 17. Controlling access to a non-volatile memory and data contained in the non-volatile memory, selectively accessing the non-volatile memory, and analyzing properties specific to the accessed data. 2. The apparatus of claim 1, further comprising: a logic circuit for determining whether data contained in the non-volatile memory includes confidential data. 18. The logic circuit identifies data blocks in the accessed data having predetermined characteristics, counts the identified data blocks, and compares the count to a threshold. 18. The apparatus of claim 17, wherein the method determines whether data contained in the non-volatile memory includes sensitive data. 19. The apparatus of claim 18, wherein each data block includes a bit and the predetermined property includes a predetermined logic state. 20. The apparatus of claim 18, wherein each data block includes a plurality of bits, and wherein the predetermined property includes a binary value falling within a range of the binary value. 21. The apparatus of claim 17, wherein the logic circuit comprises a first processor. 22. The apparatus of claim 17, further comprising a key separation circuit that connects the logic circuit directly to the encryption device. 23. The apparatus of claim 22, wherein the non-volatile memory stores the key, and the key separation circuit supplies the key to the encryption device. 24. The apparatus according to claim 22, wherein the logic circuit, the key separation circuit, and the encryption device define a closed system. 25. The apparatus of claim 1, wherein the first processor, the read / write memory, and the encryption device are embedded on an integrated circuit. 26. The integrated circuit includes pins for connecting the device to an external device and selectively disabling the pins to avoid exposing sensitive information outside a secure environment. 26. The apparatus of claim 25, further comprising a silencing circuit for: 27. The apparatus of claim 25, further comprising a watchdog circuit configured to monitor the integrated circuit for tamping. 28. The apparatus of claim 25, further comprising an input for selectively receiving the encrypted information from an external source. 29. The apparatus of claim 1, further comprising a memory management unit for maintaining a plurality of security cells in cooperation with the first processor. 30. The device according to claim 1, wherein the encryption device includes an encryption module. 31. The apparatus according to claim 1, wherein authentication of the decrypted information is performed by authenticating corresponding encrypted information. 32. An integrated circuit for providing a secure processing environment for use by an external memory having a first storage capacity and storing encrypted information, the integrated circuit comprising: a first storage capacity; Volatile memory having a small second storage capacity; import / export means for selectively importing and exporting encrypted information between the external memory and the volatile memory; Decrypting the encrypted information received from the volatile memory into the decrypted information in the environment, and encrypting the decrypted information back into the encrypted information in the confidential environment. Encryption means for processing the decrypted information in a secure environment and working with import / export means to avoid exceeding the second storage capacity; Selectively integrated circuits; and a processor for importing and exporting between the information decrypted with the external memory and the volatile memory. 33. The encrypting means has a first mode when the encrypted information corresponding to the decrypted information is imported from an external memory, and when the encrypted information is exported to the external memory. 33. The integrated circuit of claim 32, further comprising: encrypting the information so as to have a second form different from the first form even when the corresponding decrypted information remains unchanged. 34. A decrypting means decrypts the encrypted information using a first whitening key, and encrypts the decrypted information using a second whitening key different from the first whitening key. The integrated circuit according to claim 33, wherein the integrated circuit is formed. 35. The integrated circuit of claim 34, further comprising a cryptographically strong pseudo-random number generator for generating a second whitening key. 36. The integrated circuit of claim 32, further comprising means for authenticating the decrypted information in a secure environment. 37. The integrated circuit of claim 36, wherein the means for authenticating authenticates the information decrypted after importing from the external memory and re-authenticates the decrypted information before exporting to the external memory. 38. Use in an integrated circuit to perform security operations.
A method for tamper checking an integrated circuit, comprising: performing a built-in self-test on one or more elements of the integrated circuit to detect an event and determine whether a tamper has occurred; A tamper check method comprising the step of limiting one or more operations of the integrated circuit if the occurrence of is indicated. 39. A processor associated with the integrated circuit is held in a reset state such that a predefined memory storing key material cannot be accessed, and one or more elements have passed a built-in self test. 39. The method of claim 38, further comprising the step of: releasing the processor from the reset state if so, and holding the processor in the reset state if one or more components fail the built-in self test. 40. The method of claim 38, wherein said one or more devices comprises a memory. 41. The method of claim 38, wherein said one or more elements comprises a logic circuit. 42. The method of claim 38, wherein said event comprises a reset event.