TWI402755B - Secure memory card with life cycle phases - Google Patents

Description

Secure memory card with life cycle

The present invention relates generally to memory cards and encryption, and in particular to the elimination of access to secure data and keys by the testing mechanism in the card.

Not long ago, an intelligent memory card, often referred to as a smart card, was developed and accepted in the form of identification and payment. The smart card contains a small amount of memory for storing a user's identification data and for storing transaction related materials. Smart cards are also often referred to as chip cards and are used in Japan for various things (such as national identity cards) and various places, such as a type of credit card or debit card. To prevent identity theft and other currency scams, various chip design and encryption schemes have been employed in such cards and systems utilizing such cards.

There are two competing benefits when designing and manufacturing any type of secure memory card. One benefit is to maximize the security of the card, and another benefit is to maximize the reliability of the card. In order to maximize the reliability of the card, the software and hardware of the card can be tested at various manufacturing stages before the card is shipped from the factory, and at some point, even after the card has left the factory, the software and hardware of the card are tested to perform the failure. Analysis is important. The test can include testing the input and output of the test pad or contact pad on the wafer to test both the hardware and the soft body of the card. These test routines and test pads are required to ensure quality control, but are one of the card's safety data, algorithms and keys, or a "back door." Therefore, there is always some degree of compromise between maximizing reliability and maximizing security (required for testing). Different methods have been proposed to close this "back door" after the test is completed. However, for various reasons, the previous solutions to date have their own commercial and technical disadvantages.

In a method in which the Xianxin letter is used in the manufacture of the aforementioned smart card, the die of the card is tested before the memory die from the wafer is singulated. The test pads for a particular die are positioned on one of the adjacent dies of the wafer, and after testing, the singulation process separates the test pads from all of the adjacent dies. Therefore, as one of the security materials of the last memory card, any test pads that exist on the monolithic die are potentially isolated and closed. However, completely removing the test pad is not always practical or desirable. For example, the lack of available test pads precludes some amount of memory from subsequent hardware-based tests that, for example, limit the potential methods of failure analysis.

Although this method may be better for a smart card (which usually only has a small amount of memory necessary to store identification and transaction data), it is used for testing large quantities of large files (such as photos and music). The relatively large amount of memory used in memory cards and the complex safety routines are insufficient. Some examples of such mass storage memory cards are compact flash memory cards, MMC cards, and SD cards. The dissemination of digital content and related copyright issues have increased the importance of security, but at the same time, the testing and reliability of the card is still extremely important. There is a need for a more comprehensive and flexible system for manufacturing, testing and operating a mass storage secure memory card and the system is provided by the invention as will be described below.

Another important aspect is cost. Several different technologies, such as non-volatile memory, logic, and volatile memory, can be fabricated on a single integrated circuit die (wafer). However, mixing different technologies in one die results in a significant increase in production costs. In a competitive environment where cost is the primary driver, there is an extreme need to limit the amount of different technologies offered on a die. However, the use of multiple dies may mean that in the final product, sensitive information has to pass from one die to another. This is another potential weakness that hackers can use if appropriate safeguards are not used.

In particular, it is expensive to mix non-volatile memory bits with logic within the same die. The smart card uses the non-volatile memory used for data storage in the same die as the logic for operating the smart card, which is one way to maximize security. However, today, a memory card that benefits from the present invention must store larger music, photos, movies, and other user profiles. Therefore, from the cost consideration, manufacturing a single integrated circuit die memory card that can store a large amount of information (in 2005, it is about billions of bytes and still increasing) is prohibited, and it is necessary to develop a plurality of Safety system for the die. In particular, it is highly desirable to create a secure system (using encryption and decryption) that utilizes one or more discrete (cost-saving) flash memory dies that are separated from the controller die. It can be thoroughly tested before and after assembly, via testing mechanisms, and is not easily attacked.

An alternative system has been developed because the use of a single wafer having both controller functionality and the large storage required by today's digital devices is overly expensive and problematic in terms of adjustable capability. For a single wafer solution, security can be achieved with a unique wafer design that makes access testing mechanisms, encryption keys, and encrypted content difficult. However, for multi-chip designs where content is transferred from a separate memory die to a controller wafer (encrypted therein), special care must be taken to protect access to the encryption key and encrypted content. In addition, in a system where the final assembly (preferably) still has a test pad to allow testing of the assembled system, special care must be taken in software and hardware that may be used as an unauthorized access to the encrypted secret. Key and any organization behind the content.

