WO2005106672A2

WO2005106672A2 - Hierarchical storage management of encrypted data files

Info

Publication number: WO2005106672A2
Application number: PCT/US2005/013626
Authority: WO
Inventors: Finis Conner; Anil Nigam
Original assignee: Storcard, Inc.
Priority date: 2004-04-21
Filing date: 2005-04-20
Publication date: 2005-11-10
Also published as: WO2005106672A3

Abstract

A secure transportable device is provided for management of encrypted files. A memory card for enabling management of digital rights is in a format no larger than a credit card and includes a magnetic disk having a first volume which is a secure volume within which an encryption key is stored. The second volume is a non-secure volume within which encrypted information is stored. The card is suitable for being coupled to a content server via a reader to enable content from the server to be encrypted and stored in the second volume.

Description

Hierarchical Storage Management of Encrypted Data Files

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority from United States Provisional Patent Application

Serial Number 60/564,619 filed April 21, 2004, and entitled "Hierarchical Storage Management of Encrypted Data Files."

BACKGROUND OF THE INVENTION

[0002] Documents, music, movies and video games are all becoming available in digital formats. One driver for change is the enhanced presentation opportunities available for documents and the variety rich, audio-visual entertainment experience made possible by personal computers working as standalone players, or in concert with television and music systems. Digital file security, however, is an area that needs solutions. Making a file unreadable by a third party can be solved by mathematical encryption algorithms. The encrypted file (cipher text), however, must be separated from the key used to perform the encryption to maintain security. Presently there are no satisfactory solutions to provide data transportability with copyright and data file confidentiality criterion enforcement.

[0003] An alternate approach is to secure the content and documents in a remote and secure file server and only allow authenticated access to the requested information. The problem with such a solution is delivery over the "last-mile" to the residence. Furthermore, traditional displays and players must have the document or content in text form for viewing and playback. The question then becomes why encrypt when the final device, which cannot be secured, requires unencrypted information, referred to as "in the clear," This aspect is further complicated by the fact that digital information can be copied and modified with ease using commercially available software tools, and that the copy can be as good as the original. This exasperates the policy management problem causing content owners to provide restricted access to popular content or to resort to litigation to enforce copyrights.

[0004] New computer operating systems (OS) are being developed such as the Trusted

Computing Platform backed by the Trusting Computing Platform Alliance (TCP A), Microsoft's Palladium, and Next Generation Secure Computing Base (NGSCB) to address these problems. The hardware architecture to support these OSs stores cipher keys in secure digital logic mounted on the computer system's mother-board or as a pre-assigned value in the microprocessor, with the cipher text is stored in the hard drive. This results in the content becoming "tied" to a specific piece of hardware, and the user required to make periodic decisions as to which file must be deleted to make room for new data. One example of this is the Digital Video Recorder (DVR), with products such as the TINO box, which are configured with hard drives now having storage capacities of over 400GB in current configurations. This large storage volume requires a sophisticated user to implement a file management scheme if the stored materials are to protect copyright or confidentiality of the resident information. [0005] Users often collect "content" and save it for later viewing, or archive it in their collection. Current archival solutions such as CDs, tapes and ZIP disks require cipher data to be converted back to text or unencrypted form for storage. The reason for this is that cipher text and the cipher key must be stored separated from each other. Present OSs do not maintain a trace between an archived encrypted file and the originating system's mother-board. Furthermore, if a user upgrades their computer, or if it requires replacement, the entire collection of encrypted files could become unreadable as there is no secure way of moving cipher keys between system motherboards.

[0006] Digital Rights Management and the fact information must be in a form that can be displayed/played on existing viewers and entertainment systems along with the management of the rights of the author or artist creates another set of challenges. One solution is to require all digital content to be played on new players with a decryption engine in close proximity to the viewer or player unit. The cost of implementing such a system, however, would be monumental and an alternate solution is required.

BRIEF SUMMARY OF THE INVENTION [0007] This invention provides a secure, convenient and transportable device that provides seamless management of encrypted files, while preserving functionality similar to current removable media products. Preferably a memory card for enabling management of digital rights is provided in a format no larger than a credit card. It includes a magnetic disk for storing information which includes at least a first volume which is a secure volume not accessible to the user of the memory card and which stores an encryption key. The second volume is a non-secure volume within which information may be stored, which is typically encrypted and accessible by using the encryption key. The card is particularly suitable for being coupled to a content server via a reader to enable content from the server to be encrypted and stored in the second volume.

