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

Abstract

A secure memory card with encryption capabilities comprises various life cycle states that allow for testing of the hardware and software of the card in certain of the states. The testing mechanisms are disabled in certain other of the states thus closing potential back doors to secure data and cryptographic keys. Controlled availability and generation of the keys required for encryption and decryption of data is such that even if back doors are accessed that previously encrypted data is impossible to decrypt and thus worthless even if a back door is found and maliciously pried open.

Description

SECURE MEMORY CARD WITH LIFE CYCLE PHASES

The present invention relates generally to memory cards and encryption, and in particular to removing access to secure data and keys through the card's inspection mechanisms.

In the past, intelligent memory cards, commonly referred to as smart cards, were developed and accepted in the market as forms of identification and payment. The smart card includes a small amount of memory for storing user identity data and for storing contract related data. Smart cards are also often referred to as chip cards and used in Japan for various things such as national ID cards and in various places in the form of credit cards or debit cards. In order to prevent identity theft and other financial fraud, various chip designs and encryption methods have been used in cards and systems using the cards.

When designing and manufacturing any type of secure memory card, there are two opposing concerns. One concern is to maximize the security of the card and the other concern is to maximize the reliability of the card. In order to maximize the reliability of the card, it is important to be able to inspect the card's software and hardware at various manufacturing stages and in some cases even after leaving the factory to perform defect analysis before it is shipped from the factory. The inspection may include input and output of signals via inspection or contact pads on a chip to inspect both the hardware and software of the card. These inspection routines and inspection pads are necessary to ensure quality control, but a potential weakness or “backdoor” for the card's security data, algorithms, and keys arises. Thus, there is always some compromise between maximizing reliability and maximizing security (the necessary checks). Other methods have been proposed to block the "backdoor" after the test is complete. However, for various reasons, previous solutions to data each have economic and technical disadvantages.

In one method believed to be used in the generation of the smart card described above, the die of the card is inspected prior to individualization of the memory die from the wafer. Inspection pads for a particular die are placed on adjacent die of the wafer, and the individualization process cuts the inspection pads from all circuitry of the adjacent die after inspection. Therefore, any test pads on an individualized die are completely separated and blocked as a potential back door to secure data of the final memory card. However, it is not always practical or desirable to completely remove the test pads. For example, the lack of useful test pads precludes some later hardware, for example based on memory testing, which limits potential defect analysis methods.

Although this method may be desirable for smart cards that typically have only a small amount of memory needed to hold identification and financial data, it is used for large memory cards used to store many large pies such as photos and music. Insufficient for checking complex security routines and relatively large amounts of memory. Some examples of these mass memory cards are compact flash cards, MMC cards, and SD cards. The proliferation of digital content and associated copyright issues raises the importance of security, while at the same time inspection and reliability of cards remain the most important. A more comprehensive and adaptive system for manufacturing, inspecting and operating secure mass memory cards is required and provided by the present invention which will be described below.

Another important aspect is cost. Some other techniques, such as nonvolatile memory, logic, and volatile memory, can be fabricated on a single integrated circuit die (chip). However, mixing different technologies on one die greatly increases production costs. In a competitive environment where cost is the most driving force, it is highly desirable to limit the amount of other technologies provided on one die. However, using multiple dies means that sensitive information must pass from one die to another in the final product. This is another potential weakness that hackers can exploit if proper precautions are not used.

In particular, nonvolatile memory bits are expensive to mix with logic within the same die. Smart cards use nonvolatile memory to store data on the same die as the logic that smart cards operate in, which maximizes security. However, a memory card now preferred in the present invention must store very large music, photos, movies and other user files. Therefore, it is very expensive to manufacture a single integrated circuit die memory card that can store a large amount of information (a few gigabytes and more in 2005), and it is necessary to develop a security system using multiple dies. In particular, a security system (using encryption and decryption) that uses one or more discrete (economical) flash memory die that can be separated from the controller die, fully inspected before and after assembly, and can withstand attacks through inspection mechanisms. It is very desirable to produce.

