US20030021417A1 - Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data - Google Patents

Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data Download PDF

Info

Publication number
US20030021417A1
US20030021417A1 US10/146,782 US14678202A US2003021417A1 US 20030021417 A1 US20030021417 A1 US 20030021417A1 US 14678202 A US14678202 A US 14678202A US 2003021417 A1 US2003021417 A1 US 2003021417A1
Authority
US
United States
Prior art keywords
key
cryptographic
encrypted
information
remote
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US10/146,782
Inventor
Ognjen Vasic
Suhail Ansari
Ping Gan
Jinhui Hu
Bassam Khulusi
Adam Madoukh
Alexander Tyshlek
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Central Valley Administrators
Farrukh Abdallah Dr
ERUCES Inc
Original Assignee
ERUCES 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
Priority claimed from US09/693,605 external-priority patent/US7362868B2/en
Priority to US10/146,782 priority Critical patent/US20030021417A1/en
Application filed by ERUCES Inc filed Critical ERUCES Inc
Assigned to ERUCES, INC. reassignment ERUCES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MADOUKH, ADAM A., ANSARI, SUHAIL, GAN, PING, HU, JINHUI, KHULUSI, BASSAM, VASIC, OGNJEN
Assigned to ERUCES, INC. reassignment ERUCES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: TYSHLEK, ALEXANDER
Publication of US20030021417A1 publication Critical patent/US20030021417A1/en
Priority to PCT/US2003/015569 priority patent/WO2003098864A1/en
Priority to EP03728985A priority patent/EP1510030A4/en
Priority to AU2003233549A priority patent/AU2003233549A1/en
Priority to CNA03816860XA priority patent/CN1669265A/en
Priority to US11/931,116 priority patent/US7885413B2/en
Assigned to GINN, GREGORY WAYNE reassignment GINN, GREGORY WAYNE COURT TURNOVER ORDER Assignors: ERUCES, INC.
Assigned to CENTRAL VALLEY ADMINISTRATORS, FARRUKH, ABDALLAH, DR. reassignment CENTRAL VALLEY ADMINISTRATORS ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GINN, GREGORY
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245Protecting personal data, e.g. for financial or medical purposes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897Escrow, 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3226Cryptographic 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 a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231Biological data, e.g. fingerprint, voice or retina
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3263Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3271Cryptographic 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101Auditing as a secondary aspect
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115Third party
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151Time stamp
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153Using hardware token as a secondary aspect
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • a leased line is a dedicated point-to-point connection over the telephone network that is used for, among other things, routing regular telephone calls.
  • leased lines are used to provide private network connections between regional offices and corporate headquarters, carrying only information that is intended to be sent between the regional office and the headquarters.
  • a leased line may also be used to connect an organization to an Internet Service Provider (ISP).
  • ISP Internet Service Provider
  • the ISP connects its customer to a public network, such as the Internet.
  • a customer With a connection to a public network, a customer may send and receive messages to any other party also connected to the public network.
  • This has advantages of convenience and low cost relative to dedicated, private leased lines, because only a single connection to the ISP must be maintained.
  • a network user has much less control over information sent and received over a public network than a user has over data sent on a private leased line.
  • operators of networking equipment that routes information between an arbitrary sender and receiver may intercept the information and examine it or even modify it en route.
  • senders and receivers have no convenient way to police the behavior of intermediate network providers.
  • VPN Virtual Private Network
  • IP Internet Protocol
  • Firewalls filter or restrict the types of packets allowed to pass between external public networks and internal networks.
  • firewalls must allow the exchange of at least some packets to and from a public network in order for the connection to the public network to be of any value.
  • System level security layers include the pieces of software that require user names and passwords to allow connections and the like.
  • a common technique of attackers to gain unauthorized access is to exploit known defects in operating system security layers. These defects are ordinarily caused by human errors in the design and implementation of the system software. Accordingly, as fixes for the defects become available it is imperative to apply the fixes or patches. Monitoring and timely applying fixes and patches is an important aspect of sound system administration. If patches are not applied, intruders can easily gain access to end nodes.
  • SSL Secure Sockets Layer
  • SSH Secure Shell
  • Cryptography involves using codes and transformations on messages to render the messages unintelligible to anyone other than an intended recipient of the message.
  • the process of rendering a message unintelligible is called encryption
  • the process of unscrambling a message by an intended recipient to render the message intelligible is called decryption.
  • additional information other than the message itself is used to decrypt an encrypted message. Since encrypting is like locking a message and decrypting like unlocking it for the intended recipient, the information used for encrypting or decrypting is frequently called a key.
  • a message digest is frequently the output of a one-way hash function such as MD5 or SHA-1, which irreversibly produce fixed length output digests from messages of an arbitrary length.
  • MD5 or SHA-1 a one-way hash function
  • a receiver can re-calculate the message digest on the received message and verify the signature. By verifying the signature and comparing the calculated message digest to the signed message digest, the receiver verifies that he or she has received, unaltered, the same message originally signed by the sender.
  • HMAC Keyed-Hashing for Message Authentication
  • HMACs are mechanisms that can authenticate both the source of a message and its integrity.
  • HMACs utilize an arbitrary one-way hash function, such as MD5 or SHA-1 in connection with a shared secret, or key, to provide a message authentication code.
  • HMACs can also be used in connection with challenge response protocols in which a response is computed that is a function of the secret key and the challenge message.
  • Authenticity of information is verified when the receiver performs the HMAC calculation on the received message and compares it to the message authentication code sent in connection with the message. The receiver further can verify that the message originated from a source that was in possession of the secret key.
  • HMAC is further described in RFC 2104.
  • a key can be a number used in a formula to operate on a message to either encrypt or decrypt the message.
  • Other types of keys include one time pads, which are lists of keys that are applied to messages to encrypt and decrypt them, in which each element of the list of keys is used only once.
  • keys must be exchanged between parties to encrypted communication in a secure manner.
  • One inconvenient way to do this is by way of a trusted courier that physically delivers keys to parties in a locked briefcase thereby ensuring actual security by way of verifiable physical security.
  • physical courier methods of key exchange are generally too cumbersome, slow, and expensive.
  • a popular method for exchanging keys is to use public key cryptography to exchange a symmetric key.
  • Public key cryptography uses two kinds of keys to encrypt and decrypt information, namely public keys, which are intended to be widely distributed and associated with particular entities, and private keys, which are intended to be kept in a highly confidential and secure manner.
  • symmetric cryptography uses the same key to encrypt and to decrypt information.
  • Public key cryptography works by encrypting a message in a public key. Once encrypted in a public key, a message can only be decrypted using the corresponding private key.
  • a signer may create a digital signature by applying his or her private key to a message or typically to a digest of a message, which is a fixed-length piece of information that uniquely identifies the message. A digital signature is verified by applying the purported signer's public key to the signature to determine whether the signature is valid.
  • a simplified use of public key cryptography to exchange a symmetric key is accomplished in the following way.
  • One party generates a new symmetric key, for example using a random number generator.
  • the party encrypts the symmetric key using the public key of the intended recipient and sends the encrypted message to the intended recipient.
  • the recipient uses his or her private key to decrypt the message, thereby securely receiving the symmetric key which can be used to secure a channel for further communication.
  • An important concern in any application of public key cryptography is that a user of a public key cryptosystem (e.g. a sender of an encrypted message) uses authentic public keys of other parties. If a sender mistakenly uses the public key of an attacker, the attacker will be able to decrypt the message and will have the symmetric key allowing the attacker access to the secure channel. Further, if the attacker is able to inject himself or herself into the channel in this way, the attacker can forge messages to the recipient and mount a so called “man-in-the-middle” attack, in which both sender and receiver believe they are communicating directly over a secure channel but in reality are communicating through an attacker who has the ability to examine and alter messages as they pass between sender and recipient. Accordingly, the effective use of public key cryptography requires users to be able to verify that a particular public key is the true public key of the person to whom they wish to communicate. Ensuring that a public key is the correct public key is the problem of public key validation.
  • One way to solve the public key validation problem is to publish the public key in a major newspaper and for users of the public key to manually compare the public key they are using to the published numbers. This system is quite effective and occasionally used in practice. It is, however, somewhat inconvenient and not conveniently subject to automation. Other public key validation procedures have been employed. In a “ring of trust” environment, such as that used in the Pretty Good Privacy (PGP)TM system a user may manually input or automatically import public keys coming from a trusted source.
  • PGP Pretty Good Privacy
  • Another solution to verification of public keys is the digital certificate, in which a public key is digitally signed, and according to which users of a public key cryptosystem can verify the authenticity of a certificate, and its corresponding public key, by validating a the digital signature on the certificate. The signature is validated using a preestablished, trusted public key of a Certification Authority (CA).
  • CA Certification Authority
  • the SSL protocol uses digital certificates.
  • a web server has an X.509-formatted digital certificate, which is digitally signed by a trusted CA, using the CA's private key.
  • the CA's signature can be verified at the client using a trusted version of the CA's public key.
  • public keys of popular CA's come pre-loaded into the browser.
  • SSH requires an initial trusted exchange of a server's public key so that in subsequent transactions, the identity of the server can be verified by the user using conventional public key technology.
  • VPNs and channel protectors such as SSH and SSL protect data as it is exchanged from a secure node to another secure node over a potentially insecure network.
  • channel protectors protect data in transit only.
  • Channel protection technology cannot protect data once it has been decrypted on a destination node.
  • firewall and sound system administration technology have proven not to be entirely effective in keeping intruders from gaining unauthorized access to network-connected computer systems.
  • highly publicized assaults have been successful in quickly stealing thousands of credit card numbers and other confidential information from various web sites, for example.
  • an organization attempts to protect fixed encryption keys and other sensitive data by locating its servers in a physically secure room equipped with locked doors and surveillance cameras.
  • remote intruders do not need physical access to server rooms in order to access data stored on a company's server. Intruders merely need some form of remote access to the company's network. Even with the use of firewalls, this access can be gained through known exploits, incorporating techniques including for example, IP spoofing, in which an intruder forges packets to have false IP source addresses. Other techniques include network scanning which helps to identify systems having exploitable defects.
  • an intruder has essentially full access the organization's information, including, for example, credit card numbers, identifiable medical records, and other sensitive confidential information about the organization's patients, customers, and/or employees.
  • Other examples of confidential information that can be obtained by unauthorized access include credit card numbers, bank account numbers, social security numbers, birth dates, and highly personal and private medical records.
  • a computer system contains cryptographic keys and cryptographic key identifiers.
  • the system has a repository cryptographic engine that communicates securely with a remote cryptographic engine, and the repository cryptographic engine is associated with a user data store.
  • the data store includes a hidden link including a session key identifier encrypted with a protection key.
  • the hidden link is associated with a remote data entity.
  • An associated key data store includes a session key encrypted with a session-key-protection key.
  • the session key is used to encrypt and decrypt the remote data entity.
  • the system also includes a repository key exchange module operable to exchange the session key with a remote key exchange module.
  • the session key identifier is optionally operable to identify the session key corresponding to the remote data entity.
  • the computer system optionally also includes an authorization module that controls access to operations.
  • the authorization module is optionally further coupled with a user data store and access to the session key is further provided based on the user data store.
  • the protection key is a preferably a symmetric cryptographic key.
  • the session-key-protection key is a symmetric cryptographic key.
  • the session-key-protection key and the protection key are equivalent.
  • the symmetric cryptographic key is optionally the triple Data Encryption Standard or the Advanced Encryption Standard.
  • a distributed network including a repository server containing cryptographic keys.
  • the network includes a repository cryptographic engine operable to communicate securely with a remote cryptographic engine.
  • the network also includes a remote cryptographic agent operable to communicate securely with the remote cryptographic engine.
  • the network includes a business application coupled with the remote cryptographic agent, wherein authenticity of the business application is verified by the remote cryptographic engine by comparing a stored fingerprint of the business application with a calculated fingerprint of the remote cryptographic agent.
  • a cryptographic method for facilitating the secure storage of information.
  • a key request is received for a session key from a requesting key exchange module at a remote computer system.
  • the key request includes a hidden link.
  • the session key is accessed and encrypted based on the hidden link using a protection key.
  • an exchange public key is received corresponding to the requesting key exchange module.
  • the session key is encrypted in the exchange public key, resulting in an encrypted session key.
  • the encrypted session key is transmitted to the requesting key exchange module.
  • the encrypted session key is received with an exchange private key corresponding to the exchange public key.
  • a data entity is encrypted with the session key, and the hidden link is attached to the data entity. Further, the data entity is stored.
  • FIG. 1 is a schematic diagram of a computer system implementing a hidden link dynamic key manager according to the present invention
  • FIG. 2 is a schematic block diagram of the computer system of FIG. 1 illustrating software components of the computer system
  • FIG. 3 is a schematic diagram of the database structure according to the present invention and utilized by the computer system of FIG. 1;
  • FIG. 4 is a schematic diagram of a security key identification attribute of the database structure of FIG. 4;
  • FIG. 5 is a schematic diagram of a monitor illustrating adaptable display parameters according to the present invention and having only public information and fields displayed;
  • FIG. 6 is a schematic diagram of a monitor illustrating the adaptable display parameters according to the present invention and having both public and private information and fields displayed;
  • FIG. 7 is a schematic block diagram illustrating the steps for determining how to adapt the display parameters illustrated in FIGS. 5 and 6;
  • FIG. 8 is a schematic diagram of a session encryption key data entity
  • FIG. 9 is a schematic diagram of a system key common name data entity
  • FIG. 10 is a schematic block diagram illustrating the encryption and storage of data entities during an add transaction
  • FIG. 11 is a schematic block diagram illustrating the retrieval and decryption of data entities during update and view transactions
  • FIG. 12 is a schematic block diagram illustrating an alternate embodiment for the retrieval and decryption of data entities during update and view transactions
  • FIG. 13 is a schematic block diagram illustrating the deactivation of session encryption keys
  • FIG. 14 is a schematic block diagram illustrating an alternate embodiment for the deactivation of session encryption keys
  • FIG. 15 is a schematic block diagram illustrating a system in which database protection is provided consistent with the present invention.
  • FIG. 16 is a schematic block diagram illustrating a system in which remote computer systems access a key repository over a network
  • FIG. 17 is a schematic block diagram illustrating a system involving a file server, a repository server, and remote computer systems;
  • FIG. 18A is a schematic block diagram illustrating intradepartmental data protection consistent with the present invention.
  • FIG. 18B is a schematic block diagram illustrating interdepartmental data protection consistent with the present invention.
  • FIG. 18C is a schematic block diagram illustrating data protection in connection with an Intranet or extranet based key repository
  • FIG. 18D is a schematic block diagram illustrating mobile data protection
  • FIG. 18E is a schematic block diagram illustrating data protection in a multiple enterprise environment
  • FIG. 19 is a schematic block diagram illustrating an embodiment of tables corresponding to key, access control, and user databases
  • FIG. 20 is a schematic block diagram illustrating a process of encrypting a file consistent with the present invention
  • FIG. 21 is a schematic block diagram illustrating a process of maintaining an access control list
  • FIG. 22 is a schematic block diagram illustrating a process of accessing an encrypted file
  • FIG. 23 is a schematic block diagram illustrating a process of blocking access associated with a key in response to the key becoming compromised
  • FIG. 24 is a schematic block diagram illustrating a system in which trusted components are authenticated
  • FIG. 25 is a schematic block diagram illustrating a process of creating smart cards
  • FIG. 26 is a schematic block diagram illustrating a process of registering components
  • FIG. 27 is a schematic block diagram illustrating a process of performing run-time authentication of components.
  • FIGS. 1 and 2 show a computer system 20 constructed in accordance with a preferred embodiment of the present invention for storing information.
  • the present invention provides an improved method of encrypting and decrypting data preferably at rest, which is to say in its native form, for example in a file system or in a data base server.
  • the computer system 20 broadly includes a security domain 22 having an encryption key manager (EKM) 24 , system key manager (SKM) 84 , key lifetime manager (KLM) 88 , key auditing manager (KAM) 90 and database adapter (DBAD) 86 .
  • EKM encryption key manager
  • KLM key lifetime manager
  • KAM key auditing manager
  • DBAD database adapter
  • other enterprise security components are included in security domain 22 .
  • the computer system 20 also includes a plurality of client business domains 26 having an information database 28 .
  • the computer system 20 implements a method according to the present invention.
  • the method broadly includes encryption, decryption and storage of data entities 30 (FIG. 3) as illustrated in the flow diagram of FIG. 10, and the method also includes the retrieval and decryption of data for data manipulation.
  • One embodiment of the retrieval and decryption method is illustrated in the flow diagram of FIG. 11.
  • the computer system 20 utilizes a data structure illustrated in FIG. 3.
  • the data structure broadly includes a plurality of data entities 30 having a security key identification attribute 32 , which contains security key information as illustrated in FIG. 4.
  • the computer system in addition to the security domain 22 and the client business domains 26 , the computer system also includes a plurality of client terminals 34 .
  • the client terminals 34 are provided with telecommunications capabilities to communicate with the business domain 26 ,
  • the invention also contemplates the use of alternative communication mechanisms, such as Intranet, local area networks (LAN), and wide area networks (WAN), for example.
  • the Intranet, LAN, and WAN applications may be utilized for any type of facility or organization where data security is important such as a bank, hospital, or law firm, for example.
  • the client terminals 34 gain access to the client business domains 26 only after passing through security devices such as firewalls, and communication between the client business domain 26 and the security domain 22 preferably occurs through an Internet protocol secure, virtual private network tunnel (IPSEC, VPN tunnel) 38 .
  • IPSEC virtual private network tunnel
  • the security domain 22 includes a primary key server 40 , a secondary key server 42 , a security key database (KEYDB) 44 , and a certification authority server 46 .
  • Each of the key servers is a general purpose computer having various components including, for example, one or more processors, fast main memory, and persistent storage.
  • the certificate server 46 also is a general purpose computer.
  • the primary key server 40 and secondary key server 42 are mirror components. Thus, the primary and secondary key servers are substantially identical. If the primary key server 40 fails, the secondary key server 42 begins operation immediately without disruption in overall system operation, thereby providing fault tolerance. The transfer in operation is accomplished, for example, through a heart beat failover channel between the primary and secondary servers 40 , 42 .
  • the primary and secondary servers 40 , 42 each optionally include a tape backup 48 , 50 , respectively, for key retrieval in the event that the KEYDB 44 is irretrievable or a key integrity check fails.
  • the primary server 40 is provided with a primary system key reader 52 , designated reader #1 in the drawing, and a primary encryption key reader 54 , designated reader #2 in the drawing.
  • each of the primary readers 52 , 54 for the primary server 40 store the same information.
  • the primary readers 52 , 54 are mirrored hardware components for superior fault tolerance.
  • the secondary database 42 also includes a secondary system key reader 56 , designated reader #1 in the drawing, and a secondary encryption key reader 58 , designated reader #2 in the drawing.
  • each of the secondary readers 56 , 58 for the secondary server 42 store the same information.
  • the secondary readers 56 , 58 are also mirrored, and there are a total of four readers from which key information can be retrieved.
  • the readers 52 - 58 comprise security token readers for receiving security tokens.
  • the readers comprise Smart Card readers for receiving smart cards.
  • a hardware random number generator (HRNG) 59 is also optionally provided in the security domain to generate random numbers, which are used as identifiers for keys.
  • the key servers 40 and 42 contain multiple protection keys that are used to encrypt and decrypt session keys and session key identifiers.
  • the protection keys are themselves stored in a protection store, for example an ASCII flat file, and encrypted in a master key.
  • the master key can be provided based on a K of M paradigm, under which there are M, for example seven, separate sub-keys that are held by, for example, seven different people.
  • M for example seven
  • a number K for example three of the seven people must provide their sub-keys.
  • a weighted K of M scheme is employed, under which some of the M sub-keys are weighted higher than others.
  • a company's CEO can be provided with a sub-key having sufficient weight to unlock the protection store by itself, while subordinates have sub-keys with lower weights based on the subordinate's level of responsibility.
  • KEYDB 44 comprises an external disk array with a fault tolerance system for mirrored operation.
  • the KEYDB 44 is a relational database platform, such as MicrosoftTM SQL Server, OracleTM, DB2TM, mySQLTM, PostgreSQLTM, or Jet EngineTM.
  • the external disk array or database server optionally includes a redundant array of independent disks (RAID).
  • Each of the key servers 40 , 42 is operable to communicate with the KEYDB 44 .
  • the key servers communicates with the database server KEYDB 44 using ADO, ODBC, or a native database interface, such as the interface provided in connection with the OracleTM database server.
  • the client business domains 26 preferably include a plurality of application servers 60 , 61 and a primary information database 62 , which is isolated from the KEYDB 44 , and which is a database platform such as the platforms enumerated in connection with KEYDB 44 or alternatively InterSystems CachéTM
  • a backup information database 64 is also provided.
  • the backup information database 64 mirrors information in the primary information data 62 providing redundancy and protection against data loss.
  • the client business domains 26 are provided with superior fault tolerance.
  • the client business domain servers 60 , 61 are only accessible through a firewall 66 .
  • Each application server 60 , 61 may contain multiple business logic components such as business logic component number one (BLC1) 68 .
  • the BLC's contain instructions and rules for operation of the computer system 20 that are set by users and/or the developers of the users' software applications.
  • each client terminal 34 includes a central processing unit (CPU) 70 , a data entry mechanism, such as a keyboard 72 , and a display or monitor 74 .
  • the CPU 70 is operable to control the monitor 74 , receive input from the keyboard 72 , and establish and maintain communications through the Internet 36 utilizing a modem, two-way satellite, digital subscriber line (DSL), or other communication apparatus (not shown), such as an Ethernet adapter.
  • the CPU 70 is also operable to control other computer system devices such as a printer or disc drives.
  • each client terminal is also equipped with a user security token reader for receiving a security token.
  • the security token reader comprises a Smart Card reader 78 for receiving a Smart Card 80 .
  • the Smart Card is optionally provided with a private and secured file system.
  • Each user is optionally provided with his or her own Smart Card 80 , which includes a cryptographic for identifying and authenticating the user.
  • Other known solutions such as user identification and password, can be used to control access and user authentication.
  • users have one or more roles for authorization.
  • the role identifications can include assistant level, receptionist level, administrative level, and others.
  • the role identifications represent the duties performed by individuals in those levels and the extent of information needed for them to properly perform those duties. The user and role identifications are used as described below in connection with FIG. 7 to limit access to information.
  • the security domain 22 of the computer system 20 includes several software components that are resident on the hardware components illustrated in FIG. 1.
  • the primary and secondary key servers 40 , 42 include substantially the same software components and both will be described with reference to the primary key server 40 .
  • the primary key server 40 includes several software components: a general security manager (GSM) 82 , the encryption key manager (EKM) 24 , a system key manager (SKM) 84 , a database adapter (DBAD) 86 , a key lifetime manager (KLM) 88 , and a key auditing manager (KAM) 90 .
  • GSM general security manager
  • EKM encryption key manager
  • SKM system key manager
  • DBAD database adapter
  • KLM key lifetime manager
  • KAM key auditing manager
  • a certificate manager (CM) 92 is provided on the private certificate authority (CA) server 46 .
  • the general security manager (GSM) 82 operates as a gateway to the portions of the computer system 20 located in the security domain 22 .
  • each of the security domain 22 components EKM 24 , SKM 84 , DBAD 86 , KLM 88 , KAM 90 , CM 92 are preferably not operable to communicate directly with any component outside the security domain 22 of the computer system 20 . In one embodiment, they are only operable to communicate with outside components through the GSM 82 .
  • component mutual authentication occurs between the GSM 82 , which is located in the security domain, and the outside business domain components 68 .
  • COM+, CORBA, or Java security can be used to control the mutual authentication.
  • neither the client user nor any component in the client business domain 26 can contact anything other than the GSM 82 through trusted authentication process.
  • the GSM 82 is also operable to encrypt the data entities 30 (FIG. 3) using, for example, a three-key, triple data encryption standard (3DES), RC4, or any strong cryptographic algorithm on selected attributes of the data entities 30 C, 30 D as directed and requested by the BLC's and other components of the computer system 20 .
  • DES triple data encryption standard
  • the GSM preferably uses three-key 3DES, which is a symmetric 168-bit cryptosystem, having an effective key strength of about 110 bits.
  • Other strong cryptographic algorithms can be employed, such as 128-bit IDEA or AES. Using keys with extended lengths makes the keys more difficult to break than the 56-bit DES keys, which have been experimentally broken using parallel processing systems.
  • the GSM 82 also performs the decryption of the data entities 30 when other components of the computer system 20 request decryption. Further, the GSM 82 is operable to perform hashing operations using message digest 5 (MD5), SHA-1, or other strong hashing algorithms as instructed by other components.
  • MD5 message digest 5
  • the hash values or integrity values generated in the one way hashing process are typically stored as attributes in data entities for integrity check purposes.
  • the GSM 82 hashes all of the data attributes of the data entities and stores that data hash value as an attribute. After the data has been decrypted, it is again hashed and the before and after hash values are compared. If the two hash values are identical, the integrity of the data in the data entity has been confirmed. If two hash values are different, an alarm is issued and the data is retrieved from the backup information database 64 .
  • the encryption key manager (EKM) 24 generally manages encryption keys, which as described below are used to encrypt and decrypt the data entities 30 C, 30 D.
  • the EKM 24 is operable to generate multiple session encryption keys (SEK) for example either 3DES or AES and generate session encryption key identifications (SEKID's) for the SEK's.
  • SEKIDs are random numbers optionally generated with the HRNG 59 (Hardware Random Number Generator). Alternatively, SEKIDs are generated using a software random number generator.
  • the EKM is operable to perform integrity checks on the SEKs using hash values for the SEKs.
  • the EKM is further operable to transmit the SEKID to the SKM 84 for encryption, and the EKM 24 is also operable to transmit the SEK and corresponding SEKID, in encrypted form, to the GSM 82 , which then encrypts the data entities 30 C, 30 D using the SEK.
  • the system key manager (SKM) 84 generally manages system keys, which as described below are used to encrypt the SEKIDs.
  • the SKM 84 is operable to encrypt the SEKIDs.
  • a number of protection keys are used to encrypt SEKs and SEKIDs. It is understood that the number of protection keys used is an operator selectable parameter. In one embodiment, about 20 protection keys are used. In another embodiment, more than about 1,000 protection keys are used.
  • the protection keys are optionally 3DES or AES keys and pointers to protection keys are stored in connection with SEKs.
  • hidden links, which are transmitted in connection with encrypted data contain several data structures, including a pointer to a protection key, and a cryptographic engine identifier that uniquely corresponds to the cryptographic engine that generated the SEKID.
  • separate encryption keys are used to encrypt the SEK and the SEKID.
  • an encryption key public key is used to encrypt the encryption keys that are used to encrypt the SEKs.
  • a system key public key is used to encrypt symmetric keys that are used to encrypt the SEKIDs.
  • the SKM also generates a system key common name (SKCN) for the asymmertical encryption key pairs and system key pairs.
  • SKCN's are generated when generating the system public key's digital certificates, so that there is a unique SKCN for each system key pair.
  • the SEKID is encrypted in a symmetric key that is encrypted in the system key public key.
  • SEKIDs are encrypted in the same symetric key, called a protection key, as the SEKs.
  • the SKM 84 Upon request from the EKM 24 , the SKM 84 is also operable to decrypt the SEKID using the appropriate key. If desired, the SKM 84 and EKM 24 can be combined into a single component and can reside on the same server or computer system.
  • the Microsoft Crypto API application program interface
  • OpenSSLTM is used to perform cryptographic functions.
  • the key lifetime manager (KLM) 88 monitors the lifetime of the SEK's based on corresponding expiration dates and timestamps. In this embodiment, the KLM 88 flags the expired SEK's with an expiration flag, so that in the next request, the EKM will optionally check the expiration status of the SEK and replace the expired key with a new one during run-time operation.
  • a particular SEK is used in connection with a particular data object.
  • an application can save a data entity with the same SEK by resubmitting a hidden link in connection with a request to store the data entity.
  • a hidden link is a data structure including the encrypted SEKID, a pointer to the protection key used to encrypt the SEKID, and a cryptographic engine identifier.
  • the application can cause the generation of a new SEK by transmitting a save data request without including a hidden link.
  • the KLM 88 sets a key expiration flag in connection with the SEK so that an application can be alerted that it is an appropriate time to cause a new SEK to be generated.
  • the key auditing manager (KAM) 90 is operable to maintain an active audit log including all transactions involving the SEKs and the keys used to encrypt the SEKs. Generally, the KAM 90 monitors the log for alarm events utilizing smart patterns, rules, and policies. The KAM 90 is also operable to provide notification upon the occurrence of an alarm event, such as if a system key or SEK has been compromised.
  • operator selectable thresholds for numbers of new key generations are configurable. In this embodiment, an operator can observe the cryptograpic system under normal operation, noting a typical number of new keys that are generated over a particular period and set the thresholds accordingly. Once configured, if a threshold is exceeded a notification is sent regarding the exceeded threshold.
  • the certificate manager (CM) 92 is operable to perform all of the system key PKI related operations. For each system key the CM 92 generates a X.509 digital certificate. Preferably, the digital certificate includes a critical V3 extension, so that only the private certificate authority (CA) can verify the key. Each time a request for decryption by a system key is received by the SKM 84 , the CM communicates with the private certificate authority (CA), which is local to the security domain, to verify the system key.
  • CA private certificate authority
  • the database adapter (DBAD) 86 is operable to hide database specific application programming interfaces (API) from the security domain 22 components and thereby controls and enhances communications between the key managers 24 , 84 and the secured key database 44 .
  • API application programming interfaces
  • the DBAD 86 also allows the security domain components to interface with multiple databases within the security domain 22 , such as Microsoft SQLServer, Sybase, Informix, Oracle, and IBM DB2. It is understood that known databases employ database fault tolerance. While the preferred operations and locations of the respective components has been described in detail, it is understood that specific tasks can be exchanged between components and the locations of components can be combined, separated, or exchanged without departing from the spirit of the invention.
  • the database structure preferably comprises an object oriented database structure having a plurality of data entities 30 , which are preferably data objects.
  • data entities 30 which are preferably data objects.
  • a relational database could be used, such as Microsoft SQLServer, Oracle, Sybase, Informix and IBM DB2.
  • Microsoft SQLServer Oracle
  • Sybase Sybase
  • Informix IBM DB2
  • IBM DB2 IBM DB2
  • the data entity 30 A includes an Added attribute 100 and an Added By attribute 102 .
  • the Added attribute 100 records a timestamp containing the date and time the object was added, and the Added By attribute 102 records the digital signature of the user adding the record or data entity.
  • the digital signature is obtained from the digital certificate of the client user's Smart Card 80 or client's current session and user identification.
  • the Modified and Modified By attributes, collectively 104 record the same information for modifications to the data entity 30 A. In combination, these non-repudiation attributes 100 , 102 , 104 inhibit a client user from claiming that the user did not take a certain action.
  • the security status (SecStatus) attribute 108 indicates whether the data object contains plain text or cipher text and whether it is public or private.
  • a security key identification attribute 32 is also an attribute of the data entity 30 A and contains security key information.
  • the security key information includes the encrypted SEKID 112 and the SKCN hash value 114 , which are used, as described below, to find the SEK used to encrypt associated data entities 30 C, 30 D and to find the system key used to encrypt the SEKID 112 . While it is preferred that the SKCN hash value is stored in the security key attribute 32 , the SKCN could be stored in this location without hashing.
  • the data entity 30 A also includes a security integrity attribute (SecIntegrity) 116 , which contains the data entity hash value.
  • the data entity hash value is obtained by hashing all or selective attributes within the data entity. This is controlled by business needs and policies, which are preferably determined by the client and recorded in the BLC's.
  • SHA-1 SHA-1
  • that data entity hash value is compared with the stored hash value in the security integrity attribute 116 . If the hash values are the same, then the integrity of the retrieved data entity is confirmed to be correct and not altered. If the hash values are not identical, then an alarm is issued, so that the data can be optionally manually confirmed, and as described above, retrieved from the backup information database 62 .
  • a security privacy attribute 118 controls access to the information in the associated data entities 30 C, 30 D.
  • a doctor for example, marks his information private, a special access list (SAL), data entity/class 30 B is automatically created and the doctor is automatically added to the special access list.
  • the doctor can thereafter add and delete user identifications attributes 120 and/or role identifications 122 from the special access list.
  • the user attributes 120 are based on specific user identifications from the smart cards or any other authentication method.
  • the role attributes 122 are based on different security levels of users. For example, the doctor may grant permission to view private data to other doctors but not permit nurses to view private data.
  • the roles can include any security level: secretary, shareholder, custodian, and administrative, for example. In this fashion, the doctor controls who can view what information and who can edit what information. The same holds true for patient records; where nurses and doctors may have full access, clerical staff may have limited access to name, address, payment, and appointment information.
  • This privacy can be applied to any vertical market such as banking, intellectual property systems, e-Commerce, law firms, and all applications that deal with highly sensitive or classified information.
  • the computer system retrieves the information at step 126 , which will be described in greater detail below. After the information is retrieved, the system checks the security privacy attribute 118 at step 128 . If the information is not marked private, it is fully displayed on the monitor 130 as illustrated in FIG. 6. If the information is marked private, the system checks the security level of the client user at step 132 . In checking the user's security level, the system looks at both the user identification and the role identification to see if either are in the special access list, and determine what rights, such as view only or edit, the user has to the information. If the client user has full view rights, then the display of FIG. 6 is again shown.
  • step 134 the display fields of the private information, which will not be displayed, are eliminated from the display parameters with their related labels, so that when the permitted information is displayed in step 135 on monitor 136 of FIG. 5, the fields for the private information are not displayed.
  • the fields for the public information may be modified, so that the existence of the private information is completely masked.
  • personal information 138 such as data of birth and number of children are displayed for the user having access to private information.
  • the date of birth and number of children fields are removed from the display of FIG. 5.
  • the home address information 140 and work address information 142 are displayed for the user with authorization to view private information, and the fields specifically indicate which address is for work and which address is for home.
  • the work address fields 144 in FIG. 5 are modified to eliminate the designation that it is a work address.
  • the persistent data entity 30 A also includes several association attributes, which are used by the database schema to associate or link related data entities 30 B, 30 C, 30 D to the persistent data entities 30 A.
  • the persistent object 30 A includes a class identification attribute 146 and at least two search attributes 148 .
  • the searchable attributes 148 are preferably hash values of user information such as the patient name.
  • the database uses these attributes 146 , 148 and others to associate related persistent objects 30 A and related class objects 30 B, 30 C, 30 D with the persistent objects containing the appropriate security key identification 32 that was used to encrypt data attributes in the class objects.
  • Two exemplary class objects are shown in FIG. 3: a person class object 30 C and a name class object 30 D.
  • Other unillustrated class objects/entities include an address entity, employer entity, payment entity, insurance entity, and others.
  • the database is also provided with look up maps or notes 150 .
  • the illustrated lookup map 150 is for gender of the person class. This saves database resources because every person in the database simply has a 0, 1, or 2 corresponding to undisclosed, male, or female, respectively. Thus, the look up map 150 saves database resources because each person class has a single digit integer instead of a lengthy word entry.
  • Look up maps are also preferably used for the security status attribute 108 , the security privacy attribute 118 , and others.
  • the data structure also includes an SEK object 151 saved in the KEKDB 44 and a SKCN object 152 , which is saved in either the KEKDB 44 or in an alternate embodiment, a separate system key database (not shown).
  • a separate system key database not shown.
  • public key pairs are stored in a hardware security module (HSM) device.
  • HSM hardware security module
  • the SEK object/entity includes as attributes the SEKID 153 in a normal/decrypted form, the encrypted SEK 154 , the SEK integrity check 155 , which is a hash value of the SEK, and the optional SKCN hash value 156 .
  • the SEK data entity 151 preferably does not include the encrypted SEKID. This creates a hidden link between the encrypted data and the SEK used to encrypt it because the SEKID is encrypted, and the SEK is stored in a separate database.
  • an HMAC is provided for data record integrity also stored in connection with each record in the key database.
  • the secret associated with the HMAC is contained in master security container, which is optionally protected with a K of M encryption scheme.
  • the SEK object also preferably includes a Created On attribute 159 , which records a time stamp for the creation of the SEK and optionally a Last Usage Date attribute 161 , which records a time stamp for the last time the SEK was used. Additionally, the SEK object optionally has a Usage Counter attribute 163 , which records how many times the SEK has been used.
  • the Created On 159 , Last Usage Date 161 , and Usage Counter 163 attributes provide the client with optional feature selections. Specifically, the client can select to have keys expired a certain number of months, two months for example, after their creation.
  • the client can also preferably decide to have SEK's expire when they have not been used for a selected period of time or when they have been used more than a selected number of times.
  • the client can also choose to have SEK's expired randomly or not at all.
  • the SKCN object/entity includes the SKCN hash value 157 and the SKCN 158 as attributes, and is preferably stored in a database separate from the data entities 30 .
  • FIG. 15 is a schematic block diagram illustrating a system in which database protection is provided consistent with the present invention.
  • Distributed application 1500 generally provides an interface to information in database server 1520 by way of application server 1510 .
  • Information at rest is protected in database server 1520 by way of SEKs provided by cryptography server 1530 .
  • SEKs provided by cryptography server 1530 .
  • the business application 1542 receives any necessary information from the database server 1520 .
  • Sensitive information in database store 1522 is encrypted. Accordingly, in order to use the encrypted information, the business application 1542 must decrypt the encrypted information.
  • the business application 1542 utilizes the cryptography server 1530 by providing the cryptographic agent 1544 with data to encrypt and to decrypt and with an optional hidden link that is stored with the encrypted information in the data store 1522 . Further, the requesting user provides authentication information to business application 1542 . In one embodiment, the authentication information is the requesting user's user identifier and password, with which a challenge response protocol is performed. In alternative embodiments, authentication information is based on biometrics or smart cards. It is understood that other user authentication mechanisms can be used without departing from the scope of the present invention.
  • business application 1542 In fulfilling requests from the requesting user, business application 1542 provides the user's authentication information to the cryptographic agent.
  • the cryptographic agent 1544 connects to a core engine associated with cryptography server 1530 over an optionally secure channel, for example an SSL link.
  • the cryptography server 1530 validates the user authentication information in connection with user database 1526 .
  • validation of user authentication information involves a challenge response protocol between the agent and the core engine in which the user's password is used to compute the response to the challenge.
  • a core engine 1554 receives information and instructions to perform operations, such as to encrypt data or decrypt data, from the business application 1542 .
  • the cryptography server 1530 optionally determines whether the user is authorized to perform the operations by querying access control list database 1524 . If the requesting user is authorized to perform an instruction associated with a particular session key, the core engine 1554 determines which protection key is associated with the requested session key and decrypts the session key with its protection key.
  • the business application 1510 needs to decrypt a block of information stored encrypted in the database server 1520 , the business application receives the block and its associated hidden link from the database server 1520 and provides the block and its associated hidden link to the cryptographic agent 1544 .
  • the cryptographic agent 1544 relays the encrypted block and the hidden link to the core engine 1554 .
  • the a core engine 1554 can determine whether the hidden link is was generated locally or whether it is from a foreign cryptography server (not shown) by examining the cryptographic server identifier associated with the hidden link. Further, the core engine can identify the protection key with which to decrypt the encrypted SEKID in the hidden link by examining the protection key pointer contained in the hidden link.
  • the core engine decrypts an encrypted SEKID and uses the decrypted SEKID to access the encrypted session key from a key database 1540 .
  • looking up the encrypted SEK is accomplished by querying an SEK table having SEKID as a primary relational database-key.
  • the core engine decrypts the encrypted SEK with a corresponding protection key.
  • the same protection key is used to encrypt the SEKID and the SEK. Accordingly, once the SEKID protection key is identified, it is available to be used to decrypt the SEK.
  • the core engine 1554 decrypts the information the business application 1542 provided from the database server 1520 and transmits the decrypted information back to the business application 1542 through the cryptographic agent 1544 .
  • communication is performed between the cryptographic agent 1544 and the core engine 1554 using an unencrypted TCP session.
  • communication is carried out using SSL without SSL client authentication.
  • communication between agent and core engine is performed using SSL with client authentication. It is understood that other methods of securing the channel between agent and core engine can be employed without departing from the scope of the invention, such as an unencrypted TCP session over an IPSec VPN.
  • the cryptographic agent facilitates encryption of the information before the business application provides the information to the database server. If the business application is storing new information or if the business application has determined that a new SEK should be generated, then the business application provides the unencrypted information without an associated hidden link.
  • the core engine receives data to encrypt without an associated hidden link, the core engine generates a new SEK and SEKID, encrypts the provided information and the SEKID, combining a protection-key pointer and core engine identifier to form a hidden link, and returns the encrypted information and the hidden link to the business application through the cryptographic agent. Further, the business application stores the encrypted information and the associated hidden link at the database server. When it becomes necessary to access the encrypted information, the encrypted information and the associated hidden link are provided to the core engine and the core engine decrypts the information for the business application if the user has sufficient rights.
  • the business application can elect not to generate a new key.
  • the business application provides information to be encrypted in connection with the existing hidden link.
  • the core engine receives information to be encrypted and an existing hidden link, the engine encrypts the provided information with the SEK corresponding to the existing hiddenlink.
  • the business application drives the process of generating new session keys for existing data.
  • FIG. 16 is a schematic block diagram illustrating a system 1600 in which remote computer systems access a key repository over a network.
  • a repository server 1620 that includes a repository core engine 1622 .
  • the repository core engine 1622 includes a key database 1640 having cryptographic keys contained within the key database 1640 .
  • the repository core engine 1622 provides the functions of key generation, storage, and retrieval.
  • the repository server 1620 includes an access control list (ACL) database 1624 and a user database 1626 .
  • the ACL database 1624 contains information regarding types of allowed access, or rights, particular users have to particular data entities associated with cryptographic keys stored in the key database 1640 .
  • the repository server 1620 also optionally has a smart card reader 1632 , which is operable to read information from a smart card such as the GEM-159 available from Gem Plus.
  • the repository server 1620 contains a repository key exchange module 1634 and an authentication/authorization (A/A) module 1636 .
  • the repository key exchange module 1634 enables two separate cryptographic engines to share keys.
  • the A/A module 1636 identifies and/or authenticates users by, for example, a challenge response protocol in connection with smart cards or user name/password combinations, associated with the users. Further, the A/A module provides user registration functions in connection with the ACL database 1624 , which contains information regarding particular users' rights with respect to specific keys.
  • a remote computer system 1610 connects to a key repository 1620 through a network 1630 .
  • the network 1630 is preferably a data network, such as the Internet, but it is understood that the network 1630 can be other types of networks, such as the telephone network, wireless networks, such as 802.11b, BluetoothTM or other wireless networks, local area networks, wide area networks, or optical fiber networks.
  • the computer system 1610 contains a smart card reader 1632 , which is operable to enable a user to authenticate himself or herself to the repository core engine 1620 .
  • the remote computer system 1610 contains a remote key exchange module 1630 , which is operable to exchange keys with the key exchange module 1634 of the key repository 1620 .
  • the remote computer system 1610 also contains a storeless remote core engine 1642 that is operable to perform remote encryption and decryption functions on the remote computer system 1610 .
  • a storeless remote engine has no internal key database and must communicate with a repository server to obtain keys to encrypt or decrypt data.
  • a business application 1612 is also preferably associated with the remote computer system 1610 .
  • the business application 1612 is generally software that consumes and produces information that is protected by cryptographic methods and systems consistent with the present invention.
  • FIG. 17 is a schematic block diagram illustrating a system 1700 involving a file server 1720 , a repository server 1620 , and a remote computer system 1610 in a group of remote computer systems.
  • the file server 1720 includes a data store 1722 , which contains information that is protected with cryptographic methods and systems consistent with the present invention.
  • the information contained in the data store 1722 is encrypted and decrypted in connection with the remote computer system 1610 , using the remote core engine 1642 , which performs the functions of encrypting and decrypting information using keys from the repository server 1620 , which optionally contains a smart card reader 1632 , a repository key exchange module 1634 , and an authentication/authorization (A/A) module 1636 .
  • A/A authentication/authorization
  • the repository server 1620 also contains a user database 1626 and an ACL database 1624 .
  • the remote computer system 1610 optionally uses a smart card reader 1632 and a remote key exchange module 1630 to authenticate with the A/A module 1636 of the repository server 1620 to obtain appropriate keys to encrypt and decrypt information in the media store 1620 .
  • the remote core engine 1622 performs encryption and decryption functions.
  • the process of adding a new user optionally involves generating exchange and signature key pairs for users.
  • the key pairs are written to a smart card.
  • the exchange key is used for transporting session keys between the repository server 1620 and the remote computer system 1610 .
  • the signature key is used to authenticate the user via the A/A module 1636 .
  • the public keys associated with the newly generated user key pairs are stored in the user database 1626 .
  • other information such as name and contact information for a user can be stored in the user database 1626 .
  • the user takes possession of the smart card containing the key pairs so the user can perform authentication and key exchange operations in connection with the use of encrypted information.
  • the user logs into the cryptographic system by authenticating to the A/A module 1636 of the repository server 1620 .
  • the user places his or her smart card into the smart card reader 1632 and the remote core engine 1642 reads the keys from the smart card.
  • the smart card is preferably password protected.
  • the remote core engine 1642 authenticates itself to the repository server 1620 by way of the A/A module 1636 .
  • the A/A module 1636 and the remote computer system 1610 execute a challenge response protocol in connection with the user's signature key pair.
  • the A/A module verifies a signature made by the remote computer system 1610 by using the public key stored in the user database 1626 that was generated at the same time as the user's private key, when the user account was created.
  • the remote computer system optionally receives a session-level access token, for example a large random number, in connection with the challenge response protocol.
  • a user authenticates using its user identifier and, for example, password.
  • user and agent rights are granted based on rights associated with a role that is assigned to the user or agent. Further, if the user or agent has sufficient rights, an ACL corresponding to a particular key is examined to determine whether the user or agent has sufficient rights to cause the key to be used to encrypt or decrypt data.
  • FIG. 18A is a schematic block diagram illustrating intradepartmental data protection consistent with the present invention.
  • the cryptographic engines are represented in connection with the TRICRYPTION trademark of ERUCES, Inc. of Lenexa, Kans.
  • the environment broadly includes a data store 1802 , computer systems 1804 and 1808 , and repository server 1806 .
  • the data store 1802 contains, for example, encrypted files that are manipulated by computer systems 1804 , 1808 .
  • the remote computer systems 1804 , 1808 read and write the encrypted data in data store 1802 in a manner similar to that explained in connection with FIG. 15. However, in this embodiment, encryption and decryption is performed on the same computer system that manipulates the information, namely systems 1804 , 1808 .
  • remote computer system 1804 uses its remote key exchange module to obtain keys from repository server 1806 as explained in connection with FIGS. 16 and 17. Specifically, the remote computer systems 1804 , 1808 manipulate the encrypted information in data store 1802 using session keys obtained from the repository server 1806 .
  • FIG. 18B is a schematic block diagram illustrating interdepartmental data protection consistent with the present invention.
  • information contained in the data store 1802 is accessed by remote computer systems 1804 , 1808 that are in separate departments or enterprises. Accordingly, user authentication and authorization information associated with a particular user of remote computer systems 1804 and 1808 resides in a corresponding repository server 1806 or 1807 in the user's department.
  • FIG. 18C is a schematic block diagram illustrating data protection in connection with an Intranet or extranet based key repository.
  • the repository server 1806 is separated from the remote computers 1804 and 1808 by a public network 1810 and optional firewalls 1812 . Because of the secure nature of the key exchange between repository server 1806 and remote computer systems 1804 and 1808 , exchanging keys over the public network is secure, and the keys can be used to manipulate the encrypted data in data store 1802 .
  • FIG. 18D is a schematic block diagram illustrating mobile data protection.
  • mobile computer 1816 is connected through wireless access point 1814 .
  • the mobile computer 1816 such as a personal digital assistant, contains a version of a storeless cryptographic engine that is capable of performing key exchange with repository server 1806 .
  • the mobile computer system 1816 can securely retrieve the encrypted data from data store 1802 over the public network 1810 through optional firewall 1812 because of the strong cryptography used to store the information in data store 1802 , and the mobile computer can securely receive session keys from repository server 1806 using key exchange methods described above.
  • FIG. 18E is a schematic block diagram illustrating data protection in a multiple enterprise environment.
  • information can be securely shared between enterprises over the public network 1810 .
  • Data store 1802 contains encrypted information that can be provided to internal users via application server 1820 and to users of peer enterprises through their application servers, for example application server 1830 .
  • Secure and granular sharing of information between enterprises over the public network 1810 , through optional firewalls 1812 is possible because of the secure key exchange between repository servers 1806 and 1816 that reside in different enterprises.
  • Trust is optionally established between the repository servers 1806 and 1816 by way of signed certificates from certification authority 1832 , such as VeriSign Inc. of Mountain View, Calif.
  • FIG. 19 is a schematic block diagram illustrating an embodiment of tables corresponding to key management, access control, and user databases.
  • a protection key information table 1902 has the primary key of protection key identifier (protectionkeyid).
  • the protection key information table 1902 contains the columns of “created,” which is a time stamp, “keyblob,” which is an encrypted binary representation of the protection key, and a signature which is, for example an HMAC data authenticator.
  • the “keyblob” field is encrypted in a master key that is protected at rest by a K of M encryption scheme.
  • An session key information table 1904 is also provided.
  • the session key information table has a primary key called “SEKID,” which corresponds to an unencrypted SEKID.
  • a core engine decrypts an SEKID from a hidden link, it can identify and decrypt “keyblob” from the session key information table 1904 .
  • the session key “keyblob” is preferably encrypted with the same protection key as the SEKID.
  • the “created” and “signature” fields are analogous to the “created” and “signature” fields described in connection with the protection key information table 1902 .
  • a principal information table 1906 has primary database keys of “principal” which corresponds to the name of a user, agent, or server that accesses a cryptographic system consistent with the present invention.
  • the “roles” field corresponds to the roles assigned to a particular principal.
  • the “flags” field corresponds to status indicators associated with the principal, e.g. disabled principal or non-disabled principal.
  • the “subclassname” field is used to indicate, for example whether the principal uses user name/password authentication or X.509 authentication.
  • User and password information table 1908 and X.509 principal information table 1910 are related to the principal information table 1906 .
  • the user and password information table 1908 contains user identifiers and password information for corresponding users.
  • the “password” field contains an encrypted SHA-1 hash of the password initially set by the user.
  • the “password” hash is encrypted with a master key that is protected by a K of M encryption scheme.
  • the X.509 principal information table 1910 contains certificates corresponding to principals, for example the certificates of remote cryptography servers that exchange keys with the presently described core engine.
  • ACL information table 1912 has a primary database key of an ACL identifier used to relate the table to an ACL entry table 1914 .
  • the ACL information table contains one record for each key, including the key's hidden link, the ACL's creation time and the key's expiration flag.
  • the ACL entry table 1914 has a primary key including an ACL identifier a principal identifier and a system identifier, which corresponds to a core engine identifier that uniquely identifies the particular core engine that generated the key.
  • a role table 1916 has a role identifier (roleid), a role name, a list operation identifier, and a role type, which identify and define the rights associated with a particular role.
  • the operation table 1918 contains an operation identifier and operation names, which are used to associate names of operations with actual operations that a user is authorized to perform in connection with a particular core engine.
  • Audit log table 1920 and transaction log table 1922 are used to collect records that define events as they take place in a core engine.
  • the audit log table 1920 for example contains information about the principal that performed a particular operation.
  • the transaction log table 1922 contains information about, for example encryptions and decryptions that were performed by the core engine.
  • FIG. 20 is a schematic block diagram illustrating a process of encrypting a file.
  • a request for a key is made by a user at the cryptographic server (stage 140 ).
  • the repository core engine optionally creates and transmits a session key to the key exchange module (stage 142 ).
  • the repository engine receives the user's exchange public key (stage 144 ).
  • the exchange public key is the public key associated with the exchange key pair that is used to exchange session keys between key exchange modules.
  • the key repository encrypts the session in the exchange public key (stage 146 ).
  • the key exchange module informs the A/A module that the user created a new session key (stage 148 ).
  • a new session key can be created, for example, when the application elects to cause generation of a new key by saving a new data object or saving an existing data object without providing a corresponding hidden link.
  • the A/A module adds information about key ownership into the ACL database (stage 150 ). In one embodiment, the owner of a key has full access to information protected by the key. Further, in this embodiment, the owner can grant rights to information protected by the key to other users.
  • the server key exchange module 1530 sends a session key and a hidden link to the remote computer system, encrypted in the user's exchange public key (stage 152 ).
  • the user decrypts the session key using the private key associated with the exchange key pair (stage 154 ).
  • the remote core engine 1540 encrypts the user data and the user application embeds the hidden link into a data structure, such as a file structure, associated with the user data (stage 156 ).
  • FIG. 21 is a schematic block diagram illustrating a process of maintaining an access control list (ACL) of a key.
  • ACL access control list
  • a user requests the ACL of an existing key from the key repository, and the A/A module receives the ACL request (stage 160 ).
  • the A/A module queries the user and ACL databases to determine whether the user has adequate rights to view an ACL associated with a particular key (stage 162 ).
  • information regarding other users having rights associated with the key is obtained from the user database.
  • user information is obtained from the user database and the ACL database and the ACL is transmitted to the user (stage 164 ).
  • the ACL is optionally modified by the client, for example to add or remove rights in a particular key to a particular user (stage 166 ).
  • the A/A module verifies that the user has adequate rights, for example by reference to the original ACL, to modify the ACL (stage 168 ).
  • the key repository makes appropriate changes to the ACL within the ACL database (stage 170 ).
  • FIG. 22 is a schematic block diagram illustrating a process of accessing an encrypted file.
  • a file server provides encrypted information to the user, by way of the remote computer system (step 180 ).
  • the repository server verifies that the user has the rights to access the key necessary to decrypt the information provided by the file server (stage 182 ).
  • the key is transmitted to the key exchange manager (stage 184 ).
  • the repository server retrieves the User's exchange public key from the user database (stage 186 ).
  • the repository key exchange manager re-exports the session key (stage 188 ).
  • the repository key exchange module sends the encrypted session key to the user, encrypted in the user's exchange public key (stage 190 ).
  • the user decrypts the session key using the user's exchange private key (stage 192 ).
  • the remote computer system decrypts the user data (stage 194 ).
  • FIG. 23 is a schematic block diagram illustrating a process of blocking access associated with a key in response to the key becoming compromised.
  • the repository server receives information regarding a compromise of a remote computer system or of a smart card (stage 196 ).
  • the repository operator receives a connection from an authorized representative of the user (stage 198 ). Further, if the authorized representative is successfully authenticated, the keys are disabled, for example by removing all users from the ACL associated with the compromised key (stage 200 ).
  • trusted software components are executed in connection with cryptographic systems consistent with the present invention.
  • the purposes of using trusted components in connection with a cryptographic system include the ability to verify the identity and authenticity of software. Verification of software is important, because the introduction of rogue software into a functioning cryptographic system can defeat the cryptographic system.
  • One way to determine the authenticity of software is to verify its identity.
  • identity can be established based on something's inherent characteristics, based on knowledge of a secret, or based on possession of something, for example a credential or a secret.
  • knowledge of a secret or possession of a secret such as an embedded key has proved to be problematic.
  • persistent computer users have been able to locate and extract keys hidden within software. Accordingly, establishing identity based on software's inherent characteristics is preferred. But merely having the name of a file containing source code is insufficient to establish identity. A “fingerprint” that uniquely identifies the file is preferred.
  • a fingerprint can be verified at run-time before executing software to verify the identity of the software.
  • FIG. 24 is a schematic block diagram illustrating a system in which trusted components are authenticated.
  • An application server 2410 and a registration server 2430 are provided. It is understood that the application server 2410 and the registration server 2430 can be implemented as separate threads or processes on a single computer system. Alternatively, the application server 2410 and the registration server 2430 are implemented on separate computer systems.
  • a cryptography server 2420 is used in connection with the application server 2410 and the registration server 2430 to provide cryptographic functions in connection with the verification of trusted components.
  • the application server 2410 optionally includes a smart card reader 2412 that reads key information from a smart card.
  • Token dispenser 2414 provides a cryptographic token in connection with verification of trusted components.
  • Cryptographic Agent 2418 provides the cryptographic functions necessary for the application server 2410 to communicate securely with the cryptography server 2420 and to authenticate a business application 2416 .
  • the registration server 2430 includes the smart card reader 2412 and a trusted component manager 2434 that is used to gather and process information about trusted components.
  • the cryptography server 2420 includes a registration database 2426 and the optional smart card reader 2412 , Further, the cryptography server 2420 includes a core engine 2422 , which also contains a key database 2424 , containing cryptographic keys. Trusted component authentication systems are further described in connection with FIGS. 24 - 27 .
  • FIG. 25 is a schematic block diagram illustrating a process of creating smart cards.
  • two secret cryptographic keys are generated during the installation or configuration of the cryptography server 2420 .
  • an operational key is generated (stage 202 ).
  • the operational key is used to secure communication between the cryptographic agent and the cryptography server.
  • the operational key is read into separate machines containing the cryptographic agent and the cryptographic server from a smart card.
  • a “fingerprint” corresponding to the cryptographic agent is also contained in the smart card.
  • the cryptographic server can verify the authenticity of the cryptographic agent.
  • a registration key is generated (stage 203 ).
  • the registration key is used by a system administrator during the registration process to register a trusted component.
  • the operational key is placed into an operational smart card (stage 204 ), and the operational key is optionally signed, for example by a trusted entity (stage 206 ).
  • the operational key is signed with a signing key associated with the cryptography server 2420 .
  • the registration key is placed in a registration smart card (stage 208 ). Further, the registration key is signed by a trusted signer (stage 210 ).
  • FIG. 26 is a schematic block diagram illustrating a process of registering components.
  • the trusted component manager 2434 receives software in the form of electronic computer code associated with a software component, such as business application 1542 (stage 212 ).
  • the trusted component manager 2434 determines the name of the component, for example by performing an operating system call to determine the name of a file associated with the component (stage 214 ).
  • the trusted component manager 2434 calculates a “fingerprint” of the trusted component, for example by applying a hash function like MD5 or SHA-1 to the component (stage 216 ).
  • the trusted component manager 2434 reads the registration key from the registration smart card (stage 218 ).
  • the trusted component manager 2434 uses the registration key pair to perform a challenge response protocol with the cryptography server (stage 220 ) and to securely send the component's information to the cryptography server (stage 222 ). Further, the cryptography server signs the newly registered component's registration information, including, for example, the “fingerprint” (stage 224 ), and the registration information is stored in a database.
  • token dispenser 2414 Upon restart of the application server 2410 , token dispenser 2414 receives information from the operational smart card by way of the smart card reader 2412 . In one embodiment, after the smart card is inserted, a user must provide a password.
  • FIG. 27 is a schematic block diagram illustrating a process of performing run-time authentication of components.
  • the business application 2416 submits a request to cryptographic agent 2418 to operate as a trusted component.
  • the cryptographic agent 2418 receives the request (stage 226 ).
  • the cryptographic agent determines the name of the application and calculates its digital “fingerprint” (stage 228 ).
  • the cryptographic agent 2418 transmits a request for challenge to cryptography server 2420 regarding the application (stage 230 ).
  • cryptography server 2120 generates a random challenge and calculates the correct response based on the operational key and the application “fingerprint” (stage 232 ).
  • cryptography server 2420 presents the challenge to the cryptographic agent 2418 (stage 234 ) and the agent performs a first part of the response calculation using the application's fingerprint by, for example combining the fingerprint with the challenge (stage 236 ).
  • the agent instructs the token dispenser 2414 to complete the calculation of the challenge (stage 238 ).
  • the token dispenser verifies the integrity of the agent, for example by comparing the stored fingerprint with the actual fingerprint of the operational agent as it is executing in memory and the token dispenser completes the response calculation, for example by computing a HMAC of the challenge and fingerprint combination using the operational key as the key in the HMAC calculation. (stage 240 ).
  • the cryptography server 2420 verifies the response to the challenge by verifying the HMAC with the operational key and comparing the calculated fingerprint with the stored fingerprint (stage 242 ) and validates the application as a trusted component.
  • the present invention has important benefits and advantages. Because cryptographic keys are not stored in software components, known techniques cannot be used to extract the keys and defeat the cryptographic system.
  • Protected data items contain an associated hidden link that provides the identity of the associated cryptographic key within the key store. Further, instead of having a few keys for all of the protected information, a different key is used to protect discrete pieces of information, for example a different key is used for each protected file on a file server or for each protected record in a database.
  • the key store is located in a centralized key repository resulting in the advantage of simplified backup and disaster recovery procedures. Further, the keys themselves are encrypted in the key repository and the keys are not identifiable with their respective protected data item. Accordingly, without knowledge of the hidden link within a protected data object, even possession of the key repository does not allow an intruder to achieve access to actual data.
  • Additional benefits and advantages of the present invention involve the distributed nature of the cryptographic systems and methods, in that while keys are centrailzed in one or more key repositories, cryptographic computations are performed on remote computer systems that are closer to the actual producers and consumers of the protected data. Accordingly, the computational power of the remote computer systems is leveraged and computational efficiencies are achieved over systems in which cryptographic computations are performed centrally.
  • Asymmetric Key Cryptography Cryptography that uses a different key to encrypt and to decrypt information. For example, in public key cryptography, a public key is used to encrypt information, but the public key cannot be used to decrypt the information. Only a private key associated with the public key can decrypt the encrypted information.
  • Attribute/Field A category of data saved in an object.
  • BLC Business Logic Component
  • Certificate Manager Controls the system key PKI related operations and communicates with the private certification authority responsible for issuing and verifying digital certificates for the system keys.
  • Cipher Text Encrypted data.
  • Class According to object-oriented programming, a category of objects.
  • Database Adapter Software component, which allows the security domain components to save and retrieve data on various types of databases and multiple databases.
  • DES Data Encryption Standard
  • Decryption Changing data from cipher text to plain text.
  • Digital Certificate An data structure used to ensure the authenticity of a public key.
  • a typical digital certificate includes a signed collection of certificate holder information, a public key, an identification of the certificate issuer, and the serial number of the certificate.
  • Encryption The translation of data into a secret code.
  • Encryption Key Manager A software component of the computer system, which manages the session encryption keys including generation, replacing, and other tasks.
  • Fault Tolerance The ability of a system to continue operation in the event of unexpected hardware or software failures.
  • GSM General Security Manager
  • HRNG Hardware Random Number Generator
  • Hashing Generating a number from a string of text that is substantially smaller than the text itself.
  • the hash value effectively cannot be used to determine the text used to generate the hash value.
  • the hash value or integrity value is used for search queries to identify an appropriate data object and for security integrity checks.
  • IP Internet Protocol
  • IPSEC Internet Protocol Security
  • IP Spoofing Attempting to make a message appear as if it came from an authorized Internet protocol address.
  • Key A password or table needed to decipher encrypted data.
  • KAM Key Auditing Manager
  • KLM Key Lifetime Manager Monitors the SEK's for expiration and deactivates expired SEK's or alternatively flags SEK's to be deactivated in the next request or call.
  • RAM Random access memory
  • MD5 Message Digest 5
  • a one-way hash function which takes a message and converts it to a hash value, or message digest, of a particular size. It is called a one-way hash function because it is nearly impossible to reverse the process, converting the hash value to the original message.
  • Object A self-contained entity consisting of both data and procedures, or methods, to manipulate the data.
  • Object Oriented refers to a special type of programming that combines data structures with functions or methods to create reusable and extensible program elements called objects.
  • PKI Public Key Infrastructure
  • KEYDB Secure Key Database
  • SSL Secure Sockets Layer
  • Session Encryption Key A key used to encrypt and decrypt data over the course of a session, which is a period during which data is being accessed.
  • SEKID Session Encryption Key Identifier
  • Smart Card A small electronic device about the size of a credit card that contains electronic memory. It may include an integrated circuit.
  • Symmetric Key Encryption An encryption system in which data is both encrypted and decrypted using the same key.
  • System Key Pair An asymmetric key pair that is used to encrypt and decrypt the SEKID's.
  • SKCN System Key Common Name
  • SLM System Key Manager
  • VPN Virtual Private Network
  • X.509 A widely used standard for defining digital certificates.

Abstract

A computer system is disclosed that contains cryptographic keys and cryptographic key identifiers. The system has a repository cryptographic engine that communicates securely with a remote cryptographic engine, and the repository cryptographic engine is associated with a user data store. The user data store includes a hidden link including a session key identifier encrypted with a protection key. The hidden link is associated with a remote data entity. A key data store associated with the repository server includes a session key encrypted with a session-key-protection key. The session key is used to encrypt and decrypt the remote data entity. The system also includes a repository key exchange module operable to exchange the session key with a remote key exchange module.

Description

    RELATED APPLICATIONS
  • This is a continuation-in-part application of U.S. patent application Ser. No. 09/693,605, filed Oct. 20, 2000.[0001]
  • BACKGROUND OF INVENTION
  • For various reasons, organizations frequently need to exchange confidential information over a network. Sometimes organizations establish private networks over dedicated leased lines for this purpose and to avoid use of a public network. A leased line is a dedicated point-to-point connection over the telephone network that is used for, among other things, routing regular telephone calls. For example, leased lines are used to provide private network connections between regional offices and corporate headquarters, carrying only information that is intended to be sent between the regional office and the headquarters. [0002]
  • A leased line may also be used to connect an organization to an Internet Service Provider (ISP). The ISP connects its customer to a public network, such as the Internet. With a connection to a public network, a customer may send and receive messages to any other party also connected to the public network. This has advantages of convenience and low cost relative to dedicated, private leased lines, because only a single connection to the ISP must be maintained. However, a network user has much less control over information sent and received over a public network than a user has over data sent on a private leased line. Specifically, in a public network, operators of networking equipment that routes information between an arbitrary sender and receiver may intercept the information and examine it or even modify it en route. Further, over a public network, senders and receivers have no convenient way to police the behavior of intermediate network providers. [0003]
  • Accordingly, it is conventional wisdom that dedicated leased lines provide better control over the privacy and integrity of information, because while it is possible for a provider of private leased lines to examine or alter information on the private network, users of the private leased lines know who the provider is and can establish reasonable procedures to audit the behavior of the provider to ensure a reasonable level of data privacy and integrity. In a public network like the Internet, it is impracticable to ensure that intermediate network operators will not examine or alter an arbitrary message placed on the public network. [0004]
  • Therefore, in terms of data privacy and data integrity, private networks on leased lines are preferable to conventional public network connections. Nevertheless, it is frequently the case that use of dedicated leased lines for all networking becomes impractical due to the sheer number of necessary dedicated connections and the substantial expense of leased lines. Accordingly, other means of establishing data privacy and integrity have been established. [0005]
  • One of these means is the Virtual Private Network (VPN), which uses cryptography to create a virtual point-to-point connection between nodes, including computers, using a public network, such as an Internet Protocol (IP) network like the Internet. Similar to a private network, a VPN involves a point-to-point connection, however, because it uses encrypted information over a public network to establish the “virtual” connection, a VPN does not require dedicated leased lines. [0006]
  • Hardware and software are widely available to implement VPN's. However, the hardware and software and particularly staff to properly operate the VPN's can be quite expensive. [0007]
  • Because information is encrypted and unencrypted at the network level at both ends of the point-to-point link, if an attacker is successful in compromising an operating system of an end node or computer, the attacker has complete access to all information exchanged in the VPN. Accordingly, the key to ensuring safe, uncompromised operation of a VPN is to make sure that attackers and intruders are not able to compromise or gain unauthorized access to the VPN end nodes. [0008]
  • To prevent unauthorized access, organizations use firewalls and sound system administration techniques. Firewalls filter or restrict the types of packets allowed to pass between external public networks and internal networks. However, firewalls must allow the exchange of at least some packets to and from a public network in order for the connection to the public network to be of any value. [0009]
  • Accordingly, as long as some packets are being exchanged with the public network, there are opportunities for attackers to gain unauthorized access. The next level of defense is to keep operating system level security layers secure. System level security layers include the pieces of software that require user names and passwords to allow connections and the like. [0010]
  • A common technique of attackers to gain unauthorized access is to exploit known defects in operating system security layers. These defects are ordinarily caused by human errors in the design and implementation of the system software. Accordingly, as fixes for the defects become available it is imperative to apply the fixes or patches. Monitoring and timely applying fixes and patches is an important aspect of sound system administration. If patches are not applied, intruders can easily gain access to end nodes. [0011]
  • In addition to a VPN, which requires configuration between endpoints of a point-to-point link, other methods exist for establishing an encrypted channel through which to exchange private information over a public network. These channel protections include protocols like Secure Sockets Layer (SSL) and Secure Shell (SSH). [0012]
  • Cryptography involves using codes and transformations on messages to render the messages unintelligible to anyone other than an intended recipient of the message. In the context of protecting data privacy, the process of rendering a message unintelligible is called encryption, and the process of unscrambling a message by an intended recipient to render the message intelligible is called decryption. Frequently, additional information other than the message itself is used to decrypt an encrypted message. Since encrypting is like locking a message and decrypting like unlocking it for the intended recipient, the information used for encrypting or decrypting is frequently called a key. [0013]
  • In addition to protecting the privacy of information, it is useful to ensure the integrity of information, data integrity meaning that data is authentic and not altered with authorization. One way to ensure the authenticity of information is to calculate a message digest on the information and to digitally sign the message digest. A message digest is frequently the output of a one-way hash function such as MD5 or SHA-1, which irreversibly produce fixed length output digests from messages of an arbitrary length. Upon receipt, a receiver can re-calculate the message digest on the received message and verify the signature. By verifying the signature and comparing the calculated message digest to the signed message digest, the receiver verifies that he or she has received, unaltered, the same message originally signed by the sender. [0014]
  • Other methods of providing verification of data integrity include Keyed-Hashing for Message Authentication (HMAC). HMAC is a mechanism that can authenticate both the source of a message and its integrity. HMACs utilize an arbitrary one-way hash function, such as MD5 or SHA-1 in connection with a shared secret, or key, to provide a message authentication code. HMACs can also be used in connection with challenge response protocols in which a response is computed that is a function of the secret key and the challenge message. Authenticity of information is verified when the receiver performs the HMAC calculation on the received message and compares it to the message authentication code sent in connection with the message. The receiver further can verify that the message originated from a source that was in possession of the secret key. HMAC is further described in RFC 2104. [0015]
  • A key can be a number used in a formula to operate on a message to either encrypt or decrypt the message. Other types of keys include one time pads, which are lists of keys that are applied to messages to encrypt and decrypt them, in which each element of the list of keys is used only once. Of course to keep an encrypted message from being decrypted by someone other than the intended recipient of the message, it is crucial to keep keys out of the hands of non-intended recipients. Therefore keys must be exchanged between parties to encrypted communication in a secure manner. One inconvenient way to do this is by way of a trusted courier that physically delivers keys to parties in a locked briefcase thereby ensuring actual security by way of verifiable physical security. However, physical courier methods of key exchange are generally too cumbersome, slow, and expensive. [0016]
  • Accordingly, one of the major challenges in cryptography is the process of key exchange. A popular method for exchanging keys is to use public key cryptography to exchange a symmetric key. Public key cryptography uses two kinds of keys to encrypt and decrypt information, namely public keys, which are intended to be widely distributed and associated with particular entities, and private keys, which are intended to be kept in a highly confidential and secure manner. Conversely, symmetric cryptography uses the same key to encrypt and to decrypt information. [0017]
  • Public key cryptography works by encrypting a message in a public key. Once encrypted in a public key, a message can only be decrypted using the corresponding private key. Similarly, a signer may create a digital signature by applying his or her private key to a message or typically to a digest of a message, which is a fixed-length piece of information that uniquely identifies the message. A digital signature is verified by applying the purported signer's public key to the signature to determine whether the signature is valid. [0018]
  • A simplified use of public key cryptography to exchange a symmetric key is accomplished in the following way. One party generates a new symmetric key, for example using a random number generator. Next, the party encrypts the symmetric key using the public key of the intended recipient and sends the encrypted message to the intended recipient. The recipient uses his or her private key to decrypt the message, thereby securely receiving the symmetric key which can be used to secure a channel for further communication. [0019]
  • An important concern in any application of public key cryptography is that a user of a public key cryptosystem (e.g. a sender of an encrypted message) uses authentic public keys of other parties. If a sender mistakenly uses the public key of an attacker, the attacker will be able to decrypt the message and will have the symmetric key allowing the attacker access to the secure channel. Further, if the attacker is able to inject himself or herself into the channel in this way, the attacker can forge messages to the recipient and mount a so called “man-in-the-middle” attack, in which both sender and receiver believe they are communicating directly over a secure channel but in reality are communicating through an attacker who has the ability to examine and alter messages as they pass between sender and recipient. Accordingly, the effective use of public key cryptography requires users to be able to verify that a particular public key is the true public key of the person to whom they wish to communicate. Ensuring that a public key is the correct public key is the problem of public key validation. [0020]
  • One way to solve the public key validation problem is to publish the public key in a major newspaper and for users of the public key to manually compare the public key they are using to the published numbers. This system is quite effective and occasionally used in practice. It is, however, somewhat inconvenient and not conveniently subject to automation. Other public key validation procedures have been employed. In a “ring of trust” environment, such as that used in the Pretty Good Privacy (PGP)™ system a user may manually input or automatically import public keys coming from a trusted source. Another solution to verification of public keys is the digital certificate, in which a public key is digitally signed, and according to which users of a public key cryptosystem can verify the authenticity of a certificate, and its corresponding public key, by validating a the digital signature on the certificate. The signature is validated using a preestablished, trusted public key of a Certification Authority (CA). [0021]
  • The SSL protocol uses digital certificates. In SSL, a web server has an X.509-formatted digital certificate, which is digitally signed by a trusted CA, using the CA's private key. In an SSL environment, the CA's signature can be verified at the client using a trusted version of the CA's public key. In popular browsers, public keys of popular CA's come pre-loaded into the browser. SSH requires an initial trusted exchange of a server's public key so that in subsequent transactions, the identity of the server can be verified by the user using conventional public key technology. [0022]
  • Accordingly, VPNs and channel protectors such as SSH and SSL protect data as it is exchanged from a secure node to another secure node over a potentially insecure network. However, these channel protectors protect data in transit only. Channel protection technology cannot protect data once it has been decrypted on a destination node. And firewall and sound system administration technology have proven not to be entirely effective in keeping intruders from gaining unauthorized access to network-connected computer systems. Thus, highly publicized assaults have been successful in quickly stealing thousands of credit card numbers and other confidential information from various web sites, for example. [0023]
  • In some situations, an organization attempts to protect fixed encryption keys and other sensitive data by locating its servers in a physically secure room equipped with locked doors and surveillance cameras. However, remote intruders do not need physical access to server rooms in order to access data stored on a company's server. Intruders merely need some form of remote access to the company's network. Even with the use of firewalls, this access can be gained through known exploits, incorporating techniques including for example, IP spoofing, in which an intruder forges packets to have false IP source addresses. Other techniques include network scanning which helps to identify systems having exploitable defects. [0024]
  • Once an intruder gains access to one system on an internal network, it becomes possible to exploit other weaknesses in the internal network, such as intercepting unencrypted network traffic and using the information gained from the traffic to access to other systems on the internal network. For example, many common E-mail programs transmit username and password messages unencrypted or using easily breakable obfuscation of the actual values. [0025]
  • Once access is gained to key system resources, i.e. root access to a conventional database server, an intruder has essentially full access the organization's information, including, for example, credit card numbers, identifiable medical records, and other sensitive confidential information about the organization's patients, customers, and/or employees. Other examples of confidential information that can be obtained by unauthorized access include credit card numbers, bank account numbers, social security numbers, birth dates, and highly personal and private medical records. [0026]
  • In connection with access to information, including access to keys to encrypt and decrypt information, it is useful to verify identity and authorization of users of the information and of the software the user is employing to access the information. Accordingly, user authentication and software, or code, authentication schemes have been devised to perform the authentication of users and code. User authentication can be performed by, for example, receiving a password and comparing the password to a stored password or by irreversibly converting the received password into another form and comparing the converted password to a stored password in the same form. Similarly, software components can be authenticated by using, for example, a digital signature. Known methods of providing software component authentication using signed components, however, rely on policy files and a PKI chain of trust. Unfortunately, there are also known methods of undermining security that depends on the integrity of an ordinary policy file. Further, in connection with components that are signed with an enterprise-level signing private key, an intruder that obtains access to the enterprise-level signing private key can place signatures on rogue software components. Accordingly, there is a need in the art for methods and systems of software component authentication that do not suffer from the deficiencies of known methods and systems. [0027]
  • From a patient's perspective, the consequences of unauthorized access to personal medical records can be devastating. For a typical consumer, canceling and replacing credit cards is a relative minor inconvenience compared to the compromise and potential publication of sensitive medical information. Further, tampering with medical information is a potentially life threatening violation of privacy and data integrity. Therefore, the protection of confidential information, especially medical records, requires a greater assurance that the customer's or patient's confidential information is secure. Known methods of securing data only while it is being transmission do not meet this need. [0028]
  • SUMMARY OF INVENTION
  • A computer system is provided that contains cryptographic keys and cryptographic key identifiers. The system has a repository cryptographic engine that communicates securely with a remote cryptographic engine, and the repository cryptographic engine is associated with a user data store. The data store includes a hidden link including a session key identifier encrypted with a protection key. The hidden link is associated with a remote data entity. An associated key data store includes a session key encrypted with a session-key-protection key. The session key is used to encrypt and decrypt the remote data entity. The system also includes a repository key exchange module operable to exchange the session key with a remote key exchange module. [0029]
  • The session key identifier is optionally operable to identify the session key corresponding to the remote data entity. The computer system optionally also includes an authorization module that controls access to operations. The authorization module is optionally further coupled with a user data store and access to the session key is further provided based on the user data store. The protection key is a preferably a symmetric cryptographic key. [0030]
  • In an embodiment, the session-key-protection key is a symmetric cryptographic key. In an alternative embodiment, the session-key-protection key and the protection key are equivalent. The symmetric cryptographic key is optionally the triple Data Encryption Standard or the Advanced Encryption Standard. [0031]
  • A distributed network is provided including a repository server containing cryptographic keys. The network includes a repository cryptographic engine operable to communicate securely with a remote cryptographic engine. The network also includes a remote cryptographic agent operable to communicate securely with the remote cryptographic engine. Further, the network includes a business application coupled with the remote cryptographic agent, wherein authenticity of the business application is verified by the remote cryptographic engine by comparing a stored fingerprint of the business application with a calculated fingerprint of the remote cryptographic agent. [0032]
  • A cryptographic method is provided for facilitating the secure storage of information. First, a key request is received for a session key from a requesting key exchange module at a remote computer system. The key request includes a hidden link. Next, the session key is accessed and encrypted based on the hidden link using a protection key. Then an exchange public key is received corresponding to the requesting key exchange module. The session key is encrypted in the exchange public key, resulting in an encrypted session key. Further, the encrypted session key is transmitted to the requesting key exchange module. Then, at a computer system associated with a requester, the encrypted session key is received with an exchange private key corresponding to the exchange public key. A data entity is encrypted with the session key, and the hidden link is attached to the data entity. Further, the data entity is stored.[0033]
  • BRIEF DESCRIPTION OF DRAWINGS
  • These and other inventive features and advantages appear from the following Detailed Description when considered in connection with the accompanying drawings in which similar reference characters denote similar elements throughout the several views and wherein: [0034]
  • FIG. 1 is a schematic diagram of a computer system implementing a hidden link dynamic key manager according to the present invention; [0035]
  • FIG. 2 is a schematic block diagram of the computer system of FIG. 1 illustrating software components of the computer system; [0036]
  • FIG. 3 is a schematic diagram of the database structure according to the present invention and utilized by the computer system of FIG. 1; [0037]
  • FIG. 4 is a schematic diagram of a security key identification attribute of the database structure of FIG. 4; [0038]
  • FIG. 5 is a schematic diagram of a monitor illustrating adaptable display parameters according to the present invention and having only public information and fields displayed; [0039]
  • FIG. 6 is a schematic diagram of a monitor illustrating the adaptable display parameters according to the present invention and having both public and private information and fields displayed; [0040]
  • FIG. 7 is a schematic block diagram illustrating the steps for determining how to adapt the display parameters illustrated in FIGS. 5 and 6; [0041]
  • FIG. 8 is a schematic diagram of a session encryption key data entity; [0042]
  • FIG. 9 is a schematic diagram of a system key common name data entity; [0043]
  • FIG. 10 is a schematic block diagram illustrating the encryption and storage of data entities during an add transaction; [0044]
  • FIG. 11 is a schematic block diagram illustrating the retrieval and decryption of data entities during update and view transactions; [0045]
  • FIG. 12 is a schematic block diagram illustrating an alternate embodiment for the retrieval and decryption of data entities during update and view transactions; [0046]
  • FIG. 13 is a schematic block diagram illustrating the deactivation of session encryption keys; [0047]
  • FIG. 14 is a schematic block diagram illustrating an alternate embodiment for the deactivation of session encryption keys; [0048]
  • FIG. 15 is a schematic block diagram illustrating a system in which database protection is provided consistent with the present invention; [0049]
  • FIG. 16 is a schematic block diagram illustrating a system in which remote computer systems access a key repository over a network; [0050]
  • FIG. 17 is a schematic block diagram illustrating a system involving a file server, a repository server, and remote computer systems; [0051]
  • FIG. 18A is a schematic block diagram illustrating intradepartmental data protection consistent with the present invention; [0052]
  • FIG. 18B is a schematic block diagram illustrating interdepartmental data protection consistent with the present invention; [0053]
  • FIG. 18C is a schematic block diagram illustrating data protection in connection with an Intranet or extranet based key repository; [0054]
  • FIG. 18D is a schematic block diagram illustrating mobile data protection; [0055]
  • FIG. 18E is a schematic block diagram illustrating data protection in a multiple enterprise environment; [0056]
  • FIG. 19 is a schematic block diagram illustrating an embodiment of tables corresponding to key, access control, and user databases; [0057]
  • FIG. 20 is a schematic block diagram illustrating a process of encrypting a file consistent with the present invention; [0058]
  • FIG. 21 is a schematic block diagram illustrating a process of maintaining an access control list; [0059]
  • FIG. 22 is a schematic block diagram illustrating a process of accessing an encrypted file; [0060]
  • FIG. 23 is a schematic block diagram illustrating a process of blocking access associated with a key in response to the key becoming compromised; [0061]
  • FIG. 24 is a schematic block diagram illustrating a system in which trusted components are authenticated; [0062]
  • FIG. 25 is a schematic block diagram illustrating a process of creating smart cards; [0063]
  • FIG. 26 is a schematic block diagram illustrating a process of registering components; and [0064]
  • FIG. 27 is a schematic block diagram illustrating a process of performing run-time authentication of components.[0065]
  • DETAILED DESCRIPTION
  • Referring to the drawings in greater detail, FIGS. 1 and 2 show a [0066] computer system 20 constructed in accordance with a preferred embodiment of the present invention for storing information. The present invention provides an improved method of encrypting and decrypting data preferably at rest, which is to say in its native form, for example in a file system or in a data base server. The computer system 20 broadly includes a security domain 22 having an encryption key manager (EKM) 24, system key manager (SKM) 84, key lifetime manager (KLM) 88, key auditing manager (KAM) 90 and database adapter (DBAD) 86. In an alternative embodiment, other enterprise security components are included in security domain 22.
  • The [0067] computer system 20 also includes a plurality of client business domains 26 having an information database 28. The computer system 20 implements a method according to the present invention. The method broadly includes encryption, decryption and storage of data entities 30 (FIG. 3) as illustrated in the flow diagram of FIG. 10, and the method also includes the retrieval and decryption of data for data manipulation. One embodiment of the retrieval and decryption method is illustrated in the flow diagram of FIG. 11. The computer system 20 utilizes a data structure illustrated in FIG. 3. The data structure broadly includes a plurality of data entities 30 having a security key identification attribute 32, which contains security key information as illustrated in FIG. 4.
  • Referring to FIG. 1, in addition to the [0068] security domain 22 and the client business domains 26, the computer system also includes a plurality of client terminals 34. The client terminals 34 are provided with telecommunications capabilities to communicate with the business domain 26, However, the invention also contemplates the use of alternative communication mechanisms, such as Intranet, local area networks (LAN), and wide area networks (WAN), for example. The Intranet, LAN, and WAN applications may be utilized for any type of facility or organization where data security is important such as a bank, hospital, or law firm, for example. The client terminals 34 gain access to the client business domains 26 only after passing through security devices such as firewalls, and communication between the client business domain 26 and the security domain 22 preferably occurs through an Internet protocol secure, virtual private network tunnel (IPSEC, VPN tunnel) 38.
  • The [0069] security domain 22 includes a primary key server 40, a secondary key server 42, a security key database (KEYDB) 44, and a certification authority server 46. Each of the key servers is a general purpose computer having various components including, for example, one or more processors, fast main memory, and persistent storage. The certificate server 46 also is a general purpose computer.
  • The primary [0070] key server 40 and secondary key server 42 are mirror components. Thus, the primary and secondary key servers are substantially identical. If the primary key server 40 fails, the secondary key server 42 begins operation immediately without disruption in overall system operation, thereby providing fault tolerance. The transfer in operation is accomplished, for example, through a heart beat failover channel between the primary and secondary servers 40, 42. The primary and secondary servers 40, 42 each optionally include a tape backup 48, 50, respectively, for key retrieval in the event that the KEYDB 44 is irretrievable or a key integrity check fails. The primary server 40 is provided with a primary system key reader 52, designated reader #1 in the drawing, and a primary encryption key reader 54, designated reader #2 in the drawing. Preferably, each of the primary readers 52, 54 for the primary server 40 store the same information. Thus, the primary readers 52, 54 are mirrored hardware components for superior fault tolerance. The secondary database 42 also includes a secondary system key reader 56, designated reader #1 in the drawing, and a secondary encryption key reader 58, designated reader #2 in the drawing. Preferably, each of the secondary readers 56, 58 for the secondary server 42 store the same information. Thus, the secondary readers 56, 58 are also mirrored, and there are a total of four readers from which key information can be retrieved. The readers 52-58 comprise security token readers for receiving security tokens. Preferably, the readers comprise Smart Card readers for receiving smart cards. A hardware random number generator (HRNG) 59 is also optionally provided in the security domain to generate random numbers, which are used as identifiers for keys.
  • In one embodiment, the [0071] key servers 40 and 42 contain multiple protection keys that are used to encrypt and decrypt session keys and session key identifiers. The protection keys are themselves stored in a protection store, for example an ASCII flat file, and encrypted in a master key. In one embodiment, the master key can be provided based on a K of M paradigm, under which there are M, for example seven, separate sub-keys that are held by, for example, seven different people. In this embodiment, to unlock the protection key store, a number K, for example three of the seven people must provide their sub-keys. In an alternative embodiment, a weighted K of M scheme is employed, under which some of the M sub-keys are weighted higher than others. In a weighted K of M scheme, for example, a company's CEO can be provided with a sub-key having sufficient weight to unlock the protection store by itself, while subordinates have sub-keys with lower weights based on the subordinate's level of responsibility.
  • In one embodiment, [0072] KEYDB 44 comprises an external disk array with a fault tolerance system for mirrored operation. In an alternative embodiment, the KEYDB 44 is a relational database platform, such as Microsoft™ SQL Server, Oracle™, DB2™, mySQL™, PostgreSQL™, or Jet Engine™. The external disk array or database server optionally includes a redundant array of independent disks (RAID). Each of the key servers 40, 42 is operable to communicate with the KEYDB 44. In one embodiment, the key servers communicates with the database server KEYDB 44 using ADO, ODBC, or a native database interface, such as the interface provided in connection with the Oracle™ database server.
  • The [0073] client business domains 26 preferably include a plurality of application servers 60, 61 and a primary information database 62, which is isolated from the KEYDB 44, and which is a database platform such as the platforms enumerated in connection with KEYDB 44 or alternatively InterSystems Caché™ Preferably, a backup information database 64 is also provided. The backup information database 64 mirrors information in the primary information data 62 providing redundancy and protection against data loss. Thus, the client business domains 26 are provided with superior fault tolerance. For added security, in one embodiment, the client business domain servers 60, 61 are only accessible through a firewall 66. Each application server 60, 61 may contain multiple business logic components such as business logic component number one (BLC1) 68. The BLC's contain instructions and rules for operation of the computer system 20 that are set by users and/or the developers of the users' software applications.
  • Generally, each [0074] client terminal 34 includes a central processing unit (CPU) 70, a data entry mechanism, such as a keyboard 72, and a display or monitor 74. The CPU 70 is operable to control the monitor 74, receive input from the keyboard 72, and establish and maintain communications through the Internet 36 utilizing a modem, two-way satellite, digital subscriber line (DSL), or other communication apparatus (not shown), such as an Ethernet adapter. The CPU 70 is also operable to control other computer system devices such as a printer or disc drives. Preferably, each client terminal is also equipped with a user security token reader for receiving a security token. In a preferred embodiment, the security token reader comprises a Smart Card reader 78 for receiving a Smart Card 80. The Smart Card is optionally provided with a private and secured file system. Each user is optionally provided with his or her own Smart Card 80, which includes a cryptographic for identifying and authenticating the user. Other known solutions, such as user identification and password, can be used to control access and user authentication. In one embodiment, users have one or more roles for authorization. The role identifications can include assistant level, receptionist level, administrative level, and others. The role identifications represent the duties performed by individuals in those levels and the extent of information needed for them to properly perform those duties. The user and role identifications are used as described below in connection with FIG. 7 to limit access to information.
  • Referring to FIG. 2, the [0075] security domain 22 of the computer system 20 includes several software components that are resident on the hardware components illustrated in FIG. 1. The primary and secondary key servers 40, 42 include substantially the same software components and both will be described with reference to the primary key server 40. The primary key server 40 includes several software components: a general security manager (GSM) 82, the encryption key manager (EKM) 24, a system key manager (SKM) 84, a database adapter (DBAD) 86, a key lifetime manager (KLM) 88, and a key auditing manager (KAM) 90. A certificate manager (CM) 92 is provided on the private certificate authority (CA) server 46.
  • The general security manager (GSM) [0076] 82 operates as a gateway to the portions of the computer system 20 located in the security domain 22. To that end, each of the security domain 22 components EKM 24, SKM 84, DBAD 86, KLM 88, KAM 90, CM 92 are preferably not operable to communicate directly with any component outside the security domain 22 of the computer system 20. In one embodiment, they are only operable to communicate with outside components through the GSM 82. Preferably, component mutual authentication occurs between the GSM 82, which is located in the security domain, and the outside business domain components 68. COM+, CORBA, or Java security can be used to control the mutual authentication. Thus, in this embodiment, neither the client user nor any component in the client business domain 26 can contact anything other than the GSM 82 through trusted authentication process.
  • The [0077] GSM 82 is also operable to encrypt the data entities 30 (FIG. 3) using, for example, a three-key, triple data encryption standard (3DES), RC4, or any strong cryptographic algorithm on selected attributes of the data entities 30C, 30D as directed and requested by the BLC's and other components of the computer system 20. Thus, while DES uses symmetric 56-bit key encryption, the GSM preferably uses three-key 3DES, which is a symmetric 168-bit cryptosystem, having an effective key strength of about 110 bits. Other strong cryptographic algorithms can be employed, such as 128-bit IDEA or AES. Using keys with extended lengths makes the keys more difficult to break than the 56-bit DES keys, which have been experimentally broken using parallel processing systems.
  • The [0078] GSM 82 also performs the decryption of the data entities 30 when other components of the computer system 20 request decryption. Further, the GSM 82 is operable to perform hashing operations using message digest 5 (MD5), SHA-1, or other strong hashing algorithms as instructed by other components. The hash values or integrity values generated in the one way hashing process are typically stored as attributes in data entities for integrity check purposes. Preferably, the GSM 82 hashes all of the data attributes of the data entities and stores that data hash value as an attribute. After the data has been decrypted, it is again hashed and the before and after hash values are compared. If the two hash values are identical, the integrity of the data in the data entity has been confirmed. If two hash values are different, an alarm is issued and the data is retrieved from the backup information database 64.
  • The encryption key manager (EKM) [0079] 24, as its name indicates, generally manages encryption keys, which as described below are used to encrypt and decrypt the data entities 30C, 30D. Thus, the EKM 24 is operable to generate multiple session encryption keys (SEK) for example either 3DES or AES and generate session encryption key identifications (SEKID's) for the SEK's. The SEKIDs are random numbers optionally generated with the HRNG 59 (Hardware Random Number Generator). Alternatively, SEKIDs are generated using a software random number generator. The EKM is operable to perform integrity checks on the SEKs using hash values for the SEKs. The EKM is further operable to transmit the SEKID to the SKM 84 for encryption, and the EKM 24 is also operable to transmit the SEK and corresponding SEKID, in encrypted form, to the GSM 82, which then encrypts the data entities 30C, 30D using the SEK.
  • The system key manager (SKM) [0080] 84 generally manages system keys, which as described below are used to encrypt the SEKIDs. Thus, the SKM 84 is operable to encrypt the SEKIDs. In one embodiment, a number of protection keys are used to encrypt SEKs and SEKIDs. It is understood that the number of protection keys used is an operator selectable parameter. In one embodiment, about 20 protection keys are used. In another embodiment, more than about 1,000 protection keys are used. The protection keys are optionally 3DES or AES keys and pointers to protection keys are stored in connection with SEKs. In this embodiment, hidden links, which are transmitted in connection with encrypted data contain several data structures, including a pointer to a protection key, and a cryptographic engine identifier that uniquely corresponds to the cryptographic engine that generated the SEKID.
  • In one embodiment, separate encryption keys are used to encrypt the SEK and the SEKID. In this embodiment, an encryption key public key is used to encrypt the encryption keys that are used to encrypt the SEKs. Further, a system key public key is used to encrypt symmetric keys that are used to encrypt the SEKIDs. In this embodiment, the SKM also generates a system key common name (SKCN) for the asymmertical encryption key pairs and system key pairs. In this embodiment, the SKCN's are generated when generating the system public key's digital certificates, so that there is a unique SKCN for each system key pair. In an alternative embodiment, the SEKID is encrypted in a symmetric key that is encrypted in the system key public key. In yet another alternative embodiment, SEKIDs are encrypted in the same symetric key, called a protection key, as the SEKs. [0081]
  • Upon request from the [0082] EKM 24, the SKM 84 is also operable to decrypt the SEKID using the appropriate key. If desired, the SKM 84 and EKM 24 can be combined into a single component and can reside on the same server or computer system.
  • In one embodiment the Microsoft Crypto API (application program interface) is used to provide cryptographic functionality. In an alternative embodiment OpenSSL™ is used to perform cryptographic functions. [0083]
  • In one embodiment, the key lifetime manager (KLM) [0084] 88 monitors the lifetime of the SEK's based on corresponding expiration dates and timestamps. In this embodiment, the KLM 88 flags the expired SEK's with an expiration flag, so that in the next request, the EKM will optionally check the expiration status of the SEK and replace the expired key with a new one during run-time operation.
  • A particular SEK is used in connection with a particular data object. Accordingly, in one embodiment, an application can save a data entity with the same SEK by resubmitting a hidden link in connection with a request to store the data entity. A hidden link is a data structure including the encrypted SEKID, a pointer to the protection key used to encrypt the SEKID, and a cryptographic engine identifier. Additionally, the application can cause the generation of a new SEK by transmitting a save data request without including a hidden link. In one embodiment, the [0085] KLM 88 sets a key expiration flag in connection with the SEK so that an application can be alerted that it is an appropriate time to cause a new SEK to be generated.
  • In one embodiment, the key auditing manager (KAM) [0086] 90 is operable to maintain an active audit log including all transactions involving the SEKs and the keys used to encrypt the SEKs. Generally, the KAM 90 monitors the log for alarm events utilizing smart patterns, rules, and policies. The KAM 90 is also operable to provide notification upon the occurrence of an alarm event, such as if a system key or SEK has been compromised. In an alternative embodiment, operator selectable thresholds for numbers of new key generations are configurable. In this embodiment, an operator can observe the cryptograpic system under normal operation, noting a typical number of new keys that are generated over a particular period and set the thresholds accordingly. Once configured, if a threshold is exceeded a notification is sent regarding the exceeded threshold.
  • The certificate manager (CM) [0087] 92 is operable to perform all of the system key PKI related operations. For each system key the CM 92 generates a X.509 digital certificate. Preferably, the digital certificate includes a critical V3 extension, so that only the private certificate authority (CA) can verify the key. Each time a request for decryption by a system key is received by the SKM 84, the CM communicates with the private certificate authority (CA), which is local to the security domain, to verify the system key.
  • In one embodiment, the database adapter (DBAD) [0088] 86 is operable to hide database specific application programming interfaces (API) from the security domain 22 components and thereby controls and enhances communications between the key managers 24, 84 and the secured key database 44. Thus, by using different DBAD's, the security domain components can interface with different types of databases. The DBAD 86 also allows the security domain components to interface with multiple databases within the security domain 22, such as Microsoft SQLServer, Sybase, Informix, Oracle, and IBM DB2. It is understood that known databases employ database fault tolerance. While the preferred operations and locations of the respective components has been described in detail, it is understood that specific tasks can be exchanged between components and the locations of components can be combined, separated, or exchanged without departing from the spirit of the invention.
  • Referring to FIG. 3, the database structure preferably comprises an object oriented database structure having a plurality of [0089] data entities 30, which are preferably data objects. However, other types of databases are contemplated by the invention. For example a relational database could be used, such as Microsoft SQLServer, Oracle, Sybase, Informix and IBM DB2. Thus, when the term object is used, its counterparts, record for example, are also contemplated, and when the term class is used, its counterparts, table for example, are also contemplated.
  • One of the [0090] data entities 30A, specifically a persistent data entity, is shown in detail. The data entity 30A includes an Added attribute 100 and an Added By attribute 102. The Added attribute 100 records a timestamp containing the date and time the object was added, and the Added By attribute 102 records the digital signature of the user adding the record or data entity. The digital signature is obtained from the digital certificate of the client user's Smart Card 80 or client's current session and user identification. The Modified and Modified By attributes, collectively 104, record the same information for modifications to the data entity 30A. In combination, these non-repudiation attributes 100, 102, 104 inhibit a client user from claiming that the user did not take a certain action. The security status (SecStatus) attribute 108 indicates whether the data object contains plain text or cipher text and whether it is public or private.
  • Referring additionally to FIG. 4, a security [0091] key identification attribute 32 is also an attribute of the data entity 30A and contains security key information. The security key information includes the encrypted SEKID 112 and the SKCN hash value 114, which are used, as described below, to find the SEK used to encrypt associated data entities 30C, 30D and to find the system key used to encrypt the SEKID 112. While it is preferred that the SKCN hash value is stored in the security key attribute 32, the SKCN could be stored in this location without hashing.
  • Referring again to FIG. 3, the [0092] data entity 30A also includes a security integrity attribute (SecIntegrity) 116, which contains the data entity hash value. The data entity hash value is obtained by hashing all or selective attributes within the data entity. This is controlled by business needs and policies, which are preferably determined by the client and recorded in the BLC's. When a data entity is retrieved, it is hashed using, for example, SHA-1 and that data entity hash value is compared with the stored hash value in the security integrity attribute 116. If the hash values are the same, then the integrity of the retrieved data entity is confirmed to be correct and not altered. If the hash values are not identical, then an alarm is issued, so that the data can be optionally manually confirmed, and as described above, retrieved from the backup information database 62.
  • Referring additionally to FIGS. 5, 6, and [0093] 7, a security privacy attribute 118 controls access to the information in the associated data entities 30C, 30D. When a client user, a doctor for example, marks his information private, a special access list (SAL), data entity/class 30B is automatically created and the doctor is automatically added to the special access list. The doctor can thereafter add and delete user identifications attributes 120 and/or role identifications 122 from the special access list. The user attributes 120 are based on specific user identifications from the smart cards or any other authentication method. The role attributes 122 are based on different security levels of users. For example, the doctor may grant permission to view private data to other doctors but not permit nurses to view private data. The roles can include any security level: secretary, shareholder, custodian, and administrative, for example. In this fashion, the doctor controls who can view what information and who can edit what information. The same holds true for patient records; where nurses and doctors may have full access, clerical staff may have limited access to name, address, payment, and appointment information. This privacy can be applied to any vertical market such as banking, intellectual property systems, e-Commerce, law firms, and all applications that deal with highly sensitive or classified information.
  • When an authenticated client user requests information at [0094] step 124 in FIG. 7, the computer system retrieves the information at step 126, which will be described in greater detail below. After the information is retrieved, the system checks the security privacy attribute 118 at step 128. If the information is not marked private, it is fully displayed on the monitor 130 as illustrated in FIG. 6. If the information is marked private, the system checks the security level of the client user at step 132. In checking the user's security level, the system looks at both the user identification and the role identification to see if either are in the special access list, and determine what rights, such as view only or edit, the user has to the information. If the client user has full view rights, then the display of FIG. 6 is again shown. If the client user is not entitled to view the private information, the display parameters are adapted in step 134. In step 134, the display fields of the private information, which will not be displayed, are eliminated from the display parameters with their related labels, so that when the permitted information is displayed in step 135 on monitor 136 of FIG. 5, the fields for the private information are not displayed.
  • Further, it is envisioned that the fields for the public information may be modified, so that the existence of the private information is completely masked. In the example shown, [0095] personal information 138, such as data of birth and number of children are displayed for the user having access to private information. However, for a user without authorization to view the private information, the date of birth and number of children fields are removed from the display of FIG. 5. Further, the home address information 140 and work address information 142 are displayed for the user with authorization to view private information, and the fields specifically indicate which address is for work and which address is for home. In contrast, the user without access to private information not only does not see the home address, the work address fields 144 in FIG. 5 are modified to eliminate the designation that it is a work address.
  • Referring again exclusively to FIG. 3, the [0096] persistent data entity 30A also includes several association attributes, which are used by the database schema to associate or link related data entities 30B, 30C, 30D to the persistent data entities 30A. To that end, the persistent object 30A includes a class identification attribute 146 and at least two search attributes 148. For faster and secured searching, the searchable attributes 148 are preferably hash values of user information such as the patient name. The database uses these attributes 146, 148 and others to associate related persistent objects 30A and related class objects 30B, 30C, 30D with the persistent objects containing the appropriate security key identification 32 that was used to encrypt data attributes in the class objects. Two exemplary class objects are shown in FIG. 3: a person class object 30C and a name class object 30D. Other unillustrated class objects/entities include an address entity, employer entity, payment entity, insurance entity, and others.
  • The database is also provided with look up maps or notes [0097] 150. The illustrated lookup map 150 is for gender of the person class. This saves database resources because every person in the database simply has a 0, 1, or 2 corresponding to undisclosed, male, or female, respectively. Thus, the look up map 150 saves database resources because each person class has a single digit integer instead of a lengthy word entry. Look up maps are also preferably used for the security status attribute 108, the security privacy attribute 118, and others.
  • Referring to FIGS. 8 and 9, the data structure also includes an [0098] SEK object 151 saved in the KEKDB 44 and a SKCN object 152, which is saved in either the KEKDB 44 or in an alternate embodiment, a separate system key database (not shown). Thus, for increased security, several of the data entities are stored in separate databases. In one embodiment, public key pairs are stored in a hardware security module (HSM) device.
  • The SEK object/entity includes as attributes the [0099] SEKID 153 in a normal/decrypted form, the encrypted SEK 154, the SEK integrity check 155, which is a hash value of the SEK, and the optional SKCN hash value 156. The SEK data entity 151 preferably does not include the encrypted SEKID. This creates a hidden link between the encrypted data and the SEK used to encrypt it because the SEKID is encrypted, and the SEK is stored in a separate database. In one embodiment an HMAC is provided for data record integrity also stored in connection with each record in the key database. The secret associated with the HMAC is contained in master security container, which is optionally protected with a K of M encryption scheme. The SEK object also preferably includes a Created On attribute 159, which records a time stamp for the creation of the SEK and optionally a Last Usage Date attribute 161, which records a time stamp for the last time the SEK was used. Additionally, the SEK object optionally has a Usage Counter attribute 163, which records how many times the SEK has been used. The Created On 159, Last Usage Date 161, and Usage Counter 163 attributes provide the client with optional feature selections. Specifically, the client can select to have keys expired a certain number of months, two months for example, after their creation. The client can also preferably decide to have SEK's expire when they have not been used for a selected period of time or when they have been used more than a selected number of times. The client can also choose to have SEK's expired randomly or not at all. The SKCN object/entity includes the SKCN hash value 157 and the SKCN 158 as attributes, and is preferably stored in a database separate from the data entities 30.
  • FIG. 15 is a schematic block diagram illustrating a system in which database protection is provided consistent with the present invention. Distributed [0100] application 1500 generally provides an interface to information in database server 1520 by way of application server 1510. Information at rest is protected in database server 1520 by way of SEKs provided by cryptography server 1530. When a requesting user of the distributed application 1500 interacts with business application 1542, the business application 1542 receives any necessary information from the database server 1520. Sensitive information in database store 1522 is encrypted. Accordingly, in order to use the encrypted information, the business application 1542 must decrypt the encrypted information.
  • The [0101] business application 1542 utilizes the cryptography server 1530 by providing the cryptographic agent 1544 with data to encrypt and to decrypt and with an optional hidden link that is stored with the encrypted information in the data store 1522. Further, the requesting user provides authentication information to business application 1542. In one embodiment, the authentication information is the requesting user's user identifier and password, with which a challenge response protocol is performed. In alternative embodiments, authentication information is based on biometrics or smart cards. It is understood that other user authentication mechanisms can be used without departing from the scope of the present invention.
  • In fulfilling requests from the requesting user, [0102] business application 1542 provides the user's authentication information to the cryptographic agent. The cryptographic agent 1544 connects to a core engine associated with cryptography server 1530 over an optionally secure channel, for example an SSL link. The cryptography server 1530 validates the user authentication information in connection with user database 1526. In one embodiment, validation of user authentication information involves a challenge response protocol between the agent and the core engine in which the user's password is used to compute the response to the challenge.
  • If the user authentication information is valid, a [0103] core engine 1554 receives information and instructions to perform operations, such as to encrypt data or decrypt data, from the business application 1542. The cryptography server 1530 optionally determines whether the user is authorized to perform the operations by querying access control list database 1524. If the requesting user is authorized to perform an instruction associated with a particular session key, the core engine 1554 determines which protection key is associated with the requested session key and decrypts the session key with its protection key.
  • If the [0104] business application 1510 needs to decrypt a block of information stored encrypted in the database server 1520, the business application receives the block and its associated hidden link from the database server 1520 and provides the block and its associated hidden link to the cryptographic agent 1544. The cryptographic agent 1544 relays the encrypted block and the hidden link to the core engine 1554. By examining the hidden link, the a core engine 1554 can determine whether the hidden link is was generated locally or whether it is from a foreign cryptography server (not shown) by examining the cryptographic server identifier associated with the hidden link. Further, the core engine can identify the protection key with which to decrypt the encrypted SEKID in the hidden link by examining the protection key pointer contained in the hidden link. The core engine decrypts an encrypted SEKID and uses the decrypted SEKID to access the encrypted session key from a key database 1540.
  • In one embodiment, looking up the encrypted SEK is accomplished by querying an SEK table having SEKID as a primary relational database-key. The core engine decrypts the encrypted SEK with a corresponding protection key. In one embodiment, the same protection key is used to encrypt the SEKID and the SEK. Accordingly, once the SEKID protection key is identified, it is available to be used to decrypt the SEK. Next, the [0105] core engine 1554 decrypts the information the business application 1542 provided from the database server 1520 and transmits the decrypted information back to the business application 1542 through the cryptographic agent 1544. In one embodiment, communication is performed between the cryptographic agent 1544 and the core engine 1554 using an unencrypted TCP session. In an alternative embodiment, communication is carried out using SSL without SSL client authentication. In yet another embodiment, communication between agent and core engine is performed using SSL with client authentication. It is understood that other methods of securing the channel between agent and core engine can be employed without departing from the scope of the invention, such as an unencrypted TCP session over an IPSec VPN.
  • When a user causes the business application to store information at the database server, the cryptographic agent facilitates encryption of the information before the business application provides the information to the database server. If the business application is storing new information or if the business application has determined that a new SEK should be generated, then the business application provides the unencrypted information without an associated hidden link. When the core engine receives data to encrypt without an associated hidden link, the core engine generates a new SEK and SEKID, encrypts the provided information and the SEKID, combining a protection-key pointer and core engine identifier to form a hidden link, and returns the encrypted information and the hidden link to the business application through the cryptographic agent. Further, the business application stores the encrypted information and the associated hidden link at the database server. When it becomes necessary to access the encrypted information, the encrypted information and the associated hidden link are provided to the core engine and the core engine decrypts the information for the business application if the user has sufficient rights. [0106]
  • When storing information that has an associated hidden link, for example when a field in the database is modified, the business application can elect not to generate a new key. To achieve this result, the business application provides information to be encrypted in connection with the existing hidden link. When the core engine receives information to be encrypted and an existing hidden link, the engine encrypts the provided information with the SEK corresponding to the existing hiddenlink. In this regard, the business application drives the process of generating new session keys for existing data. [0107]
  • FIG. 16 is a schematic block diagram illustrating a [0108] system 1600 in which remote computer systems access a key repository over a network. One embodiment includes a repository server 1620 that includes a repository core engine 1622. The repository core engine 1622 includes a key database 1640 having cryptographic keys contained within the key database 1640. The repository core engine 1622 provides the functions of key generation, storage, and retrieval.
  • Further, the [0109] repository server 1620 includes an access control list (ACL) database 1624 and a user database 1626. The ACL database 1624 contains information regarding types of allowed access, or rights, particular users have to particular data entities associated with cryptographic keys stored in the key database 1640. The repository server 1620 also optionally has a smart card reader 1632, which is operable to read information from a smart card such as the GEM-159 available from Gem Plus. Further, the repository server 1620 contains a repository key exchange module 1634 and an authentication/authorization (A/A) module 1636. The repository key exchange module 1634 enables two separate cryptographic engines to share keys. The A/A module 1636 identifies and/or authenticates users by, for example, a challenge response protocol in connection with smart cards or user name/password combinations, associated with the users. Further, the A/A module provides user registration functions in connection with the ACL database 1624, which contains information regarding particular users' rights with respect to specific keys.
  • A [0110] remote computer system 1610 connects to a key repository 1620 through a network 1630. The network 1630 is preferably a data network, such as the Internet, but it is understood that the network 1630 can be other types of networks, such as the telephone network, wireless networks, such as 802.11b, Bluetooth™ or other wireless networks, local area networks, wide area networks, or optical fiber networks. In one embodiment, the computer system 1610 contains a smart card reader 1632, which is operable to enable a user to authenticate himself or herself to the repository core engine 1620. Further, the remote computer system 1610 contains a remote key exchange module 1630, which is operable to exchange keys with the key exchange module 1634 of the key repository 1620. In one embodiment, the remote computer system 1610 also contains a storeless remote core engine 1642 that is operable to perform remote encryption and decryption functions on the remote computer system 1610. A storeless remote engine has no internal key database and must communicate with a repository server to obtain keys to encrypt or decrypt data.
  • A [0111] business application 1612 is also preferably associated with the remote computer system 1610. The business application 1612 is generally software that consumes and produces information that is protected by cryptographic methods and systems consistent with the present invention.
  • FIG. 17 is a schematic block diagram illustrating a [0112] system 1700 involving a file server 1720, a repository server 1620, and a remote computer system 1610 in a group of remote computer systems. The file server 1720 includes a data store 1722, which contains information that is protected with cryptographic methods and systems consistent with the present invention. The information contained in the data store 1722 is encrypted and decrypted in connection with the remote computer system 1610, using the remote core engine 1642, which performs the functions of encrypting and decrypting information using keys from the repository server 1620, which optionally contains a smart card reader 1632, a repository key exchange module 1634, and an authentication/authorization (A/A) module 1636. The repository server 1620 also contains a user database 1626 and an ACL database 1624. The remote computer system 1610 optionally uses a smart card reader 1632 and a remote key exchange module 1630 to authenticate with the A/A module 1636 of the repository server 1620 to obtain appropriate keys to encrypt and decrypt information in the media store 1620. The remote core engine 1622 performs encryption and decryption functions.
  • In connection with the cryptographic systems of FIGS. 16 and 17 several operations are performed, including: (i) adding a user to the cryptographic system; (ii) providing an interface for a user to log in and to thereby authenticate himself or herself to the cryptographic system; (iii) encrypting a new file; (iv) maintaining, which is accessing or changing, ACLs associated with keys; (v) blocking access to a key that has become compromised; reassigning ownership of a cryptographic key; and (vi) accessing and decrypting existing information for use in connection with a software application. [0113]
  • The process of adding a new user optionally involves generating exchange and signature key pairs for users. In one embodiment, the key pairs are written to a smart card. The exchange key is used for transporting session keys between the [0114] repository server 1620 and the remote computer system 1610. The signature key is used to authenticate the user via the A/A module 1636.
  • In one embodiment, the public keys associated with the newly generated user key pairs are stored in the [0115] user database 1626. Optionally, other information, such as name and contact information for a user can be stored in the user database 1626. Further, the user takes possession of the smart card containing the key pairs so the user can perform authentication and key exchange operations in connection with the use of encrypted information.
  • In connection with the smart card, the user logs into the cryptographic system by authenticating to the A/[0116] A module 1636 of the repository server 1620. First, the user places his or her smart card into the smart card reader 1632 and the remote core engine 1642 reads the keys from the smart card. The smart card is preferably password protected.
  • Once the [0117] remote core engine 1642 has access to the private key of the signature key pair, it authenticates itself to the repository server 1620 by way of the A/A module 1636. In one embodiment, the A/A module 1636 and the remote computer system 1610 execute a challenge response protocol in connection with the user's signature key pair. In this embodiment, the A/A module verifies a signature made by the remote computer system 1610 by using the public key stored in the user database 1626 that was generated at the same time as the user's private key, when the user account was created. Next, the remote computer system optionally receives a session-level access token, for example a large random number, in connection with the challenge response protocol. In an alternative embodiment, a user authenticates using its user identifier and, for example, password. In one embodiment, user and agent rights are granted based on rights associated with a role that is assigned to the user or agent. Further, if the user or agent has sufficient rights, an ACL corresponding to a particular key is examined to determine whether the user or agent has sufficient rights to cause the key to be used to encrypt or decrypt data.
  • FIG. 18A is a schematic block diagram illustrating intradepartmental data protection consistent with the present invention. In this embodiment, the cryptographic engines are represented in connection with the TRICRYPTION trademark of ERUCES, Inc. of Lenexa, Kans. The environment broadly includes a [0118] data store 1802, computer systems 1804 and 1808, and repository server 1806. The data store 1802 contains, for example, encrypted files that are manipulated by computer systems 1804, 1808. The remote computer systems 1804, 1808 read and write the encrypted data in data store 1802 in a manner similar to that explained in connection with FIG. 15. However, in this embodiment, encryption and decryption is performed on the same computer system that manipulates the information, namely systems 1804, 1808. To accomplish this, remote computer system 1804 uses its remote key exchange module to obtain keys from repository server 1806 as explained in connection with FIGS. 16 and 17. Specifically, the remote computer systems 1804, 1808 manipulate the encrypted information in data store 1802 using session keys obtained from the repository server 1806.
  • FIG. 18B is a schematic block diagram illustrating interdepartmental data protection consistent with the present invention. In this embodiment, information contained in the [0119] data store 1802 is accessed by remote computer systems 1804, 1808 that are in separate departments or enterprises. Accordingly, user authentication and authorization information associated with a particular user of remote computer systems 1804 and 1808 resides in a corresponding repository server 1806 or 1807 in the user's department.
  • It may be useful for the user of the [0120] remote computer system 1804 to access information for which the user of the remote computer system 1808 is the key owner. If a user needs to access information protected by a key contained in a repository server located in another department, then interdepartmental key exchange is employed. To accomplish interdepartmental key exchange, repository server 1806 and repository server 1807 exchange keys using mechanisms described in connection with FIGS. 16 and 17. Once a user's departmental repository server has received the appropriate session key from a peer departmental repository server, the local repository server can either provide the key to a storeless cryptographic engine, such as computer system 1804 or perform the encryption or decryption for an agent directly in the core engine of the storeful repository server.
  • FIG. 18C is a schematic block diagram illustrating data protection in connection with an Intranet or extranet based key repository. In this embodiment, the [0121] repository server 1806 is separated from the remote computers 1804 and 1808 by a public network 1810 and optional firewalls 1812. Because of the secure nature of the key exchange between repository server 1806 and remote computer systems 1804 and 1808, exchanging keys over the public network is secure, and the keys can be used to manipulate the encrypted data in data store 1802.
  • FIG. 18D is a schematic block diagram illustrating mobile data protection. In this embodiment, [0122] mobile computer 1816 is connected through wireless access point 1814. The mobile computer 1816, such as a personal digital assistant, contains a version of a storeless cryptographic engine that is capable of performing key exchange with repository server 1806. The mobile computer system 1816 can securely retrieve the encrypted data from data store 1802 over the public network 1810 through optional firewall 1812 because of the strong cryptography used to store the information in data store 1802, and the mobile computer can securely receive session keys from repository server 1806 using key exchange methods described above.
  • FIG. 18E is a schematic block diagram illustrating data protection in a multiple enterprise environment. In this embodiment, information can be securely shared between enterprises over the [0123] public network 1810. Data store 1802 contains encrypted information that can be provided to internal users via application server 1820 and to users of peer enterprises through their application servers, for example application server 1830. Secure and granular sharing of information between enterprises over the public network 1810, through optional firewalls 1812, is possible because of the secure key exchange between repository servers 1806 and 1816 that reside in different enterprises. Trust is optionally established between the repository servers 1806 and 1816 by way of signed certificates from certification authority 1832, such as VeriSign Inc. of Mountain View, Calif.
  • FIG. 19 is a schematic block diagram illustrating an embodiment of tables corresponding to key management, access control, and user databases. A protection key information table [0124] 1902 has the primary key of protection key identifier (protectionkeyid). The protection key information table 1902 contains the columns of “created,” which is a time stamp, “keyblob,” which is an encrypted binary representation of the protection key, and a signature which is, for example an HMAC data authenticator. In one embodiment, the “keyblob” field is encrypted in a master key that is protected at rest by a K of M encryption scheme. An session key information table 1904 is also provided. The session key information table has a primary key called “SEKID,” which corresponds to an unencrypted SEKID. Accordingly, once a core engine decrypts an SEKID from a hidden link, it can identify and decrypt “keyblob” from the session key information table 1904. The session key “keyblob” is preferably encrypted with the same protection key as the SEKID. In the session key information table 1904 and the other tables illustrated in FIG. 19, the “created” and “signature” fields are analogous to the “created” and “signature” fields described in connection with the protection key information table 1902.
  • A principal information table [0125] 1906 has primary database keys of “principal” which corresponds to the name of a user, agent, or server that accesses a cryptographic system consistent with the present invention. The “roles” field corresponds to the roles assigned to a particular principal. The “flags” field corresponds to status indicators associated with the principal, e.g. disabled principal or non-disabled principal. The “subclassname” field is used to indicate, for example whether the principal uses user name/password authentication or X.509 authentication.
  • User and password information table [0126] 1908 and X.509 principal information table 1910 are related to the principal information table 1906. The user and password information table 1908 contains user identifiers and password information for corresponding users. In one embodiment the “password” field contains an encrypted SHA-1 hash of the password initially set by the user. In this embodiment, the “password” hash is encrypted with a master key that is protected by a K of M encryption scheme. The X.509 principal information table 1910 contains certificates corresponding to principals, for example the certificates of remote cryptography servers that exchange keys with the presently described core engine. ACL information table 1912 has a primary database key of an ACL identifier used to relate the table to an ACL entry table 1914. The ACL information table contains one record for each key, including the key's hidden link, the ACL's creation time and the key's expiration flag. The ACL entry table 1914 has a primary key including an ACL identifier a principal identifier and a system identifier, which corresponds to a core engine identifier that uniquely identifies the particular core engine that generated the key.
  • A role table [0127] 1916 has a role identifier (roleid), a role name, a list operation identifier, and a role type, which identify and define the rights associated with a particular role. The operation table 1918 contains an operation identifier and operation names, which are used to associate names of operations with actual operations that a user is authorized to perform in connection with a particular core engine.
  • Audit log table [0128] 1920 and transaction log table 1922 are used to collect records that define events as they take place in a core engine. The audit log table 1920, for example contains information about the principal that performed a particular operation. The transaction log table 1922 contains information about, for example encryptions and decryptions that were performed by the core engine.
  • FIG. 20 is a schematic block diagram illustrating a process of encrypting a file. First a request for a key is made by a user at the cryptographic server (stage [0129] 140). Next, the repository core engine optionally creates and transmits a session key to the key exchange module (stage 142). Next, the repository engine receives the user's exchange public key (stage 144). The exchange public key is the public key associated with the exchange key pair that is used to exchange session keys between key exchange modules. Next, the key repository encrypts the session in the exchange public key (stage 146). Next, the key exchange module informs the A/A module that the user created a new session key (stage 148). A new session key can be created, for example, when the application elects to cause generation of a new key by saving a new data object or saving an existing data object without providing a corresponding hidden link. Next, the A/A module adds information about key ownership into the ACL database (stage 150). In one embodiment, the owner of a key has full access to information protected by the key. Further, in this embodiment, the owner can grant rights to information protected by the key to other users. Next, the server key exchange module 1530 sends a session key and a hidden link to the remote computer system, encrypted in the user's exchange public key (stage 152). Next, the user decrypts the session key using the private key associated with the exchange key pair (stage 154). Next, the remote core engine 1540 encrypts the user data and the user application embeds the hidden link into a data structure, such as a file structure, associated with the user data (stage 156).
  • FIG. 21 is a schematic block diagram illustrating a process of maintaining an access control list (ACL) of a key. First, a user requests the ACL of an existing key from the key repository, and the A/A module receives the ACL request (stage [0130] 160). Next the A/A module queries the user and ACL databases to determine whether the user has adequate rights to view an ACL associated with a particular key (stage 162). In one embodiment, information regarding other users having rights associated with the key is obtained from the user database. Next, user information is obtained from the user database and the ACL database and the ACL is transmitted to the user (stage 164). Next, the ACL is optionally modified by the client, for example to add or remove rights in a particular key to a particular user (stage 166). Next, the A/A module verifies that the user has adequate rights, for example by reference to the original ACL, to modify the ACL (stage 168). Finally, the key repository makes appropriate changes to the ACL within the ACL database (stage 170).
  • FIG. 22 is a schematic block diagram illustrating a process of accessing an encrypted file. First, a file server provides encrypted information to the user, by way of the remote computer system (step [0131] 180). Next, the repository server verifies that the user has the rights to access the key necessary to decrypt the information provided by the file server (stage 182). Next, the key is transmitted to the key exchange manager (stage 184). The repository server then retrieves the User's exchange public key from the user database (stage 186). Next, the repository key exchange manager re-exports the session key (stage 188). Next, the repository key exchange module sends the encrypted session key to the user, encrypted in the user's exchange public key (stage 190). Next, the user decrypts the session key using the user's exchange private key (stage 192). Further, the remote computer system decrypts the user data (stage 194).
  • FIG. 23 is a schematic block diagram illustrating a process of blocking access associated with a key in response to the key becoming compromised. First, the repository server receives information regarding a compromise of a remote computer system or of a smart card (stage [0132] 196). Next, the repository operator receives a connection from an authorized representative of the user (stage 198). Further, if the authorized representative is successfully authenticated, the keys are disabled, for example by removing all users from the ACL associated with the compromised key (stage 200).
  • In one embodiment, trusted software components are executed in connection with cryptographic systems consistent with the present invention. The purposes of using trusted components in connection with a cryptographic system include the ability to verify the identity and authenticity of software. Verification of software is important, because the introduction of rogue software into a functioning cryptographic system can defeat the cryptographic system. [0133]
  • One way to determine the authenticity of software is to verify its identity. In general, identity can be established based on something's inherent characteristics, based on knowledge of a secret, or based on possession of something, for example a credential or a secret. However, knowledge of a secret or possession of a secret such as an embedded key has proved to be problematic. For example, persistent computer users have been able to locate and extract keys hidden within software. Accordingly, establishing identity based on software's inherent characteristics is preferred. But merely having the name of a file containing source code is insufficient to establish identity. A “fingerprint” that uniquely identifies the file is preferred. A fingerprint can be verified at run-time before executing software to verify the identity of the software. [0134]
  • FIG. 24 is a schematic block diagram illustrating a system in which trusted components are authenticated. An [0135] application server 2410 and a registration server 2430 are provided. It is understood that the application server 2410 and the registration server 2430 can be implemented as separate threads or processes on a single computer system. Alternatively, the application server 2410 and the registration server 2430 are implemented on separate computer systems. A cryptography server 2420 is used in connection with the application server 2410 and the registration server 2430 to provide cryptographic functions in connection with the verification of trusted components.
  • The [0136] application server 2410 optionally includes a smart card reader 2412 that reads key information from a smart card. Token dispenser 2414 provides a cryptographic token in connection with verification of trusted components. Cryptographic Agent 2418 provides the cryptographic functions necessary for the application server 2410 to communicate securely with the cryptography server 2420 and to authenticate a business application 2416. The registration server 2430 includes the smart card reader 2412 and a trusted component manager 2434 that is used to gather and process information about trusted components.
  • The [0137] cryptography server 2420 includes a registration database 2426 and the optional smart card reader 2412, Further, the cryptography server 2420 includes a core engine 2422, which also contains a key database 2424, containing cryptographic keys. Trusted component authentication systems are further described in connection with FIGS. 24-27.
  • FIG. 25 is a schematic block diagram illustrating a process of creating smart cards. In one embodiment, two secret cryptographic keys are generated during the installation or configuration of the [0138] cryptography server 2420. First, an operational key is generated (stage 202). In one embodiment, the operational key is used to secure communication between the cryptographic agent and the cryptography server. In one embodiment, the operational key is read into separate machines containing the cryptographic agent and the cryptographic server from a smart card. In this embodiment, a “fingerprint” corresponding to the cryptographic agent is also contained in the smart card. Using the stored “fingerprint” of the cryptographic agent, the cryptographic server can verify the authenticity of the cryptographic agent. Next, a registration key is generated (stage 203). The registration key is used by a system administrator during the registration process to register a trusted component. Next, the operational key is placed into an operational smart card (stage 204), and the operational key is optionally signed, for example by a trusted entity (stage 206). In one embodiment, the operational key is signed with a signing key associated with the cryptography server 2420. Next, the registration key is placed in a registration smart card (stage 208). Further, the registration key is signed by a trusted signer (stage 210).
  • FIG. 26 is a schematic block diagram illustrating a process of registering components. First, the trusted [0139] component manager 2434 receives software in the form of electronic computer code associated with a software component, such as business application 1542 (stage 212). Next, the trusted component manager 2434 determines the name of the component, for example by performing an operating system call to determine the name of a file associated with the component (stage 214). Next, the trusted component manager 2434 calculates a “fingerprint” of the trusted component, for example by applying a hash function like MD5 or SHA-1 to the component (stage 216). Next, the trusted component manager 2434 reads the registration key from the registration smart card (stage 218). Accordingly, users that do not have access to the registration smart card do not have the ability to register a component. Next, using the registration key, the trusted component manager 2434 uses the registration key pair to perform a challenge response protocol with the cryptography server (stage 220) and to securely send the component's information to the cryptography server (stage 222). Further, the cryptography server signs the newly registered component's registration information, including, for example, the “fingerprint” (stage 224), and the registration information is stored in a database.
  • Upon restart of the [0140] application server 2410, token dispenser 2414 receives information from the operational smart card by way of the smart card reader 2412. In one embodiment, after the smart card is inserted, a user must provide a password.
  • FIG. 27 is a schematic block diagram illustrating a process of performing run-time authentication of components. First, the [0141] business application 2416 submits a request to cryptographic agent 2418 to operate as a trusted component. The cryptographic agent 2418 receives the request (stage 226). Next, the cryptographic agent determines the name of the application and calculates its digital “fingerprint” (stage 228). Next, the cryptographic agent 2418 transmits a request for challenge to cryptography server 2420 regarding the application (stage 230). Next, cryptography server 2120 generates a random challenge and calculates the correct response based on the operational key and the application “fingerprint” (stage 232). Next, cryptography server 2420 presents the challenge to the cryptographic agent 2418 (stage 234) and the agent performs a first part of the response calculation using the application's fingerprint by, for example combining the fingerprint with the challenge (stage 236). Next, the agent instructs the token dispenser 2414 to complete the calculation of the challenge (stage 238). Next, the token dispenser verifies the integrity of the agent, for example by comparing the stored fingerprint with the actual fingerprint of the operational agent as it is executing in memory and the token dispenser completes the response calculation, for example by computing a HMAC of the challenge and fingerprint combination using the operational key as the key in the HMAC calculation. (stage 240). Further, the cryptography server 2420 verifies the response to the challenge by verifying the HMAC with the operational key and comparing the calculated fingerprint with the stored fingerprint (stage 242) and validates the application as a trusted component.
  • The present invention has important benefits and advantages. Because cryptographic keys are not stored in software components, known techniques cannot be used to extract the keys and defeat the cryptographic system. Protected data items contain an associated hidden link that provides the identity of the associated cryptographic key within the key store. Further, instead of having a few keys for all of the protected information, a different key is used to protect discrete pieces of information, for example a different key is used for each protected file on a file server or for each protected record in a database. In one embodiment, the key store is located in a centralized key repository resulting in the advantage of simplified backup and disaster recovery procedures. Further, the keys themselves are encrypted in the key repository and the keys are not identifiable with their respective protected data item. Accordingly, without knowledge of the hidden link within a protected data object, even possession of the key repository does not allow an intruder to achieve access to actual data. [0142]
  • Additional benefits and advantages of the present invention involve the distributed nature of the cryptographic systems and methods, in that while keys are centrailzed in one or more key repositories, cryptographic computations are performed on remote computer systems that are closer to the actual producers and consumers of the protected data. Accordingly, the computational power of the remote computer systems is leveraged and computational efficiencies are achieved over systems in which cryptographic computations are performed centrally. [0143]
  • The above described computer system and database structure are utilized in the method of encrypting, storing, retrieving, and decrypting data. When a client user requests a data manipulation including add, update, and view requests, the computer system will implement the appropriate steps. For each transaction, it is assumed that the client user has already gained access to the business domain using a trusted authentication method, such as smart cards, two-factor authentication devices, or user name and password. [0144]
  • GLOSSARY
  • Asymmetric Key Cryptography: Cryptography that uses a different key to encrypt and to decrypt information. For example, in public key cryptography, a public key is used to encrypt information, but the public key cannot be used to decrypt the information. Only a private key associated with the public key can decrypt the encrypted information. [0145]
  • Attribute/Field: A category of data saved in an object. [0146]
  • Business Logic Component (BLC): A component in the computer system accessible by the client to establish and change business rules controlling operation of the system and what data will or will not be encrypted. [0147]
  • Certificate Manager (CM): Controls the system key PKI related operations and communicates with the private certification authority responsible for issuing and verifying digital certificates for the system keys. [0148]
  • Cipher Text: Encrypted data. [0149]
  • Class: According to object-oriented programming, a category of objects. [0150]
  • Database Adapter (DBAD): Software component, which allows the security domain components to save and retrieve data on various types of databases and multiple databases. [0151]
  • Data Encryption Standard (DES): A symmetric-key algorithm established by the U.S. government that uses a 56-bit key. [0152]
  • Decryption: Changing data from cipher text to plain text. [0153]
  • Digital Certificate: An data structure used to ensure the authenticity of a public key. A typical digital certificate includes a signed collection of certificate holder information, a public key, an identification of the certificate issuer, and the serial number of the certificate. [0154]
  • Encryption: The translation of data into a secret code. [0155]
  • Encryption Key Manager (EKM): A software component of the computer system, which manages the session encryption keys including generation, replacing, and other tasks. [0156]
  • Fault Tolerance: The ability of a system to continue operation in the event of unexpected hardware or software failures. [0157]
  • General Security Manager (GSM): A software component, which operates as a gatekeeper to the security domain and performs hashing, encryption and decryption functions. [0158]
  • Hardware Random Number Generator (HRNG): A device used to generate numbers randomly for the SEKID. [0159]
  • Hashing: Generating a number from a string of text that is substantially smaller than the text itself. In connection with a “one-way” hash function, the hash value effectively cannot be used to determine the text used to generate the hash value. The hash value or integrity value is used for search queries to identify an appropriate data object and for security integrity checks. [0160]
  • Internet Protocol (IP): Specifies the format of information and the addressing scheme for transmission of information over the Internet. [0161]
  • Internet Protocol Security (IPSEC): A set of protocols to support secure exchanges of information at the Internet protocol layer. [0162]
  • IP Spoofing: Attempting to make a message appear as if it came from an authorized Internet protocol address. [0163]
  • Key: A password or table needed to decipher encrypted data. [0164]
  • Key Auditing Manager (KAM): Maintains an active audit log about all EKM and SKM operations with the ability to send alarms and notifications to recipients based on policies and rules. [0165]
  • Key Lifetime Manager (KLM): Monitors the SEK's for expiration and deactivates expired SEK's or alternatively flags SEK's to be deactivated in the next request or call. [0166]
  • Memory (RAM): Random access memory. [0167]
  • Message Digest 5 (MD5): A one-way hash function, which takes a message and converts it to a hash value, or message digest, of a particular size. It is called a one-way hash function because it is nearly impossible to reverse the process, converting the hash value to the original message. [0168]
  • Object: A self-contained entity consisting of both data and procedures, or methods, to manipulate the data. [0169]
  • Object Oriented: Refers to a special type of programming that combines data structures with functions or methods to create reusable and extensible program elements called objects. [0170]
  • Plain Text: Unencrypted data. [0171]
  • Public Key Infrastructure (PKI): A collection of hardware and software systems to facilitate reliable use of public key cryptography, including certification authorities to certify digital certificates, and other registration authorities that verify and authenticate the validity and identity of parties involved with signing or receiving encrypted messages using public key cryptography. [0172]
  • Secure Hash Algorithm (SHA-1): Another one-way hash function. [0173]
  • Secure Key Database (KEYDB): A database inside the security domain on which the SEK's and SEKID's are saved. [0174]
  • Secure Sockets Layer (SSL): A protocol developed for transmitting information securely over the public Internet. [0175]
  • Session Encryption Key (SEK): A key used to encrypt and decrypt data over the course of a session, which is a period during which data is being accessed. [0176]
  • Session Encryption Key Identifier (SEKID): A randomly generated identification number for the SEK. [0177]
  • Smart Card: A small electronic device about the size of a credit card that contains electronic memory. It may include an integrated circuit. [0178]
  • Symmetric Key Encryption: An encryption system in which data is both encrypted and decrypted using the same key. [0179]
  • System Key Pair: An asymmetric key pair that is used to encrypt and decrypt the SEKID's. [0180]
  • System Key Common Name (SKCN): System key digital certificate serial number and subject common name. [0181]
  • System Key Manager (SKM): Manages system keys including generation, verification, and other tasks. [0182]
  • Virtual Private Network (VPN): A virtual connection over a public network for conducting private exchange of information using cryptographic techniques. [0183]
  • X.509: A widely used standard for defining digital certificates. [0184]

Claims (21)

1. A computer system containing cryptographic keys and cryptographic key identifiers, the computer system comprising:
a repository cryptographic engine operable to communicate securely with a remote cryptographic engine, the repository cryptographic engine associated with a user data store having at least one hidden link including a session key identifier encrypted with at least one protection key, the hidden link associated with at least one remote data entity;
at least one session key encrypted with at least one session-key-protection key, the session key operable to be used in connection with cryptographic operations on the remote data entity; and
a repository key exchange module operable to exchange the session key with a remote key exchange module.
2. The computer system according to claim 1, wherein the session key identifier is operable to identify the session key corresponding to the remote data entity.
3. The computer system according to claim 1 further comprising:
an authorization module coupled with at least one access control list, wherein access to operations based on the session key is provided based on the access control list.
4. The computer system according to claim 3, wherein the authorization module is further coupled with a user data store and wherein access to the session key is further provided based on the user data store.
5. The computer system according to claim 1, wherein the protection key is a symmetric cryptographic key.
6. The computer system according to claim 1, wherein the session-key-protection key is a symmetric cryptographic key.
7. The computer system according to claim 1, wherein the session-key-protection key and the protection key are equivalent.
8. The computer system according to claim 6, wherein the symmetric cryptographic key is used in connection with the triple Data Encryption Standard.
9. The computer system according to claim 6, wherein the symmetric cryptographic key is used in connection with the Advanced Encryption Standard.
10. The computer system according to claim 1, wherein the hidden link is associated with the remote data entity.
11. The computer system according to claim 10, wherein the remote data entity is a file and the hidden link is embedded into a header of the file.
12. A distributed network including a repository server containing cryptographic keys, the distributed network comprising:
a repository cryptographic engine operable to communicate securely with a remote cryptographic engine;
a remote cryptographic agent operable to communicate securely with the remote cryptographic engine; and
a business application coupled with the remote cryptographic agent, wherein authenticity of the business application is verified by the remote cryptographic engine by comparing a stored fingerprint of the business application with a calculated fingerprint of the remote cryptographic agent.
13. The distributed network according to claim 12, wherein the remote cryptographic agent and the remote cryptographic engine are resident in separate computer systems.
14. The distributed network according to claim 12, wherein secure communication between the remote cryptographic agent and the remote cryptographic engine is secured using a shared operational key.
15. The distributed network according to claim 14, wherein the shared operational key is received by the remote cryptographic agent and the remote cryptographic engine from a smart card.
16. A computer readable data transmission medium containing a data structure for facilitating the secure exchange and use of encrypted data, the data structure comprising:
at least one data entity encrypted by at least one encryption key;
at least one key association that associates the data entity with the encryption key; and
instructions operable to receive commands from an application software component to generate a new encryption key, to store the data entity in encrypted form, and to transmit an unencrypted form of the data entity to the application software component, the commands proxied through a trusted cryptographic agent.
17. A cryptographic method for facilitating the secure storage of information, the method comprising:
receiving a key request for a session key from a requesting key exchange module at a remote computer system, the key request including a hidden link;
accessing and decrypting the session key based on the hidden link using a protection key;
receiving an exchange public key corresponding to the requesting key exchange module;
encrypting the session key in the exchange public key, resulting in an encrypted session key;
transmitting the encrypted session key to the requesting key exchange module;
decrypting, at a computer system associated with a requester, the encrypted session key with an exchange private key corresponding to the exchange public key;
encrypting a data entity with the session key, and attaching the hidden link to the data entity; and
storing the data entity.
18. A cryptographic method for facilitating the secure retrieval of information, the method comprising:
providing at least one encrypted data entity to a requester;
receiving access control information corresponding to the requester;
determining whether the requester has sufficient access rights to decrypt the encrypted data entity;
transmitting a session key to a key exchange module, the session key corresponding to the encrypted data entity;
receiving an exchange public key from a user database;
encrypting the session key in the exchange public key, resulting in an encrypted session key;
transmitting the encrypted session key to the requester;
decrypting the encrypted session key at a computer system associated with the requester using an exchange private key corresponding to the exchange public key; and
decrypting the encrypted data entity with the session key.
19. A cryptographic method for facilitating the secure processing of information using trusted components, the method comprising:
receiving electronic code associated with a software component;
receiving a component identifier associated with the software component;
calculating a fingerprint associated with the electronic code;
reading a registration key from a registration key source;
executing a registration challenge response protocol using the registration key, whereby authority to register the software component is demonstrated;
storing registration information and the fingerprint in connection with the component identifier of the software component;
receiving request from the software component at a cryptographic agent to perform an authorized cryptographic operation; and
transmitting a request for challenge to a cryptography server regarding the software component;
providing a challenge to agent;
receiving a response to the challenge;
verifying the response to the challenge including calculating the fingerprint and verifying an operational key.
20. The method as set forth in claim 19, wherein the registration key source is a registration smart card.
21. A cryptographic system for facilitating the secure processing of information, the system comprising:
means for providing at least one encrypted data entity to a requester;
means for receiving access control information corresponding to the requester;
means for determining whether the requester has sufficient access rights to access the encrypted data entity;
means for transmitting a session key to a key exchange module, the session key corresponding to the encrypted data entity;
means for receiving an exchange public key from a user database;
means for encrypting the session key in the exchange public key, resulting in an encrypted session key;
means for transmitting the encrypted session key to the requester;
means for decrypting the encrypted session key at a computer system associated with the requester using an exchange private key corresponding to the exchange public key; and
means for decrypting the encrypted data entity with the session key.
US10/146,782 2000-10-20 2002-05-15 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data Abandoned US20030021417A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US10/146,782 US20030021417A1 (en) 2000-10-20 2002-05-15 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
PCT/US2003/015569 WO2003098864A1 (en) 2002-05-15 2003-05-15 Hidden link dynamic key manager for use in computer systems
EP03728985A EP1510030A4 (en) 2002-05-15 2003-05-15 Hidden link dynamic key manager for use in computer systems
AU2003233549A AU2003233549A1 (en) 2002-05-15 2003-05-15 Hidden link dynamic key manager for use in computer systems
CNA03816860XA CN1669265A (en) 2002-05-15 2003-05-15 Hidden link dynamic key manager for use in computer systems
US11/931,116 US7885413B2 (en) 2000-10-20 2007-10-31 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/693,605 US7362868B2 (en) 2000-10-20 2000-10-20 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US10/146,782 US20030021417A1 (en) 2000-10-20 2002-05-15 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/693,605 Continuation-In-Part US7362868B2 (en) 2000-10-20 2000-10-20 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/931,116 Continuation US7885413B2 (en) 2000-10-20 2007-10-31 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data

Publications (1)

Publication Number Publication Date
US20030021417A1 true US20030021417A1 (en) 2003-01-30

Family

ID=29548293

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/146,782 Abandoned US20030021417A1 (en) 2000-10-20 2002-05-15 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US11/931,116 Expired - Fee Related US7885413B2 (en) 2000-10-20 2007-10-31 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/931,116 Expired - Fee Related US7885413B2 (en) 2000-10-20 2007-10-31 Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data

Country Status (5)

Country Link
US (2) US20030021417A1 (en)
EP (1) EP1510030A4 (en)
CN (1) CN1669265A (en)
AU (1) AU2003233549A1 (en)
WO (1) WO2003098864A1 (en)

Cited By (114)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040086121A1 (en) * 2002-10-31 2004-05-06 Sensis Corporation Secure automatic dependant surveillance
US20040109567A1 (en) * 2002-12-05 2004-06-10 Canon Kabushiki Kaisha Encryption key generation in embedded devices
US20040153646A1 (en) * 2003-01-30 2004-08-05 Smith Ned M. Distributed control of integrity measurement using a trusted fixed token
US20040158635A1 (en) * 2003-01-23 2004-08-12 Digi International Inc.. Secure terminal transmission system and method
US20040193876A1 (en) * 2003-03-27 2004-09-30 Donley Christopher J. Method to authenticate packet payloads
US20040250169A1 (en) * 2003-04-17 2004-12-09 Kddi Corporation IDS log analysis support apparatus, IDS log analysis support method and IDS log analysis support program
US20040268124A1 (en) * 2003-06-27 2004-12-30 Nokia Corporation, Espoo, Finland Systems and methods for creating and maintaining a centralized key store
EP1510901A2 (en) * 2003-08-29 2005-03-02 Matsushita Electric Industrial Co., Ltd. Secure data management apparatus
US20050125674A1 (en) * 2003-12-09 2005-06-09 Kenya Nishiki Authentication control system and authentication control method
US20050165623A1 (en) * 2003-03-12 2005-07-28 Landi William A. Systems and methods for encryption-based de-identification of protected health information
US20050172143A1 (en) * 2004-01-30 2005-08-04 Fearnley Daniel P. Method and apparatus for secure data storage
US20050193214A1 (en) * 2004-02-28 2005-09-01 Mi-Jung Noh Engine, register and methods for the same
US20050254656A1 (en) * 2004-03-18 2005-11-17 Qualcomm Incorporated Efficient transmission of cryptographic information in secure real time protocol
US20050256742A1 (en) * 2004-05-05 2005-11-17 Kohan Mark E Data encryption applications for multi-source longitudinal patient-level data integration
US20050254653A1 (en) * 2004-05-14 2005-11-17 Proxim Corporation Pre-authentication of mobile clients by sharing a master key among secured authenticators
US20050268094A1 (en) * 2004-05-05 2005-12-01 Kohan Mark E Multi-source longitudinal patient-level data encryption process
US20050283620A1 (en) * 2004-06-17 2005-12-22 Bassam Khulusi System and method for dis-identifying sensitive information and associated records
US20060031256A1 (en) * 2004-05-20 2006-02-09 Bea Systems, Inc. Template language for mobile client
US20060075479A1 (en) * 2004-10-04 2006-04-06 Harald Hagedorn Data processing system and method
EP1645984A1 (en) * 2004-10-08 2006-04-12 FeliCa Networks, Inc. Information processing apparatus, information processing method, and program
US20060080322A1 (en) * 2004-10-08 2006-04-13 Felica Networks, Inc. Information processing apparatus, information processing method, and program
US20060126850A1 (en) * 2004-12-09 2006-06-15 Dawson Colin S Apparatus, system, and method for transparent end-to-end security of storage data in a client-server environment
US20060126520A1 (en) * 2004-12-15 2006-06-15 Cisco Technology, Inc. Tape acceleration
WO2007017884A1 (en) * 2005-08-05 2007-02-15 Hewlett-Packard Development Company L.P. System, method and apparatus to obtain a key for encryption/decryption/data recovery from an enterprise cryptography key management system
US20070078994A1 (en) * 2005-10-03 2007-04-05 Kabushiki Kaisha Toshiba And Toshiba Tec Kabushiki Kaisha System and method for automatic wireless detection and identification of document processing service location
US20070100830A1 (en) * 2005-10-20 2007-05-03 Ganesha Beedubail Method and apparatus for access control list (ACL) binding in a data processing system
US20070101134A1 (en) * 2005-10-31 2007-05-03 Cisco Technology, Inc. Method and apparatus for performing encryption of data at rest at a port of a network device
US20070143210A1 (en) * 2005-10-12 2007-06-21 Kabushiki Kaisha Toshiba System and method for embedding user authentication information in encrypted data
US20070174093A1 (en) * 2005-09-14 2007-07-26 Dave Colwell Method and system for secure and protected electronic patient tracking
US20070220007A1 (en) * 2006-03-17 2007-09-20 International Business Machines Corporation Method and system for electronic authentication
US20070239986A1 (en) * 2006-04-07 2007-10-11 Sensis Corporation Secure ADS-B authentication system and method
US20070300062A1 (en) * 2006-06-27 2007-12-27 Osmond Roger F Identifying and enforcing strict file confidentiality in the presence of system and storage administrators in a nas system
US20070297589A1 (en) * 2005-09-14 2007-12-27 Greischar Patrick J Method and system for data aggregation for real-time emergency resource management
US20080016354A1 (en) * 2003-08-26 2008-01-17 International Business Machines Corporation System and Method for Secure Remote Access
US20080046285A1 (en) * 2006-08-18 2008-02-21 Greischar Patrick J Method and system for real-time emergency resource management
US20080077806A1 (en) * 2006-09-27 2008-03-27 International Business Machines Corporation Encrypting and decrypting database records
EP1967979A2 (en) * 2007-03-09 2008-09-10 Quantum Corporation Cryptographic key management for stored data
US20080263645A1 (en) * 2007-04-23 2008-10-23 Telus Communications Company Privacy identifier remediation
US20080292105A1 (en) * 2007-05-22 2008-11-27 Chieh-Yih Wan Lightweight key distribution and management method for sensor networks
EP2016701A1 (en) * 2006-04-25 2009-01-21 Stephen Laurence Boren Dynamic distributed key system and method for identity management, authentication servers, data security and preventing man-in-the-middle attacks
WO2009012165A2 (en) 2007-07-13 2009-01-22 Microsoft Corporation Creating and validating cryptographically secured documents
US7496762B1 (en) * 2004-10-07 2009-02-24 Sprint Communications Company L.P. Security architecture for modified segregated environment for federal telecom services
US7527192B1 (en) * 2005-12-15 2009-05-05 At&T Corp. Network based method of providing access to information
US20090208017A1 (en) * 2008-02-20 2009-08-20 International Business Machines Corporation Validation of encryption key
US20090271633A1 (en) * 2008-03-10 2009-10-29 Aceinc Pty Limited Data Access and Identity Verification
US20090296937A1 (en) * 2008-05-27 2009-12-03 Kabushiki Kaisha Toshiba Data protection system, data protection method, and memory card
US20100017625A1 (en) * 2003-11-20 2010-01-21 Johnson Richard C Architecure, system, and method for operating on encrypted and/or hidden information
US7676681B2 (en) 2003-06-17 2010-03-09 Veratad Technologies, Llc Method, system, and apparatus for identification number authentication
US7681046B1 (en) 2003-09-26 2010-03-16 Andrew Morgan System with secure cryptographic capabilities using a hardware specific digital secret
US20100161995A1 (en) * 2008-12-19 2010-06-24 James Browning System, method, and computer-readable medium for cryptographic key rotation in a database system
US20100250939A1 (en) * 2009-02-26 2010-09-30 Research In Motion Limited System and method of handling encrypted backup data
US8069270B1 (en) 2005-09-06 2011-11-29 Cisco Technology, Inc. Accelerated tape backup restoration
US8099605B1 (en) 2006-06-05 2012-01-17 InventSec AB Intelligent storage device for backup system
US8196182B2 (en) 2007-08-24 2012-06-05 Netapp, Inc. Distributed management of crypto module white lists
US8245050B1 (en) 2006-09-29 2012-08-14 Netapp, Inc. System and method for initial key establishment using a split knowledge protocol
US8464074B1 (en) 2008-05-30 2013-06-11 Cisco Technology, Inc. Storage media encryption with write acceleration
US8588425B1 (en) * 2007-12-27 2013-11-19 Emc Corporation Encryption key recovery in the event of storage management failure
US8611542B1 (en) 2007-04-26 2013-12-17 Netapp, Inc. Peer to peer key synchronization
US20140059354A1 (en) * 2005-03-18 2014-02-27 Microsoft Corporation Scalable Session Management
US8667273B1 (en) 2006-05-30 2014-03-04 Leif Olov Billstrom Intelligent file encryption and secure backup system
US20140068267A1 (en) * 2003-04-29 2014-03-06 Actividentity, Inc. Universal secure messaging for cryptographic modules
US8799022B1 (en) 2011-05-04 2014-08-05 Strat ID GIC, Inc. Method and network for secure transactions
US8799681B1 (en) 2007-12-27 2014-08-05 Emc Corporation Redundant array of encrypting disks
US20140229739A1 (en) 2013-02-12 2014-08-14 Amazon Technologies, Inc. Delayed data access
US20140237230A1 (en) * 2012-11-08 2014-08-21 CompuGroup Medical AG Computer system for storing and retrieval of encrypted data items, client computer, computer program product and computer-implemented method
US8824686B1 (en) 2007-04-27 2014-09-02 Netapp, Inc. Cluster key synchronization
US20140304512A1 (en) * 2013-03-14 2014-10-09 Sergei Pronin Method and system for authenticating and preserving data within a secure data repository
AU2011218632B2 (en) * 2004-05-05 2015-01-22 Ims Software Services, Ltd Multi-source longitudinal patient-level data encryption process
US20150082041A1 (en) * 2011-10-13 2015-03-19 Evolium Management, S. L. Multi - repository key storage and selection
US20150156180A1 (en) * 2013-03-12 2015-06-04 Silver Spring Networks, Inc. Handheld video visitation
US20150212206A1 (en) * 2014-01-29 2015-07-30 Electronics And Telecommunications Research Institute Automatic dependent surveillance data protection method for air traffic management, and system for the same
US20150288659A1 (en) * 2014-04-03 2015-10-08 Bitdefender IPR Management Ltd. Systems and Methods for Mutual Integrity Attestation Between A Network Endpoint And A Network Appliance
US20150304286A1 (en) * 2007-12-14 2015-10-22 Intel Corporation Symmetric key distribution framework for the internet
US20150360932A1 (en) * 2013-11-18 2015-12-17 Wayne Fueling Systems Sweden Ab Systems and Methods for Fuel Dispenser Security
CN105191207A (en) * 2013-02-12 2015-12-23 亚马逊技术股份有限公司 Federated key management
EP2963854A1 (en) * 2014-07-02 2016-01-06 SECVRE GmbH Device for secure peer-to-peer communication for voice and data
US9251337B2 (en) * 2011-04-27 2016-02-02 International Business Machines Corporation Scalable, highly available, dynamically reconfigurable cryptographic provider with quality-of-service control built from commodity backend providers
US20160036812A1 (en) * 2014-07-31 2016-02-04 International Business Machines Corporation Database Queries Integrity and External Security Mechanisms in Database Forensic Examinations
WO2016069719A1 (en) * 2014-10-29 2016-05-06 Alcatel Lucent Generation of multiple shared keys by user equipment and base station using key expansion multiplier
US20160149867A1 (en) * 2013-07-29 2016-05-26 Alcatel Lucent Adaptive traffic encryption for optical networks
US9355273B2 (en) 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data
US9425958B2 (en) 2005-08-05 2016-08-23 Hewlett Packard Enterprise Development Lp System, method and apparatus for cryptography key management for mobile devices
US9438421B1 (en) * 2014-06-27 2016-09-06 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US20170046521A1 (en) * 2014-11-06 2017-02-16 International Business Machines Corporation Secure database backup and recovery
WO2017134445A3 (en) * 2016-02-05 2017-09-14 Thales Holdings Uk Plc A method of data transfer, a method of controlling use of data and a cryptographic device
US20170272253A1 (en) * 2016-03-15 2017-09-21 Phillip Lavender Validation cryptogram for transaction
US9774445B1 (en) 2007-09-04 2017-09-26 Netapp, Inc. Host based rekeying
US9830278B1 (en) 2008-03-06 2017-11-28 EMC IP Holding Company LLC Tracking replica data using key management
US9886558B2 (en) 1999-09-20 2018-02-06 Quintiles Ims Incorporated System and method for analyzing de-identified health care data
US10055594B2 (en) 2012-06-07 2018-08-21 Amazon Technologies, Inc. Virtual service provider zones
US10075295B2 (en) 2013-02-12 2018-09-11 Amazon Technologies, Inc. Probabilistic key rotation
US10075471B2 (en) 2012-06-07 2018-09-11 Amazon Technologies, Inc. Data loss prevention techniques
US10084818B1 (en) 2012-06-07 2018-09-25 Amazon Technologies, Inc. Flexibly configurable data modification services
US10148433B1 (en) 2009-10-14 2018-12-04 Digitalpersona, Inc. Private key/public key resource protection scheme
US10211977B1 (en) 2013-02-12 2019-02-19 Amazon Technologies, Inc. Secure management of information using a security module
US10263988B2 (en) * 2016-07-02 2019-04-16 Intel Corporation Protected container key management processors, methods, systems, and instructions
US10313312B2 (en) 2013-06-13 2019-06-04 Amazon Technologies, Inc. Key rotation techniques
CN110199263A (en) * 2017-01-19 2019-09-03 电子湾有限公司 Fraud tracking based on password
US10404670B2 (en) 2013-02-12 2019-09-03 Amazon Technologies, Inc. Data security service
US10467422B1 (en) 2013-02-12 2019-11-05 Amazon Technologies, Inc. Automatic key rotation
EP3588397A1 (en) * 2018-06-29 2020-01-01 Social CRM Squad Ltd Apparatus and methods for retrieving lost property
US10721075B2 (en) 2014-05-21 2020-07-21 Amazon Technologies, Inc. Web of trust management in a distributed system
CN111698087A (en) * 2020-06-15 2020-09-22 北京数字认证股份有限公司 Miniature cipher machine and information processing method
US20200322794A1 (en) * 2016-05-30 2020-10-08 Telecom Italia S.P.A. Protection of privacy in wireless telecommunication networks
US11032080B2 (en) 2017-06-20 2021-06-08 Google Llc Tokenized hardware security modules
US11036869B2 (en) 2013-02-12 2021-06-15 Amazon Technologies, Inc. Data security with a security module
US20210177054A1 (en) * 2014-06-27 2021-06-17 Fontem Holdings 1 B.V. Electronic smoking device and capsule system
CN113316915A (en) * 2019-12-08 2021-08-27 西部数据技术公司 Unlocking a data storage device
EP3873024A1 (en) * 2015-12-11 2021-09-01 Visa International Service Association Device using secure storage and retrieval of data
US20220138190A1 (en) * 2020-10-29 2022-05-05 Pacific Investment Management Company LLC Surrogate data generation of private data
US11334678B2 (en) * 2017-07-06 2022-05-17 Chromaway Ab Method and system for a distributed computing system
CN115334073A (en) * 2022-10-13 2022-11-11 中国电子科技集团公司第十五研究所 Method and system for deeply pulling remote file
US11626996B2 (en) 2014-09-15 2023-04-11 Amazon Technologies, Inc. Distributed system web of trust provisioning
US20230153209A1 (en) * 2021-11-17 2023-05-18 Coinbase Il Rd Ltd System and method for database recovery

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10143754A1 (en) * 2001-09-06 2003-04-03 Siemens Ag Scalable peer-to-peer network with a directory service
AU2004201058B1 (en) * 2004-03-15 2004-09-09 Lockstep Consulting Pty Ltd Means and method of issuing Anonymous Public Key Certificates for indexing electronic record systems
GB2415064B (en) * 2004-06-10 2008-01-09 Symbian Software Ltd Computing device with a process-based keystore and method for operating a computing device
US8086853B2 (en) * 2005-03-18 2011-12-27 Microsoft Corporation Automatic centralized authentication challenge response generation
JP4709583B2 (en) * 2005-05-31 2011-06-22 株式会社東芝 Data transmission apparatus and data transmission method
US7953978B2 (en) * 2006-09-07 2011-05-31 International Business Machines Corporation Key generation and retrieval using key servers
WO2008070191A2 (en) 2006-12-06 2008-06-12 Fusion Multisystems, Inc. (Dba Fusion-Io) Apparatus, system, and method for a reconfigurable baseboard management controller
CN101686123B (en) * 2008-09-24 2012-01-25 中国移动通信集团公司 Method and system for managing key, method and device for generating and authenticating key
US9489523B2 (en) 2010-04-08 2016-11-08 University Of Washington Through Its Center For Commercialization Systems and methods for file access auditing
US8458346B2 (en) * 2010-07-30 2013-06-04 Sap Ag Multiplexer for multi-tenant architectures
DE102010041804A1 (en) * 2010-09-30 2012-04-05 Siemens Aktiengesellschaft Method for secure data transmission with a VPN box
KR20130031435A (en) * 2011-09-21 2013-03-29 주식회사 팬택 Method and apparatus for generating and managing of encryption key portable terminal
US8661255B2 (en) * 2011-12-06 2014-02-25 Sony Corporation Digital rights management of streaming contents and services
WO2013084054A1 (en) 2011-12-08 2013-06-13 Dark Matter Labs Inc. Key creation and rotation for data encryption
US8964990B1 (en) * 2012-05-17 2015-02-24 Amazon Technologies, Inc. Automating key rotation in a distributed system
US8908868B1 (en) 2012-05-17 2014-12-09 Amazon Technologies, Inc. Key rotation with external workflows
US8712044B2 (en) * 2012-06-29 2014-04-29 Dark Matter Labs Inc. Key management system
CN103051446B (en) * 2012-12-26 2016-04-27 公安部第一研究所 A kind of key encrypting and storing method
JP6076752B2 (en) * 2013-01-22 2017-02-08 株式会社東芝 COMMUNICATION DEVICE, COMMUNICATION SYSTEM, AND PROGRAM
CN103095731A (en) * 2013-02-22 2013-05-08 浪潮电子信息产业股份有限公司 REST security system based on signature mechanism
US20160065374A1 (en) * 2014-09-02 2016-03-03 Apple Inc. Method of using one device to unlock another device
US11595417B2 (en) 2015-09-15 2023-02-28 Mimecast Services Ltd. Systems and methods for mediating access to resources
US9654492B2 (en) 2015-09-15 2017-05-16 Mimecast North America, Inc. Malware detection system based on stored data
US10536449B2 (en) 2015-09-15 2020-01-14 Mimecast Services Ltd. User login credential warning system
US9467435B1 (en) * 2015-09-15 2016-10-11 Mimecast North America, Inc. Electronic message threat protection system for authorized users
US10728239B2 (en) 2015-09-15 2020-07-28 Mimecast Services Ltd. Mediated access to resources
US9705859B2 (en) * 2015-12-11 2017-07-11 Amazon Technologies, Inc. Key exchange through partially trusted third party
US10412098B2 (en) 2015-12-11 2019-09-10 Amazon Technologies, Inc. Signed envelope encryption
US10198595B2 (en) * 2015-12-22 2019-02-05 Walmart Apollo, Llc Data breach detection system
US10169602B2 (en) * 2016-02-22 2019-01-01 Dell Products, L.P. Method for local key management setup and recovery
US10846668B1 (en) 2016-04-12 2020-11-24 Wells Fargo Bank, N.A. Systems and methods for completing transactions via curbside service
US10771261B1 (en) * 2016-09-29 2020-09-08 EMC IP Holding Company LLC Extensible unified multi-service certificate and certificate revocation list management
US10615969B1 (en) 2017-02-10 2020-04-07 Wells Fargo Bank, N.A. Database encryption key management
US10615970B1 (en) 2017-02-10 2020-04-07 Wells Fargo Bank, N.A. Secure key exchange electronic transactions
US10965474B1 (en) * 2017-02-27 2021-03-30 Apple Inc. Modifying security state with highly secured devices
EP3386146A1 (en) * 2017-04-05 2018-10-10 Siemens Aktiengesellschaft Method for ensuring the authenticity at least one value of a device property, computer program, computer-readable storage medium and device
US10462140B2 (en) 2017-04-28 2019-10-29 Bank Of America Corporation Data transmission authentication and self-destruction
CN107784107B (en) * 2017-10-31 2020-06-30 杭州安恒信息技术股份有限公司 Dark chain detection method and device based on escape behavior analysis
CN110019994A (en) 2017-11-13 2019-07-16 阿里巴巴集团控股有限公司 Data encryption, decryption and querying method, data ciphering and deciphering and inquiry unit
US11151266B2 (en) 2017-12-06 2021-10-19 International Business Machines Corporation Secure data storage and access during transition operations
US11620671B2 (en) * 2018-04-10 2023-04-04 Medibloc Co., Ltd. Method and system for managing medical information platform by using blockchain, and non-transitory computer-readable recording medium
EP3582031A1 (en) * 2018-06-11 2019-12-18 Siemens Aktiengesellschaft Secure management of access data for control devices
US11641274B2 (en) 2019-03-22 2023-05-02 Jpmorgan Chase Bank, N.A. Systems and methods for manipulation of private information on untrusted environments
EP4035048A1 (en) 2019-09-25 2022-08-03 ARRIS Enterprises LLC Secure scalable link key distribution using bootsrapping
CN110808829B (en) * 2019-09-27 2023-04-18 国电南瑞科技股份有限公司 SSH authentication method based on key distribution center
US11831752B2 (en) * 2020-01-09 2023-11-28 Western Digital Technologies, Inc. Initializing a data storage device with a manager device
US11682008B2 (en) * 2020-09-28 2023-06-20 Vadim Nikolaevich ALEKSANDROV Method of authenticating a customer, method of carrying out a payment transaction and payment system implementing the specified methods
CN114338010B (en) * 2021-12-31 2024-02-20 深圳昂楷科技有限公司 Database key exchange method and device and electronic equipment

Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4423287A (en) * 1981-06-26 1983-12-27 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4578530A (en) * 1981-06-26 1986-03-25 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4912762A (en) * 1987-04-22 1990-03-27 International Business Machines Corporation Management of cryptographic keys
US5301270A (en) * 1989-12-18 1994-04-05 Anderson Consulting Computer-assisted software engineering system for cooperative processing environments
US5363507A (en) * 1990-08-13 1994-11-08 Hitachi, Ltd. Method and system for storing and retrieving collaboratively processed information by associated identification data
US5369702A (en) * 1993-10-18 1994-11-29 Tecsec Incorporated Distributed cryptographic object method
US5495533A (en) * 1994-04-29 1996-02-27 International Business Machines Corporation Personal key archive
US5533123A (en) * 1994-06-28 1996-07-02 National Semiconductor Corporation Programmable distributed personal security
US5546304A (en) * 1994-03-03 1996-08-13 At&T Corp. Real-time administration-translation arrangement
US5680452A (en) * 1993-10-18 1997-10-21 Tecsec Inc. Distributed cryptographic object method
US5682524A (en) * 1995-05-26 1997-10-28 Starfish Software, Inc. Databank system with methods for efficiently storing non-uniform data records
US5729608A (en) * 1993-07-27 1998-03-17 International Business Machines Corp. Method and system for providing secure key distribution in a communication system
US5757925A (en) * 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
US5764772A (en) * 1995-12-15 1998-06-09 Lotus Development Coporation Differential work factor cryptography method and system
US5778072A (en) * 1995-07-07 1998-07-07 Sun Microsystems, Inc. System and method to transparently integrate private key operations from a smart card with host-based encryption services
US5796830A (en) * 1996-07-29 1998-08-18 International Business Machines Corporation Interoperable cryptographic key recovery system
US5799086A (en) * 1994-01-13 1998-08-25 Certco Llc Enhanced cryptographic system and method with key escrow feature
US5815573A (en) * 1996-04-10 1998-09-29 International Business Machines Corporation Cryptographic key recovery system
US5907618A (en) * 1997-01-03 1999-05-25 International Business Machines Corporation Method and apparatus for verifiably providing key recovery information in a cryptographic system
US5915025A (en) * 1996-01-17 1999-06-22 Fuji Xerox Co., Ltd. Data processing apparatus with software protecting functions
US5937066A (en) * 1996-10-02 1999-08-10 International Business Machines Corporation Two-phase cryptographic key recovery system
US5949882A (en) * 1996-12-13 1999-09-07 Compaq Computer Corporation Method and apparatus for allowing access to secured computer resources by utilzing a password and an external encryption algorithm
US6044154A (en) * 1994-10-31 2000-03-28 Communications Devices, Inc. Remote generated, device identifier key for use with a dual-key reflexive encryption security system
US6058188A (en) * 1997-07-24 2000-05-02 International Business Machines Corporation Method and apparatus for interoperable validation of key recovery information in a cryptographic system
US6084969A (en) * 1997-12-31 2000-07-04 V-One Corporation Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network
US6289451B1 (en) * 1997-04-18 2001-09-11 Sun Microsystems, Inc. System and method for efficiently implementing an authenticated communications channel that facilitates tamper detection
US20020031230A1 (en) * 2000-08-15 2002-03-14 Sweet William B. Method and apparatus for a web-based application service model for security management
US6947556B1 (en) * 2000-08-21 2005-09-20 International Business Machines Corporation Secure data storage and retrieval with key management and user authentication

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4713753A (en) * 1985-02-21 1987-12-15 Honeywell Inc. Secure data processing system architecture with format control
US5748735A (en) * 1994-07-18 1998-05-05 Bell Atlantic Network Services, Inc. Securing E-mail communications and encrypted file storage using yaksha split private key asymmetric cryptography
CN1126377C (en) * 1995-03-08 2003-10-29 皇家菲利浦电子有限公司 Three-dimensional image display system
US5625693A (en) 1995-07-07 1997-04-29 Thomson Consumer Electronics, Inc. Apparatus and method for authenticating transmitting applications in an interactive TV system
US6023506A (en) * 1995-10-26 2000-02-08 Hitachi, Ltd. Data encryption control apparatus and method
SE506853C2 (en) * 1996-06-20 1998-02-16 Anonymity Prot In Sweden Ab Method of data processing
US6061790A (en) * 1996-11-20 2000-05-09 Starfish Software, Inc. Network computer system with remote user data encipher methodology
US5881225A (en) * 1997-04-14 1999-03-09 Araxsys, Inc. Security monitor for controlling functional access to a computer system
EP0878796B1 (en) * 1997-05-13 2006-04-19 Kabushiki Kaisha Toshiba Information recording apparatus, information reproducing apparatus, and information distribution system
GB9712459D0 (en) 1997-06-14 1997-08-20 Int Computers Ltd Secure database system
WO1999000958A1 (en) * 1997-06-26 1999-01-07 British Telecommunications Plc Data communications
JPH11143780A (en) 1997-11-05 1999-05-28 Hitachi Ltd Method and device for managing secret information in database
US6246771B1 (en) * 1997-11-26 2001-06-12 V-One Corporation Session key recovery system and method
US6430549B1 (en) 1998-07-17 2002-08-06 Electronic Data Systems Corporation System and method for selectivety defining access to application features
US6226618B1 (en) * 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
DE60024800T2 (en) * 1999-04-09 2006-07-06 General Instrument Corporation KEY MANAGEMENT BETWEEN CABLE TELEPHONE SYSTEM ADAPTER AND SIGNAL EQUIPMENT CONTROL
SE9904094D0 (en) 1999-11-12 1999-11-12 Protegrity Research & Dev Method for reencryption of a database
US7412462B2 (en) * 2000-02-18 2008-08-12 Burnside Acquisition, Llc Data repository and method for promoting network storage of data
FR2810434A1 (en) * 2000-06-17 2001-12-21 Espace Cx Com Medical record storage and transfer system includes coding system with dual keys to ensure confidentiality and security of data
US7203314B1 (en) * 2000-07-21 2007-04-10 The Directv Group, Inc. Super encrypted storage and retrieval of media programs with modified conditional access functionality
US7111005B1 (en) 2000-10-06 2006-09-19 Oracle International Corporation Method and apparatus for automatic database encryption
US7362868B2 (en) * 2000-10-20 2008-04-22 Eruces, Inc. Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US6986040B1 (en) * 2000-11-03 2006-01-10 Citrix Systems, Inc. System and method of exploiting the security of a secure communication channel to secure a non-secure communication channel
JP2005079912A (en) * 2003-08-29 2005-03-24 Matsushita Electric Ind Co Ltd Secure data management device

Patent Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4578530A (en) * 1981-06-26 1986-03-25 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4423287A (en) * 1981-06-26 1983-12-27 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4912762A (en) * 1987-04-22 1990-03-27 International Business Machines Corporation Management of cryptographic keys
US5301270A (en) * 1989-12-18 1994-04-05 Anderson Consulting Computer-assisted software engineering system for cooperative processing environments
US5363507A (en) * 1990-08-13 1994-11-08 Hitachi, Ltd. Method and system for storing and retrieving collaboratively processed information by associated identification data
US5729608A (en) * 1993-07-27 1998-03-17 International Business Machines Corp. Method and system for providing secure key distribution in a communication system
US5680452A (en) * 1993-10-18 1997-10-21 Tecsec Inc. Distributed cryptographic object method
US5369702A (en) * 1993-10-18 1994-11-29 Tecsec Incorporated Distributed cryptographic object method
US5799086A (en) * 1994-01-13 1998-08-25 Certco Llc Enhanced cryptographic system and method with key escrow feature
US5546304A (en) * 1994-03-03 1996-08-13 At&T Corp. Real-time administration-translation arrangement
US5495533A (en) * 1994-04-29 1996-02-27 International Business Machines Corporation Personal key archive
US5533123A (en) * 1994-06-28 1996-07-02 National Semiconductor Corporation Programmable distributed personal security
US6044154A (en) * 1994-10-31 2000-03-28 Communications Devices, Inc. Remote generated, device identifier key for use with a dual-key reflexive encryption security system
US5682524A (en) * 1995-05-26 1997-10-28 Starfish Software, Inc. Databank system with methods for efficiently storing non-uniform data records
US5809497A (en) * 1995-05-26 1998-09-15 Starfish Software, Inc. Databank system with methods for efficiently storing non uniforms data records
US5778072A (en) * 1995-07-07 1998-07-07 Sun Microsystems, Inc. System and method to transparently integrate private key operations from a smart card with host-based encryption services
US5764772A (en) * 1995-12-15 1998-06-09 Lotus Development Coporation Differential work factor cryptography method and system
US5915025A (en) * 1996-01-17 1999-06-22 Fuji Xerox Co., Ltd. Data processing apparatus with software protecting functions
US5815573A (en) * 1996-04-10 1998-09-29 International Business Machines Corporation Cryptographic key recovery system
US5757925A (en) * 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
US6052469A (en) * 1996-07-29 2000-04-18 International Business Machines Corporation Interoperable cryptographic key recovery system with verification by comparison
US5796830A (en) * 1996-07-29 1998-08-18 International Business Machines Corporation Interoperable cryptographic key recovery system
US5937066A (en) * 1996-10-02 1999-08-10 International Business Machines Corporation Two-phase cryptographic key recovery system
US5949882A (en) * 1996-12-13 1999-09-07 Compaq Computer Corporation Method and apparatus for allowing access to secured computer resources by utilzing a password and an external encryption algorithm
US5907618A (en) * 1997-01-03 1999-05-25 International Business Machines Corporation Method and apparatus for verifiably providing key recovery information in a cryptographic system
US6289451B1 (en) * 1997-04-18 2001-09-11 Sun Microsystems, Inc. System and method for efficiently implementing an authenticated communications channel that facilitates tamper detection
US6058188A (en) * 1997-07-24 2000-05-02 International Business Machines Corporation Method and apparatus for interoperable validation of key recovery information in a cryptographic system
US6084969A (en) * 1997-12-31 2000-07-04 V-One Corporation Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network
US20020031230A1 (en) * 2000-08-15 2002-03-14 Sweet William B. Method and apparatus for a web-based application service model for security management
US6947556B1 (en) * 2000-08-21 2005-09-20 International Business Machines Corporation Secure data storage and retrieval with key management and user authentication

Cited By (198)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9886558B2 (en) 1999-09-20 2018-02-06 Quintiles Ims Incorporated System and method for analyzing de-identified health care data
US20040086121A1 (en) * 2002-10-31 2004-05-06 Sensis Corporation Secure automatic dependant surveillance
US20040109567A1 (en) * 2002-12-05 2004-06-10 Canon Kabushiki Kaisha Encryption key generation in embedded devices
US20040158635A1 (en) * 2003-01-23 2004-08-12 Digi International Inc.. Secure terminal transmission system and method
US7210034B2 (en) * 2003-01-30 2007-04-24 Intel Corporation Distributed control of integrity measurement using a trusted fixed token
US20040153646A1 (en) * 2003-01-30 2004-08-05 Smith Ned M. Distributed control of integrity measurement using a trusted fixed token
US7519591B2 (en) * 2003-03-12 2009-04-14 Siemens Medical Solutions Usa, Inc. Systems and methods for encryption-based de-identification of protected health information
US20050165623A1 (en) * 2003-03-12 2005-07-28 Landi William A. Systems and methods for encryption-based de-identification of protected health information
US8245032B2 (en) * 2003-03-27 2012-08-14 Avaya Inc. Method to authenticate packet payloads
US20040193876A1 (en) * 2003-03-27 2004-09-30 Donley Christopher J. Method to authenticate packet payloads
US20040250169A1 (en) * 2003-04-17 2004-12-09 Kddi Corporation IDS log analysis support apparatus, IDS log analysis support method and IDS log analysis support program
US20140068267A1 (en) * 2003-04-29 2014-03-06 Actividentity, Inc. Universal secure messaging for cryptographic modules
US10554393B2 (en) * 2003-04-29 2020-02-04 Assa Abloy Ab Universal secure messaging for cryptographic modules
US7676681B2 (en) 2003-06-17 2010-03-09 Veratad Technologies, Llc Method, system, and apparatus for identification number authentication
US20040268124A1 (en) * 2003-06-27 2004-12-30 Nokia Corporation, Espoo, Finland Systems and methods for creating and maintaining a centralized key store
US20080016354A1 (en) * 2003-08-26 2008-01-17 International Business Machines Corporation System and Method for Secure Remote Access
US8904178B2 (en) * 2003-08-26 2014-12-02 International Business Machines Corporation System and method for secure remote access
US20050050363A1 (en) * 2003-08-29 2005-03-03 Ken Naka Secure data management apparatus
EP1510901A2 (en) * 2003-08-29 2005-03-02 Matsushita Electric Industrial Co., Ltd. Secure data management apparatus
EP1510901A3 (en) * 2003-08-29 2006-06-07 Matsushita Electric Industrial Co., Ltd. Secure data management apparatus
US7681046B1 (en) 2003-09-26 2010-03-16 Andrew Morgan System with secure cryptographic capabilities using a hardware specific digital secret
US20100017625A1 (en) * 2003-11-20 2010-01-21 Johnson Richard C Architecure, system, and method for operating on encrypted and/or hidden information
US7694151B1 (en) 2003-11-20 2010-04-06 Johnson Richard C Architecture, system, and method for operating on encrypted and/or hidden information
US8335930B2 (en) 2003-11-20 2012-12-18 Johnson Richard C Architecture, system, and method for operating on encrypted and/or hidden information
US20050125674A1 (en) * 2003-12-09 2005-06-09 Kenya Nishiki Authentication control system and authentication control method
US20050172143A1 (en) * 2004-01-30 2005-08-04 Fearnley Daniel P. Method and apparatus for secure data storage
WO2005074489A2 (en) * 2004-01-30 2005-08-18 Neopost Industrie Sa Method and apparatus for secure data storage
WO2005074489A3 (en) * 2004-01-30 2006-12-28 Neopost Ind Sa Method and apparatus for secure data storage
US20050193214A1 (en) * 2004-02-28 2005-09-01 Mi-Jung Noh Engine, register and methods for the same
US7630498B2 (en) 2004-02-28 2009-12-08 Samsung Electronics.Co., Ltd. Engine, register and methods for the same
US20050254656A1 (en) * 2004-03-18 2005-11-17 Qualcomm Incorporated Efficient transmission of cryptographic information in secure real time protocol
US8867745B2 (en) * 2004-03-18 2014-10-21 Qualcomm Incorporated Efficient transmission of cryptographic information in secure real time protocol
US20050268094A1 (en) * 2004-05-05 2005-12-01 Kohan Mark E Multi-source longitudinal patient-level data encryption process
WO2005109294A3 (en) * 2004-05-05 2007-01-04 Ims Health Inc Multi-source longitudinal patient-level data encryption process
US8275850B2 (en) 2004-05-05 2012-09-25 Ims Software Services Ltd. Multi-source longitudinal patient-level data encryption process
AU2011218632B2 (en) * 2004-05-05 2015-01-22 Ims Software Services, Ltd Multi-source longitudinal patient-level data encryption process
US20050256742A1 (en) * 2004-05-05 2005-11-17 Kohan Mark E Data encryption applications for multi-source longitudinal patient-level data integration
US20050254653A1 (en) * 2004-05-14 2005-11-17 Proxim Corporation Pre-authentication of mobile clients by sharing a master key among secured authenticators
US20060031256A1 (en) * 2004-05-20 2006-02-09 Bea Systems, Inc. Template language for mobile client
US7681042B2 (en) * 2004-06-17 2010-03-16 Eruces, Inc. System and method for dis-identifying sensitive information and associated records
US20050283620A1 (en) * 2004-06-17 2005-12-22 Bassam Khulusi System and method for dis-identifying sensitive information and associated records
WO2006009648A3 (en) * 2004-06-17 2006-10-19 Eruces Inc System and method for dis-identifying sensitive information and assocaites records
US7752657B2 (en) * 2004-10-04 2010-07-06 Sap Ag Data processing system and method
US20060075479A1 (en) * 2004-10-04 2006-04-06 Harald Hagedorn Data processing system and method
US7496762B1 (en) * 2004-10-07 2009-02-24 Sprint Communications Company L.P. Security architecture for modified segregated environment for federal telecom services
US7707225B2 (en) * 2004-10-08 2010-04-27 Felica Networks, Inc. Information processing apparatus, information processing method, and program
EP1645984A1 (en) * 2004-10-08 2006-04-12 FeliCa Networks, Inc. Information processing apparatus, information processing method, and program
US20060080322A1 (en) * 2004-10-08 2006-04-13 Felica Networks, Inc. Information processing apparatus, information processing method, and program
US20060078109A1 (en) * 2004-10-08 2006-04-13 Felica Networks, Inc. Information processing apparatus, information processing method, and program
US7899189B2 (en) * 2004-12-09 2011-03-01 International Business Machines Corporation Apparatus, system, and method for transparent end-to-end security of storage data in a client-server environment
US20060126850A1 (en) * 2004-12-09 2006-06-15 Dawson Colin S Apparatus, system, and method for transparent end-to-end security of storage data in a client-server environment
US20060126520A1 (en) * 2004-12-15 2006-06-15 Cisco Technology, Inc. Tape acceleration
US20140059354A1 (en) * 2005-03-18 2014-02-27 Microsoft Corporation Scalable Session Management
US9673984B2 (en) * 2005-03-18 2017-06-06 Microsoft Technology Licensing, Llc Session key cache to maintain session keys
US7970143B2 (en) 2005-08-05 2011-06-28 Hewlett-Packard Development Company, L.P. System, method and apparatus to obtain a key for encryption/decryption/data recovery from an enterprise cryptography key management system
US9425958B2 (en) 2005-08-05 2016-08-23 Hewlett Packard Enterprise Development Lp System, method and apparatus for cryptography key management for mobile devices
US20080232598A1 (en) * 2005-08-05 2008-09-25 Ravigopal Vennelakanti System, Method and Apparatus to Obtain a Key for Encryption/Decryption/Data Recovery From an Enterprise Cryptography Key Management System
WO2007017884A1 (en) * 2005-08-05 2007-02-15 Hewlett-Packard Development Company L.P. System, method and apparatus to obtain a key for encryption/decryption/data recovery from an enterprise cryptography key management system
US8069270B1 (en) 2005-09-06 2011-11-29 Cisco Technology, Inc. Accelerated tape backup restoration
US20070297589A1 (en) * 2005-09-14 2007-12-27 Greischar Patrick J Method and system for data aggregation for real-time emergency resource management
US20090018869A1 (en) * 2005-09-14 2009-01-15 Patrick J Greischar Method and system for data aggregation for real-time emergency resource management
US20070174093A1 (en) * 2005-09-14 2007-07-26 Dave Colwell Method and system for secure and protected electronic patient tracking
US8428961B2 (en) 2005-09-14 2013-04-23 Emsystem, Llc Method and system for data aggregation for real-time emergency resource management
US20070078994A1 (en) * 2005-10-03 2007-04-05 Kabushiki Kaisha Toshiba And Toshiba Tec Kabushiki Kaisha System and method for automatic wireless detection and identification of document processing service location
US7450946B2 (en) 2005-10-03 2008-11-11 Kabushiki Kaisha Toshiba System and method for automatic wireless detection and identification of document processing service location
US7606769B2 (en) 2005-10-12 2009-10-20 Kabushiki Kaisha Toshiba System and method for embedding user authentication information in encrypted data
US20070143210A1 (en) * 2005-10-12 2007-06-21 Kabushiki Kaisha Toshiba System and method for embedding user authentication information in encrypted data
US20080235234A1 (en) * 2005-10-20 2008-09-25 International Business Machines Corporation Access control list (acl) binding in a data processing system
US20070100830A1 (en) * 2005-10-20 2007-05-03 Ganesha Beedubail Method and apparatus for access control list (ACL) binding in a data processing system
US20070101134A1 (en) * 2005-10-31 2007-05-03 Cisco Technology, Inc. Method and apparatus for performing encryption of data at rest at a port of a network device
WO2007053623A3 (en) * 2005-10-31 2009-05-07 Cisco Tech Inc Method and apparatus for performing encryption of data at rest at a port of a network device
US8266431B2 (en) * 2005-10-31 2012-09-11 Cisco Technology, Inc. Method and apparatus for performing encryption of data at rest at a port of a network device
US7909245B1 (en) 2005-12-15 2011-03-22 At&T Intellectual Property Ii, L.P. Network based method of providing access to information
US7527192B1 (en) * 2005-12-15 2009-05-05 At&T Corp. Network based method of providing access to information
US20070220007A1 (en) * 2006-03-17 2007-09-20 International Business Machines Corporation Method and system for electronic authentication
US7730307B2 (en) 2006-04-07 2010-06-01 Sensis Corporation Secure ADS-B authentication system and method
US20070239986A1 (en) * 2006-04-07 2007-10-11 Sensis Corporation Secure ADS-B authentication system and method
US20090106551A1 (en) * 2006-04-25 2009-04-23 Stephen Laurence Boren Dynamic distributed key system and method for identity management, authentication servers, data security and preventing man-in-the-middle attacks
US9166782B2 (en) 2006-04-25 2015-10-20 Stephen Laurence Boren Dynamic distributed key system and method for identity management, authentication servers, data security and preventing man-in-the-middle attacks
EP2016701A4 (en) * 2006-04-25 2012-04-25 Stephen Laurence Boren Dynamic distributed key system and method for identity management, authentication servers, data security and preventing man-in-the-middle attacks
EP2016701A1 (en) * 2006-04-25 2009-01-21 Stephen Laurence Boren Dynamic distributed key system and method for identity management, authentication servers, data security and preventing man-in-the-middle attacks
US8667273B1 (en) 2006-05-30 2014-03-04 Leif Olov Billstrom Intelligent file encryption and secure backup system
US8099605B1 (en) 2006-06-05 2012-01-17 InventSec AB Intelligent storage device for backup system
US8176319B2 (en) * 2006-06-27 2012-05-08 Emc Corporation Identifying and enforcing strict file confidentiality in the presence of system and storage administrators in a NAS system
US20070300062A1 (en) * 2006-06-27 2007-12-27 Osmond Roger F Identifying and enforcing strict file confidentiality in the presence of system and storage administrators in a nas system
US8769271B1 (en) 2006-06-27 2014-07-01 Emc Corporation Identifying and enforcing strict file confidentiality in the presence of system and storage administrators in a NAS system
US20080046285A1 (en) * 2006-08-18 2008-02-21 Greischar Patrick J Method and system for real-time emergency resource management
US7904732B2 (en) * 2006-09-27 2011-03-08 Rocket Software, Inc. Encrypting and decrypting database records
US20080077806A1 (en) * 2006-09-27 2008-03-27 International Business Machines Corporation Encrypting and decrypting database records
US8245050B1 (en) 2006-09-29 2012-08-14 Netapp, Inc. System and method for initial key establishment using a split knowledge protocol
US9355273B2 (en) 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data
EP1967979A2 (en) * 2007-03-09 2008-09-10 Quantum Corporation Cryptographic key management for stored data
US20080219449A1 (en) * 2007-03-09 2008-09-11 Ball Matthew V Cryptographic key management for stored data
EP1967979A3 (en) * 2007-03-09 2011-06-15 Quantum Corporation Cryptographic key management for stored data
US20080263645A1 (en) * 2007-04-23 2008-10-23 Telus Communications Company Privacy identifier remediation
US8611542B1 (en) 2007-04-26 2013-12-17 Netapp, Inc. Peer to peer key synchronization
US8824686B1 (en) 2007-04-27 2014-09-02 Netapp, Inc. Cluster key synchronization
US20080292105A1 (en) * 2007-05-22 2008-11-27 Chieh-Yih Wan Lightweight key distribution and management method for sensor networks
US8254581B2 (en) 2007-05-22 2012-08-28 Intel Corporation Lightweight key distribution and management method for sensor networks
WO2009012165A2 (en) 2007-07-13 2009-01-22 Microsoft Corporation Creating and validating cryptographically secured documents
EP2176984A4 (en) * 2007-07-13 2016-10-05 Microsoft Technology Licensing Llc Creating and validating cryptographically secured documents
US8196182B2 (en) 2007-08-24 2012-06-05 Netapp, Inc. Distributed management of crypto module white lists
US9774445B1 (en) 2007-09-04 2017-09-26 Netapp, Inc. Host based rekeying
US9654453B2 (en) * 2007-12-14 2017-05-16 Intel Corporation Symmetric key distribution framework for the Internet
US20150304286A1 (en) * 2007-12-14 2015-10-22 Intel Corporation Symmetric key distribution framework for the internet
US8799681B1 (en) 2007-12-27 2014-08-05 Emc Corporation Redundant array of encrypting disks
US9571278B1 (en) * 2007-12-27 2017-02-14 EMC IP Holding Company LLC Encryption key recovery in the event of storage management failure
US8588425B1 (en) * 2007-12-27 2013-11-19 Emc Corporation Encryption key recovery in the event of storage management failure
US8254577B2 (en) * 2008-02-20 2012-08-28 International Business Machines Corporation Validation of encryption key
US20090208017A1 (en) * 2008-02-20 2009-08-20 International Business Machines Corporation Validation of encryption key
US9830278B1 (en) 2008-03-06 2017-11-28 EMC IP Holding Company LLC Tracking replica data using key management
US20090271633A1 (en) * 2008-03-10 2009-10-29 Aceinc Pty Limited Data Access and Identity Verification
US20090296937A1 (en) * 2008-05-27 2009-12-03 Kabushiki Kaisha Toshiba Data protection system, data protection method, and memory card
US8750519B2 (en) * 2008-05-27 2014-06-10 Kabushiki Kaisha Toshiba Data protection system, data protection method, and memory card
US8464074B1 (en) 2008-05-30 2013-06-11 Cisco Technology, Inc. Storage media encryption with write acceleration
US20100161995A1 (en) * 2008-12-19 2010-06-24 James Browning System, method, and computer-readable medium for cryptographic key rotation in a database system
US8504844B2 (en) * 2008-12-19 2013-08-06 Teradata Us, Inc. System, method, and computer-readable medium for cryptographic key rotation in a database system
US20100250939A1 (en) * 2009-02-26 2010-09-30 Research In Motion Limited System and method of handling encrypted backup data
US10148433B1 (en) 2009-10-14 2018-12-04 Digitalpersona, Inc. Private key/public key resource protection scheme
US9251337B2 (en) * 2011-04-27 2016-02-02 International Business Machines Corporation Scalable, highly available, dynamically reconfigurable cryptographic provider with quality-of-service control built from commodity backend providers
US9251338B2 (en) 2011-04-27 2016-02-02 International Business Machines Corporation Scalable, highly available, dynamically reconfigurable cryptographic provider with quality-of-service control built from commodity backend providers
US8799022B1 (en) 2011-05-04 2014-08-05 Strat ID GIC, Inc. Method and network for secure transactions
US20150082041A1 (en) * 2011-10-13 2015-03-19 Evolium Management, S. L. Multi - repository key storage and selection
US9647993B2 (en) * 2011-10-13 2017-05-09 Evolium Technologies, S.L. Multi-repository key storage and selection
US10474829B2 (en) 2012-06-07 2019-11-12 Amazon Technologies, Inc. Virtual service provider zones
US10834139B2 (en) 2012-06-07 2020-11-10 Amazon Technologies, Inc. Flexibly configurable data modification services
US10084818B1 (en) 2012-06-07 2018-09-25 Amazon Technologies, Inc. Flexibly configurable data modification services
US10075471B2 (en) 2012-06-07 2018-09-11 Amazon Technologies, Inc. Data loss prevention techniques
US10055594B2 (en) 2012-06-07 2018-08-21 Amazon Technologies, Inc. Virtual service provider zones
US9141822B2 (en) * 2012-11-08 2015-09-22 CompuGroup Medical AG Computer system for storing and retrieval of encrypted data items, client computer, computer program product and computer-implemented method
US20140237230A1 (en) * 2012-11-08 2014-08-21 CompuGroup Medical AG Computer system for storing and retrieval of encrypted data items, client computer, computer program product and computer-implemented method
EP2731040B1 (en) * 2012-11-08 2017-04-19 CompuGroup Medical SE Computer system for storing and retrieval of encrypted data items, client computer, computer program product and computer-implemented method
CN105191207A (en) * 2013-02-12 2015-12-23 亚马逊技术股份有限公司 Federated key management
US11372993B2 (en) 2013-02-12 2022-06-28 Amazon Technologies, Inc. Automatic key rotation
US10404670B2 (en) 2013-02-12 2019-09-03 Amazon Technologies, Inc. Data security service
US10211977B1 (en) 2013-02-12 2019-02-19 Amazon Technologies, Inc. Secure management of information using a security module
US10210341B2 (en) 2013-02-12 2019-02-19 Amazon Technologies, Inc. Delayed data access
US11036869B2 (en) 2013-02-12 2021-06-15 Amazon Technologies, Inc. Data security with a security module
CN105191207B (en) * 2013-02-12 2020-09-08 亚马逊技术股份有限公司 Federated key management
US20140229739A1 (en) 2013-02-12 2014-08-14 Amazon Technologies, Inc. Delayed data access
US11695555B2 (en) 2013-02-12 2023-07-04 Amazon Technologies, Inc. Federated key management
US10382200B2 (en) 2013-02-12 2019-08-13 Amazon Technologies, Inc. Probabilistic key rotation
US10075295B2 (en) 2013-02-12 2018-09-11 Amazon Technologies, Inc. Probabilistic key rotation
US10666436B2 (en) 2013-02-12 2020-05-26 Amazon Technologies, Inc. Federated key management
US10467422B1 (en) 2013-02-12 2019-11-05 Amazon Technologies, Inc. Automatic key rotation
US20150156180A1 (en) * 2013-03-12 2015-06-04 Silver Spring Networks, Inc. Handheld video visitation
US10764261B2 (en) * 2013-03-12 2020-09-01 Itron, Inc. System and method for enabling a scalable public-key infrastructure on a smart grid network
US20140304512A1 (en) * 2013-03-14 2014-10-09 Sergei Pronin Method and system for authenticating and preserving data within a secure data repository
US10601789B2 (en) 2013-06-13 2020-03-24 Amazon Technologies, Inc. Session negotiations
US11470054B2 (en) 2013-06-13 2022-10-11 Amazon Technologies, Inc. Key rotation techniques
US10313312B2 (en) 2013-06-13 2019-06-04 Amazon Technologies, Inc. Key rotation techniques
US11323479B2 (en) 2013-07-01 2022-05-03 Amazon Technologies, Inc. Data loss prevention techniques
US20160149867A1 (en) * 2013-07-29 2016-05-26 Alcatel Lucent Adaptive traffic encryption for optical networks
US10091171B2 (en) * 2013-07-29 2018-10-02 Alcatel Lucent Adaptive traffic encryption for optical networks
US20150360932A1 (en) * 2013-11-18 2015-12-17 Wayne Fueling Systems Sweden Ab Systems and Methods for Fuel Dispenser Security
US9580295B2 (en) * 2013-11-18 2017-02-28 Wayne Fueling Systems Sweden Ab Systems and methods for fuel dispenser security
US20150212206A1 (en) * 2014-01-29 2015-07-30 Electronics And Telecommunications Research Institute Automatic dependent surveillance data protection method for air traffic management, and system for the same
US20150288659A1 (en) * 2014-04-03 2015-10-08 Bitdefender IPR Management Ltd. Systems and Methods for Mutual Integrity Attestation Between A Network Endpoint And A Network Appliance
US10721075B2 (en) 2014-05-21 2020-07-21 Amazon Technologies, Inc. Web of trust management in a distributed system
US20170093569A1 (en) * 2014-06-27 2017-03-30 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US20180227124A1 (en) * 2014-06-27 2018-08-09 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US11368300B2 (en) * 2014-06-27 2022-06-21 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US9942036B2 (en) * 2014-06-27 2018-04-10 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US10587405B2 (en) * 2014-06-27 2020-03-10 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US9438421B1 (en) * 2014-06-27 2016-09-06 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US20210177054A1 (en) * 2014-06-27 2021-06-17 Fontem Holdings 1 B.V. Electronic smoking device and capsule system
EP2963854A1 (en) * 2014-07-02 2016-01-06 SECVRE GmbH Device for secure peer-to-peer communication for voice and data
US20160036812A1 (en) * 2014-07-31 2016-02-04 International Business Machines Corporation Database Queries Integrity and External Security Mechanisms in Database Forensic Examinations
US11626996B2 (en) 2014-09-15 2023-04-11 Amazon Technologies, Inc. Distributed system web of trust provisioning
WO2016069719A1 (en) * 2014-10-29 2016-05-06 Alcatel Lucent Generation of multiple shared keys by user equipment and base station using key expansion multiplier
US9585013B2 (en) 2014-10-29 2017-02-28 Alcatel Lucent Generation of multiple shared keys by user equipment and base station using key expansion multiplier
US9929861B2 (en) * 2014-11-06 2018-03-27 International Business Machines Corporation Secure database backup and recovery
US11139968B2 (en) 2014-11-06 2021-10-05 International Business Machines Corporation Secure database backup and recovery
US9953172B2 (en) 2014-11-06 2018-04-24 International Business Machines Corporation Secure database backup and recovery
US10341101B2 (en) 2014-11-06 2019-07-02 International Business Machines Corporation Secure database backup and recovery
US10554403B2 (en) 2014-11-06 2020-02-04 International Business Machines Corporation Secure database backup and recovery
US9916460B2 (en) * 2014-11-06 2018-03-13 International Business Machines Corporation Secure database backup and recovery
US10903995B2 (en) 2014-11-06 2021-01-26 International Business Machines Corporation Secure database backup and recovery
US20170046521A1 (en) * 2014-11-06 2017-02-16 International Business Machines Corporation Secure database backup and recovery
EP3873024A1 (en) * 2015-12-11 2021-09-01 Visa International Service Association Device using secure storage and retrieval of data
WO2017134445A3 (en) * 2016-02-05 2017-09-14 Thales Holdings Uk Plc A method of data transfer, a method of controlling use of data and a cryptographic device
US11101983B2 (en) * 2016-02-05 2021-08-24 Ncipher Security Limited Method of data transfer, a method of controlling use of data and a cryptographic device
US20210344482A1 (en) * 2016-02-05 2021-11-04 Ncipher Security Limited Method of data transfer, a method of controlling use of data and cryptographic device
US11849029B2 (en) * 2016-02-05 2023-12-19 Ncipher Security Limited Method of data transfer, a method of controlling use of data and cryptographic device
US20170272253A1 (en) * 2016-03-15 2017-09-21 Phillip Lavender Validation cryptogram for transaction
US10742419B2 (en) * 2016-03-15 2020-08-11 Visa International Service Association Validation cryptogram for transaction
US20200322794A1 (en) * 2016-05-30 2020-10-08 Telecom Italia S.P.A. Protection of privacy in wireless telecommunication networks
US10263988B2 (en) * 2016-07-02 2019-04-16 Intel Corporation Protected container key management processors, methods, systems, and instructions
CN110199263A (en) * 2017-01-19 2019-09-03 电子湾有限公司 Fraud tracking based on password
US11032080B2 (en) 2017-06-20 2021-06-08 Google Llc Tokenized hardware security modules
US11334678B2 (en) * 2017-07-06 2022-05-17 Chromaway Ab Method and system for a distributed computing system
EP3588397A1 (en) * 2018-06-29 2020-01-01 Social CRM Squad Ltd Apparatus and methods for retrieving lost property
CN113316915A (en) * 2019-12-08 2021-08-27 西部数据技术公司 Unlocking a data storage device
CN111698087A (en) * 2020-06-15 2020-09-22 北京数字认证股份有限公司 Miniature cipher machine and information processing method
US20220138190A1 (en) * 2020-10-29 2022-05-05 Pacific Investment Management Company LLC Surrogate data generation of private data
US11775522B2 (en) * 2020-10-29 2023-10-03 Pacific Investment Management Company LLC Surrogate data generation of private data
US20230153209A1 (en) * 2021-11-17 2023-05-18 Coinbase Il Rd Ltd System and method for database recovery
CN115334073A (en) * 2022-10-13 2022-11-11 中国电子科技集团公司第十五研究所 Method and system for deeply pulling remote file

Also Published As

Publication number Publication date
EP1510030A1 (en) 2005-03-02
US7885413B2 (en) 2011-02-08
WO2003098864A1 (en) 2003-11-27
US20080301445A1 (en) 2008-12-04
EP1510030A4 (en) 2011-08-24
CN1669265A (en) 2005-09-14
AU2003233549A1 (en) 2003-12-02

Similar Documents

Publication Publication Date Title
US7885413B2 (en) Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US7362868B2 (en) Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US8656166B2 (en) Storage and authentication of data transactions
US8667269B2 (en) Efficient, secure, cloud-based identity services
US9425958B2 (en) System, method and apparatus for cryptography key management for mobile devices
US20030012386A1 (en) Forward-secure commercial key escrow systems and escrowing methods thereof
US20050071657A1 (en) Method and system for securing digital assets using time-based security criteria
KR20030071843A (en) Method and system for obtaining digital signatures
CA2949847A1 (en) System and method for secure deposit and recovery of secret data
KR19990044692A (en) Document authentication system and method
US20090271627A1 (en) Secure Data Transmission
JPH10274926A (en) Cipher data restoration method, key registration system and data restoration system
JP2009514072A (en) Method for providing secure access to computer resources
US20080044023A1 (en) Secure Data Transmission
US20070055893A1 (en) Method and system for providing data field encryption and storage
US8583943B2 (en) Method and system for providing data field encryption and storage
US8401183B2 (en) Method and system for keying and securely storing data
Kou Networking security and standards
Barker et al. Sp 800-57. recommendation for key management, part 1: General (revised)
Brauer Authentication and security aspects in an international multi-user network
JP3989340B2 (en) Database security system
Aljahdali et al. Efficient and Secure Access Control for IoT-based Environmental Monitoring
Headayetullah et al. Efficient and Secure Information Sharing For Security Personnels: A Role and Cooperation Based Approach
Chousiadis et al. An authentication architecture for healthcare information systems
Dridi et al. Managing Security in the World Wide Web: Architecture, Services and Techniques

Legal Events

Date Code Title Description
AS Assignment

Owner name: ERUCES, INC., KANSAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TYSHLEK, ALEXANDER;REEL/FRAME:013375/0199

Effective date: 20020912

Owner name: ERUCES, INC., KANSAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VASIC, OGNJEN;ANSARI, SUHAIL;GAN, PING;AND OTHERS;REEL/FRAME:013375/0215;SIGNING DATES FROM 20020606 TO 20020917

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: GINN, GREGORY WAYNE, TEXAS

Free format text: COURT TURNOVER ORDER;ASSIGNOR:ERUCES, INC.;REEL/FRAME:043016/0626

Effective date: 20170621

AS Assignment

Owner name: CENTRAL VALLEY ADMINISTRATORS, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GINN, GREGORY;REEL/FRAME:044507/0218

Effective date: 20171207

Owner name: FARRUKH, ABDALLAH, DR., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GINN, GREGORY;REEL/FRAME:044507/0218

Effective date: 20171207