Storage card with integral file system, access control and cryptographic support

[00002] This invention relates generally to multimedia cards, and more particularly, but not exclusively, provides a portable storage card having an integral file system, access control, and cryptographic support.

[00003] Conventional handheld computing devices are becoming more popular. They were initially used primarily for note taking and as appointment reminders, but they are gradually becoming more versatile.

[00004] The conventional handheld computing devices typically have limited amounts of storage capacity, so many of them now support removable media in the form of multimedia cards and memory sticks®. For example, the Sony CLIE™ uses removable memory sticks® ranging in size from 8 MB up to 128 MB.

[00005] With the introduction of these removable media types, it becomes possible for the end user to store large amounts of data. Some of this data may be of a confidential nature and/or include copyrighted material, and the end user may wish to restrict access to this data to a specific authorized user or class of users. The current generation of secure media attempts to address this problem by requiring authentication by the user. However, these secure media devices implement a type of security where the file is visible in an encrypted form even without authentication. This is undesirable because the encrypted data might still be decrypted using a brute-force “try all permutations” type approach. Further, encrypted keys or passwords needed to decrypt the encrypted data may also be visible without authentication and therefore subject to decryption without user authentication.

[00006] For example, referring to FIG. 1, a block diagram illustrating an embodiment of a conventional handheld computer device 105 communicatively coupled to a conventional removable secure media card 145 is shown. The computer device 105 includes an application 110, file system 120, authentication engine 130, and an authentication graphical user interface 140 (GUI), which all reside in memory (not shown) of the computer device 105. The card 145 includes an authentication database 150, sector driver 160, and physical media 170.

[00007] The secure media card 145 protects data by keeping the authentication database 150 on the card 145 and by encrypting the database 150. This design protects the authentication database 150 by preventing authentication codes and encrypted passwords in database 150 from being compromised. However, the secure media card 145 itself is accessed by sectors, and does not know which sectors belong to protected and unprotected files, so it cannot perform access checks at the sector level. Therefore, the raw encrypted data is accessible at the sector level.

[00008] The present invention provides a crypto-media card having an integral file system, access control, and cryptographic support. This new card solves the problem of access to raw encrypted data by providing a device that responds to file access commands instead of sector access commands. With this implementation, it is not possible to access the encrypted data unless a user has been authenticated. In fact, it is possible to even hide the existence of the encrypted data on the card if desired.

[00009] The card comprises an authentication engine and database, a file system, a sector driver, and an encryption engine. The authentication engine and database authenticates users, thereby enabling to access the file system, which reads and writes from and to memory on the card. The encryption system enables encryption and decryption of data on the card. A computing device that is communicatively coupled to the card issues file access commands directly to the removable card. The authentication engine and database can accept or reject access to protected data dependent on whether or not the user has performed authentication with the card. Further, the card does not allow sector level access, thereby preventing access to encrypted data.

[00010] In an alternative embodiment of the invention, the card includes a biometric reader, such as a fingerprint reader, voice analyzer, or retina scanner, that is integral to card and is used to gain access to data on the card.

[00011] The present invention further provides methods for storing and accessing data. In contrast to conventional removable storage media, both methods are performed within the storage card, thereby preventing sector level access to data stored on the card. The storing method comprises: receiving a write request, requesting a password (and/or other authentication data, such as biometric data); receiving and validating the password; and encrypting and storing the data if the password is valid. The accessing method comprises: receiving a read request; requesting a password (and/or other authentication data, such as biometric data); receiving a password and validating the password; retrieving a decryption key and decrypting the read-requested data using the key.

[00012] The card and methods therefore advantageously prevents unauthorized sector level access to data stored on the card.

[00019] The following description is provided to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles, features and teachings disclosed herein.

