WO2005107287A1

WO2005107287A1 - Secure portable data communicator and viewer

Info

Publication number: WO2005107287A1
Application number: PCT/US2005/013638
Authority: WO
Inventors: Finis Conner; Anil Nigam; An Van Le; Paul Guthrie
Original assignee: Storcard, Inc.
Priority date: 2004-04-21
Filing date: 2005-04-20
Publication date: 2005-11-10

Abstract

A system includes a memory card (7) which has a rotating magnetic memory (22) for storing information and a microprocessor (35). The memory card (7) is adapted to be coupled to a reader (12) for storing and retrieving information therefrom, and the memory card (7) includes a first public encryption key. The memory card (7) may be coupled to a secure content server (1) which is also coupled to a reader (12) for the memory card (7). The reader (12), the server (1), and the memory card (7) each store private and public encryption keys, including the first public encryption key. In this manner the memory card (7) and the server (1) can authenticate each other.

Description

Secure Portable Data Communicator and Viewer

CROSS-REFERENCE TO RELATED APPLICATION

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

Application Serial Number 60/564,567 filed April 21, 2004, and entitled "Secure and Portable Data Communicator and Viewer."

BACKGROUND OF THE INVENTION

[0002] Today's communication equipment and the Internet have made work environments and entertainment mobile and un-tethered. Project groups can be created outside the walls of a corporation, and entertainment such as music, movies and games can be played and enjoyed "on the go," whether during a commuter train ride, while traveling in an automobile, or enjoying a meal at a restaurant. Security of data, however, is a growing area of concern. [0003] Currently, document security is usually controlled by a software fire-wall that manages the flow of data between a file server and the user. The user can connect to the server via a wired or wireless node. A security policy consisting of comparing a pre-assigned ID and password with those input by the user is required for authentication. Once access is attained, however, there are no controls that restrict the transfer of files and data from the server to the user, or manage its use, modification or reproduction thereafter. One example is a mobile worker connecting to a corporate network with a notebook computer. Upon signing onto the server, the worker can download files and store these on the hard drive in his or her notebook. If this computer is lost or misplaced, the security of the information is compromised. [0004] In another example, a user transfers music purchased via an Internet website or a

CD to the hard drive of a desktop or notebook computer using commercially available software and hardware. This file can then be shared with others. Because digital data may be copied without loss of resolution, the copy is as good as the original. In this example the copyright for the music is compromised.

[0005] There are products in the marketplace that overcome some these problems by encrypting documents and content prior to delivery to the user. For example, Windows XP has tools that can encrypt individual files stored in the hard drive. Alternately, an encrypted partition can be created in the hard drive using software sold by PGP Corporation, Palo Alto, California. This software eliminates the need to remember ciphers keys for each individual file. The use of these software packages, however, locks the data to a specific PC. Transportation of this information requires that the entire hardware be moved, which can be inconvenient, or the file must be decrypted and converted to text form for storage in a removable medium such as a CD or flash memory card, also a security risk.

[0006] Encrypted solutions for music and video content such as the DVD format and

Secure Digital card allow data to be converted to cipher text and then back to text for playback. One algorithm licensed by 4C Entity LLC, Morgan Hill, California utilizes a matrix of keys. This matrix is distributed to device manufacturers and content is encrypted utilizing a key from the matrix prior to distribution to the consumer. This approach, however, depends upon the entire manufacturer's group making an effort to secure the cipher keys. Any leakage or security lapse, as in the case of the DND format, compromises the entire system without possibility of recovery.

[0007] Alternate solutions which provide portability of encrypted files, such as the personal server architecture presented by Intel consist of a portable hard drive and an operating system (OS). The unit can be implemented in a form no bigger than a deck of cards, thus making it portable. The OS provides the security firewall and policy management. The use of a small hard drive, however, makes the unit fragile. Inadvertent rough handling can damage the disk drive rendering the data unrecoverable. Other solutions based upon a peripheral interface such as the secure Thumbdrive™ sold by Trek 2000 International, Singapore, the secure Picodisk sold by Eutron S.p.a., Italy, and DiskOnKey manufactured by M-Systems, Newark, California, and Micro Vault by Sony Corporation, Japan, provide security for personal information, but not for information that belongs to others. For example a mobile worker could carry data and files that relate to his or her work, which may include proprietary information belonging to their employer. This information, if stored on any one of these devices can be encrypted and under the control of the user and the content owner, or a policing authority will be precluded from any audit capabilities.

[0008] As described above there is a need that remains unsatisfied in today's products.

This invention describes a portable unit to satisfy this need. BRIEF SUMMARY OF THE INVENTION

[0009] Herein we describe a portable device that can be used to securely transport digital data and has the following features. Information can be encrypted and stored in an economical and conveniently transportable device with the cipher keys stored in a separate volume contained within the same portable unit. Files in the storage medium can be viewed and edited in third party owned computers without compromising security. Users can securely download third party owned content and store it in a convenient, economical and transportable medium, while providing the third party controls to manage the associated copyrights and revocation polices, and cipher keys can be recovered if forgotten.

[0010] A system according to a preferred embodiment includes a memory card which has a rotating magnetic memory for storing information and a microprocessor. The memory card is adapted to be coupled to a reader for storing and retrieving information therefrom, and the memory card includes a first public encryption key. The memory card is coupled to a secure content server which is also coupled to a reader for the memory card. The reader, the server, and he memory card each stores private and public encryption keys, including the first public encryption key. In this manner both the memory card and the server can authenticate each other.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a perspective view of the hardware components of a preferred embodiments, wherein;