Other systems have been developed because using a single chip with both the controller function and the high capacity storage capability required by today's digital devices presents excessively expensive and scaling problems. Security in a single chip solution can be achieved with a unique chip design that makes it difficult to access inspection mechanisms, encryption keys and encrypted content. However, in a multi-chip design where content passes from an independent memory chip to a controller chip where encryption occurs, particular care is required to protect access to the encryption keys and the encrypted content. In addition, any system of software and hardware that can be used as a back door for unauthorized access to encrypted keys and content, in a system with inspection pads in the final assembly to allow inspection of the assembled system. Particular attention should be paid to

The present invention has a number of life cycle steps that are entered and passed during the life of the card. In accordance with the above steps, the logic of the card that enables or disables the encryption engine controls access to hardware (before and after wafer personalization and card assembly) and software inspection mechanisms, and controls key generation. These steps not only allow both the hardware and software of the card to be fully inspected before and after manufacturing (unlike smart cards with the test pads removed), but also when the card is in the secure phase, ie when shipped to the user. It actually makes it impossible to access the encrypted key and the encrypted content when in. Therefore, the present invention provides a memory card that can be inspected but resists unauthorized access to protected data within the card.

In addition, a more comprehensive and flexible system for manufacturing, inspecting and operating secure mass storage memory cards is required and provided by the present invention which will be described later.

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

1A is a schematic diagram of a system 10 in accordance with one embodiment of the present invention.

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

2A is a flow diagram illustrating various life cycle steps in one embodiment of the invention.

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

3 is a flow chart illustrating boot up processing and life cycle steps.

Memory system architecture

An exemplary memory system in which the various aspects of the invention are implemented is shown in the block diagram of FIG. 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, flash memory 20, and peripheral access module 22. The memory system 10 communicates with a host device 24 via a host interface bus 26 and a port 26a. Flash memory 20, which may be of NAND type, provides data storage for host device 24. Software code for the CPU 12 may also be stored in the flash memory 20. FIM 18 connects to flash memory 20 through a port (not shown) in flash interface bus 28 and in some examples if flash memory 20 is a removable component. The HIM 16 is suitable for connecting to a host system such as digital cameras, personal computers, personal digital assistants (PDAs) and MP-3 players, cellular telephones or other digital devices. Peripheral access module 22 selects appropriate controller modules, such as FIM, HIM, and BMU, to communicate with CPU 12. In one embodiment, all the components of the system 10 in the dashed box can be sealed in a single unit such as a memory card and preferably sealed in the card.

The buffer management unit 14 includes a host direct memory access unit (HDMA) 32, a flash direct memory access unit (FDMA) 34, a coordinator 36, a CPU bus coordinator 35, registers 33, a buffer A random access memory (BRAM) 38, and a crypto engine 40 called an encryption engine 40. The coordinator 36 is a shared bus coordinator and the slave or target is the BRAM 38 so that only one master or initiator (which may be HDMA 32, FDMA 34 or CPU 12) can be activated at any time. The coordinator responds to channel the appropriate initiator requester to the BRAM 38. HDMA 32 and FDMA 34 may respond to data transferred between HIM 16, FIM 18 and BRAM 38 or RAM 11. The CPU bus coordinator 35 directly from the clipto engine 40 and the flash DMA 34 to the RAM 11 via the system bus 15 used in certain situations such as when bypassing the crypto engine is desired. Allow data transfer. The operation of HDMA 32 and FDMA 34 is generic and need not be described in detail herein. The BRAM 38 is used to store data passed between the host device 24 and the flash memory 20. HDMA 32 and FDMA 34 may transfer data between HIM 16 / FIM 18 and BRAM 38 or CPU RAM 12a and respond to indicate sector completion.

When data from the flash memory 20 is read by the host device 24, the encrypted data in the memory 20 is transferred to the bus 28, the FIM 18, the FDMA 34, and the crypto engine 40. Is fetched through and the encrypted data is decrypted and stored in the BRAM 38. Decrypted data is then sent from the BRAM 38 to the host device 24 via the HDMA 32, HIM 16, and bus 26. The data retrieved from the BRAM 38 is compared before the data sent to the host device 24 is encrypted by different keys and / or algorithms and passed to the HDMA 32 so that the data stored in the memory 20 is encrypted. It is encrypted again by the crypto engine 40. Optionally, rather than storing the decrypted data in the BRAM 38 in the above process where the data may be attacked by unauthorized access, the data from the memory 20 is decrypted and sent to the BRAM 38. It is encrypted again by the crypto engine 40 before it is. The data encrypted in the BRAM 38 is sent to the host device 24 as before. This shows 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 transmitted by the host device to the crypto engine 40 via the bus 26, HIM 16, HDMA 32, the data is not stored in the BRAM 38 before being stored. It can be encrypted by the engine 40. Optionally, unencrypted data may be stored in the BRAM 38. The data is then encrypted in memory 20 before being sent to FDMA 34 along its way.

