JP2009537026A - System and method for write failure recovery - Google Patents

Abstract

  When cipher block chaining encryption / decryption is used, disaster recovery is achieved by storing information useful for writing cipher block chained data before it is written to the storage cell. When a write failure is detected, this stored information can be retrieved to rewrite the data to the cell. Preferably, the storage information includes security configuration information related to cipher block chain processing in units of data.

Description

  The present invention relates generally to memory systems with data encryption / decryption, and more particularly to a memory system or method for writing data with write failure recovery capability.

  Portable storage devices have been in commercial use for many years. A portable storage device carries data from one computing device to another or for storing backup data. The mobile device market has evolved to capture content storage, increasing average revenues by increasing data exchange. This means that valuable content stored on the mobile device must be protected. In order to protect the content stored in the portable storage device, the stored data is usually encrypted, and only authorized users are allowed to decrypt the data. This is done by an engine called a crypto engine.

  Cipher block chaining (CBC) is an encryption method that feeds back the result of encrypting a previous plain text block (in the form of a cipher text block) to the encryption of the next plain text block. Thus, each cipher text block depends not only on the plain text block but also on the previous plain text block. The initial vector (IV) is randomized data, which is encrypted as the first block in the CBC process, providing a unique input to the encryption engine, so that the specific plane used for encryption For text keys, the generated ciphertext is still unique.

  The CBC process is performed by a crypto engine that can perform encryption and / or decryption. This engine context refers to the current state of the engine at a particular time. A specific context is generated and used in a particular encryption / decryption cycle.

  Using CBC to encrypt data during a write operation may cause storage device programming to fail. In such a case, the storage device must be reprogrammed with data. This requires that data that could not be written during the write operation be transferred again to the storage device. However, once data passes through a crypto or encryption / decryption engine using a specific context, the engine cannot pass the same data unless the engine is reconfigured with the appropriate context. Therefore, it is desirable to provide a solution to the problem described above.

  The problem described above is that information useful for writing data processed in a cipher block chaining scheme during one or more programming cycles is stored before writing such data to the storage device during such cycles. In this way, when a write failure occurs, such data can be written to the storage device again.

  One unit of data is written to the storage device during at least one programming cycle. In one embodiment, the stored information is a data unit after being processed in the cipher block chaining method. In another embodiment, the stored information comprises security configuration or context information regarding cipher block chaining of data units.

  For convenience of explanation, the same components are labeled with the same numbers in the present application.

  The block diagram of FIG. 1 illustrates an example of a representative memory system in which various aspects of the present invention can be implemented. As shown in FIG. 1, the memory system 10 includes a central processing unit (CPU) 12, a buffer management unit (BMU) 14, a host interface module (HIM) 16 and a flash interface module (FIM) 18, and a flash memory 20. And a peripheral device access module (PAM) 22. The memory system 10 communicates with the host device 24 through the host interface bus 26 and the port 26a. The flash memory 20 may be of the NAND type and provides a data storage area for the host device 24. Software code for the CPU 12 can also be stored in the flash memory 20. FIM 18 connects to flash memory 20 through flash interface bus 28 and port 28a. The HIM 16 is suitable for connection to a host system including a digital camera, personal computer, personal digital assistant (PDA), digital media player, MP-3 player, mobile phone, or other digital device. Peripheral device access module 22 selects an appropriate controller module that communicates with CPU 12, such as FIM, HIM, and BMU. In one embodiment, all components of the system 10 that are within the dashed frame are enclosed in a single unit, such as a memory card or stick 10 ', preferably enclosed in a card or stick.

  The buffer management unit 14 includes a host direct memory access (HDMA) 32, a flash direct memory access (FDMA) controller 34, an arbiter 36, a buffer random access memory (BRAM) 38, and a crypto engine 40. Since arbiter 36 is a shared bus arbiter, there is always only one master or initiator (which can be HDMA 32, FDMA 34, or CPU 12) active and its slave or target is BRAM 38. The arbiter is responsible for directing the appropriate initiator request to the BRAM 38. HDMA 32 and FDMA 34 are responsible for transferring data between HIM 16, FIM 18, and BRAM 38, or CPU random access memory (CPU RAM) 12a. The operation of HDMA 32 and FDMA 34 are conventional and need not be described in detail herein. The BRAM 38 is used to store data exchanged among the host device 24, the flash memory 20, and the CPURAM 12a. The HDMA 32 and the FDMA 34 transfer data between the HIM 16 / FIM 18 and the BRAM 38 or the CPURAM 12a, and further serve to instruct completion of sector transfer.

  When originally encrypted data is written into the flash memory 20 by the host device 24, the encrypted data is transmitted from the host to the bus 26, the HIM 16, the HDMA 32, and the crypto engine 40, where the encrypted data is decrypted. Stored in the BRAM 38. Next, the decoded data is transmitted from the BRAM 38 to the flash memory 20 through the FDMA 34, the FIM 18, and the bus 28. When the data extracted from the BRAM 38 is encrypted again by the crypto engine 40 before being transferred to the FDMA 34, the data transmitted to the flash memory 20 is different from that used for decrypting the data from the host device 24. It is encrypted again with the key and / or algorithm. This is the data stream for the writing process.

  When unencrypted data is transmitted from the host device to the crypto engine 40 via the bus 26, HIM 16, and HDMA 32, such unencrypted data can be stored in the BRAM 38. After this data is encrypted, it is transmitted to the FDMA 34 and directed to the memory 20. When the write data passes through the multi-stage encryption process, the engine 40 preferably completes such a process and then transmits the processed data to the memory 20.

  In many applications, it is desirable to perform data encryption in real time when data is written to a storage device such as memory 20, which is known as on-the-fly data encryption. In this way, since it is not necessary to store data for encryption as an intermediate step before writing data to the storage device, efficiency is further increased. Therefore, preferably, encryption is performed on the fly when unencrypted data or encrypted data is transmitted from the host 24 to the memory 20.

  In the process described above, there is a data stream between the host device 24 and the memory 20. Therefore, at this time, the data supply source is the host device 24 and the write destination is the memory 20. In addition, the data supply source in the write operation may be the CPU 12, and the write destination in that case is the memory 20. Regardless of whether the data supply source is the host device 24 or the CPU 12, data stored in the flash memory 20 is first subjected to encryption processing by the engine 40 and then written to the memory 20.

  The memory system of FIG. 1 may incorporate a flash memory, but instead, a different type of non-volatile memory such as a magnetic disk, an optical CD, and other rewritable non-volatile memory systems may be included in the system. The various advantages described below are equally applicable to such alternative embodiments. In an alternative embodiment, the memory is preferably encapsulated in the same object (such as a memory card or stick) with the remaining components of the memory system.

  When data stored in the BRAM 38 (data from the host device 24 or data from the CPU 12) is written into the flash memory 20, the data is written in programmable units known as metapages, and each program of the CPU 12 is programmed. In the cycle, a metapage is written in the flash memory 20. A metapage may contain several sectors, and the sector size is determined by the host system. For example, a sector consists of 512 bytes of user data according to the magnetic disk drive standard, and several bytes of overhead information regarding the user data and / or metapage to which the sector belongs.

  The crypto engine 40 executes or processes cryptographic processing using a cryptographic algorithm and a cryptographic key. Many common cryptographic algorithms process 128-byte data as a cryptographic processing unit. This is typically less than the size of the metapage of data written during each programming cycle to flash memory 20.

  When the crypto engine 40 executes the CBC process on the data, the crypto engine 40 executes the CBC process for each plain text block of the data stream (in this case, a plain text block made up of cryptographic processing units) and responds. Get the cipher text block to Therefore, the cipher text block obtained from each cipher processing unit depends not only on the corresponding cipher processing unit but also on the previous cipher processing unit.