The present invention has numerous life cycle stages that enter and pass during the life of the card. Depending on the stage, the logic in the card enables or disables the encryption engine, controls access to the hardware (before and after wafer singulation and card assembly) and software testing mechanisms, and controls key generation. These phases not only allow the hard drive and the soft body of the card to be thoroughly tested before and after manufacture (unlike the smart card with the test pad removed), but also when the card is in a safe phase (the card is shipped to use) Accessing the encrypted key and thus the encrypted content is virtually impossible when it is in the operational phase. Accordingly, the present invention provides a memory card that can be well tested, but which also resists unauthorized access to protected material in the card.

In addition, there is a need for a more comprehensive and flexible system for manufacturing, testing and operating a mass storage secure memory card and the system is provided by the invention as will be described below.

The accompanying drawings, which are incorporated in the claims Accordingly, all patents, patent applications, articles, and other publications referenced herein are hereby incorporated by reference in their entirety in their entirety.

Memory system architecture

An example memory system in which various aspects of the invention may be constructed is illustrated by block diagram 1A. 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. The memory system 10 communicates with the host device 24 via a host interface bus 26 and port 26a. Flash memory 20 (which may be of the NAND type) provides data storage for host device 24. The software code of the CPU 12 can also be stored in the flash memory 20. The FIM 18 is coupled to the flash memory 20 via a flash interface bus 28, and in some cases, if the flash memory 20 is a removable component, the FIM 18 is flashed via a port (not shown). Memory 20. The HIM 16 is adapted to be connected to a host system such as a digital camera, a personal computer, a personal digital assistant (PDA) and an MP-3 player, a mobile phone or other digital device. Peripheral access module 22 selects appropriate controller modules (such as FIM, HIM, and BMU) for communication with CPU 12. In one embodiment, all of the components of system 10 within the dashed box may be enclosed in a single unit, such as enclosed in a memory card and preferably enclosed 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, and a register 33. A buffer random access memory (BRAM) 38 and a cryptographic engine 40 (also referred to as encryption engine 40). The arbiter 36 is a shared bus arbiter such that only one master or initiator (which may be HDMA 32, FDMA 34 or CPU 12) may be active and the slave or target is BRAM 38 at any time. The arbiter is responsible for channelizing the appropriate initiator request to the BRAM 38. HDMA 32 and FDMA 34 are responsible for data transfer between HIM 16, FIM 18 and BRAM 38 or RAM 11. The CPU bus arbitrator 35 allows data to be transferred directly from the cryptographic engine 40 and the flash DMA 34 to the RAM 11 via the system bus 15 and in some cases (such as when bypassing the cryptographic engine is required) to use the system bus . The operation of HDMA 32 and FDMA 34 is conventional and need not be detailed herein. The BRAM 38 is used to store data transferred between the host device 24 and the flash memory 20. HDMA 32 and FDMA 34 are responsible for transferring data between HIM 16/FIM 18 and BRAM 38 or CPU RAM 12a and are responsible for indicating sector completion.

When the data from the flash memory 20 is read by the host device 24, the encrypted data in the memory 20 is via the bus bar 28, the FIM 18, the FDMA 34, and the cryptographic engine 40 (the encrypted data is decrypted therein). ) to extract and store in BRAM 38. Then, the decrypted data is transmitted from the BRAM 38 to the host device 24 via the HDMA 32, the HIM 16, and the bus bar 26. The data extracted from the BRAM 38 can be re-encrypted by means of the cryptographic engine 40 before it is passed to the HDMA 32, so that the data sent to the host device 24 is re-encrypted, but stored in the memory 20 by means of an encryption and encryption. The keys and/or algorithms used by the data are different from their keys and/or algorithms. Alternatively, unlike the process in which the decrypted material is stored in BRAM 38 (which can make the data vulnerable to unauthorized access attacks), data from memory 20 can be sent to BRAM 38. It was previously decrypted and encrypted by the cryptographic engine 40. Next, as described above, the encrypted material in the BRAM 38 is sent to the host device 24. This illustrates the flow of data during a read.