[00020] The present invention provides a crypto-media card that only responds to file access commands instead of to sector access commands. An advantage of the crypto-media card over conventional removable storage cards is that the crypto-media card prevents reading of raw data on the card without authentication. Further, the crypto-media card stores authentication codes on the crypto-media card instead of on a computer. Storing the authentication codes locally is superior because otherwise the authentication codes are extremely vulnerable because they reside on the computing device and can be relatively easily read. Typically, it is easy to load new programs onto this computing device, and these new programs can be used to subvert the authentication. When the authentication code is on the removable storage device, the authentication code is protected from malicious programs that can be loaded on the computing device.

[00021] In addition, to prevent unauthorized access to data on the crypto-media card, the card can be made physically tamperproof in many different ways, including encasing the crypto-media card in epoxy so that tampering with the device will destroy the device. Alternatively, crypto-media card can be made from a single chip. This considerably complicates the process of intercepting the signal between different components extremely difficult, since it necessitates use of an advanced microscope, such as a scanning tunneling microscope, to view the signal paths.

[00022] A further advantage of the crypto-media card is that it prevents decryption key interception since the decryption key is stored on the crypto-media card and not on a computer and is never transmitted external to the crypto-media card.

[00023] FIG. 2 is a block diagram illustrating a crypto-media card 240 communicatively coupled to a computer 200 according to an embodiment of the invention. The term computer as used herein refers generically to a computing device and may include, for example, a desktop computer, a laptop computer, a personal digital assistant, etc. The computer 200 includes a central processing unit (CPU) 205; working memory 210; persistent memory 215; input/output (I/O) interface 220; display 225 and input device 230, all communicatively coupled to each other via system bus 235. CPU 205 includes a processor capable to execute software stored in persistent memory 215. Working memory 210 may include random access memory (RAM) or any other type of read/write memory devices or combination of memory devices. Persistent memory 215 may include a hard drive, read only memory (ROM) or any other type of memory device or combination of memory devices that can retain data after example computer 200 is shut off. I/O interface 220 is communicatively coupled, via wired or wireless techniques, crypto-media card 240, thereby enabling communications between example computer 200 and the crypto-media card 240.

[00024] Display 225 may include a liquid crystal display or other display device. Input device 230 may include a keyboard, mouse, or other device for inputting data, or a combination of devices for inputting data.

[00025] One skilled in the art will recognize that the example computer 200 may also include additional devices, such as network connections, additional memory, additional processors, LANs, input/output lines for transferring information across a hardware channel, the Internet or an intranet, etc. One skilled in the art will also recognize that the programs and data may be received by and stored in the system in alternative ways.

[00026] Crypto-media card 240 may include a memory stick or any other portable memory device that can be removeably coupled to computer 200. The card 240 comprises an I/O interface 245, a CPU 250, RAM 260 (or other working memory type) and non-volatile memory 255. The components of card 240 are all interconnected together for communication via bus 270. In addition, card 240 may also comprise a biometric reader 265 coupled to bus 270. I/O 245 enables communication with computer 200. CPU 205 processes instructions stored in non-volatile memory 255. Biometric reader 265 is a device for read biometric data, such as a fingerprint scanner, retina scanner, or voiceprint analyzer.

[00027] FIG. 3 is a block diagram illustrating software components of the crypto-media card 240 (FIG. 2) and computer 200 (FIG. 2). The computer 200 includes an authentication graphical user interface (GUI) 300 and an application 310. The card 240 includes an authentication engine 320, authentication database 350, file system 330, encryption engine 360, and sector driver 340.

[00028] Application 310 sends file read and write commands to file system 330, which only responds to the commands upon receiving authorization from authentication engine 320. Authentication GUI 300 prompts a user for a password and sends it to authentication engine 320 to authenticate the password using data from database 350. GUI 300 may also encrypt the password before sending it to authentication engine 320. In an alternative embodiment of the invention, biometric reader 265, which is integral with card 240, may prompt a user for biometric data for authentication by engine 320. Once authentication engine 320 authenticates the password or biometric data, engine 320 gives authorization to file system 330 to read and/or write from and/or to non-volatile memory 255 via sector driver 340. In addition, encryption engine 360 may encrypt data before file system 330 stores the data in memory 255. If the data is encrypted, file system 330 will also store a decryption key in memory 255. The decryption key may be identical to the encryption key in cases where symmetric encryption is used. If asymmetric encryption is used, the decryption key will be different from the encryption key. During a data read operation, encryption engine 360 will decrypt the data using the decryption key stored in memory 255.