Life cycle stages

Security systems or security operating systems that are particularly useful when executed on a memory card such as those described above have other steps or states, for example. These steps are preferably entered sequentially so that after proceeding from one step to the next, the previous step cannot be entered again. Therefore, the above steps can be thought of as life cycle steps.

Before describing the steps in detail, other system level diagrams will be discussed briefly. 1B shows another embodiment of a system 10. Only certain components of system 10 are shown in the figures for simplicity and clarity. Memory system 10 includes test pads called hardware test input / output (I / O) 54. The hardware bus (HW bus) 56 is preferably connected to the test pads 54. These test pads and the HW bus 56 are connected to various hardware and circuits (not shown) of the system and used to inspect the hardware and circuitry of the system 10. JTAG bus 62 may be connected to system bus 15 (shown in FIG. 1A) and used to replace controller firmware and drive hardware blocks from outside of system 10. This is used for hardware checks that require register read / write operations. Since the JTAG bus 62 accesses RAM and ROM, the bus is used to check the firmware of the system 10. The host bus 26 is used to send diagnostic commands to the system 10 and to check the firmware of the system.

The NVM 50 of the encryption engine 40 is also shown. In the NVM 50, values for the life cycle state 77 and the secret key 99 are stored. NVM inspection port 58 is used to inspect the NVM within the encryption engine 40.

Status indicator fuse 66 is used to indicate that the product is in NVM state 110 (described below) rather than depending on the NVM content. This is because the reliability of the initial values stored in the NVM during the manufacturing phase cannot be guaranteed. Therefore, other more reliable indicators such as indicators are used. The system will determine if the fuse is in state 110. If system 10 is reset, it will look for NVM life cycle state 77 to determine the state.

2A shows the various states and the order of transitions between them. Each state defines different behaviors and capabilities of the card (or other system executed) before and after the card is manufactured, as shown in the following table played back as FIG. 2B.

condition Key generation NVM inspection HW inspection FW inspection Crypto Engine 110 All regenerated power rises E E E D 120 Constant wiring D E E E 130 Once created D E E E 140 Once created D D D E 150 - D D D E 160 All regenerated power rises D E E E 170 - D E E D