When the data is written to the memory 20 by the host device 24, the data flow is in the opposite direction. For example, if the unencrypted data is sent to the cryptographic engine 40 by the host device, via the busbar 26, the HIM 16, and the HDMA 32, the data may be sent by the engine 40 before it is stored in the BRAM 38. encryption. Alternatively, unencrypted material can be stored in BRAM 38. The data is then encrypted prior to being sent to the FDMA 34 on its way to the memory 20.

Life cycle stage

A security system or a secure operating system (such as the system described above) that is particularly useful when constructed in a memory card has different phases or states. Preferably, these stages are entered in sequence such that after progressing from one stage to the next, the previous stage cannot be re-entered. Therefore, these stages can be considered as life cycle stages.

Before describing these stages in detail, another system level map will be briefly discussed. FIG. 1B illustrates another embodiment of system 10. For the sake of simplicity and clarity, only certain components of system 10 are illustrated in this figure. The memory system 10 includes a test pad (also referred to as a hardware test input/output (I/O) terminal) 54. The hardware bus bar (HW bus bar) 56 is preferably connected to the test pad 54. These test pads and HW bus bars 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. JTAG bus bar 62 is coupled to system bus 15 (see FIG. 1A) and can be used to replace the controller firmware and drive hardware blocks from outside of system 10. It is used for hardware testing that requires a scratchpad read/write operation. Because the JTAG bus 62 can access the RAM and ROM, it is also used to test the firmware of the system 10. The host bus 26 is used to send diagnostic commands to the system 10 and to test the firmware of the system.

The NVM 50 of the encryption engine 40 is also shown. The lifecycle state 77 (value) and secret key 99 stored in the NVM 50. The NVM test 58 is used to test the NVM in the encryption engine 40.

Status indicator fuse 66 is used to indicate that the product is in NVM state 110 (described below) without relying on NVM content. The reason for this is that the reliability of one of the initial values stored in the NVM during manufacturing cannot be guaranteed. Therefore, another, more reliable indicator is used, such as the use of a fuse. If the fuse is set, the system determines that the product is in state 110. If system 10 is reset, it will look at NVM lifecycle state 77 to determine the state.

Figure 2A illustrates the order of transitions between various states and states. Before and after the card is manufactured, each state defines the different behaviors and capabilities of the card (or other system in which the card is constructed), as shown in the following table, which is also reproduced in Figure 2B.

The state is preferably stored as a value of one of 32 bits in the non-volatile memory of the encryption engine. There are 6 pre-allocated values from a large number ( ^~ 10 ⁹ ) of possible combinations representing the state 120-170. All other values indicate state 110. This is because there is no guarantee that a certain value can be reliably stored during manufacture and subsequent retrieval, as various processing operations during manufacturing, assembly, testing, and shipping may alter any stored value in the memory.

The key value is also preferably stored as one of the 128-bit fields in the non-volatile memory of the encryption engine. The key value is typically generated randomly by a seeded algorithm. The re-generation of the key is highly likely to change the value of the key, but this cannot be guaranteed because a (pseudo) random number generator may in fact possibly produce the same value continuously. However, even if the value of the key is not changed during the re-generation, the term of the change key is used interchangeably with the term re-generating the key in this application. It goes without saying that the value of the key used to encrypt the information is crucial. The same key value must be used for both encryption and decryption. Therefore, if a key value is regenerated when each power of the system is turned on, the encrypted data before the power is turned on is in fact invaluable because it cannot be decrypted with the new key. Although the data is still physically present in the memory of the card, the data is useless if there is no appropriate key value to unlock. Therefore, if a hacker somehow forces the card to retreat to a state other than the security state 150, he cannot obtain any useful information. In states 110 and 160, a new key will be generated each time the power is turned on, and in state 150, the key previously used to store the information will not be available to decrypt the information. In states 170 and 110, the encryption engine is completely unavailable regardless of the key value.

