WO2005107287A1 - Dispositif de communication et de visualisation de donnees portatif securise - Google Patents

Dispositif de communication et de visualisation de donnees portatif securise Download PDF

Info

Publication number
WO2005107287A1
WO2005107287A1 PCT/US2005/013638 US2005013638W WO2005107287A1 WO 2005107287 A1 WO2005107287 A1 WO 2005107287A1 US 2005013638 W US2005013638 W US 2005013638W WO 2005107287 A1 WO2005107287 A1 WO 2005107287A1
Authority
WO
WIPO (PCT)
Prior art keywords
card
scs
certificate
disk
reader
Prior art date
Application number
PCT/US2005/013638
Other languages
English (en)
Inventor
Finis Conner
Anil Nigam
An Van Le
Paul Guthrie
Original Assignee
Storcard, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Storcard, Inc. filed Critical Storcard, Inc.
Publication of WO2005107287A1 publication Critical patent/WO2005107287A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/603—Digital right managament [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • 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.
  • 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.
  • Windows XP has tools that can encrypt individual files stored in the hard drive.
  • 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.
  • 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.
  • 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).
  • OS operating system
  • 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.
  • 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.
  • a system 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.
  • Figure 1 is a perspective view of the hardware components of a preferred embodiments, wherein;
  • Figures 2 is top view of the preferred embodiment
  • Figures 3 is a front view of the preferred embodiment.
  • Figures 4 is a side view of the preferred embodiment
  • 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
  • Figure 6 illustrates internal details, in a side view, of a section taken through the reader mechanism shown in Figure 5;
  • Figure 7 is a front view of the card utilized in the preferred embodiment;
  • Figure 8 is a side view of the card, showing its thickness relative to other dimensions of the card;
  • 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;
  • Figure 10 is an exploded view of the card and some internal components
  • Figure 11 illustrates the electronic architecture of the preferred embodiment
  • Figure 12 illustrates another electronic architecture of the preferred embodiment
  • Figure 13 depicts the layout of the disk storage volume in the card
  • Figure 14 depicts the file structure of the disk storage volume contained in the card
  • Figure 15 illustrates another arrangement of the hardware of the preferred embodiment
  • Figure 16 depicts another configuration of the hardware of the preferred embodiment
  • Figure 17 shows storage options that can be used with the removable option illustrated in Figure 16;
  • Figure 18 depicts a three-tier logical security model involving the reader, the card, and the host computer;
  • Figure 19 depicts the steps in the mutual authentication process between the card and the reader
  • Figure 20 depicts the steps in verifying the reader's public key certificate by the card
  • FIG. 21 illustrates a Certificate Management Policy (CMP) to specify how the fields in a certificate might be checked
  • Figure 22 illustrates the boot process
  • Figure 23 depicts a password recovery process in an enterprise environment
  • Figure 24 illustrates a password initialization process in an environment where the user of the card is self-supported
  • Figure 25 illustrates the password recovery process
  • Figure 26 illustrates the system operating in automatic decryption mode
  • Figure 27 illustrates the system operating in automatic encryption mode
  • Figure 28 illustrates another embodiment with a display screen and controls to review content locally
  • Figure 29 illustrates an orientation of the display screen to achieve a slimmer form factor.
  • FIG. 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.
  • Card 7 preferably has a form factor of a credit card, namely, 85.6mm long,
  • FIG. 2 and 3 show the orthographic views of SCS 1.
  • 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.
  • Reader 12 when inserted into SCS 1 is received by a mechanism referred to herein as reader 12.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 8 is a side view of card 7. The thickness of this card in one embodiment is
  • 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.
  • FIG 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.
  • the pin holds the shutter, while the card body is moved into the unit.
  • 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.
  • the- shutter covers opening 27.
  • a hub 31 A 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.
  • 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.
  • a card with a flexible magnetic disk 22 provides the large storage volume.
  • FIG. 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 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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
  • Certificate 302 is stored in EEPROM 41 of IC 8.
  • the SCS 1 issues a command to IC 8, requesting it to validate the SOS's certificate 301.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • IC 8 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.
  • IC 8 may send back a value derived from RNl, such as a hash 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.
  • 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.
  • SCS 1 uses its private key, which is stored in the secure write once memory
  • the response sent back to IC 8 is normally the challenge RN2 encrypted using the
  • 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.
  • SCS 1 issues a command to IC 8, requesting it to authenticate it by validating the response 307.
  • 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.
  • 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.
  • FIG. 20 is a flow-chart that illustrates the verification of certificate 301 by IC 8.
  • 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.
  • CA Certificate Authority
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Another example of the Security Grade of an SCS is based on whether it is developed for an Enterprise application or for a Consumer application.
  • 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.
  • 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.
  • the issuer may decide to embed the
  • 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 can be checked in the manner specified by the encoded values of the CMP.
  • 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.
  • HSM high security module
  • 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.
  • 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.
  • 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.
  • Mutual authentication is the first operation that is performed after booting the
  • 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.
  • 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.
  • the card 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.
  • various password recovery methods can be used. In a preferred embodiment recovering a lost password in an enterprise setting described next.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • the CMP may specify that only a device with a specific certificate ID is allowed to recover the password.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • the IT Administrator via a desktop program, may send his/her certificate to the IC.
  • 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.
  • 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.
  • 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.
  • the IC 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.
  • the SCS uses the symmetric session key to decrypt the encrypted data and obtain the data-encrypting key(s) in the clear.
  • 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.
  • IC 8 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.
  • 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.
  • CBC Cipher Block Chaining
  • a provider may want to encrypt content using a key that is generated using a High Security Module (HSM) residing at his facility.
  • HSM High Security Module
  • 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.
  • the SCS does not perform any transformation on the received data; it simply uses the pass-through mode and stores it on the disk.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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,
  • the SCS 1 may map each partition, namely, 61, 62, 63 or 64 to the host 201 as separate storage volumes.
  • FIG. 15 illustrates another embodiment of SCS 1.
  • 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.
  • files in the hard drive can be encrypted with the user's key.
  • 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
  • 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.
  • 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 CompactFlashTM interface 73, or a SD Card or a multimedia card 71 or a SmartmediaTM Card 70 which could be utilized. It should be noted that each of these storage devices may require a separate adaptor module.
  • Figure 28 illustrates another embodiment where a display screen 77 is included in the SCS 78.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système comprenant une carte mémoire (7) possédant une mémoire magnétique rotative (22) destinée à stocker des informations et un microprocesseur (35). La carte mémoire (7) est conçue pour être couplée à un lecteur (12) permettant de stocker des informations et de les récupérer à partir de celle-ci, et la carte mémoire (7) comprend une première clé publique de chiffrement. La carte mémoire (7) peut être couplée à un serveur de contenu sécurisé (1), lequel est également couplé au lecteur (12) pour la carte mémoire (7). Le lecteur (12), le serveur (1) et la carte mémoire (7) permettent chacun de stocker des clés publiques et privées de chiffrement, y compris la première clé publique de chiffrement. Ainsi, la carte mémoire (7) et le serveur (1) peuvent s'authentifier mutuellement.