[0012] Figures 2 is top view of the preferred embodiment;

[0013] Figures 3 is a front view of the preferred embodiment; and

[0014] Figures 4 is a side view of the preferred embodiment;

[0015] Figure 5 is a top view of the internal details of the reader mechanism for reading and writing information onto the disk contained in the card used in the preferred embodiment;

[0016] Figure 6 illustrates internal details, in a side view, of a section taken through the reader mechanism shown in Figure 5;

[0017] Figure 7 is a front view of the card utilized in the preferred embodiment; [0018] Figure 8 is a side view of the card, showing its thickness relative to other dimensions of the card;

[0019] Figure 9 is a view of the back of the card and illustrates details of how the disk contained in the card can be accessed by the reader mechanism;

[0020] Figure 10 is an exploded view of the card and some internal components;

[0021] Figure 11 illustrates the electronic architecture of the preferred embodiment;

[0022] Figure 12 illustrates another electronic architecture of the preferred embodiment;

[0023] Figure 13 depicts the layout of the disk storage volume in the card;

[0024] Figure 14 depicts the file structure of the disk storage volume contained in the card;

[0025] Figure 15 illustrates another arrangement of the hardware of the preferred embodiment;

[0026] Figure 16 depicts another configuration of the hardware of the preferred embodiment;

[0027] Figure 17 shows storage options that can be used with the removable option illustrated in Figure 16;

[0028] Figure 18 depicts a three-tier logical security model involving the reader, the card, and the host computer;

[0029] Figure 19 depicts the steps in the mutual authentication process between the card and the reader;

[0030] Figure 20 depicts the steps in verifying the reader's public key certificate by the card;

[0031] Figure 21 illustrates a Certificate Management Policy (CMP) to specify how the fields in a certificate might be checked;

[0032] Figure 22 illustrates the boot process;

[0033] Figure 23 depicts a password recovery process in an enterprise environment;

[0034] Figure 24 illustrates a password initialization process in an environment where the user of the card is self-supported;

[0035] Figure 25 illustrates the password recovery process;

[0036] Figure 26 illustrates the system operating in automatic decryption mode;

[0037] Figure 27 illustrates the system operating in automatic encryption mode; [0038] Figure 28 illustrates another embodiment with a display screen and controls to review content locally; and

[0039] Figure 29 illustrates an orientation of the display screen to achieve a slimmer form factor.

DETAILED DESCRIPTION OF THE INVENTION

[0040] Figure 1 is a perspective view of the portable, Secure Content Server (SCS) 1 of this invention. The device has a casing with a slot 3 through which a card 7 can be inserted into server 1 and ejected by depressing button 5. A clear plastic window 6 is provided on the top of the SCS 1 to show a user if a card is installed in the device. An activity LED 9 is provided to indicate when the unit is busy communicating with external equipment or to indicate fault conditions. An antenna 4 is attached to the side of the SCS to allow wireless communication with Bluetooth, Wi-fi (802.1 la, b or g), satellite or cellular service. Additional antennae, similar to 4, can also be provided on SCS 1 to allow simultaneous communication in multiple frequency bands. SCS 1 includes a PC board containing electronics such as that illustrated in Figure 11, and described later below. A keypad, camera, microphone or biometric fingerprint sensor (not shown) can also be mounted to the SCS and located, in one embodiment, on the top surface 24. The keypad can be used for personal identification number (pin) entry, while a camera, microphone or biometric sensor can be used to compare the user's fingerprint or other biometric data, for example, facial or voice recognition, with a template stored in the SCS 1 or in card 7 as an authentication criterion. The SCS unit preferably is about 100mm long, 65mm wide and 15mm tall. Other configurations with other dimensions can also be realized. [0041] Card 7 preferably has a form factor of a credit card, namely, 85.6mm long,

53.98mm wide and 0.76mm thick. These dimensions are for a Smart Card per ISO 7816-1. A semiconductor device 8 is attached to the front face of card 7. The functions of this device are described later below. A rotatable disk, similar to a floppy disk with a diameter of about 45mm is contained between the top and bottom surfaces of card 7. Figures 2, 3 and 4 show the orthographic views of SCS 1. In Figures 2 and 3, antenna 4 is illustrated as attached to a block 10 to allow the antenna to be rotated and stored within the thickness of SCS 1 for ease of transportation. Rubber pads 11, shown in Figures 3 and 4, are attached to the bottom of SCSI to provide friction between it and the table to restrict the device from sliding when card 7 is inserted in to it. A rechargeable battery pack, such as Sony model UP325385A (not shown) is contained in the housing of the SCS 1 to power the electronics for a wireless session. A wired connection such as USB can be used to charge this battery and communicate with a host PC, or an external power supply may be connected to power the device.

