JP2008530659A - Secure memory card with life cycle phase - Google Patents

Abstract

  Secure memory cards with encryption capabilities have various lifecycle states that allow testing of the card hardware and software in multiple states. Since the test mechanism is invalidated in some other state of the plurality of states, potential loopholes to secure data and encryption keys are closed. Even if a loophole is accessed, previously encrypted data cannot be decrypted, so data is encrypted and decrypted so that even if a loophole is found and entered maliciously, it is worthless The availability and generation of keys required for

Description

  The present invention relates generally to memory cards and encryption, and more particularly to exclusion of access to secure data and keys by a card testing mechanism.

  A considerable amount of time has passed since development, and intelligent memory cards, commonly referred to as smart cards, are accepted by the market in the form of identification and payment. The smart card includes a small amount of memory for storing user identification data and transaction related data. Smart cards are often called chips. In Japan, smart cards are used in various places such as national identity cards and credit cards and debit cards. Various chip designs and encryption schemes have been employed in cards and card-based systems to prevent impersonation crimes and other financial fraud.

  There are two competing benefits in the design and manufacture of any type of secure memory card. One benefit is to maximize card security, and another benefit is to maximize card reliability. To maximize the reliability of the card, the card software and hardware at various stages of production can be analyzed before failure from the factory, and in some cases even after shipment from the factory, for failure analysis. It is important to be able to test the wear. To test both the hardware and software of the card, the test may be performed by inputting / outputting signals to / from a test on a chip or a contact pad. While these test routines and test pads need to ensure quality control, they are a potential weakness for secure data, algorithms, and card keys, so-called “loopholes”. Thus, there is always some degree of compromise between maximizing reliability and maximizing security (the tests required for). Various approaches have been proposed to close this “loophole” after testing is complete. However, for various reasons, each of the previous solutions has commercial and technical drawbacks.

  In one approach that may be employed in the smart card fabrication described above, the card die is tested before the memory die is singulated from the wafer. A test pad for a particular die is provided on the adjacent die of the wafer, and the singulation process cuts the test pad from all circuitry on the adjacent die after testing. Thus, any test pads present on the singulated die are completely isolated and closed as a potential loophole to the secure data on the final memory card. However, complete removal of the test pad is not always practical or desirable. For example, without a usable test pad, a certain amount of hardware-based memory testing cannot continue, which limits, for example, potential failure analysis methods.

  This approach is typically used to store large numbers of large files such as photos and music, although it may be preferable for smart cards that have only a small amount of memory required to hold identification and transaction data It is insufficient to test the relatively large amount of memory and complex security routines employed in high capacity memory cards. Some examples of these large capacity memory cards are compact flash cards, MMC cards, and SD cards. With the proliferation of digital content and the associated copyright issues, the importance of security is increasing, while card testing and reliability remain the most important. There is a need for a more comprehensive and flexible system for manufacturing, testing, and operating secure mass memory cards and is provided by the present invention described below.

  Another important aspect is cost. Several different technologies such as non-volatile memory, logic, volatile memory, etc. can be fabricated on a single integrated circuit die (chip). However, when various technologies are mixed in one die, the production cost is remarkably increased. In competitive environments where cost is a major driving force, it is highly desirable to limit the number of different technologies that can be given to a die. However, using multiple dies also means that confidential information needs to be passed from one die to another in the final product. This is another potential weakness that hackers can take advantage of without proper precautions.