PCT/US2005/013638 2004-04-21 2005-04-20 Dispositif de communication et de visualisation de donnees portatif securise WO2005107287A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US56456704P 2004-04-21 2004-04-21
US60/564,567 2004-04-21

Publications (1)

Publication Number Publication Date
WO2005107287A1 true WO2005107287A1 (fr) 2005-11-10

Family

ID=35242057

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/013638 WO2005107287A1 (fr) 2004-04-21 2005-04-20 Dispositif de communication et de visualisation de donnees portatif securise

Country Status (1)

Country Link
WO (1) WO2005107287A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012093921A (ja) * 2010-10-27 2012-05-17 Nec Engineering Ltd 情報漏洩防止ストレージシステム
US9407610B2 (en) 2009-03-25 2016-08-02 Pacid Technologies, Llc Method and system for securing communication
US9411972B2 (en) 2009-03-25 2016-08-09 Pacid Technologies, Llc System and method for creating and protecting secrets for a plurality of groups
US10320765B2 (en) 2009-03-25 2019-06-11 Pacid Technologies, Llc Method and system for securing communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030043485A1 (en) * 2001-07-27 2003-03-06 Storcard, Inc. Apparatus for reading and writing cards having rotating memory
US20030218064A1 (en) * 2002-03-12 2003-11-27 Storcard, Inc. Multi-purpose personal portable electronic system
US6832730B2 (en) * 2001-07-27 2004-12-21 Storcard, Inc. Smart card with rotating storage

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030043485A1 (en) * 2001-07-27 2003-03-06 Storcard, Inc. Apparatus for reading and writing cards having rotating memory
US6832730B2 (en) * 2001-07-27 2004-12-21 Storcard, Inc. Smart card with rotating storage
US20030218064A1 (en) * 2002-03-12 2003-11-27 Storcard, Inc. Multi-purpose personal portable electronic system

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9407610B2 (en) 2009-03-25 2016-08-02 Pacid Technologies, Llc Method and system for securing communication
US9411972B2 (en) 2009-03-25 2016-08-09 Pacid Technologies, Llc System and method for creating and protecting secrets for a plurality of groups
US9876771B2 (en) 2009-03-25 2018-01-23 Pacid Technologies, Llc System and method for authenticating users
US9882883B2 (en) 2009-03-25 2018-01-30 Pacid Technologies, Llc Method and system for securing communication
US10044689B2 (en) 2009-03-25 2018-08-07 Pacid Technologies, Llc System and method for authenticating users
US10171433B2 (en) 2009-03-25 2019-01-01 Pacid Technologies, Llc System and method for authenticating users
US10320765B2 (en) 2009-03-25 2019-06-11 Pacid Technologies, Llc Method and system for securing communication
US10484344B2 (en) 2009-03-25 2019-11-19 Pacid Technologies, Llc System and method for authenticating users
US11070530B2 (en) 2009-03-25 2021-07-20 Pacid Technologies, Llc System and method for authenticating users
JP2012093921A (ja) * 2010-10-27 2012-05-17 Nec Engineering Ltd 情報漏洩防止ストレージシステム