[0042] Card 7 when inserted into SCS 1 is received by a mechanism referred to herein as reader 12. The internal details of reader 12 are shown in plan view in Figure 5. Reader 12 has a spindle motor 15 mounted onto the chassis 18. The disk in card 7 is engaged by a magnetic clutch 102 and centered on to spindle shaft 103. In the preferred embodiment the spindle motor rotates this disk in card 7 to an approximate speed of 3600 rpm. A rotor mechanism 16 has a recording head mounted to it and moves over the disk surface by a coil attached to the opposite end. This coil is suspended in a magnetic field developed between two magnets poles. When a current is passed through the coil, torque is generated which moves the head rapidly over the disk surface. This mechanism typically achieves an access time of about 15milliseconds. A PCB 13 is mounted to chassis 18 of reader 12 together with integrated circuits (IC) 14. These ICs are utilized to control spindle 15, control the position of rotor 16, and to control reading and writing information to and from the disk. Figure 6 is a side view of reader 12 showing the top cover 19, chassis 18, PCB 13, spindle motor 15, and rotor 16. A slot 20 is created in reader 12 though which card 7 can be received and seated onto spindle motor 15. Slot 20 is aligned with slot 3 in the SCS casing. The head attached to rotor 16 is held on a cam 104 when card 7 is not present in reader 12. This allows the recording head to be supported during transportation of SCS I.

[0043] Figure 7 is a front view of card 7 with the 45mm disk 22 shown in dashed lines.

Disk 22 is contained in a cavity formed between the top surface 33 and bottom surface 34 of card 7. This cavity is preferably lined with fabric liners to protect disk 22 from rubbing against the interior surfaces of the card. A slider 23 is attached to the underside of the top cover 33 of card 7. Slider 23 opposes the recording head attached to rotor 16 in reader 12, and is spring loaded with a force of about 4 grams in the direction toward slider 23. The slider and the head maintain a non-contact condition with the disk when it is spinning at about 3600 rpm. [0044] Figure 8 is a side view of card 7. The thickness of this card in one embodiment is

0.76 mm. hi other implementations, cards with thickness from 0.13mm to 6.35mm are used. The card in this embodiment is made from thin plastic and metal sheets to have about the same flexibility as a common credit card, and to allow it to be carried in a wallet of the user in a similar manner to ordinary credit cards.

[0045] Figure 9 shows the back face of card 7 and certain internal details. Disk 22 is contained in cavity 25, which is about 0.38mm in diameter. The disk is 0.063mm thick. A shutter 26 operates in a cavity created between the layers of card 7 and is actuated by a pin (not shown) in reader 12. This pin engages hole 29 in shutter 26, which is reinforced by a metal plate 31. As card 7 is pushed into reader 12, the pin holds the shutter, while the card body is moved into the unit. In this manner opening 28 in shutter 26 is aligned with opening 27 in the bottom plate of card 7. With this alignment, a portion of disk 22 is exposed and can be accessed by the recording head attached to rotor 16. When the card is not in the reader 12, the- shutter covers opening 27. A hub 31 A, preferably low carbon steel, attaches to disk 22 and engages with clutch 102, is attached to spindle 15. Hub 31 A has a hole concentric with the outer diameter of disk 22 and this is positioned onto spindle shaft 103. A magnetic strip 21 is attached to the rear surface of card 7 to maintain compatibility with swipe card readers.

[0046] Figure 10 illustrates internal details of card 7. Top cover 33, preferably PVC, allows the card to be personalized with printing methods similar to common credit cards. Fabric liners 32 protect the surfaces of disk 22 and capture contaminants that may enter disk cavity 25. A spacer layer, not shown in this figure, has a cut out 25 in it and forms the disk cavity with layers 33 and 34. Shutter 26 moves in a slot formed in this spacer layer. In Figure 10, a card with a flexible magnetic disk 22 provides the large storage volume. Other cards where this storage volume is provided by an optical disk such as a CD-R or DVD-R/RW or semiconductor devices such as flash memory, can also be used, for example, as described in commonly assigned, copending United States patent application entitled "Secure Transaction Card with a Large Storage Volume," serial number 10/716,267, filed on November 17, 2003. [0047] Figure 11 is a diagram of the hardware components in SCS 1 and card 7.

Integrated circuit 8, in one embodiment is an IC used in Smart Cards, such as Philips P8WE5003 or equivalent. This device has a secure microprocessor with RAM 37 and ROM 38 connected via bus 43. Digital logic block 39 includes a hardware accelerator to perform crypto functions such as RSA and/or ECC PKI verification and DES, 3DES or AES symmetric encryption. A FIPS-140 compliant random number generator 36 and ISO7816 T=0 or T=l input/output protocol support is provided by 42. A small amount of secure non- volatile EEPROM memory 41 about 8Kbytes is used to store encryption keys, programs and user personalization data. The electronics to control the position of rotor 16, the speed of spindle 15 and read and write operations on the disk is provided by block 48. This circuitry includes ICs 14 mounted on PCB 13 and contained in reader 12. A buffer 49 is used to stage the data to and from disk 22. A disk controller 50 interfaces with data buffer 49 and the storage electronics 48. This controller can be implemented as an ATA controller or a SCSI controller depending upon the interface in reader 12. Electronic block 52 encrypts data that is written to the disk and decrypts data read from the disk. Control of the encryption/decryption engine is performed by microprocessor 46. The electronics contained in circuitry 48, 49, and 50 process cipher text. Consequently these ICs do not need necessarily require additional security, and thus consist of ICs utilized in common hard drives. Microprocessor 46 in one embodiment is an ARM 7 running the eCOS operating system. [0048] In one embodiment this operating system is downloaded from disk 22 once card 7 is installed in reader 12 and is resident in RAM 51 as shown in Figure 18. Upon removal of card 7 RAM 51 is zeroed by hardware. Boot ROM 47 contains basic routines such as "power — on" sequence and routines to load the operating system from disk 22 into RAM 51. A private and public key set is stored in module 45. Module 45 can be write-once memory or flash depending upon the functionality desired. If the key pair in SCS 1 needs to be modifiable in the field, the memory preferably will be implemented as EEPROM or flash, otherwise write-once can be utilized. Additionally, SCS 1 also stores the public key of the issuer of the data security applications that run on the SCS and the IC 8. This public key, referred herein as the issuer public key, is used to verify the authenticity of the certificate of IC 8 whenever the SCS and the IC perform a mutual authentication.