[0008] In an alternate embodiment a memory card for enabling management of digital rights includes an enclosure no larger than a credit card, a magnetic disk for storing information contained within the enclosure, and a microprocessor affixed to the memory card for processing encrypted information in response to encryption keys stored therein. The invention also provides a method of providing secure downloadable files. In such a method a memory card having a rotatable magnetic memory therein is provided. Using a communications medium the card is connected to a content supplier to determine if the card can be personalized. If so, the card is personalized to restrict its use. Then security information is stored on the card, and the requested content is also stored on the card.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 illustrates a secure file server and a method of delivering fully encrypted content with a digital signature of the originating server;

[0010] Figure 2 illustrates a preferred embodiment of a card, with two storage volumes and an identification number that personalizes these two volumes;

[0011] Figure 3 illustrates details of the portable card;

[0012] Figure 4 illustrates components inside a card reader;

[0013] Figure 5 illustrates a preferred embodiment of the architecture of the reader;

[0014] ^• Figure 6 illustrates file hierarchy and file migration during archiving; and

[0015] Figure 7 illustrates file archiving using file segments.

[0016] Figure 8 is a flow chart of the events while serving a request for a file download;

[0017] Figure 9 is a flow chart of the sequence of events where the user is provided an option of storing a file in the secondary storage; and

[0018] Figure 10 is a flow chart of the sequence of events during a file playback request. [0019] Figure 11 shows the download and personalization sequence using blank cards.

DETAILED DESCRIPTION OF THE INVENTION

[0020] Figure 1 shows a typical secure file server environment. Server 1 has a firewall 3

. that encloses the storage volume 2. Files in the storage volume are either encrypted or maintained in text form. The security of individual files on server 1 is not further discussed here because the entire environment is kept behind firewall 3. One specific implementation is presented where a file 5 having content Dj with an entry in the file directory 60 is contained in storage volume 2. A directory of authorized members having access privileges to server 1 is maintained in a second directory 4. For example, member "k" has a preassigned authentication key set _k, a symmetric cipher key set k and a file listing information L_kathat member "k" has previously downloaded from server 1 with digital signature Sj.

[0021] Information that leaves the firewall 3 of server 1 can be separated into that which is secure and encrypted, and that which is of primarily promotional or commercial value and transmitted in text form. This typically includes the file title, an advertising clip, a song or a movie preview. Encrypted data is created by an algorithm described as function "f," for which an AES algorithm with k_k as the cipher key, or some other algorithm, may be used. The encryption in this embodiment is personalized to the member requesting it. Thus, member "k" will be the only one that can convert the file to readable/playable form, and content security is guaranteed even if an open distribution channel is utilized. Also this scheme can protect against rouge users who may sign in to server 1 using some other member "k's" ID and password. The information transmitted would require an additional device such as card 1, shown in Figure 2, to convert the file to readable form. Commercial portion of the content such as file titles, advertising clips, song or movie previews can be transmitted in the clear or processed using a hash function and digitally signed by the issuing server using function "S" and its ID as S;. The advantage of having digitally signed text data is that it can protect the issuer from third party tampering should that.be required. The authentication scheme utilized could consist of comparing the User ID and a preassigned password, or it can be a more secure system, such as a challenge response sequence using the Pk keys. [0022] Figure 2 illustrates the user environment where card 1, which in a preferred embodiment has the form factor of a credit card, and typically a Smart Card, is used to receive file 6. Card 7 is constructed with two storage volumes, and includes a secure volume 8 with a firewall 10 enforced by an operating system, such as Javacard or other multifunction Smart Card OS. A microcontroller with a secure architecture is implemented in block 8. Alternatively, a simple challenge response hardware algorithm as a "state machine" could be implemented in digital logic in microcontroller 8 such as Atmel's Crypto-memory Smart Card IC. [0023] In one embodiment microcontroller 8 includes a secure 8051 -like microcontroller implementation with a Javacard OS and remote personalization capabilities. Controller 8 can be programmed to securely receive and store cipher keys pi, k;, with the digital signature of the server that issued this information, the number printed on the front face of card 7, the member name, address and any other information appropriate to the specific implementation. This forms the personalization sequence for card 7 to communicate with server 1. The cipher keys can be random numbers generated by card 7 or server 1 and exchanged securely during the personalization sequence. These values exist behind security walls 3 for server 1 and 10 for IC 8, and cannot be viewed by the user or a third party. Additionally, integrated circuit (IC) 8 incorporates an authentication procedure for server 1 utilizing function "g" and the key i. This protocol can be defined or downloaded into controller 8 during a card personalization sequence or it may be incorporated in the card OS. The symmetric encryption keys kj's consist of a list, each related to a content or file downloaded utilizing card 7. A detail list of the file titles can be kept in the IC or on volume 9 as shown in the figure. Generally, however, EEPROM storage capacity available in the IC is expensive; for a typical Smart Card priced at less than $10, this is ^• about 64 Kbytes. [0024] Content 6 and the respective directory 12 are stored in another volume on card 7.