Another security measure includes limiting the availability of firmware and hardware testing mechanisms. The system contains logic to enable or disable such mechanisms. The previously described host bus is one of the mechanisms used to test the firmware of the card. The host can issue a diagnostic command via the host bus to test the firmware. This hardware can also be tested when these instructions are executed. The hardware can also be directly tested via the hardware bus and the JTAG, which provides direct access to various memories of the system. Please note that in states 140 and 150, the NVM test mechanism, HW test mechanism, and FW test mechanism are all disabled.

The channels between the states and states as shown in Figure 2A will now be further detailed.

State 110 refers to controller non-volatile memory (NVM) testing. This state is the initial state after the memory die is fabricated and is used to test the state of the non-volatile memory of the controller die before packaging the die and mounting it into the memory card. Tests that occur in this state can be performed prior to singulation and the dies are still integrated in wafer format, or the test can be performed on individual dies instead of singulation. Once the NVM is tested, its contents (using the NVM tester) are initialized to indicate state 120 and the fuse 66 is blown. In this state, the encryption engine 40 is disabled. During the life cycle of the card, this state is only designed to enter once, and there is no method available in the system to return the card to this state. However, as previously described, this state may be indicated by any of the six pre-allocated values other than the many possible combinations of 32-bit values used to define the lifecycle state. If an illegal value is detected and the fuse is blown (not allowed to enter the NVM state 110), the crypto engine will not be ready and the system will not start, or bypass step 302 described below with reference to FIG. Therefore, each time the card is powered on and in this state, a new key will be randomly generated and it is impossible to decrypt the previously encrypted material. Even if the crypto engine is not enabled in this mode (because the mode is designed to be used while the wafer is still intact during manufacturing), the key is regenerated every time the power is turned on to protect it from a hacker The hacker may enter this state in some unpredictable ways and attempt to detect the security information of the card via various test mechanisms and mechanisms. Additionally, by design, after exiting state 110, the NVM testing mechanisms will no longer be available.

State 120 is referred to as a constant energization state. In this state, the encryption engine 40 is enabled. The key that the encryption engine will use is not generated by the random number generator and is not stored in memory, but is hardwired to some external source and is constant during this phase. Hardware and software testing mechanisms are available in this state. This state is entered by a hardware tester.

State 130 is referred to as a random empowerment state. This state is similar to state 120, however, the secret key is randomly generated (once) when entering state 130 and is not constant and hardwired. This is used for the final test, characterization, and qualification of the memory card. Using a firmware that uses a secret key or a key derived from the secret key, including cryptographic operations for encryption and decryption is possible. This state is entered by the code loaded into system 10 via host device 24 and then executed by system 10.

State 140 is referred to as the final key state. In this state, the card uses the last secret key that will be shipped with the card. The hardware and software testing mechanisms are enabled and cannot be accessed by the logic of the card. This includes hardware test busbars and test pads (see Figure 1B). This state is used to load the card with the final firmware and configuration data that must be protected with the key shipped with the product. The product can be configured in this state, but not in state 150. This state is entered by a host command. The instruction may be included in a code downloaded from the host and executed by the card ("DLE Code"). This instruction can alternatively be issued directly from the host. This is true when the term DLE code is used at any time below.

State 150 is referred to as a secure state. This is the state of the card when it is shipped from the factory. The hardware and software testing mechanisms are capable of being accessed by the logic of the card. This status is entered at the end of the manufacturing site test and configuration product. The key is not regenerated and the value stored in memory during state 140 is utilized during state 150. While the derived keys can be used for various operations of the card, the key 99 is always required to derive their keys and encrypt and decrypt the data. This key is intended to be used for the validity period of the security card (when it is used as a security card in the hands of the consumer, not later). The firmware in the card cannot use the secret key for any operation. The hardware of the encryption engine is responsible for performing all encryption and decryption in the card. This state is entered by the DLE code.

State 160 is referred to as the returned merchandise authorization or RMA state. This state is designed to allow testing of a card that is returned by a consumer because it is not working properly. This is the status of the failure analysis of the executable card. Software and hardware testing mechanisms are available again. Note that this state is only important for factory accessible systems. In addition, after entering the RMA state, the card must never be used again as a security card. In other words, the card must never enter state 150 again or otherwise be used to decrypt information resident on the card or to save the encrypted information to the card. The secret key is regenerated when entering this mode, and each chip is reset during execution while the card is in this state. The operation of decrypting using a secret key is only enabled at boot time and the firmware cannot use the secret key for any operation. This state is entered by a ROM code that is the result of the host command.