[0049] SCS 1 in one embodiment includes a wireless 802.11 and Bluetooth interface, as well as a wired USB interface. Antemia 55 can be an external unit or mounted to the PCB mside server 1. Microprocessor 46 can be the host for disk controller 50 or can be configured to be a monitor of the data traffic that passes through disk controller 50. The crypto mode selection, namely, encrypt, decrypt or pass-through, loading of the symmetric key and imtiahzation vector into module 52 is performed by microprocessor 46. An ISO 7816 interface 44, which in one embodiment is an SPI port on microprocessor 46, is utilized to communicate with IC 8. A custom cryptographic protocol is utilized with an application running in microprocessor 35 to establish that SCS 1 is a trusted environment. Once this protocol has been successfully completed, the symmetric key and initialization vector for the respective file can be obtained, or derived based on secret information from the card, to encrypt or decrypt data. [0050] Figure 18 illustrates the three tier logical security model where host device 201 which may be a PC, Personal Digital Assistant (PDA) or other device, assumed to be "un- trusted," communicates with a trusted environment 203 comprised of card 7 and the SCS 1. The channel of communication 202 may be either wired as in USB, USB2 or PCMCIA or wireless. The host device 201 is utilized for display and input, and in turn assumes the security services of the trusted environment 203. SCS 1 is less portable, but has significantly more computing power than card 7. Card 7 is therefore used for the most sensitive cryptographic operations such as digital signatures. The trusted environment is a cryptographically secure computing environment that achieves portability through card 7 but boots and mutually authenticates with SCS 1. At this point, much of the computing and security functionality is handled by the SCS. Only with card 7 inserted in it, can the SCS 1 be trusted to perform security and storage operations for the host 201.

[0051] Those skilled in the art will recognize that there are various methods for SCS 1 and IC 8 to mutually authenticate each other and establish a secure session such that private data can be exchanged between them. In this invention a method is described, which is an improvement over prior art techniques and can be used to optimize the performance while ensuring a higher level of security. A flow chart of this method is shown in Figure 19 where the operational steps are labeled in encircled numbers and these steps are discussed below: [0052] 1. The SCS 1 issues a command to IC 8 sending its public key certificate.

This certificate is digitally signed by the Issuer or the owner of the security application. A "public key certificate," which is frequently referred to as a "certificate," is a collection of data that describes the attributes of the public key of a person or a device. The attributes of the public key include the identification or name of the entity that owns it, how it is used, and when it expires. The certificate also contains the value of the public key itself, and a signature of an authority, effectively binding the public key to its owner. Certificates play an important role in authentication mechanisms used in systems based on public key cryptography. More information about certificates can be found in: "Security in Computing, Second Edition," Charles Pfleeger, Prentice Hall, NJ, 1997, pp. 135-140, and "E-Mail Security— How to Keep Your Electronic Messages Private," Bruce Schneider, John Wiley & Sons, NY, 1995. [0053] 2. IC 8 responds by sending its certificate 302, which is also signed by the

Issuer. Certificate 302 is stored in EEPROM 41 of IC 8.

[0054] 3. The SCS 1 issues a command to IC 8, requesting it to validate the SOS's certificate 301. Upon receiving the request, IC 8 uses the Issuer Public Key, which is stored in ROM 38, to verify the digital signature on certificate 301 of SCS 1. This verification can be done utilizing the commonly known RSA, ElGamal, DSA, or ECC algorithm. In addition, IC 8 validates certain information in certificate 301, based on a pre-installed policy referred to as Certificate Management Policy 303 (CMP). This is illustrated in Figure 20 and described below. The CMP 303 is installed in EEPROM 41 of IC 8, and is depicted in Figure 21. If the digital signature is not valid, or if the fields in certificate 301 are not compliant with the CMP specification, the IC 8 rejects the SCS's certificate and returns an appropriate error message terminating all communications with card 7.

[0055] 4. In a similar manner SCS 1 uses the Issuer Public Key, which is stored in the Secure Write Once Memory 45 of the SCS, to verify the digital signature on certificate 302 of IC 8. The SCS also validates certain information in the ICs certificate 302, based on the Certificate Management Policy 304, which is similar in concept to CMP 303 discussed above. Note that CMP 304 installed in SCS 1 need not be identical to CMP 303 installed on IC 8. This is because IC 8 contains additional secret information that is necessary to decrypt and use the content, and thus it is more discriminatory in the types of devices with which it communicates. If the digital signature on the certificate 302 is not valid, or if certain fields in the certificate 302 are not compliant with the specifications of CMP 304, SCS 1 rejects the ICs certificate and returns an appropriate error message.

