System, method and apparatus for decrypting data stored on removable media

A technique that decrypts data stored on removable media, if the device on which the encryption was performed is lost, unavailable, or the user credentials are lost. In example embodiment, this is achieved by using the administrator UID, the administrator UDID, the removable media, the names of one or more data files to be decrypted, the administrator Pswd, and a KeyID to decrypt data stored on the removable media associated with a lost or unavailable mobile device on which encryption was performed.

FIELD OF THE INVENTION

This invention relates to the field of cryptography mechanisms, and more specifically to a system, method and apparatus to decrypt data stored in removable media.

BACKGROUND OF THE INVENTION

To ensure data security on devices for local storage, several pointed solutions are available that rely on proven encryption and decryption mechanisms. Standard security practices recommend that the keys used for encryption and decryption should not be stored along with the encrypted data. This is akin to locking a door with a strong lock and leaving the key under the doormat.

Also, a user may use multiple keys to encrypt different pieces of data. Managing these keys can become very difficult when the number of keys used to encrypt the different pieces of data significantly increases.

Furthermore, standard security practices require that the keys used for encryption and decryption should be changed periodically. In such a case, the data encrypted by previous keys should be recoverable and the integrity of data should still be maintainable. The keys required for decryption of data may get lost or corrupted. In which case there would be no way of recovering the encrypted data.

Organizations require that access to sensitive corporate data stored in encrypted format should be recoverable (decrypted) by authorized personnel other than the entity who may have encrypted the data. This requirement arises from the fact that an entity may leave the organization. In such a case the data encrypted by that entity should still be recoverable by authorized personnel such as an administration/organization or a government.

Conventional solutions for key escrow and distribution are largely targeted towards systems, such as desktops, servers, storage devices, and other such fixed machines, which are protected within the periphery of the corporate firewall. These systems generally have sufficient processing capabilities, power/energy resources and capabilities to comply with the corporate security policies. In addition, these systems are physically protected within the corporate periphery.

However, these conventional solutions are not adequate to address the security and integrity needs of mobile computing devices like laptops, personal digital assistants (PDAs), tablet computers and mobile media like flash cards. Mobile devices and media are exposed to security threats, which are not common to fixed systems. They do not lie within the periphery of the enterprise; hence it is difficult to mandate and audit them to adhere to corporate security and firewall policies.

In addition, portable computing devices and mobile media are vulnerable to theft, thereby increasing the likelihood of exposing sensitive files. Storing laptop data in a cryptographic file system does not fully address the problem. Such systems ask the user to imbue them with long-term authority for decryption, but that authority can be used by anyone who physically possesses the machine.

Further, these conventional solutions do not address the issue of recovering encrypted data stored in removable media like flash cards, floppies, thumb drives and the like, when user credentials are unavailable or the device used for encryption is lost. When there is a loss of a mobile device or user credentials, there is no mechanism to recover the data stored on removable media by conventional techniques and hence there is a loss of data.

Furthermore, mobile devices have limited computing and battery power and hence solutions that rely on public keys may prove to be computationally expensive. Not all mobile devices support industry standard key-lengths, such as 128 bit and above for symmetric encryption and 512 bit and above for asymmetric key encryption.

One conventional technique uses a Public Key Infrastructure (PKI) based solution, which mostly depends on X.509 Digital Certificates, Certification Authority, CA and PKI. These solutions typically rely on asymmetric keys for mutual authentication, which can require large processing capabilities and mandate the requirement of a PKI. Therefore, these solutions can result in not being very cost effective. Moreover, the certificates used in PKI are not customized with extensions to accommodate the requirements of mobile devices, like unique device identifier, device capability credentials and so on.

Another conventional technique relies on using trusted escrow agents that require manual intervention. Such solutions are generally not feasible in an enterprise with a large number of mobile device deployments. Further, these solutions tend to be slow and non-adaptive.