In particular, non-volatile memory bits are expensive to mix with logic within the same die. Smart cards employ non-volatile memory for data storage on the same die as the logic that implements the smart card, which is one way to maximize security. Today, however, memory cards that benefit from the present invention must store very large music, photos, videos, and other user files. Thus, the production of a single integrated circuit die memory card that can store large amounts of information (a few gigabytes as of 2005, but even more) is prohibitively expensive and employs multiple dies. It is necessary to develop a secure system. In particular, a secure system (encryption) using one or more discrete (cost-effective) flash memory dies that are separated from the controller die and can be fully tested before and after assembly but are less susceptible to attack via the test mechanism Production) is highly desirable.
US Patent Application No. 11 / 284,623

  Using a single chip that combines the functionality of a controller with the mass storage required by today's digital devices is overly costly and has scalability issues, so alternative systems Has been developed. In the case of a single chip solution, security can be ensured with a unique chip design that makes it difficult to access the test mechanism, encryption key, and encrypted content. However, in the case of a multi-chip design where content is passed from a separate memory chip to the controller chip where encryption occurs, particular attention must be paid to the encryption key and access protection to the encrypted content. In addition, a system that still has a test pad (preferably) in the final assembly so that the assembled system can be tested can be used as software and hardware that could be a loophole for unauthorized access to encryption keys and content. Special attention must be paid to any mechanism.

  The present invention has a number of life cycle phases that pass through the lifetime of the card. Depending on the phase, the card logic enables or disables the encryption engine, controls access to hardware and software test mechanisms (before and after wafer singulation and card assembly), and generates keys. Control. These phases (unlike smart cards with the test pad removed) will not only allow thorough testing of both the card hardware and software before and after production, but also when the card is in the secure phase, That is, when in the operational phase, which is the state of the card when it is shipped to the user, the encrypted key and thus the encrypted content is virtually inaccessible. Therefore, the present invention provides a memory card that can be fully tested but is resistant to unauthorized access to protected data in the card.

  Furthermore, there is a need for a more comprehensive and flexible system for manufacturing, testing, and operating secure mass memory cards and is provided by the present invention described below.

  Additional aspects, advantages, and features of the present invention are included in the following description of exemplary embodiments of the invention, referenced in conjunction with the accompanying drawings, in which like features are used to describe the same features. A reference number is used. All patents, patent applications, articles, and other publications referenced herein are hereby incorporated by reference in their entirety for all purposes.

(Memory system structure)
The block diagram of FIG. 1A illustrates an exemplary memory system in which various aspects of the invention may be implemented. As shown in FIG. 1A, the memory system 10 includes a central processing unit (CPU) or controller 12, a buffer management unit (BMU) 14, a host interface module (HIM) 16, and a flash interface module (FIM). ) 18, a flash memory 20, and a peripheral access module 22. Memory system 10 communicates with host device 24 via host interface bus 26 and port 26a. The flash memory 20, which may be of NAND type, provides the host device 24 with a data storage device. The software code of the CPU 12 is stored in the flash memory 20. The FIM 18 is connected to the flash memory 20 via a flash interface bus 28, but in some cases if the flash memory 20 is a removable component, not shown in the figure. The HIM 16 is suitable for connection to a host system such as a digital camera, personal computer, personal digital assistant (PDA) and MP-3 player, mobile phone, or other digital device. The peripheral access module 22 selects an appropriate controller module such as FIM, HIM, and BMU for communication with the CPU 12. In one embodiment, all components of the system 10 enclosed in a dotted box may be encapsulated in a single unit, such as a memory card, and preferably encapsulated in a card.

  The buffer management unit 14 includes a host direct memory access unit (HDMA) 32, a flash direct memory access unit (FDMA) 34, an arbiter 36, a CPU bus arbiter 35, a register 33, and a buffer random access memory (BRAM) 38. And an encryption engine 40 also called an encryption engine 40. Arbiter 36 is a shared bus arbiter in which only one master or initiator (which can be HDMA 32, FDMA 34, or CPU 12) is always active and the slave or target becomes BRAM 38. The arbiter is responsible for passing the appropriate initiator request to the BRAM 38. HDMA 32 and FDMA 34 are responsible for data transmitted between HIM 16, FIM 18, and BRAM 38 or RAM 11. The CPU bus arbiter 35 can transfer data directly from the cryptographic engine 40 and the flash DMA 34 to the RAM 11 via the system bus 15, which is used in situations where it is desirable not to go through the cryptographic engine, for example. The The operation of HDMA 32 and FDMA 34 is conventional and will not be described in detail herein. The BRAM 38 is used to store data passing between the host device 24 and the flash memory 20. The HDMA 32 and FDMA 34 are responsible for transferring data between the HIM 16 / FIM 18 and the BRAM 38 or CPU RAM 12a and indicating the completion of the sector.

  When data from the flash memory 20 is read by the host device 24, the encrypted data in the memory 20 is retrieved through the bus 28, FIM 18, FDMA 34, and cryptographic engine 40, and the encrypted data is decrypted and stored in the BRAM 38. Stored. The decrypted data is then transmitted from the BRAM 38 to the host device 24 through the HDMA 32, the HIM 16, and the bus 26. The data retrieved from the BRAM 38 may be encrypted again using the cryptographic engine 40 before being passed to the HDMA 32 so that the data sent to the host device 24 is encrypted again, but is stored in the memory 20. The data may be re-encrypted using a different key and / or algorithm compared to the encrypted data. In another form, instead of storing the decrypted data in the BRAM 38 in the process described above where the data may be vulnerable to unauthorized access, the data from the memory 20 is sent to the cryptographic engine before being sent to the BRAM 38. 40 may be decrypted and encrypted again. Next, the encrypted data in the BRAM 38 is transmitted to the host device 24 as described above. This indicates the data stream during the read process.

  When data is written to the memory 20 by the host device 24, the direction of the data stream is reversed. For example, if unencrypted data is sent by the host device through the bus 26, HIM 16 and HDMA 32 to the cryptographic engine 40, such data is encrypted by the engine 40 before being stored in the BRAM 38. May be used. In other forms, unencrypted data may be stored in the BRAM 38. The data is then encrypted before being sent to FDMA 34 on the way to memory 20.