[0056] 5. SCS 1 generates a random number and uses it as a challenge, RN1. It encrypts the challenge using the public key of IC 8, and sends the encrypted value 305 to the IC 8. The public key of the IC can be extracted from the ICs certificate 302. SCS 1 also retains the value of RN1 in its secure storage for later reference.

[0057] 6. SCS 1 issues a command to IC 8, requesting the IC to process the encrypted challenge 305 that it sent, and also to provide a response to the challenge. Upon receiving the command, IC 8 performs the following tasks: (1) it uses its private key, stored in EEPROM 41, to decrypt the encrypted data 305 received from SCS 1 and obtain the challenge RNl, and (2) the IC generates its own challenge, RN2, encrypting the concatenated value of RN2 with RNl, using SCS l's public key , and sends its response 306 back to SCS 1. SCS l's public key can be extracted from certificate 301. The IC also retains the value of RN2 in its storage for later reference. (To help defend against future attacks, instead of sending back RNl as part of the response, IC 8 may send back a value derived from RNl, such as a hash value of RNl.) [0058] To prevent replay of a previous encrypted value of RNl , the encryption preferably is performed on the concatenated value of RN2 and RNl as a single unit instead of two encryptions: one on RN2 alone and one on RNl alone. Also, if RSA is used as the public key encryption algorithm, the RSA-encryption is preferably based on secure methods, such as those recommended in the "RSA PKCS #1" standard, Version 2.1, published in June 2002. [0059] 7. SCS 1 uses its private key, which is stored in the secure write once memory

45, to decrypt the response 306 sent by IC 8 and obtain its own challenge RNl and the ICs challenge RN2, in the clear. It then verifies RNl against the reference value of RNl that it retained earlier. If the two values match, the SCS can be satisfied that IC 8 is authentic. It then sends back a response 307 to the IC.

[0060] The response sent back to IC 8 is normally the challenge RN2 encrypted using the

ICs public key, thus making full use of a public key authentication method. To minimize the number of public key-based encryption and decryptions, however, which are usually computationally intensive and create a heavy burden on low-power computing devices, a hash value of RN2 can be sent back instead, as is preferred for this invention. The hash value of RN2 is computed by using a secure hash algorithm, such as SHA-256. A description of the SHA-256 algorithm is described in the United States Federal Information Processing Standard (FJJPS) 180- 2, published in 2002.

[0061] 8. SCS 1 issues a command to IC 8, requesting it to authenticate it by validating the response 307. Upon receiving this command, the IC computes a hash of the value RN2 that it retained earlier, and compares it with the hash value sent back by the SCS. If the two values match, IC 8 can be satisfied that SCS 1 is authentic.

[0062] 9. At this point in the process, both SCS 1 and IC 8 have mutually authenticated each other. They both form a symmetric session key by combining the value of RNl and RN2, and use the session key to exchange sensitive information. A commonly used combination operation is the bit-wise XOR of RN 1 and RN2.

[0063] The private key and the corresponding public key certificate for both SCS 1 and

IC 8 are created and written in the respective memory modules during a secure initialization process. This can be done as a step in the manufacturing process of these devices. Furthermore, depending on the security protocols and applications that will run on these devices, other cryptographic variables, such as the CMP, can also be loaded onto the devices. [0064] Figure 20 is a flow-chart that illustrates the verification of certificate 301 by IC 8.

The steps of this process are encircled in the figure, and described as follows: [0065] 1. IC 8 verifies the digital signature on certificate 301 using the aforementioned Issuer Public Key. Note, however, there are cases where this certificate is not signed by the same issuer of the ICs certificate. In such cases, the CMP 303 would specify whether the IC can accept a certificate signed by a different issuer. Also, certificate 301 must be accompanied by the certificate of the issuer of the SCS. It is assumed that this issuer's certificate is signed by a root CA (Certificate Authority) whose public key is pre-installed in the ICs storage, such as the manufacturer of card 7. If the CMP allows certificates signed by a different issuer, the IC proceeds to verify the digital signature on the Issuer Certificate that accompanies certificate 301, using the root CA's public key. If this verification is successful, the IC proceeds to verify the digital signature on certificate 301. It should be noted that the method utilized to verify a digital signature is usually the same as the method used to create it, such as RSA, ElGamal, DSA, or ECC. Details of these methods are well known. See, e.g. the RSA PKCS #1 standard, the FTPS 186-2 Digital Signature Standard (2000), or the ANSI X9.62 Elliptic Curve Digital Signature Algorithm (ECDSA, 1998). If there is any failure in the verification of the digital signature on certificate 301, or on any certificate in the certificate chain, the IC will reject the SCS and abort the authentication process.

[0066] 2. IC 8 examines the encoded values of CMP 303, which is illustrated in

Figure 21, to determine which field of certificate 301 it is mandated to check. Since the CMP specifies these fields. The length of the CMP could vary from one application to another, for example where one specific field is checked to one that is more secure, and a combination of fields are checked, utilizing the logical operators "AND" and "OR" [0067] Figure 21 illustrates one specification of CMP 303. As an example, the CMP may specify a value that indicates a field, referred to as the "Security Grade", be checked in the manner specified in the next byte of the CMP. In this example, the Security Grade conveys the security rating of the SCS, which has been developed to meet a certified level of the U.S. FDPS 140-2. The IC must ensure the Security Grade of the SCS is Level 3 before the IC can proceed with the mutual authentication process.

