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

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. In order 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 prior to 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 cryptographic engine will not be ready and the system will not start 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 look for 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 (29)

A memory card operating method ,
The memory card includes a memory die provided with a test port and a security system, the memory card is operable in a test state, an operation state, a failure analysis state, and an invalidation state, and the security system includes an encryption engine and a cipher Including the key
During test state, the test port is available for hardware testing, and Ri operation and the software test routines to enable testing of the memory card software available Der of the encryption engine,
During operation state is the test port is unavailable, the software testing routine Ri impossible der utilized and the memory card is configured to operate as a secure memory card,
During the disabled state, the disabled state is irreversible, the encryption engine is disabled, and the memory card operates as a non-secure memory card,
When the host is connected to the memory card,
Testing the memory card software while the memory card is in the test state ;
And transmitting the irreversibly switched commands the memory card to the operating state from the test state, before Symbol memory card,
Upon detecting a failure of the memory card, the software and hardware test of the memory card is validated, and the memory card again decrypts information already stored on the memory card or enters a secure operating state And operating the memory card during a failure analysis state to configure the memory card so that the memory card can only transition to an invalidation state;
Wherein the host executes . The method of claim 1 , wherein
A method in which an indicator indicating the current state of the memory card is stored in a non-volatile memory of the memory card . The method of claim 1, wherein
By operating the memory card during the failure analysis state, the memory card generates a new key value at each startup in the failure analysis state, and the memory card generates data encrypted before the most recent startup. That can not be decrypted. A security system is realized either as operatively memory cards of the secure card or a regular card,
To protect the information stored in the memory card, and configured encryption engine to encrypt information, and decoding,
A secret key in the memory card used for the encryption and decryption ,
The security system is operable with respect to transitions between test state, secure operating state, bypass operating state;
During the test state,
The encryption engine is activated,
When entering the test state, the secret key is generated,
Firmware test of the memory card is enabled,
Hardware test of the memory card is enabled,
It said in a secure operating state,
Firmware test of the memory card is disabled,
Hardware test of the memory card is disabled,
The encryption engine is activated,
The secret key is used by the encryption engine to encrypt and decrypt information ;
During the bypass operating state,
The encryption engine is disabled,
Hardware test of the memory card is enabled,
Firmware test of the memory card is enabled,
If operating as a regular card, the bypass operation state is used, and when the bypass operation state is entered, the security system cannot transition to the secure operation state again . The system of claim 4 , wherein
A system in which the memory card is initially sold as a non-secure card configured during the bypass operating state. The system of claim 4 , wherein
A system in which the memory card is initially sold as a secure card configured during the secure operating state. The system of claim 6 , wherein
A system in which the memory card that is initially sold as a secure card is put into the bypass operation state when returned to the manufacturer. The system of claim 7 , wherein
A system for selling the memory card after the bypass operation state as a non-secure card. The system of claim 4 , wherein
A system in which the encryption engine is hardware based. The system of claim 4 , wherein
A system in which the secret key is stored in a non-volatile memory of the encryption engine. The system of claim 4 , wherein
Hardware test of the memory card is enabled,
Firmware test of the memory card is enabled,
A system further comprising a failure analysis operating state, wherein the secret key is regenerated each time the system is activated during a failure analysis state. The system of claim 11 , wherein
Wherein After entering the failure analysis operating state, it can not be used again the memory card in secure operating state system. The system of claim 12 , wherein
System the failure analysis operating state, which is activated prior to entering the bypass operating state. The system of claim 4, wherein
The test conditions, the use of firmware near Rute strike mechanism Te Sutopoto and the memory card are possible, including one or more test conditions of available operations during testing of the memory card,
The secure operating state, prohibit the use of firmware near Rute strike mechanism Te Sutopoto and the memory card are available during normal use of the memory card,
The memory card may further comprising one or more logic for switching between one test state and secure operation state of the test conditions, when switched to the memory card Gase cure state, the can not be re-access one or more test conditions, by preventing access to the firmware near ruthenate strike mechanism and the test port, Cie to prevent access to the secure data on the memory card Stem. The system of claim 14 , wherein
Failure analysis state further comprising a new key used to encrypt and decrypt the data is generated for each time of startup, it is impossible to decrypt the encrypted data in a certain key on another key system. The system of claim 15 , wherein
Prior to entering the bypass operating conditions, the system entering the failure analysis state. The system of claim 14 , wherein
Se further comprising a final key state used to load the final firmware used during cure operation state to the memory card, the final firmware near ruthenate strike mechanism is disabled during the final key state system. The system of claim 17 , wherein
A system in which communication with the test port becomes unavailable during the final key state. A 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
To protect the information stored in the memory card, the encryption engine designed to encrypt and decrypt information,
In a test state,
The encryption engine is activated,
The memory card firmware may be tested,
A test state in which the memory card hardware may be tested; and
A secure operating state,
The firmware of the memory card is untestable,
The memory card hardware 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 according to claim 19 ,
During the bypass operation state,
The memory card hardware is testable;
A memory card in which firmware of the memory card can be tested. The memory card according to claim 19 ,
A final key state ,
The final key to be used in a secure operating state is utilized in the previous Symbol memory card,
The memory card is configurable;
The hardware test mechanism of the memory card is untestable,
A memory card whose software test mechanism is not testable. A flash memory card,
An encryption engine for encrypting and decrypting data stored in the memory 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 to use the second key to encrypt and decrypt data stored in the memory card,
A third operating state defining a bypass operating state, wherein the operation of the encryption engine is disabled, the memory card hardware test is enabled, and the memory card firmware test is enabled; ,
With
Configuring the memory card so that the memory card cannot re-enter the second operating state after transitioning from the second operating state;
First key encrypted data previously in SL can not be decrypted with a second key, the encrypted data in the second key can not be decrypted before Symbol first key,
Although the encryption engine can be tested in a first operating state, the memory card is encrypted while in the first operating state data, while the memory card is in the second operating state memory card can not Succoth read out. The memory card according to claim 22 ,
A memory card in which the value of the first key is changed each time the memory card is activated. The memory card according to claim 22 ,
A memory card in which the value of the first key is constant. The memory card according to claim 22 ,
A memory card in which the value of the first key is regenerated once every time the first operating state is entered. The memory card according to claim 22 ,
A memory card in which a value of the second key is constant and stored in a nonvolatile memory of the memory card. 27. The memory card according to claim 26 .
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 operating state. The memory card according to claim 22 ,
During said first operational state, the memory card hardware and firmware test mechanisms for testing is available. The memory card according to claim 22 ,
A memory card in which hardware and firmware test mechanisms for testing are not available during the second operating state.

Images