FIG. 2 is a block diagram of a CBC process that serves to illustrate the present invention. As shown in FIG. 2, when processing the first metapage, the CBC process starts with a random number called the initial vector (IV). The engine 40 encrypts this number using a key to arrive at one block of cipher text c ₁ . The value c ₁ and the first plaintext block p ₁ of the metapage are fed as inputs to the XOR gate, and the cipher text c ₂ is obtained by re-encrypting the output of the gate using the key. This operation is repeated for c ₂ input to XOR and plain text block p ₂ , and cipher text c ₃ is obtained by re-encrypting the output of the gate using the key. This process continues in a similar manner until all plain text blocks in the metapage are encrypted. The same process then begins with the second metapage and all subsequent metapages, using the last ciphertext block of the previous metapage instead of the initial vector (IV).

The cipher text block is sometimes referred to as a data authentication message authentication code (MAC). Thus, the encryption and decryption CBC functions for a first metapage of the type found in FIG. 2 can be expressed as follows:
Encryption input: m-bit key k; l-bit IV;
l-bit plain text block p ₁ ,... p _r
Output: c ₀ ··· c _r,
1 ≦ i ≦ r and c ₀ ← IV, c _i ← e _k (c _i-1 (+) p _i )
Decryption input: m-bit key k; l-bit IV;
l-bit cipher text block c ₁ ... _cr
Output: p ₀ ... P _r ,
1 ≦ i ≦ r and p ₀ ← IV, p _i ← c _i-1 (+) e _k ⁻¹ (c _i )
(However, (+) means an exclusive OR symbol.)