The above techniques rely heavily on role based access control to restrict/allow access to corporate data. Such techniques have control over who is viewing the data, but they do not have any control over where the data is being accessed. For example, based on use and domain credential an authorized user can access enterprise data from a desktop, laptop or PDA. While this addresses convenience of data being accessed any time, anywhere, there are serious security threats to be concerned about when dealing with mobile devices. The security capabilities of mobile devices are generally inferior when compared with the security capabilities of fixed devices. In addition, current corporate security policies and firewalls do not provide adequate control over mobile devices.

SUMMARY OF THE INVENTION

According to an aspect of the present subject matter, there is provided a method for decrypting data stored on removable media, if a device on which an encryption was performed is lost or unavailable or user credentials are lost, when using an administrator unique user identifier, a administrator unique device identifier, a removable media, names of one or more data files to be decrypted, an administrator password, and a unique key identifier.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the preferred embodiments, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

The abbreviation “UID” refers to a unique user identifier. The abbreviation “UDID” refers to a unique device identifier. The abbreviation “H(UDID)” refers to a hash of UDID. The abbreviation “Pswd” refers to a password or authentication credentials or a shared secret. The abbreviation “Key Escrow” refers to a mechanism to safely and reliably store and retrieve a cryptography key with a trusted entity for encryption and decryption of data. The abbreviation “KeyID/KID” refers to a key identifier. The abbreviation “Key” refers to a cryptography key used for encryption and decryption of data, and is also referred to as “data recovery key”. The abbreviation “{H(UDID)} Pswd” refers to a password-encrypted H(UDID). The abbreviation “{KeyID} Pswd” refers to a password-encrypted KeyID. The abbreviation “{H(UDID), KeyID} Pswd” refers to a password-encrypted H(UDID) and KeyID. The term “KeyID is optional” defines the requirement that KeyID may be specified optionally in the mechanism to obtain a key for encryption if a specific key is desired for encryption. If not the Key ID is used and a new key will be generated and sent to the client for encryption. The abbreviation “{Key}Pswd” refers to a password-encrypted key.

The term “desired operation” refers to all authorized operations that can be performed by an authenticated user with the cryptography key management system. Exemplary desired operations include, obtaining a cryptography key for encryption, obtaining a cryptography key for decryption, changing a password, decrypting data on a removable media if a device and/or a cryptography key is lost, registering a cryptography key, creating new user accounts and associating with devices and keys, and the like. The terms “administrator”, “system administrator” and “system admin” are used interchangeably throughout the document. The terms “key management system” and “cryptography key management system” is used interchangeably throughout the document.

The proposed technique provides a key escrow and key distribution mechanism that addresses security needs of mobile devices. The proposed security mechanism addresses the security based on principles of security, such as authentication, authorization, confidentiality, integrity, and non-repudiation.

Referring now toFIG. 1, there is shown an example embodiment that is used for decrypting data stored on removable media for which keys for decrypting associated with the device are lost or for which user credentials are unavailable. The enterprise cryptography key management system shown inFIG. 1includes a client mobile device105, a system administrator120, intended user135, cryptography key management system140, and a secure key database150coupled to the cryptography key management system140. Furthermore as shown inFIG. 1, the cryptography key management system140includes a key management server142, a privilege server148, a policy engine146, and a key access component147. Further as shown inFIG. 1, the client mobile device105includes a key management application module110that includes a key policy engine210, a file access component220, and an encrypted file store310that is coupled to the key management application module110. In operation, as shown inFIG. 1, the system admin120resets a user's account to an inactive state. The cryptography key management system140then associates the UDID associated with the UID of the user with the lost device or lost credentials, to the UDID of the administrator's mobile device105. The cryptography key management system140then attaches the removable media to the administrator's mobile device registered with the cryptography key management system140. The cryptography key management system140then requests for the UID, the names of the one or more data files to be decrypted, and the password from the administrator via the client mobile device105. The cryptography key management system140then determines unique KeyID from stored associated metadata to decrypt the one or more data files. The cryptography key management system140then determines the UDID associated with the client mobile device105.