(Life cycle phase)
For example, security systems or secure operating systems that are particularly useful when implemented on a memory card such as those described above have different phases or states. These phases are preferably entered continuously after proceeding from one phase to the next so that the previous phase cannot be entered again. Therefore, these phases can be considered life cycle phases.

  Before describing the phases in detail, another system level diagram is briefly described. FIG. 1B illustrates another embodiment of the system 10. Only certain components of the system 10 are shown in this figure for the sake of brevity and clarity. The memory system 10 includes a test pad, also referred to as a hardware test input / output (I / O) 54. The hardware bus (HW bus) 56 is preferably connected to the test pad 54. These test pads and HW bus 56 are connected to various hardware and circuitry (not shown) of system 10 and are used to test the hardware and circuitry of system 10. The JTAG bus 62 is connected to the system bus 15 (shown in FIG. 1A) and can be used to replace controller firmware and drive hardware blocks from outside the system 10. This is used for hardware tests that require register read / write operations. The JTAG bus 62 is also used to test the firmware of the system 10 because it has access to RAM and ROM. The host bus 26 is used to send diagnostic commands to the system 10 and is also used to test the system firmware.

  Also shown is the NVM 50 of the encryption engine 40. What is stored in the NVM 50 is a life cycle state 77 and a secret key 99 (value thereof). NVM test port 58 is used to test the NVM in encryption engine 40.

  The status indicator fuse 66 is used to indicate that the product is in an NVM state 110 (described below) rather than relying on NVM content. The reason is that the reliability of the initial value stored in the NVM during production cannot be guaranteed. Therefore, another more reliable indicator such as a fuse is used. The system determines that it is in state 110 if the fuse is set. If the system 10 is reset, it will see the NVM lifecycle state 77 to determine the state.

FIG. 2A shows the various states and the order of transitions between the states. Each state prescribes various behaviors and capabilities of the card (or system in which the card is implemented) before and after card manufacture, as can be seen from the following table, which is also reproduced in FIG. 2B.