The value c ₀ ··· c _r of the aforementioned is a cipher text block or message authentication code metapage consisting plaintext block p ₁ ··· p _r contained in the data stream (MAC). IV is the initial vector and k is the key. Therefore, it encrypts the metapages with data blocks p ₁ ··· p _r, if it is desired to write to memory 20, MAC from the data block crypto engine 40 of the system 10 using a function such as a CBC function described above A value (for example, c ₀ ... C _r ) is calculated, and the MAC value is written in the memory 20. In the above equation, e _k (x) means the process of encrypting x using the key k, and e _k ⁻¹ (x) means that x is decrypted using the key k.

When engine 40 encrypts (excluding first metapage) each metapage, it is necessary to use the last message authentication code or cipher text c _r previous meta page instead of IV is above Can be seen from the encryption process. The engine 40 needs to use the initial vector IV in encrypting the first metapage.

After encryption using the write failure recovery CBC, the cipher text blocks or MAC value encrypted for each meta pages included in the data stream is c ₀ ··· c _r is understood from the previous description. These cipher text blocks are then written to the flash memory 20.

  If a problem occurs in writing the I-th metapage, it is necessary to write the series of MAC values of the encrypted metapage to the flash memory 20 again. Since the crypto engine 40 normally does not store encrypted data, such encrypted data no longer exists.

Order to start over the process of writing I th metadata pages, encrypted I th metadata pages, i.e. c ₀ ··· c _r is, somewhere in the system 10, for example, in memory 20 or RAM 12a In this way, if a problem is found in the process of writing the encrypted I-th metapage to the flash memory 20, the stored encrypted metapage is taken out again and flashed. It can be written again into the memory 20. Thus, the encrypted I-th metapage is not broken during programming and can be retrieved later if a write failure occurs. In addition, the program command included in the programming code of the CPU 12 does not involve data transfer from the BRAM 38. This program command uses the data buffer in the flash memory 20 or RAM 12a instead as a data supply source, and the data is written to the flash memory 20 again. These programming modes can be used if a write failure is detected.