In one embodiment this is a magnetic disk 9 with a storage capacity preferably greater than 100MB. Content 6 as received from Server 1 is stored as an encrypted file 13 with a directory entry made in 12. The cipher key for this content is available in IC 8. Consequently, if the disk in accessed independently of the IC, the contents of file 13 would consist of unusable cipher data. If the available storage on disk 9 is not larger than required for content 6, a tag file entry 14 is created and associated with directory 12 and file 13. Tag 14 contains information about where the remainder of file 13 is stored. [0025] Figure 3 illustrates details of one embodiment of card 7. In this embodiment the card includes a Smart Card IC 8, a cover layer 15, another layer 16 which consists of a fabric liner material similar to that used in the common floppy disk. Magnetic disk 9 is protected by liner layers 16 and 17 such that during storage and handling the surfaces of disk 9 do not contact layers 15, 18 or 19. Such contact could result in the surfaces of disk 9 becoming scratched. Layer 19 is the bottom of card 7. In one embodiment this layer is made from metal, more specifically stainless steel. An opening 56 in provided in this layer. When card 7 is not in a card reader such as 20, a shutter layer 18 covers opening 56. This construction is utilized to keep contaminants from entering the disk cavity formed between layers 16 and 19. To read or write information to the card it must be inserted into a reader 20 (depicted in Figure 4). A mechanism in reader 20 actuates shutter 18, moving it such that opening 56 aligns with opening 57 thereby providing access to the magnetic recording surfaces on disk 9.

[0026] Reader 20 is shown in detail in Figure 4. This mechanism performs reading of the disk. Card 7 is inserted in a slot 23 in receiver 21. Receiver 21 has pins 59 that ride in slots 58. The figure shows the reader with receiver 21 in an exploded form for greater clarity. This mechanism operates such that, as card 7 is inserted into reader 21 the insertion force pushes receiver 12 rearward, moving it in the cam profile machined as slots 58, to a point where the slot profile causes card 7 to have vertical movement. The arrangement of the cam profile is designed to provide movement only when disk 9 gets positioned over the top of spindle motor 24 and aligned with its rotational axis. A magnetic clutch (not shown) attached to disk 9 allows spindle 24 to rotate disk 9. Card 7 has a thickness of about .030 inches, similar to the thickness of the common credit card. The thickness of layers 15, 16, 17, 18 and 19 are selected to provide a vertical dimension of about 0.015 inches in which disk 9, which is about 0.0015 inch thick, can rotate uriimpeded. A connector 22 mounted to receiver 21 interfaces with IC 8 on card 7, and head 25 interfaces with disk 9. Head 25 is pivoted at 26 such that it can be positioned at the various data tracks formed on disk 9. Reader 20 has a PCB 28 which contains the electronics to spin motor 24, position head 25, encode/decode magnetic transitions on disk 9 and transfer this information to the outside world using industry standard protocols via connector 27. In one embodiment connector 27 and the communication protocol implemented in reader 20 conforms to USB 2.0. [0027] Figure 5 is a block diagram of reader 20. In the playback mode, content 13 is located on disk 9. The cipher keys and authentication protocol are located in IC 8. A microcontroller 29, which in one embodiment is an ARM7-TDMI, 32 bit RISC processor, manages the flow of information between disk volume 9 and the external world. Processor 29 has a secure communication channel with IC 8. Upon insertion of card 7 into reader 20 a mutual authentication protocol is executed to establish the validity of card 7 and reader 20. This protocol is described in co-pending commonly assigned U. S. Patent Application entitled "Secure and Portable Data Communicator and Viewer," Application Serial Number 60/564567 filed April 21, 2004, and a corresponding non-provisional application filed contemporaneously herewith. Upon completion of this protocol, processor 29 has a valid volume mounted and it can identify itself as a storage unit on the system bus via interface logic 32. Microcode that operates processor 29 is located in ROM 30 or can be downloaded from disk 9 into RAM 31 depending upon the protocol established between processor 29 and IC 8 during mutual authentication, and the hierarchy of execution of the respective code.