The cryptography key management system140then hashes the UDID and encrypts the H(UDID) and KeyID using a symmetric cryptography key derived from the Pswd to obtain a {H(UDID, KeyID}Pswd. The cryptography key management system140then sends the {H(UDID, KeyID}Pswd, and the UID to a cryptography key management system and requests for the password. The cryptography key management system140then connects to a secure key database150via a valid user role upon successful validation of the UID and returns the password for the associated UID to the cryptography key management system140.

The cryptography key management system140then decrypts the {H(UDID), KeyID}Pswd using a symmetric cryptography key derived from the password to obtain the H(UDID) and the KeyID by the cryptography key management system. The cryptography key management system140then determines whether the decryption of the {H(UDID, KeyID}Pswd was successful. The cryptography key management system then establishes client authentication and passes the H(UDID) and the KeyID by the cryptography key management system upon a successful client authentication.

The cryptography key management system140then retrieves the cryptography/data recovery key associated with the H(UDID) and the KeyID. The cryptography key management system then encrypts the cryptography/data recovery key using a symmetric cryptography key derived from the password to obtain the {Key} Pswd and sends it to a key management application module110via the cryptography key management system140. The cryptography key management system140then forwards the {Key} Pswd to the key management application module110.

The cryptography key management system140then decrypts the {Key}Pswd using a symmetric cryptography key derived from the password by the key management application module110to obtain the data recovery key. The cryptography key management system140then determines whether the decrypting of the {Key} Pswd was successful. The cryptography key management system140then establishes a server authentication by the key management application module110, if the decryption of the {Key} Pswd was successful. The cryptography key management system140then determines whether the server authentication was successful. The cryptography key management system then uses the cryptography/data recovery key for decrypting the one or more data files if the authentication was successful.

This following code is a pseudo implementation specific to a PocketPC platform. However, the design and mechanisms described above are platform agnostic and can be implemented on any other standard platform and device.

Creation of Private Exponent One Key

The keys for an RSA algorithm generally have two parts. The first part is referred to as a modulus. A modulus is a 512-bit number (64 bytes) and is the product of two 256-bit primes. The modulus is the same for both the public and the private keys. The second part of an RSA key is referred to as an exponent. This is a number of variable lengths, with the exponent of the public key usually being the smaller of the two. The two exponents, the public and the private, are related in a mathematical way, but determining one exponent from the other is hard without knowing the primes.

Essentially, with the RSA encryption, the plaintext viewed as a binary number, is raised to the power of the public exponent, and the remainder after dividing by the modulus is the ciphertext. To decrypt, the ciphertext is raised to the power of the private exponent, and the remainder after dividing by the modulus is the plaintext again. In Exponent one keys, the exponent part of the public and private RSA keys is set to 1. Because the key exponent is one, both the encryption and decryption do not affect the plain text, and thus essentially leave the data in plain text.

The exponent one key pair needs to be generated to export the encryption/decryption key in a PLAIN TEXT BLOB format. The following illustrates an example source code that can be used to create a private exponent one key:

The following illustrates an example source code that can be used to generate a random session key:

The following illustrates an example source code that can be used to derive a session key from a password:

The following illustrates an example source code that can be used to export a session key in a plain blob format:

The following illustrates an example source code that can be used to import a session key from plain blob format:

The following illustrates an example source code to encrypt a file:

The following illustrates an example source code that can be used to decrypt a file:

The following illustrates an example source code that can be used to generate a key identifier by hashing a UDID and a plain text key blob:

The hash of the UDID and the plain text key blob could act as a unique key identifier

The following illustrates an example source code that can be used to obtain a UDID for a pocket PC 2002 device:

The above technique addresses the security and data integrity needs of mobile devices and removable media that cache sensitive enterprise data. Further, the technique binds the decryption keys to a particular mobile device and a user.

Following are some examples of security threats, to encrypted data cached on the mobile device and removable media, that are addressed using the above described techniques:

If a mobile device is lost or stolen or falls in the wrong hands, the user will be prevented from decrypting the encrypted data.

If a removable media is lost or stolen or falls in the wrong hands, the user will be prevented from decrypting the data without having possession of the mobile device on which the data was originally encrypted and the correct credentials.

Any malicious intent of copying or beaming encrypted data onto a different device and trying to decrypt the data by a user will be prevented.

This technique also addresses all the basic requirements of data security in an enterprise; for example, authentication, confidentiality, integrity, authorization, non-repudiation (note that, in this context the definition of non-repudiation is limited to non-deniability), and other such data security requirements. These security requirements are addressed in the various mechanisms spelt out for key escrow and distribution. The mechanisms described above are original and are based on industry proven algorithms and security protocols. The proposed technique applies these raw technologies and concepts to address mobile device security and solutions.

The above approach provides administrative mechanisms, which can be executed only by using administrative credentials to override the general functionality of the system. These mechanisms can be typically used to recover encrypted data if a user leaves the organization, if the data is backed up in a secure location, cached on removable media, and/or the device on which the original encryption was performed is lost. Furthermore, administration or government requirements for escrow can also be addressed.

The above technique addresses computational and battery power limitations of mobile devices. The present invention does not rely on public key certificates, CA, or on the existence of PKI, which require higher computational power that is undesirable in the context of mobile devices. Moreover, the present invention relies on industry proven symmetric key mechanisms for mutual authentication, transit security, and local data encryption and decryption. The symmetric key based mechanisms require lesser processing and computational power. Also, the present invention significantly reduces usage of computing and battery resources in mobile devices.

The above-described techniques do not rely on the existence of a public key deployment. Hence they provide a cost effective solution for a large number of mobile devices in an enterprise. Further, this approach does not require manual intervention and relies on industry proven mechanisms and algorithms for security requirements. Hence, this approach is also feasible for large-scale mobile deployments.

This approach can be easily plugged into any existing security management infrastructure. It can also accommodate industry standard algorithms, protocols, and/or mechanisms. Further, the architecture provides scalability and availability. Furthermore, the approach can leverage trusted platforms for enhanced security. The mechanism of mutual authentication before transfer of keys becomes simpler with the use of trusted platforms. This is because the establishment of trust becomes simpler when the entities used in the transaction are trusted platforms. In addition, mechanisms for auditing and logging of access and activities on the enterprise are provided by trusted platform modules. Trusted platforms provide for binding data to a particular software state on the device. This can be leveraged to enhance the mechanism for binding the data to a device and a user.

This approach also addresses the needs of a general key escrow and distribution system as mentioned above. This approach provides a significant cost savings over traditional PKI based installations. Also, the proposed technique is computationally inexpensive and well suited for the processing capabilities of mobile devices. Further, the mobile device can be plugged into any existing key management infrastructure, thus enhancing the capabilities of existing installations.

In the embodiment shown inFIG. 2, a hardware and operating environment is provided that is applicable to any of the information systems and tools shown in the other Figures.

As shown inFIG. 2, one embodiment of the hardware and operating environment includes a general purpose computing device in the form of a computer20(e.g., a personal computer, workstation, or server), including one or more processing units21, a system memory22, and a system bus23that operatively couples various system components including the system memory22to the processing unit21. There may be only one or there may be more than one processing unit21, such that the processor of computer20comprises a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a multiprocessor or parallel-processor environment. In various embodiments, computer20is a conventional computer, a distributed computer, or any other type of computer.

The system bus23can be any one of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory can also be referred to as simply the memory, and, in some embodiments, includes read-only memory (ROM)24and random-access memory (RAM)25. A basic input/output system (BIOS) program26, containing the basic routines that help to transfer information between elements within the computer20, such as during start-up, may be stored in ROM24. The computer20further includes a hard disk drive27for reading from and writing to a hard disk, not shown, a magnetic disk drive28for reading from or writing to a removable magnetic disk29, and an optical disk drive30for reading from or writing to a removable optical disk31such as a CD ROM or other optical media.

The hard disk drive27, magnetic disk drive28, and optical disk drive30couple with a hard disk drive interface32, a magnetic disk drive interface33, and an optical disk drive interface34, respectively. The drives and their associated computer-readable media provide non volatile storage of computer-readable instructions, data structures, program modules and other data for the computer20. It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), redundant arrays of independent disks (e.g., RAID storage devices) and the like, can be used in the exemplary operating environment.

A plurality of program modules can be stored on the hard disk27, magnetic disk29, optical disk31, ROM24, or RAM25, including an operating system35, one or more application programs36, other program modules37, and program data38. For example, a cryptography key management system may be implemented as one or more program modules. For example, the one or more application programs36can include programs for the cryptography key management for a client mobile device as described with reference toFIG. 1.

A user may enter commands and information into computer20through input devices such as a keyboard40and pointing device42. Other input devices (not shown) can include a microphone, joystick, game pad, satellite dish, scanner, or the like. These other input devices are often connected to the processing unit21through a serial port interface46that is coupled to the system bus23, but can be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB). A monitor47or other type of display device can also be connected to the system bus23via an interface, such as a video adapter48. The monitor47can display a graphical user interface for the user. In addition to the monitor47, computers typically include other peripheral output devices (not shown), such as speakers and printers.

The computer20may operate in a networked environment using logical connections to one or more remote computers or servers, such as remote computer49. These logical connections are achieved by a communication device coupled to or a part of the computer20; the invention is not limited to a particular type of communications device. The remote computer49can be another computer, a server, a router, a network PC, a client, a peer device or a common network node, and typically includes many or all of the elements described above relative to the computer20, although only a memory storage device50has been illustrated. The logical connections depicted inFIG. 8include a local area network (LAN)51and/or a wide area network (WAN)52. Such networking environments are commonplace in office networks, enterprise-wide computer networks, intranets and the internet, which are all types of networks.

When used in a LAN-networking environment, the computer20is connected to the LAN51through a network interface or adapter53, which is one type of communications device. In some embodiments, when used in a WAN-networking environment, the computer20typically includes a modem54(another type of communications device) or any other type of communications device, e.g., a wireless transceiver, for establishing communications over the wide-area network52, such as the internet. The modem54, which may be internal or external, is connected to the system bus23via the serial port interface46. In a networked environment, program modules depicted relative to the computer20can be stored in the remote memory storage device50of remote computer, or server49. It is appreciated that the network connections shown are exemplary and other means of, and communications devices for, establishing a communications link between the computers may be used including hybrid fiber-coax connections, T1-T3 lines, DSL's, OC-3 and/or OC-12, TCP/IP, microwave, wireless application protocol, and any other electronic media through any suitable switches, routers, outlets and power lines, which are known and understood by one of ordinary skill in the art.

In the foregoing detailed description of embodiments of the invention, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description of embodiments of the invention, with each claim standing on its own as a separate embodiment. It is understood that the above description is intended to be illustrative, and not restrictive. It is intended to cover all alternatives, modifications and equivalents as may be included within the spirit and scope of the invention as defined in the appended claims. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” and “third,” etc., are used merely as labels, and are not intended to impose numerical requirements on their objects.

The above-described technique provides various embodiments for authenticating a mobile device in an enterprise cryptography key management system. It is to be understood that the above-description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above-description. The scope of the subject matter should, therefore, be determined with reference to the following claims, along with the full scope of equivalents to which such claims are entitled.

As shown herein, the present subject matter can be implemented in a number of different embodiments, including various methods, a circuit, an I/O device, a system, and an article comprising a machine-accessible medium having associated instructions.

Other embodiments will be readily apparent to those of ordinary skill in the art. The elements, algorithms, and sequence of operations can all be varied to suit particular requirements. The operations described-above with respect to the method illustrated inFIG. 1can be performed in a different order from those shown and described herein.

FIGS. 1 & 2are merely representational and are not drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized.FIGS. 1 & 2illustrate various embodiments of the subject matter that can be understood and appropriately carried out by those of ordinary skill in the art.