In order to store the encrypted metapage in the flash memory 20 or the RAM 12a, it is necessary to prepare a sufficiently large buffer in the flash memory 20 or the RAM 12a for storing the entire encrypted metapage. Therefore, preferably and as an alternative, storing only the information necessary to return the engine 40 to an appropriate state will continue to fail even after it has been discovered that the encrypted metapage writing process has failed. The plain text block of such a metapage can then be processed again. Again, the unencrypted metapage can be retrieved from the BRAM 38 and processed by the engine 40, and the processed metapage can be written back into the memory 20. Therefore, before the current metapage is processed by the engine 40, the context information or security configuration information of the engine 40 is stored in a buffer, for example, the RAM 12a of FIG. Such information preferably includes a last message authentication code or MAC value c _r before metapage, and different values of the registers of the engine 40, an encryption algorithm used in processing, and further described below Information for identifying a metapage (or its position) that needs to be written again for a reason is included as appropriate. When writing the first metapage, such stored information preferably includes the initial vector IV instead of the last message authentication code or MAC value of the previous metapage. After storing such information, CPU 12 returns control to FIM and FDMA, which processes the current metapage _i and causes it to be encrypted by engine 40, and then encrypted current metapage. Write the page to the flash memory 20.

  In some embodiments, it may be desirable to use a buffer (not shown) between the FIM 18 and the memory 20, in which case one or more encrypted metapages, eg, one or more of the metapages to be processed. Sectors are cached before being written to flash memory 20. This buffer may be part of FIM 18 or memory 20.

  Although only a part of one metapage enters the cache, there is a possibility that both the metapage data currently being processed and the metapage data in the cache are simultaneously written to the flash memory 20. If a write failure is detected in such a case, how far can the system go back in the data stream to encrypt the data and rewrite to the memory 20 (ie, the metapage currently being processed, or Need to determine if it is a subsequent metapage in the cache). For this reason, the stored security configuration or context information preferably also includes the starting logical block address (LBA) of the metapage that is written simultaneously to the memory 20, so that one of the writing processes of such a metapage is in the process of writing. Even if a failure is detected, the system can return to the start address of the metapage that failed the writing process, and this metapage is rewritten in the flash memory 20 in an encrypted state.

  As described above, in the first method for solving the write failure problem, since all of a large number of cipher text blocks are stored in the flash memory 20 or the RAM 12a, a considerable storage space is required in the flash memory or the RAM 12a. It becomes. This is because it is impossible to know in advance exactly which part of the metapage will cause a write failure. For this reason, all the cipher text blocks are stored so that they can be written to the flash memory again.

  In contrast, in the second approach of storing only metapage security configuration information or context information, it is not necessary to store all of the metapage ciphertext blocks. Instead, only the last cipher text block or initial vector of the previous metapage needs to be stored in addition to the information for returning the engine 40 to the proper state. The last cipher text block or initial vector of the previous metapage is supplied as an input to the XOR gate along with the first plaintext block contained in the current metapage, and the output of this gate is input to the engine 40. Performs encryption. In this way, it is not necessary to prepare a capacity for storing all the cipher text blocks of any metapage in the flash memory or the RAM 12a.

  As described above, data of two metapages may be processed and written to the flash memory 20 at the same time. Therefore, the security configuration information of the two metapages being processed is stored using the two buffers in the RAM 12a. Of course, more than two metapages may be written to the memory 20, in which case more than two buffers are used instead, and such and other variations are within the scope of the invention. It is. Assuming that two metapages are written to the flash memory 20 at the same time, use a parameter called bufferindex to keep track of the two sets of security configuration information stored in the two buffers and is appropriate when a write failure occurs Collect security configuration information and reprocess the corresponding metapage. In this case, the two buffers for storing the security configuration information can be labeled 12a (0) and 12a (1), and the buffer index is switched between 0 and 1 so that the two buffers for storing the security configuration information are stored. Either one becomes clear. FIG. 3 shows a write failure recovery process by storing security configuration information.

  The CPU 12 first initializes the context or security configuration information stored in the two buffers 12a (0) and 12a (1) and sets the value of bufferindex to 0 (block 102). This setting or context is loaded by the CPU 12 into the buffer management unit 14 and the FIM 18. This prepares the FDMA 34 and the FIM 18 is ready to process data. A crypto engine 40 is also configured. After such loading, the CPU 12 waits until the flash memory 20 is ready to receive data (block 104). System 10 is now ready for write operation 106.

  CPU 12 initiates an FIM write program and hands over control of various buses to FIM 18 (block 108). FIM 18 suspends CPU 12 immediately before data is transferred from BRAM 38 to FIM 18 and flash memory 20, that is, before a DMA write operation code is issued (block 110). The back-end (BE) flashware and stop / resume module (SRM) API are software that is read from a storage area such as the flash memory 20 into the CPU RAM 12a. The BE flashware is executed by the CPU 12 and calls the SRM API to save the metapage and engine 40 cryptographic context or security configuration information in a buffer pointed to by the value of bufferindex. Therefore, since bufferindex was initially set to 0, this information is stored in buffer 12a (0). The start logical block address of the metapage to be written by this write operation is also stored in the buffer 12a (0) (block 112).

  The BE flashware executed by CPU 12 then returns control of device 10 to FIM 18. The CPU 12 activates the FDMA 34, and encryption of the metapage data from the BRAM 38 by the crypto engine 40 begins and is written to the memory 20 (block 114). The FIM 18 checks whether or not programming of the entire metapage for the flash memory 20 has been completed, and points out the success or failure of such metapage programming (diamond 116). If the metapage is successfully written to the flash memory 20, the buffer index is incremented by 1, and then divided by 2 (or modulo 2) to obtain the remainder (block 112). Since the bufferindex in this case is set to 0 in advance, the bufferindex is set to 1 at block 122 by such an operation, and the process is repeated at the next metapage, so the FIM 18 transfers the control right to the CPU 12 at block 104. return. Since bufferindex is set to 1, in the next cycle in which the next metapage is written, context or security configuration information is written to the buffer 12a (1).

  However, if the programming fails, FIM 18 suspends processor 12 (block 118) and the retry operation 120 is used to retry the write operation. The retry mechanism is illustrated in FIG. Referring to FIG. 4, when the FIM 18 detects a failure in the write operation, the location of the write failure and the metapage in which the write failure has occurred are grasped. That is, the FIM 18 grasps the start logical block address (LBA) of the metapage where the write failure has occurred. This address is compared or compared with the starting LBA address in the two buffers 12a (0) and 12a (1) to identify the buffer containing the LBA address that matches that of the metapage where the write failure occurred ( Block 152). The state of the crypto engine 40 is then restored using the identified context or security configuration information stored in such a buffer (block 154). CPU 12 starts FIM 18, FDMA 34, and engine 40, and the metapage of BRAM 38 is re-encrypted from the start logical block address of the metapage where the write failure occurred, and the encrypted metapage is The data is written into the flash memory 20 as before (blocks 156 and 158). FIM 18 also deletes or marks it for deletion if an incomplete encrypted metapage is written to memory 20. The CPU 12 returns the operation to the block 104 in FIG. 3 after this operation is completed.

  As described above, two or more metapage data may be written or programmed to memory 20 during the same cycle. Therefore, when a write error occurs when data of a certain metapage is written in the memory 20, such a metapage data preceding the metapage is also written in the memory 20. It may be necessary or desirable to rewrite or reprogram the preceding metapage as well as the metapage. Therefore, when a write failure occurs, the CPU 12 determines how far back the data should be rewritten or reprogrammed. In other words, the CPU 12 determines whether to rewrite or reprogram only the metapage in which the write failure has occurred, or to rewrite or reprogram the metapage that precedes it. Preferably, even if a write failure does not occur during programming of the preceding metapage, if the preceding metapage is not completely written to memory 20, the preceding metapage is also rewritten or reprogrammed. . In embodiments where two metapages may be written during the same cycle, the programming state of a particular metapage is only known after the next metapage in the cache has finished programming. In such a case, the CPU 12 always reprograms the two metapages (ie, the metapage in which the write failure occurred and the preceding metapage), and only the last metapage is limited to the last metapage. Reprogram.

  When using more than two buffers to store context or security configuration information and the starting logical block address of more than two corresponding metapages, instead of indexing the two buffers in RAM 12a, more than two By indexing the buffer, the process described above can be easily extended. The operation described above relates to recovery from a write failure when the metapage is encrypted. The same process applies basically when the encrypted data in the BRAM 38 is decrypted before being written to the memory 20. While the embodiments of the present invention have been illustrated with reference to on-the-fly data encryption processing so far, it can be understood that this also applies to systems that do not perform on-the-fly data encryption processing during the data writing process. Although the above-described embodiments refer to various examples of specific size data blocks and various sized metapages processed by the engine, different sized data blocks processed by the engine 40 and different sized metapages. You can see that the same benefits apply to pages. Depending on the application, if a write failure is detected, the system will return to the sector within the metapage instead of the beginning of the metapage where the write failure occurred, and such sectors and data streams It is desirable to encrypt all sectors in such metapages that follow such sectors and rewrite them into memory 20. In this way, the system does not need to encrypt the sector that precedes the sector where the write failure occurred in such a metapage. This increases efficiency. All of these and other variations are within the scope of the present invention.

  Although the invention has been described with reference to various embodiments, changes and modifications can be made without departing from the scope of the invention which is defined solely by the appended claims and their equivalents. Will be understood. The reference material referred to in this specification is hereby incorporated by reference in its entirety.