[0028] Upon a request for information from the host system, processor 29 will identify file 13 reading directory 12 and command the storage hardware 60 to spin disk 9 and position head 25 to retrieve this file. In addition processor 29 will query IC 8 to obtain the cipher key or keys to decrypt the requested file. The cipher key or key sequence will be loaded into encryption engine 33. An additional feature is implemented in one embodiment where the reader conditions the decrypted text using function "g" implemented in the encryption engine. Function "g" encodes a watermark in the content creating special text 34 as D*. This text is personalized to the user using information available in IC 8. The purpose is to include enough information to identify the originator with a link useable by a policing authority if necessary. This watermark is transparent to the player. This feature could discourage illegal copies and copyright infringement activities. The procedure to encode watermarks in this manner is described in the above referenced U. S. Patent Application.

[0029] In the event content 6 requires storage larger than what is available on the disk 9, a tag file is created and linked to file 13 with a directory entry in directory 12. The cipher keys remain in IC 8. The remaining portion of file 6 is stored in secondary storage volume 35 as shown in Figure 6, such as file 39, and a tag header 40 consisting of the last three digits, or the entire number 11, file title, user name, and a hash of this data with the digital signature of the issuing server Si. Alternatively, the entire file can be stored on volume 35 such as file 39A, and only a directory entry with destination information 14 kept in file 9. Furthermore, this file could be moved to other storage volumes such as volumes 36 or 37, as necessary. It should be noted that content 39 is married with tag file 40, and to an external system it appears as one file. Because it is encrypted, the file is of little value to third parties. The only way to play or view the content is to install the specific card 7 containing the specific tag file 14 in a reader 20 with access to volumes 35, 36 or 37. In these embodiments it should be noted that card 7 is a portable unit and can be moved from one computer system to another. Volumes 35, 36 and 37 could be public volumes.

[0030] In situations where content 50 is much larger than the storage available in disk 9 and disk 41 as shown in Figure 7, it can be segmented into volumes 51, 52, 53, 54 and 55. Each of these segments can be tagged with a header such as 45, 47 and 49 with a destination header 14 maintained in card 7, and a similar tag file in the previous volume with the next volume's destination information. The contents of these tags consist of the card ID, the file title with a hash of this information and the digital signature of the issuing server and the segment number such as "n." When a request is made for this file, microcontroller 29 interrogates directory 12 and tag file 14, then requests the user to mount the respective volume in the sequence specified in the tag files of each volume. Alternatively, the user may elect to have the files downloaded into a local scratch volume for temporary storage. It should be recognized that security is preserved since each segment 44, 46 or 48 requires the cipher key stored in IC 8. Again portability of the cipher key is a major benefit of this embodiment.

[0031] Figure 8 is a flow chart of the events that would occur while serving a request for a file download 61 from a secure Server 1. Server 1 initiates an authentication protocol 62 to establish the validity of the requesting user and the presence of a valid card 7. A number of authentication techniques can be utilized to accomplish this, and these are described in the application referred to above. Once authenticity of both the user and the card is established, processor 29 in the reader creates a directory entry in directory 12 on storage volume 9. Additionally, a tag file 14 is also created to support this directory entry. Server 1 identifies the user through directory 4 and procures cipher key ki. Content Dj, encrypted using function "f," is sent to reader 20 using a commercial communication channel, for example, over the I-nternet using the TCP/IP protocol. At the reader, TCP/IP is implemented in the host system and the assembled packets can be sent to reader 20, for example, by the USB protocol. Reader 20 reviews the storage requirements of the respective file 65. If there is space available in volume 9 each record will be stored 66 on the disk as file 13 until the entire file download is completed. If the storage space in volume 9 is exceeded, then either the entire file, or a portion thereof can be stored elsewhere. For example, the data can be stored in a secondary storage volume accessed on the host, for example, via a USB bus, or the user can be requested to insert another card 7 in reader 20.