State 170 is referred to as the de-energized state. In this de-energized state, the crypto engine 40 is in a bypass mode and all cryptographic capabilities are disabled. Only non-secure algorithms can be used in this card. Because there is no encryption engine, intrusion or other interventions are of no value, so the hardware and software testing mechanisms are re-enabled. Any encrypted information can no longer be decrypted and becomes worthless. Again, no additional information can be encrypted and subsequently decrypted. This state can be used to produce an unsecure or "normal" card. In this way, the same system can be used both for the production of secure memory cards and for the production of non-secure memory cards. The difference is that in a non-secure card, the card security system is in an disabled state, or, more generally, the card can be in state 170. The de-energized state can also be used to re-ship a product that has been sent back to the factory for failure analysis and thus has entered the RMA state 160. As mentioned above, after a card enters the RMA state 160, it must never return to any of the previous states and must never be sold again as a security card. However, a card that is functional or can be remanufactured at the factory can be placed in the disengaged state 170 and sold as a non-secure card. In this way, the card can be recycled and used for all deep uses like a new non-secure or "normal" card. The recycled non-secure card and a new non-secure card can operate the same firmware in the same state.

Most cards are now non-secure cards. While the power to bring security cards to market is high (which is primarily due to the needs of content providers), it is unclear what percentage of future memory card sales will be compared to non-secure cards. It is clear that there is likely to be a lot of non-secure content and therefore there is a need for non-secure cards. The present invention not only allows testing of all hardware and software of a security card (only by authorized personnel), but also provides the ability to recycle the returned security card for use by a variety of non-secure users. In addition, the system of the present invention allows for a card with robust security, but it does not need to be revoked or compromised by the security system (with an accessible "back door") to perform fault analysis. Because of the widespread dissemination of devices that use memory cards and the increasing proliferation, the ability to recycle cards that can otherwise become a defective security card is of great benefit to consumers and manufacturers.

Figure 3 illustrates the startup process for constructing a memory card of the above system. For more information on the start-up process, please refer to the application "Method of Hardware Driver Integrity Check Of Memory Card Controller Firmware", application No. 11/284, 623, and the agent's case. No. SNDK.408US1, which is incorporated herein by reference in its entirety.

In step 302, the system checks if the password hardware (including the cryptographic engine 40 and other components) is ready. The system will wait until the hardware is ready to continue. When the hardware is ready, the system proceeds to step 304. In step 304, the system checks if the card is in state 170 (de-energized state). If the card is in state 170, then in step 306, the system uploads a boot loader ("BLR") from flash memory 20 to RAM 11, which is the minimum amount of boot code. Next, in step 308, the system checks if the BLR is fully uploaded. If so, then in step 310, the system will upload the firmware required for operation in non-secure mode (standard firmware minus password function). If the BLR fails to be fully uploaded as determined in step 308, the system will proceed to step 324 below.

If, in step 304, the system determines that the card is not in state 170, then the system will clear the RAM content in step 312. After the step, the system will again check in step 314 what state the card is in. If the card is in state 120, 130 or 140, the BLR will be uploaded in step 316. In step 318, the system will check if the BLR is fully loaded. Next, in step 320, an integrity check of the BLR code will be performed. This integrity check is a hardware-based check performed by computing a message authentication code (MAC) value and comparing the value to a reference value. The result of this integrity check is a simple flag stored in memory. In step 322, the firmware checks the flag to determine if the integrity is verified. If the integrity is verified, the system will upload the firmware necessary for operation in safe mode in step 342, which of course allows for the storage and retrieval of non-secure data. If the integrity is not verified as determined in step 322, the system will wait for a diagnostic command from the host to download and execute certain instructions from the host (DLE instructions) as represented by step 324. If a DLE instruction is received as shown in step 326, the system will continue to load the DLE code into RAM in step 328. In step 330, the DLE code will be executed by the controller.