Similar Documents

Publication Publication Date Title
US9286493B2 (en) Encryption bridge system and method of operation thereof
TW514845B (en) Data storage regenerator and data storage processing method and program providing media
US7254706B2 (en) System and method for downloading of files to a secure terminal
US8787973B2 (en) Device and method for controlling usage of a memory card
US8966580B2 (en) System and method for copying protected data from one secured storage device to another via a third party
US7496756B2 (en) Content usage-right management system and management method
US8898477B2 (en) System and method for secure firmware update of a secure token having a flash memory controller and a smart card
JP2003058840A (ja) Ｒｆｉｄ搭載コンピュータ記録媒体利用の情報保護管理プログラム
US7721346B2 (en) Method and apparatus for encrypting data to be secured and inputting/outputting the same
US20090268906A1 (en) Method and System for Authorized Decryption of Encrypted Data
US20020138733A1 (en) Information transaction system
US20050235143A1 (en) Mobile network authentication for protection stored content
US20090276474A1 (en) Method for copying protected data from one secured storage device to another via a third party
US8763110B2 (en) Apparatuses for binding content to a separate memory device
JP2008504592A (ja) 安全なデータ・バックアップおよび再生
US8689009B2 (en) Authentication-secured access to a data carrier comprising a mass storage device and chip
US20050027991A1 (en) System and method for digital rights management
WO2006004130A1 (fr) Procédé de gestion de données, programme correspondant et support d’enregistrement de programme
CN101595488A (zh) 用于将内容绑定到单独的存储器装置的方法和设备
US8954757B2 (en) Method, host, storage, and machine-readable storage medium for protecting content
JP4047573B2 (ja) 電子情報管理装置及びプログラム
CN110929302B (zh) 一种数据安全加密存储方法及存储装置
WO2005107287A1 (fr) Dispositif de communication et de visualisation de donnees portatif securise
KR20050088081A (ko) 고 저장 용량을 구비한 보안 트랜잭션 카드
CN112434271A (zh) 存储设备身份的加密验证方法、装置及设备

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1) EPC.EPO FORM 1205A DATED 21.02.2007

122 Ep: pct application non-entry in european phase