[0068] Another example of the Security Grade of an SCS (or an IC) is based on whether it is developed for an Enterprise application or for a Consumer application. For example, the Security Grade in the certificate of the SCS (or IC) may indicate that the SCS (or the IC) is suitable for use in Enterprise installations. Thus, the CMP may specify that the IC will operate only with an SCS that is classified at the same security level. This policy may be less restrictive than the FU?S 140-2 example described above, and it provides the issuer with another way to specify how comparable devices can operate with each other.

[0069] Depending on the scope of the application, the issuer may decide to embed the

Security Grade of the SCS (or the IC) in an existing field of the certificate, or extend an existing certificate into an X509 Version 3 certificate and dedicate a new field for it. In the example of Figure 21, the Security Grade is defined as an Extension field, and is assigned an ordinal number of 8. A detailed description of an X509 certificate can be found in the "ITU-publication, "Recommendation X.509: The Directory Authentication Framework," published by CCITT in 1988.

[0070] Figure 21 also illustrates other fields of the certificate, such as the Public Key

Modulus Length sub-field of the Subject Public Key Info field and the Signature Algorithm Identifier. These can be checked in the manner specified by the encoded values of the CMP. In one preferred embodiment, information in the certificate that is governed by the CMP is the "type," referred to herein as "Device Type" that can communicate with the IC. This is intended to control the number of devices or equipment that can establish a secure session with the IC and extract sensitive information from it. The issuer may specify in the CMP: only a device whose Device Type field indicates it is an SCS or third party content provider high security module (HSM), is allowed to communicate with the IC. If IC 8 determines that any of the fields that it was instructed to check fail to meet the requirements specified by CMP 303, it will reject the SCS and return an error code to indicate the reason for the rejection. [0071] The Certificate Management Policy 303 is pre-loaded into IC 8 during initialization, when cryptographic variables such as the public and private key pair and the issuer's public key, are installed onto the IC. Depending on the security policy of the application issuer, the CMP 303 may not be changed after it is installed, or it can be updated, provided it is authenticated with an accompanying digital signature issued by the issuer. If the CMP is updateable, it preferably will include a version number. The digital signature usually will be computed on the CMP, as well as the version number. This helps assure that an outdated CMP of a previous version cannot be replayed and re-installed onto the IC. [0072] The method described herein provides a content provider a flexible and secure way to manage policies on the content contained in storage volume 22. Those skilled in the art will appreciate that although fields in certificates have been used to enforce security for email and for e-commerce applications, there is no comprehensive and flexible method such as described herein.

[0073] Mutual authentication is the first operation that is performed after booting the

Operating System from card 7. Once this is successful SCS 1 must obtain the key(s) used to encrypt and decrypt the content contained in disk 22 from IC 8. The reader may boot and create the secure environment listed in Figure 18 by the process shown in Figure 22. h Figure 22, the SCS 1 ROM memory segment 47 has executable code which may load an operating system 209 which is eCOS in the preferred embodiment, but may be another embedded operating system into RAM 51 on the SCS. The RAM may be either static RAM, for example, flash or EEPROM, or dynamic RAM. The operating system 209 segment is contained within the magnetic storage media 22 of the card 7. The reader 1 then goes through its boot routine. During the boot process, the operating system reads applications 210 from the storage media 22 and allows execution of these applications. These applications may be dynamically updated by the holder of an issuer key. In the preferred embodiment, before providing the server with the symmetric key to bulk-encrypt or decrypt the data to and from the disk, the card must authenticate the cardholder via the means of biometric data or a password. This helps protect the user in the event the user loses the disk, such that the user's own private data will not be compromised. [0074] In the event the user forgets the password, or the user returns the disk to the organization before leaving the organization, but refuses to provide the password to access the content on the disk, various password recovery methods can be used. In a preferred embodiment recovering a lost password in an enterprise setting described next.

[0075] At the time the card is initialized, a password recovery policy is included in the

Certificate Management Policy 303 and loaded onto the IC. This policy may specify that only a fixed certificate ID belonging to the IT administrator is authorized to recover the password. Alternatively, the policy may specify that a certificate of any authorized IT administrator can be used to recover the password. Subsequently, when a user loses the password, card 1 can be brought to the IT administrator, and the password can be recovered in the manner illustrated in Figure 23 and described below:

[0076] 1. Upon verifying the cardholder is the true owner of the card, the IT administrator inserts the disk into SCS 1 attached to host PC 201 of Figure 18, and uses a desktop password recovery application 308 running on the host PC to send a password recovery request to IC 8, via a smart card command referred to as an APDU. [0077] 2. Upon receiving the request, IC 8 generates a random number RN and returns the random number as well as the ICs unique ID to the application. The IC also retains the random number RN for later reference.

[0078] 3. The IT administrator, via the password recovery application 308, uses his/her own private key to produce a digital signature 309 on the said random number and the ICs unique ID. The application 308 then sends the digital signature, as well as the certificate 310 of the IT administrator to IC S, via an APDU requesting a changing or resetting of the password. The certificate 310 contains a public key that corresponds to the IT administrator's private key.