If it is determined in step 314 that the card is not in state 120, 130 or 140, then the system will check in step 332 if the card is in state 150. If so, the system will then upload the BLR in step 334. This is done by the ROM code. If the BLR loading is complete as determined in step 336, then a hardware based integrity check will be performed in step 338, as described in step 320 above. After this hardware-based integrity check, another integrity check (this time a software-based integrity check) will be performed in step 340. If the integrity is verified, the system will then upload the firmware necessary for operation in safe mode in step 342, which of course also allows for the storage and retrieval of non-secure data.

If it is determined in step 332 that the card is not in state 150, the system will then check the status of the card and whether the card is in state 160, and if so, it will wait for a diagnostic command indicated by step 348. However, if it is determined in step 344 that the card is not in state 160, the system will wait for an instruction to enter the RMA state 160 (see step 346).

10. . . Memory system/system

11. . . RAM

12. . . Central Processing Unit (CPU) / Controller / CPU

12a. . . CPU RAM

14. . . Buffer Management Unit (BMU)

15. . . System bus

16. . . Host Interface Module (HIM) / HIM

18. . . Flash Interface Module (FIM)/FIM

20. . . Flash memory/memory

twenty two. . . Peripheral access module

twenty four. . . Host device

26. . . Host interface bus/bus

26a. . . port

28. . . Flash interface bus/bus

32. . . Host direct memory access unit / HDMA

33. . . Register

34. . . Flash direct memory access unit / FDMA / flash DMA

35. . . CPU bus arbiter

36. . . Arbitrator

38. . . Buffer random access memory/BRAM

40. . . Password engine / encryption engine / engine

50. . . NVM

54. . . Hardware Test Input/Output (I/O) / Test Pad

56. . . Hardware bus/HW bus

58. . . NVM test埠

62. . . JTAG bus

66. . . Status indicator fuse/fuse

77. . . Life cycle state

99. . . Secret key/key

FIG. 1A is a schematic illustration of a system 10 in accordance with an embodiment of the present invention.

FIG. 1B is a schematic diagram of another embodiment of system 10.

2A is a flow chart illustrating various life cycle stages in an embodiment of the present invention.

Figure 2B is a table of various life cycle stages.

Figure 3 is a flow chart illustrating the startup process and the life cycle phase.

110. . . NVM status

120. . . Constant energization state

130. . . Random empowerment state

140. . . Last key status

150. . . Security status

160. . . RMA status

170. . . De-enable state

Claims (22)