[00029] As the file system 330 and sector driver 340 are located in card 240 instead of in computer 200, hackers cannot gain access to raw encrypted data stored in memory 255. Further, as decryption keys are stored in memory 255 and are never transmitted outside of card 240, the decryptions keys cannot be intercepted. When a biometric reader 265, which is integrated into card 240, is used in place of authentication GUI 300 for entering authentication data, the authentication data is never transmitted outside of card 240 and therefore cannot be intercepted. In an embodiment of the invention, biometric reader 265 and authentication GUI 300 may be used concurrently so as to accept to sets of authentication data.

[00030] In an embodiment of the invention, the authentication engine 320 enforces a minimum password length when authentication GUI 300 is used. For example, authentication engine 320 may require a minimum password length of six characters with at least one number, wherein two adjacent characters are not identical. This limitation provides a password space of at least 1.8 billion passwords, making it extremely time consuming to crack the password if an authentication delay is used between authentication attempts. An authentication delay of just one second would require about 59.9 years to search the entire password space, thereby making it extremely time consuming to crack a password using a brute force method.

[00031] Wherein the card 240 is mass duplicated with identical data and passwords, it may be necessary to increase the password space and/or increase the authentication delay since otherwise one could hack multiple devices in parallel by searching different fractions of the password space for each copy.

[00032] File system 330 of crypto-media card 240 is robust and does not get corrupted if power is shut down suddenly. File system 330 automatically returns file system metadata and data to the last consistent state when faced with a power interruption or decoupling from computer 200. Accordingly, the file system 330 is either log-structured or journaled so that unfinished write operations may be cleanly removed from the non-volatile memory 255. However, a variable that holds an authentication flag is in volatile memory and so when the crypto-media card 240 is shut down or otherwise looses power, the flag is cleared until power is reapplied and the user is authenticated again.

[00033] Storage card 240 may also include a user API (not shown) between the application 310 and file system 330. Example code for the API follows:

• [00034] FILE *fopen(const char *path, const char *mode);
• [00035] FILE *fdopen(int fildes, const char *mode);
• [00036] FILE *freopen(const char *path, const char *mode, FILE *stream);
• [00037] int fclose(FILE *stream);
• [00038] size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
• [00039] size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);
• [00040] int fflush(FILE *stream);
• [00041] int feof(FILE *stream);
• [00042] void rewind(FILE *stream);
• [00043] int fseek(FILE *stream, long offset, int whence);
• [00044] long ftell(FILE *stream);
• [00045] int fsetpos(FILE *stream, fpos_t *pos);
• [00046] int fgetpos(FILE *stream, fpos_t *pos);
• [00047] void clrerr(FILE *stream);
• [00048] int ferror(FILE *stream);
• [00049] int remove(const char *filename);
• [00050] int fstat(int filedes, struct stat *buf);

[00051] Access to the crypto-media card 240 is at the user level and is done through the standard C library functions as defined by the ANSI X3.159-1989 and IEEE Std1003.1-1988 standards. There are special extensions to support the crypto media card 240, which are documented below:

• [00052] 1.The fopen( ) function accepts two additional options as modes:
  • [00053] a. The “x” option which requires the user to authenticate before the file is opened. If a file is opened for writing with the “x” option, the following steps will be taken:
    • [00054] 1. Invoke a system function to create an authentication token from the user input
    • [00055] 2. Create the file
    • [00056] 3. Store the authentication token in the file attributes so it can be checked when reading
    • [00057] When the file is opened for reading with the “x” option, the following steps will be taken:
    • [00058] 1. Invoke a system function to read an authentication token from the user
    • [00059] 2. Compare the authentication token with the authentication token stored in the file attributes
    • [00060] 3. If the tokens match, then the file file open succeeds.
    • [00061] The authentication token created or compared by the system may be a simple password, based on a biometric signature (handwriting analysis, facial recognition, retinal scan, fingerprint/thumbprint analysis, etc), a time-based or some other identifier.
  • [00062] b. The “e” option which specifies the file should be encrypted as it is written or decrypted as it is read. When the “e” option is used when writing a file, the following steps will be taken:
    • [00063] 1. Generate an encryption key
    • [00064] 2. Invoke a system function to create an authentication token
    • [00065] 3. Create the file
    • [00066] 4. Store the encryption key in a secure database so it can be accessed with the authentication token
    • [00067] 5. Encrypt the file as it is written into the file

[00068] When the “e” option is used when reading a file, the following steps will be taken

• • • [00069] 1. Invoke a system function to read an authentication token
    • [00070] 2. Retrieve the encryption key for the file by using the authentication token
    • [00071] 3. Decrypt the file as it is read from the file

[00072] FIG. 4 is a flowchart illustrating a method 400 for storing data on the crypto-media card 240. First, a write request is received (410). A password is then requested (420). In an alternative embodiment of method 400, a password may be sent concurrently with the write request. In another embodiment of method 400, biometric data may be used in place of or in addition to a password. The password is then received (430) and validated (430). The received password may be encrypted and therefore needs to be decrypted before validation (430). If the password is not valid, the method 400 ends and can be restarted after a time delay of, for example, one second. If the password is valid, then the data from the write request is encrypted (450) and written (460) with a decryption key to memory.

[00073] In an embodiment of the invention, encryption can be done in software on the CPU if encryption speed is not an issue since encryption algorithms generally run slowly in software. If a user stores large files, such as media files (e.g., movies, songs, etc.) then fast decryption is necessary to ensure a continuous stream of data. Accordingly, for large files it may be preferable to user hardware decryption. In another embodiment of the invention, symmetric encryption is used and therefore the decryption key is identical to the encryption key. In another embodiment, asymmetric encryption is used and therefore the decryption key is different from the encryption key. Generally, asymmetric encryption is more secure than symmetric encryption, but asymmetric encryption is slower.

[00074] In another embodiment of the invention, data need not be encrypted. Accordingly, encrypting (450) and writing (460) may not be needed and instead non-encrypted data may be written to memory. In another embodiment of the invention, repeated writes using method 400 only requires single entry of a password. In this case, requesting (420) and receiving (430) need not be repeated after the first successful write.

[00075] FIG. 5 is a flowchart illustrating a method 500 for reading data on the crypto-media card 240. First, a read request is received (510). A password is then requested (520). In an alternative embodiment of method 500, a password may be sent concurrently with the read request. In another embodiment of method 500, biometric data may be used in place of or in addition to a password. The password is then received (530) and validated (530). The received password may be encrypted and therefore will need to be decrypted before validation (530). If the password is not valid, the method 500 ends and can be restarted after a time delay of, for example, one second. If the password is valid, a decryption key is retrieved (550) and the requested data is decrypted (560). The decrypted data can then be sent to computer 200 to be displayed. The method 500 then ends.

[00076] In an alternative embodiment of the invention, the data may not be encrypted and accordingly retrieving (550) and decrypting (560) are not performed. In another embodiment of the invention, repeated reads may only require entry of a password once. Accordingly, after a successful read, requesting (520) and receiving (530) need not be repeated.

[00077] The foregoing description of the illustrated embodiments of the present invention is by way of example only, and other variations and modifications of the above-described embodiments and methods are possible in light of the foregoing teaching. Further, components of this invention may be implemented using a programmed general purpose digital computer, using application specific integrated circuits, or using a network of interconnected conventional components and circuits. Connections may be wired, wireless, modem, etc. The embodiments described herein are not intended to be exhaustive or limiting. The present invention is limited only by the following claims.