1 is a block diagram of a memory system in communication with a host device, illustrating the present invention. FIG. 3 is a block diagram of a CBC process that is useful for illustrating the present invention. 2 is a flowchart illustrating the operation of the system of FIG. 1 when writing data to a storage device that stores security configuration information, illustrating an embodiment of the present invention. 2 is a flowchart illustrating the operation of the system of FIG. 1 when reconfiguring a crypto engine using stored security configuration information when retrying a write operation of data that failed to be written, illustrating an embodiment of the present invention.

Claims (26)

A method of processing data in a memory system that stores encrypted data comprising a non-volatile memory cell and a cryptographic circuit,
Causing the circuit to perform cryptographic block chaining on the data in the data stream to be written to the cell;
Writing the data in the data stream to the cells in a series of programming cycles, whereby the data in the data stream is processed by a cryptographic block chaining process before being written to the cells;
During at least one programming cycle of a programming cycle, such data can be stored by storing information useful for writing cipher block chained data in such cycle before such data is written to the cell. Can write to the cell again after a write failure is detected,
Including methods. The method of claim 1, wherein
Detecting a write failure of cipher block chained data to the cell in such a cycle;
Writing the encrypted block chained data into the cell using the stored information;
A method further comprising: The method of claim 2, wherein
A step of causing a circuit to execute a cipher block chaining process using stored information for data that has failed to be written to a cell, and obtaining cipher block chaining processed data to be rewritten to the cell in such a process. Further comprising a method. The method of claim 3, wherein
Writing data in the at least one programming cycle writes a data unit to a cell, and storing stores the data unit after it has been cryptographic block chained. The method of claim 3, wherein
Writing data in the at least one programming cycle writes a data unit to a cell, and storing stores security configuration information related to cipher block chaining of the data unit. The method of claim 5, wherein
The security configuration information includes a cryptographic key, a cryptographic algorithm, and / or a message authentication code and an initial vector. The method of claim 6 wherein:
A method further comprising: retrieving stored security configuration information including a message authentication code and / or an initial vector; and deriving an updated message authentication code from the retrieved message authentication code and / or initial vector. The method of claim 5, wherein
The storing is a method of storing security configuration information regarding cipher block chaining of data units in such a cycle before each such data is written to a cell during at least two consecutive programming cycles. The method of claim 8, wherein
The stored security configuration information includes a location information for specifying a location of a data unit. The method of claim 9, wherein
Caching one or more portions of at least one cipher block chained data unit before it is written to a cell, said writing comprising said at least one cipher during said at least one cycle; The block chain processed unit data and another unit are written to the cell, and the above detection is based on the cached data unit and the other unit, which data unit failed to be written to the cell. Detecting whether or not
The step of identifying the position of the data unit that has failed to be written and takes the form before the cipher block chaining process by using position information, and the circuit performs the cipher block chaining process for such data unit And steps to
A method further comprising: The method of claim 10, wherein
The detected data unit is a data unit in which one or more parts of it are cached, and the method is preceded by such a data unit as well as such a unit in the data stream and fully cell. The method further includes the step of causing the circuit to execute a cipher block chaining process for all data units that have not been written to. The method of claim 11 wherein:
The method further comprising the step of deleting any unit that was not completely written to the cell or marking it as a unit to be deleted from the cell. A method of processing data in a memory system that stores encrypted data comprising a non-volatile memory cell and a cryptographic circuit,
Causing the circuit to perform cryptographic block chaining on the data in the data stream towards the cell;
Writing the data in the data stream to the cells in a series of programming cycles, whereby the data in the data stream is processed by the circuit before being written to the cells;
During at least one programming cycle of a programming cycle, such data is stored by storing information useful for cryptographic block chaining of the data in at least a portion of such cycle before such data is written to the cell. A step of being able to write to the cell again after being subjected to the cryptographic block chaining after the write failure is detected,
Including methods. A memory system for storing encrypted data,
A non-volatile memory cell;
A circuit that performs cryptographic block chaining on the data in the data stream going to the cell;
A controller that writes cipher block chained data from a data stream to a cell in a series of programming cycles, which is useful for writing cipher block chained data in such cycles during at least one programming cycle of the programming cycle. A controller that allows such data to be written to the cell again after a write failure is detected by storing such data before it is written to the cell;
A system comprising: The system of claim 14, wherein
The controller detects a write failure of cipher block chained data for a cell in such a cycle, and writes the cipher block chained data to the cell again using stored information. The system of claim 15, wherein
The controller causes the circuit to execute a cipher block chain process using stored information for data that has failed to be written to the cell after the data has been subjected to the cipher block chain process, and the cipher block to be rewritten to the cell A system for obtaining chained data. The system of claim 16, wherein
Writing data in the at least one programming cycle writes a data unit to a cell, and the controller stores the data unit after it has been cryptographic block chained. The system of claim 16, wherein
Writing data in the at least one programming cycle writes a data unit to a cell, and the controller stores security configuration information related to cryptographic block chain processing of the data unit. The system of claim 18, wherein
The security configuration information includes a cryptographic key, a cryptographic algorithm, and / or a message authentication code and an initial vector. The system of claim 19, wherein
The system wherein the controller retrieves stored security configuration information including a message authentication code and / or an initial vector, and derives an updated message authentication code from the retrieved message authentication code. The system of claim 18, wherein
The controller stores security configuration information regarding cipher block chaining of data units in such a cycle during at least two consecutive programming cycles before such data is written to the cell. The system of claim 21, wherein
The stored security configuration information is a system that includes location information for specifying the location of a data unit. The system of claim 22, wherein
The system further comprises a vault that caches one or more portions of at least one cipher block chained data unit before the portion is written to a cell, the controller during the at least one cycle. The data of the at least one cipher block chained unit and the other unit are written to the cell, and either of the cached data unit and the other unit fails to write to the cell. And detecting the position of the detected data unit that takes the form before the cipher block chaining process using position information, and causing the circuit to execute the cipher block chaining process for such a data unit. system. 24. The system of claim 23.
The detected data unit is a data unit in which one or more parts of it are cached, and the controller is responsible for such data unit as well as preceding such a unit in the data stream and fully cell. A system for causing the circuit to execute a cipher block chaining process for all data units that have not been written to the data. 25. The system of claim 24.
The controller is a system in which any unit that has not been completely written to a cell is deleted from the cell or marked as a unit to be deleted. A memory system for storing encrypted data,
A non-volatile memory cell;
A circuit that performs cryptographic block chaining on the data in the data stream going to the cell;
A controller that writes cipher block chained data from a data stream to a cell in a series of programming cycles, and serves cipher block chaining of data during at least a portion of such cycles during at least one of the programming cycles. A controller that stores information before such data is written to the cell, so that such data can be re-written to the cell after a cryptographic block chaining after a write failure is detected;
A system comprising:

Images