A method of operating a memory card, comprising: performing a plurality of steps in a host when a host is coupled to a memory card, wherein the memory card includes a memory die having a test cartridge and a security system, and The memory card can be operated in a test, operation, failure analysis and de-energization state. The security system includes: a cryptographic engine and a cryptographic key, wherein the test 埠 can be used for hardware testing and software testing in the test state. The routine can be used to enable the operation of the cryptographic engine and the testing of the software of the memory card, wherein in the operating state, the testing system is not available, the software testing routine is unavailable, and the memory card is grouped. When the state is to operate as a secure memory card, and the cryptographic engine is enabled and the memory card operates as an unsecure memory card, the power-off state is irreversible, and the steps include: when the memory card is in the test In the state, testing the memory card software; transmitting an instruction to the memory card to cause the memory card to irreversibly switch from the test state to the operating state; and detecting one of the memory cards Thereafter, the memory card is operated in the fault analysis state of the fault test of the software and the hardware that enables the memory card, preventing the memory card from decrypting the previously stored information on the memory card or entering a safe operation state. And configuring the memory card so that the memory card can only be switched to the disabled state. The method of claim 1, wherein the indicator of one of the current states of the memory card is stored in one of the non-volatile memories of the memory card. The method of claim 1, wherein causing the memory card to operate in the fault test state causes the memory card to generate a new key value each time the power is turned on in the fault analysis state, and wherein the last time The power is turned on and the data cannot be encrypted by the memory card before decryption. A security system constructed in a memory card, comprising: a cryptographic engine configured to encrypt and decrypt information to preserve information stored on the memory card; and a secret key in the memory card For encryption and decryption, wherein the security system operation is switched between a test state, a secure operation state, and a bypass operation state, wherein in a test state, the encryption engine is enabled, and the secret key is entered into the After the test state is generated, the test of the firmware in the memory card is enabled, and the test of the hardware of the memory card is enabled, wherein in the safe operation state, the cryptographic engine is enabled, and the memory card is The firmware test is disabled, the hardware test of the memory card is disabled, and the secret key is used by the encryption engine to encrypt and decrypt the information, and in the bypass operation state, The encryption engine is disabled; the test of the hardware of the memory card is enabled, the test of the firmware of the memory card is enabled, and if the memory card operates as a normal memory card, the bypass operation is used. a state in which the security system operates the memory card to operate as a non-secure memory card and cannot be switched to the safe operating state again once in the bypass operating state. The system of claim 4, wherein the encryption engine is hardware based. The system of claim 4, wherein the secret key is stored in one of the non-volatile memories of the encryption engine. The system of claim 4, further comprising: a fault analysis operation state, wherein: the hardware of the memory card can be tested; the firmware of the memory card can be tested; and the secret key is tied to the fault whenever In the analysis state, the power is regenerated when the system is turned on. The system of claim 7, wherein the memory card is never used again in the safe operating state after entering the fault analysis operational state. The system of claim 8, wherein the fault analysis operational state is initiated prior to entering the bypass state. The security system of claim 4, wherein the test status comprises one or more test states available during testing of the memory card, the test states permitting use of the test on an integrated circuit and in the memory Test mechanism in the firmware of the card; Wherein the safe operating state is available during normal use of the memory card, the safe operating state prohibiting the use of the test and the testing mechanisms in the firmware; and wherein the memory card is further included for use in the or a logic for switching between one of the test states and the safe operating state, wherein once the memory card is switched to the safe operating state, the or the test state is never accessed again, thereby preventing Accessing the test mechanisms in the firmware and the test files to disable access to the security material on the memory card. The system of claim 10, further comprising a failure analysis state, wherein a new key for encrypting and decrypting data is generated each time the power is turned on, and wherein the data encrypted by one key cannot be another secret Key to decrypt. The system of claim 11, wherein the fault analysis state is entered before the bypass state can be entered. The system of claim 10, further comprising a final key state for loading a final firmware to be used in the secure state to the memory card, the test mechanism in the firmware being at the last key The state is removed. A system as claimed in claim 13, wherein in the final key state, communication with the test cartridges is not available. The system of claim 4, further comprising a final key state, wherein: a final key usable in the secure operating state is utilized for the In the memory card; the memory card can be configured; the hardware testing mechanism of the memory card cannot be tested; and the software testing mechanism of the memory card cannot be tested. A flash memory card includes: an encryption engine that encrypts and decrypts data stored in the flash memory card; and a first operational state for testing the flash memory card, wherein the flash memory card is generated a first key, the first key uses the encryption engine to enable encryption and decryption; a second operational state used by the consumer of the flash memory card, wherein the flash memory card operates as a security a memory card, wherein the flash memory card uses a second key to encrypt and decrypt data stored in the flash memory card, wherein a value of the second key is constant and stored during the second operating state Determining, in one of the non-volatile memory cards of the flash memory card, a third operational state of a bypass operation state, wherein the flash memory card operates as a non-secure memory card, and wherein in the third operational state Go to the encryption engine, enable the hardware test of the flash memory card, and enable the firmware test of the flash memory card, and wherein the flash memory card is configured to make the flash memory card Cannot be heavy after the second state transition Entering the second operating state, and wherein the first key to encrypt the data can not be decrypted with the second key and the second key to the encrypted data can not decrypt the first key, and The encryption engine can be tested in the first state, but when the flash memory card is in the second state, the data encrypted when the flash memory card is in the first state cannot be read. The flash memory card of claim 16, wherein the value of the first key changes each time the flash is turned on. A flash memory card as claimed in claim 16, wherein the value of the first key is constant. The flash memory card of claim 16, wherein the value of the first key is regenerated once each time the first operational state is entered. The flash memory card of claim 16, wherein the value of the second key is equal to the value of the first key last stored in the memory during the first state. The flash memory card of claim 16, wherein in the first state, the hardware and firmware testing mechanisms are available for testing. The flash memory card of claim 16, wherein in the second state, the hardware and firmware testing mechanisms are not available for testing.