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

Abstract

Secure memory cards with encryption capabilities include various cycle states that allow hardware and software checks of the card at certain states. Inspection mechanisms are disabled in certain other states, blocking potential backdoors for secure data and cryptographic keys. Controlled utilization and generation of keys required for encryption and decryption of data, even if the backdoors are accessed, makes previously encrypted data undecrypted and therefore useless even if the backdoor is found and unfairly opened.

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 reliably stored during manufacturing and then various processing operations during the manufacturing, assembly, inspection, and shipping may 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 allows cards that have strong security, but which 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)

In the method of operating a memory card, The method includes steps performed at the host when the host is connected to a memory card, the memory card including a memory die and a security system equipped with test ports, wherein the memory card includes test status, operational status, and fault analysis. Operating in the state and disabled state, The security system includes a crypto engine and a cryptographic key, In the test state, the test ports are used for hardware test, software test routines are used to enable the operation of the crypto engine and the test of the software of the memory card, In the operating state, the use of the test ports is prohibited, the use of the software test routines is prohibited, the memory card is set for operation as a secure memory card, The disabled state is irreversible, in the disabled state the crypto engine is disabled, the memory card operates as a non-secure memory card, The steps performed at the host are: Inspecting the software of the memory card while the memory card is in the test state; Sending a command to the memory card to cause the memory card to irreversibly switch from the test state to the operating state; And When the defect is found in the memory card, causing the memory card to operate in the defect analysis state, wherein in the defect analysis state, defect inspection of software and hardware of the memory card is enabled, and the memory card is configured to execute the memory card. Preventing the decryption of the information previously stored in the card again, wherein the memory card is set such that the memory card is switched only to the disabled state; Memory card operating method comprising a. delete delete delete The method of claim 1, wherein an indicator indicating a current state of the memory card is stored in a nonvolatile memory of the memory card. 2. The method of claim 1, wherein causing the memory card to operate in the fault analysis state causes the memory card to generate a new key value each time power is applied in the fault analysis state, and encrypts before the most recent power up. Memory data is prohibited from being decrypted by said memory card. delete A security device implemented in a memory card operating as a security card or a regular card, the security device comprising: An encryption engine for encrypting and decrypting information to protect the information stored in the memory card; And A security key in the memory card, used for encryption and decryption; Including, The security device is operative to switch between an inspection state, a security operation state and a bypass operation state, In the inspection state, the crypto engine is enabled, the security key is generated upon entering the inspection state, inspection of firmware in the memory card is enabled, inspection of hardware in the memory card is enabled, In the secure operating state, the crypto engine is enabled, a check of firmware in the memory card is disabled, a check of hardware in the memory card is disabled, and the security key is used to encrypt and decrypt information. Used by the crypto engine, In the bypass operation state, the crypto engine is disabled, inspection of hardware in the memory card is enabled, inspection of firmware in the memory card is enabled,  And the bypass operation state is used when operating as a regular memory card. delete delete delete delete 9. The security device of claim 8, wherein said crypto engine is implemented by hardware. 9. The security device of claim 8, wherein the security key is stored in a nonvolatile memory of the crypto engine. The apparatus of claim 8, wherein the security device further comprises a defect analysis operation state for performing a defect analysis of the memory card, In the defect analysis operation state, inspection of hardware in the memory card is enabled, inspection of firmware in the memory card is enabled, and the security key is applied to the security device in the defect analysis operation state. The security device is regenerated every time. The security device of claim 15, wherein after entering the defect analysis operating state, the memory card is prohibited from use in the secure operating state. 17. The security device of claim 16, wherein the fault analysis operating state is activated prior to entering the bypass operating state. 10. The system of claim 8, wherein the test state includes one or more test operating states used during the testing of the memory card, wherein the test operating state comprises the use of test ports on an integrated circuit and the use of test mechanisms in firmware on the memory card. Allow, The secure operational state is used during normal use of the memory card, the secure operational state prohibits the use of the test ports and the use of the test mechanisms, The memory card further includes logic for switching between the test operational state and the secure operational state, wherein access to the test operational state is inhibited once the memory card is transitioned to the secure operational state, thereby providing the check mechanisms. And prevent access to secure data on the memory card by preventing access to the inspection ports. delete delete delete delete 19. The apparatus of claim 18, wherein the security device further comprises a defect analysis state, wherein in the defect analysis state, a new key used to encrypt and decrypt data is generated each time power is applied, and data encrypted with one key is generated. Security device characterized in that it is prohibited to decrypt with other keys. 24. The security device of claim 23, wherein the fault analysis state is entered prior to entering the bypass operational state. 19. The device of claim 18, wherein the security device further comprises a final key state used to load a memory card with final firmware to be used in the secure operating state, wherein the checking mechanisms are disabled in the final key state. Security device. 27. The security device of claim 25, wherein communication with the test ports is prohibited in the final key state. delete delete The apparatus of claim 8, wherein the security device further comprises a key implementation operational state, In the key implementation operation state, a final key to be used in the security operation state is used in the memory card, setting of the memory card is enabled, inspection of hardware check mechanisms of the memory card is disabled, and And wherein the inspection of the software inspection mechanisms of the memory card is disabled. delete delete delete In a flash memory card, The memory card, An encryption engine for encrypting and decrypting data stored in the memory card; A first state for inspecting the memory card, the first state in which the memory card generates a first key that enables encryption and decryption using the crypto engine; And A second state for consumer use of the memory card, the memory card using a second key to encrypt and decrypt data stored on the memory card, the value of the second key being constant during a second state and the memory A second state, stored in a nonvolatile memory of the card; Including, The data encrypted with the first key is prohibited from being decrypted with the second key, and the data encrypted with the second key is prohibited from being decrypted with the first key, Checking for the cryptographic engine is enabled in the first state, but encrypted data while the memory card is in the first state is prohibited from reading while the memory card is in the second state. Flash memory card. 34. The flash memory card of claim 33, wherein the value of the first key changes each time power is applied to the memory card. 34. The flash memory card of claim 33, wherein the value of the first key is constant. 34. The flash memory card of claim 33, wherein a value of the first key is regenerated every time the first state is entered. delete 34. The flash memory card of claim 33, 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. 34. The flash memory card of claim 33, wherein hardware and firmware check mechanisms are enabled in the first state. 34. The flash memory card of claim 33, wherein hardware and firmware check mechanisms are disabled in the second state.

Images