The state is preferably stored as a 32-bit value in non-volatile memory of the encryption engine. There are six pre-assigned values among the multiple (# 10 ⁹ ) combinations used to represent states 120-170. All other values indicate state 110. This is because it can not be guaranteed that the defined values can be stored reliably during manufacturing and then various processing operations during the manufacturing, assembly, inspection, and shipping can change the values stored arbitrarily in memory.

The key value is preferably stored as a 128-bit field in the non-volatile memory of the encryption engine. Key values are normally randomly generated by a seeded algorithm. The reproduction of the key can change the value of the key well, but this cannot be guaranteed because a (pseudo) random number of generators can actually produce the same value continuously. However, the term changing keys is used interchangeably with the playback of keys in such applications even though it is understood that the value of the keys cannot change during playback. Needless to say, the value of the key used to encrypt the information is important. The same key value should be used for both encryption and decryption. Thus, if the key value is reproduced at every power up of the system, the data encrypted before the power up is not really valuable because it cannot be decrypted with the new key. Although the data is physically provided to the memory of the card, the data cannot be used without the proper key to unlock it. Thus, if the hacker manages to return the card to one state anyway, unlike the other security state 15, the hacker will not get any good information. In states 110 and 160, a new key will be generated at every power up and the key previously used to store information in state 150 may not be used to decrypt the information. In states 170 and 110, the encryption engine is simply not available despite the key value.

Another security measure is to limit the use of firmware and hardware inspection mechanisms. The system includes logic to enable or disable the mechanisms. The previously described host bus is one of the mechanisms used to check the card's firmware. The host can issue diagnostic commands on the host bus to check the firmware. The hardware can be checked when these instructions are executed. The hardware is checked directly on the JTAG port as well as on the hardware bus, which provides direct access to the various memories of the system. NVM inspection mechanisms, HW inspection mechanisms, and FW inspection mechanisms in states 140 and 150 are all disabled.

The passage between states and the states shown in FIG. 2A will now be described in further detail.

State 110 is referred to as a controller nonvolatile memory (NVM) check. This state is the initial state after fabrication of the memory die and is used to inspect the nonvolatile memory of the controller die before the die is packaged and installed in the memory card. Inspections occurring in this condition may be performed before individualization while the dies are integral to the wafer format, or may optionally be performed on individual die after individualization. Once the NVM is inspected, the content (using the NVM inspector) begins to indicate state 120, and fuse 66 is blown. In this state, the encryption engine 40 is disabled. This state is designed to be entered only once in the card's life cycle and there is no way in the system to return to this state. However, as discussed previously, this state is indicated as any other than six pre-allocated 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 blows (NVM state 110 is not entered), the Crypto Engine is never ready and the system does not boot or proceeds beyond step 302 described below with respect to FIG. . Therefore, each time the card is powered up and in this state, a new key is randomly generated, and the previously encrypted data is not decrypted. Although the decryption engine is not enabled in this mode, since the mode is designed to be used while the wafer is still intact during manufacturing, the key may enter this state in some accidental manner and with various inspection ports and Mechanisms are replayed at every power up to protect hackers who wish to inspect the card's security data. Otherwise, after the conventional state 110 by design, the NVM inspection mechanisms are no longer available.

State 120 is referred to as a constant enable state. In this state, the encryption engine 40 is enabled. The keys that the encryption engine will use are generated by a random number of generators, not stored in memory, but wired to some external sources and constants during this step. Hardware and software inspection mechanisms can be used in this state. This state is entered by a hardware checker.

State 130 is referred to as a random enable state. This state is similar to state 120, but a security key is randomly generated (once) when state 130 is entered instead of constants and wires. This is the state used for the final inspection, characterization and condition of the memory card. Cryptographic operations, including encryption and decryption, are possible in firmware using a security key or a key derived from the security key. This state is entered by code loaded into the system 10 by the host device 24 and executed by the system 10.

State 140 is referred to as the final key state. In this state, the card uses the final security key to which the card will be shipped. Hardware and software inspection mechanisms are disabled and cannot be accessed by the card logic. This includes the hardware test bus and test pads shown in FIG. 1B. This state is used to load the card with the final firmware and configuration data that needs to be protected by the key that ships the product. The product may be configured in this state, but not in state 15. This state is entered by a host command. The command may be included in code that is downloaded from the host and executed by the card ("DLE code"). Commands can optionally be issued directly from the host. This is true at any time the term DLE code is used below.

State 150 is referred to as a security state. This is the state where the card is shipped from manufacture. Hardware and software inspection mechanisms are disabled and cannot be accessed by the card logic. This state is entered at the end of the inspection and configuration of the product on the manufacturing flow. The key 140 is not played and the value stored in memory during state 150 is used during state 150. When derived keys can be used for various operations of the card, the key 99 will always need to derive these keys and encrypt and decrypt the data. This key is meant to be used for the life of the security card (not afterwards when it is in the customer's hand as a security card). In-card firmware cannot use the security key during any operation. There is hardware in the encryption engine that is used to perform both in-card encryption and decryption. This state is entered by the DLE code.

State 160 is referred to as the returned product certification or RMA state. This state is designed to allow inspection of the card returned by the customer because it does not work properly. This is a state in which defect analysis of the card can be performed. Software and hardware inspection mechanisms are available again. It is important to note that this state can only be accessed by the manufactory. In addition, after the RAM state is entered, the card can never be used again as a security card. In other words, it is used to decrypt information that can never enter or otherwise reside on the card 150 or to store the encrypted information on the card. The security key is played when this mode is entered and performed during all chip resets while the card is in this state. The operation of using the security key for decryption is only enabled at boot time and the firmware cannot use the security key for any operations. This state is entered by the ROM code that is the result of the host command.

State 170 is referred to as a disabled state. In the disabled state, the crypto engine 40 is in bypass mode with all cryptographic capabilities disabled. Only insecure algorithms are used in the card. Hardware and software inspection mechanisms are re-enabled because nothing can be hacked or otherwise eavesdropped without the encryption engine. Any encrypted information is no longer decrypted and obsolete. In addition, additional information may be encrypted and subsequently decrypted. This state can be used to create an insecure or "normal" card. In this way, the same system can be used to form secure and insecure memory cards. The difference is that in a non-secure card the card's security system is disabled or the card is not in state 170. The disabled state can also be used to re-ship the product sent back to the factory for defect analysis, and thus passed to RMA state 160. As noted above, after the card enters RMA state 160, it can never return to any previous state and cannot be sold again as a security card. However, cards that have a functional action or that can be formed again at the factory are placed in the disabled state 170 and sold again as an unsecured card. In this way, the card is played and is identical to the new unsecured or "regular" card for all strong purposes. Both recycled non-security cards and new non-security cards will run the same firmware in the same state.

Currently, the vast majority of cards are nonsecure cards. While the movement to sell security cards is high mainly due to the needs of content providers, it is unclear what percentage of future memory card sales will be security cards versus non-security cards. What is clear is that there is always a lot of unsecured content and therefore there is a need for unsecured cards. The present invention not only can inspect all hardware and software of the security card (only by authorized persons) but also provides the ability to play the returned security cards for various non-security purposes. In addition, the system of the present invention has a strong security, but allows cards that do not need to be disabled or have a compromised security system (having an accessible "backdoor") to perform fault analysis. Due to the widespread proliferation of devices using memory cards, the ability to play back a defective security card is likewise highly desirable to consumers and manufacturers.

3 shows a boot process for a memory card executing the system described above. For much of the information during the boot up process, it is hereby incorporated by reference in its entirety, by Micky Holtzman et al. See application 11 / 284,623.

In step 302, the system checks whether cryptographic hardware including crypto engine 40 and other components is ready. The system will wait for processing until the hardware is ready. The system proceeds to step 304 when the hardware is ready. In step 304 the system checks to see if the card is in a state 170 (disabled state). If the card is in state 170, at step 306 the system will upload a minimum amount of startup code (“BLR”) from the flash memory 20 to the RAM 11. Next, at step 308 the system checks to see if the BLR has been uploaded properly. If so, in step 310, the system will upload the firmware required to operate in an insecure mode (standard firmware minus cryptographic function). If the BLR is not uploaded properly as determined in step 308, the system will proceed to step 324 described below.

If the system determines that the card is not in state 170 in step 304, the system will delete the RAM contents in step 312. The system will then check again at step 314 to see what the card is like. If the card is in state 120, 130, or 140, the BLR will be uploaded at step 316. At step 318, the system will check to see if the BLR has been uploaded properly. Next, in step 320 the integrity check of the BLR code will be performed. This integrity check is a hardware based check performed by calculating message authentication code (MAC) values and comparing them with reference values. The result of the integrity check is a simple flag stored in memory. In step 322, the firmware checks the flag to see if integrity is verified or not. If maintenance is OK, the system will upload the firmware required to operate in secure mode in step 342, which of course allows non-secure data to be stored and retrieved. If maintenance is not OK as determined in step 322, the system will wait for a diagnostic command from the host to download and execute specific commands (DLE command) from the host as represented by step 324. . If the DLE instruction is retrieved as in step 326, the system will load the DLE code into RAM in step 328. In step 330 the DLE code will be executed by the controller.

If at step 314 it is determined that the card is not in state 120, 130 or 140, the system will check at step 332 to see if the card is in state 150. If so, the system will upload the BLR in step 334. This is done by ROM code. If the BLR upload is OK as determined in step 336, then the hardware background integrity check will be performed in step 338 as described above in step 320. After this hardware based integrity check, another maintenance check, a software based integrity check will be performed at step 340. If preservation is OK, the system will upload the firmware needed to operate in secure mode, allowing non-secure data to be stored and retrieved.

If at step 332 it is determined that the card is not in state 150, the system checks the state of the card and if the card is in state 160 and if so then issues a diagnostic command as represented by step 348. I will wait. However, if at step 344 it is determined that the card is not in state 160, the system will wait for a command to proceed to RMA state 160 as shown in step 346.

Claims (40)

As a method of forming a memory card, Providing a memory die at the test ports; Providing a security system, the security system comprising: Crypto engine, Passkey, Test states that test ports are available for hardware test and software test routines are used to perform the operation of the crypto engine and software test of the memory card, and An operational state in which test ports are not available and the software test routines are not available; Checking the memory card software using the test status; And Providing a command from the host to the card for irreversibly switching the card from the test state to the operational state. A method for testing the functionality of a memory card including a nonvolatile memory die with test pads, the method comprising: Inspecting a memory die before any firmware is loaded and before the firmware is part of a memory card; Loading firmware into a memory of a memory die; Changing the stage of the card to a first stage that allows inspection of the hardware and software of the memory card; Checking the hardware and software of the memory card; And Changing the stage of the card to a second stage that does not allow inspection of the hardware and software of the memory card. 3. The method of claim 2 wherein the test pads are provided to a memory die when the die is installed in the card. 3. The method of claim 2, further comprising changing the step of the card after the defect of the card to the step of inspecting the software and hardware of the memory card for defect analysis, wherein after entering the step the memory card is subjected to this step. The method of testing memory card functionality that can no longer decrypt data that was encrypted before entering. 3. The method of claim 2 wherein the indicator of the step is stored in a nonvolatile memory of the controller chip. 3. The method of claim 2 wherein signals are not passed to test pads and to test pads in a second step. A method for providing secure storage of data in a memory card, Providing a flash memory in the memory card; Providing an encryption engine to the controller chip for encrypting and decrypting data stored in the flash memory; Storing a key in a nonvolatile memory of the controller chip; Encrypting the card data file of the user with the key before the file is stored in the flash memory chip; Storing the encrypted data file in flash memory; And If the use of a card checking mechanism is desired, including replaying the value of the key such that the encrypted file cannot be decrypted. A security system running on a memory card that operates as a security card or a regular card, A cryptographic engine that encrypts and decrypts the information to protect the information stored on the card; Secret keys in cards used for encryption and decryption; Including the inspection state, in the inspection state, The encryption engine is enabled, The security key is generated during entry into the inspection state, In-card firmware can be checked, The hardware of the card can be checked; A secure operating state, wherein in the secure operating state, The firmware on the card cannot be checked, The hardware of the card cannot be checked, The encryption engine is enabled, The security key is used by the encryption engine to encrypt and decrypt the information; And A bypass operating state, wherein in the bypass operating state, The encryption engine is disabled, The hardware of the card can be checked, The card's firmware can be checked, The bypass operating state is used if acting as a regular card. 9. The security system of claim 8, wherein said card is initially sold as an unsecured card configured in a bypass operational state. 10. The security system of claim 8, wherein said card is initially sold as a security card configured in a secure operating state. 11. The security system of claim 10, wherein the card that is initially sold as a security card after being returned to the manufacturer is in bypass operation. 12. The security system of claim 11, wherein the card is sold as an unsecured card after being bypassed. 10. The security system of claim 8, wherein the encryption engine is hardware based. 9. The security system of claim 8, wherein the security key is stored in a nonvolatile memory of an encryption engine. The method of claim 8, Further comprising a defect analysis operation state, wherein in the defect analysis operation state, The hardware of the card can be checked, The card's firmware can be checked, The security key is refreshed every time the system is powered up in a fault analysis state. 16. The security system of claim 15, wherein after entering a fault analysis operational state, the card can never be used again as a secure operational state. 17. The security system of claim 16, wherein said fault analysis operational state is activated prior to entering a bypass state. A system for checking a memory card with firmware, Inspection ports on integrated circuit die; In-memory inspection mechanisms; And A security system, wherein the security system, Crypto engine; One or more test states of an action that can be utilized during testing of the card, wherein the test states allow the use of test ports and test mechanisms in firmware; A security state of an operation that can be used during normal use of the card, the security state prohibiting the use of test ports and test mechanisms in firmware; Logic for switching between a check state and a secure state of one of the one or more check states, and once the card is switched to the secure state, one or more check states can never be accessed again, Preventing access to secure data on the card by preventing access to the inspection mechanisms and inspection ports of the memory card inspection system. 19. The memory card inspection system of claim 18 wherein the security system further comprises a bypass operating state and the crypto engine is disabled. 20. The system of claim 19 wherein the bypass state is used to create an insecure memory card. 20. The memory card inspection system of claim 19 wherein the bypass state is activated when a security card is returned for service, converting the security card into an unsecured card and playing the card for further use. 22. The memory card inspection system of claim 21 wherein the non-secure card can never be used again in a secure state after conversion. 20. The method of claim 19, further comprising a fault analysis state, wherein a new key used to encrypt and decrypt data is generated at every power up, and data encrypted with one key cannot be decrypted with another key. Memory card inspection system. 24. The system of claim 23 wherein the fault analysis state is entered prior to entering the bypass state. 19. The memory card inspection system of claim 18, further comprising a final key state used to load a card with final firmware to be used for a secure state, wherein the inspection mechanisms of the firmware are disabled in the final key state. 26. The memory card inspection system of claim 25 wherein communication with inspection ports in the last key state is unavailable. As a memory card, A security system running on a memory card that can be used to form a security or non-security card; A cryptographic engine designed to encrypt and decrypt the information to protect the information stored on the card; Including the inspection state, in the inspection state, The encryption engine is enabled, In-card firmware can be checked, The hardware of the card can be checked; A secure operating state, wherein in the secure operating state, The firmware on the card cannot be checked, The hardware of the card cannot be checked, The encryption engine is enabled; And And a bypass operating state, wherein the encryption engine is disabled. The method of claim 27, wherein in the bypass operating state, The hardware of the card can be checked, The card's firmware can be checked, the memory card. 28. The apparatus of claim 27, further comprising a final key state, The final key to be used for the secure operating state is used for the card, Card can be configured, The hardware inspection mechanisms of the card cannot be tested, The card's software checking mechanisms cannot be checked. As a flash memory card, A security system, wherein the security system, Includes two or more operating states, the card operates in one operating state at a time, Means for encrypting and decrypting data in the card; Means for inspecting the card while the card is in the first operating state; Means for advancing the state of the card such that the previous state cannot enter again after the state has progressed; In one of the two or more operating states, the means for encrypting and decrypting the data is used but the means for inspecting the card is not available in the operating state so as to control access to the data of the card. Means for preventing unauthorized access to data on the card via the inspection means. As a flash memory card, A security system, wherein the security system, Two or more operating states, the card operating in one operating state at a time; An encryption engine for encrypting and decrypting data in the card; An inspection mechanism that can be used while the card is in the first operating state; And Includes logic to advance the state of the card so that the previous state cannot enter after the state has progressed, The data encrypted in the at least one states cannot be decrypted in the later entered state. As a flash memory card, A first integrated circuit die comprising a nonvolatile flash memory for mass storage of data files; And A second integrated circuit die, wherein the second integrated circuit die comprises: Microprocessor, An encryption engine that encrypts and decrypts data, Nonvolatile memory, and A security key that enables operation of an encryption engine, the security key being stored in a nonvolatile memory of a second integrated circuit die, In normal operation mode the memory card uses the value of the first security key for encryption and decryption, In test mode the memory card uses the second value of the security key for encryption and decryption, The second value cannot be used to decrypt the data encrypted with the first value, The first value cannot be used to decrypt data encrypted with a second value. As a flash memory card, An encryption engine for encrypting and decrypting data stored in the card; A first operating state for inspecting a memory card, the memory card generating a first key to enable encryption and decryption using an encryption engine; And A second operating state for consumer use of the memory card, the memory card using the second key to encrypt and decrypt the data stored on the card, The data encrypted with the first key cannot be decrypted with the second key and the data encrypted with the second key cannot be decrypted with the first key, The encryption engine may be tested in the first state, but encrypted data cannot be read while the card is in the second state while the card is in the first state. 34. The flash memory card of claim 33, wherein the value of the first key changes each time the power of the memory card is raised. 34. The flash memory card of claim 33 wherein the value of the first key is a constant. 34. The flash memory card of claim 33, wherein the value of the first key is played each time a first operating state enters. 34. The flash memory card of claim 33, wherein the value of the second key is a constant and is stored in a nonvolatile memory of the card. 38. The flash memory card of claim 37, wherein the value of the second key is the same as the value of the first key last stored in the memory during the first state. 34. The flash memory card of claim 33, wherein the hardware and firmware check mechanisms are used to check in a first state. 34. The flash memory card of claim 33, wherein the hardware and firmware checking mechanisms are not usable to check in the second state.

Images