The state is preferably stored as a 32-bit value in the non-volatile memory of the encryption engine. From the large number of possible (≈10 ⁹ ) combinations used to represent states 120-170, there are six pre-assigned values. All other values represent state 110. This ensures that the default values are stored during production, since various processing operations during production, assembly, testing, and shipping can alter any value stored in memory, and then This is because it cannot be ensured to be taken out.

  The key value is preferably stored as a 128-bit field in the non-volatile memory of the encryption engine. The key value is usually randomly generated by a seed algorithm. Key regeneration is likely to change the key value, but this cannot be guaranteed because the (pseudo) random number generator may actually generate the same value continuously. However, even though it is well understood that the value of a key may not change during regeneration, the term key change is interchangeable with the term key regeneration herein. Used for. Needless to say, the value of the key used to encrypt the information is important. The same key value must be used for both encryption and decryption. In this way, if the key value is regenerated every time the system is activated, the data encrypted before the activation cannot be decrypted with the new key, and thus becomes virtually worthless. The data is still physically present in the card's memory but is useless without the proper key value to unlock it. Thus, even if a hacker manages to return the card to a state other than the secure state 150, valuable information cannot be obtained. In states 110 and 160, a new key is generated at each startup, and the key that was already used to store the information in state 150 cannot be used to decrypt the information. In states 170 and 110, the encryption engine is simply unavailable regardless of the key value.

  Another security measure includes limiting the use of firmware and hardware test mechanisms. The system includes logic to enable or disable this mechanism. The host bus described above is one of the mechanisms used to test the card firmware. The host can issue diagnostic commands on the host bus to test the firmware. The hardware may also be tested when these commands are executed. The hardware is also tested directly on the hardware bus along with the JTAG port, which provides direct access to the various memories of the system. Note that in states 140 and 150, the NVM test mechanism, the HW test mechanism, and the FW test mechanism are all disabled.

  Hereinafter, the state and transition between states as shown in FIG. 2A will be described in more detail.

  State 110 is referred to as a non-volatile memory (NVM) test of the controller. This state is the initial state after the memory die is fabricated and is the state used to test the non-volatile memory of the controller die before the die is packaged and mounted on the memory card. Tests performed in this state may be performed before singulation while the dies are integral with the wafer format, or in other forms may be performed on individual dies after singulation. When the NVM is tested, its content (using the NVM tester) is initialized to display the status 120 and the fuse 66 is blown. In this state, the encryption engine 40 is invalidated. This state is designed to be entered only once in the card life cycle, and there is no way in the system to return to this state. However, as described above, this state is displayed with something other than the six pre-assigned values of the many possible combinations of 32-bit values used to define the life cycle state. If an illegal value is detected and the fuse is blown (cannot enter NVM state 110), the crypto engine will not be ready and the system will not boot or see FIG. The process proceeds beyond step 302 described below. Therefore, each time the card is activated and enters this state, a new key is randomly generated and the already encrypted data cannot be decrypted. Even if the encryption engine is not enabled in this mode, this mode is designed to be used while the wafer remains intact during fabrication, so in some unexpected way To protect against hackers trying to enter this state and seek out the card's secure data via various test ports and mechanisms, the key is regenerated at each startup. Otherwise, by design, the NVM test mechanism is not available after the existing state 110.

  State 120 is called a certain validation state. In this state, the encryption engine 40 is activated. The key used by the encryption engine is not generated by a random number generator and stored in memory, but is wired to some external source and is constant during this phase. Hardware and software test mechanisms are available in this state. This state is entered by a hardware tester.

  State 130 is referred to as a random activation state. This state is similar to state 120, but the secret key is generated randomly (once) instead of being fixed and wired when entering state 130. This is the state used for final testing, characterization and qualification of memory cards. Cryptographic operations including encryption and decryption are possible with firmware using a secret key or a key derived from the secret key. This state is entered by code executed by the system 10 after being loaded into the system 10 by the host device 24.

  State 140 is called the final key state. In this state, the card uses the final secret key from which the card is shipped. The hardware and software test mechanism is disabled by the card logic and is inaccessible. This includes a hardware test bus and a test pad, as shown in FIG. 1B. This state is used to load the final firmware and configuration data that needs to be protected with the key used at the time of product shipment to the card. The product can be configured in this state, but not in state 150. This state is entered by a host command. The commands may be included in code (“DLE code”) downloaded from the host and executed by the card. The command may be issued directly from the host in other forms. This is always the case when the term DLE code is used below.

  State 150 is called a secure state. This is a state where the card is shipped from the factory. The hardware and software test mechanism is disabled by the card logic and is inaccessible. This state is entered at the end of product testing and configuration at the manufacturing site. The key is not regenerated and the value stored in memory during state 140 is used during state 150. Derived keys may be used for various operations of the card, but key 99 is always necessary to derive these keys and to encrypt and decrypt data. This key means that it will be used for the lifetime of the secure card (while it is in the customer's hand as a secure card and not included thereafter). The card firmware cannot use the private key for any operation. It is the encryption engine hardware that is responsible for performing all encryption and decryption within the card. This state is entered by a DLE code.

  State 160 is referred to as a return authorization or RMA state. This condition is designed to allow testing of cards returned by consumers because they do not work properly. This is a state where the failure analysis of the card can be executed. Software and hardware test mechanisms are available again. It is important to note that this state is accessible only by the factory. Furthermore, after entering the RMA state, the card cannot be used again as a secure card. In other words, the card cannot re-enter state 150, or otherwise cannot be used to decrypt information on the card or store encrypted information on the card. . The private key is regenerated when entering this mode and between chip resets performed while the card is in this state. The operation that uses the encryption key for decryption is enabled only at startup, and the firmware cannot use the secret key for any operation. This state is entered by the ROM code that is the result of the host command.

  State 170 is referred to as an invalidation state. In the disabled state, the cryptographic engine 40 is in a bypass mode in which all of the cryptographic functions are disabled. Only non-secure algorithms are used in the card. Hardware and software test mechanisms are re-enabled without an encryption engine, because they are not worth intrusion or tampering with. Arbitrary encrypted information cannot be decrypted and is made worthless. Also, there is no additional information that may be encrypted and subsequently decrypted. This state may be used to produce a non-secure or “regular” card. In this way, the same system can be used to produce both secure and non-secure memory cards. The difference is that in a non-secure card, it is said that the card's security system is in a disabled state or that the card is more generally in state 170. The invalidation state is also returned to the factory for failure analysis and can therefore be used to re-ship the product that has been placed into the RMA state 160. As described above, after entering the RMA state 160, the card cannot return to any of the previous states and may not be resold as a secure card. However, a card that can function or can be re-functioned at the factory can be placed in the disabled state 170 and resold as a non-secure card. In this way, the card can be collected and becomes the same as a new non-secure or “regular” card for any intensive purpose. Both the recovered non-secure card and the new non-secure card will run the same firmware in the same state.

  Currently, the vast majority of cards are non-secure cards. Mainly due to demand from content providers, there is a growing movement to spread secure cards to the market, but what will be the future memory card sales percentage between secure and non-secure cards Is not clear. What is clear is that there is always a large number of non-secure content and therefore it is expected that there will be a demand for non-secure cards. The present invention not only allows all of the secure card hardware and software to be tested (by an authorized person only), but can also recover a variety of returned secure cards for non-secure use. In addition, the system of the present invention provides a card that has robust security but does not need to be discarded or compromised in order to perform failure analysis (accessible “loophole”). "). Considering that devices that use memory cards are becoming more popular, the ability to recover a defective secure card is a tremendous benefit for consumers and manufacturers alike.

  FIG. 3 shows a boot process for a memory card that executes the system described above. For further information on the boot process, see Mickey Holtzman et al., Co-pending U.S. Patent Application No. 11 / 284,623, “How to Check Memory Driver Firmware Hardware Driver Integrity” (Attorney Docket No. SNDK.408US1). ) (Patent Document 1). This patent application is incorporated herein by reference in its entirety.

  In step 302, the system checks whether the cryptographic hardware including the cryptographic engine 40 and other components is ready. The system waits for progress until the hardware is ready. When the hardware is ready, the system proceeds to step 304. In step 304, the system checks to see if the card is in state 170, i.e., the disabled state. If the card is in state 170, in step 306, the system uploads the boot loader (“BLR”), which is the minimum amount of start code, from flash memory 20 to RAM 11. Next, in step 308, the system checks to see if the BLR has been properly uploaded. If so, in step 310, the system uploads the firmware that needs to be run in non-secure mode (removing the cryptographic function from the standard firmware). As determined in step 308, if the BLR has not been uploaded properly, the system proceeds to step 324 described below.

  If, at step 304, the system determines that the card is not in state 170, the system clears the RAM content at step 312. Thereafter, the system performs a check again in step 314 to confirm which state the card is in. If the card is in state 120, 130, or 140, the BLR is uploaded in step 316. In step 318, the system checks to see if the BLR has been uploaded properly. Next, in step 320, a BLR code integrity check is performed. This integrity check is a hardware-based check that is performed by calculating a message authentication code (MAC) value and comparing that value to a reference value. The result of the integrity check is a simple flag stored in memory. In step 322, the firmware checks the flag to see if the integrity has been verified. If integrity is approved, it will be appreciated that the system can upload the firmware necessary to run in secure mode in step 342, thereby storing and retrieving non-secure data. If the integrity is not approved as determined in step 322, the system will use a diagnostic command (DLE) from the host to download and execute certain instructions from the host, as represented by step 324. Command). As can be seen from step 326, if a DLE command is received, the system proceeds to load the DLE code into RAM at step 328. In step 330, the DLE code is executed by the controller.

  If in step 314 it is determined that the card is not in state 120, 130, or 140, the system checks in step 332 to see if the card is in state 150. If so, the system uploads the BLR at step 334. This is done by ROM code. If the BLR upload is approved, as determined at step 336, at step 338, a hardware-based integrity check as described above at step 320 is performed. After this hardware-based integrity check, at step 340, another integrity check, in this case a software-based integrity check, is performed. If integrity is approved, it will be appreciated that the system can upload firmware that needs to be run in secure mode at step 342, thereby storing and retrieving non-secure data.

  If it is determined in step 332 that the card is not in state 150, the system checks the status of the card and whether the card is in state 160, and if so, the system is represented by step 348. Wait for a diagnostic command. However, if it is determined in step 344 that the card is not in state 160, the system waits for a command to proceed to RMA state 160, as can be seen from step 346.