[0032] Using the path 65, if a store volume 35 is not available then the user is informed and requested to supply the destination volume or the communication with server 1 is terminated. Assuming there is available storage in the secondary volume 35 a tag file is created 69 in this volume with a directory entry similar to 40 and data downloading continues using 70 and 71 until the file transfer is complete. If volume 35 runs out of storage capacity the user is flagged 75 to either move files to volumes 36 and 37 or 74 to delete files in volume 35. In one embodiment where reader 20 and volume 35 are both local and attached to microcontroller 29, the user can be queried 74 to identify files that can be deleted from either volume 9 or volume 35 to make space for the new file. Alternatively, in one embodiment this process is automated with the oldest files being removed from volume 35.

[0033] In the situation 75 where the file is segment similar to Figure 7 and portions recorded in volumes 42 and 43, and in the special case where card 7 is not present in the communication, then a special tag file entry is created in volume 41 with the address of card 7. A flag is set in this file to ensure that the tag file 14 and director 12 of the card will be updated the next time it is inserted in reader 20. This situation is for the environment where reader 20 and a storage volume such as 35 or 41 are present and connected to microcontroller 29. [0034] Figure 8 illustrates another operating environment for such a device where volume 9 in card 7 is utilized to store directory and tag file entries only, and is utilized in the situation where the secondary storage volume is full and does not have room to create the special tag file discussed above 78, and the user is prompted to insert this special card 7 and the respect tag file data is recorded. It should be recognized that this specific card can only keep the tag file information and does not have access to the cipher key stored in the original card. [0035] Figure 11 illustrates the sequence of events where the user is provided an option files contained in these volumes. The archived files can be moved to volumes 36 and 37 with a special tag file 100 created in volumes 35 or 41 with the new destination of these files. Because card 7 inserted in reader 20 is not the originator of these files, this tag file is appended to the original tag file containing the information of the originating card 7. Whenever this card is inserted into reader 20 it will request the installation of volume 36 and the special tag file will provide information to microcontroller 29 to update the tag file entry in the specific card 7 to show the new destination information of the respective file and the special tag file along with the original tag file in volumes 35 and 41 can be deleted.

[0036] Figure 9 shows a method of creating a utility card, and Figure 10 is a flow chart of the sequence of events during a file playback request 79. User authentication 80 is the first event followed by a query regarding the files availability 81. If the file is not available in volume 9, or there is no tag file showing a destination address, the user is request to initiate a file download sequence 82. If the file requested in not in the specific card 7, but a tag file entry is available in the secondary volume such as 36 or 41, the user is instructed to insert the appropriate card 83. If the file is archived as segments, then the user is also instructed to mount the respective volumes 42 and 43. If the tag files on card 7 do not match the tag file on the secondary storage, a search in initiated of the special tag file entry 85 and 87 the appropriate updates made to the tag files in card 7. Once the housekeep activities of the tag files are complete, the file is assembled and transmitted to the host 87. As discussed earlier, this content can processed by the encryption engine 33 under the control of the microcode in RAM 32 or ROM 31 to have suitable watermarking information to establish barriers discouraging illegal file sharing. [0037] Preferred embodiments of the invention have been described in detail. It will be appreciated that changes and modifications of the implementations described may be made without departing from the scope of the invention as defined by the appended claims.

Claims

What is claimed is:

1. A memory card for enabling management of digital rights comprising: an enclosure no larger than a credit card; a magnetic disk for storing information contained within the enclosure, the magnetic disk including at least a first volume and a second volume for storing information, wherein the first volume is a secure volume not accessible to the user of the memory card which first volume includes a stored encryption key; and the second volume is a non-secure volume within which information may be stored.

2. A memory card as in claim 1 wherein the secure volume further includes authentication and personalization information.

3. A memory card as in claim 2 adapted to coupled to a content server via a reader whereby content from the server may be encrypted and stored in the second volume.

4. A memory card as in claim 3 wherein the content from the server is larger than the second volume, and a tag file entry is created and stored in the second volume to refer to another location storing the content.

5. A memory card for enabling management of digital rights comprising: an enclosure no larger than a credit card; a magnetic disk for storing information contained within the enclosure; and a microprocessor affixed to the memory card for processing encrypted information in response to encryption keys stored therein.

6. A method of providing secure downloadable files comprising: providing a memory card having a rotatable magnetic memory therein; using a communications medium to determine if the card can be personalized, and if so, personalizing the card to restrict its use; storing security information on the card; and storing a file on the card.