[0079] 4. Upon receiving the information from the desktop application 308, IC S uses the aforementioned Issuer Public Key to verify the authenticity of the IT administrator's certificate 310. This process is the same as that depicted in Figure 20, except for checking the fields of the certificates. For password recovery, the checking of the CMP focuses only on that part of the policy that deals with devices that are authorized to interact with the IC to recover the password. For example, the CMP may specify that only a device with a specific certificate ID is allowed to recover the password. In this case, the IC compares the specific ID stored in the CMP with the certificate ID stored in the IT adniinistrator's certificate 310. If the two values match, the IC proceeds to the next step. Otherwise, the IC rejects the password recovery request and aborts the recovery operation.

[0080] Alternately, if the CMP 303 specifies that any authorized IT administrator is allowed to recover the password, the IC verifies that the function or usage field, which is an

X509.3 certificate extension field, contains the information indicating that the IT administrator is authorized to recover the password. If this verification fails, the IC aborts the recovery operation.

[0081] 5. The IC 8 verifies the digital signature 309 on the random number and the

ICs unique ID by using the IT Administrator's public key to decrypt the digital signature to obtain a 160-bit hash value. Next, it appends its unique ID to the random number RN that it retained previously, and performs a hashing operation on the appended result, using the same hash algorithm that the password recovery application 308 used in the generation of the digital signature 309. The IC then compares the computed hash value with the decrypted hash value. If the two values match, the IC resets the password and allows the user (or new user) to select a new password for the card.

[0082] 6. IC 8 informs the password recovery application 308 that the password recovery/reset operation is successful. The application then guides the cardholder through the process of setting a new password.

[0083] Note that the user that requests password recovery may not necessarily require delivering the card to the IT administrator, as this may not be convenient, for example, if the user is traveling, or resides in a different geographic location. It will be appreciated that the method described herein can also be used by the IT administrator to authorize a password reset via the .

Internet, provided the IT administrator has records to track the issued cards, and that a prior arrangement has been made to enable the IT administrator to indirectly authenticate the cardholder, for example, via voice recognition on the phone, via the confirmation of the cardholder's supervisor, or via another mutually acceptable means.

[0084] Those skilled in the art will appreciate that there are other methods for the IT

Administrator to recover a lost password. For example, the IT Administrator, via a desktop program, may send his/her certificate to the IC. Upon successfully validating the IT administrator's certificate, the IC uses it to encrypt the password and returns the cipher text to the desktop program. Since the IT administrator has the corresponding private key, he is the only one that can decrypt the password and provide it to the user.

[0085] Regardless of the method used, because the IT administrator's private key is such a powerful tool for recovering the password, it is important that its value and usage be protected to prevent abuses. One way to achieve this is to store the private key in a Smart Card, and have all cryptographic computations involving the private key performed inside the card's IC. [0086] In a small business or a home setting, where the cost does not justify having an IT administrator, password recovery can be achieved via another method as described next. Figure 24 describes an alternate process of generating a password recovery token, which may then be utilized to reset the password, as shown in the figure. The user selects two "Secret Questions" 220 which have indexes 221 in a master list of questions. These indexes 221 are combined with a random number 222 generated on the host to create a recovery file 223 which is then stored on the disk of the local host machine 224. The answers to the secret questions (item 220) 225 are then normalized and combined with random number 222 and a SHA1 hash or any other form of cryptographic hash is utilized to generate the recovery token which is written to the EEPROM 42 in card 7.

[0087] To recover or reset the password, the method illustrated in Figure 25 is used. The recovery file 223 is located on the local PC 224 and read. From this, the indexes 221 of secret questions 220 are parsed and the secret questions 220 are displayed. The user must then input the answers 225 to the secret questions 220. These answers are then normalized and appended to the random number 222 read from the recovery file 223 and a cryptographic hash generated as in the previous step. This hash is sent to card 7 where it is compared to the hash generated in the step illustrated in Figure 24 and if the hashes match, a password reset is allowed. [0088] After the IC has successfully authenticated the user, it uses the symmetric session key, which is formed as a result of the mutual authentication process with SCS 1, to encrypt the data-encrypting key(s) stored in its secure storage and return the encrypted result(s) to the SCS. In turn, the SCS uses the symmetric session key to decrypt the encrypted data and obtain the data-encrypting key(s) in the clear.

[0089] Depending on the value of the content, a single data-encrypting key may be used for all the data on the disk, or a different data-encrypting key can be used for each sector of the disk. In the latter case, the number of data-encrypting keys might be large and the data- encrypting keys can be stored on the disk instead of the IC. The assignment of a data-encrypting key to one or multiple sectors of the disk can be achieved via an indexing scheme as follows: [0090] The sector number is right shifted (binary shift) by a number of bits contained in a storage location on the IC. The resulting number is used as the index for the IV table kept on disk. This allows the system to use one IV per sector, or for any group of sectors that is a power of 2.

[0091] In addition to providing the data encrypting keys to SCS 1, IC 8 also provides the

SCS a mask for producing the initialization vector (IV) as described in Figures 26 and 27. This mask is referred herein as IV Mask 206. Using this mask, an TV can be created for each sector of the disk by encrypting the sector number (or ID) with TV Mask 205. The IV so generated is fed to the Encryption/Decryption Engine 52, for use with an appropriate key 207 employing the Cipher Block Chaining (CBC) mode.

[0092] Those skilled in the art will appreciate that there are various methods by which content providers can protect their content. For example, a provider may want to encrypt content using a key that is generated using a High Security Module (HSM) residing at his facility. The provider may then want to transmit this encrypted content to disk 22 in card 7 on an end-to-end basis using the Internet or a proprietary network. In this case, the SCS does not perform any transformation on the received data; it simply uses the pass-through mode and stores it on the disk. At the same time, the HSM of the content provider could establish a secure session with IC 8, and securely transmit the encryption key(s) to it. This secure session can be established via the authentication procedure described earlier in this invention, or by any other technique preferred by the content provider.

