Abstract:
Portable electronic storage devices with hardware based security are described. According to one exemplary embodiment of the present invention, a portable electronic storage device (PESD) comprises a security engine integrated thereon. The security engine is configured to provide data encryption, data decryption, and encryption/decryption key (referred to as a key) generation according to a security standard (e.g., Advance Encryption Standard (AES)). AES is a symmetric encryption algorithm processing data in block of 128 bits. Under the influence of a key, a 128-bit data block is encrypted by transforming the data block in a unique way into a new data block of the same size. AES is symmetric sine the same key is used for encryption and the reverse transformation (i.e., decryption). The only secret necessary to keep for security is the key. AES may use different key-lengths (i.e., 128-bit, 192-bits and 256-bits).

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation-in-part (CIP) of co-pending U.S. patent application Ser. No. 11/624,667 filed on Jan. 18, 2007, entitled “Electronic data Storage Medium with Fingerprint Verification Capability”, which is a divisional patent application of U.S. patent application Ser. No. 09/478,720 filed on Jan. 6, 2000, now U.S. Pat. No. 7,257,714. 
         [0002]    This application is also a CIP of co-pending U.S. patent application Ser. No. 11/674,645 filed on Feb. 13, 2007, entitled “Recycling Partially-Stale Flash Blocks Using a sliding Window for Multi-Level-Cell (MLC) Flash Memory”, which is a CIP of co-pending U.S. patent application Ser. No. 11/466,759 filed on Aug. 23, 2006, entitled “Flash Memory Controller for Electronic Data Flash Card”, which is a CIP of U.S. patent application Ser. No. 10/789,333 filed on Feb. 26, 2004 entitled “System and Method for Controlling Flash Memory”. 
         [0003]    This application is also a CIP of co-pending U.S. patent application Ser. No. 11/742,270 filed on Apr. 30, 2007, entitled “Two-Level RAM Lookup Table for Block and Page Allocation and Wear-Leveling in Limited Write Flash-Memories”, which is a CIP of U.S. patent application Ser. No. 10/957,089 filed on Oct. 1, 2004, entitled “Flash Card Systems”. 
         [0004]    This application is also a CIP of co-pending U.S. patent application Ser. No. 11/864,696 filed on Sep. 28, 2007, entitled “Backward Compatible Extended USB Plug and Receptacle with Dual Personality”, which is a CIP of U.S. patent application Ser. No. 10/854,004 filed on May 25, 2004, entitled “Extended Secure-Digital Card Devices and Hosts”, which is a CIP of U.S. patent application Ser. No. 10/708,712 filed on Feb. 12, 2004 entitled “Dual-personality Extended-USB Plug and Receptacle with PCI-Express or Serial-AT-Attachment Extensions”, now U.S. Pat. No. 7,021,971. 
         [0005]    This application is also a CIP of co-pending U.S. patent application Ser. No. 11/685,143 filed on Mar. 12, 2007, entitled “Data Security for Electronic Data Flash Card”. 
         [0006]    This application is also a CIP of co-pending U.S. patent application Ser. No. 11/770,642 filed on Jun. 28, 2007, entitled “High-Speed Controller for Phase-Change Memory Peripheral Device”, which is a CIP of U.S. patent application Ser. No. 10/818,653, filed on Apr. 5, 2004, now U.S. Pat. No. 7,243,185. 
     
    
     FIELD OF THE INVENTION 
       [0007]    The present invention relates to portable electronic storage devices (PESD), and more particularly to portable electronic storage devices with data security feature included therein. 
       BACKGROUND OF THE INVENTION 
       [0008]    Portable electronic storage devices have become widely accepted and used by consumers. A portable electronic storage device (PESD) uses flash memory as non-volatile storage. There are many types of PESD including, Multi-Media Card (MMC), Secure Digital (SD), micro Secure Digital (micro-SD), Compact Flash (CF), Memory Stick (MS) or Memory Stick-Pro (MS-Pro), Solid State Drive or Disk (SSD), Universal Serial Bus (USB) based flash memory device, etc. 
         [0009]    Due to similarities between the MMC and SD standards (e.g., form factors and construction, locations of connectors, contact pads, etc.), MMC and SD cards are collectively referred to herein as “MMC/SD” cards unless separately specified. 
         [0010]    Many of the PESD do not include any security measures. The data stored on the PESD can be accessed and read by any person who gets hold on the PESD. Worse, the data may be compromised even if the owner of the PESD simply misplaces the PESD. One such prior art PESD is shown in  FIG. 1A . The PESD. 100  comprises a flash memory  102 , a controller  104 (e.g., flash memory controller), and an input/output (I/O) interface  106 . The controller  104  is configured to control read and/or write operations to the flash memory  102 . The I/O interface  106  coupled to the flash memory controller  104  is adapted to provide data input and output of the PESD  100 . The PESD  100  provides a data storage to a host  120  (e.g., a computing device, a consumer electronic device, etc.) via an interface bus  110  (e.g., USB, Serial Advanced Technology Attachment (SATA)). The interface bus  110  transmits the data, signals and power between the host  120  and the PESD  100 . 
         [0011]    Since there is no security measures included in the PESD  100 , the data stored in the flash memory  102  may be accessed by any host device  120  that is capable of accessing data from the PESD. Lack of security on this type of PESD creates a huge security risk for sensitive data (e.g., financial records, personal information, secret data, etc.). 
         [0012]    One of the solutions to the security problem is to include a means to identify the owner of a PESD.  FIG. 1B  shows a prior art PESD that include a finger print sensor for owner identification. The finger print sensor PESD  140  comprises a flash memory  142 , a processing unit  144 , an I/O interface  146 , a power source  150 , a display  152 , at least one functional key  154  and a finger print sensor  158 . The processing unit  144  is a core of the PESD  140  as all other components are coupled thereto. Read and write operations to the flash memory  142  are controlled by a controller (not shown) coupling to the processing unit  144 . The I/O interface  146  is configured to provide data input and output of the PESD  140 . The power source  150  provides the power to the processing unit  144  as requirements for power is much more significant due to processing of finger print. The display  152  is configured to provide output from the processing unit  144 , while the functional key set  154  is configured to provide input. The finger print sensor  158  is configured to scan the finger print of the owner of the PESD  140 . The PESD  140  is configured to provide data storage to a host  170 . Signals, data (in form of data packets) and power are transmitted via the interface bus  160  such as USB, SATA, etc. 
         [0013]    Although the finger print sensor PESD  140  can provide certain level of security to the data stored on the PESD  140 , there are problems with this approach. The drawbacks are as follows: 1) costs associated with manufacturing PESD with finger print sensor are high; 2) complexity related to data sharing when a group of users; 3) finger print sensor may not be reliable as finger print may be altered; and 4) comparison of scan finger print with a reference print may not always be reliable. 
         [0014]    Therefore it would be desirable to provide a PESD with high level of security measures built-in for data stored therein without cost ineffective or not always reliable solutions. 
       BRIEF SUMMARY OF THE INVENTION 
       [0015]    This section is for the purpose of summarizing some aspects of the present invention and to briefly introduce some preferred embodiments. Simplifications or omissions in this section as well as in the abstract and the title herein may be made to avoid obscuring the purpose of the section. Such simplifications or omissions are not intended to limit the scope of the present invention. 
         [0016]    Portable electronic storage devices with hardware based security are disclosed. According to one aspect of the present invention, a portable electronic storage device (PESD) comprises a security engine integrated thereon. The security engine is configured to provide data encryption, data decryption, and encryption/decryption key (referred to as a key) generation according to a security standard (e.g., Advance Encryption Standard (AES)). AES is a symmetric encryption algorithm processing data in block of 128 bits. Under the influence of a key, a 128-bit data block is encrypted by transforming the data block in a unique way into a new data block of the same size. AES is symmetric since the same key is used for encryption and the reverse transformation (i.e., decryption). The only secret necessary to keep for security is the key. AES may use different key-lengths (i.e., 128-bit, 192-bits and 256-bits). 
         [0017]    In another aspect, a security engine is configured to be located on a host that is capable of performing data transactions (i.e., read/write operation) with a PESD. Unencrypted data is encrypted on the host before transmitting to the PESD. Encrypted data stored on the PESD is transmitted to the host before being decrypted. The security engine may be implemented in hardware, software or combination of both. The PESD operates the same way as the PESD without any security measures; however, data stored on the PESD are encrypted hence secured. 
         [0018]    In yet another aspect, the present invention requires a data encryption/decryption security password to turn on data encryption/decryption. In other words, the security engine may only be activated when a correct encryption/decryption security password has been entered. As a result, a mixed mode of data operation may be implemented. In other words, data stored on a PESD may be encrypted and unencrypted depending upon which mode (encryption/decryption ON or OFF). Because data operations either read or write are in a data file basis, a data file password would provide additional security to those data files have a data file password. 
         [0019]    In still another aspect, the encryption key may be created by a manufacturer of a PESD and stored in a system area of the flash memory. The same key may be used for encryption for all data stored on the PESD. Alternatively, the key may be generated for each data file using the data file password. 
         [0020]    According to one exemplary embodiment of the present invention, a portable electronic storage device (PESD) includes at least a security engine configured to provide data encryption and data decryption when required, the security engine includes a key generator for generating and/or holding a key used for the data encryption and the data decryption; a flash memory configured to provide data storage; a controller or microcontroller configured to control the flash memory and the security engine; and an internal data bus configured to provide data and control signal transmission among the controller, the security engine and the flash memory within the PESD. 
         [0021]    The PESD further includes a data error corrector configured to provide data reliability using an error-correcting code (ECC) scheme; a page register configured to hold data in a static random access memory for fast direct memory access; and an input/output (I/O) interface configured to provide data transfer between a host and the PESD. 
         [0022]    One of the objects, features, and advantages of the present invention is to provide a built-in data security for portable electronic storage devices. Other objects, features, and advantages of the present invention will become apparent upon examining the following detailed description of an embodiment thereof, taken in conjunction with the attached drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0023]    These and other features, aspects, and advantages of the present invention will be better understood with regard to the following description, appended claims, and accompanying drawings as follows: 
           [0024]      FIG. 1A  is a block diagram showing a prior art flash memory device; 
           [0025]      FIG. 1B  is a block diagram showing another prior art flash memory device with finger print verification capability; 
           [0026]      FIG. 2  is a block diagram showing salient components of an exemplary portable electronic storage device (PESD) with an Advanced Encryption Standard (AES) based hardware security engine integrated therein, according to an embodiment of the present invention; 
           [0027]      FIG. 3A  is a diagram depicting a first exemplary environment in which one embodiment of the present invention is implemented; 
           [0028]      FIG. 3B  is a diagram depicting a second exemplary environment in which another embodiment of the present invention is implemented; 
           [0029]      FIG. 3C  is a diagram depicting a third exemplary environment in which yet another embodiment of the present invention is implemented; 
           [0030]      FIG. 4A  is a block diagram illustrating data and control signal paths of a PESD with an AES security engine integrated therein, according to an embodiment of the present invention; 
           [0031]      FIG. 4B  is a block diagram showing salient components of the AES engine of  FIG. 4A ; 
           [0032]      FIG. 5A  is a flow chart showing an exemplary process of secured data input and/or output to and from a PESD in the first exemplary environment of  FIG. 3A  in accordance with one embodiment of the present invention; 
           [0033]      FIG. 5B  is a flow chart showing an exemplary process of secured data input and/or output to and from a PESD in either the second or the third exemplary environment of  FIG. 3B  or  FIG. 3C , respectively, in accordance with one embodiment of the present invention; 
           [0034]      FIG. 6  is a flow chart showing an exemplary process of creating a password to enable secured data input and/or output to and from a PESD in accordance with one embodiment of the present invention; 
           [0035]      FIGS. 7A-D  are flow charts showing various options of performing secured data input and output in the AES security engine of  FIG. 4B , according to one embodiment of the present invention; 
           [0036]      FIGS. 8A-8C  are a series of tables showing an exemplary solution for multi-time programming problem encountered in Multi-Level-Cell flash memory based PESD; and 
           [0037]      FIGS. 9A-9G  are block diagrams illustrating various data access schemes between a flash memory controller and flash memory including Single-Level-Cell and Multi-Level-Cell used in PESD. 
       
    
    
     DETAILED DESCRIPTION  
       [0038]    In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will become obvious to those skilled in the art that the present invention may be practiced without these specific details. The descriptions and representations herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the present invention. 
         [0039]    Reference herein to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Used herein, the terms “upper”, “lower”, “top”, “bottom”, “middle”, “upwards”, and “downwards” are intended to provide relative positions for the purposes of description, and are not intended to designate an absolute frame of reference. Further, the order of blocks in process flowcharts or diagrams representing one or more embodiments of the invention do not inherently indicate any particular order nor imply any limitations in the invention. 
         [0040]    Embodiments of the present invention are discussed herein with reference to  FIGS. 2-9G . However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments. 
         [0041]    Referring now to the drawings, in which like numerals refer to like parts throughout several views.  FIG. 2  shows a block diagram of an exemplary portable electronic storage device (PESD)  200  with an Advanced Encryption Standard (AES) based hardware security engine  208  integrated therein, according to an embodiment of the present invention. The PESD  200  (e.g., a flash memory storage card) comprises one or more flash memory devices  202 , a controller or micro-controller  204 , an input/output (I/O) interface  206  (e.g., a USB interface), and an AES security engine  208 . The controller  204  is configured to control the one or more flash memory devices  202  and the AES engine  208 . The one or more flash memory devices  202  comprise either single-level-cell (SLC) or multi-level-cell (MLC) flash memory. Detailed descriptions of various configurations of flash memory device are shown in  FIGS. 9A-9G  below. The AES engine  208  is configured to perform data encryption and data decryption. The controller  204  is configured to transmit data, signals and power via the I/O interface  206  to a host  220 . The I/O interface  206  is configured to adapt data, signals and power in accordance with a standard, for example, USB, SATA, SSD, MMC/SD, micro-SD, MS, CF, etc. The host  220  comprises a computing device (e.g., a personal computer, a consumer electronic device, etc.) capable of transmitting data, signals and power to and from the PESD  200  via an interface bus  210  (e.g., USB, SATA, etc.). 
         [0042]      FIGS. 3A ,  3 B and  3 C show three exemplary environments, an embodiment of the present invention may be implemented in each of which. A first exemplary environment, shown in  FIG. 3A , includes a device  320  coupling to a host  310  via an interface bus  315 . The device  320  comprises a PESD without any security measure. An AES security engine  312  is adapted to the host  310  as software, hardware or a combination of both. In the first environment, the security of the data stored on the device  320  is protected using AES data encryption performed on the AES security engine  312  installed or integrated on the host  310  (e.g., a computing device). In other words, the data stored on the device  320  are encrypted with a key, which can only be accessed by an owner of the device  312 , because the key is protected by a security password only known to the owner. Thus, the data would render useless when compromised, for example, even data is illegitimately accessed, but the encrypted data are not readable without the key. In general, encrypted data stored on the device  320  can only be accessed by the host  310 , because the AES security engine  312  can decrypt the encrypted data using a same algorithm and key. However, in certain situations, other hosts may be able to access the encrypted data. For example, the secret algorithm and key are given and installed on other hosts. 
         [0043]    A second environment shown in  FIG. 3B  comprises a device  340  coupling to a host  330  via an interface bus  335 . In contrast to the first environment, an AES based hardware security engine  342  is adapted or installed to the device  340  instead of the host  330 . Data security is achieved by data encryption performed by the AES security engine  342 . The AES based hardware security engine  342  may be implemented using integrated circuits (e.g., Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), etc.). Similar to the first environment, data stored on the device  340  are encrypted with a key only known to the owner of the device  312 . The device  340  may be accessed by other hosts equipped with the same interface bus  335 . 
         [0044]      FIG. 3C  shows a third environment, which is a variation of the second environment. The third environment comprises an AES based hardware security engine  362  adapted to a device  360 , and a host  350  coupling to the device  360  via an interface bus  355 . The difference between the third and the second environment is that the host  350  is configured to perform data compression and decompression in accordance with certain access control standards (e.g., digital rights management or digital restrictions management (DRM)). The compressed data is then encrypted and stored on the device  360 . The encryption and decryption of the compressed data are performed by the AES based hardware security engine  362  with a key known to the owner of the device  360 . 
         [0045]      FIG. 4A  is a block diagram showing data flow and control signal path of a device  400  with an AES security engine  410  (e.g., AES security engine  342  of  FIG. 3B  or AES security engine  362   FIG. 3C ), according to an embodiment of the present invention. The device  400  comprises an I/O interface  402 , a controller or micro-controller  404 , a static random access memory (SRAM) buffer or page register  408 , an AES security engine  410 , other functional logic blocks  412  (e.g., a data error corrector using Error Correction Code (ECC) technique), a flash memory interface  414  and at least one flash memory device  418 . An internal data bus  420  is configured to provide data transmission within the device  400 . The internal data bus  420  is depicted as solid lines with arrow, which indicate direction of data flows. For example, data are directed to the AES security engine  410  and other functional logic blocks  412  for processing, then the processed data are sent out. Unencrypted data are sent to the AES security engine  410  for encryption, while encrypted data are for decryption. The control signal path (e.g., AES security engine control signal path  422  and control signal path  424 ) are indicated as dotted lines. 
         [0046]    The I/O interface  402  is configured to provide data, signals and power transmission to and from the host (not shown) in accordance with one of the standards (e.g., USB, SATA, etc.). The controller  404  is configured to provide controls to retrieve and store data to the at least flash memory device  418  via the flash memory interface  414 . The controller  404  is further configured to provide controls to the AES security engine  410  such that data are encrypted and decrypted accordingly. Controls to other functional logic blocks  412  (e.g., data error corrector) are also provided by the controller  404 . The SRAM buffer  408  is configured to provide directed memory access (DMA) so that the AES security engine  410  can perform data encryption/decryption without delay due to slower flash memory access. The data error corrector may be configured to create ECC parity or other overhead information to ensure data can be stored and retrieved with high reliability, for example, a 4-bit ECC represents an ECC code may correct up to four (4) individual error bits. In one embodiment, Reed-Solomon technique is used in the ECC data error corrector so that data error within the threshold of the Reed-Solomon technique can be recovered. In another embodiment, a BCH (Bose, Ray-Chaudhuri, Hocquenghem) code is used for data error correction. 
         [0047]      FIG. 4B  is a block diagram illustrating further details of the AES security engine  410  of  FIG. 4A . The AES engine  410  comprises an in-buffer  430 , an out-buffer  450 , an AES data encryption logic block  442 , an AES data decryption logic block  444  and a key generator  434 . Data flow paths are shown using solid lines with arrow. Control signal paths (e.g., enable signal for data encryption and/or decryption) are shown with dotted lines. The in-buffer  430  is configured to receive data as indicated by data-in. The key generator  434  is configured to generate and/or hold a key used in data encryption and data decryption. The AES encryption logic block  442  is configured to encrypt the received data from the in-buffer  430  using the key from the key generator  434 . The AES decryption logic block  444  is configured to decrypt the received data from the in-buffer  430  using the key from the key generator  434 . In one embodiment, the encryption key and decryption key are the same as symmetry keys. The out-buffer  450  is configured to hold processed data from either the AES encryption logic block  442  or the AES decryption logic block  444 . 
         [0048]      FIG. 5A  is a flow chart illustrating an exemplary process  500  of providing data security for the device  320  (e.g., PESD) with the AES security engine  312  on the host  310  in the first exemplary environment ( FIG. 3A ). The process  500  starts with the device  320  electrically connected to the host  310 , for example, a PESD plugged into a computing device. At this point, the device  320  receives power from the host  310 . The device  320  is then initialized at  501 . The host  320  initializes with a control program in the AES security engine  312  at  502 . In one embodiment, the initial operation mode is set to an “AES security OFF” or “encryption/decryption OFF” state at  504 . Data transmission between the host  310  and the device  320  is conducted without any AES security in the “encryption/decryption OFF” state at  506 . Next, when AES security is desired, an AES security password for turning on AES security is checked at decision  508 . If AES security password is not correct at decision  508 , then the AES security will not be enabled (i.e., “encryption/decryption OFF”). The process  500  follows the “no” branch back to  504 . 
         [0049]    If the AES security password is correct at decision  508 , the process  500  changes the state to “AES security ON” or “encryption/decryption ON” at  510 . As a result, unencrypted data are encrypted before sending to the device and encrypted data are decrypted after receiving from the device  320  as indicated in data path  512 . Data encryption and data decryption are performed in the AES security engine  312  using a key. The same key may be used for encrypting all of the data to be stored on the device. Alternatively, a different key may be used for each individual data file, when data file is optionally protected by a data file password. The key would be generated using the data file password, which is then associated with the data file as an overhead or metadata. For example, the overhead may be appended to the corresponding data file, or the overhead may be stored in a designated storage area at  514 . Optional data file password is either created or retrieved for writing or reading a data file. Data encryption and decryption becomes a data file dependent in this situation hence higher security achieved. According to another embodiment, AES encryption and decryption is performed with one master encryption/decryption key (i.e., the key associated with the decision  508 ), even if each data file is protected by a specific data file password. Next at decision  516 , a command (e.g., a signal, an interrupt, etc.) for exiting AES security is checked. If “no”, the process  500  remains at “encryption/decryption ON” state at  510 . Otherwise, the process  500  follows the “yes” branch to  504  back to “encryption/decryption OFF” state. Because data encryption and decryption and key generation are performed in the AES engine  312  located on the host  310 , the device  320  operates in a normal operation  518 . 
         [0050]    Referring now to  FIG. 5B , which is a flowchart illustrating an exemplary process  540  of providing data security for the device  340  (e.g., PESD) with the AES security engine  342  on the device  340  in the second exemplary environment ( FIG. 3B ). The process  540  applies to the third exemplary environment ( FIG. 3C ) due to a same data transmission procedure. The following descriptions are for the second environment. 
         [0051]    The process  540  starts when the device  340  is electrically and physically connected to the host  330  via the interface bus  315 . For example, a USB flash memory device is plugged into a USB receptacle of a computer. The device  340  receives power and signals from the host  330  through the interface bus  315  and is initialized at  542 . The host  330  loads a device control program from the device  340  at  543  and establishes a data transfer session. With the device control program running on the host  330  at  545 , data transmission is conducted between the host  330  and the device  340  in “no AES security” mode. The device  340  is set to an “AES security OFF” or “encryption/decryption OFF” state at  544 . This state will be reset when a request to turn on AES security from the host  330  at  547  is received. Included in the request is an AES security password, which is then sent to the device  340  for verification at decision  546 . The AES security password may be retrieved from a special location on the host  330  or created by a user (i.e., enter a password). If the AES security password is incorrect at decision  546 , the AES security request is denied and device remains in the “AES security OFF” state. If the AES security password is correct, the process  540  sets the device  340  to an “AES security ON” or “encryption/decryption ON” state at  548 . In the “AES security ON” state, an encryption/decryption key is activated. The key may be created in a number of ways, for example, provided by manufacturer of the device; inputted by a user; generated by using the AES password, etc. 
         [0052]    When the device  340  is in the “AES security ON” state, the device  340  continuously checks each data access command (read or write request from the host  330  at  549 ) at decision  550 . Once a read/write command is received, the device  340  performs an optional data file password request to the host  330  at  552 . The host  330 , upon receiving the data file password request, prompts the user to enter a data file password at  551 . The data file password may comprise a simple password, a security phrase, reminder hints for password, and the likes. The user entered data file password is then transmitted to the device  340 . The AES security engine  342  may use the data file password to generate a data file dependent key to encrypt the associated data file in a data write operation at  554 . The data file password is appended to the associated data file as an overhead or metadata. In a data read operation, the AES engine  342  extracts the overhead or metadata to obtain the stored password. If user entered data file password matches the extracted password, the data file is decrypted at  554 . Since the data encryption and data decryption are performed by the AES security engine  342  on the device  340 , the data sent and received at the host are conducted normally at  555 . The “AES security ON” state is terminated when an exit command is detected by the device  340  at decision  556 . The command is sent from the host  330  at  557 . Once the security termination command is confirmed, the device  340  is set to “AES security OFF” state at  544 . Otherwise, the device  340  stays in the “AES security ON” state at  548 . 
         [0053]      FIG. 6  shows a flowchart for a password creation process  600 . The second environment ( FIG. 3B ) is used for describing the password creation process  600  below. The process  600  starts when the device  340  is electrically connected to the host  330 . Signals and power are drawn from the host  330  to the device  340  as the device is initialized at  602 . A device control program is loaded and initialized on the host  330  at  603 . The default state for the device  340  is set to “encryption/decryption OFF” at  604 . Next, at  606 , the device sends password status of the device to the host. For example, the password status may comprises one bit of data with zero (0) indicates no password and one (1) represents password exists on the device. The host reads the password status at  608  and checks the status at decision  610 . If there is no password on the device, then the decision  610  becomes no. The host prompts user to enter a password and/or password hints at  612 . The password hints may comprise a special name, a special event or a phrase for reminding user in case of forgotten password. At  614 , the new user entered password is sent to the device. Upon receiving the newly entered password, the device writes or stores the password and/or hints to a secured system area of the flash memory at  616 . The stored password on the device may be hashed or scrambled in a particular manner that can only be understood by the device. 
         [0054]    If the decision  610  is true, that means there is a password existed on the device. The host prompts user to enter a password at  618  and transmits the user entered password to the device at  620 . The device checks the received user entered password at decision  630 . If it is determined that the user entered password is not correct, the device stays in the “encryption/decryption OFF” state at  632 . Otherwise, the device turns on data security by setting the state to “encryption/decryption ON” at  634  and  636 . In order to handle user error in the process of entering the password, the result of the decision  630  is sent back to the host in a password verification status. The password status may comprise a single bit data indicator; for example, one (1) for the correct password and zero (0) for the incorrect password, or vice versa. The password verification status is then checked at decision  622  in the host. If the password verification status indicates a correct password, the host will start data transmission. Otherwise, data is not transmitted by the host  330 , the process  600  moves back to  612  prompting user for another password entry. When the number of repeated password entries is larger a predefined maximum (e.g., three (3)), the decision  624  becomes true. And the host  330  will not allow any additional password entry attempt. In certain more strict implementation, the files may be erased for security purpose if the number of password entry attempts is higher than the pre-defined threshold. 
         [0055]      FIG. 7A  is a flowchart showing an exemplary process  700  of performing data file reading and writing using data encryption and decryption in an AES engine using one key created by manufacturer of a PESD, according to an embodiment of the present invention. The process  700  is preferably understood in conjunction with previous figures especially  FIG. 4A  and  FIG. 4B . 
         [0056]    Process  700  starts with the AES security engine  410  writes the encryption/decryption key to the key generator  434  at  702 . The key is created by the manufacturer of the device  400  (PESD) and stored in the system area of the flash memory. When a new data access command arrives, the AES security engine  410  determines whether it is a data “read” or “write” command at decision  704 . If the command is a data write command, the AES security engine  410  accesses the data from the I/O interface  402  to the SRAM buffer  408  with direction memory access (DMA) scheme at  705 . Next at  706 , the data in the SRAM buffer  408  is encrypted in the AES encryption block  442  through the in-buffer  430  in conjunction using the key from the key generator  434 . The encrypted data is then written back to the SRAM buffer  408  via the out-buffer  450 . Then the encrypted data in the SRAM  408  is accessed by the data error corrector (i.e., other function logic  412 ) to include ECC overhead information (i.e., parity or error code) to enhance data reliability at  707 . Finally at  708 , the ECC processed data in the SRAM buffer  408  is written to the flash memory  418  through the flash memory interface  414 . Logical block address (LBA) of the “write” data is converted into physical block address (PBA) of the flash memory  418 . The data “write” command ends after step  418 . A variety of flash memory devices will be described below in  FIGS. 9A-9G . 
         [0057]    Referring back to decision  704 , when the data access command is a data “read” command, the AES security engine  410  retrieves the data (e.g., DMA) from the flash memory device  418  to the SRAM buffer  408  at  711 . PBA of the flash memory is converted to LBA in the SRAM buffer. Next at  712 , the retrieved data in the SRAM buffer  408  is checked for error by the data error corrector. At decision  713 , it is determined whether there are excessive amount of errors in the retrieved data in the SRAM buffer  408 . If there are excessive errors, the excessive error condition is reported to the local controller  404  that the data cannot be read and recover at  714  before process  700  ends. If there are errors that can be corrected or recovered, the retrieved data is corrected by the data error corrector and stored back to the SRAM buffer  408  at  715 . If there is no error, the process  700  moves directly to  716 . At  716 , the encrypted data in the SRAM buffer  408  is accessed by the AES decryption block  444  through the in-buffer  430 . The decryption is performed using the key from the key generator  434  (written from the system area at step  702 ). The decrypted data is then written back to the SRAM buffer  408  through the out-buffer  450 . Finally, at  718 , the unencrypted data is send to the host via the I/O interface  402  to complete the data “read” operation. 
         [0058]      FIG. 7B  is a flowchart showing an exemplary process  720  of performing data file reading and writing using data encryption and decryption in an AES engine using one encryption/decryption key created by manufacturer of a device  400  (PESD) with additional security provided by a data file password for each data file, according to another embodiment of the present invention. Similar to  FIG. 7A , the process  720  is preferably understood in conjunction with previous figures especially  FIG. 4A  and  FIG. 4B . 
         [0059]    The process  720  starts with the AES security engine  410  writes the encryption/decryption key to the key generator  434  at  721 . Next, at  722 , a data file password associated with a data file access command is received at the device  400  (i.e., sent from the host). The device determines the data access command is a data “read” or “write” at decision  724 . If a data “write” command is determined, received data are copied from the I/O interface  402  to the SRAM buffer  408  using DMA scheme at  725 . Then the unencrypted data in the SRAM buffer  408  is encrypted by the AES encryption block  442  through the in-buffer  430  using the key from the key generator  434 . The encrypted data is then written back to the SRAM buffer  408  through the out-buffer  450  at  726 . The additional security is created by generating overhead information for each data file based on the data file password at  727 . The overhead is then appended or associated with the data file at  728 . Next the encrypted data along with the overhead information is processed by the data error corrector at  729 . Finally the ECC processed data from the SRAM buffer  408  is written to the flash memory  418  through the flash memory interface  414 . 
         [0060]    If the data access command is determined as a data “read” command at decision  724 . Data stored in the flash memory device  418  for the requested data file are retrieved to the SRAM buffer  408  at  731 . Next, the retrieved data is checked for error at  732 . At decision  733 , if it is determined that there are excessive errors, the data error condition is reported to the local controller  404  at  734  and process  720  ends. If the error is correctable by the data error corrector. The ECC data correction is performed at  735 . If there is no error, the process  720  moves directly to  736 . At  736 , the overhead information for the retrieved data file is read as reference password for authenticating the data “read” request. Then at decision  737 , the data file password received from the host is compared with the reference password obtained from the overhead information. If the received data file password matches the reference, the encrypted data in the SRAM buffer  408  is decrypted in the AES decryption block  444  of the AES security engine  410  at  738  before sending the unencrypted data to the host  739 . 
         [0061]    If the decision  737  determines the data file password is incorrect comparing to the reference password, the process  720  allows the user to re-enter the data file password from the host in predefined number (e.g., three times) of password entry attempts. If user has not exceeded the maximum allowed number of password entry attempts, the result of decision  740  is “no”. The user operates the host is given another opportunity to enter the data file password or password hints at  741 . The password is then received by the device at  742  for checking at decision  737 . If the number of password entry attempts exceeds the allowable, decision  740  becomes “yes”, data file “read” access is denied. 
         [0062]      FIG. 7C  is a flowchart showing an exemplary process  750  of performing data file reading and writing using data encryption and decryption in an AES engine using encryption/decryption key created for each data file using the data file password, according to yet another embodiment of the present invention. Again, the process  750  is preferably understood in conjunction with previous figures especially  FIG. 4A  and  FIG. 4B . 
         [0063]    The process  750  starts by receiving a data file password associated with a data file access command at the device  400  (e.g., a PESD) at  752 . The data file access command is then determined at decision  754 . If the data file access command is a data “write” command, the data file password is sent to the key generator  434  to generate an encryption key at  755 . This means that the key becomes data file dependent instead of one key for the entire device used in the processes  700  and  720 . Steps  756  to  761  of the process  750  are the same as steps  725  to  730  of the process  720 . The data file “write” command ends after step  761 . 
         [0064]    Similarly if the data file access command is a data “read” command, steps  764  to  770  of the process  750  are the same as the steps  731  to  736  of the process  720 . If it is determined that the received data file password at  752  matches the password extracted from the overhead information of the request data file, the result of the decision  770  is “yes”, and the matched data file password is sent to the key generator  434  to generate a decryption key at  771 . Then the encryption data in the requested data file are decrypted in the AES decryption block  444  of the AES security engine  410  at  772 . The decrypted data is written to the SRAM buffer  408  before sending to the host through the I/O interface  402  at  703 . 
         [0065]    If the received password is determined to be incorrect at the decision  770 , the following steps  774  to  776  of the process  750  are the same as the steps  740  to  742 . 
         [0066]    Referring now to  FIG. 7D , which is a flowchart showing an exemplary process  780  of performing data file reading and writing without AES security or in the state of “encryption/decryption OFF” in accordance with one embodiment of the present invention. 
         [0067]    The process  780  starts by receiving a data file access command from the host at  781 . Next, at decision  782 , the data file access command is determined whether it is a data “read” or “write” command. If the command is data “write”, data of the data file is written to the SRAM buffer  408  through the I/O interface  402  using DMA scheme at  783 . Then the data in the SRAM buffer  408  is processed by the data error corrector at  784 , in which ECC overhead information is created for data reliability. Finally, the ECC processed data in the SRAM buffer  408  is written to the flash memory  418  through the flash memory controller  414  at  785 . 
         [0068]    If the data file access command is a data “read” command, the device retrieves data of the requested data file from the flash memory  418  to the SRAM buffer  408  at  786 . Next, at  787 , the retrieved data in the SRAM buffer  408  is checked for error in the data error corrector. At decision  788 , if it is determined that there are excessive ECC errors, the data error condition is reported to the local controller  404  at  789  and the process  780  ends. If the data error can be corrected, the ECC data correction procedure is performed at  790  to correct the error. If there is no data error determined at decision  788 , the process  780  goes directly to  791 , in which the data in the SRAM buffer  408  is sent to the host through the I/O interface  402 . It is noted that the AES security engine  410  is not used in any step of the process  780 . 
         [0069]    To support various AES security measures described above, flash memory devices of greater capacity are used in some embodiments. Advances in flash technology have created many types of flash memory device. For example, Multi-Bit Cell (MBC) or Multi-Level Cell (MLC) flash memory devices have a higher capacity than Single Bit Cell (SBC) or Single-level cell (SLC) flash memory devices for the same form factor. In general, SLC type of flash memory cells is more reliable with higher data transmission rate, while MLC type flash memory cells is more economical. SLC type flash memory cells may include Small Block SLC (SSLC) and Large Block SLC (LSLC). Likewise, MLC type of flash memory cells may include Small Block MLC (SMLC) and Large Block MLC (LMLC). Flash memory with SMLC is typically arranged into 512+16 bytes per page, while flash memory with LMLC is 2048+64 bytes per page. The “+16” bytes and “+64” bytes are spare area for each page. A page is the unit used for data access (read or write). Therefore, the data access speed depends upon the size of the page. A larger page size (e.g., 2048 bytes) flash memory has a better data write performance against a smaller page size flash memory (e.g., 512 bytes). To support larger page size, the flash memory controller (e.g., controller  404  of  FIG. 4A ) needs to control (e.g., detect and access) the page size accordingly. 
         [0070]    A typical flash memory device contains an identification (ID) code that shows the flash memory type, the manufacturer and characteristics of the flash memory such as page size, block size, capacity, etc. Read ID code information is performed when the device (e.g., PESD) is electrically and physically connected to a host during the initialization. 
         [0071]    In one embodiment, the flash memory controller is configured with a 512-byte page register (e.g., SRAM buffer  408  of  FIG. 4A ). Data to be read from and written to the flash memory need to be copied to the register first for various processing (e.g., encryption/decryption, ECC data error recovery, etc.). The data access is performed in a sequential block by block order. Each data access is limited to a 512-byte page. 
         [0072]    In another embodiment, the flash memory controller is configured with a larger register (e.g., 2048-byte, 4096-byte, etc.). The larger register allows multiple of 512-byte data transfer performed in parallel, therefore improving the data transfer performance. One example of the larger register PESD is based on MLC flash memory, which may comprise 2048-byte per page. However, there is a limitation as to writing data into each block. A block becomes restricted when the block is partially written. This problem is referred to as “Partial Write Prohibited” or “NOP=1 (Number of Program equal to 1)”. The term “Program” means writing data to the flash memory. With many of the convention flash memory controller configured to perform a 512-byte data transfer, the larger block sized flash memory encountered the “Partial Write Prohibited” problems. Since the present invention may be implemented on a PESD using MLC based flash memory, the “Partial Write Prohibited” problem needs to be avoided to ensure higher data transfer speed. 
         [0073]    The solution to this problem is described below using a 2048-byte block sized flash memory (e.g., MLC flash memory) as an example. The solution uses a page mapping scheme in a flash memory controller to avoid multi-time programming to one physical block of the flash memory. 
         [0000]    
       
         
               
               
               
               
               
               
               
               
               
             
           
               
                 TABLE 1A 
               
               
                   
               
               
                 physical block 
                 0 
                 1 
                 2 
                 3 
                 4 
                 5 
                 6 
                 7 
               
               
                   
               
             
             
               
                 logical block 
                 1 
                 5 
                 63 
                 63 
                 63 
                 63 
                 63 
                 63 
               
               
                   
               
             
          
         
       
     
         [0000]    
       
         
               
               
               
               
               
               
               
               
               
             
           
               
                 TABLE 1B 
               
               
                   
               
               
                 physical block 
                 0 
                 1 
                 2 
                 3 
                 4 
                 5 
                 6 
                 7 
               
               
                   
               
             
             
               
                 logical block 
                 1 
                 5 
                 8 
                 63 
                 63 
                 63 
                 63 
                 63 
               
               
                   
               
             
          
         
       
     
         [0000]    
       
         
               
               
               
               
               
               
               
               
               
             
           
               
                 TABLE 1C 
               
               
                   
               
               
                 physical block 
                 0 
                 1 
                 2 
                 3 
                 4 
                 5 
                 6 
                 7 
               
               
                   
               
             
             
               
                 logical block 
                 1 
                 5 
                 8 
                 8 
                 63 
                 63 
                 63 
                 63 
               
               
                   
               
             
          
         
       
     
         [0074]      FIG. 8A-8C  and Table 1A-1C collectively show how the flash memory controller solves this problem in MLC based PESD.  FIG. 8A  shows eight physical blocks with 2048-byte per block. There are valid data stored in physical blocks  0  and  1  and the rest are empty. Table 1A is a correlation table between physical block number of the flash memory and logical block number of the data to be written. The first row of Table 1 lists physical blocks from block zero (block  0 ) to block seven (block  7 ). The second row lists the corresponding logical block number to the physical block numbers. For example, physical block  0  corresponds to logical block  1  and physical block  2  corresponds to logical block  5 . The rest of the logical block numbers is shown as sixty-three ( 63 ), which is a 6-digit binary number of one&#39;s (i.e., b‘111111’). That is an indicator for empty flash memory as shown in  FIG. 8A . 
         [0075]    After a first 1024-byte data write command from the host is received and executed on the PESD, updated status of the flash memory is shown in  FIG. 8B  and Table 1B.  FIG. 8B  shows the 1024-byte data is written in two pages of 512-byte in physical block  2  of the flash memory. Table 1B shows that the logical block  8  corresponding to physical block  2 . As a result, the physical block  2  has been partially written. 
         [0076]    Then a second 1024-byte data write command has arrived from the host. Although there is enough space to hold newly arrived second 1024-byte data, the limitation of “Partial Write Prohibited” prevents the device to store or write into physical block  2 . It would need to find the next available space which is physical block  3 . However, that would cause physical block  3  becoming partially written. As a result, the large page flash memory such as MLC based flash may be wasted due to this problem. One solution to this problem is to have the controller to do page mapping before writing to the flash memory. For example, the first 1024-byte data in the partially written physical block  2  and the newly arrived second 1024-byte data are mapped in the register (i.e., a 2048-byte register or SRAM buffer) before writing to the next available physical block  3  as shown in  FIG. 8C . Table 1C reflects the new data in the physical block  3 , which corresponds to logical block  8 . This scheme ensures partially used spaces are optimized to reduce waste. 
         [0077]    To access data, the controller searches the logical block number in Table 1C backwards starting from physical block  7  to physical block  0 . The first matched logical block is the newest updated data. For example, physical block  3  corresponds to logical block  8  in Table 1C. When the controller searches for the logical block  8 , the first encountered location is physical block  3 . Although the logical block  8  also corresponds to physical block  2 , the controller would not select this because physical block  3  is always searched first. In other words, only the last of repeated logical block numbers is the newest data. All of the earlier ones can be regarded as “out-of-date” data block. 
         [0078]    According to one embodiment of the present invention, the encrypted data created by the AES security engine  410  of  FIG. 4A  needs to be written or stored in the manner described herein for MLC based flash memory. 
         [0079]    The flash memory device shown and described above in  FIG. 4A  may comprise many different types.  FIGS. 9A-9G  are block diagrams illustrating various data access schemes between a flash memory controller and flash memory including Single-Level-Cell and Multi-Level-Cell. Due to data reading and writing in a flash memory device requiring access and verification. The data access speed is a major concern to ensure a good device performance. 
         [0080]    In one embodiment, a PESD comprises a flash memory controller  902  and an 8-bit based flash memory integrated circuit (IC) chip  904  shown in  FIG. 9A . The controller  902  controls the flash memory IC chip  904  via an 8-bit data bus, which is referred to as single-channel data bus. In another embodiment shown in  FIG. 9B , A PESD comprises a flash memory controller  912  and a 16-bit data bus based flash memory IC chip  914 . The 16-bit data bus is referred to as dual-channel data bus. The dual-channel data bus in general provides two times of speedup in comparing with the single-channel data bus does. 
         [0081]    In yet another embodiment shown in  FIG. 9C , a PESD comprises a flash memory controller  922  and two 8-bit based flash memory IC chip  924   a  and  924   b . Each of the two chips  924   a  and  924   b  is controlled by the controller  922  via an 8-bit data base. 
         [0082]      FIG. 9D  shows yet another alternative embodiment of a PESD comprising a flash memory controller  932  and an 8-bit based dual-die flash memory IC chip  934 . The single channel interleave operation is achieved with two flash memory dies. In yet anther embodiment shown in  FIG. 9E , a PESD includes a flash memory controller  942  and an 8-bit based flash memory chip  944  with four dies mounted therein. Alternatively, according to yet anther embodiment,  FIG. 9F  shows another PESD, which comprises a flash memory controller  952  and four 8-bit based flash memory chip  954   a - 954   d.    
         [0083]      FIG. 9G  shows a much more complex PESD, which comprises a flash memory controller  962  and a plurality of flash memory chips  964   a - 964   p  as a flash memory module. The controller  962  includes sixteen (16) chip-enablers (CS#), four (4) ready/busy (RB#) signals and four (4) channels to control data and signals. The flash memory module may include sixty-four (64) single-channel flash memory dies or chips, thirty-two (32) dual-channel flash memory dies or sixteen (16) quad-channel flash memory dies. 
         [0084]    Although the present invention has been described with reference to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of, the present invention. Various modifications or changes to the specifically disclosed exemplary embodiments will be suggested to persons skilled in the art. For example, whereas the exemplary security measure is shown and described using AES security, other types of equivalent security measures may be used. Additionally, whereas the interface bus is described and shown as USB, other data buses may be used such as Peripheral Component Interconnect Express (PCI Express or PCI-E), Serial ATA, Firewire (i.e., IEEE 1394), small computer system interface (SCSI), etc. In summary, the scope of the invention should not be restricted to the specific exemplary embodiments disclosed herein, and all modifications that are readily suggested to those of ordinary skill in the art should be included within the spirit and purview of this application and scope of the appended claims.