1 is a schematic diagram of a system 10 according to one embodiment of the invention. FIG. 2 is a schematic diagram of another embodiment of system 10. Figure 5 is a flow chart illustrating various life cycle phases in one embodiment of the present invention. Table of various life cycle phases. It is a flowchart which shows a starting process and a life cycle phase.

Claims (40)

In the method of manufacturing a memory card,
Providing a test port on the memory die; and
A step of providing a security system,
A crypto engine,
An encryption key,
A test state in which the test port is available for hardware testing and a software test routine is available that enables operation of the cryptographic engine and software testing of the memory card;
Providing a security system comprising: an operating state in which the test port is unavailable and the software test routine is unavailable;
Testing the memory card software by utilizing the test state;
Providing a command from the host to the card to irreversibly switch the card from the test state to the operational state;
Including methods. In a method for testing functionality of a memory card including a non-volatile memory die having a test pad,
Testing the memory die before any firmware is loaded into the memory die and before becoming part of the memory card;
Loading the firmware into the memory of the memory die;
Changing the phase of the card to a first phase that allows testing of the hardware and software of the memory card;
Then testing the memory card hardware and software;
Then changing the phase of the card to a second phase that disables hardware and software testing of the memory card;
Including methods. The method of claim 2, wherein
The method wherein the test pad remains on the memory die when the die is mounted on the card. The method of claim 2, wherein
After the failure of the card, the method further includes the step of changing the phase of the card into a phase that enables testing of the memory card software and hardware for the purpose of failure analysis, and after entering the phase, the memory card Can not decrypt the encrypted data before entering the phase. The method of claim 2, wherein
The method wherein the phase indicator is stored in a non-volatile memory of the controller chip. The method of claim 2, wherein
In the second phase, no signal is transferred to and from the test pad. In a method of providing a secure storage device for data in a memory card,
Providing a flash memory in the memory card;
Providing a controller chip with an encryption engine for encrypting and decrypting data stored in the flash memory;
Storing a key in a non-volatile memory of the controller chip;
Encrypting a user of the data file of the card with the key before the file is stored in the flash memory chip;
Storing the encrypted data file in the flash memory;
Regenerating the key value so that the encrypted file cannot be decrypted if it is desired to use a card test mechanism;
Including methods. In a security system implemented in a memory card that can operate as either a secure card or a regular card,
A cryptographic engine that encrypts and decrypts information to protect the information stored on the card;
A secret key on the card used for the encryption and decryption; and
In a test state,
The encryption engine is activated,
When entering the test state, the secret key is generated,
The card firmware may be tested,
A test state in which the hardware of the card may be tested;
A secure operating state,
The card firmware is untestable,
The hardware of the card is untestable,
The encryption engine is activated,
A secure operating state in which the secret key is used by the encryption engine to encrypt and decrypt information;
In the bypass operation state,
The encryption engine is disabled,
The hardware of the card is testable;
The card firmware is testable,
If operating as a regular card, the bypass operating state is used,
A system comprising: The system of claim 8, wherein
A system in which the card is initially sold as a non-secure card configured in the bypass operational state. The system of claim 8, wherein
A system in which the card is initially sold as a secure card configured in the secure operating state. The system of claim 10, wherein
A system that is placed in the bypass operation state when the card that was originally sold as a secure card is returned to the manufacturer. The system of claim 11, wherein
A system in which the card is sold as a non-secure card after being placed in the bypass state. The system of claim 8, wherein
A system in which the encryption engine is hardware based. The system of claim 8, wherein
A system in which the secret key is stored in a non-volatile memory of the encryption engine. The system of claim 8, wherein
The hardware of the card is testable;
The card firmware is testable,
A system further comprising a failure analysis operating state, wherein the secret key is regenerated each time the system is activated in a failure analysis state. The system of claim 15, wherein
A system in which the card cannot be used again in the secure operation state after entering the failure analysis operation state. The system of claim 16, wherein
A system that is activated before the failure analysis operating state enters the bypass state. In a system for testing a memory card having firmware,
A test port on the integrated circuit die; and
A test mechanism in the firmware;
A security system, the security system comprising:
A crypto engine,
One or more test states of operations available during testing of the card that allow use of the test mechanism in the test port and the firmware;
A secure state of operation available during normal use of the card that prohibits the use of the test mechanism in the test port and the firmware;
Logic for switching between the test state of the one or more test states and the secure state, wherein when the card is switched to the secure state, accessing the one or more test states again Logic that prohibits access to secure data on the card by preventing access to the test mechanism and the test port in the firmware,
A system comprising: The system of claim 18, wherein
The system wherein the security system further includes a bypass operating state and the cryptographic engine is disabled. The system of claim 19, wherein
A system in which the bypass condition is used to produce a non-secure memory card. The system of claim 19, wherein
The bypass state is activated when the secure card is returned for inspection, thereby transforming the secure card into a non-secure card and collecting the card for further use. The system of claim 21, wherein
A system in which the non-secure card cannot be used again in a secure state after transformation. The system of claim 19, wherein
A new key used for encrypting and decrypting data is also provided with a failure analysis state and is generated at startup, and data encrypted with one key cannot be decrypted with another key system. 24. The system of claim 23.
A system that enters the failure analysis state before entering the bypass state. The system of claim 18, wherein
A system further comprising a final key state used to load final card used in the secure state into the card, wherein the test mechanism in the firmware is revoked in the final key state. The system of claim 25.
A system in which communication with the test port is not available in the final key state. In the memory card,
A security system implemented in the memory card that can be used to produce either a secure card or a non-secure card; and
A cryptographic engine designed to encrypt and decrypt information to protect the information stored on the card;
In a test state,
The encryption engine is activated,
The card firmware may be tested,
A test state in which the hardware of the card may be tested;
A secure operating state,
The card firmware is untestable,
The hardware of the card is untestable,
A secure operating state in which the encryption engine is enabled; and
A bypass operating state in which the encryption engine is disabled;
A memory card. The memory card of claim 27,
In the bypass operation state,
The hardware of the card is testable;
A memory card whose firmware can be tested. The memory card of claim 27,
A final key state,
The final key used in the secure operating state is utilized in the card;
The card is configurable;
The hardware test mechanism of the card is untestable;
A memory card whose software test mechanism is not testable. In flash memory card,
A security system, the security system comprising:
Two or more operating states in which the card operates in one operating state at a time;
Means for encrypting and decrypting data in the card;
Means for testing the card while the card is in the first state of the operating state;
Means for advancing the state of the card so that it cannot re-enter the previous state after having advanced to the previous state;
In one of the two or more operational states, means for encrypting and decrypting the data is available, but the means for testing the card is unavailable in the operational state, so that the test Means for controlling access to the data of the card so as to prevent unauthorized access to the data in the card via means for
With flash memory card. In flash memory card,
A security system, the security system comprising:
Two or more operating states in which the card operates in one operating state at a time;
An encryption engine for encrypting and decrypting data in the card;
A test mechanism available while the card is in the first state of operation;
Logic to advance the state of the card so that it cannot re-enter the previous state after it has advanced to the state,
A flash memory card that cannot be decrypted when data encrypted in at least one of the states continues to enter. In flash memory card,
A first integrated circuit die including a non-volatile flash memory for a large capacity data file;
A second integrated circuit die,
A microprocessor;
An encryption engine that encrypts and decrypts data;
Non-volatile memory;
A second integrated circuit die that enables operation of the encryption engine and comprises a secret key stored in the non-volatile memory of the second integrated circuit die;
In the normal operation mode, the memory card uses the first value of the secret key for encryption and decryption,
In the test mode, the memory card uses a second value of the secret key for encryption and decryption,
The second value cannot be used to decrypt data encrypted with the first value;
A flash memory card in which the first value cannot be used to decrypt data encrypted with the second value. In flash memory card,
An encryption engine for encrypting and decrypting data stored in the card;
A first operating state that tests the memory card to generate a first key that enables encryption and decryption using the encryption engine;
A second operating state for consumer use of the memory card that utilizes a second key to encrypt and decrypt data stored on the card;
The data encrypted with the first key cannot be decrypted with the second key, the data encrypted with the second key cannot be decrypted with the first key,
The encryption engine is testable in the first state, but data encrypted while the card is in the first state is read while the card is in the second state. Flash memory card that is impossible. 34. The memory card according to claim 33.
A memory card in which the value of the first key is changed each time the memory card is activated. 34. The memory card according to claim 33.
A memory card in which the value of the first key is constant. 34. The memory card according to claim 33.
A memory card in which the value of the first key is regenerated once every time the first operating state is entered. 34. The memory card according to claim 33.
A memory card in which the value of the second key is constant and stored in a non-volatile memory of the card. The memory card according to claim 37,
A memory card wherein the value of the second key is equal to the value of the first key stored last in memory during the first state. 34. The memory card according to claim 33.
A memory card in which hardware and firmware test mechanisms are available for testing in the first state. 34. The memory card according to claim 33.
A memory card in which hardware and firmware test mechanisms are not available for testing in the second state.

Images