[0093] hi the preferred embodiment, a number of physical security countermeasures can be employed on both the SCS 1 and IC 8, to provide a high level of confidentiality for the secrets stored in memory units 45 and 41. Chief among these countermeasures are: (1) sensors that trip when they detect temperature, voltage, and frequency applied to the SCS and IC 8 outside normal operating ranges, (2) burying signal paths and connectors under a high-grade epoxy coating or a multi-layer circuit board, and (3) tamper resistance circuitry, including optical sensors installed under the above coatings. When a tampering act is detected, cipher keys stored in 45 and 41 can be erased or reset to zero. [0094] In another embodiment shown in Figure 12, SCS 1 has an additional electronic block 56 consisting of radio, encoding and digital logic connected to a separate antenna 57. This antenna in one embodiment is tuned to a 2.6GHz satellite frequency band or to a 900MHz cellular band or a GSM band. This architecture allows SCS 1 to connect to a variety of mobile devices that have just 802.11 or Bluetooth functionality and can provide these platforms access to satellite or cellular bands for a richer user experience. SCS 1 becomes a mobile communicator and data server.

[0095] Figure 13 illustrates the disk storage area 22 on card 7. This storage area is separated into multiple segments, including a user accessible segment 58, a SCS only accessible application segment 59 for applications 210 and their data and a reserved segment 60 for operating system 209 and other system data.

[0096] Figure 14 illustrates the user accessible segment 58, which may in turn be separated into multiple partitions, one of which may be unencrypted 61 while the others 62, 63,

64 are encrypted and only accessible after user authentication. The SCS 1 may map each partition, namely, 61, 62, 63 or 64 to the host 201 as separate storage volumes.

[0097] Figure 15 illustrates another embodiment of SCS 1. In this configuration a hard drive 65, for example, a 1.0 inch disk drive with a flexible cable 66 is mounted inside the SCS housing. Hard drive 65 is powered by the battery contained inside the unit, via the USB cable, or by other well known techniques, and is connected to disk controller 50. Microprocessor 46, in one embodiment, is the host for controller 50 and can be configured with hard drive 65 as a slave to disk 22 or as the master with disk 22 as the slave. The benefit of this architecture is that files in the hard drive can be encrypted with the user's key. Furthermore, third party content can be encrypted and stored in disk 22 with the respective cipher keys stored in IC 8. Third party content can be separated from the user's information. For example, a company could issue card 7 to an employee along with SCS 1. The employee can store personal information in hard drive

65 and encrypt it with a key that is known only to that person. SCS 1 then operates with a default operating system installed in hard drive 65. When the employee utilizes confidential information of the company, a specific card 7 is inserted, and microprocessor 46 installs the appropriate operation system to allow operation with the files and data stored in disk 22. In the event the employee creases to be with the company, a policy, for example, requiring the user to logon to the company's network every day or within a pre-selected time period to keep card 7 active, can be managed by IC 8. Absent such log-in, the company's server can disable card 7 and lock the information in disk 22. The user could attempt to read disk 22 in a modified reader 12, but this attempt would fail because the encryption key is only available through IC 8. [0098] Figure 16 illustrates another embodiment of SCS 1. In this configuration a PC

Card Type II slot is provided in SCS 1. The PC Card is connected to disk controller 50. A PC Card hard drive can also use this slot for additional storage capacity than available through hard drive 65. Alternately, as shown in Figure 17, the PC Card slot could allow other storage media to be utilized with a PC Card adapter module 67. This adaptor has a slot 69 through which other types of storage media can be inserted. The figure shows a 1.0 inch hard disk drive 72 with a CompactFlash™ interface 73, or a SD Card or a multimedia card 71 or a Smartmedia™ Card 70 which could be utilized. It should be noted that each of these storage devices may require a separate adaptor module.

[0099] Figure 28 illustrates another embodiment where a display screen 77 is included in the SCS 78. In this embodiment the screen has a resolution of 640x 480 pixels with 262K colors and a diagonal dimension of 4.0 inches. File management controls are provided as a menu button 76 and a touch-screen input zone (not shown in the Figure) on the display screen 77. Video and music can be played using the buttons stop 89, rewind 80, play 81, forward 82 and card eject 83. The audio signal is available via headphone jack 78. The display screen can also be utilized for e-mail, file directory, document editing and digital still picture viewing. Figure 29 illustrates yet another embodiment with the display in the plane of the SCS 78 for a slimmer and more portable form factor.

[0100] Preferred embodiments of the invention have been described in detail. It will be appreciated, however, that many changes and modifications in these implementations may be made. The scope of the invention is defined by the following claims.

Claims

What is claimed is:

1. A system comprising: a memory card including a rotating magnetic memory for storing information, and a microprocessor, the memory card adapted to be coupled to a reader for storing and retrieving information therefrom, and the memory card including a first public encryption key; and a secure content server coupled to the reader, the server storing private and public encryption keys, including the first public encryption key, whereby the memory card and the secure content server can authenticate each other.

2. A system as in claim 1 wherein the authentication includes an exchange of keys between the memory card and the server.