US20160021068A1 - Encryption device with configurable security functionality using network authorization code - Google Patents

Encryption device with configurable security functionality using network authorization code Download PDF

Info

Publication number
US20160021068A1
US20160021068A1 US14/697,627 US201514697627A US2016021068A1 US 20160021068 A1 US20160021068 A1 US 20160021068A1 US 201514697627 A US201514697627 A US 201514697627A US 2016021068 A1 US2016021068 A1 US 2016021068A1
Authority
US
United States
Prior art keywords
sped
user
key
data
hcd
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
US14/697,627
Inventor
Robert R. Jueneman
Duane J. LINSENBARDT
John N. Young
William Reid Carlisle
Burton George Tregub
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.)
Spyrus Inc
Original Assignee
Spyrus Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Spyrus Inc filed Critical Spyrus Inc
Priority to US14/697,627 priority Critical patent/US20160021068A1/en
Publication of US20160021068A1 publication Critical patent/US20160021068A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/32User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • 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/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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
    • 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/0822Key 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 key encryption key
    • 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/085Secret sharing or secret splitting, e.g. threshold schemes
    • 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/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • 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/2113Multi-level security, e.g. mandatory access control
    • 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/24Key scheduling, i.e. generating round keys or sub-keys for block encryption
    • 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
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/63Location-dependent; Proximity-dependent

Definitions

  • Another trend in data mobility is to upload and download data on demand over a network, so that the most recent version of the data is always accessible and can be shared only with authorized users.
  • This facilitates the use of “thin client” software and minimizes the cost of storing replicated versions of the data, facilitates the implementation of a common backup and long-term storage retention and/or purging plan, and may provide enhanced visibility and auditing as to who accessed the data and the time of access, as may be required for regulatory compliance.
  • thin client software greatly increases the vulnerability of such data to hackers who are able to penetrate the firewalls and other mechanisms, unless the data is encrypted on the storage medium in such a way that only authorized users could make sense of it, even if an unauthorized user were able to access the encrypted files.
  • What is needed is a secure portable storage apparatus and method of encrypting and sealing (via a combination of secure hash and digital signature technologies) digital information files and storing them in the device's integral or removable memory, or alternatively on the host device's memory or other ancillary memory storage devices, while operating under cryptographically protected security policies for transport and authorized access to such digital information.
  • the portable encryption device provide and make use of a highly secure logon mechanism, to ensure that a user is not allowed to or even be capable of operating the device in order to encrypt, decrypt, sign, or verify the data, or perform various other sensitive operations unless and until that user has been specifically authenticated and authorized in accordance with the organization's security policies and procedures.
  • a secure PIN entry mechanism as well as supporting an optional biometric identification mechanism, and various other optional enhanced authentication devices, functions, and methods.
  • the secure portable encryption device may be used in a high threat and high-risk environment, there is the possibility that the device could be lost, stolen, or captured by competitive or criminal forces, and later disassembled and even reverse engineered by a sophisticated and capable adversary. For this reason, it is highly desirable that it be impossible for such an organization to extract the user's authorization PIN or password, biometric template, or other enhanced authentication/authorization parameters, or any of the private keys or critical cryptographic parameters, either from the data itself, the encryption device itself, or from the cryptographic processor, or from combination of the three.
  • An “enclave” is considered to consist of one or more host computers operating within a single organization or enterprise and under the control of a common security administration, typically subject to some level of physical security, and within which there is some reasonable expectation of interoperability with respect to the use of the subject invention.
  • An example of an enclave would be the computers used within a single corporate campus, such that an employee could insert and use the secure portable secure encryption device.
  • An enclave may be restricted in its scope to include only those host computers that are authorized to process information of a particular type, e.g. Engineering, Human Resources, or Finance. A given host computer may be authorized to be a member of multiple enclaves.
  • a “domain” is considered to consist of one or more enclaves distributed across one or more enterprises or organizations, all operating within a common security framework and policy.
  • An example would be a collection of computers operating at the SECRET level throughout a portion of the Department of Defense, including civilian contractors and other cleared users.
  • a “Community of Interest” is typically a more loosely defined set of host processors and users who all share a common interest and “Need to Know,” even if (in some cases) that interest spans enclaves and domains and even governmental boundaries.
  • An example would be communications between the U.S. military and our allied and coalition partners, and in some cases even indigenous tribal authorities and informal collaborators.
  • a community of interest might include “Friends and Family,” a chat room, membership on a professional or social e-mail or blog list, etc.
  • guard processor can be provided to ensure that only encrypted and sealed information can be written to or read from designated input/output ports or devices, including removable media.
  • a “black” guard processor could examine any incoming or outgoing traffic on a communications link to ensure that it was properly encrypted and had not been modified prior to allowing it to be transmitted or received, without the necessity of providing the guard processor the ability to decrypt the data.
  • a “red” guard processor could also be used to decrypt and examine the data for specified sensitive context prior to either releasing it for transmission or, if sensitive data is identified, returning it to the originator with instructions to delete the sensitive data, and perhaps raising an alarm or log event that proper policies have not been followed.
  • data typically in the form of a file
  • data may be communicated, relayed, and stored over a large number of communications and storage media, each of which has some small but finite probability of introducing an error into the transmission or storage of that information. Even if the error is later detected, it may not be possible to correct it if the original source is no longer available.
  • an uncorrected error may cause error propagation throughout the remainder of the decrypted file or message after the point of the error, rendering the data completely unintelligible.
  • the methods and apparatus use encryption/decryption and digital signing techniques and related private key and public key algorithms and key sizes that are preferred by the communities of users or have been adopted by international or national standards, or are proprietary to unique institutions.
  • One preferred cryptographic embodiment and implementation is currently (year 2008) represented by the “Suite B” algorithms for both unclassified and classified use by the U.S. Government.
  • Suite B consists of Elliptic Curve Cryptography (ECC) in the prime field GF(P) using key sizes P-256 and P-384 for key establishment between two parties as well as for digital signature creation and verification; the Advanced Encryption Standard (AES) with keys sizes of 128 or 256 bits for symmetric key encryption; and the updated Secure Hash Algorithms (SHA-256 and SHA-384).
  • ECC Elliptic Curve Cryptography
  • AES Advanced Encryption Standard
  • SHA-256 and SHA-384 Secure Hash Algorithms
  • the processes to authenticate the user and authorize decryption of the data are generally not cryptographically secure nor are they adaptable to be implemented by the portable storage device itself, even with the presence of processing capability on the device.
  • the present invention addresses these issues and severely mitigates or eliminates vulnerabilities or requires levels of time and effort that could well render the value of the information as insignificant by the time it could be exposed as plaintext.
  • one or more of the generated secrets have been shrouded with one or more external secrets using an invertible transform, such that any one of the external secrets may be changed without recreation or re-dealing of all of the plurality of generated secrets.
  • a suitable invertible transform is XOR.
  • One or more of the external secrets may comprise a user's PIN, which may be a supervisory user's PIN.
  • the external secrets comprise a plurality of user's PINs, and the transform is invertible with less than all of the plurality of user's PINs.
  • one or more of the external secrets comprise a firmware hash
  • one or more of the external secrets comprise a host authorization code associated with one or more specific host computing devices, binding the portable encryption device to such one or more host computing devices, or one or more of the external secrets is generated by a proximity detection mechanism.
  • An external secret can also be a function of multivariate parameters, such as geographic-locus or biometric input.
  • the external secrets are communicated over a secure channel with a secondary device, such as a connected host computing device, or a remote device.
  • Means for interfacing with a user authentication device can be added, such as a secure PIN entry mechanism, or secure biometric input.
  • Still further embodiments comprise removable memory configured for data storage, a data communication module, or additional cryptographic processors within the enclosure.
  • the cryptographic processor may be a microprocessor that has been programmed to execute cryptographic functions.
  • a method for controlling logon access on a portable encryption device having a portable form factor and a cryptographic processor comprising generating a plurality of secrets by a secret sharing algorithm, configuring the cryptographic processor to reconstitute an encryption key from the plurality of generated secrets, and determining logon access as a function of the reconstituted encryption key.
  • the secret sharing algorithm may comprise a K out of N secret sharing mechanism, such as Shamir's Secret-Sharing Algorithm with Lagrange interpolation.
  • the encryption key may be, for example, a master key encryption key, or application key encryption key.
  • a further step can be added of shrouding one or more of the generated secrets with one or more external secrets using an invertible transform, such that any one of the external secrets may be changed without recreation or re-dealing of all of the plurality of secrets.
  • a suitable invertible transform is XOR.
  • One or more of the external secrets may comprise a user's PIN, which may be a supervisory user's PIN.
  • the external secrets comprise a plurality of user's PINs, and the transform is invertible with less than all of the plurality of user's PINs.
  • a further step can be added of communicating the external secrets over a secure channel with a secondary device, such as a connected host computing device, or a remote device.
  • a step is added of receiving input from a user authentication device, such as secure biometric data, optionally over a secure channel.
  • a portable encryption device with file decryption controlled by a file encryption key comprising an enclosure for the device providing a portable form factor, and a cryptographic processor within the enclosure for reconstituting the file encryption key from a version of the file encryption key which has been shrouded with a network authorization code.
  • a method for controlling file decryption with a portable encryption device having a portable form factor and a cryptographic processor comprising generating a network authorization code, distributing the network authorization code to a community of interest through an out-of-band distribution mechanism, shrouding a file encryption key with the network authorization code using an invertible transform, receiving the network authorization code from a user, causing the cryptographic processor to reconstitute the file encryption key from the received network authorization code, and determining file access as a function of the reconstituted file encryption key.
  • An encrypted file may then be decrypted as a function of the reconstituted file encryption key.
  • the invertible transform may be XOR, or an invertible transform that is resistant to quantum computing attacks.
  • the network authorization code is encrypted and code is distributed to a recovery agent.
  • a method for file encryption of a plaintext file comprising the steps of hashing the plaintext file to produce a plaintext hash, compressing the plaintext file, encrypting the compressed plaintext file to create ciphertext, hashing the ciphertext to produce a ciphertext hash, hashing the plaintext hash and the ciphertext hash to produce a result hash, and sealing the ciphertext together with the result hash using a digital signature algorithm to produce the encrypted file.
  • the encrypted file may be communicated to originator-selected optional recipients.
  • a portable encryption device having a portable form factor and an on-board cryptographic processor may be used to perform the method.
  • a further embodiment separately encrypts the metadata, and the seals the ciphertext together with the result hash and the encrypted metadata.
  • Optional further steps for independent key exchange mechanism to permit decrypting the metadata by catalog agent are possible.
  • FIG. 1 is a block diagram of one embodiment of how a SPED can be utilized.
  • FIG. 2A is a block diagram of a HCD, and one embodiment of an SPED, and biometric authenticator configurations.
  • FIG. 2B is a perspective view of one embodiment of an HCD and SPED.
  • FIG. 2C is a sketch of an SPED in a portable form factor.
  • FIG. 3B is a view of a physical implementation of one embodiment of a system incorporating an SPED and HCD.
  • FIG. 4 is a flow chart of a method, according to an embodiment, for installing software to initiate use of an SPED and to authenticate a user or system security officer.
  • FIG. 5 is a block diagram of an HCD, according to one embodiment of the invention.
  • FIG. 6 is a block diagram illustrating one embodiment of the HCD, the SPED, and the optional secure PIN entry/biometric sensor device.
  • FIG. 7 is a flow chart of a method, according to one embodiment of the invention, for selecting among the different modes of operation of a system according to one embodiment of the invention.
  • FIG. 8 is a flow chart of one embodiment of key management within an SPED.
  • FIG. 9 is a block diagram of another embodiment of the physical implementation of the system with security operations executed by software within the SPED.
  • cryptographic operations are implemented on data for secure storage and transport by means of a system comprised of one or more than one secure portable encryption device (“SPED”) capable of such cryptographic operations, and optionally storing and communicating such secure data to host or peripheral devices, one or more than one host computing device (“HCD”), and means for securely protecting access to that data.
  • SPED secure portable encryption device
  • HCD host computing device
  • One embodiment of the means for securely protecting data is to permit access and cryptographic operations on that data only to authorized recipients, or only on authorized host computing devices, by a “K of N” split-knowledge sharing algorithm method of generating and cryptographically assigning shrouded secret shares which are bound to authentication/authorization means such as shareholder PINs, passwords, Host Authorization Codes (HAC), or other host, SPED, or other user authentication/authorization means as will be known to one or ordinary skill in the art with reference to this disclosure.
  • Another embodiment of the means for securely protecting data is to utilize a Network Access Code (“NAC”) as part of a shrouding operation on file encryption keys.
  • NAC Network Access Code
  • Another embodiment is a method for file encryption of a plaintext file, comprising the steps of hashing the plaintext file to produce a plaintext hash, compressing the plaintext file, encrypting the compressed plaintext file to create ciphertext, hashing the ciphertext to produce a ciphertext hash, hashing the plaintext hash and the ciphertext hash to produce a result hash, and sealing the ciphertext together with the result hash, to produce the encrypted file.
  • the phrase “cryptographic operation” includes hashing, encryption/decryption, digital signature/verification, and sealing (e.g., hashed and digitally signed ciphertext).
  • PIN Personal Identification Number
  • the term “PIN” is used herein to designate a (typically short) series of numbers, an alphanumeric password, or a lengthy passphrase consisting of arbitrary words, letters, numbers, and/or special characters without limitation.
  • the SPED is used to communicate with the HCD to enable one or more cryptographic operations to be performed by the SPED on data provided from the HCD to the SPED (which data can then be, for example, stored in the SPED or returned to the HCD for storage) or on data that has been transmitted by wire or wireless means to the SPED from another device, or input to the SPED by a person.
  • the data may be represented and stored as individually encrypted and/or sealed files.
  • the process of hashing, compressing, encrypting, and digitally sealing the file results in a new object that may be of considerably different size, either larger or more often smaller than the original, with the result that the encrypted file cannot simply replace the original file.
  • the act of storing the encrypted file must involve interactions with the directory or File Allocation Table in ways that the originating program or operating system cannot easily discern.
  • the means of encrypting these files may either be a straight pass-through, generally requiring the implementation of a file-handling system within the SPED itself, or the data may be looped-back to the HCD, either for storage locally, or for yet another pass, wherein the files are broken up into discrete sectors by the host operating system prior to being stored on the SPED, such that the SPED is not required to implement the required file processing logic.
  • the means of generating and distributing Host Authorization Codes for host computing devices on the basis of security policies allows an institution to permit users to securely move data back and forth among a multiplicity of computers in a defined enclave, for example, between a branch and a central office, but prevents a user from decrypting the data on an unauthorized machine, even if the user possesses the encrypted data, the SPED device containing the keys necessary to decrypt the data, and is in possession of the PIN/password required for access, and can even satisfy any biometric criteria, so long as he does not know the Host Authorization Code, or other Enhanced Authorization codes, devices, or methods.
  • This invention dynamically defines and configures the authorized population and tiers of users, portable encryption devices, and host computing devices.
  • the use of a set of K out of N shrouded secrets to reconstitute a Master Key Encryption Key involves the use of an exclusive-OR operation for the shrouding, and a mathematical algorithm (Shamir's secret sharing algorithm) involving N equations with K unknowns. Neither of those operations involve the use of cryptography in the conventional sense, and the difficulty of “breaking” such schemes does not depend upon any assumptions of computational intractability, but instead provide provable mathematical intractability.
  • K out of N secret sharing scheme for example, if fewer than K shares are entered, or if any of the shares are entered incorrectly, then the results are mathematically indeterminate and no better than random guessing. Likewise, if even a single bit is in error in the shrouded calculation, then the result is simply incorrect, and provides absolutely no information that might aid an attacker.
  • this embodiment of the invention provides mathematically provable security with regard to the reconstitution of the Master Key Encryption Key. Even if a very sophisticated laboratory attack could be used to “peel” the security processor chip and extract the contents, without the knowledge of K out of N of the authentication factors, it is mathematically impossible to recover any data, unless someone can break the AES-256 key wrapping algorithm.
  • two subsystems operate in conjunction for creating and distributing secret shares and Host Authorization Codes according to the authorized configuration of users, secure portable encryption devices, and host computing devices: (1) a hardware-based encryption device identified as the Secure Portable Encryption Device (SPED) that connects to a host computer device via an interface such as a Universal Serial Bus (USB 2.0 or 1.1), an ExpressCardTM interface, or other similar wired or wireless functionality, and contains its own integrated cryptographic security and operational processing capabilities and memory storage facilities, and (2) a general purpose computer, or a form of PC computer, PDA, cell phone, or other type of programmable computing device supporting applications software, referred to as the host computer device, which contains a suitable operating system, the necessary device drivers and other middleware, and an application program which provides the Graphical User Interface (GUI) to control the functionality.
  • SPED Secure Portable Encryption Device
  • USB 2.0 or 1.1 Universal Serial Bus
  • ExpressCardTM interface or other similar wired or wireless functionality
  • GUI Graphical User Interface
  • the Originator/user 11 of data 12 is shown as part of the block diagram which depicts the various major functional parts of the system including the two apparatus subsystems, the secure portable encryption device 14 (hereinafter referred to as the SPED) and the host computing device 13 (hereinafter referred to as the HCD). It also illustrates the cryptographic system means 20 by which access to the stored content of the SPED 14 is authorized only for designated users 11 and HCDs 13 .
  • the SPED secure portable encryption device 14
  • HCD host computing device 13
  • Data 12 is introduced into the system for the purpose of having some cryptographic operations performed on it (e.g., digital signature, hashing, encryption) in order that it may be secured in the HCD 13 to be securely transported 15 , via the SPED 14 , to another authorized HCD 13 for the originator's 11 use, or for use only by an authorized Recipient 17 , and protecting the SPED 14 so that, if lost, the data content cannot be accessed.
  • some cryptographic operations performed on it e.g., digital signature, hashing, encryption
  • the data 12 can be any form of digital data (text, photographic, scanned, audio, video, etc.) and can be generated through keyboard input 18 by the user 11 , or input by the user through attachment of a peripheral device (e.g., disc reader, memory storage device, digital camera, etc.) or downloaded through some form of wired or wireless network connection to either the HCD 13 or the SPED 14 .
  • a peripheral device e.g., disc reader, memory storage device, digital camera, etc.
  • the SPED 14 can be of a form such as a flash drive token, or a digital media recorder/receiver or iPod® type device, with integral or replaceable/removable memory, comprised of cryptographic and operational processing hardware capabilities, control and flow logic controls, and interface connections for multiple device attachments.
  • HCD 13 such as a personal computer, hereinafter referred to as a PC.
  • HCDs 13 may be cell phones, video recorders, workstations, or other device configurations which support an input device 18 for input of user commands (e.g., a keyboard or touch screen), some form of display 19 for graphically providing information to the user, a form of digital computer processor for computing on data and interfacing with the input commands supplied by the user, storage memory means for storing data and program instructions, connection port interfaces (e.g., USB, Firewire, ExpressCardTM) for connecting with peripherals (e.g., disc storage, printers, scanners) and communications devices (e.g., WLAN, Ethernet, modems), control logic and busses for routing of data and control signals among all the elements of the device and with external peripheral devices sufficient to perform the functions required by the application, and some form of operating system software (e.g., Windows XP®, Windows Mobile®, VISTA®, MAC OS®, Linux®, Sym
  • Externally generated data may be loaded into the HCD via any of the available interfaces of the HCD or, in another embodiment, loaded into the SPED through an external secondary connector integral to the SPED.
  • Access to the SPED 14 contents and its operation with an HCD 13 is controlled by authentication of an authorized user 11 and a HCD 13 authorized by the SPED 14 through use of a split-knowledge approach that applies the Shamir secret sharing algorithm, which is well known to those who practice the state-of-the-art in cryptography.
  • System means for implementation of the secret sharing algorithm is comprised of computing method 20 , executed by cooperation between host computing device 13 and secure portable encryption device 14 , that creates the Master Key Encryption Key that protects the critical cryptographic parameters of the SPED and creates secret authorization shares which protect the contents of the SPED from access by any but authorized users on authorized HCDs.
  • AKEKs Application Key Encryption Keys
  • Secret sharing refers to any method for distributing a secret amongst a group of entities, human or inanimate, each of which is allocated a share of the secret. The secret can only be reconstructed when the shares are combined together; individual shares are of no use on their own. Secret sharing schemes were discovered independently by Blakley and Shamir. The motivation for secret sharing is secure key management. There is one secret key, the SPED 14 Master Key Encryption Key (the MKEK), (or potentially one or more Application Key Encryption Keys per application) which provides access to all the secure keys and critical cryptographic attributes held by the SPED 14 .
  • MKEK Master Key Encryption Key
  • Secret shares are created within the SPED 14 through an initialization process that generates, according to the method of Shamir, a temporary polynomial equation from which the MKEK and the secret shares are derived.
  • the shares are then individually combined and shrouded, through the use of a transform, with external secrets (e.g., PINs, authorization codes) from each of the entities or components comprising the system (e.g., users and apparatus, namely, users 11 , the HCDs 13 , and the SPED 14 ).
  • external secrets e.g., PINs, authorization codes
  • the novelty of storing and using a transform rather than the secret shares themselves prevents collusion of external entities, which have knowledge of their own external secrets, from recovering and reconstituting the MKEK or AKEKs, and allows simpler logistics for changing any individual entity's secret without generating a new polynomial and distributing new shares to all.
  • the external secrets are required inputs for authorization to reconstitute the secret MKEK or an AKEK and access the secured data contents contained by the SPED 14 or the associated HCD 13 .
  • K, N any group of K or more entities (up to N) can come together to reconstruct the secret MKEK or an AKEK, but no group of less than K entities can accomplish this.
  • Such a system is called a (K, N)-threshold scheme.
  • a popular technique to implement share reconstitution in polynomial based threshold schemes uses polynomial interpolation (“Lagrange interpolation”). Two points uniquely define a line, three points define a parabola, four define a cubic curve, etc. More generally, n coordinate pairs (x i , y i ) uniquely define a polynomial of degree n ⁇ 1.
  • the SPED 14 processor generates the temporary polynomial equation, encodes the secret (i.e., the SPED Master Key Encryption Key—MKEK or one of the Application Key Encryption Keys) as the curve's y-intercept, and creates shares, each of which represent the coordinates of a point on this curve.
  • MKEK the SPED Master Key Encryption Key
  • interpolation can compute the y-intercept that represents the secret MKEK. It is also possible, using a well-known optimization of the Lagrange method, to recover a specific point without recovering the entire polynomial.
  • Shamir's scheme is provably secure, that means: in a (K, N) scheme one can prove that it makes no difference whether an attacker has K ⁇ 1 valid shares at his disposal or none at all; as long as he has less than K shares, there is no better option than guessing to find out the secret.
  • K shares the polynomial is uniquely determined and hence the secret MKEK, the “y” intercept, can be computed.
  • MKEK the secret
  • the external secrets cannot be used directly to reconstitute the secret MKEK.
  • the shrouding operation discussed above provides additional security against attacks by ensuring that the secret shares do not remain in static storage within the system and are only reconstituted at their time of use.
  • the shrouding technique provides the additional advantage that a user's PIN or some other external input can easily be changed by un-shrouding with the old value and reshrouding it with the new value, without have to replace the shared secret or re-deal all of the shares. Because of this approach, neither the share values nor the external secrets are ever stored on the SPED.
  • the external secrets e.g., PINs, authorization codes
  • N ⁇ (K+1) of the external secrets are the only values known outside the SPED.
  • the MKEK is mathematically-provably secure, as the scheme does not rely on the usual assumptions of “computational infeasibility” required for most cryptographic operations. So long as K shares are known, the MKEK can be recovered, otherwise all of the data protected by the MKEK will be irretrievably lost.
  • the entities with shares include two classes—authorizing and enabling. At least one of the authorizing entities, the security officer PIN or the user PIN, must be present in order to reconstitute the secret MKEK. Enabling shares are bound to at least: 1) the media controller/microprocessor in the SPED 14 , 2 ) the SPED itself through identification of its integral cryptographic processor chip, and 3) a host-computing device. Optional shares may be created and stored within the SPED cryptographic processor for binding with other identified entities. Where a security officer is not involved, the user PIN and the security officer PIN can be set to be equal. External PINs and/or passwords uniquely associated with each of the entities are cryptographically associated with each of these shares as will be discussed further below.
  • FIG. 2A is a block diagram of a system 200 .
  • the system 200 includes an HCD and a SPED 202 that communicate via a communications interface 203 .
  • the SPED may also optionally contain another communications port interface ( 204 ) for connection to other types of peripheral devices 205 , such as digital cameras, wireless or wire transceivers, memory devices, etc.
  • the SPED 202 includes at least an integrated cryptographic processor IC chip set 202 a that enables cryptographic operations (examples of which are described in more detail below) to be performed on data that is stored within and “looped-back” to the HCD 201 , data that is transmitted from the HCD 201 to the SPED 202 , data that is transmitted from the SPED to the HCD 201 , data that is transmitted from another peripheral device 205 through connection port 204 to the SPED, data that is transmitted from the SPED 202 to another peripheral device 205 through connection port 204 .
  • cryptographic operations examples of which are described in more detail below
  • the SPED 202 can obtain its mass memory capacity through integral connection port 206 which interfaces to a mass memory storage module 207 (e.g., a mini SD memory card).
  • a mass memory storage module 207 e.g., a mini SD memory card.
  • the SPED 202 can connect, as shown in FIG. 2C , through connection port 206 to a biometric module 208 (e.g., a module including a fingerprint scanning device 209 , a retinal scanning device, or a face print scanning device) with a secure direct entry scrolling thumbwheel or similar device 210 , a display window for status information 211 , and an internal connector 212 for connection to SPED 202 through connector 206 .
  • a biometric module 208 e.g., a module including a fingerprint scanning device 209 , a retinal scanning device, or a face print scanning device
  • a secure direct entry scrolling thumbwheel or similar device 210 e.g., a display window for status information 211
  • the communications interface 203 can be embodied by any of a variety of communication interfaces, such as a wireless communications, USB, Firewire, Express Card, a serial such as an RS-232 interface, or a parallel interface.
  • Each embodiment of the communications interface 203 includes hardware present in each of the HCD 201 and SPED 202 that operates in accordance with a communications protocol (which can be embodied, for example, by software stored in a memory device and/or firmware that is present in the HCD 201 and SPED 202 ) appropriate for that type of communications interface, as known to those skilled in the art.
  • a communications protocol which can be embodied, for example, by software stored in a memory device and/or firmware that is present in the HCD 201 and SPED 202
  • Each embodiment of the communications interface 203 also includes mechanisms to enable physical engagement, as appropriate, between the HCD 201 and the SPED 202 . Similar embodiments can exist for communications port 204 to connect peripheral modules 205 and the SPED 202 .
  • the cryptographic processor configuration 202 a can be configured to perform any electronic data cryptographic operation (herein, referred to simply as a “cryptographic operation”) including, for example, operations that provide one or more of the basic cryptographic functions, such as hashing, encryption/decryption, digital signature, key exchange, verification of data integrity, and user authentication. Particular cryptographic operations that can be implemented in the SPED 202 are described in more detail below.
  • a cryptographic operation including, for example, operations that provide one or more of the basic cryptographic functions, such as hashing, encryption/decryption, digital signature, key exchange, verification of data integrity, and user authentication.
  • the cryptographic processor configuration 202 a can be, for example, a dedicated cryptographic processor in combination with an FPGA and an ARM microprocessor.
  • “cryptographic processor” refers to an IC chip set configuration that performs cryptographic operations and that includes one or more mechanisms (such as, for example, use of a hardware random number generator and/or protected memory) to provide security for the content of those operations.
  • FIG. 2B is a perspective view of a physical implementation of the system 200 of FIG. 2A , according to one embodiment of the invention.
  • the SPED 202 of FIG. 2A is embodied as a flash card memory device form factor 215 that can be inserted into a corresponding USB socket 213 formed in a laptop computer 214 that, in FIG. 3B , embodies the HCD 201 of FIG. 2A .
  • various pieces of metadata from the original file may be included in final encrypted version of the file.
  • Such data may be carried in the clear, i.e., unencrypted, or it may be encrypted using the same keys used to encrypt the data, or it may be encrypted in yet another key or keys, including the key(s) associated with a central repository or cataloguing service, or in some combination of these keys.
  • the function that performs this cataloging service will be referred to as a Catalog Agent.
  • the Catalog Agent may or may not be the same entity as the Mandatory Recovery Agent described above.
  • FIG. 3A is a block diagram of an SPED 301 , according to one embodiment, including an integral cryptographic processor chip set 302 , a plug-in replaceable/removable mass storage media 303 (e.g., miniSD memory card), and an optional authentication module 304 that consists of a biometric fingerprint scanner and a mechanism for securely entering an alphanumeric PIN input device, such a thumbwheel, joystick, or touch screen. It is possible, as explained in more detail below, to use the modular SPED 301 with the replaceable/removable mass memory storage module 303 without any connected biometric module 304 or external peripheral device.
  • the SPED 301 and memory module 303 are physically separate devices that can be physically and electrically joined (as described further below) to enable communication between the modules 301 and 303 .
  • FIG. 3B is a plan view of a modular SPED 310 that represents a physical implementation, according to one embodiment, of the modular device 301 of FIG. 3A .
  • the SPED 310 includes a first module 311 and can attach to a second module 325 through port connection 314 and can communicate with an attached peripheral 316 (e.g., wireless transceiver) through an additional port connection 315 .
  • a connector 313 is formed at one end of SPED 311 . Opposite the connector 313 is a connector 314 for attaching a miniSD memory card 317 or other mass memory storage module or peripheral 325 with a compatible connection interface for signaling and data transfers.
  • an optional biometric fingerprint scanner 318 and alphanumeric user input device illustrated in FIG. 3 as a scrolling alphanumeric thumbwheel 319 with “push-to-enter” characteristics and display window 320 can be configured as a covering “sleeve” housing 321 to connect to the SPED through connections 314 , for the purposes of using a scanned fingerprint and secure user PIN entry for securely authenticating the user to the SPED 310 and HCD 324 .
  • the mating connection of this biometric module 312 is constructed to have a compatible connection 322 within the recess of its housing to mechanically and electrically interface to the SPED module 311 .
  • the SPED 311 can have a size and shape such that the SPED 311 can be directly inserted into a USB connector socket 323 on the HCD 324 , to enable communication between the HCD 324 and the SPED 310 .
  • another external peripheral apparatus 316 e.g., a digital camera, a wireless transceiver, a memory media, may be directly attached or cabled to the port connection 315 for transferring data to or from the SPED 310 .
  • FIG. 4 is a flow chart of a method 400 for initiating use of a system.
  • the system that includes a SPED and a HCD can be implemented according to the method 400 so that policies can be accommodated for first time initialization of the system by a user or by a designated system security officer 402 .
  • Either designee proceeds through steps 403 or 414 to load and install software on the HCD to display user procedures to initialize, zeroize, change PIN, and view device properties of the SPED.
  • the designated user inserts the SPED 404 into the connection socket of the HCD and the presence of the SPED is detected 405 .
  • the SPED is further configured to optionally recognize a particular recipient HCD through the setting of the Host Authorization Code in steps 406 or 407 , and proceed to initialize the SPED 408 in preparation for the user or SSO authentication process as illustrated by steps 409 and 410 or 411 , 412 , 413 , and 415 .
  • the user may start the application 416 .
  • the system security officer is the designated SPED installer and initializer, the SPED may be delivered to the user by the security officer who initiates a log on process by which the user can enter their own PIN for processing through steps 417 , 418 and 419 .
  • the user then proceeds to authenticate himself to the device through steps 409 and 410 or 411 , 412 , 415 , and if successful, starts the application in step 416 .
  • the method 400 shown in FIG. 4 is not the only way to enable the embodiments of use of an SPED with a HCD as illustrated in FIG. 4 .
  • such embodiments can be implemented using any of a variety of other appropriate methods.
  • the installation of software and initialization of a SPED can include embodiments not illustrated in FIG. 4 as in the case of authentication default processes 413 and 420 ; likewise, such use may not include some of the embodiments illustrated in FIG. 4 because of specific security policies or regulations governing the user's organization.
  • the method 400 of FIG. 4 is shown merely to aid in the illustration of certain embodiments, and should not be interpreted as restricting the manner in which an SPED can be used.
  • FIG. 5 is a block diagram of an HCD 501 according to one embodiment, illustrating operation of the HCD 501 during a method such as the method 400 of FIG. 4 .
  • the HCD 501 e.g., as a desktop PC configuration
  • the HCD 501 comprises a display device 502 (e.g., an LCD display, monitor), and user input device 503 (e.g., a keyboard, touch screen, trackball, joystick or other appropriate device), referred to collectively hereinafter as user interface device 503 .
  • a display device 502 e.g., an LCD display, monitor
  • user input device 503 e.g., a keyboard, touch screen, trackball, joystick or other appropriate device
  • the HCD 501 also comprises, mounted within a housing 504 , a processing device 505 , a memory device 506 , an input/output (I/O) device 507 for enabling communication with the user interface device 503 , and an input/output (I/O) device 508 for enabling communication with the SPED.
  • the devices 505 , 506 , 507 , and 508 can each be implemented by conventional devices and can communicate with each other via a conventional computer bus 509 , as is well known and understood.
  • FIG. 6 is a block diagram of system 600 , according to one embodiment, comprising the separate hardware and software/firmware components that are used in the cryptographic-processing, authentication, and authorization processes such as the method 400 of FIG. 4 .
  • the HCD 601 comprises resident applications software and drivers that interface with the SPED 610 and cooperate to execute the secret sharing algorithm for combining cryptographic shares from the user, the HCD 601 , the SPED 610 , and, optionally, an administrative security officer, to implement the system means for reconstituting the Master Key Encryption Key of the module SPED 610 as will be described later.
  • the user interface software module 602 is integrated into the operating system file system through a browser shell and interacts with the user by providing the user with appropriate menus and messages.
  • the SPED middleware 603 provides functionality that is used by the user interface to interact with the modular SPED 610 .
  • the SPED administrative tool software module 604 provides a user interface for SPED administration that helps the user to initialize, zeroize, change PIN, and view the device properties.
  • the filter driver software module 605 is constructed as a file system mini-filter driver that uses the operating system filter manager component.
  • the USB function driver module 606 presents a Microsoft Windows PCSC interface to the system and the host authorization service module 607 is a service that runs in system space as part of the systems methods that protect the host authorization code and cooperates with the SPED 610 to support the execution of the shared secret algorithm. In other operating systems, similar constructs could be used.
  • One embodiment of the SPED 610 includes a processor/controller device 611 , an FPGA 612 , a cryptographic processing device 613 , an attachable/replaceable memory device (e.g., miniSD, miniSDHC, or microSDHC memory card) 614 , an input/output (I/O) device 615 for enabling communication with the host computing device 601 , an input/output (I/O) facility 616 for enabling communication with an optional biometric fingerprint scanner and secure PIN entry device 620 , and to communicate and interface with an optional peripheral device (e.g., a digital camera, an additional memory media, a wireless transceiver) 617 .
  • an optional peripheral device e.g., a digital camera, an additional memory media, a wireless transceiver
  • the components 611 , 612 , 613 , 614 , 615 , 616 , and 617 can each be implemented by commercially made devices and can communicate with each other via conventional computer busses as is well known and understood.
  • the processor/controller 611 is a 32-bit ARM processor and is the main controller for all the secure mass storage operations and for most interface data flows performed by the SPED module 610 . It acts as the master state controller for the SPED module 610 , and implements public key cryptographic and signing processing used during the file encryption and decryption operations. It also implements a hashing operation as part of providing the random numbers required for ephemeral keys and other cryptographic values.
  • the FPGA 612 provides high-speed execution of AES-256 and SHA-384 algorithms (as well as other AES key size and hash size alternatives) to support encrypt-and-seal/decrypt-and-verify operations, as well as providing the interface to the cryptographic processor 613 and the attachable mass memory (e.g., mini-SDHC memory card) storage device 614 .
  • AES-256 and SHA-384 algorithms as well as other AES key size and hash size alternatives
  • the cryptographic processing device 613 is implemented in a cryptographic controller that has been programmed for such processes.
  • the secure operation of the SPED 610 uses this processor for user authentication and for secure generation and storage of the static keys used during file encryption and decryption. It also provides an approved high-entropy random bit generator. In this embodiment, it is fabricated with special coating and electrical shield properties and zeroization schemes to protect the chip contents from sophisticated electronic “peeling” or scanning or invasive attacks to retrieve secure contents.
  • an optional biometric authentication device comprises a fingerprint scanner and secure PIN entry 620 and serves to provide, during the user log-on process, additional secure levels of authentication through biometric fingerprint scanning to match user templates captured and stored in the processor 621 memory of the 620 during scanner training and initialization procedures.
  • This physical configuration embodiment fits as a sleeve over most of the SPED module 610 and connects through an internal connector 625 that is within the recess of the module and interfaces with the SPED module 610 .
  • the biometric authentication device 620 includes an integrated control processor 621 with on-chip RAM and flash memory, and a biometric fingerprint swipe or platen sensor 622 used for capturing the fingerprint image that can be processed by the SPED module 610 for template matching and user authentication.
  • the biometric module 620 also comprises a scrollable thumbwheel or other form of human input device 623 for use in direct secure PIN entry by a user.
  • the control processor 621 When requested by the SPED module 610 , the control processor 621 will use this human input device 623 to collect the PIN and send it directly to the SPED module 610 for user authentication.
  • a display 624 is used for displaying status messages and prompting the user for required inputs.
  • the devices 621 , 622 , 623 , and 624 can each be implemented by conventional devices and can communicate with each other via a conventional computer bus 626 , as is well known and understood.
  • the HCD module 601 , the SPED module 610 , the biometric module 620 , and the peripheral device module 617 are shown in simplified form in FIG. 6 to facilitate clarity in illustration of this embodiment, as described in more detail below and as understood by those skilled in the art.
  • the HCD module 601 , the SPED module 610 , the biometric module 620 , and the peripheral device module 617 can—and typically will—include other devices not shown in FIG. 6 .
  • a significant advantage of the system according to the present invention comprising a SPED and a HCD is that the system comprises a set of sequential procedures for system installation and initialization of hardware and software subsystems to configure and integrate physical and logical levels of access authorization for portable memory storage apparatus.
  • the present invention accomplishes this by means of a K out of N split-knowledge technique that combines a mandatory minimum set of: 1) Host Authorization Code (HAC) information that can be specific to a HCD and enables a unique transformed external secret for each HCD, 2) the user's PIN, 3) an optional security officer's PIN, 4) SPED-specific internal identification information, and 5) other unique identifier information that may be optionally required by an organization's security policies and procedures.
  • HAC Host Authorization Code
  • the system can be implemented to employ these individually created and independent authorization parameters to reconstitute at least “K” shared data values whose total combination is required to reconstitute a Master Key Encryption Key (MKEK) that protects the private keys and the other critical cryptographic parameters stored on the SPED against loss or all forms of attacks.
  • MKEK Master Key Encryption Key
  • the system that comprises a HCD and a SPED can, in general, be configured, initialized, and operated in one of two modes depending upon an organization's security policies and procedures: 1) requiring only a single user PIN to install and initialize the system as in the case of a sole proprietorship where the individual selected for the installation and initialization procedures can be the ultimate user of the system, and 2) requiring a second PIN assigned to an administrative system security officer (hereinafter referred to as SSO), as in a government or commercial institution protecting valuable intellectual property or vital national interests.
  • SSO administrative system security officer
  • the system can enable a system security officer or other designated security administrator, according to the policies and procedures of an organization, to be the designated person to physically initialize the SPED with the HCD in order to limit the access only to those users, SPEDs, and HCD host computers that have “need to know” access permissions as defined by such policies and procedures.
  • the system can be implemented so that under such a security policy, first the system security officer can create the HAC for each designated HCD, then create an SSO PIN and initialize the SPED, and then can distribute an SPED to the user for the creation of their PIN as in FIG. 4 , Method 400 , steps 402 , 403 , and 414 .
  • the system that includes a SPED and a HCD can be implemented so that first time use of the system begins when the user loads (either through media (e.g., CD-ROM, the SPED memory download) or network interconnection) and installs mass storage software 602 , 603 , 605 , 607 , into the HCD 601 which includes its own device drivers 605 for the SPED replaceable/removable storage module 614 .
  • This software also includes operational and user interfaces 602 for the SPED replaceable/removable storage module 614 .
  • a user of the system connects the modular SPED 610 device to the HCD. Such connection can occur in any manner that enables the SPED to communicate with the HCD.
  • the SPED can be implemented as a USB flash memory token (e.g., a form factor conforming to a USB connection as established by the appropriate standard), or alternately by an ExpressCard form factor, that is inserted into a corresponding socket formed in the HCD.
  • the SPED can be implemented in a housing from which a connection cord extends, a plug of the cord being inserted into a mating receptacle formed in the HCD.
  • the SPED can also be connected to the HCD by any type of wireless communication, e.g. Bluetooth or infrared, for which the HCD contains an appropriate interface.
  • the system that includes a SPED and a HCD can be implemented so that for the first time use of the system, a user can also load and install administrative tools software 604 on the HCD 601 that provides user interfaces and procedures to initialize, zeroize, change PIN and view device properties on the SPED 610 and operate the SPED 610 and HCD 601 systems.
  • administrative tools software 604 on the HCD 601 that provides user interfaces and procedures to initialize, zeroize, change PIN and view device properties on the SPED 610 and operate the SPED 610 and HCD 601 systems.
  • a user inserts the SPED 610 into the connection socket of the HCD 601 .
  • the HCD 601 detects the presence of the modular device. Such detection of the presence of a peripheral device is typically enabled as a standard embodiment of the software installed into the HCD.
  • All of the hashing, symmetric key encryption/decryption, and public key operations may be performed within the security perimeter of the trusted hardware security device.
  • another embodiment may comprise a hybrid means whereby a decrypt-only capability could be provided, wherein only the public key operations are implemented within a hardware device, and the hashing and/or symmetric key operations are carried out in software on the host computing device.
  • Yet another embodiment may consist of a purely software implementation of the Recovery Agent decryption capability.
  • the authentication and authorization methods used within the SPED are sufficiently extensible as to deal with other enhanced authentication devices, methods, and functions, in such a manner as not to necessitate the storing of such enhanced authentication parameters (e.g., biometric indicia, user proximity detection code, permitted operational location information, etc.,) for later comparison in such a manner that such parameters could be extracted and used, under even national laboratory conditions.
  • enhanced authentication parameters e.g., biometric indicia, user proximity detection code, permitted operational location information, etc.,
  • an organization security officer/administrator or an individual user loads a set of software modules into the host-computing device from a CD-ROM, from a read-only portion of the SPED itself, or from other forms of software distribution media, including wireless communications.
  • the administrator/user determines if the SPED is to function only on one or more designated host computing devices, or with any and all host computing devices. In the case of assigning the SPED to only work with designated host computing devices, the SPED executes, prior to initialization, a series of programs to establish one or more named or default “Host Authorization Codes (“HAC”) which can be unique to each host computing device or can be shared among an enclave or Community of Interest of users.
  • HAC Home Authorization Codes
  • an administrator can, personally or by delegation to a trusted representative, cause the same HAC to be set on each HCD or can set multiple HACs on HCDs if the host computing devices are to be shared by different user enclaves or Communities of Interest.
  • a default HAC is created and the initialization program creates an individual PIN and generates new sets of cryptographic signature and encryption keys.
  • the administrator can generate a system security officer PIN and each user PIN number to complete the initialization process.
  • a “diversified” version of the HAC may be created by hashing or encrypting the stored HAC value together with the serial number of SPED device, prior to loading the diversified HAC onto the SPED, in order to ensure that a “wire-sniffing” attack could only compromise the particular diversified value of the HAC used for that particular SPED, and not all such devices.
  • the integrated SPED processor mediates the communications between the host computing device (HCD) and the SPED itself, as a result of user interface enabled instructions provided by the host computing device, to allow various options for user authentication and log on, device initialization, optional setting of the host authorization code (HAC), and control of the processing and flow of the encrypted/decrypted data.
  • HCD host computing device
  • One security mode encrypts data from the HCD and stores it directly in the SPED memory media for storage or communication with another device.
  • data from the HCD is encrypted and returned directly in a “loop-back” mode of operation, without being stored for application usage by the SPED memory, and, in the reverse situation, data from the HCD is sent to the SPED for decryption and then returned.
  • HCD data encrypted by the SPED can only be accessed and decrypted by a user who has the PIN and the SPED device, and an authorized computer, if a host authorization code process has been established.
  • the SPED is activated by the user through the input of a PIN to execute the log on process and gain access to the facilities of the SPED.
  • the PIN is established during an initialization process, which can be executed by an individual user acting as a security administrator.
  • the system security officer can initialize any SPEDs. The user may be allowed to change his or her own PIN/pas sword, or that ability may be blocked by a policy option.
  • HAC Host Authorization Code
  • This embodiment of the present invention can provide a unique fourth level of authentication, (in addition to the physical possession of the device, the knowledge of a PIN, and the biological sensing of some user's physical characteristic, e.g., a fingerprint), namely identification and authorization of a particular HCD(s) 601 in order for an authorized user to logon and access the information on the SPED 610 .
  • a user or SSO can log on to the HCD and set the Host Authorization Code (HAC) by creating a long, statistically unlikely to guess or discover (in excess of 100 alphanumeric characters; for highest security, the present embodiment permits up to 255 alphanumeric characters) random or pseudo-random code, which can be generated by blind fingering actions on a keyboard, or by creation of a pseudorandom or random code by the SPED cryptographic processor 613 , or by an application program that runs on the HCD 601 , and whose results can be copied and transferred as the HAC input to the HAC creation program.
  • This input HAC alphanumeric string can be put through a transform (e.g.
  • HAC a one-way hash function
  • This HAC in its transformed form if this has been done, is stored in the HCD 601 registry in an encrypted form that is specific to the computer (HCD) on which the SPED 610 will be authorized to operate. This is accomplished by using a unique property of the HCD, such as an internal serial number of the bios chip, processor chip, or other secure readable or calculable method of identification installed by the manufacturer for unique HCD identification and licensing. Access to this encrypted HAC value in the registry is further protected against extraction or copying, by authorization services SPED authorization service 607 software procedures allowing read only access only to designated administrators. Users that do not belong to this group cannot have any access permissions to the registry key or value.
  • the HAC will also be sent to the SPED 610 to set up this value as the authorization code used for recovering its corresponding share to be used in the K of N derivation of the MKEK.
  • the HAC value in the SPED 610 Before setting the HAC value in the SPED 610 it can also be transformed yet again in order to diversify it so that it is unique to the SPED on which it is set, so that a compromise of a HAC for a particular SPED would not compromise the HAC for all SPEDs used with a common HAC through a common enclave or domain, for example.
  • something unique to the SPED 610 e.g. the SPED serial number
  • combining it with the HAC combining it with the HAC to perform the
  • the particular manner in which the HAC shared secret can be set is dependent upon the initial entry of a pseudo-random alphanumeric string and the binding of the creation of the secret to a specific identity of the HCD 601 .
  • the same HAC can be set on more than one HCD 601 allowing a particular SPED 610 (an SPED initialized with this particular HAC) to be used on multiple HCDs.
  • the SPED 610 in question the SPED initialized with this HAC
  • the HAC when saving the HAC on a particular HCD 601 , the HAC can optionally be assigned a common name associated with that particular HAC value. In this way, multiple HACs can be set for a single HCD 601 , each only valid for the specific SPEDs that have been initialized with this particular named HAC. Using this feature, a given host can support multiple levels of security classifications, each with it own community of interest as defined by a common named HAC.
  • the system that includes a SPED and a HCD can be implemented to permit alternative creation of HACs for remotely located HCDs, on which the proper SPED mass storage and administrative tools software have been loaded.
  • FIG. 1 For example, in an alternate embodiment of the present invention as illustrated in FIG.
  • multiple remotely located host computing devices are connected to a network 22 in a client-server configuration which also comprises a server 21
  • An Originator 11 can create a host authorization code on their specific host computing device 13 and secure portable encryption device 14 , and share this HAC with other Recipients or users 17 in the same Community of Interest without requiring individual user interaction by the Originator's SPED 14 with each host computing device, by communicating the Originator's created host authorization code by a cryptographically secure mutually authenticated client-server channel connection 22 to a system server 21 .
  • Distribution of the Originator created host authorization code to the host computing devices of the designated members 17 of the enclave or domain transmits the shared HAC through a cryptographically-secure, mutually-authenticated client-server channel connection 22 . Since the external host authorization code is transformed by the SPED using a unique identifier from each HCD, the HAC secret can only be correctly reverse transformed by the same HCD and combined with the other shared secrets to reconstitute the MKEK. In this manner, multiple HACs may be created to be distributed to combinations of host computing device according to security policies and the designation of Communities of Interest.
  • a given SPED 610 can only support a single HAC and therefore a single, optionally named classification level.
  • the name of the HAC 601 specified for operating with a given SPED 610 is carried as a public object in the SPED 610 cryptographic processor 613 and is accessed by the HCD middleware 603 after insertion of the SPED, and the matching HAC in the HCD 610 list of HACs will be loaded into the SPED 615 in order to enable a user to log on from the particular authenticated HCD.
  • a further embodiment of a system is that once the HAC has been set, the user continues with the process of initialization of the SPED 610 .
  • the SPED 610 Before use of the secure data processing applications of the SPED 610 for the first time, the SPED 610 must be initialized to generate keys and set the user Personal Identification Number (PIN).
  • PIN Personal Identification Number
  • a minimum length of at least seven alphanumeric characters for the PIN is entered via keyboard input.
  • the SPED device can be configured to require an even longer PIN, and/or imposed various complexity requirements such as the number or upper and lower case characters, numbers, and/or special characters.
  • the system according to the present invention can require PIN entry either from a keyboard input associated with the HCD 601 , or from a secure PIN entry device 623 integrated with a biometric (e.g. fingerprint) scanner 622 as dictated by security policies for user authentication.
  • a biometric e.g. fingerprint
  • the SPED can identify, through the HCD microprocessor 611 operating system software, the presence of a secure PIN entry/biometric verifier device 620 . In one embodiment, in the event that biometric identification fails, then PIN entry is blocked. If biometric authentication is successful, and incorrect PINs are used to try to access the SPED 610 , either as a result of forgetting the PIN or an attack, the time between successive tries can be doubled each time to further increase the difficulty of attack, particularly if the device is left unattended and attached to a host computer. After ten tries, a counter in the SPED cryptographic processor can signal the logic in the SPED to become blocked to prevent a further brute force attack to gain access. The threshold count can send a logic signal to cryptographic processor 613 and encryption keys can be deleted and the PINs completely reset.
  • a SPED can be implemented so that when the PIN entry process is complete and approved, the initialization process continues with the generation of static keys for file encryption, of public/private signature key pairs with private keys stored in cryptographic processor 613 , of key encryption keys for wrapping and protecting file encryption keys, and generation of an AES-256 Master Key Encryption Key for encrypted protection of the entire contents of all keys and critical cryptographic parameters stored within the SPED cryptographic processor 613 .
  • N secret shares associated with that key are created by the cryptographic processor 613 .
  • This embodiment of the secret sharing algorithm incorporated by the invention namely that a minimum set of K out of N shares must be combined to reconstitute the Master Key Encryption Key (or the specific Application Key Encryption Key for the application that is being selected) at log on, and that the HAC, user PIN, and SPED 610 data must be within the K set, makes the SPED 610 information storage contents provably secure against access and cryptographic attacks unless all these codes are available. Without the proper HAC, it is mathematically impossible for anyone to be able to log on to the device and access or decrypt the data contents, even if the user PIN is known.
  • the SPED may be equipped with a non-volatile memory storage device, such as a miniSD or microSD memory card, available in various sizes up to multiple gigabytes in a very compact form-factor.
  • a non-volatile memory storage device such as a miniSD or microSD memory card, available in various sizes up to multiple gigabytes in a very compact form-factor.
  • the memory can be hard-wired and non-removable, but preferably is removable and replaceable via a built-in memory chip socket.
  • the SPED takes the form of the SPYRUS Hydra Privacy Card® Series II (Hydra PCTM) using either the USB interface or the ExpressCardTM interface that is intended to be plugged into a socket within the host computer device housing.
  • This embodiment is of the type of form factor generally used in “flash memory” drive products.
  • An alternate embodiment would include the ExpressCardTM form factor, using an adapter cable with appropriate voltage-reducing circuitry to connect the ExpressCardTM to a USB connector on the host device.
  • Other alternate embodiments of the SPED can be of the form of a handheld multimedia communications device such as a cell phone, smartphone, MP3 player, video player wherein the host computing device can be a local user desktop or laptop computer, or a remote media distribution facility interconnected by wireline or wireless communications over the Internet.
  • the host computing device 610 detects and identifies the presence of the SPED in the manner of plug-and-play protocols as is known in the state of the art.
  • the SPED detects the presence and identity of the associated non-volatile mass memory storage module 614 and any peripheral device 617 that is connected to the secondary EO connection port 616 .
  • Such detection of the presence of an attached peripheral device 617 is typically enabled as a standard embodiment of the operating system software of the SPED processor 611 .
  • the operating system software (or companion software program) also identifies the type of the peripheral device (e.g., digital camera, wireless transceiver, disk memory module). This can be accomplished, for example, by a standard software device driver (hereinafter, “SPED driver”) for peripheral devices 617 of the type that use the SPED secondary EO connection port 616 .
  • SPED driver a standard software device driver
  • the SPED driver is stored in the RAM memory 611 a of the SPED processor 611 . It is to be understood that the examples given above are merely illustrative, not exhaustive, of the ways in which a peripheral device 617 can be used. Many more possibilities exist.
  • the SPED includes cryptographic processing functionality, and also provides connection to peripheral device functionality 617 , the system 600 can be operated so that only the cryptographic processing functionality is used.
  • the SPED device driver and HCD interface, administrative, and middleware software can have been previously installed to the RAM memory of the host computing device via an appropriate interface (such as a CD-ROM drive or network connection), as previously discussed for first use installation and initialization, at the time when the user first initiated interaction between the host computing device and the SPED.
  • an appropriate interface such as a CD-ROM drive or network connection
  • the SPED related software can be stored in non-volatile storage memory 614 of the SPED or, as available, in the SPED 611 a microprocessor memory configuration.
  • the host computing device can automatically provide the user with the opportunity to instruct the host computing device to cause the SPED interface, middleware and device driver software to be transferred from the SPED memory to the host computing device.
  • FIG. 7 is a flow chart of a method 700 , according to an embodiment, for using an SPED.
  • the user can begin using the SPED (in particular, the cryptographic processing functionality of the SPED), as shown by steps 701 , 702 , 703 , 704 , and 705 of the method 700 .
  • the SPED in particular, the cryptographic processing functionality of the SPED
  • steps 701 , 702 , 703 , 704 , and 705 of the method 700 can be enabled by software programs that are cooperatively executed by the host computing device and the SPED.
  • the method 700 shown in FIG. 7 is not the only way to enable the embodiments of use of an SPED that are illustrated in FIG. 7 ; as can be readily appreciated by those skilled in the art, such embodiments can be implemented using any of a variety of other appropriate methods. Further, the use of a SPED can include embodiments not illustrated in FIG. 7 ; likewise, such use may not include some of the embodiments illustrated in FIG. 7 .
  • the method 700 of FIG. 7 is shown merely to aid in the illustration of certain embodiments, and should not be interpreted as restricting the manner in which an SPED, can be used.
  • a SPED can, in general, be operated in one of four modes: 1) a mode in which the cryptographic processing functionality is used on data created by the HCD and is stored in the SPED mass memory module 614 for physical transport or subsequent electronic communication, 2) a mode in which the cryptographic processing functionality is used on data created by the HCD and is looped back to the HCD for storage in an HCD integral or attached memory storage module or for communication to a server or remote storage device, 3) a mode in which the cryptographic processing functionality is used on data communicated by the attached peripheral device 617 and is stored in the SPED mass memory module 614 for physical transport or subsequent electronic communication, and 4) a mode in which the cryptographic processing functionality is used on data communicated by the attached peripheral device 617 and is looped back to the attached peripheral device 617 for storage in the peripheral device integral or attached memory storage module.
  • the SPED Upon receipt of an acceptable user authentication input, the SPED signals the host computing device to present a user interface that enables the user to effect desired control of the SPED, and, in particular, to use the SPED to perform cryptographic operations, as described below.
  • the user interface for enabling a user to operate the SPED can be implemented in any of a variety of well-known ways (e.g., as a graphical user interface) using methods and apparatus that are well known to those skilled in the art.
  • the user interface enables the user to perform any functionality that is provided by the SPED as described in more detail elsewhere herein.
  • a SPED can be operated in any of four modes.
  • the peripheral device driver can enable the user to select one of the four modes, as shown in step 706 of the method 700 .
  • the HCD user interface software and the underlying middleware, drivers, applications, and interface software enables the user to input all desired or required instructions regarding the cryptographic data processing operations to be performed for a particular “transaction” (e.g., encryption of a file from the HCD for storage in the mass memory module 614 , the transmission of encrypted data by an attached peripheral communications device, or a loop back of data encrypted for storage in the HCD) as shown by steps 710 , 711 , and 712 of the method 700 .
  • the user interface software module 602 can enable the user to select on which data cryptographic operations are to be performed, specify the application of particular cryptographic operation to that data, and specify parameters or other information required for a particular cryptographic operation.
  • the cryptographic functionality is embodied as encryption of files and folders from the HCD 601 for storage on the mass memory 614 of the SPED 610
  • the file or folder icon is highlighted and selected on the HCD displayed graphical user interface, and, for example on a Microsoft Windows system, a drop-down menu lists “Encrypt to SPED” as a prompt for clicking on the item to execute the action and implement the data transfer through modules 605 , 606 , and 615 , and to effect cryptographic processing actions via the appropriate cryptographic resources available from the appropriate SPED cryptographic processing modules 611 , 612 , and 613 .
  • the HCD software 603 and 606 will prompt the user to select the destination SPED.
  • the file or folder name stays unchanged and a new file extension is added to indicate that the file is encrypted.
  • step 708 or 711 or 714 or 717 of the method 700 the particular cryptographic processing transaction is executed, as shown by step 708 or 711 or 714 or 717 of the method 700 .
  • the data is transferred to the appropriate destination via step 709 or 712 or 715 or 718 .
  • step 719 of the method 700 use of the SPED ends, as shown by step 719 of the method 700 .
  • the cryptographic processing functionality of a SPED can be configured to perform any cryptographic operation, as well as other, related mathematical operations.
  • a configuration of the cryptographic processing functionality that enables a particular cryptographic or mathematical operation can be produced, for example, by using appropriate existing cryptographic software, application-specific hardware, or combination of the two, as known by those skilled in the art of producing cryptographic devices.
  • the SPED can be configured such that the functionality of the Crypto Processor ( 613 ) serves in a manner similar to a conventional smart card or USB token for carrying out a wide variety of cryptographic and PKI functions, including both legacy (RSA, DSA, triple-DES, SHA-1) and advanced (EC Diffie-Hellman, ECMQV, ECDSA, AES, and SHA-2) algorithms in combination with HCD application and/or operating system software.
  • legacy RSA, DSA, triple-DES, SHA-1
  • EC Diffie-Hellman, ECMQV, ECDSA, AES, and SHA-2 EC Diffie-Hellman, ECMQV, ECDSA, AES, and SHA-2
  • processing examples include hardware-based public key operations earned out within the SPED, with symmetric key and hashing functions earned out in software on the HCD, for applications such as smart card logon, IPSEC link encryption, SSL/TLS encryption and mutual authentication to web servers, secure and authenticated e-mail (S/MIME), pre-boot authentication for Full Disk Encryption solutions, WiFi link encryption, and other similar cryptographic protocols and purposes known to those skilled in the art.
  • applications such as smart card logon, IPSEC link encryption, SSL/TLS encryption and mutual authentication to web servers, secure and authenticated e-mail (S/MIME), pre-boot authentication for Full Disk Encryption solutions, WiFi link encryption, and other similar cryptographic protocols and purposes known to those skilled in the art.
  • a SPED can implement one or more cryptographic key exchange operations. Any key exchange operation can be implemented, such as, for example, the ECDH, the ECMQV, the RSA, and the X9.42 (ANSI Banking Standard) key exchange algorithms.
  • a SPED can also implement one or more hash operations. Any hash operation can be implemented, such as, for example, the SHA-224/256/384/512, SHA-1, and the Message Digest 5 (MD5) algorithms.
  • MD5 Message Digest 5
  • a SPED can also implement one or more digital signature operations. Any digital signature operation can be implemented, such as, for example, the ECDSA Digital Signature Algorithm, and the RSA Signature (1024, 2048) algorithms.
  • a SPED can also implement one or more key wrapping operations for both symmetric and asymmetric keys.
  • a key wrapping operation can ensure that plaintext keys are not accessible external to the portable device. Any key wrapping operation can be implemented.
  • a SPED can also implement one or more symmetric encryption operations.
  • Any symmetric encryption operation can be implemented, such as, for example, the AES-128/192/256 with ECB, CBC, CTR, and key wrap modes, and the DES (including 3DES, EDE3, CBC and ECB).
  • a SPED can also implement one or more asymmetric (public key) encryption operations. While asymmetric encryption operations underlie the key exchange operations described above, asymmetric key operations can also be used independently in a SPED for bulk encryption. Any asymmetric encryption operation can be implemented, such as, for example, the RSA, Diffie-Hellman, and Elliptic Curve Diffie-Hellman algorithms, and various variants thereof.
  • a SPED can also implement one or more exponentiation operations, which are required in many cryptographic operations. Any exponentiation operation can be implemented. Since exponentiation requires a significant amount of processing time relative to other mathematical operations, it can be desirable to implement an exponentiation operation in dedicated hardware.
  • the cryptographic processing functionality of the portable device includes a full exponentiator implemented in hardware.
  • a SPED can also implement one or more random number generations, which are required in many cryptographic operations. Since high quality random number generation is required for robust, strong key generation and other critical cryptographic functions, and requires a significant amount of processing time relative to other mathematical operations, it is desirable to implement random number generation with approved algorithms in dedicated hardware.
  • Cryptographic processing functionality of the portable device includes a full random number generator implemented in hardware.
  • the files or records to be encrypted, digitally signed, and/or sealed may include a multiplicity of file header information sufficient to allow multiple Recipients (optionally including the Originator) to be able to decrypt and verify the information that has been so protected, whether that data has been recorded on the storage medium contained within the Secure Portable Encryption device itself, on an integral or ancillary encryption device connected to the host computing device, or some other encryption device that is logically accessible to the Host Computer Device or the Secure Portable Encryption device.
  • a means of designating a number (zero or more) of Mandatory Recovery Agents or Recipients of the secured information that cannot be bypassed by the normal originator may be provided on behalf of the institution under the control of the System Administrator or System Security Officer on a per HCD basis; together with some other number (zero or more) Optional Recipients specified by the originator, that are required or allowed to be able to decrypt the encrypted information.
  • This set of Mandatory and Optional Recipients is not necessarily limited to a single enclave as defined by a single common named or default Host Authorization Code (HAC), but instead can confine communications between and among a fixed set of users operating in different enclaves, while preventing users from accessing or decrypting the information outside of their own authorized enclave, even if they possess the secure portable encryption device and know the user PIN.
  • HAC Host Authorization Code
  • This invention dynamically defines and configures the authorized population and tiers of users, portable encryption devices, and host computing devices that are allowed to communicate through the flexibility of support of multiple Host Authorization Codes by each host-computing device.
  • the credential(s) of the Recipient(s) may be provided to the Secure Portable Encryption device (SPED) in the form of a raw public key, for example suitable for use in the EC Diffie-Hellman or ECMQV key establishment scheme, through some trusted out of band process.
  • SPED Secure Portable Encryption device
  • the Recipient's credentials may be embedded in a conventional X.509 digital certificate, which has been digitally signed by a trusted Certification Authority or chain of Certification authorities acceptable to the Originator.
  • the user's credentials in the form of one or more X.509 certificates including a certificate and certificate chain that has been signed using the legacy public key algorithms (e.g., RSA or DSA) and legacy hash functions (MD5 or SHA-1), together with the user's SPED ECC encryption and digital signature public keys, may be bound together in either a proprietary format or an X.509 attribute certificate, and signed using the user's/SPED high-strength ECC digital signature key.
  • legacy public key algorithms e.g., RSA or DSA
  • legacy hash functions MD5 or SHA-1
  • the various Mandatory or Optional Recipients may be differentiated and selected by the guaranteed longevity of the secrecy of the private keys held by those Recipients, e.g., an Historical Recovery Agent.
  • an Historical Recovery Agent e.g., the private keys associated with such a Historical Recovery Agent would be split into independent shares using a secret-sharing algorithm, and those shares entrusted to a large number of universities, public libraries, museums, government archives, religious organizations, and other stable and long-lived institutions, such that many but not necessarily all of those institutions working in concert, e.g., perhaps 70 out of 100, would be able to reconstitute the private key.
  • the public key associated with the Historical Recovery Agent could be included within an X.509 or other form of public key certificate, with the expiry period being plainly indicated in the certificate itself. Those institutions could then gather in a conclave perhaps once per decade, reconstitute the private key that was destined to expire on that date, and publish it to the world. As a result, documents that had been securely encrypted for the last 10, 20, 50, or even 100 years would instantly become readily accessible to future generations.
  • Another embodiment of the means for securely protecting decryption is to utilize a Network Access Code (a synonymous term for a Network Authorization Code known to those skilled in the art, either term being represented by the acronym “NAC”) as part of a shrouding operation on file encryption keys.
  • a Network Access Code a synonymous term for a Network Authorization Code known to those skilled in the art, either term being represented by the acronym “NAC”
  • means are provided to optionally restrict the decryption of encrypted information flowing to or from (a) the HCD via the SPED, and (b) one or more other (remote) authorized user(s); unless both the Originator of the encrypted communication and all of the Recipients of said encrypted communication share a common pre-shared NAC or key, which is associated with the creation of a named Community of Interest of authorized members in such a way that if both the Originator and a particular Recipient do not both know the Network Authorization Code the Recipient will not be able to decrypt the information, even if the Originator has knowledge of and trusts the Recipient's public key.
  • This Network Authorization Code may be stored on the user's SPED, or alternatively on the HCD or some external device or server, or even split between and among the SPED, the HCD, and some user-provided information using a secret-sharing algorithm (for example, as described above), and may be used as part of an overall data containment enforcement mechanism to ensure that information is not communicated, either physically or logically (e.g., via a communications network) to unauthorized users, even on a cross-domain basis.
  • the NAC can be used to enforce data containment to within a group or domain of authorized users, by requiring the Originator and all of the various Recipients know or share a common NAC for that domain.
  • Means are further provided to securely generate, distribute, store and access, use, and recover the NAC throughout the Community of Interest.
  • Various means including encrypting the NAC in the public key of the authorized user's SPED device, can be used to distribute the NAC securely, such that it can be stored on the SPED device itself, on the host processor that is used, or on some external device such as a server, so that it can be retrieved and used.
  • similar means can be used to distribute the named NAC for a given Community of Interest to one or more Community-Of-Interest Recovery Agents, so that it can be reconstituted in the event of the loss or destruction of the SPED or even the death or disability of the user.
  • the management of possession of this NAC could take a multiplicity of forms, ranging from a simple out-of band communication of the password or passphrase used to generate the NAC; up to a complex, world-wide network of Community of Interest Registrars and Recovery Agents responsible for authenticating the identities, clearance levels, and bona rides with respect to membership in the Community of Interest.
  • the NAC is exclusive-ORed (XORed) or otherwise combined (e.g., by the use of encryption or some other invertible transform) with the File Encryption Key used to encrypt the file or message, to create what may be called a Shrouded File Encryption Key (SFEK).
  • SFEK Shrouded File Encryption Key
  • This SFEK can then be encrypted in the normal manner with a Key Encrypting Key that is derived from the EC Diffie-Hellman or other key exchange mechanism through a standard key derivation process as described in the literature.
  • this process makes it impossible to decrypt the File Encryption Key, and therefore the file itself, unless the EC Diffie-Hellman key exchange operation takes place successfully, and the NAC is known.
  • FIG. 8 is a flow diagram that illustrates one embodiment of how key management is performed within the SPED 811 when a NAC is used. For every file that is to be encrypted, a new ephemeral public/private ECC key is generated for the Originator 800 . The public ephemeral key that is generated at the same time (not shown) is saved for inclusion in the File Header 817 of the Encrypted File 813 . The SPED receives the Recipient's static public key 801 from an external source, which may be an X.509 public key certificate or similar construct 804 .
  • an external source which may be an X.509 public key certificate or similar construct 804 .
  • the Elliptic Curve Diffie-Hellman operation 802 is carried out in the conventional manner, by multiplying the Originator's private ephemeral key times the Recipient's static public key in the ECC field.
  • the output of that function is a shared secret, conventionally called Z, that is passed to a Key Derivation Function (KDF) 803 such as the Concatenation Key Derivation Function defined within SP 800-56A.
  • KDF Key Derivation Function
  • Other supplementary public and/or private information 804 may be passed in to the KDF as well, in order to bind the key that is generated to the identity of the parties.
  • KDF Key Derivation Function
  • Other supplementary public and/or private information 804 may be passed in to the KDF as well, in order to bind the key that is generated to the identity of the parties.
  • the output of the KDF is a Key Encrypting Key (KEK) 804 .
  • KEK Key Encrypting Key
  • a random generated symmetric File Encryption Key (FEK) 806 is generated for the file, along with a randomly generated Initialization Vector (IV) 810 .
  • the NAC 805 is retrieved from secure storage within the SPED, and both the NAC and the FEK are passed to the shrouding operation 807 , which may simply exclusive-OR the two values together, or alternatively might encrypt the FEK using the NAC as a key.
  • the output of that operation is a Shrouded Key Encryption Key, which is input as data to the AES Key Wrap operation 808 and wrapped with the Key Encryption Key (KEK) 804 that was previously computed by the KDF.
  • KEK Key Encryption Key
  • the output of the AES Key Wrap operation is a Wrapped Key Blob 809 , which is then written to the File Header 817 of the encrypted file 813 .
  • the Originator's ephemeral public key (not shown) that was generated at the same time as, and corresponds to, the Originator's ephemeral private key 800 , as well as the Initialization Vector (IV) 810 .
  • the symmetric File Encryption Key 806 together with the Initialization Vector ( 810 ) is then used to encrypt the plaintext data 816 using the conventional Cipher Block Chaining mode of operation, or alternatively a mode such as Galois Counter Mode, to create the final Encrypted File 813 .
  • NAC Network Authorization Code
  • means are provided for surviving the loss, theft, destruction, or eventual failure or obsolescence of a SPED by recovering, at a trusted third-party File Recovery Agent, the file encryption keys used to encrypt a multiplicity of files and then securely re-encrypting the individual file encryption keys associated with the data (but not the data itself) using a new encryption key or set of keys installed in a newer or replacement SPED, all the while guaranteeing that the Recovery Agent cannot access or decrypt the contents of the file without knowing the NAC that was used when the file was originally encrypted.
  • means are provided for surviving the loss, theft, destruction, or eventual failure or obsolescence of a SPED by recovering the Network Access Code or NAC, though the use of a Community-of-Interest Recovery Agent (CRA), that would receive and store the encrypted NAC used within a Community of Interest, and could upon an authenticated demand, export that NAC to an authorized user's SPED device, but without ever having access to the private key or keys of any of the authorized users SPED devices, and hence without the ability to decrypt the data itself.
  • CRA Community-of-Interest Recovery Agent
  • the NAC could be entered by the Originator during the encryption process (and by the Recipient(s) during any decryption), in the form of a passphrase that would be entered via the keyboard attached to the HCD, with the passphrase being passed to the SPED by the host software and hashed within the SPED to form the NAC before it is used.
  • the NAC can be given a unique name, and centrally managed by a Community of Interest manager or authority. For example, a community of interest of automobile parts manufacturers might be established by Chrysler, so that those vendors could communicate with Chrysler, but Ford would not be able to originate or decrypt messages to that COI. Likewise, Ford could set up their own COI, and Chrysler would not be able to participate, but those vendors that sold to both Chrysler and Ford would be able to communicate with both, but separately.
  • the NAC would be randomly generated using a random number generator in an SPED, and then encrypted in the ECC public key of the authorized user, using a conventional EC Diffie-Hellman and Key Derivation Function to encrypt the wrapped NAC.
  • the named wrapped NAC could be sent to an authorized user in any convenient manner, including e-mail, FTP, etc.
  • the named NAC could be stored on the SPED token itself or it could be stored on the HCD for retrieval as needed.
  • the NAC would be decrypted by the SPED prior to use.
  • An additional embodiment recognizes that in order to recover a file or other information at some distant point in time, it will be necessary to recover the NAC as well as being able to decrypt the Shrouded File Encryption Key. Because databases of keys, NACs and other such information might become disassociated from the message or otherwise rendered inaccessible, it is highly desirable that the encrypted NAC information be earned in the encrypted file or message itself. For that reason, preferably the NAC will be encrypted in the public key of the authorized user, and in the public key or keys of one or more Community of Interest Recovery Agents (CRA). In this embodiment, the NAC would be encrypted only once per user, but the encrypted form would include the wrapped version of the NAC, encrypted one or more times for the various CRAs.
  • CRA Community of Interest Recovery Agents
  • the wrapped value of the named, encrypted NAC would never change from the time it is created, it can simply be included in every message as a opaque blob.
  • the Originator of the message or file would be able to decrypt the NAC, if necessary, using the private key of the SPED, and any authorized CRA would be able to decrypt that NAC, but the various Recipients would not be able to decrypt it, because it was not encrypted using their keys.
  • the Recipient In order to decrypt the message, the Recipient would have to have received their own copy of the NAC, encrypted in their own public key, in order to decrypt and apply the NAC and subsequently decrypt the message.
  • means are provided through which an independent Guard Processor computer or mechanism can verify that the entire contents of any encrypted file or other form of data were properly encrypted and have not been tampered with or accidentally modified since that time.
  • the means makes use of a secure hash function that is computed by the SPED contemporaneously or simultaneously with the encryption operation, with the resulting hash function being digitally signed by the Originator's digital signature key and the signature being embedded in the file metadata or trailer along with the public signature key to be used for verification.
  • the validity of the Originator's public key can be established through a trusted out-of-band mechanism, e.g., an X.509 certificate that is signed by a trusted Certification Authority, or one or more public key or authorized Originators that are securely installed in the Guard Processor under the System Security officer's control.
  • a trusted out-of-band mechanism e.g., an X.509 certificate that is signed by a trusted Certification Authority, or one or more public key or authorized Originators that are securely installed in the Guard Processor under the System Security officer's control.
  • the Recipient may not have received out-of-band confirmation of the Originator's public signature key, which might allow an attacker to substitute a bogus public key in the file metadata (trailer).
  • the SPED includes the Originator's public signature key (as obtained from the file metadata) within the Key Derivation Function that is used by both the Originator and a Recipient to derive the Key Encrypting Key used to encrypt the File Encryption Key. If the Originator's public key were modified in the file, the Recipient would not be able to rederive the key necessary to decrypt the file, and the process would fail.
  • the Guard Processor function may be implemented in software on a user's HCD, and used to block or filter all information that has not been properly encrypted from being written to (or alternately read from) another mass encryption device or other media, unless it has been properly encrypted, in order to prevent the leakage of sensitive plaintext information.
  • FEC Forward Error Correction
  • various forms of Forward Error Correction may be included within the encoded structure of the encrypted file itself, logically after the file has been encrypted and hashed as part of the digital sealing mechanism.
  • FEC may be applied while the file is being encrypted and the ciphertext hashed, all in a single pass.
  • any existing errors will be corrected prior to hashing the encrypted file and perform the decryption operation.
  • various forms of Forward Error Correction can be applied, including but not limited to simple Reed-Solomon (255,233) code, wherein 233 bytes of data plus 32 bytes of parity information are encoded into a 255 byte block.
  • Such a code can correct up to 16 short bursts of error.
  • More complex coding techniques such as Cross-Interleaved Reed-Solomon Coding (CIRC) technique used in Compact Disks can completely correct error bursts of up to 4000 bits. The use of such techniques can enable the complete recovery of encrypted messages that might otherwise be rendered completely unintelligible due to as little as a single bit error.
  • CIRC Cross-Interleaved Reed-Solomon Coding
  • the SPED can be connected to an optional Enhanced Authentication Device (“EAD”), which contains a biometric fingerprint scanner that compares the fingerprint input data to fingerprint templates previously registered and stored within the SPED.
  • EAD Enhanced Authentication Device
  • This apparatus provides an additional authentication factor of “Who you are” to positively identify the user as the legitimate unique user, or one of a set of authorized users who has previously registered their fingerprints on the SPED to strongly and securely bind their identity as an authorized user to access the operations on the SPED.
  • the optional EAD takes the form of a covering sleeve and includes a secure PIN entry mechanism to allow the PIN or password to be entered directly into the SPED without the need to communicate the PIN over an external or unprotected communications channel.
  • the proximity of the authorized user to the SPED may be confirmed by means of an RFID tag, Bluetooth device, or other limited near-field or wireless communications mechanism that is normally worn on or attached to the user's person, and may be “paired” to either the SPED or the EAD, so that if the user leaves the immediate area of the SPED that condition will be sensed, and the user required to log on again before taking further actions with the SPED.
  • RFID tag RFID tag
  • Bluetooth device or other limited near-field or wireless communications mechanism that is normally worn on or attached to the user's person
  • Other sensors and more exotic applications could likewise be supported, including live finger determination, blood-alcohol content, two-man rule conditions, etc.
  • the normal mode of operation would be for the SPED to be used within limited geographical locus, e.g., within a corporate campus, and use outside of that locus would be prevented.
  • this geographical locus can be managed by having the EAD determine the current geographical position, (e.g., from a GPS or Loran system, or by triangulation form cell phone towers or similar means), and then apply a coordinate transformation to effectively round both the X and Y coordinates to define a more limited precision locus.
  • This “fuzzy” or limited-precision locus can then be used as one of the authentication and authorization parameters that are entered into the secret-sharing authentication algorithm at the time the SPED is initialized and the keys are generated, just as the user PIN, Host Authorization Code, an/or other authorization parameters are entered.
  • the extension of the authentication and authorization parameters from what is effectively a precise, one-dimensional Host Authorization Code to a fuzzy two-dimensional geographic position locus can be extended to three or more dimensions, including altitude, time or day, or other multivariate coordinates.
  • many pattern matching algorithms used in biometric applications can be viewed as a multi-dimensional variation around a known point, which is determined by the biometric template or indicia.
  • the template would be entered into the secret-sharing authentication and authorization algorithm, and the allowable degree of deviation from that template would be implemented through the coordinate transformation and truncation or rounding algorithm, so that it would not be necessary to store the template itself for comparison where it could possibly be compromised.
  • the SPED is constructed with a multiplicity of logical cryptographic or application partitions, in order to permit sharing a single SPED among or between multiple users, as in a branch office, or engineering design or finance group, where each user can have access to their own unique private keys.
  • each user can have access to their own unique private keys.
  • multiple users of the same device can be authorized, each with their own PIN or password and optional biometric identifier, but the various users can all share access to a common set of decryption keys, for purposes of survivability. In that scenario, each user might or might not have unique digital signature keys.
  • the SPED can be constructed with a multiplicity of logical cryptographic or application partitions, so that certain less sensitive applications can be performed without requiring the Host Authorization Code or other authorization parameters to be stored externally, while still requiring the HAC for the more sensitive applications.
  • One such application would be the use of the SPED for pre-boot authentication of a Full Disk Encryption software or hardware application, where there is no secure location in which to store a HAC until the operating system has completed the boot process, and hence it would be desirable to use independent HACs for maximum security.
  • Another such application would be the use of the SPED to access Multiple Independent Security Levels when dealing with a classified environment.
  • HAC Home Access Control
  • biometrics might authorize access to a host computer at the Unclassified level, another set at the SECRET level, and yet another set at the TOP SECRET level. If a particular user or SPED is not authorized to access the higher level security classifications, the HAC for that classified enclave security level would not be loaded onto the SPED by the Security Officer.
  • a multiplicity of independent SPEDs may be aggregated into a single physical device containing multiple SPED devices, all capable of functioning independently at different security levels, and connected to the HCD by a multi-pin plug and socket arrangement containing e.g., as many as 16 different connecting pins, as may be required to support the I/O requirements.
  • Each SPED could then be dedicated to distinct security levels, e.g., Unclassified, CONFIDENTIAL, SECRET, and TOP SECRET, providing complete electrical as well as application and cryptographic separation between levels.
  • the SPED may take the form of a digital media recorder/receiver or an “iPod” type device, which includes a large capacity micro disc hard drive or internal mass memory chip, and connects to the host computing device through a miniUSB or adapter cable connection, or wireless connection, depending upon the native interface of this SPED.
  • a touch screen display may enable a keyboard to be presented to the user to provide a means for entering a PIN number directly into the SPED without transporting the PIN from an unprotected external device and communications channel.
  • a SPED apparatus is constructed and enabled to also perform one or more cryptographic operations on data that has been transmitted to the SPED by a remote wireless device by inclusion of a wireless transceiver, or input to the SPED by a person through a keyboard, or input to the SPED by another peripheral device (e.g., digital camera, disk storage module) through an additional secondary physical connector and communications port.
  • a remote wireless device by inclusion of a wireless transceiver, or input to the SPED by a person through a keyboard, or input to the SPED by another peripheral device (e.g., digital camera, disk storage module) through an additional secondary physical connector and communications port.
  • the host computing device may be a programmable product such as laptop, desktop or UltraMobile PCs, a PDA cell phone, a digital audio or video recorder, a photographic camera or recorder, with an embedded microprocessor that supports applications software, peripheral device interfaces, and graphical user interfaces, and operates on digital data in any format (e.g., encoded alphanumeric, video, audio, photographic).
  • a programmable product such as laptop, desktop or UltraMobile PCs, a PDA cell phone, a digital audio or video recorder, a photographic camera or recorder, with an embedded microprocessor that supports applications software, peripheral device interfaces, and graphical user interfaces, and operates on digital data in any format (e.g., encoded alphanumeric, video, audio, photographic).
  • the SPED 610 and an associated peripheral device driver may be implemented so that it is possible to use the functionality of the SPED, even without accessing any cryptographic processing functions of the SPED.
  • Using the SPED in this way can be useful, for example, when the targeted functionality (referring to FIG. 6 ) is embodied as the secure PIN entry/biometric authentication device 620 , previously described, that is used to perform user authentication.
  • the targeted functionality referring to FIG. 6
  • device 620 is to be used as the mechanism to enter the user PIN in FIG. 7 step 704
  • operation in this mode may be necessary (depending on the capabilities of the biometric device) to enable such use of the biometric device.
  • the biometric authentication device is defined herein as any device that is adapted to receive input data regarding a physical characteristic of a person based upon a physical interaction of the person with the device.
  • Biometric devices that can be used in a peripheral device can include, for example, a fingerprint-scanning device, a retinal scanning device, or a face print scanning device.
  • a biometric device includes a sensor for sensing the physical characteristic, and an analog-to-digital converter to transform the analog data representing the sensed characteristic into digital data.
  • a fingerprint-scanning device includes a sensor upon which a person can place or swipe a finger, the sensor sensing the fingerprint of the finger, the content of the sensed fingerprint being converted into digital data by the device.
  • a retinal scanning device includes a sensor that can be placed proximate to a person's eye, the sensor sensing characteristics of the eye such as blood vessel pattern or iris pattern, the device translating the content of the sensed characteristics into digital data.
  • biometric devices in general, as well as those identified particularly above, is well understood by those skilled in that art, so that, together with an understanding of the required communication capability between the biometric sensor and the control processor 620 , a biometric device for use with the invention can be easily operated.
  • Fingerprint scanning devices and retinal and face print scanning devices that can readily be modified for use with the invention, i.e., to communicate with the control processor 620 , are known to those skilled in that art.
  • the secure PIN/biometric device 620 contains a human input device 623 for scrolling through alphanumeric characters that are sequentially displayed on display screen 624 . As each desired character appears on the display screen 624 , a selection is made and the character is locked. After the correct sequence of characters is entered, they can be entered as the PIN, in one embodiment, by scrolling the thumbwheel to an “enter” position and pressing inward.
  • the secure PIN entry is transferred to the SPED cryptographic processing configuration modules 611 , 612 , and 613 via control processor 621 and EO modules 625 and 616 to determine authentication approval by matching the stored PIN data.
  • the biometric scanner 622 may be used to scan the user's biometric fingerprint data into the SPED control processor 621 according to the particular instructions and settings of the scanner parameters. If a correct match is made after comparing the biometric data to an appropriate library of biometric data representing a predetermined group of people (e.g., authorized users) stored within the processor 621 , the resultant user authentication approval is sent from the control processor 621 via EO modules 625 and 616 to the SPED microprocessor 611 . (Of course, in this case, user authentication is used as part of the step 714 ). Again, eventually, use of the SPED device ends (step 719 ).
  • biometric scanner 622 may be used to scan the user's biometric fingerprint data into the SPED control processor 621 according to the particular instructions and settings of the scanner parameters. If a correct match is made after comparing the biometric data to an appropriate library of biometric data representing a predetermined group of people (e.g., authorized users) stored within the processor 621 , the resultant user authentication approval is sent
  • FIG. 9 A further system embodiment 922 is illustrated in FIG. 9 .
  • the HCD 915 is similar to that presented in FIG. 5 and can take the form of some portable form factor physical configuration for a PC, a PDA phone, a smartphone or other such similar devices.
  • the HCD 915 is comprised of a microprocessor 912 , an internal memory 913 , a computer bus 911 for interconnection of the internal components of the HCD 915 , a data input mechanism for user input illustrated herein as a keyboard 914 which is connected to the HCD 915 through a USB input/output module and connector 910 .
  • a wireless connection can be used to interconnect a data input device 914 to the HCD 915 .
  • FIG. 9 the HCD 915 is similar to that presented in FIG. 5 and can take the form of some portable form factor physical configuration for a PC, a PDA phone, a smartphone or other such similar devices.
  • the HCD 915 is comprised of a microprocessor 912 , an internal memory
  • the host computing device executes the software modules 605 , 606 , 601 , 602 , and 607 necessary to interface with the secure portable encryption device and the secure portable encryption device mass memory.
  • the HCD 915 includes a wireless input/output module and connector 909 for communications to other devices using WLAN IEEE 802.11, Bluetooth, or such other wireless communications methods as may be adopted for industry use by handheld digital computer and communicating devices and host computing devices. Wireless communications is enabled by HCD 915 internal or external antenna 908 .
  • the secure portable encryption device 900 may be implemented in a form of digital data media recorder/receiver 900 containing an integrated or removable mass memory disc or mass memory chip module 901 .
  • This secure portable encryption device 900 also contains a control microprocessor 903 , internal RAM memory 904 , an internal communications bus 902 , and input/output module and connector 906 which includes a wireless capability and is connected to internal or external antenna 907 through which communications is effected.
  • Wireless communications can utilize a method such as Bluetooth, WLAN IEEE 802.11 protocols, or other methods adopted by industry providers.
  • Wireless communications can be implemented using one of the industry security methods (e.g., WAP2 IEEE 802.11i, Bluetooth mutual authentication method for encryption key generation) for establishing a mutually authenticated ephemeral session encryption key between the HCD 915 and the SPED 900 in order to secure communications of critical security parameters that are exchanged between the HCD 915 and the SPED 900 .
  • industry security methods e.g., WAP2 IEEE 802.11i, Bluetooth mutual authentication method for encryption key generation
  • This configuration 922 may execute all security operations as have been previously described for occurring within the secure portable encryption device 900 for protection of the SPED memory 901 data by means of software stored in a partition 905 of the internal memory, or alternatively and not illustrated, in a separate EEROM memory connected to computer bus 902 .
  • the control microprocessor 903 processes all memory applications, initialization applications, generates the ephemeral polynomial curve from which the “N” shared secrets and Master Key Encryption Key (MKEK) are created, and performs the security processing operations necessary to cryptographically associate each shared secret with an external secret, (e.g., the user PIN, the security officer PIN, the unique identifier for the HCD, the identification of the specific secure portable security device), and all other cryptographic algorithms and related memory storage applications as are required and store such values in nonvolatile permanent memory of the SPED.
  • MKEK Master Key Encryption Key
  • the system secret sharing means implemented by the SPED 900 control microprocessor 903 and security processing programs stored in memory 905 do not require static storage of the external secrets and the MKEK and thus provides the advantage of avoiding these vulnerabilities which are subject to brute force and other attacks.
  • Installation and initialization software modules (not illustrated) as previously discussed may also be stored within the SPED 900 to be directly downloaded to a HCD 915 without the necessity of using a separate digital media, e.g., CD-ROM.
  • user authentication can be implemented by PIN input through the data entry device 914 for the HCD 915 , or, for additional levels of secure authentication, through a separate biometric and secure PIN entry device 916 , configured in this embodiment in a USB flash memory portable form factor. Other form factors may also be implemented.
  • the biometric authentication device 916 is connected to the host computing device through a USB connection 921 which mates with the USB input/output and connector module 910 on the HCD 915 .
  • the biometric authentication device 916 may be comprised of a biometric sensor depicted in FIG. 9 as a fingerprint sensor 917 , a scrolling thumbwheel 918 for selection and input of the alphanumeric characters to compose the PIN, a display 920 to provide status to the user, and an internal control microprocessor 919 for execution of all operations.

Abstract

A device and method for file encryption and decryption with a cryptographic processor reconstituting a file encryption key from a version of the key which has been shrouded with a network authorization code. This meets a need for restricted communication and data containment by limiting access to a pre-defined community-of-interest, so that no one outside of that community can decrypt encrypted content.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application claims the benefit of U.S. Provisional Patent Application No. 60/886,087 titled “Modular Portable Storage Device And System With Configurable Security Functionality” filed Jan. 22, 2007, and is a division of U.S. non-provisional patent application Ser. No. 13/650,459 titled “Portable Data Encryption Device With Configurable Security Functionality And Method For File Encryption, filed Oct. 12, 2012, currently pending, which is a continuation of U.S. non-provisional patent application Ser. No. 12/018,094 titled “Portable Data Encryption Device With Configurable Security Functionality And Method For File Encryption, filed Jan. 22, 2008, now abandoned, the contents of all of which are incorporated by reference in this disclosure.
  • BACKGROUND OF THE INVENTION
  • The creation of proprietary digital information is arguably the most valuable intellectual asset developed, shared, and traded among individuals, businesses, institutions, and countries today. This information is mostly defined in electronic digital formats, e.g., alphanumeric, audio, video, photographic, scanned image, etc. The exposed storage and transport of this proprietary information, particularly for the purposes of sharing among separate collaboration groups, has significantly increased the risk of interception and theft by criminal elements, competitors, amateur thieves, computer hackers, terrorists, or political or industrial spies.
  • Simultaneously, there is an increased need for mobility of such data by physical or logical transport between home and office, or from office to office(s) among designated recipients. The dramatic increase in the velocity of business transactions and the fusion of business, home, and travel environments has accelerated sharing of this proprietary commercial, government, and military digital information. To facilitate sharing and mobility, large amounts of valuable information may be stored on a variety of portable storage devices (e.g., memory cards, memory sticks, flash drives, optical and hard disc magnetic media) and moved among home and office PCs, portable laptops, PDAs and cell phones, and data and video players and recorders. The physical mobility of these storage devices makes them vulnerable to theft, capture, loss, and possible misuse. Indeed, the storage capacity of such portable storage devices is now approaching a terabyte, sufficient to capture an entire computer operating environment and associated data. This would permit copying a targeted computer on the storage media and replicating the entire data environment on an unauthorized “virgin” computer or host device.
  • Another trend in data mobility is to upload and download data on demand over a network, so that the most recent version of the data is always accessible and can be shared only with authorized users. This facilitates the use of “thin client” software and minimizes the cost of storing replicated versions of the data, facilitates the implementation of a common backup and long-term storage retention and/or purging plan, and may provide enhanced visibility and auditing as to who accessed the data and the time of access, as may be required for regulatory compliance. However, thin client software greatly increases the vulnerability of such data to hackers who are able to penetrate the firewalls and other mechanisms, unless the data is encrypted on the storage medium in such a way that only authorized users could make sense of it, even if an unauthorized user were able to access the encrypted files.
  • There is a balance among legal, economic, national security, and pragmatic motivations to develop robust security implementations and policies to protect the storage of proprietary digital information, based on the value of the information, the consequences of its exposure or theft, and the identification and trust associated with each of the targeted recipients. In order to provide such varying degrees of protection for portable storage devices, system methods and application functionality must be developed and easily integrated into the operating procedures of the relevant institutions. Different policies defining degrees of protection are required to economically accommodate and adapt to a wide range of targeted recipient audiences for this data.
  • Currently and predominantly, for portable storage devices, passwords and software solutions are used for such purposes as encryption of information and to provide the authentication functions to access and manipulate private intellectual property. The sophistication of literally millions of mathematicians, computer engineers and scientists, many of whom can be hostile to the protection of digital intellectual property for economic, political, or frivolous purposes, represents a great threat to the efficacy of simple implementations of password security and software encryption systems currently implemented on such portable encryption devices. Furthermore, the difficulty and, in some cases, the inability to change security policies for access to such data forms yet another barrier to the commercial and institutional interests of the owners of the intellectual property in controlled and directed sharing of such information, and of the user's ability to retrieve, search, and store such data in their daily activities.
  • In contrast, some users have adopted the use of hardware-based encryption solutions in order to prevent these problems, only to discover a few years later that their data was irretrievable because their cryptographic token was lost, stolen, or malfunctioned and they had no backup or recovery agent capability, or that interesting or even vital historical records could not be read because no information exists as to what keys were used to encrypt the documents, or what tokens or PINs were used. It is easy to imagine that if these issues are a significant problem today, then the problem of encrypting data for personal privacy for 40 or 50 years, or even the life of the individual, will become overwhelming.
  • What is needed are highly robust and proven security techniques incorporated into new system methods and into new commercially available portable storage hardware apparatus to implement configurable security policies for accessing information through rigorous authentication means, to secure the information with certified levels of accepted cryptographic technology, and to rigorously control the environment within which the information is shared.
  • What is needed is a secure portable storage apparatus and method of encrypting and sealing (via a combination of secure hash and digital signature technologies) digital information files and storing them in the device's integral or removable memory, or alternatively on the host device's memory or other ancillary memory storage devices, while operating under cryptographically protected security policies for transport and authorized access to such digital information.
  • It is essential that the portable encryption device provide and make use of a highly secure logon mechanism, to ensure that a user is not allowed to or even be capable of operating the device in order to encrypt, decrypt, sign, or verify the data, or perform various other sensitive operations unless and until that user has been specifically authenticated and authorized in accordance with the organization's security policies and procedures. To this end, it would be very desirable for the device to support the use of a secure PIN entry mechanism, as well as supporting an optional biometric identification mechanism, and various other optional enhanced authentication devices, functions, and methods.
  • Because the secure portable encryption device may be used in a high threat and high-risk environment, there is the possibility that the device could be lost, stolen, or captured by competitive or criminal forces, and later disassembled and even reverse engineered by a sophisticated and capable adversary. For this reason, it is highly desirable that it be impossible for such an organization to extract the user's authorization PIN or password, biometric template, or other enhanced authentication/authorization parameters, or any of the private keys or critical cryptographic parameters, either from the data itself, the encryption device itself, or from the cryptographic processor, or from combination of the three.
  • There is a need for secure physical and logical transport of data for multiple recipients. To this end, it is desirable to provide a means of securely transporting data from one place to another, if the user has to carry the data with him or her, or physically transport the data and the secure encryption device, and somehow communicate the information necessary to log on and access the data by another authorized user. What is required are a multiplicity of methods to securely transport the encrypted data, either physically or logically, between an Originator user and one or more authorized Recipient users of devices and host computers that are operating within authorized enclaves or domains, or are members of certain authorized Communities of Interest.
  • An “enclave” is considered to consist of one or more host computers operating within a single organization or enterprise and under the control of a common security administration, typically subject to some level of physical security, and within which there is some reasonable expectation of interoperability with respect to the use of the subject invention. An example of an enclave would be the computers used within a single corporate campus, such that an employee could insert and use the secure portable secure encryption device. An enclave may be restricted in its scope to include only those host computers that are authorized to process information of a particular type, e.g. Engineering, Human Resources, or Finance. A given host computer may be authorized to be a member of multiple enclaves. A “domain” is considered to consist of one or more enclaves distributed across one or more enterprises or organizations, all operating within a common security framework and policy. An example would be a collection of computers operating at the SECRET level throughout a portion of the Department of Defense, including civilian contractors and other cleared users. A “Community of Interest” is typically a more loosely defined set of host processors and users who all share a common interest and “Need to Know,” even if (in some cases) that interest spans enclaves and domains and even governmental boundaries. An example would be communications between the U.S. military and our allied and coalition partners, and in some cases even indigenous tribal authorities and informal collaborators. In the civilian or social networking sphere, a community of interest might include “Friends and Family,” a chat room, membership on a professional or social e-mail or blog list, etc.
  • In many environments, it is not sufficient merely to restrict the physical access and ability to log on to the device to certain host computers within a given enclave. Instead, there is a need for restricted communication and data containment, and it is necessary to constrain encrypted communications to those members of a pre-defined Community of Interest, so that no one outside of that Community of Interest could possibly decrypt the message. Such a mechanism could be used to enforce Mandatory Access Controls (e.g., clearance levels, compartments, and/or caveats in the military), or a defined Need-To-Know for various proprietary or sensitive types of information in commercial enterprises.
  • It is very important to provide a mechanism for data confinement, such that the secure portable encryption device can only be used in combination with an authorized host computing device. In a military environment, such a mechanism would prevent the encrypted data from being compromised even if the user were coerced into divulging or entering the PIN or password and activating any biometric sensors. In a commercial enterprise environment, such a mechanism could be used to prevent an authorized user from accessing and storing proprietary or personal of data and later decrypting them on his home computer without proper authorization, for personal gain, vicarious pleasure, or purposes that are more nefarious.
  • Similarly, in multiple-recipient data sharing modes of operation, it would be highly desirable to provide one or more system methods or means to control access and cryptographic operations, so that the data contained in or secured by such a secure portable encryption device can only be encrypted on behalf of, and decrypted by, an authorized user, and only on an authorized host computing device as dictated by the security policies of the enclave, domain, or Community of Interest; and not by just anyone who may possess an encryption key pair that could be used in the encryption/decryption process. It would also be highly desirable to ensure that the data is authenticated as having originated by a given user, and to provide nonrepudiation-level protection against manipulation or substitution of the data by an attacker.
  • It would also be highly desirable if a “blocking” or “guard processor” can be provided to ensure that only encrypted and sealed information can be written to or read from designated input/output ports or devices, including removable media. Similarly, it would be highly desirable to support the use of a “black” guard processor that could examine any incoming or outgoing traffic on a communications link to ensure that it was properly encrypted and had not been modified prior to allowing it to be transmitted or received, without the necessity of providing the guard processor the ability to decrypt the data. A “red” guard processor could also be used to decrypt and examine the data for specified sensitive context prior to either releasing it for transmission or, if sensitive data is identified, returning it to the originator with instructions to delete the sensitive data, and perhaps raising an alarm or log event that proper policies have not been followed.
  • There is a need for very long term data recovery mechanisms, and in order to conform to various regulatory and organizational governance requirements, it is desirable that one or more recovery agents be supported, possibly of different types, so that the encrypted data can be decrypted if necessary, even if the original cryptographic keys have been lost and the original user's PIN forgotten. Preferably, the necessary information to support this recovery must be embedded in the encrypted data itself.
  • In the case of small businesses or home users, it may be important to provide some form of an inexpensive Recovery Agent capability that can be used in conjunction with a primary encryption device to decrypt and recover data on a one-time-only basis. Because such a device or means will only be used in the event of the loss or malfunction of the primary device, it may be sufficient (and desirable from a marketing perspective) if the functionality can be limited to a decrypt-only mode of operation. For this reason, it is desirable to support a hybrid mode of operation, providing a static private Elliptic Curve Cryptography (“ECC”) key within a security processor or token, to be used for decryption only; with the symmetric key encryption being performed in software, or at a very bandwidth-limited rate in hardware.
  • Because it is difficult to predict the course of history, the possibility of natural disasters, the failure or obsolescence of the hardware device, and even the dissolution of the original equipment vendor or the user's organization, it is desirable that a highly robust solution be devised to enable distant generations to read the data easily, while at the same time protecting the data as securely as possible for the current generation. This requires what we define as “strong but brittle cryptography”—a cryptographic system that will resist all known attacks for a well-defined period of years or decades, and then will suddenly “snap” and provide relatively simple access to the data by future historians. Because it is difficult to ensure that any hardware mechanism will survive for many decades without failure, in addition to the hybrid decryption function described previously, it is desirable to support a decrypt-only function in a purely software means or mechanism, so that the inevitable changes in computers, operating systems, applications, and even programming languages can be accommodated by updating or porting the software functionality to the future environment.
  • Finally, it must be recognized that the long-term storage of encrypted data presents some very difficult problems in sorting, searching, or even finding any data that is relevant to a particular subject, without being forced to decrypt the entire archive in order to find something. This process is difficult enough if the document is a text document that can be searched relatively easily, but if the information that is sought is a photograph, drawing, sound recording, musical score, computer program, or other more abstract data type, then the search process can be very difficult indeed. In addition to the search difficulty, there is a cost associated with the long-term storage of any kind of data, encrypted or not, and it is often necessary to make an intelligent decision as to what to save and what to discard. But if the information is encrypted, making that decision effectively requires that the information be decrypted in order to examine it, and that may not be practical if terabytes, exabytes, or even petabytes of data are involved. For this reason, it would be desirable if metadata—data about the data—could be saved along with the encrypted data itself. This metadata might or might not be as sensitive as the data itself, just as the subject of an e-mail might or might not be particularly revealing. In some cases, it may not be necessary to encrypt the metadata at all, and in other cases, it may be sufficient to encrypt the metadata using a key that is common across many such files or messages, and is shared with a central archive, catalog, or directory facility. It is therefore desirable to provide a mechanism for attaching metadata to the encrypted file in such a manner as to facilitate the cataloging and subsequent discovery of the contents of the files involved, and allowing the metadata to be sent in the clear, or encrypted in a common key or keys of the archive facility or catalog.
  • In modem communications systems, data, typically in the form of a file, may be communicated, relayed, and stored over a large number of communications and storage media, each of which has some small but finite probability of introducing an error into the transmission or storage of that information. Even if the error is later detected, it may not be possible to correct it if the original source is no longer available. In particular, depending on the Mode of Operation of the cryptographic system, an uncorrected error may cause error propagation throughout the remainder of the decrypted file or message after the point of the error, rendering the data completely unintelligible. This is a particular problem in the case of one-way transmissions, e.g., when the recipient is operating under “EMCON” (emissions control) or radio silence conditions, as well as for one-way storage or archive operations. Although it may not possible to prevent such errors completely, it is desirable to have robust error detection and correction, and to make use of Forward Error Correction techniques that are embedded in the file or message itself, and therefore can be used to recover errors on an end-to-end basis, rather than having to rely on the proper operation of every intermediate link and storage mechanism.
  • In implementing all of the above functionality, it is highly desirable that the methods and apparatus use encryption/decryption and digital signing techniques and related private key and public key algorithms and key sizes that are preferred by the communities of users or have been adopted by international or national standards, or are proprietary to unique institutions. One preferred cryptographic embodiment and implementation is currently (year 2008) represented by the “Suite B” algorithms for both unclassified and classified use by the U.S. Government. Suite B consists of Elliptic Curve Cryptography (ECC) in the prime field GF(P) using key sizes P-256 and P-384 for key establishment between two parties as well as for digital signature creation and verification; the Advanced Encryption Standard (AES) with keys sizes of 128 or 256 bits for symmetric key encryption; and the updated Secure Hash Algorithms (SHA-256 and SHA-384). Reference is also made to U.S. Pat. No. 6,088,802, “Peripheral Device With Integrated Security Functionality,” and U.S. Pat. No. 6,003,135, “Modular Security Device,” both of which are incorporated by reference in their entirety.
  • At the present time, extrapolating the increase in performance and scale of existing technology indicates that the ECC P-384 keys should resist attacks by even nation-states for well over 100 years. However, the looming threat on the horizon is the possibility of highly parallel computations made possible by a form of computation called “quantum computing.” At present, many of the cryptographic protocols, including RSA and ECC are believed to be secure, in that the effort which would be required to break them is considered computationally infeasible. The possibility that quantum computing might become feasible would change this picture dramatically. If realized, the difficulty of most of these problems would drop from exponential complexity to merely polynomial complexity, rendering currently deployed cryptographic systems and key lengths useless. Current expectations by knowledgeable people in the field are that quantum-computing attacks against ECC might become feasible within 30 to 50 years, and that we may have a better understanding of the threat within 10 years. At least at present, there does not seem to be a comparable threat against AES, particular AES-256. The possible threat against “SHA-2” is not known, but NIST has initiated a call for a next generation of hashing functions, “SHA-3.” It is therefore desirable to resist quantum-computing attacks against ECC and against SHA-2 wherever possible.
  • Most prior art solutions to secure information on portable storage devices for transport to different host computing devices or for use by authorized users have certain vulnerabilities as a result of their reliance on software and unprotected hardware implementations, or on the long term, static, non-volatile, and accessible storage of important codes and cryptographic parameters. These vulnerabilities have become much more widely exploitable due to the readily available technological and intellectual resources possessed by well-funded criminal elements, rogue nations, terrorists, and political and military enemies. As of December 2006, as quoted in the New York Times, “Despite an almost four-and-half-year campaign on the part of the company (Microsoft), and the best interests of the computer industry, the threat from harmful computer software continues to grow. Criminal attacks now range from programs that steal information from home and corporate PCs to growing armies of slave computers that are wreaking havoc on the commercial Internet.” Many computer security companies say that there is a lively underground market for information that permits attackers to break into systems via the Internet through Trojan horses among other hardware and software means of invasion of processors and software.
  • Attacks on personal computers and commercial, government and military data are now commonplace; indeed, identity theft of passwords is the largest white-collar crime in the United States. Yet passwords and PINs (Personal Identification Numbers), in most cases generated by human beings who are tempted to use native-language words, Social Security Numbers, telephone numbers, etc., are still the most used access security methods for protecting portable encryption devices, and among the most vulnerable to both brute force dictionary attacks as well as sophisticated logic tracing. Professional criminal attackers and even amateur hackers now have access to sophisticated software and supercomputing networks that can unknowingly invade processing devices and storage devices, trace software instruction sequences and memory locations, and by knowing or discovering the algorithms being used, intercept and copy encryption keys, PINs, and other profile data used to protect the access to stored content. They can exploit vulnerabilities in the underlying commercial software, or in the construction of the integrated circuit chips housing and executing the cryptographic processes, or in the specialized cryptographic software, which enables exposing keys and access parameters at some deterministic point in the processing sequence. Industrial laboratory facilities are also available to read the data content stored in memory cells by measuring the electronic charge through the use of electronic beam microscopes, and thus steal stored PINs, keys, and therefore access the previously protected data.
  • One of the key deficiencies of prior art, therefore, is the widespread reliance on a stored PIN or password that is used for comparison purpose, for access control, or used for password-based encryption to protect other cryptographic variables. Typically, the value that is stored is not the PIN itself, but a hashed or otherwise obfuscated version of the PIN, e.g., in the form produced by a PKCS#5 process. In the case of a password-based encryption process, the PIN itself may not be stored, but only the encrypted key, which may then be used to encrypt other information. In any case, however, some kind of a value is stored, and if it is possible to locate and extract that value, then in general it is then possible to mount an offline exhaustive search attack against the PIN itself, with no constraints as to the amount of time, number of unsuccessful attempts, or the number of networked distributed processors that may be applied to such an effort. Many of the more celebrated attacks against Digital Rights Management and copy protection systems for digital media, for example, have been successfully carried out by such means.
  • Prior art is also directed at methods of cataloging user access at different security sensitivity levels and in different communities of interest through implementation of access control tables generally located at centralized servers. These tables are controlled by an institution's centralized policies that specify predetermined access rights for each of a plurality of users relative to data resources which themselves are identified with predetermined levels of security. Access tables further include domain and rule information for each user to control the collection of domains and conditions of authorization of their security rights. Such systems are optimized for protecting access to centralized sensitive data but are not adaptable to secure the user authorization and access and decryption rights to data which is transportable via portable storage media. Since the table data is external to the secured media on which the data is stored, the processes to authenticate the user and authorize decryption of the data are generally not cryptographically secure nor are they adaptable to be implemented by the portable storage device itself, even with the presence of processing capability on the device.
  • Many prior art methods exist for the key management protection necessary for securing key encryption keys for large groups of users. Split-key secret sharing schemes have been proposed whereby the decryption key is split and shared among multiple parties or entities to be combined to reconstitute the decryption key. In these cases, however, the individual secret shares themselves are maintained statically in multiple storage devices, generally on-line, where they are susceptible to attackers, particularly from within the institution, who can target the secret shares and recombine then to form the decryption key. Such solutions are implemented for relatively static configurations of computing and storage devices and related communities of interest or tiers of users, and have not addressed the ability to so protect key encrypting keys when the data itself, and the means to encrypt and decrypt the data and to generate and recombine the shared secrets, are on a portable device.
  • SUMMARY OF THE INVENTION
  • The present invention addresses these issues and severely mitigates or eliminates vulnerabilities or requires levels of time and effort that could well render the value of the information as insignificant by the time it could be exposed as plaintext. Through the use of the methods, apparatus, and system represented by the invention, together with the selection of available manufacturing techniques for protection of circuit chip contents by means of physically bonded sealing and shielding, self-destructive anti-tampering logic to zeroize memory contents, and advanced techniques for mitigating so-called side-channel attacks, a commercially affordable and superior security solution for protecting the access to portable stored data by unauthorized host computing devices or unauthorized users can be introduced to the public.
  • A portable encryption device with logon access controlled by an encryption key is disclosed comprising an enclosure for the device providing a portable form factor, and a cryptographic processor within the enclosure for reconstituting the encryption key from a plurality of secrets generated by a secret sharing algorithm. The secret sharing algorithm may comprise a K out of N secret sharing mechanism, such as Shamir's Secret-Sharing Algorithm with Lagrange interpolation. The encryption key may be, for example, a master key encryption key, or application key encryption key.
  • Optionally, one or more of the generated secrets have been shrouded with one or more external secrets using an invertible transform, such that any one of the external secrets may be changed without recreation or re-dealing of all of the plurality of generated secrets. A suitable invertible transform is XOR. One or more of the external secrets may comprise a user's PIN, which may be a supervisory user's PIN. Still further embodiments are possible where the external secrets comprise a plurality of user's PINs, and the transform is invertible with less than all of the plurality of user's PINs.
  • Other embodiments of the external secrets are possible, such as where one or more of the external secrets comprise a firmware hash, one or more of the external secrets comprise a host authorization code associated with one or more specific host computing devices, binding the portable encryption device to such one or more host computing devices, or one or more of the external secrets is generated by a proximity detection mechanism. An external secret can also be a function of multivariate parameters, such as geographic-locus or biometric input. Optionally, the external secrets are communicated over a secure channel with a secondary device, such as a connected host computing device, or a remote device.
  • Means for interfacing with a user authentication device can be added, such as a secure PIN entry mechanism, or secure biometric input. Still further embodiments comprise removable memory configured for data storage, a data communication module, or additional cryptographic processors within the enclosure. The cryptographic processor may be a microprocessor that has been programmed to execute cryptographic functions.
  • A method for controlling logon access on a portable encryption device having a portable form factor and a cryptographic processor is disclosed, comprising generating a plurality of secrets by a secret sharing algorithm, configuring the cryptographic processor to reconstitute an encryption key from the plurality of generated secrets, and determining logon access as a function of the reconstituted encryption key. The secret sharing algorithm may comprise a K out of N secret sharing mechanism, such as Shamir's Secret-Sharing Algorithm with Lagrange interpolation. The encryption key may be, for example, a master key encryption key, or application key encryption key.
  • Optionally, a further step can be added of shrouding one or more of the generated secrets with one or more external secrets using an invertible transform, such that any one of the external secrets may be changed without recreation or re-dealing of all of the plurality of secrets. A suitable invertible transform is XOR. One or more of the external secrets may comprise a user's PIN, which may be a supervisory user's PIN. Still further embodiments are possible where the external secrets comprise a plurality of user's PINs, and the transform is invertible with less than all of the plurality of user's PINs.
  • Other embodiments of the external secrets are possible, as noted above. Optionally, a further step can be added of communicating the external secrets over a secure channel with a secondary device, such as a connected host computing device, or a remote device. In a still further embodiment, a step is added of receiving input from a user authentication device, such as secure biometric data, optionally over a secure channel.
  • A portable encryption device with file decryption controlled by a file encryption key is disclosed comprising an enclosure for the device providing a portable form factor, and a cryptographic processor within the enclosure for reconstituting the file encryption key from a version of the file encryption key which has been shrouded with a network authorization code.
  • A method for controlling file decryption with a portable encryption device having a portable form factor and a cryptographic processor is disclosed, comprising generating a network authorization code, distributing the network authorization code to a community of interest through an out-of-band distribution mechanism, shrouding a file encryption key with the network authorization code using an invertible transform, receiving the network authorization code from a user, causing the cryptographic processor to reconstitute the file encryption key from the received network authorization code, and determining file access as a function of the reconstituted file encryption key. An encrypted file may then be decrypted as a function of the reconstituted file encryption key. The invertible transform may be XOR, or an invertible transform that is resistant to quantum computing attacks. In a further step, the network authorization code is encrypted and code is distributed to a recovery agent.
  • A method for file encryption of a plaintext file is disclosed, comprising the steps of hashing the plaintext file to produce a plaintext hash, compressing the plaintext file, encrypting the compressed plaintext file to create ciphertext, hashing the ciphertext to produce a ciphertext hash, hashing the plaintext hash and the ciphertext hash to produce a result hash, and sealing the ciphertext together with the result hash using a digital signature algorithm to produce the encrypted file. The encrypted file may be communicated to originator-selected optional recipients. A portable encryption device having a portable form factor and an on-board cryptographic processor may be used to perform the method.
  • Further optional embodiments provide for an enforced mandatory recovery agent, breaking the encryption of the encrypted file at a pre-determined date, or embedding forward error correction within the encrypted file.
  • Where the plaintext file has metadata, a further embodiment separately encrypts the metadata, and the seals the ciphertext together with the result hash and the encrypted metadata. Optional further steps for independent key exchange mechanism to permit decrypting the metadata by catalog agent are possible.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of one embodiment of how a SPED can be utilized.
  • FIG. 2A is a block diagram of a HCD, and one embodiment of an SPED, and biometric authenticator configurations.
  • FIG. 2B is a perspective view of one embodiment of an HCD and SPED.
  • FIG. 2C is a sketch of an SPED in a portable form factor.
  • FIG. 3A is a block diagram of the SPED with optional removable memory module and an optional user authentication device comprising a secure PIN entry mechanism and biometric input.
  • FIG. 3B is a view of a physical implementation of one embodiment of a system incorporating an SPED and HCD.
  • FIG. 4 is a flow chart of a method, according to an embodiment, for installing software to initiate use of an SPED and to authenticate a user or system security officer.
  • FIG. 5 is a block diagram of an HCD, according to one embodiment of the invention.
  • FIG. 6 is a block diagram illustrating one embodiment of the HCD, the SPED, and the optional secure PIN entry/biometric sensor device.
  • FIG. 7 is a flow chart of a method, according to one embodiment of the invention, for selecting among the different modes of operation of a system according to one embodiment of the invention.
  • FIG. 8 is a flow chart of one embodiment of key management within an SPED.
  • FIG. 9 is a block diagram of another embodiment of the physical implementation of the system with security operations executed by software within the SPED.
  • DETAILED DESCRIPTION
  • In accordance with the present invention, cryptographic operations are implemented on data for secure storage and transport by means of a system comprised of one or more than one secure portable encryption device (“SPED”) capable of such cryptographic operations, and optionally storing and communicating such secure data to host or peripheral devices, one or more than one host computing device (“HCD”), and means for securely protecting access to that data. One embodiment of the means for securely protecting data is to permit access and cryptographic operations on that data only to authorized recipients, or only on authorized host computing devices, by a “K of N” split-knowledge sharing algorithm method of generating and cryptographically assigning shrouded secret shares which are bound to authentication/authorization means such as shareholder PINs, passwords, Host Authorization Codes (HAC), or other host, SPED, or other user authentication/authorization means as will be known to one or ordinary skill in the art with reference to this disclosure. Another embodiment of the means for securely protecting data is to utilize a Network Access Code (“NAC”) as part of a shrouding operation on file encryption keys. Another embodiment is a method for file encryption of a plaintext file, comprising the steps of hashing the plaintext file to produce a plaintext hash, compressing the plaintext file, encrypting the compressed plaintext file to create ciphertext, hashing the ciphertext to produce a ciphertext hash, hashing the plaintext hash and the ciphertext hash to produce a result hash, and sealing the ciphertext together with the result hash, to produce the encrypted file. These and other embodiments will now be discussed in detail. It should be noted that these embodiments could be used alone, or in combination.
  • As will be understood by those skilled in the art, the phrase “cryptographic operation” includes hashing, encryption/decryption, digital signature/verification, and sealing (e.g., hashed and digitally signed ciphertext). The term “PIN” (Personal Identification Number) is used herein to designate a (typically short) series of numbers, an alphanumeric password, or a lengthy passphrase consisting of arbitrary words, letters, numbers, and/or special characters without limitation.
  • In one embodiment, the SPED is used to communicate with the HCD to enable one or more cryptographic operations to be performed by the SPED on data provided from the HCD to the SPED (which data can then be, for example, stored in the SPED or returned to the HCD for storage) or on data that has been transmitted by wire or wireless means to the SPED from another device, or input to the SPED by a person.
  • In another embodiment, the data may be represented and stored as individually encrypted and/or sealed files. In general, the process of hashing, compressing, encrypting, and digitally sealing the file results in a new object that may be of considerably different size, either larger or more often smaller than the original, with the result that the encrypted file cannot simply replace the original file. As a result, the act of storing the encrypted file must involve interactions with the directory or File Allocation Table in ways that the originating program or operating system cannot easily discern. For this reason, the means of encrypting these files may either be a straight pass-through, generally requiring the implementation of a file-handling system within the SPED itself, or the data may be looped-back to the HCD, either for storage locally, or for yet another pass, wherein the files are broken up into discrete sectors by the host operating system prior to being stored on the SPED, such that the SPED is not required to implement the required file processing logic.
  • Split-Knowledge Sharing Algorithm Method of Generating and Cryptographically Assigning Shrouded Secret Shares which are Bound to Authentication/Authorization Means
  • In one embodiment, the means of generating and distributing Host Authorization Codes for host computing devices on the basis of security policies allows an institution to permit users to securely move data back and forth among a multiplicity of computers in a defined enclave, for example, between a branch and a central office, but prevents a user from decrypting the data on an unauthorized machine, even if the user possesses the encrypted data, the SPED device containing the keys necessary to decrypt the data, and is in possession of the PIN/password required for access, and can even satisfy any biometric criteria, so long as he does not know the Host Authorization Code, or other Enhanced Authorization codes, devices, or methods. This invention dynamically defines and configures the authorized population and tiers of users, portable encryption devices, and host computing devices.
  • As will be described, the use of a set of K out of N shrouded secrets to reconstitute a Master Key Encryption Key involves the use of an exclusive-OR operation for the shrouding, and a mathematical algorithm (Shamir's secret sharing algorithm) involving N equations with K unknowns. Neither of those operations involve the use of cryptography in the conventional sense, and the difficulty of “breaking” such schemes does not depend upon any assumptions of computational intractability, but instead provide provable mathematical intractability. With respect to the K out of N secret sharing scheme, for example, if fewer than K shares are entered, or if any of the shares are entered incorrectly, then the results are mathematically indeterminate and no better than random guessing. Likewise, if even a single bit is in error in the shrouded calculation, then the result is simply incorrect, and provides absolutely no information that might aid an attacker.
  • For this reason, this embodiment of the invention provides mathematically provable security with regard to the reconstitution of the Master Key Encryption Key. Even if a very sophisticated laboratory attack could be used to “peel” the security processor chip and extract the contents, without the knowledge of K out of N of the authentication factors, it is mathematically impossible to recover any data, unless someone can break the AES-256 key wrapping algorithm.
  • Two Subsystems for Distributing Secret Shares and Host Authorization Codes
  • In one embodiment, two subsystems operate in conjunction for creating and distributing secret shares and Host Authorization Codes according to the authorized configuration of users, secure portable encryption devices, and host computing devices: (1) a hardware-based encryption device identified as the Secure Portable Encryption Device (SPED) that connects to a host computer device via an interface such as a Universal Serial Bus (USB 2.0 or 1.1), an ExpressCard™ interface, or other similar wired or wireless functionality, and contains its own integrated cryptographic security and operational processing capabilities and memory storage facilities, and (2) a general purpose computer, or a form of PC computer, PDA, cell phone, or other type of programmable computing device supporting applications software, referred to as the host computer device, which contains a suitable operating system, the necessary device drivers and other middleware, and an application program which provides the Graphical User Interface (GUI) to control the functionality.
  • Overview of the Major Functional Parts of the System
  • Referring to FIG. 1 of the drawings, the Originator/user 11 of data 12 is shown as part of the block diagram which depicts the various major functional parts of the system including the two apparatus subsystems, the secure portable encryption device 14 (hereinafter referred to as the SPED) and the host computing device 13 (hereinafter referred to as the HCD). It also illustrates the cryptographic system means 20 by which access to the stored content of the SPED 14 is authorized only for designated users 11 and HCDs 13. Data 12 is introduced into the system for the purpose of having some cryptographic operations performed on it (e.g., digital signature, hashing, encryption) in order that it may be secured in the HCD 13 to be securely transported 15, via the SPED 14, to another authorized HCD 13 for the originator's 11 use, or for use only by an authorized Recipient 17, and protecting the SPED 14 so that, if lost, the data content cannot be accessed.
  • The data 12 can be any form of digital data (text, photographic, scanned, audio, video, etc.) and can be generated through keyboard input 18 by the user 11, or input by the user through attachment of a peripheral device (e.g., disc reader, memory storage device, digital camera, etc.) or downloaded through some form of wired or wireless network connection to either the HCD 13 or the SPED 14.
  • The SPED 14 can be of a form such as a flash drive token, or a digital media recorder/receiver or iPod® type device, with integral or replaceable/removable memory, comprised of cryptographic and operational processing hardware capabilities, control and flow logic controls, and interface connections for multiple device attachments.
  • The SPED 14 is connected to an HCD 13 such as a personal computer, hereinafter referred to as a PC. Other forms of HCDs 13 may be cell phones, video recorders, workstations, or other device configurations which support an input device 18 for input of user commands (e.g., a keyboard or touch screen), some form of display 19 for graphically providing information to the user, a form of digital computer processor for computing on data and interfacing with the input commands supplied by the user, storage memory means for storing data and program instructions, connection port interfaces (e.g., USB, Firewire, ExpressCard™) for connecting with peripherals (e.g., disc storage, printers, scanners) and communications devices (e.g., WLAN, Ethernet, modems), control logic and busses for routing of data and control signals among all the elements of the device and with external peripheral devices sufficient to perform the functions required by the application, and some form of operating system software (e.g., Windows XP®, Windows Mobile®, VISTA®, MAC OS®, Linux®, Symbian®) which provides the process control and sequencing of all instructions, operations, and data flows within the HCD 13 and to all peripheral devices, and supports applications software which can be loaded through digital media (e.g., CD-ROM) or downloaded via the internet or some other network facility.
  • Externally generated data may be loaded into the HCD via any of the available interfaces of the HCD or, in another embodiment, loaded into the SPED through an external secondary connector integral to the SPED.
  • Description of Split-Knowledge and the Application of Shamir's Secret-Sharing Algorithm
  • Access to the SPED 14 contents and its operation with an HCD 13 is controlled by authentication of an authorized user 11 and a HCD 13 authorized by the SPED 14 through use of a split-knowledge approach that applies the Shamir secret sharing algorithm, which is well known to those who practice the state-of-the-art in cryptography. System means for implementation of the secret sharing algorithm is comprised of computing method 20, executed by cooperation between host computing device 13 and secure portable encryption device 14, that creates the Master Key Encryption Key that protects the critical cryptographic parameters of the SPED and creates secret authorization shares which protect the contents of the SPED from access by any but authorized users on authorized HCDs. It should be understood that in the case of multiple cryptographic applications, a multiplicity of Application Key Encryption Keys (AKEKs) may be used, with one AKEK being used per application, rather than a single Master Key Encryption Key for the entire device. The following detailed descriptions will apply to a single Master Key Encryption Key or a multiple Application Key Encryption Key.
  • Secret Sharing
  • Secret sharing refers to any method for distributing a secret amongst a group of entities, human or inanimate, each of which is allocated a share of the secret. The secret can only be reconstructed when the shares are combined together; individual shares are of no use on their own. Secret sharing schemes were discovered independently by Blakley and Shamir. The motivation for secret sharing is secure key management. There is one secret key, the SPED 14 Master Key Encryption Key (the MKEK), (or potentially one or more Application Key Encryption Keys per application) which provides access to all the secure keys and critical cryptographic attributes held by the SPED 14.
  • Secret shares are created within the SPED 14 through an initialization process that generates, according to the method of Shamir, a temporary polynomial equation from which the MKEK and the secret shares are derived. The shares are then individually combined and shrouded, through the use of a transform, with external secrets (e.g., PINs, authorization codes) from each of the entities or components comprising the system (e.g., users and apparatus, namely, users 11, the HCDs 13, and the SPED 14). The novelty of storing and using a transform rather than the secret shares themselves prevents collusion of external entities, which have knowledge of their own external secrets, from recovering and reconstituting the MKEK or AKEKs, and allows simpler logistics for changing any individual entity's secret without generating a new polynomial and distributing new shares to all. The external secrets are required inputs for authorization to reconstitute the secret MKEK or an AKEK and access the secured data contents contained by the SPED 14 or the associated HCD 13.
  • Any group of K or more entities (up to N) can come together to reconstruct the secret MKEK or an AKEK, but no group of less than K entities can accomplish this. Such a system is called a (K, N)-threshold scheme.
  • A popular technique to implement share reconstitution in polynomial based threshold schemes uses polynomial interpolation (“Lagrange interpolation”). Two points uniquely define a line, three points define a parabola, four define a cubic curve, etc. More generally, n coordinate pairs (xi, yi) uniquely define a polynomial of degree n−1. The SPED 14 processor generates the temporary polynomial equation, encodes the secret (i.e., the SPED Master Key Encryption Key—MKEK or one of the Application Key Encryption Keys) as the curve's y-intercept, and creates shares, each of which represent the coordinates of a point on this curve. When the shares from K entities are reconstituted to re-form the polynomial curve, interpolation can compute the y-intercept that represents the secret MKEK. It is also possible, using a well-known optimization of the Lagrange method, to recover a specific point without recovering the entire polynomial.
  • This particular method was invented by Adi Shamir in 1979. Shamir's scheme is provably secure, that means: in a (K, N) scheme one can prove that it makes no difference whether an attacker has K−1 valid shares at his disposal or none at all; as long as he has less than K shares, there is no better option than guessing to find out the secret. Given any K shares, the polynomial is uniquely determined and hence the secret MKEK, the “y” intercept, can be computed. However, given (K−1) or fewer shares, the secret cannot be reconstituted.
  • Shrouding External Secrets
  • The external secrets cannot be used directly to reconstitute the secret MKEK. The shrouding operation discussed above provides additional security against attacks by ensuring that the secret shares do not remain in static storage within the system and are only reconstituted at their time of use. The shrouding technique provides the additional advantage that a user's PIN or some other external input can easily be changed by un-shrouding with the old value and reshrouding it with the new value, without have to replace the shared secret or re-deal all of the shares. Because of this approach, neither the share values nor the external secrets are ever stored on the SPED.
  • This scheme ensures that the shares cannot be recovered, even by a sophisticated attacker who might “peel” the chip and attempt to analyze it with an electron microscope or extremely small probes. The external secrets (e.g., PINs, authorization codes) are the only values known outside the SPED. Assuming that at least N−(K+1) of the external secrets remain secure, the MKEK is mathematically-provably secure, as the scheme does not rely on the usual assumptions of “computational infeasibility” required for most cryptographic operations. So long as K shares are known, the MKEK can be recovered, otherwise all of the data protected by the MKEK will be irretrievably lost.
  • An external PIN, password, passphrase, or arbitrary string of bits is hashed using SHA-256, and that value “Exclusive OR'ed” (XOR) with its associated secret share value to provide the shrouded share value that is maintained within the SPED. After the shrouding operation is complete, the (un-shrouded) secret shares are securely destroyed by overwriting memory locations in which they were stored.
  • For this embodiment, K=5 and N=6, and the secret shares, in their shrouded form, are stored within the cryptographic boundary of the cryptographic processing chip on the SPED 14 and never leave the device. The entities with shares include two classes—authorizing and enabling. At least one of the authorizing entities, the security officer PIN or the user PIN, must be present in order to reconstitute the secret MKEK. Enabling shares are bound to at least: 1) the media controller/microprocessor in the SPED 14, 2) the SPED itself through identification of its integral cryptographic processor chip, and 3) a host-computing device. Optional shares may be created and stored within the SPED cryptographic processor for binding with other identified entities. Where a security officer is not involved, the user PIN and the security officer PIN can be set to be equal. External PINs and/or passwords uniquely associated with each of the entities are cryptographically associated with each of these shares as will be discussed further below.
  • Block Diagram of the System and its Constituent Parts
  • FIG. 2A is a block diagram of a system 200. The system 200 includes an HCD and a SPED 202 that communicate via a communications interface 203. The SPED may also optionally contain another communications port interface (204) for connection to other types of peripheral devices 205, such as digital cameras, wireless or wire transceivers, memory devices, etc. The SPED 202 includes at least an integrated cryptographic processor IC chip set 202 a that enables cryptographic operations (examples of which are described in more detail below) to be performed on data that is stored within and “looped-back” to the HCD 201, data that is transmitted from the HCD 201 to the SPED 202, data that is transmitted from the SPED to the HCD 201, data that is transmitted from another peripheral device 205 through connection port 204 to the SPED, data that is transmitted from the SPED 202 to another peripheral device 205 through connection port 204. As explained in more detail below, the SPED 202 can obtain its mass memory capacity through integral connection port 206 which interfaces to a mass memory storage module 207 (e.g., a mini SD memory card). Alternatively, for more secure authentication of users in the log on process, the SPED 202 can connect, as shown in FIG. 2C, through connection port 206 to a biometric module 208 (e.g., a module including a fingerprint scanning device 209, a retinal scanning device, or a face print scanning device) with a secure direct entry scrolling thumbwheel or similar device 210, a display window for status information 211, and an internal connector 212 for connection to SPED 202 through connector 206.
  • Generally, the communications interface 203 can be embodied by any of a variety of communication interfaces, such as a wireless communications, USB, Firewire, Express Card, a serial such as an RS-232 interface, or a parallel interface. Each embodiment of the communications interface 203 includes hardware present in each of the HCD 201 and SPED 202 that operates in accordance with a communications protocol (which can be embodied, for example, by software stored in a memory device and/or firmware that is present in the HCD 201 and SPED 202) appropriate for that type of communications interface, as known to those skilled in the art. Each embodiment of the communications interface 203 also includes mechanisms to enable physical engagement, as appropriate, between the HCD 201 and the SPED 202. Similar embodiments can exist for communications port 204 to connect peripheral modules 205 and the SPED 202.
  • Generally, the cryptographic processor configuration 202 a can be configured to perform any electronic data cryptographic operation (herein, referred to simply as a “cryptographic operation”) including, for example, operations that provide one or more of the basic cryptographic functions, such as hashing, encryption/decryption, digital signature, key exchange, verification of data integrity, and user authentication. Particular cryptographic operations that can be implemented in the SPED 202 are described in more detail below.
  • The cryptographic processor configuration 202 a can be, for example, a dedicated cryptographic processor in combination with an FPGA and an ARM microprocessor. Herein, “cryptographic processor” refers to an IC chip set configuration that performs cryptographic operations and that includes one or more mechanisms (such as, for example, use of a hardware random number generator and/or protected memory) to provide security for the content of those operations.
  • FIG. 2B is a perspective view of a physical implementation of the system 200 of FIG. 2A, according to one embodiment of the invention. In FIG. 2B, the SPED 202 of FIG. 2A is embodied as a flash card memory device form factor 215 that can be inserted into a corresponding USB socket 213 formed in a laptop computer 214 that, in FIG. 3B, embodies the HCD 201 of FIG. 2A.
  • In another embodiment, various pieces of metadata from the original file, including time and data information, file name, and other data, optionally including metadata specifically added by the user or attached to the file through other mechanisms, including so-called Alternate Data Streams, may be included in final encrypted version of the file. Such data may be carried in the clear, i.e., unencrypted, or it may be encrypted using the same keys used to encrypt the data, or it may be encrypted in yet another key or keys, including the key(s) associated with a central repository or cataloguing service, or in some combination of these keys. The function that performs this cataloging service will be referred to as a Catalog Agent. The Catalog Agent may or may not be the same entity as the Mandatory Recovery Agent described above.
  • Block Diagram of the System Showing Optional Memory Module and Adjunct Authentication Module
  • FIG. 3A is a block diagram of an SPED 301, according to one embodiment, including an integral cryptographic processor chip set 302, a plug-in replaceable/removable mass storage media 303 (e.g., miniSD memory card), and an optional authentication module 304 that consists of a biometric fingerprint scanner and a mechanism for securely entering an alphanumeric PIN input device, such a thumbwheel, joystick, or touch screen. It is possible, as explained in more detail below, to use the modular SPED 301 with the replaceable/removable mass memory storage module 303 without any connected biometric module 304 or external peripheral device. The SPED 301 and memory module 303 are physically separate devices that can be physically and electrically joined (as described further below) to enable communication between the modules 301 and 303.
  • Plan View of Physical Implementation
  • FIG. 3B is a plan view of a modular SPED 310 that represents a physical implementation, according to one embodiment, of the modular device 301 of FIG. 3A. The SPED 310 includes a first module 311 and can attach to a second module 325 through port connection 314 and can communicate with an attached peripheral 316 (e.g., wireless transceiver) through an additional port connection 315. A connector 313 is formed at one end of SPED 311. Opposite the connector 313 is a connector 314 for attaching a miniSD memory card 317 or other mass memory storage module or peripheral 325 with a compatible connection interface for signaling and data transfers.
  • For example, in one embodiment, an optional biometric fingerprint scanner 318 and alphanumeric user input device illustrated in FIG. 3 as a scrolling alphanumeric thumbwheel 319 with “push-to-enter” characteristics and display window 320 can be configured as a covering “sleeve” housing 321 to connect to the SPED through connections 314, for the purposes of using a scanned fingerprint and secure user PIN entry for securely authenticating the user to the SPED 310 and HCD 324. The mating connection of this biometric module 312 is constructed to have a compatible connection 322 within the recess of its housing to mechanically and electrically interface to the SPED module 311. The SPED 311 can have a size and shape such that the SPED 311 can be directly inserted into a USB connector socket 323 on the HCD 324, to enable communication between the HCD 324 and the SPED 310. Optionally, another external peripheral apparatus 316, e.g., a digital camera, a wireless transceiver, a memory media, may be directly attached or cabled to the port connection 315 for transferring data to or from the SPED 310.
  • Initiating Use of the System
  • FIG. 4 is a flow chart of a method 400 for initiating use of a system. The system that includes a SPED and a HCD can be implemented according to the method 400 so that policies can be accommodated for first time initialization of the system by a user or by a designated system security officer 402. Either designee proceeds through steps 403 or 414 to load and install software on the HCD to display user procedures to initialize, zeroize, change PIN, and view device properties of the SPED. The designated user inserts the SPED 404 into the connection socket of the HCD and the presence of the SPED is detected 405. The SPED is further configured to optionally recognize a particular recipient HCD through the setting of the Host Authorization Code in steps 406 or 407, and proceed to initialize the SPED 408 in preparation for the user or SSO authentication process as illustrated by steps 409 and 410 or 411, 412, 413, and 415. In the case where the user is the designated installer and initializer of the SPED, if successful authentication has occurred, the user may start the application 416. If the system security officer is the designated SPED installer and initializer, the SPED may be delivered to the user by the security officer who initiates a log on process by which the user can enter their own PIN for processing through steps 417, 418 and 419. The user then proceeds to authenticate himself to the device through steps 409 and 410 or 411, 412, 415, and if successful, starts the application in step 416.
  • It is to be understood that the method 400 shown in FIG. 4 is not the only way to enable the embodiments of use of an SPED with a HCD as illustrated in FIG. 4. As can be readily appreciated by those skilled in the art, such embodiments can be implemented using any of a variety of other appropriate methods. Further, the installation of software and initialization of a SPED can include embodiments not illustrated in FIG. 4 as in the case of authentication default processes 413 and 420; likewise, such use may not include some of the embodiments illustrated in FIG. 4 because of specific security policies or regulations governing the user's organization. The method 400 of FIG. 4 is shown merely to aid in the illustration of certain embodiments, and should not be interpreted as restricting the manner in which an SPED can be used.
  • Description of the Host Computing Platform
  • FIG. 5 is a block diagram of an HCD 501 according to one embodiment, illustrating operation of the HCD 501 during a method such as the method 400 of FIG. 4. The HCD 501 (e.g., as a desktop PC configuration) comprises a display device 502 (e.g., an LCD display, monitor), and user input device 503 (e.g., a keyboard, touch screen, trackball, joystick or other appropriate device), referred to collectively hereinafter as user interface device 503. The HCD 501 also comprises, mounted within a housing 504, a processing device 505, a memory device 506, an input/output (I/O) device 507 for enabling communication with the user interface device 503, and an input/output (I/O) device 508 for enabling communication with the SPED. The devices 505, 506, 507, and 508 can each be implemented by conventional devices and can communicate with each other via a conventional computer bus 509, as is well known and understood.
  • Description of the Separate Hardware and Software/Firmware Elements
  • FIG. 6 is a block diagram of system 600, according to one embodiment, comprising the separate hardware and software/firmware components that are used in the cryptographic-processing, authentication, and authorization processes such as the method 400 of FIG. 4. The HCD 601 comprises resident applications software and drivers that interface with the SPED 610 and cooperate to execute the secret sharing algorithm for combining cryptographic shares from the user, the HCD 601, the SPED 610, and, optionally, an administrative security officer, to implement the system means for reconstituting the Master Key Encryption Key of the module SPED 610 as will be described later. The user interface software module 602 is integrated into the operating system file system through a browser shell and interacts with the user by providing the user with appropriate menus and messages. The SPED middleware 603 provides functionality that is used by the user interface to interact with the modular SPED 610. The SPED administrative tool software module 604 provides a user interface for SPED administration that helps the user to initialize, zeroize, change PIN, and view the device properties. The filter driver software module 605 is constructed as a file system mini-filter driver that uses the operating system filter manager component. The USB function driver module 606 presents a Microsoft Windows PCSC interface to the system and the host authorization service module 607 is a service that runs in system space as part of the systems methods that protect the host authorization code and cooperates with the SPED 610 to support the execution of the shared secret algorithm. In other operating systems, similar constructs could be used.
  • One embodiment of the SPED 610 includes a processor/controller device 611, an FPGA 612, a cryptographic processing device 613, an attachable/replaceable memory device (e.g., miniSD, miniSDHC, or microSDHC memory card) 614, an input/output (I/O) device 615 for enabling communication with the host computing device 601, an input/output (I/O) facility 616 for enabling communication with an optional biometric fingerprint scanner and secure PIN entry device 620, and to communicate and interface with an optional peripheral device (e.g., a digital camera, an additional memory media, a wireless transceiver) 617. The components 611, 612, 613, 614, 615, 616, and 617 can each be implemented by commercially made devices and can communicate with each other via conventional computer busses as is well known and understood. The processor/controller 611 is a 32-bit ARM processor and is the main controller for all the secure mass storage operations and for most interface data flows performed by the SPED module 610. It acts as the master state controller for the SPED module 610, and implements public key cryptographic and signing processing used during the file encryption and decryption operations. It also implements a hashing operation as part of providing the random numbers required for ephemeral keys and other cryptographic values. The FPGA 612 provides high-speed execution of AES-256 and SHA-384 algorithms (as well as other AES key size and hash size alternatives) to support encrypt-and-seal/decrypt-and-verify operations, as well as providing the interface to the cryptographic processor 613 and the attachable mass memory (e.g., mini-SDHC memory card) storage device 614.
  • In one embodiment, the cryptographic processing device 613 is implemented in a cryptographic controller that has been programmed for such processes. The secure operation of the SPED 610 uses this processor for user authentication and for secure generation and storage of the static keys used during file encryption and decryption. It also provides an approved high-entropy random bit generator. In this embodiment, it is fabricated with special coating and electrical shield properties and zeroization schemes to protect the chip contents from sophisticated electronic “peeling” or scanning or invasive attacks to retrieve secure contents.
  • In another embodiment, an optional biometric authentication device comprises a fingerprint scanner and secure PIN entry 620 and serves to provide, during the user log-on process, additional secure levels of authentication through biometric fingerprint scanning to match user templates captured and stored in the processor 621 memory of the 620 during scanner training and initialization procedures. This physical configuration embodiment fits as a sleeve over most of the SPED module 610 and connects through an internal connector 625 that is within the recess of the module and interfaces with the SPED module 610. After the fingerprint scanner is used and the user fingerprint is verified, and secure PIN entry is made through the human input device, and the user is authenticated by the SPED module 610, and the log on process is completed and displayed to the user by the HCD 601, the sleeve may be removed and the removable mass memory device 614 attached. The biometric authentication device 620 includes an integrated control processor 621 with on-chip RAM and flash memory, and a biometric fingerprint swipe or platen sensor 622 used for capturing the fingerprint image that can be processed by the SPED module 610 for template matching and user authentication. The biometric module 620 also comprises a scrollable thumbwheel or other form of human input device 623 for use in direct secure PIN entry by a user. When requested by the SPED module 610, the control processor 621 will use this human input device 623 to collect the PIN and send it directly to the SPED module 610 for user authentication. A display 624 is used for displaying status messages and prompting the user for required inputs. The devices 621, 622, 623, and 624 can each be implemented by conventional devices and can communicate with each other via a conventional computer bus 626, as is well known and understood. The HCD module 601, the SPED module 610, the biometric module 620, and the peripheral device module 617 are shown in simplified form in FIG. 6 to facilitate clarity in illustration of this embodiment, as described in more detail below and as understood by those skilled in the art. The HCD module 601, the SPED module 610, the biometric module 620, and the peripheral device module 617 can—and typically will—include other devices not shown in FIG. 6.
  • Inter-Relationship of the Components
  • A significant advantage of the system according to the present invention comprising a SPED and a HCD is that the system comprises a set of sequential procedures for system installation and initialization of hardware and software subsystems to configure and integrate physical and logical levels of access authorization for portable memory storage apparatus. The present invention accomplishes this by means of a K out of N split-knowledge technique that combines a mandatory minimum set of: 1) Host Authorization Code (HAC) information that can be specific to a HCD and enables a unique transformed external secret for each HCD, 2) the user's PIN, 3) an optional security officer's PIN, 4) SPED-specific internal identification information, and 5) other unique identifier information that may be optionally required by an organization's security policies and procedures. The system can be implemented to employ these individually created and independent authorization parameters to reconstitute at least “K” shared data values whose total combination is required to reconstitute a Master Key Encryption Key (MKEK) that protects the private keys and the other critical cryptographic parameters stored on the SPED against loss or all forms of attacks.
  • The system that comprises a HCD and a SPED can, in general, be configured, initialized, and operated in one of two modes depending upon an organization's security policies and procedures: 1) requiring only a single user PIN to install and initialize the system as in the case of a sole proprietorship where the individual selected for the installation and initialization procedures can be the ultimate user of the system, and 2) requiring a second PIN assigned to an administrative system security officer (hereinafter referred to as SSO), as in a government or commercial institution protecting valuable intellectual property or vital national interests. The system can enable a system security officer or other designated security administrator, according to the policies and procedures of an organization, to be the designated person to physically initialize the SPED with the HCD in order to limit the access only to those users, SPEDs, and HCD host computers that have “need to know” access permissions as defined by such policies and procedures. The system can be implemented so that under such a security policy, first the system security officer can create the HAC for each designated HCD, then create an SSO PIN and initialize the SPED, and then can distribute an SPED to the user for the creation of their PIN as in FIG. 4, Method 400, steps 402, 403, and 414.
  • As discussed further in this Description, there can be delineation between the required authorized actions of a user and an administrator/security officer. Unless otherwise specified, the general term user will apply to both.
  • Referring to FIG. 6, the system that includes a SPED and a HCD can be implemented so that first time use of the system begins when the user loads (either through media (e.g., CD-ROM, the SPED memory download) or network interconnection) and installs mass storage software 602, 603, 605, 607, into the HCD 601 which includes its own device drivers 605 for the SPED replaceable/removable storage module 614. This software also includes operational and user interfaces 602 for the SPED replaceable/removable storage module 614. When prompted by the appropriate software module, a user of the system connects the modular SPED 610 device to the HCD. Such connection can occur in any manner that enables the SPED to communicate with the HCD. Frequently, this will occur as a result of a physical connection of the modular device to the host-computing device. For example, the SPED can be implemented as a USB flash memory token (e.g., a form factor conforming to a USB connection as established by the appropriate standard), or alternately by an ExpressCard form factor, that is inserted into a corresponding socket formed in the HCD. Alternatively, the SPED can be implemented in a housing from which a connection cord extends, a plug of the cord being inserted into a mating receptacle formed in the HCD. However, such physical connection need not necessarily occur; the SPED can also be connected to the HCD by any type of wireless communication, e.g. Bluetooth or infrared, for which the HCD contains an appropriate interface.
  • The system that includes a SPED and a HCD can be implemented so that for the first time use of the system, a user can also load and install administrative tools software 604 on the HCD 601 that provides user interfaces and procedures to initialize, zeroize, change PIN and view device properties on the SPED 610 and operate the SPED 610 and HCD 601 systems. In the case of a physical connection, a user inserts the SPED 610 into the connection socket of the HCD 601. Once connection between the SPED 610 and the HCD 601 is made, the HCD 601 detects the presence of the modular device. Such detection of the presence of a peripheral device is typically enabled as a standard embodiment of the software installed into the HCD.
  • Support for Software-Only and/or Hybrid Decryption and Recovery Mechanisms
  • All of the hashing, symmetric key encryption/decryption, and public key operations (key establishment and digital signatures) may be performed within the security perimeter of the trusted hardware security device. However, in order to satisfy potential cost constraints for the Recovery Agent capability, another embodiment may comprise a hybrid means whereby a decrypt-only capability could be provided, wherein only the public key operations are implemented within a hardware device, and the hashing and/or symmetric key operations are carried out in software on the host computing device. Yet another embodiment may consist of a purely software implementation of the Recovery Agent decryption capability.
  • Mathematically Protected Enhanced Authentication Mechanisms and Indicia
  • In another embodiment, the authentication and authorization methods used within the SPED are sufficiently extensible as to deal with other enhanced authentication devices, methods, and functions, in such a manner as not to necessitate the storing of such enhanced authentication parameters (e.g., biometric indicia, user proximity detection code, permitted operational location information, etc.,) for later comparison in such a manner that such parameters could be extracted and used, under even national laboratory conditions.
  • Embodiment Using a Host Authorization Code
  • In a further embodiment, an organization security officer/administrator, or an individual user loads a set of software modules into the host-computing device from a CD-ROM, from a read-only portion of the SPED itself, or from other forms of software distribution media, including wireless communications. The administrator/user determines if the SPED is to function only on one or more designated host computing devices, or with any and all host computing devices. In the case of assigning the SPED to only work with designated host computing devices, the SPED executes, prior to initialization, a series of programs to establish one or more named or default “Host Authorization Codes (“HAC”) which can be unique to each host computing device or can be shared among an enclave or Community of Interest of users. In an information system configuration involving multiple Originators, Recipients and host computing devices, an administrator can, personally or by delegation to a trusted representative, cause the same HAC to be set on each HCD or can set multiple HACs on HCDs if the host computing devices are to be shared by different user enclaves or Communities of Interest. In the case of setting up the SPED to work with any host computing device, a default HAC is created and the initialization program creates an individual PIN and generates new sets of cryptographic signature and encryption keys. In the case of security policies of centralized organizations, the administrator can generate a system security officer PIN and each user PIN number to complete the initialization process. Although the HAC used within an enclave may be the same for all the host processors within the enclave, a “diversified” version of the HAC may be created by hashing or encrypting the stored HAC value together with the serial number of SPED device, prior to loading the diversified HAC onto the SPED, in order to ensure that a “wire-sniffing” attack could only compromise the particular diversified value of the HAC used for that particular SPED, and not all such devices.
  • In another embodiment, the integrated SPED processor mediates the communications between the host computing device (HCD) and the SPED itself, as a result of user interface enabled instructions provided by the host computing device, to allow various options for user authentication and log on, device initialization, optional setting of the host authorization code (HAC), and control of the processing and flow of the encrypted/decrypted data. One security mode encrypts data from the HCD and stores it directly in the SPED memory media for storage or communication with another device. In an alternative mode, data from the HCD is encrypted and returned directly in a “loop-back” mode of operation, without being stored for application usage by the SPED memory, and, in the reverse situation, data from the HCD is sent to the SPED for decryption and then returned. It is important to note that HCD data encrypted by the SPED can only be accessed and decrypted by a user who has the PIN and the SPED device, and an authorized computer, if a host authorization code process has been established.
  • In a further embodiment, the SPED is activated by the user through the input of a PIN to execute the log on process and gain access to the facilities of the SPED. The PIN is established during an initialization process, which can be executed by an individual user acting as a security administrator. Alternatively, in an organization with a centralized administrator and set of tiered or multi-level security policies, the system security officer can initialize any SPEDs. The user may be allowed to change his or her own PIN/pas sword, or that ability may be blocked by a policy option.
  • Another benefit of a system that includes a SPED 610 and a HCD 601 is that the system can be implemented so that an optional Host Authorization Code (HAC) can also be set so that the SPED 610 will function only with HCDs 601 set up with the appropriate HAC (i.e. the same HAC that has been set on the SPED 610). This embodiment of the present invention can provide a unique fourth level of authentication, (in addition to the physical possession of the device, the knowledge of a PIN, and the biological sensing of some user's physical characteristic, e.g., a fingerprint), namely identification and authorization of a particular HCD(s) 601 in order for an authorized user to logon and access the information on the SPED 610.
  • Depending upon the organization's policies, a user or SSO can log on to the HCD and set the Host Authorization Code (HAC) by creating a long, statistically unlikely to guess or discover (in excess of 100 alphanumeric characters; for highest security, the present embodiment permits up to 255 alphanumeric characters) random or pseudo-random code, which can be generated by blind fingering actions on a keyboard, or by creation of a pseudorandom or random code by the SPED cryptographic processor 613, or by an application program that runs on the HCD 601, and whose results can be copied and transferred as the HAC input to the HAC creation program. This input HAC alphanumeric string can be put through a transform (e.g. a one-way hash function) before being maintained on the HCD 601 or being set on the SPED 610. This HAC, in its transformed form if this has been done, is stored in the HCD 601 registry in an encrypted form that is specific to the computer (HCD) on which the SPED 610 will be authorized to operate. This is accomplished by using a unique property of the HCD, such as an internal serial number of the bios chip, processor chip, or other secure readable or calculable method of identification installed by the manufacturer for unique HCD identification and licensing. Access to this encrypted HAC value in the registry is further protected against extraction or copying, by authorization services SPED authorization service 607 software procedures allowing read only access only to designated administrators. Users that do not belong to this group cannot have any access permissions to the registry key or value.
  • The HAC will also be sent to the SPED 610 to set up this value as the authorization code used for recovering its corresponding share to be used in the K of N derivation of the MKEK. Before setting the HAC value in the SPED 610 it can also be transformed yet again in order to diversify it so that it is unique to the SPED on which it is set, so that a compromise of a HAC for a particular SPED would not compromise the HAC for all SPEDs used with a common HAC through a common enclave or domain, for example. This requires using something unique to the SPED 610 (e.g. the SPED serial number) and combining it with the HAC to perform the transform before sending it to the SPED (e.g. append the SPED serial number to the HAC and then cryptographically hash the combined value). Of course, this same process will be used when the shared secret is first generated and the shares created.
  • The particular manner in which the HAC shared secret can be set is dependent upon the initial entry of a pseudo-random alphanumeric string and the binding of the creation of the secret to a specific identity of the HCD 601. Using this process the same HAC can be set on more than one HCD 601 allowing a particular SPED 610 (an SPED initialized with this particular HAC) to be used on multiple HCDs. However, if the appropriate HAC has not been set on a particular HCD 601 the SPED 610 in question (the SPED initialized with this HAC) will not be able to be authenticated, therefore blocking its use on that HCD 601.
  • In addition, when saving the HAC on a particular HCD 601, the HAC can optionally be assigned a common name associated with that particular HAC value. In this way, multiple HACs can be set for a single HCD 601, each only valid for the specific SPEDs that have been initialized with this particular named HAC. Using this feature, a given host can support multiple levels of security classifications, each with it own community of interest as defined by a common named HAC.
  • To illustrate this mode of operation, the system that includes a SPED and a HCD can be implemented to permit alternative creation of HACs for remotely located HCDs, on which the proper SPED mass storage and administrative tools software have been loaded. For example, in an alternate embodiment of the present invention as illustrated in FIG. 1, multiple remotely located host computing devices are connected to a network 22 in a client-server configuration which also comprises a server 21 An Originator 11 can create a host authorization code on their specific host computing device 13 and secure portable encryption device 14, and share this HAC with other Recipients or users 17 in the same Community of Interest without requiring individual user interaction by the Originator's SPED 14 with each host computing device, by communicating the Originator's created host authorization code by a cryptographically secure mutually authenticated client-server channel connection 22 to a system server 21.
  • Distribution of the Originator created host authorization code to the host computing devices of the designated members 17 of the enclave or domain transmits the shared HAC through a cryptographically-secure, mutually-authenticated client-server channel connection 22. Since the external host authorization code is transformed by the SPED using a unique identifier from each HCD, the HAC secret can only be correctly reverse transformed by the same HCD and combined with the other shared secrets to reconstitute the MKEK. In this manner, multiple HACs may be created to be distributed to combinations of host computing device according to security policies and the designation of Communities of Interest.
  • In one further embodiment of the present invention, a given SPED 610 can only support a single HAC and therefore a single, optionally named classification level. At the time of SPED 610 initialization, the name of the HAC 601 specified for operating with a given SPED 610 is carried as a public object in the SPED 610 cryptographic processor 613 and is accessed by the HCD middleware 603 after insertion of the SPED, and the matching HAC in the HCD 610 list of HACs will be loaded into the SPED 615 in order to enable a user to log on from the particular authenticated HCD.
  • User Authentication after the HAC has been Set
  • A further embodiment of a system is that once the HAC has been set, the user continues with the process of initialization of the SPED 610. Before use of the secure data processing applications of the SPED 610 for the first time, the SPED 610 must be initialized to generate keys and set the user Personal Identification Number (PIN). Preferably, a minimum length of at least seven alphanumeric characters for the PIN is entered via keyboard input. Optionally, the SPED device can be configured to require an even longer PIN, and/or imposed various complexity requirements such as the number or upper and lower case characters, numbers, and/or special characters. The system according to the present invention can require PIN entry either from a keyboard input associated with the HCD 601, or from a secure PIN entry device 623 integrated with a biometric (e.g. fingerprint) scanner 622 as dictated by security policies for user authentication.
  • The SPED can identify, through the HCD microprocessor 611 operating system software, the presence of a secure PIN entry/biometric verifier device 620. In one embodiment, in the event that biometric identification fails, then PIN entry is blocked. If biometric authentication is successful, and incorrect PINs are used to try to access the SPED 610, either as a result of forgetting the PIN or an attack, the time between successive tries can be doubled each time to further increase the difficulty of attack, particularly if the device is left unattended and attached to a host computer. After ten tries, a counter in the SPED cryptographic processor can signal the logic in the SPED to become blocked to prevent a further brute force attack to gain access. The threshold count can send a logic signal to cryptographic processor 613 and encryption keys can be deleted and the PINs completely reset.
  • A SPED can be implemented so that when the PIN entry process is complete and approved, the initialization process continues with the generation of static keys for file encryption, of public/private signature key pairs with private keys stored in cryptographic processor 613, of key encryption keys for wrapping and protecting file encryption keys, and generation of an AES-256 Master Key Encryption Key for encrypted protection of the entire contents of all keys and critical cryptographic parameters stored within the SPED cryptographic processor 613.
  • When the Master Key Encryption Key (or an individual Application key Encryption Key) is generated during initialization, “N” secret shares associated with that key are created by the cryptographic processor 613. This embodiment of the secret sharing algorithm incorporated by the invention, namely that a minimum set of K out of N shares must be combined to reconstitute the Master Key Encryption Key (or the specific Application Key Encryption Key for the application that is being selected) at log on, and that the HAC, user PIN, and SPED 610 data must be within the K set, makes the SPED 610 information storage contents provably secure against access and cryptographic attacks unless all these codes are available. Without the proper HAC, it is mathematically impossible for anyone to be able to log on to the device and access or decrypt the data contents, even if the user PIN is known.
  • When PIN creation is complete, the SPED is ready for log on and all cryptographic processing operations.
  • Detection and Use of the SPED and any Mass Memory or Peripheral Device
  • The SPED may be equipped with a non-volatile memory storage device, such as a miniSD or microSD memory card, available in various sizes up to multiple gigabytes in a very compact form-factor. The memory can be hard-wired and non-removable, but preferably is removable and replaceable via a built-in memory chip socket.
  • In another embodiment the SPED takes the form of the SPYRUS Hydra Privacy Card® Series II (Hydra PC™) using either the USB interface or the ExpressCard™ interface that is intended to be plugged into a socket within the host computer device housing. This embodiment is of the type of form factor generally used in “flash memory” drive products. An alternate embodiment would include the ExpressCard™ form factor, using an adapter cable with appropriate voltage-reducing circuitry to connect the ExpressCard™ to a USB connector on the host device. Other alternate embodiments of the SPED can be of the form of a handheld multimedia communications device such as a cell phone, smartphone, MP3 player, video player wherein the host computing device can be a local user desktop or laptop computer, or a remote media distribution facility interconnected by wireline or wireless communications over the Internet.
  • When the user PIN is created, connection between the SPED 610 and the HCD 601 is made, and the user logs on to the SPED through one of the PIN/biometric methods previously described, the host computing device 610 detects and identifies the presence of the SPED in the manner of plug-and-play protocols as is known in the state of the art. The SPED detects the presence and identity of the associated non-volatile mass memory storage module 614 and any peripheral device 617 that is connected to the secondary EO connection port 616. Such detection of the presence of an attached peripheral device 617 is typically enabled as a standard embodiment of the operating system software of the SPED processor 611.
  • Typically, once the presence of an attached peripheral device 617 is detected by the operating system software of the SPED 610, the operating system software (or companion software program) also identifies the type of the peripheral device (e.g., digital camera, wireless transceiver, disk memory module). This can be accomplished, for example, by a standard software device driver (hereinafter, “SPED driver”) for peripheral devices 617 of the type that use the SPED secondary EO connection port 616. In FIG. 6, the SPED driver is stored in the RAM memory 611 a of the SPED processor 611. It is to be understood that the examples given above are merely illustrative, not exhaustive, of the ways in which a peripheral device 617 can be used. Many more possibilities exist.
  • Though, as shown in FIG. 6, the SPED includes cryptographic processing functionality, and also provides connection to peripheral device functionality 617, the system 600 can be operated so that only the cryptographic processing functionality is used.
  • The SPED device driver and HCD interface, administrative, and middleware software can have been previously installed to the RAM memory of the host computing device via an appropriate interface (such as a CD-ROM drive or network connection), as previously discussed for first use installation and initialization, at the time when the user first initiated interaction between the host computing device and the SPED. Additionally, when a SPED device is used with a host computing device which utilizes operating system software that supports the feature informally referred to as plug and play, the SPED related software can be stored in non-volatile storage memory 614 of the SPED or, as available, in the SPED 611 a microprocessor memory configuration. Thus, when the SPED is connected for the first time to a particular host computing device, the host computing device can automatically provide the user with the opportunity to instruct the host computing device to cause the SPED interface, middleware and device driver software to be transferred from the SPED memory to the host computing device.
  • Modes of Operational Use
  • FIG. 7 is a flow chart of a method 700, according to an embodiment, for using an SPED. Once user authentication has been acknowledged and approved, the user can begin using the SPED (in particular, the cryptographic processing functionality of the SPED), as shown by steps 701, 702, 703, 704, and 705 of the method 700. Such use can be enabled by software programs that are cooperatively executed by the host computing device and the SPED.
  • It is to be understood that the method 700 shown in FIG. 7 is not the only way to enable the embodiments of use of an SPED that are illustrated in FIG. 7; as can be readily appreciated by those skilled in the art, such embodiments can be implemented using any of a variety of other appropriate methods. Further, the use of a SPED can include embodiments not illustrated in FIG. 7; likewise, such use may not include some of the embodiments illustrated in FIG. 7. The method 700 of FIG. 7 is shown merely to aid in the illustration of certain embodiments, and should not be interpreted as restricting the manner in which an SPED, can be used.
  • A SPED can, in general, be operated in one of four modes: 1) a mode in which the cryptographic processing functionality is used on data created by the HCD and is stored in the SPED mass memory module 614 for physical transport or subsequent electronic communication, 2) a mode in which the cryptographic processing functionality is used on data created by the HCD and is looped back to the HCD for storage in an HCD integral or attached memory storage module or for communication to a server or remote storage device, 3) a mode in which the cryptographic processing functionality is used on data communicated by the attached peripheral device 617 and is stored in the SPED mass memory module 614 for physical transport or subsequent electronic communication, and 4) a mode in which the cryptographic processing functionality is used on data communicated by the attached peripheral device 617 and is looped back to the attached peripheral device 617 for storage in the peripheral device integral or attached memory storage module.
  • Upon receipt of an acceptable user authentication input, the SPED signals the host computing device to present a user interface that enables the user to effect desired control of the SPED, and, in particular, to use the SPED to perform cryptographic operations, as described below. The user interface for enabling a user to operate the SPED can be implemented in any of a variety of well-known ways (e.g., as a graphical user interface) using methods and apparatus that are well known to those skilled in the art. Generally, the user interface enables the user to perform any functionality that is provided by the SPED as described in more detail elsewhere herein.
  • As indicated above, a SPED can be operated in any of four modes. Once an acceptable user authentication has been approved, the peripheral device driver can enable the user to select one of the four modes, as shown in step 706 of the method 700. The HCD user interface software and the underlying middleware, drivers, applications, and interface software enables the user to input all desired or required instructions regarding the cryptographic data processing operations to be performed for a particular “transaction” (e.g., encryption of a file from the HCD for storage in the mass memory module 614, the transmission of encrypted data by an attached peripheral communications device, or a loop back of data encrypted for storage in the HCD) as shown by steps 710,711, and 712 of the method 700. For example, again referring to FIG. 6, the user interface software module 602 can enable the user to select on which data cryptographic operations are to be performed, specify the application of particular cryptographic operation to that data, and specify parameters or other information required for a particular cryptographic operation.
  • For example, if the cryptographic functionality is embodied as encryption of files and folders from the HCD 601 for storage on the mass memory 614 of the SPED 610, the file or folder icon is highlighted and selected on the HCD displayed graphical user interface, and, for example on a Microsoft Windows system, a drop-down menu lists “Encrypt to SPED” as a prompt for clicking on the item to execute the action and implement the data transfer through modules 605, 606, and 615, and to effect cryptographic processing actions via the appropriate cryptographic resources available from the appropriate SPED cryptographic processing modules 611,612, and 613. If more than one SPED is inserted into the HCD when files or folders are encrypted, the HCD software 603 and 606 will prompt the user to select the destination SPED. The file or folder name stays unchanged and a new file extension is added to indicate that the file is encrypted.
  • Once the user has provided instructions in steps 706 and 707 or 710 or 713 or 714, the particular cryptographic processing transaction is executed, as shown by step 708 or 711 or 714 or 717 of the method 700. After execution of the cryptographic processing transaction, the data is transferred to the appropriate destination via step 709 or 712 or 715 or 718. Eventually, use of the SPED ends, as shown by step 719 of the method 700.
  • Use of the SPED for General Cryptographic Processing, Including PKI Functions
  • The cryptographic processing functionality of a SPED can be configured to perform any cryptographic operation, as well as other, related mathematical operations. A configuration of the cryptographic processing functionality that enables a particular cryptographic or mathematical operation can be produced, for example, by using appropriate existing cryptographic software, application-specific hardware, or combination of the two, as known by those skilled in the art of producing cryptographic devices.
  • In particular, the SPED can be configured such that the functionality of the Crypto Processor (613) serves in a manner similar to a conventional smart card or USB token for carrying out a wide variety of cryptographic and PKI functions, including both legacy (RSA, DSA, triple-DES, SHA-1) and advanced (EC Diffie-Hellman, ECMQV, ECDSA, AES, and SHA-2) algorithms in combination with HCD application and/or operating system software. Examples of such processing include hardware-based public key operations earned out within the SPED, with symmetric key and hashing functions earned out in software on the HCD, for applications such as smart card logon, IPSEC link encryption, SSL/TLS encryption and mutual authentication to web servers, secure and authenticated e-mail (S/MIME), pre-boot authentication for Full Disk Encryption solutions, WiFi link encryption, and other similar cryptographic protocols and purposes known to those skilled in the art.
  • Following is a description of exemplary cryptographic and mathematical operations that can be implemented as part of the cryptographic processing functionality of a SPED. These cryptographic and mathematical operations are well known and can readily be implemented in a SPED by a person of skill in the art of cryptography.
  • For example, a SPED can implement one or more cryptographic key exchange operations. Any key exchange operation can be implemented, such as, for example, the ECDH, the ECMQV, the RSA, and the X9.42 (ANSI Banking Standard) key exchange algorithms.
  • A SPED can also implement one or more hash operations. Any hash operation can be implemented, such as, for example, the SHA-224/256/384/512, SHA-1, and the Message Digest 5 (MD5) algorithms.
  • A SPED can also implement one or more digital signature operations. Any digital signature operation can be implemented, such as, for example, the ECDSA Digital Signature Algorithm, and the RSA Signature (1024, 2048) algorithms.
  • A SPED can also implement one or more key wrapping operations for both symmetric and asymmetric keys. A key wrapping operation can ensure that plaintext keys are not accessible external to the portable device. Any key wrapping operation can be implemented.
  • A SPED can also implement one or more symmetric encryption operations.
  • Any symmetric encryption operation can be implemented, such as, for example, the AES-128/192/256 with ECB, CBC, CTR, and key wrap modes, and the DES (including 3DES, EDE3, CBC and ECB).
  • A SPED can also implement one or more asymmetric (public key) encryption operations. While asymmetric encryption operations underlie the key exchange operations described above, asymmetric key operations can also be used independently in a SPED for bulk encryption. Any asymmetric encryption operation can be implemented, such as, for example, the RSA, Diffie-Hellman, and Elliptic Curve Diffie-Hellman algorithms, and various variants thereof.
  • A SPED can also implement one or more exponentiation operations, which are required in many cryptographic operations. Any exponentiation operation can be implemented. Since exponentiation requires a significant amount of processing time relative to other mathematical operations, it can be desirable to implement an exponentiation operation in dedicated hardware. In one embodiment of a SPED, the cryptographic processing functionality of the portable device includes a full exponentiator implemented in hardware.
  • A SPED can also implement one or more random number generations, which are required in many cryptographic operations. Since high quality random number generation is required for robust, strong key generation and other critical cryptographic functions, and requires a significant amount of processing time relative to other mathematical operations, it is desirable to implement random number generation with approved algorithms in dedicated hardware. Cryptographic processing functionality of the portable device includes a full random number generator implemented in hardware.
  • Provision for a Multiplicity of Mandatory and Optional Recipients of the Encrypted Data
  • In another principle embodiment of the present invention, the files or records to be encrypted, digitally signed, and/or sealed may include a multiplicity of file header information sufficient to allow multiple Recipients (optionally including the Originator) to be able to decrypt and verify the information that has been so protected, whether that data has been recorded on the storage medium contained within the Secure Portable Encryption device itself, on an integral or ancillary encryption device connected to the host computing device, or some other encryption device that is logically accessible to the Host Computer Device or the Secure Portable Encryption device.
  • A means of designating a number (zero or more) of Mandatory Recovery Agents or Recipients of the secured information that cannot be bypassed by the normal originator may be provided on behalf of the institution under the control of the System Administrator or System Security Officer on a per HCD basis; together with some other number (zero or more) Optional Recipients specified by the originator, that are required or allowed to be able to decrypt the encrypted information. This set of Mandatory and Optional Recipients is not necessarily limited to a single enclave as defined by a single common named or default Host Authorization Code (HAC), but instead can confine communications between and among a fixed set of users operating in different enclaves, while preventing users from accessing or decrypting the information outside of their own authorized enclave, even if they possess the secure portable encryption device and know the user PIN. This invention dynamically defines and configures the authorized population and tiers of users, portable encryption devices, and host computing devices that are allowed to communicate through the flexibility of support of multiple Host Authorization Codes by each host-computing device.
  • Use of Public Keys and Credentials
  • In another embodiment of the present invention, the credential(s) of the Recipient(s) may be provided to the Secure Portable Encryption device (SPED) in the form of a raw public key, for example suitable for use in the EC Diffie-Hellman or ECMQV key establishment scheme, through some trusted out of band process. Alternatively, the Recipient's credentials may be embedded in a conventional X.509 digital certificate, which has been digitally signed by a trusted Certification Authority or chain of Certification Authorities acceptable to the Originator.
  • In another embodiment, the user's credentials in the form of one or more X.509 certificates, including a certificate and certificate chain that has been signed using the legacy public key algorithms (e.g., RSA or DSA) and legacy hash functions (MD5 or SHA-1), together with the user's SPED ECC encryption and digital signature public keys, may be bound together in either a proprietary format or an X.509 attribute certificate, and signed using the user's/SPED high-strength ECC digital signature key. Such an approach would allow the user's legacy credentials to be validated using the existing (typically RSA-based) certificate infrastructure and revocation checking mechanisms, while still making use of the much higher-strength ECC keys for long-term transactions.
  • Data Recovery Through Strong but Brittle Cryptography
  • In another embodiment of the present invention, the various Mandatory or Optional Recipients may be differentiated and selected by the guaranteed longevity of the secrecy of the private keys held by those Recipients, e.g., an Historical Recovery Agent. It is envisioned that the private keys associated with such a Historical Recovery Agent would be split into independent shares using a secret-sharing algorithm, and those shares entrusted to a large number of universities, public libraries, museums, government archives, religious organizations, and other stable and long-lived institutions, such that many but not necessarily all of those institutions working in concert, e.g., perhaps 70 out of 100, would be able to reconstitute the private key. The public key associated with the Historical Recovery Agent could be included within an X.509 or other form of public key certificate, with the expiry period being plainly indicated in the certificate itself. Those institutions could then gather in a conclave perhaps once per decade, reconstitute the private key that was destined to expire on that date, and publish it to the world. As a result, documents that had been securely encrypted for the last 10, 20, 50, or even 100 years would instantly become readily accessible to future generations.
  • Containment of Encrypted Data to Authorized Users within a Named Community-of-Interest by Means of a Network Access Code
  • Another embodiment of the means for securely protecting decryption is to utilize a Network Access Code (a synonymous term for a Network Authorization Code known to those skilled in the art, either term being represented by the acronym “NAC”) as part of a shrouding operation on file encryption keys. In this embodiment, means are provided to optionally restrict the decryption of encrypted information flowing to or from (a) the HCD via the SPED, and (b) one or more other (remote) authorized user(s); unless both the Originator of the encrypted communication and all of the Recipients of said encrypted communication share a common pre-shared NAC or key, which is associated with the creation of a named Community of Interest of authorized members in such a way that if both the Originator and a particular Recipient do not both know the Network Authorization Code the Recipient will not be able to decrypt the information, even if the Originator has knowledge of and trusts the Recipient's public key.
  • This Network Authorization Code may be stored on the user's SPED, or alternatively on the HCD or some external device or server, or even split between and among the SPED, the HCD, and some user-provided information using a secret-sharing algorithm (for example, as described above), and may be used as part of an overall data containment enforcement mechanism to ensure that information is not communicated, either physically or logically (e.g., via a communications network) to unauthorized users, even on a cross-domain basis. The NAC can be used to enforce data containment to within a group or domain of authorized users, by requiring the Originator and all of the various Recipients know or share a common NAC for that domain.
  • Means are further provided to securely generate, distribute, store and access, use, and recover the NAC throughout the Community of Interest. Various means, including encrypting the NAC in the public key of the authorized user's SPED device, can be used to distribute the NAC securely, such that it can be stored on the SPED device itself, on the host processor that is used, or on some external device such as a server, so that it can be retrieved and used. Optionally, similar means can be used to distribute the named NAC for a given Community of Interest to one or more Community-Of-Interest Recovery Agents, so that it can be reconstituted in the event of the loss or destruction of the SPED or even the death or disability of the user.
  • As will be understood by those skilled in the art, the management of possession of this NAC could take a multiplicity of forms, ranging from a simple out-of band communication of the password or passphrase used to generate the NAC; up to a complex, world-wide network of Community of Interest Registrars and Recovery Agents responsible for authenticating the identities, clearance levels, and bona rides with respect to membership in the Community of Interest.
  • The NAC is exclusive-ORed (XORed) or otherwise combined (e.g., by the use of encryption or some other invertible transform) with the File Encryption Key used to encrypt the file or message, to create what may be called a Shrouded File Encryption Key (SFEK). This SFEK can then be encrypted in the normal manner with a Key Encrypting Key that is derived from the EC Diffie-Hellman or other key exchange mechanism through a standard key derivation process as described in the literature. As will be appreciated by those skilled in the art, this process makes it impossible to decrypt the File Encryption Key, and therefore the file itself, unless the EC Diffie-Hellman key exchange operation takes place successfully, and the NAC is known.
  • Details of the Cryptographic Key Exchange Mechanisms
  • FIG. 8 is a flow diagram that illustrates one embodiment of how key management is performed within the SPED 811 when a NAC is used. For every file that is to be encrypted, a new ephemeral public/private ECC key is generated for the Originator 800. The public ephemeral key that is generated at the same time (not shown) is saved for inclusion in the File Header 817 of the Encrypted File 813. The SPED receives the Recipient's static public key 801 from an external source, which may be an X.509 public key certificate or similar construct 804. The Elliptic Curve Diffie-Hellman operation 802 is carried out in the conventional manner, by multiplying the Originator's private ephemeral key times the Recipient's static public key in the ECC field. The output of that function is a shared secret, conventionally called Z, that is passed to a Key Derivation Function (KDF) 803 such as the Concatenation Key Derivation Function defined within SP 800-56A. Other supplementary public and/or private information 804 may be passed in to the KDF as well, in order to bind the key that is generated to the identity of the parties. The output of the KDF is a Key Encrypting Key (KEK) 804.
  • Independent of the EC D-H key agreement, a random generated symmetric File Encryption Key (FEK) 806 is generated for the file, along with a randomly generated Initialization Vector (IV) 810. In addition, the NAC 805 is retrieved from secure storage within the SPED, and both the NAC and the FEK are passed to the shrouding operation 807, which may simply exclusive-OR the two values together, or alternatively might encrypt the FEK using the NAC as a key.
  • In either case, the output of that operation is a Shrouded Key Encryption Key, which is input as data to the AES Key Wrap operation 808 and wrapped with the Key Encryption Key (KEK) 804 that was previously computed by the KDF.
  • The output of the AES Key Wrap operation is a Wrapped Key Blob 809, which is then written to the File Header 817 of the encrypted file 813. Also included in the File Header is the Originator's ephemeral public key (not shown) that was generated at the same time as, and corresponds to, the Originator's ephemeral private key 800, as well as the Initialization Vector (IV) 810.
  • The symmetric File Encryption Key 806 together with the Initialization Vector (810) is then used to encrypt the plaintext data 816 using the conventional Cipher Block Chaining mode of operation, or alternatively a mode such as Galois Counter Mode, to create the final Encrypted File 813.
  • The operation of this process during the decryption step is almost identical, except that the role of the Originator's ephemeral private key and the Recipient's public key are reversed. In other words, the Recipient uses his or her static private key instead of the Originator's private ephemeral key 800, and uses the ephemeral public key obtained from the File Header instead of the Recipient's public key 801. Otherwise, the operation proceeds exactly as for the encryption step, except that the File Encryption step 811 is replaced by a decryption operation.
  • Mitigation of Quantum Computing Attacks
  • An additional benefit of the NAC would apply in the event quantum computing ever becomes practical. Although it is hypothesized that some day it might be possible to use quantum computing as a tool to “break” an RSA, ECC, or other public key algorithm that might be used to encrypt the Shrouded File Encryption Key, breaking that algorithm would do the attacker no good at all without the knowledge of the Network Authorization Code. Assuming the NAC is XORed with the File Encryption Key, and that the NAC itself is distributed by a secure, out-of-band process, i.e., it is not itself encrypted in a public key system, then there are no mathematical or cryptographic processes that could be attacked using quantum computing other than a brute force exhaustive search attack against a 256-bit key.
  • Separation of Function Between Trusted Third Party Recovery Agents
  • In yet another embodiment, means are provided for surviving the loss, theft, destruction, or eventual failure or obsolescence of a SPED by recovering, at a trusted third-party File Recovery Agent, the file encryption keys used to encrypt a multiplicity of files and then securely re-encrypting the individual file encryption keys associated with the data (but not the data itself) using a new encryption key or set of keys installed in a newer or replacement SPED, all the while guaranteeing that the Recovery Agent cannot access or decrypt the contents of the file without knowing the NAC that was used when the file was originally encrypted.
  • In yet another embodiment, means are provided for surviving the loss, theft, destruction, or eventual failure or obsolescence of a SPED by recovering the Network Access Code or NAC, though the use of a Community-of-Interest Recovery Agent (CRA), that would receive and store the encrypted NAC used within a Community of Interest, and could upon an authenticated demand, export that NAC to an authorized user's SPED device, but without ever having access to the private key or keys of any of the authorized users SPED devices, and hence without the ability to decrypt the data itself.
  • Generating, Distributing, Storing, and Using the Network Authorization Code
  • It will be understood by those skilled in the art that there are a multiplicity of means methods that could be used to securely generate, distribute, store, and make use of the Network Access Code.
  • In one instantiation, which might be well-suited for casual use by friends and family or social networks, the NAC could be entered by the Originator during the encryption process (and by the Recipient(s) during any decryption), in the form of a passphrase that would be entered via the keyboard attached to the HCD, with the passphrase being passed to the SPED by the host software and hashed within the SPED to form the NAC before it is used.
  • The NAC can be given a unique name, and centrally managed by a Community of Interest manager or authority. For example, a community of interest of automobile parts manufacturers might be established by Chrysler, so that those vendors could communicate with Chrysler, but Ford would not be able to originate or decrypt messages to that COI. Likewise, Ford could set up their own COI, and Chrysler would not be able to participate, but those vendors that sold to both Chrysler and Ford would be able to communicate with both, but separately.
  • The NAC would be randomly generated using a random number generator in an SPED, and then encrypted in the ECC public key of the authorized user, using a conventional EC Diffie-Hellman and Key Derivation Function to encrypt the wrapped NAC. Once created, the named wrapped NAC could be sent to an authorized user in any convenient manner, including e-mail, FTP, etc. Upon receipt by a user, the named NAC could be stored on the SPED token itself or it could be stored on the HCD for retrieval as needed. The NAC would be decrypted by the SPED prior to use. An additional embodiment recognizes that in order to recover a file or other information at some distant point in time, it will be necessary to recover the NAC as well as being able to decrypt the Shrouded File Encryption Key. Because databases of keys, NACs and other such information might become disassociated from the message or otherwise rendered inaccessible, it is highly desirable that the encrypted NAC information be earned in the encrypted file or message itself. For that reason, preferably the NAC will be encrypted in the public key of the authorized user, and in the public key or keys of one or more Community of Interest Recovery Agents (CRA). In this embodiment, the NAC would be encrypted only once per user, but the encrypted form would include the wrapped version of the NAC, encrypted one or more times for the various CRAs. Because the wrapped value of the named, encrypted NAC would never change from the time it is created, it can simply be included in every message as a opaque blob. The Originator of the message or file would be able to decrypt the NAC, if necessary, using the private key of the SPED, and any authorized CRA would be able to decrypt that NAC, but the various Recipients would not be able to decrypt it, because it was not encrypted using their keys. In order to decrypt the message, the Recipient would have to have received their own copy of the NAC, encrypted in their own public key, in order to decrypt and apply the NAC and subsequently decrypt the message.
  • Assured Protection Against Tampering Via an Independent Guard Processor
  • In an optional embodiment, means are provided through which an independent Guard Processor computer or mechanism can verify that the entire contents of any encrypted file or other form of data were properly encrypted and have not been tampered with or accidentally modified since that time. The means makes use of a secure hash function that is computed by the SPED contemporaneously or simultaneously with the encryption operation, with the resulting hash function being digitally signed by the Originator's digital signature key and the signature being embedded in the file metadata or trailer along with the public signature key to be used for verification. In this embodiment, the validity of the Originator's public key can be established through a trusted out-of-band mechanism, e.g., an X.509 certificate that is signed by a trusted Certification Authority, or one or more public key or authorized Originators that are securely installed in the Guard Processor under the System Security officer's control. Through this means and apparatus, the authenticity of the ciphertext can be established without any necessity for the Guard Processor to require or even possess the ability to decrypt the information.
  • In some environments, the Recipient may not have received out-of-band confirmation of the Originator's public signature key, which might allow an attacker to substitute a bogus public key in the file metadata (trailer). In order to prevent this from occurring without detection, preferably the SPED includes the Originator's public signature key (as obtained from the file metadata) within the Key Derivation Function that is used by both the Originator and a Recipient to derive the Key Encrypting Key used to encrypt the File Encryption Key. If the Originator's public key were modified in the file, the Recipient would not be able to rederive the key necessary to decrypt the file, and the process would fail.
  • In another embodiment of the present invention, the Guard Processor function may be implemented in software on a user's HCD, and used to block or filter all information that has not been properly encrypted from being written to (or alternately read from) another mass encryption device or other media, unless it has been properly encrypted, in order to prevent the leakage of sensitive plaintext information.
  • ADDITIONAL SPED EMBODIMENTS
  • Numerous variations and additions to the SPED can be made, without departing from the scope of the invention.
  • Robust File-Based End-to-End Error Correction Means and Mechanism
  • Optionally, various forms of Forward Error Correction (FEC) may be included within the encoded structure of the encrypted file itself, logically after the file has been encrypted and hashed as part of the digital sealing mechanism. In order to minimize the latency involved, FEC may be applied while the file is being encrypted and the ciphertext hashed, all in a single pass. During the decryption process, any existing errors will be corrected prior to hashing the encrypted file and perform the decryption operation. As will be understood by those skilled in the art, various forms of Forward Error Correction can be applied, including but not limited to simple Reed-Solomon (255,233) code, wherein 233 bytes of data plus 32 bytes of parity information are encoded into a 255 byte block. Such a code can correct up to 16 short bursts of error. More complex coding techniques, such as Cross-Interleaved Reed-Solomon Coding (CIRC) technique used in Compact Disks can completely correct error bursts of up to 4000 bits. The use of such techniques can enable the complete recovery of encrypted messages that might otherwise be rendered completely unintelligible due to as little as a single bit error.
  • Provision of an Adjunct Enhanced Authentication Device
  • The SPED can be connected to an optional Enhanced Authentication Device (“EAD”), which contains a biometric fingerprint scanner that compares the fingerprint input data to fingerprint templates previously registered and stored within the SPED. This apparatus provides an additional authentication factor of “Who you are” to positively identify the user as the legitimate unique user, or one of a set of authorized users who has previously registered their fingerprints on the SPED to strongly and securely bind their identity as an authorized user to access the operations on the SPED.
  • In a further embodiment, the optional EAD takes the form of a covering sleeve and includes a secure PIN entry mechanism to allow the PIN or password to be entered directly into the SPED without the need to communicate the PIN over an external or unprotected communications channel.
  • User Authentication Combined with Proximity Detection
  • In another embodiment, the proximity of the authorized user to the SPED may be confirmed by means of an RFID tag, Bluetooth device, or other limited near-field or wireless communications mechanism that is normally worn on or attached to the user's person, and may be “paired” to either the SPED or the EAD, so that if the user leaves the immediate area of the SPED that condition will be sensed, and the user required to log on again before taking further actions with the SPED. Other sensors and more exotic applications could likewise be supported, including live finger determination, blood-alcohol content, two-man rule conditions, etc.
  • Extensions of the Authentication Mechanism to Fuzzy Multivariate Factors
  • In some cases, the normal mode of operation would be for the SPED to be used within limited geographical locus, e.g., within a corporate campus, and use outside of that locus would be prevented. Rather than storing the authorized locus and comparing it to the current position, with the risk that it might be possible to extract the authorized coordinates and determine how to spoof the device, in another embodiment this geographical locus can be managed by having the EAD determine the current geographical position, (e.g., from a GPS or Loran system, or by triangulation form cell phone towers or similar means), and then apply a coordinate transformation to effectively round both the X and Y coordinates to define a more limited precision locus. This “fuzzy” or limited-precision locus can then be used as one of the authentication and authorization parameters that are entered into the secret-sharing authentication algorithm at the time the SPED is initialized and the keys are generated, just as the user PIN, Host Authorization Code, an/or other authorization parameters are entered.
  • In yet another embodiment, the extension of the authentication and authorization parameters from what is effectively a precise, one-dimensional Host Authorization Code to a fuzzy two-dimensional geographic position locus can be extended to three or more dimensions, including altitude, time or day, or other multivariate coordinates. For example, many pattern matching algorithms used in biometric applications can be viewed as a multi-dimensional variation around a known point, which is determined by the biometric template or indicia. In this embodiment, the template would be entered into the secret-sharing authentication and authorization algorithm, and the allowable degree of deviation from that template would be implemented through the coordinate transformation and truncation or rounding algorithm, so that it would not be necessary to store the template itself for comparison where it could possibly be compromised. Those skilled in the art will recognize that it is desirable to ensure that a sufficient amount of entropy be provided during this process, so as to make it computationally infeasible to guess or exhaustively search for parameters that would satisfy the enhanced authentication/authorization criteria. This objective can be accomplished by combining a multiplicity of such parameters into a single split-knowledge share. If necessary, a random seed, serial number, or other variable that is unique to a particular enhanced authentication device may be hashed or otherwise combined with the relevant parameters in order to make it more difficult to mount an exhaustive search.
  • Extensions to Multiple Cryptographic or Application Partitions
  • In another further embodiment, the SPED is constructed with a multiplicity of logical cryptographic or application partitions, in order to permit sharing a single SPED among or between multiple users, as in a branch office, or engineering design or finance group, where each user can have access to their own unique private keys. In other cases, e.g., within a military or surveillance operation, multiple users of the same device can be authorized, each with their own PIN or password and optional biometric identifier, but the various users can all share access to a common set of decryption keys, for purposes of survivability. In that scenario, each user might or might not have unique digital signature keys.
  • In a similar embodiment, the SPED can be constructed with a multiplicity of logical cryptographic or application partitions, so that certain less sensitive applications can be performed without requiring the Host Authorization Code or other authorization parameters to be stored externally, while still requiring the HAC for the more sensitive applications. One such application would be the use of the SPED for pre-boot authentication of a Full Disk Encryption software or hardware application, where there is no secure location in which to store a HAC until the operating system has completed the boot process, and hence it would be desirable to use independent HACs for maximum security. Another such application would be the use of the SPED to access Multiple Independent Security Levels when dealing with a classified environment. One set of user PIN/password, HAC, and biometrics might authorize access to a host computer at the Unclassified level, another set at the SECRET level, and yet another set at the TOP SECRET level. If a particular user or SPED is not authorized to access the higher level security classifications, the HAC for that classified enclave security level would not be loaded onto the SPED by the Security Officer.
  • In yet another embodiment, a multiplicity of independent SPEDs, either with or without the capability of interfacing to a removable memory device, may be aggregated into a single physical device containing multiple SPED devices, all capable of functioning independently at different security levels, and connected to the HCD by a multi-pin plug and socket arrangement containing e.g., as many as 16 different connecting pins, as may be required to support the I/O requirements. Each SPED could then be dedicated to distinct security levels, e.g., Unclassified, CONFIDENTIAL, SECRET, and TOP SECRET, providing complete electrical as well as application and cryptographic separation between levels.
  • Interfaces to Other Media
  • In a further embodiment, the SPED may take the form of a digital media recorder/receiver or an “iPod” type device, which includes a large capacity micro disc hard drive or internal mass memory chip, and connects to the host computing device through a miniUSB or adapter cable connection, or wireless connection, depending upon the native interface of this SPED. A touch screen display may enable a keyboard to be presented to the user to provide a means for entering a PIN number directly into the SPED without transporting the PIN from an unprotected external device and communications channel.
  • In a further embodiment, a SPED apparatus is constructed and enabled to also perform one or more cryptographic operations on data that has been transmitted to the SPED by a remote wireless device by inclusion of a wireless transceiver, or input to the SPED by a person through a keyboard, or input to the SPED by another peripheral device (e.g., digital camera, disk storage module) through an additional secondary physical connector and communications port.
  • In another embodiment, the host computing device may be a programmable product such as laptop, desktop or UltraMobile PCs, a PDA cell phone, a digital audio or video recorder, a photographic camera or recorder, with an embedded microprocessor that supports applications software, peripheral device interfaces, and graphical user interfaces, and operates on digital data in any format (e.g., encoded alphanumeric, video, audio, photographic).
  • Use of the SPED for Biometric Authentication
  • The SPED 610 and an associated peripheral device driver may be implemented so that it is possible to use the functionality of the SPED, even without accessing any cryptographic processing functions of the SPED. Using the SPED in this way can be useful, for example, when the targeted functionality (referring to FIG. 6) is embodied as the secure PIN entry/biometric authentication device 620, previously described, that is used to perform user authentication. In particular, if device 620 is to be used as the mechanism to enter the user PIN in FIG. 7 step 704, operation in this mode may be necessary (depending on the capabilities of the biometric device) to enable such use of the biometric device.
  • The biometric authentication device is defined herein as any device that is adapted to receive input data regarding a physical characteristic of a person based upon a physical interaction of the person with the device. Biometric devices that can be used in a peripheral device can include, for example, a fingerprint-scanning device, a retinal scanning device, or a face print scanning device. A biometric device includes a sensor for sensing the physical characteristic, and an analog-to-digital converter to transform the analog data representing the sensed characteristic into digital data. For example, a fingerprint-scanning device includes a sensor upon which a person can place or swipe a finger, the sensor sensing the fingerprint of the finger, the content of the sensed fingerprint being converted into digital data by the device. Similarly, a retinal scanning device includes a sensor that can be placed proximate to a person's eye, the sensor sensing characteristics of the eye such as blood vessel pattern or iris pattern, the device translating the content of the sensed characteristics into digital data. The construction and operation of biometric devices in general, as well as those identified particularly above, is well understood by those skilled in that art, so that, together with an understanding of the required communication capability between the biometric sensor and the control processor 620, a biometric device for use with the invention can be easily operated. Fingerprint scanning devices and retinal and face print scanning devices that can readily be modified for use with the invention, i.e., to communicate with the control processor 620, are known to those skilled in that art.
  • In a further embodiment, the secure PIN/biometric device 620 contains a human input device 623 for scrolling through alphanumeric characters that are sequentially displayed on display screen 624. As each desired character appears on the display screen 624, a selection is made and the character is locked. After the correct sequence of characters is entered, they can be entered as the PIN, in one embodiment, by scrolling the thumbwheel to an “enter” position and pressing inward. The secure PIN entry is transferred to the SPED cryptographic processing configuration modules 611, 612, and 613 via control processor 621 and EO modules 625 and 616 to determine authentication approval by matching the stored PIN data.
  • If biometric approval is also required as an authentication procedure, the biometric scanner 622 may be used to scan the user's biometric fingerprint data into the SPED control processor 621 according to the particular instructions and settings of the scanner parameters. If a correct match is made after comparing the biometric data to an appropriate library of biometric data representing a predetermined group of people (e.g., authorized users) stored within the processor 621, the resultant user authentication approval is sent from the control processor 621 via EO modules 625 and 616 to the SPED microprocessor 611. (Of course, in this case, user authentication is used as part of the step 714). Again, eventually, use of the SPED device ends (step 719).
  • Embodiments Utilizing Wireless Communications
  • A further system embodiment 922 is illustrated in FIG. 9. In this configuration 922, the HCD 915 is similar to that presented in FIG. 5 and can take the form of some portable form factor physical configuration for a PC, a PDA phone, a smartphone or other such similar devices. The HCD 915 is comprised of a microprocessor 912, an internal memory 913, a computer bus 911 for interconnection of the internal components of the HCD 915, a data input mechanism for user input illustrated herein as a keyboard 914 which is connected to the HCD 915 through a USB input/output module and connector 910. Alternatively, a wireless connection can be used to interconnect a data input device 914 to the HCD 915. As previously described in FIG. 6, the host computing device executes the software modules 605, 606, 601, 602, and 607 necessary to interface with the secure portable encryption device and the secure portable encryption device mass memory. Referring to FIG. 9, the HCD 915 includes a wireless input/output module and connector 909 for communications to other devices using WLAN IEEE 802.11, Bluetooth, or such other wireless communications methods as may be adopted for industry use by handheld digital computer and communicating devices and host computing devices. Wireless communications is enabled by HCD 915 internal or external antenna 908.
  • Referring to FIG. 9, the secure portable encryption device 900 may be implemented in a form of digital data media recorder/receiver 900 containing an integrated or removable mass memory disc or mass memory chip module 901. This secure portable encryption device 900 also contains a control microprocessor 903, internal RAM memory 904, an internal communications bus 902, and input/output module and connector 906 which includes a wireless capability and is connected to internal or external antenna 907 through which communications is effected. Wireless communications can utilize a method such as Bluetooth, WLAN IEEE 802.11 protocols, or other methods adopted by industry providers. Wireless communications can be implemented using one of the industry security methods (e.g., WAP2 IEEE 802.11i, Bluetooth mutual authentication method for encryption key generation) for establishing a mutually authenticated ephemeral session encryption key between the HCD 915 and the SPED 900 in order to secure communications of critical security parameters that are exchanged between the HCD 915 and the SPED 900.
  • This configuration 922 may execute all security operations as have been previously described for occurring within the secure portable encryption device 900 for protection of the SPED memory 901 data by means of software stored in a partition 905 of the internal memory, or alternatively and not illustrated, in a separate EEROM memory connected to computer bus 902. The control microprocessor 903 processes all memory applications, initialization applications, generates the ephemeral polynomial curve from which the “N” shared secrets and Master Key Encryption Key (MKEK) are created, and performs the security processing operations necessary to cryptographically associate each shared secret with an external secret, (e.g., the user PIN, the security officer PIN, the unique identifier for the HCD, the identification of the specific secure portable security device), and all other cryptographic algorithms and related memory storage applications as are required and store such values in nonvolatile permanent memory of the SPED.
  • The system secret sharing means implemented by the SPED 900 control microprocessor 903 and security processing programs stored in memory 905 do not require static storage of the external secrets and the MKEK and thus provides the advantage of avoiding these vulnerabilities which are subject to brute force and other attacks. Installation and initialization software modules (not illustrated) as previously discussed may also be stored within the SPED 900 to be directly downloaded to a HCD 915 without the necessity of using a separate digital media, e.g., CD-ROM.
  • As previously discussed, user authentication can be implemented by PIN input through the data entry device 914 for the HCD 915, or, for additional levels of secure authentication, through a separate biometric and secure PIN entry device 916, configured in this embodiment in a USB flash memory portable form factor. Other form factors may also be implemented. The biometric authentication device 916 is connected to the host computing device through a USB connection 921 which mates with the USB input/output and connector module 910 on the HCD 915. The biometric authentication device 916 may be comprised of a biometric sensor depicted in FIG. 9 as a fingerprint sensor 917, a scrolling thumbwheel 918 for selection and input of the alphanumeric characters to compose the PIN, a display 920 to provide status to the user, and an internal control microprocessor 919 for execution of all operations.
  • The choice of algorithms and techniques for encryption/decryption, digital hashing, digital signing, and other related operations associated with these operations is not meant to be limited by this disclosure. Such choices are expected to change over time, due to new standards being set by governments and institutions and standards-making bodies for acceptance by all communities, and this invention is not limited, in implementation, to any one set of such cryptographic algorithms and techniques.
  • It is to be understood that the various configurations and embodiments of the system, methods, and apparatus which have been described are merely illustrative, not limitative, of an application of the principles. It will be apparent to one skilled in the art that numerous modifications may be made to the system configurations, methods, and apparatus described herein without departing from the scope of the claims set out below.

Claims (7)

What is claimed is:
1. An encryption device with file decryption controlled by a file encryption key, comprising:
an enclosure for the device, and
a cryptographic processor within the enclosure for reconstituting the file encryption key from a version of the file encryption key which has been shrouded with a network authorization code.
2. A method for file decryption comprising:
generating a network authorization code,
distributing the network authorization code to a community of interest through an out-of-band distribution mechanism,
shrouding a file encryption key with the network authorization code using an invertible transform,
receiving the network authorization code from a user,
causing a cryptographic processor to reconstitute the file encryption key from the received network authorization code, and
decrypting the file as a function of the reconstituted file encryption key.
3. The method of claim 2, where the invertible transform is XOR.
4. The method of claim 2, where the invertible transform is resistant to quantum computing attacks.
5. The method of claim 2, further comprising steps for encrypting the network authorization code and distributing the code to a recovery agent.
6. The device of claim 1, where the enclosure has a portable form factor.
7. A method for file decryption comprising steps for:
generating a network authorization code,
distributing the network authorization code to a community of interest through an out-of-band distribution mechanism,
shrouding a file encryption key with the network authorization code using an invertible transform,
receiving the network authorization code from a user,
causing a cryptographic processor to reconstitute the file encryption key from the received network authorization code, and
decrypting the file as a function of the reconstituted file encryption key
US14/697,627 2007-01-22 2015-04-28 Encryption device with configurable security functionality using network authorization code Abandoned US20160021068A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/697,627 US20160021068A1 (en) 2007-01-22 2015-04-28 Encryption device with configurable security functionality using network authorization code

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US88608707P 2007-01-22 2007-01-22
US12/018,094 US20080263363A1 (en) 2007-01-22 2008-01-22 Portable Data Encryption Device with Configurable Security Functionality and Method for File Encryption
US13/650,459 US9049010B2 (en) 2007-01-22 2012-10-12 Portable data encryption device with configurable security functionality and method for file encryption
US14/697,627 US20160021068A1 (en) 2007-01-22 2015-04-28 Encryption device with configurable security functionality using network authorization code

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13/650,459 Division US9049010B2 (en) 2007-01-22 2012-10-12 Portable data encryption device with configurable security functionality and method for file encryption

Publications (1)

Publication Number Publication Date
US20160021068A1 true US20160021068A1 (en) 2016-01-21

Family

ID=39873427

Family Applications (4)

Application Number Title Priority Date Filing Date
US12/018,094 Abandoned US20080263363A1 (en) 2007-01-22 2008-01-22 Portable Data Encryption Device with Configurable Security Functionality and Method for File Encryption
US13/650,459 Active - Reinstated US9049010B2 (en) 2007-01-22 2012-10-12 Portable data encryption device with configurable security functionality and method for file encryption
US14/697,627 Abandoned US20160021068A1 (en) 2007-01-22 2015-04-28 Encryption device with configurable security functionality using network authorization code
US14/697,900 Expired - Fee Related US9521123B2 (en) 2007-01-22 2015-04-28 Method for file encryption

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US12/018,094 Abandoned US20080263363A1 (en) 2007-01-22 2008-01-22 Portable Data Encryption Device with Configurable Security Functionality and Method for File Encryption
US13/650,459 Active - Reinstated US9049010B2 (en) 2007-01-22 2012-10-12 Portable data encryption device with configurable security functionality and method for file encryption

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/697,900 Expired - Fee Related US9521123B2 (en) 2007-01-22 2015-04-28 Method for file encryption

Country Status (4)

Country Link
US (4) US20080263363A1 (en)
EP (1) EP2122900A4 (en)
IL (2) IL199983A (en)
WO (1) WO2008147577A2 (en)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170214712A1 (en) * 2016-01-25 2017-07-27 Aol Inc. Compromised password detection based on abuse and attempted abuse
WO2018071195A1 (en) * 2016-10-14 2018-04-19 Alibaba Group Holding Limited Method and system for quantum key distribution based on trusted computing
US10154014B2 (en) 2015-08-21 2018-12-11 Alibaba Group Holding Limited Method and system for efficient encryption, transmission, and decryption of video data
US10164778B2 (en) 2016-12-15 2018-12-25 Alibaba Group Holding Limited Method and system for distributing attestation key and certificate in trusted computing
US10313115B2 (en) 2016-02-15 2019-06-04 Alibaba Group Holding Limited System and method for quantum key distribution
US10326591B2 (en) 2016-02-15 2019-06-18 Alibaba Group Holding Limited Efficient quantum key management
US10439806B2 (en) 2016-05-19 2019-10-08 Alibaba Group Holding Limited Method and system for secure data transmission
US10491383B2 (en) 2016-05-11 2019-11-26 Alibaba Group Holding Limited Method and system for detecting eavesdropping during data transmission
US10574446B2 (en) 2016-10-14 2020-02-25 Alibaba Group Holding Limited Method and system for secure data storage and retrieval
US10693635B2 (en) 2016-05-06 2020-06-23 Alibaba Group Holding Limited System and method for encryption and decryption based on quantum key distribution
US10841800B2 (en) 2017-04-19 2020-11-17 Alibaba Group Holding Limited System and method for wireless screen projection
US20200372159A1 (en) * 2017-11-30 2020-11-26 Bae Systems Plc Methods of decrypting disk images, and decryption-enabling devices
US10855452B2 (en) 2016-10-14 2020-12-01 Alibaba Group Holding Limited Method and system for data security based on quantum communication and trusted computing
US10951614B2 (en) 2017-03-30 2021-03-16 Alibaba Group Holding Limited Method and system for network security
US10985913B2 (en) 2017-03-28 2021-04-20 Alibaba Group Holding Limited Method and system for protecting data keys in trusted computing
US20210157747A1 (en) * 2019-11-26 2021-05-27 Samsung Electronics Co., Ltd. Memory controller, storage device including the same, and operating method of the memory controller
US11032069B2 (en) * 2018-11-07 2021-06-08 iStorage Limited Methods and systems of securely transferring data
US11074332B2 (en) 2017-09-05 2021-07-27 iStorage Limited Methods and systems of securely transferring data
US11258610B2 (en) 2018-10-12 2022-02-22 Advanced New Technologies Co., Ltd. Method and mobile terminal of sharing security application in mobile terminal
US11429519B2 (en) 2019-12-23 2022-08-30 Alibaba Group Holding Limited System and method for facilitating reduction of latency and mitigation of write amplification in a multi-tenancy storage drive

Families Citing this family (337)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1276033B1 (en) * 2001-07-10 2012-03-14 Trident Microsystems (Far East) Ltd. Memory device with data protection in a processor
CN100543691C (en) * 2005-04-20 2009-09-23 阿克萨纳(以色列)有限公司 Remote data mirroring system
WO2010079447A1 (en) * 2009-01-12 2010-07-15 Axxana (Israel) Ltd Disaster-proof data recovery
US9195397B2 (en) 2005-04-20 2015-11-24 Axxana (Israel) Ltd. Disaster-proof data recovery
US7447908B2 (en) * 2005-05-09 2008-11-04 Silverbrook Research Pty Ltd Method of authenticating a print medium offline
AU2009200408B2 (en) * 2006-09-12 2012-05-10 Cpc Patent Technologies Pty Ltd Password generator
KR100782113B1 (en) * 2006-11-13 2007-12-05 삼성전자주식회사 Memory card system and method transmitting host identification information thereof
EP2122900A4 (en) * 2007-01-22 2014-07-23 Spyrus Inc Portable data encryption device with configurable security functionality and method for file encryption
KR100841982B1 (en) * 2007-02-08 2008-06-27 삼성전자주식회사 Memory card storing host identification information and access method thereof
US20080226082A1 (en) * 2007-03-12 2008-09-18 Storage Appliance Corporation Systems and methods for secure data backup
US8756659B2 (en) * 2007-04-19 2014-06-17 At&T Intellectual Property I, L.P. Access authorization servers, methods and computer program products employing wireless terminal location
US7706750B2 (en) * 2007-05-07 2010-04-27 Dell Products L.P. Enabling bluetooth support within a secondary and/or across multiple operating system partitions
EP2009605A1 (en) * 2007-06-28 2008-12-31 Gemplus Method of interaction with physical elements forming the content of a machine
US8915447B2 (en) 2007-09-12 2014-12-23 Devicefidelity, Inc. Amplifying radio frequency signals
US9311766B2 (en) 2007-09-12 2016-04-12 Devicefidelity, Inc. Wireless communicating radio frequency signals
US20090069049A1 (en) 2007-09-12 2009-03-12 Devicefidelity, Inc. Interfacing transaction cards with host devices
US9304555B2 (en) 2007-09-12 2016-04-05 Devicefidelity, Inc. Magnetically coupling radio frequency antennas
US8070057B2 (en) 2007-09-12 2011-12-06 Devicefidelity, Inc. Switching between internal and external antennas
US11190936B2 (en) 2007-09-27 2021-11-30 Clevx, Llc Wireless authentication system
US10778417B2 (en) 2007-09-27 2020-09-15 Clevx, Llc Self-encrypting module with embedded wireless user authentication
US10783232B2 (en) * 2007-09-27 2020-09-22 Clevx, Llc Management system for self-encrypting managed devices with embedded wireless user authentication
US10181055B2 (en) 2007-09-27 2019-01-15 Clevx, Llc Data security system with encryption
EP2201456A4 (en) * 2007-10-08 2012-02-15 Axxana Israel Ltd Fast data recovery system
US8543831B2 (en) * 2007-11-14 2013-09-24 Qimonda Ag System and method for establishing data connections between electronic devices
DE102007058975B4 (en) * 2007-12-07 2022-10-06 Bayerische Motoren Werke Aktiengesellschaft Vehicle electrical system of a motor vehicle with a master security module
US20090164804A1 (en) * 2007-12-25 2009-06-25 Sandisk Il Ltd. Secured storage device
CN101174295B (en) * 2008-01-16 2010-09-01 北京飞天诚信科技有限公司 Off-line DRM authentication method and system
US7937387B2 (en) * 2008-02-01 2011-05-03 Mandiant System and method for data preservation and retrieval
US8271736B2 (en) * 2008-02-07 2012-09-18 International Business Machines Corporation Data block frequency map dependent caching
EP2259603B1 (en) * 2008-03-28 2015-04-08 Sharp Kabushiki Kaisha Remote operation device, device to be operated, control method for remote operation device, control method for device to be operated, and remote operation system
FR2931336B1 (en) * 2008-05-19 2011-02-11 Eads Secure Networks METHODS AND DEVICES FOR TRANSMITTING AND AUTHENTICATING MESSAGES TO GUARANTEE THE AUTHENTICITY OF A SYSTEM
EP2286343A4 (en) * 2008-05-19 2012-02-15 Axxana Israel Ltd Resilient data storage in the presence of replication faults and rolling disasters
GB2460412B (en) * 2008-05-28 2012-09-19 Hewlett Packard Development Co Information sharing
US8402111B2 (en) 2009-01-28 2013-03-19 Headwater Partners I, Llc Device assisted services install
US8406748B2 (en) 2009-01-28 2013-03-26 Headwater Partners I Llc Adaptive ambient services
US8548428B2 (en) 2009-01-28 2013-10-01 Headwater Partners I Llc Device group partitions and settlement platform
US8331901B2 (en) 2009-01-28 2012-12-11 Headwater Partners I, Llc Device assisted ambient services
US8391834B2 (en) 2009-01-28 2013-03-05 Headwater Partners I Llc Security techniques for device assisted services
US8626115B2 (en) 2009-01-28 2014-01-07 Headwater Partners I Llc Wireless network service interfaces
US8589541B2 (en) 2009-01-28 2013-11-19 Headwater Partners I Llc Device-assisted services for protecting network capacity
US8340634B2 (en) 2009-01-28 2012-12-25 Headwater Partners I, Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8346225B2 (en) 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8635335B2 (en) 2009-01-28 2014-01-21 Headwater Partners I Llc System and method for wireless network offloading
US8832777B2 (en) 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
US8275830B2 (en) 2009-01-28 2012-09-25 Headwater Partners I Llc Device assisted CDR creation, aggregation, mediation and billing
FR2933510B1 (en) * 2008-07-04 2010-10-15 Oberthur Technologies PORTABLE ELECTRONIC DEVICE COMPRISING A PORTABLE APPLICATION AND A SECURE MODULE THAT CAN COMMUNICATE BETWEEN THEM, AND ASSOCIATED COMMUNICATION METHOD
US8286171B2 (en) 2008-07-21 2012-10-09 Workshare Technology, Inc. Methods and systems to fingerprint textual information using word runs
US8204220B2 (en) * 2008-09-18 2012-06-19 Sony Corporation Simulcrypt key sharing with hashed keys
CN101685425A (en) * 2008-09-28 2010-03-31 联想(北京)有限公司 Mobile storage device and method of encrypting same
TWI525452B (en) * 2008-10-02 2016-03-11 美國博通公司 Secure virtual machine manager
WO2010059747A2 (en) 2008-11-18 2010-05-27 Workshare Technology, Inc. Methods and systems for exact data match filtering
KR20100067415A (en) * 2008-12-11 2010-06-21 삼성전자주식회사 Electronic device and method for controlling output
US8296554B2 (en) * 2008-12-30 2012-10-23 Intel Corporation Pre-boot recovery of a locked computer system
KR101029758B1 (en) * 2008-12-31 2011-04-19 노틸러스효성 주식회사 A method for firmware updating in remote
WO2010076755A2 (en) * 2009-01-05 2010-07-08 Axxana (Israel) Ltd Disaster-proof storage unit having transmission capabilities
US9286493B2 (en) * 2009-01-07 2016-03-15 Clevx, Llc Encryption bridge system and method of operation thereof
US10057775B2 (en) 2009-01-28 2018-08-21 Headwater Research Llc Virtualized policy and charging system
US10783581B2 (en) 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
US9571559B2 (en) 2009-01-28 2017-02-14 Headwater Partners I Llc Enhanced curfew and protection associated with a device group
US9954975B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Enhanced curfew and protection associated with a device group
US9253663B2 (en) 2009-01-28 2016-02-02 Headwater Partners I Llc Controlling mobile device communications on a roaming network based on device state
US10779177B2 (en) 2009-01-28 2020-09-15 Headwater Research Llc Device group partitions and settlement platform
US10237757B2 (en) 2009-01-28 2019-03-19 Headwater Research Llc System and method for wireless network offloading
US9270559B2 (en) 2009-01-28 2016-02-23 Headwater Partners I Llc Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow
US9706061B2 (en) 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US10264138B2 (en) 2009-01-28 2019-04-16 Headwater Research Llc Mobile device and service management
US10798252B2 (en) 2009-01-28 2020-10-06 Headwater Research Llc System and method for providing user notifications
US10484858B2 (en) 2009-01-28 2019-11-19 Headwater Research Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US9647918B2 (en) 2009-01-28 2017-05-09 Headwater Research Llc Mobile device and method attributing media services network usage to requesting application
US9351193B2 (en) 2009-01-28 2016-05-24 Headwater Partners I Llc Intermediate networking devices
US9755842B2 (en) 2009-01-28 2017-09-05 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US10064055B2 (en) 2009-01-28 2018-08-28 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US8745191B2 (en) 2009-01-28 2014-06-03 Headwater Partners I Llc System and method for providing user notifications
US10248996B2 (en) 2009-01-28 2019-04-02 Headwater Research Llc Method for operating a wireless end-user device mobile payment agent
US9955332B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
US10715342B2 (en) 2009-01-28 2020-07-14 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US10326800B2 (en) 2009-01-28 2019-06-18 Headwater Research Llc Wireless network service interfaces
US11218854B2 (en) 2009-01-28 2022-01-04 Headwater Research Llc Service plan design, user interfaces, application programming interfaces, and device management
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US10492102B2 (en) 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US9565707B2 (en) 2009-01-28 2017-02-07 Headwater Partners I Llc Wireless end-user device with wireless data attribution to multiple personas
US9578182B2 (en) 2009-01-28 2017-02-21 Headwater Partners I Llc Mobile device and service management
US9609510B2 (en) 2009-01-28 2017-03-28 Headwater Research Llc Automated credential porting for mobile devices
US9557889B2 (en) 2009-01-28 2017-01-31 Headwater Partners I Llc Service plan design, user interfaces, application programming interfaces, and device management
US8793758B2 (en) 2009-01-28 2014-07-29 Headwater Partners I Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9392462B2 (en) 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US9858559B2 (en) 2009-01-28 2018-01-02 Headwater Research Llc Network service plan design
US10841839B2 (en) 2009-01-28 2020-11-17 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US10200541B2 (en) 2009-01-28 2019-02-05 Headwater Research Llc Wireless end-user device with divided user space/kernel space traffic policy system
US8296564B2 (en) 2009-02-17 2012-10-23 Microsoft Corporation Communication channel access based on channel identifier and use policy
US8397051B2 (en) * 2009-02-23 2013-03-12 Autonomy, Inc. Hybrid hash tables
US20100215175A1 (en) * 2009-02-23 2010-08-26 Iron Mountain Incorporated Methods and systems for stripe blind encryption
US8090683B2 (en) * 2009-02-23 2012-01-03 Iron Mountain Incorporated Managing workflow communication in a distributed storage system
US8145598B2 (en) * 2009-02-23 2012-03-27 Iron Mountain Incorporated Methods and systems for single instance storage of asset parts
US8229509B2 (en) * 2009-02-27 2012-07-24 Microsoft Corporation Protective shroud for handheld device
DE102009013606B4 (en) * 2009-03-17 2013-11-07 Attila Landauer A storage device for preventing unauthorized use of data and methods for operating the same
US8539241B2 (en) 2009-03-25 2013-09-17 Pacid Technologies, Llc Method and system for securing communication
US8726032B2 (en) 2009-03-25 2014-05-13 Pacid Technologies, Llc System and method for protecting secrets file
US10447474B2 (en) * 2009-04-20 2019-10-15 Pure Storage, Inc. Dispersed data storage system data decoding and decryption
US8744071B2 (en) * 2009-04-20 2014-06-03 Cleversafe, Inc. Dispersed data storage system data encryption and encoding
JP5446453B2 (en) * 2009-04-30 2014-03-19 ソニー株式会社 Information processing apparatus, electronic signature generation system, electronic signature key generation method, information processing method, and program
US20100287382A1 (en) * 2009-05-07 2010-11-11 John Charles Gyorffy Two-factor graphical password for text password and encryption key generation
US8321688B2 (en) * 2009-06-12 2012-11-27 Microsoft Corporation Secure and private backup storage and processing for trusted computing and data services
US20100318782A1 (en) * 2009-06-12 2010-12-16 Microsoft Corporation Secure and private backup storage and processing for trusted computing and data services
US9734356B2 (en) * 2009-06-29 2017-08-15 Clevx, Llc Encrypting portable media system and method of operation thereof
CA2767115A1 (en) * 2009-07-01 2011-01-06 Mandar Patil Method for remotely controlling and monitoring the data produced on desktop software
US8914874B2 (en) * 2009-07-21 2014-12-16 Microsoft Corporation Communication channel claim dependent security precautions
US8509449B2 (en) 2009-07-24 2013-08-13 Microsoft Corporation Key protector for a storage volume using multiple keys
JP5521479B2 (en) * 2009-10-14 2014-06-11 富士通株式会社 Program, data storage device and data storage system
WO2011047717A1 (en) * 2009-10-21 2011-04-28 Jennifer Kate Schofield Method for securing and retrieving a data file
US8874929B2 (en) * 2009-10-27 2014-10-28 Lockheed Martin Corporation Cross domain discovery
WO2011067702A1 (en) 2009-12-02 2011-06-09 Axxana (Israel) Ltd. Distributed intelligent network
KR101714108B1 (en) 2009-12-04 2017-03-08 크라이프토그라피 리서치, 인코포레이티드 Verifiable, leak-resistant encryption and decryption
US9104252B2 (en) * 2010-02-12 2015-08-11 Microsoft Technology Licensing, Llc Assignment of control of peripherals of a computing device
US8312296B2 (en) 2010-03-10 2012-11-13 Dell Products L.P. System and method for recovering from an interrupted encryption and decryption operation performed on a volume
US8930713B2 (en) 2010-03-10 2015-01-06 Dell Products L.P. System and method for general purpose encryption of data
US9135471B2 (en) * 2010-03-10 2015-09-15 Dell Products L.P. System and method for encryption and decryption of data
US8429420B1 (en) * 2010-04-12 2013-04-23 Stephen Waller Melvin Time-based key management for encrypted information
US8275996B1 (en) 2010-04-12 2012-09-25 Stephen Waller Melvin Incremental encryption of stored information
US8812875B1 (en) 2010-04-12 2014-08-19 Stephen Melvin Virtual self-destruction of stored information
US8462955B2 (en) 2010-06-03 2013-06-11 Microsoft Corporation Key protectors based on online keys
WO2011159918A2 (en) * 2010-06-16 2011-12-22 Vasco Data Security, Inc. Mass storage device memory encryption methods, systems, and apparatus
US10025759B2 (en) 2010-11-29 2018-07-17 Workshare Technology, Inc. Methods and systems for monitoring documents exchanged over email applications
US11030163B2 (en) 2011-11-29 2021-06-08 Workshare, Ltd. System for tracking and displaying changes in a set of related electronic documents
US10783326B2 (en) 2013-03-14 2020-09-22 Workshare, Ltd. System for tracking changes in a collaborative document editing environment
US8634563B2 (en) 2010-12-17 2014-01-21 Microsoft Corporation Attribute based encryption using lattices
US8972746B2 (en) * 2010-12-17 2015-03-03 Intel Corporation Technique for supporting multiple secure enclaves
EP2474931A1 (en) * 2010-12-31 2012-07-11 Gemalto SA System providing an improved skimming resistance for an electronic identity document.
GB2486920A (en) * 2010-12-31 2012-07-04 Daniel Cvrcek USB data storage and generation device connected to a host computer as or as an interface to a Human Interface Device
US8516609B2 (en) * 2011-02-11 2013-08-20 Bank Of America Corporation Personal encryption device
US8595507B2 (en) 2011-02-16 2013-11-26 Novell, Inc. Client-based authentication
US9231943B2 (en) 2011-02-16 2016-01-05 Novell, Inc. Client-based authentication
US9154826B2 (en) 2011-04-06 2015-10-06 Headwater Partners Ii Llc Distributing content and service launch objects to mobile devices
US9235532B2 (en) * 2011-06-03 2016-01-12 Apple Inc. Secure storage of full disk encryption keys
US9170990B2 (en) 2013-03-14 2015-10-27 Workshare Limited Method and system for document retrieval with selective document comparison
US10880359B2 (en) 2011-12-21 2020-12-29 Workshare, Ltd. System and method for cross platform document sharing
US10963584B2 (en) 2011-06-08 2021-03-30 Workshare Ltd. Method and system for collaborative editing of a remotely stored document
US10574729B2 (en) 2011-06-08 2020-02-25 Workshare Ltd. System and method for cross platform document sharing
US9948676B2 (en) 2013-07-25 2018-04-17 Workshare, Ltd. System and method for securing documents prior to transmission
US9613340B2 (en) 2011-06-14 2017-04-04 Workshare Ltd. Method and system for shared document approval
US8817976B2 (en) * 2011-06-24 2014-08-26 Gregory Scott Callen Reversible cipher
GB201111554D0 (en) * 2011-07-06 2011-08-24 Business Partners Ltd Search index
EP2732397B1 (en) * 2011-07-12 2020-02-26 Hewlett-Packard Development Company, L.P. Computing device including a port and a guest domain
US10102383B2 (en) * 2011-08-19 2018-10-16 Quintessencelabs Pty Ltd. Permanently erasing mechanism for encryption information
WO2013033424A1 (en) * 2011-08-31 2013-03-07 AppCard, Inc. Apparatus and method for collecting and manipulating transaction data
US9811667B2 (en) * 2011-09-21 2017-11-07 Mcafee, Inc. System and method for grouping computer vulnerabilities
US8479021B2 (en) * 2011-09-29 2013-07-02 Pacid Technologies, Llc Secure island computing system and method
US8649820B2 (en) 2011-11-07 2014-02-11 Blackberry Limited Universal integrated circuit card apparatus and related methods
CN104396181B (en) * 2012-02-09 2018-02-23 爱迪德技术有限公司 system and method for generating and protecting cryptographic key
DE102013203357B4 (en) * 2012-03-01 2022-01-20 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) METHOD OF ESTABLISHING COMMUNICATION BETWEEN DEVICES IN A VEHICLE
EP2634993B1 (en) * 2012-03-01 2017-01-11 Certicom Corp. Devices and methods for connecting client devices to a network
US8936199B2 (en) 2012-04-13 2015-01-20 Blackberry Limited UICC apparatus and related methods
USD703208S1 (en) 2012-04-13 2014-04-22 Blackberry Limited UICC apparatus
USD701864S1 (en) 2012-04-23 2014-04-01 Blackberry Limited UICC apparatus
US9021255B1 (en) * 2012-06-29 2015-04-28 Emc Corporation Techniques for multiple independent verifications for digital certificates
US9996480B2 (en) * 2012-07-18 2018-06-12 Analog Devices, Inc. Resilient device authentication system with metadata binding
US9904788B2 (en) * 2012-08-08 2018-02-27 Amazon Technologies, Inc. Redundant key management
AU2013216623B2 (en) * 2012-08-16 2018-07-05 Berkeley Information Technology Pty Ltd A device configured to manage secure ingestion of documents into an information system, and methods for operating such a device
ES2912265T3 (en) * 2012-08-30 2022-05-25 Triad Nat Security Llc Multi-factor authentication using quantum communication
US9390280B2 (en) * 2012-09-16 2016-07-12 Angel Secure Networks, Inc. System and method for obtaining keys to access protected information
EP2912588A4 (en) 2012-10-25 2016-06-29 Intel Corp Anti-theft in firmware
CN103793819B (en) * 2012-10-31 2017-12-19 天地融科技股份有限公司 transaction system and method
US9357382B2 (en) * 2012-10-31 2016-05-31 Intellisist, Inc. Computer-implemented system and method for validating call connections
US8806200B2 (en) * 2012-11-30 2014-08-12 Prakash Baskaran Method and system for securing electronic data
US8897450B2 (en) * 2012-12-19 2014-11-25 Verifyle, Inc. System, processing device, computer program and method, to transparently encrypt and store data objects such that owners of the data object and permitted viewers are able to view decrypted data objects after entering user selected passwords
US9076018B2 (en) 2012-12-19 2015-07-07 Clevx, Llc Encryption key generation in encrypted storage devices
US9026888B2 (en) * 2012-12-21 2015-05-05 Intel Corporation Method, system and apparatus for providing access to error correction information
EP2951746B1 (en) * 2013-01-29 2019-10-30 BlackBerry Limited System and method of enhancing security of a wireless device through usage pattern detection
WO2014129378A1 (en) * 2013-02-20 2014-08-28 株式会社ソニー・コンピュータエンタテインメント Character string input system
US11567907B2 (en) 2013-03-14 2023-01-31 Workshare, Ltd. Method and system for comparing document versions encoded in a hierarchical representation
US8949960B2 (en) * 2013-03-15 2015-02-03 Google Inc. Privacy preserving knowledge and factor possession tests for persistent authentication
JP5859484B2 (en) * 2013-05-31 2016-02-10 京セラドキュメントソリューションズ株式会社 Image forming apparatus, file browsing control system, and image forming method
JP6211818B2 (en) * 2013-06-11 2017-10-11 株式会社東芝 COMMUNICATION DEVICE, COMMUNICATION METHOD, PROGRAM, AND COMMUNICATION SYSTEM
WO2015004327A1 (en) * 2013-07-08 2015-01-15 Tuukka Korhonen Method and device for file encryption
US9369289B1 (en) 2013-07-17 2016-06-14 Google Inc. Methods and systems for performing secure authenticated updates of authentication credentials
US10911492B2 (en) 2013-07-25 2021-02-02 Workshare Ltd. System and method for securing documents prior to transmission
US9684805B2 (en) * 2013-08-20 2017-06-20 Janus Technologies, Inc. Method and apparatus for securing computer interfaces
US10769028B2 (en) 2013-10-16 2020-09-08 Axxana (Israel) Ltd. Zero-transaction-loss recovery for database systems
US9342331B2 (en) 2013-10-21 2016-05-17 International Business Machines Corporation Secure virtualized mobile cellular device
US10354084B2 (en) * 2013-10-28 2019-07-16 Sepior Aps System and a method for management of confidential data
WO2015071707A1 (en) 2013-11-15 2015-05-21 Here Global B.V. Security operations for wireless devices
CN104658073A (en) * 2013-11-20 2015-05-27 鸿富锦精密工业(武汉)有限公司 Iris key and method for unlocking electronic apparatus therewith
US20150172920A1 (en) * 2013-12-16 2015-06-18 Mourad Ben Ayed System for proximity based encryption and decryption
US9495546B2 (en) 2013-12-31 2016-11-15 Vasco Data Security, Inc. Electronic signing methods, systems, and apparatus
EP2905922A1 (en) * 2014-02-10 2015-08-12 Thomson Licensing Signing method delivering a partial signature associated to a message, threshold signing method, signature verification method, and corresponding computer program and electronic devices
JP6359285B2 (en) * 2014-02-17 2018-07-18 株式会社東芝 Quantum key distribution apparatus, quantum key distribution system, and quantum key distribution method
WO2015142765A1 (en) 2014-03-17 2015-09-24 Coinbase, Inc Bitcoin host computer system
US10298555B2 (en) * 2014-04-04 2019-05-21 Zettaset, Inc. Securing files under the semi-trusted user threat model using per-file key encryption
US10873454B2 (en) 2014-04-04 2020-12-22 Zettaset, Inc. Cloud storage encryption with variable block sizes
US10043029B2 (en) 2014-04-04 2018-08-07 Zettaset, Inc. Cloud storage encryption
WO2015153698A2 (en) * 2014-04-05 2015-10-08 Azoulai Avi Secured private network and storage device
US11423169B1 (en) * 2014-04-14 2022-08-23 Goknown Llc System, method and apparatus for securely storing data on public networks
US9825925B2 (en) * 2014-06-11 2017-11-21 Bijit Hore Method and apparatus for securing sensitive data in a cloud storage system
US20150382190A1 (en) * 2014-06-25 2015-12-31 Qualcomm Incorporated Enhanced secure identity generation
GB2513260B (en) * 2014-06-27 2018-06-13 PQ Solutions Ltd System and method for quorum-based data recovery
US10083311B2 (en) * 2014-06-30 2018-09-25 Konica Minolta Laboratory U.S.A., Inc. Cryptographic key
US9378383B2 (en) 2014-08-21 2016-06-28 Seagate Technology Llc Location based disk drive access
US10721062B2 (en) 2014-09-24 2020-07-21 Hewlett Packard Enterprise Development Lp Utilizing error correction for secure secret sharing
US9526032B2 (en) * 2014-09-26 2016-12-20 Apple Inc. Network bandwidth sharing for small mobile devices
US9774591B2 (en) 2014-10-15 2017-09-26 Airbnb, Inc. Password manipulation for secure account creation and verification through third-party servers
US10326590B2 (en) * 2014-11-11 2019-06-18 Intel Corporation Technologies for trusted device on-boarding
TWI570711B (en) * 2014-12-12 2017-02-11 魏如隆 Dynamic spectrum audio encryption device and method thereof
US11182551B2 (en) 2014-12-29 2021-11-23 Workshare Ltd. System and method for determining document version geneology
US10133723B2 (en) 2014-12-29 2018-11-20 Workshare Ltd. System and method for determining document version geneology
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
CN107251479B (en) * 2015-02-20 2020-08-11 三菱电机株式会社 Data storage device and data processing method
CN107409274B (en) 2015-03-06 2020-09-15 苹果公司 Determining when to establish a connection between a mobile client and a proxy device
WO2016145454A1 (en) * 2015-03-12 2016-09-15 Wiacts, Inc. Multi-factor user authentication
EP3070900A1 (en) * 2015-03-16 2016-09-21 Thomson Licensing Method and system of access of a mobile terminal to information in an area
US9565169B2 (en) * 2015-03-30 2017-02-07 Microsoft Technology Licensing, Llc Device theft protection associating a device identifier and a user identifier
CN106161402B (en) * 2015-04-22 2019-07-16 阿里巴巴集团控股有限公司 Encryption equipment key injected system, method and device based on cloud environment
US9735958B2 (en) * 2015-05-19 2017-08-15 Coinbase, Inc. Key ceremony of a security system forming part of a host computer for cryptographic transactions
US11283604B2 (en) * 2015-05-29 2022-03-22 Microsoft Technology Licensing, Llc Sharing encrypted data with enhanced security by removing unencrypted metadata
US10122767B2 (en) 2015-05-29 2018-11-06 Nagravision S.A. Systems and methods for conducting secure VOIP multi-party calls
US9900769B2 (en) 2015-05-29 2018-02-20 Nagravision S.A. Methods and systems for establishing an encrypted-audio session
US9891882B2 (en) 2015-06-01 2018-02-13 Nagravision S.A. Methods and systems for conveying encrypted data to a communication device
US10379958B2 (en) 2015-06-03 2019-08-13 Axxana (Israel) Ltd. Fast archiving for database systems
US10356059B2 (en) 2015-06-04 2019-07-16 Nagravision S.A. Methods and systems for communication-session arrangement on behalf of cryptographic endpoints
EP3119031A1 (en) * 2015-07-16 2017-01-18 ABB Schweiz AG Encryption scheme using multiple parties
US11763013B2 (en) 2015-08-07 2023-09-19 Workshare, Ltd. Transaction document management system and method
US11329980B2 (en) * 2015-08-21 2022-05-10 Veridium Ip Limited System and method for biometric protocol standards
HK1204847A2 (en) * 2015-09-16 2015-12-04 英基科技有限公司 A time card punching system
US9852300B2 (en) * 2015-09-25 2017-12-26 Saife, Inc. Secure audit logging
US10044514B1 (en) * 2015-09-25 2018-08-07 Xilinx, Inc. Secure external key storage for programmable ICS
CN105224848B (en) * 2015-10-15 2019-06-21 京东方科技集团股份有限公司 A kind of equipment authentication method, apparatus and system
US10387636B2 (en) * 2015-10-20 2019-08-20 Vivint, Inc. Secure unlock of a device
US11115393B2 (en) * 2015-10-27 2021-09-07 Line Corporation Message server, method for operating message server and computer-readable recording medium
KR101777698B1 (en) * 2015-10-27 2017-09-12 라인 가부시키가이샤 User terminal, method and computer for receiving and sending messages
US10380070B2 (en) * 2015-11-12 2019-08-13 International Business Machines Corporation Reading and writing a header and record on tape
CN105515764B (en) * 2015-12-08 2019-06-07 北京元心科技有限公司 A kind of method and apparatus for protecting key safety in the terminal
US10559902B2 (en) 2016-01-04 2020-02-11 International Business Machines Corporation Electrical connection management using a card
US9515401B1 (en) 2016-01-04 2016-12-06 International Business Machines Corporation Elastomeric electrical connector structure joining two hardware planes at right angles to each other
GB2562923B (en) * 2016-01-04 2020-02-12 Clevx Llc Data security system with encryption
US20170230352A1 (en) * 2016-02-06 2017-08-10 Xiaoqing Chen Method and System for Securing Data
WO2017151080A1 (en) * 2016-03-03 2017-09-08 Сэргий Валэрийовыч АРТЭМЭНКО Personal identification system
JP6728799B2 (en) * 2016-03-11 2020-07-22 日本電気株式会社 Cryptographic communication system, cryptographic communication method, security chip, communication device, control method thereof, and control program
US10230522B1 (en) 2016-03-24 2019-03-12 Amazon Technologies, Inc. Network access control
ES2951417T3 (en) * 2016-04-01 2023-10-20 Telefonica Cybersecurity & Cloud Tech S L U Procedure and system to protect a computer file against possible encryption by malicious software
US9590958B1 (en) 2016-04-14 2017-03-07 Wickr Inc. Secure file transfer
CN105844120B (en) * 2016-05-05 2019-06-14 北京元心科技有限公司 A kind of method and system of integrated Encryption Algorithm
US10289835B1 (en) * 2016-06-13 2019-05-14 EMC IP Holding Company LLC Token seed protection for multi-factor authentication systems
US20170372085A1 (en) * 2016-06-28 2017-12-28 HGST Netherlands B.V. Protecting data in a storage device
US20180034787A1 (en) * 2016-08-01 2018-02-01 Vormetric, Inc. Data encryption key sharing for a storage system
WO2018029464A1 (en) * 2016-08-08 2018-02-15 Record Sure Limited A method of generating a secure record of a conversation
WO2018031702A1 (en) * 2016-08-10 2018-02-15 Nextlabs, Inc. Sharing encrypted documents within and outside an organization
US10621351B2 (en) 2016-11-01 2020-04-14 Raptor Engineering, LLC. Systems and methods for tamper-resistant verification of firmware with a trusted platform module
US10191818B2 (en) * 2016-11-14 2019-01-29 Sap Se Filtered replication of data in distributed system of data centers
US10404667B2 (en) * 2016-11-17 2019-09-03 Bank Of America Corporation Secure, autonomous file encryption and decryption
WO2018137225A1 (en) * 2017-01-25 2018-08-02 深圳市汇顶科技股份有限公司 Fingerprint data processing method and processing apparatus
US9992022B1 (en) 2017-02-06 2018-06-05 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes
CN107070881B (en) * 2017-02-20 2020-11-27 北京古盘创世科技发展有限公司 Key management method, system and user terminal
US10360359B2 (en) * 2017-03-07 2019-07-23 International Business Machines Corporation Enabling single finger tap user authentication and application launch and login using fingerprint scanning on a display screen
US10592326B2 (en) 2017-03-08 2020-03-17 Axxana (Israel) Ltd. Method and apparatus for data loss assessment
WO2018194634A1 (en) * 2017-04-21 2018-10-25 Hewlett-Packard Development Company, L.P. Encryption key shares to different devices for rendering
US10505723B1 (en) 2017-04-26 2019-12-10 Wells Fargo Bank, N.A. Secret sharing information management and security system
US10211979B2 (en) * 2017-05-19 2019-02-19 Swfl, Inc. Systems and methods securing an autonomous device
CN110650675B (en) * 2017-05-22 2022-12-06 贝克顿·迪金森公司 System, apparatus and method for secure wireless pairing between two devices using embedded out-of-band key generation
US10536445B1 (en) 2017-06-12 2020-01-14 Daniel Maurice Lerner Discrete blockchain and blockchain communications
US10154015B1 (en) 2017-06-12 2018-12-11 Ironclad Encryption Corporation Executable coded cipher keys
US10171435B1 (en) 2017-06-12 2019-01-01 Ironclad Encryption Corporation Devices that utilize random tokens which direct dynamic random access
US10764282B2 (en) 2017-06-12 2020-09-01 Daniel Maurice Lerner Protected and secured user-wearable devices for assured authentication and validation of data storage and transmission that utilize securitized containers
US10158613B1 (en) 2017-06-12 2018-12-18 Ironclad Encryption Corporation Combined hidden dynamic random-access devices utilizing selectable keys and key locators for communicating randomized data together with sub-channels and coded encryption keys
EP3639502A4 (en) 2017-06-12 2020-11-25 Daniel Maurice Lerner Securitization of temporal digital communications with authentication and validation of user and access devices
US10645070B2 (en) 2017-06-12 2020-05-05 Daniel Maurice Lerner Securitization of temporal digital communications via authentication and validation for wireless user and access devices
US10154016B1 (en) 2017-06-12 2018-12-11 Ironclad Encryption Corporation Devices for transmitting and communicating randomized data utilizing sub-channels
US10623384B2 (en) 2017-06-12 2020-04-14 Daniel Maurice Lerner Combined hidden dynamic random-access devices utilizing selectable keys and key locators for communicating randomized data together with sub-channels and coded encryption keys
US10154031B1 (en) 2017-06-12 2018-12-11 Ironclad Encryption Corporation User-wearable secured devices provided assuring authentication and validation of data storage and transmission
US10650139B2 (en) 2017-06-12 2020-05-12 Daniel Maurice Lerner Securing temporal digital communications via authentication and validation for wireless user and access devices with securitized containers
US10616192B2 (en) 2017-06-12 2020-04-07 Daniel Maurice Lerner Devices that utilize random tokens which direct dynamic random access
WO2018231703A1 (en) 2017-06-12 2018-12-20 Daniel Maurice Lerner Securitization of temporal digital communications via authentication and validation for wireless user and access devices
CN107483192B (en) * 2017-08-25 2020-08-11 科华恒盛股份有限公司 Data transmission method and device based on quantum communication
US11677743B2 (en) * 2017-09-28 2023-06-13 Fortinet, Inc. Ethernet key
JP6818220B2 (en) * 2017-10-19 2021-01-20 三菱電機株式会社 Key sharing device, key sharing method and key sharing program
CN107908932B (en) * 2017-12-10 2020-10-13 吕文华 Digital currency anti-counterfeiting and verification method, system and equipment based on L algorithm
US9990504B1 (en) 2017-12-18 2018-06-05 Northern Trust Corporation Systems and methods for generating and maintaining immutable digital meeting records within distributed network nodes
JP6943196B2 (en) * 2018-02-05 2021-09-29 日本電信電話株式会社 Control system and control method
WO2019157503A1 (en) 2018-02-12 2019-08-15 Massachusetts Institute Of Technology Systems and methods for providing secure communications using a protocol engine
US10212599B1 (en) * 2018-02-19 2019-02-19 Nxp B.V. Method for preventing unauthorized use of electronic accessories
US11277421B2 (en) * 2018-02-20 2022-03-15 Citrix Systems, Inc. Systems and methods for detecting and thwarting attacks on an IT environment
US11115216B2 (en) * 2018-03-20 2021-09-07 Micro Focus Llc Perturbation-based order preserving pseudonymization of data
US10673626B2 (en) * 2018-03-30 2020-06-02 Spyrus, Inc. Threshold secret share authentication proof and secure blockchain voting with hardware security modules
US11409878B2 (en) 2018-05-31 2022-08-09 Hewlett-Packard Development Company, L.P. Trusted sequence for computing devices via hashes
US11627132B2 (en) * 2018-06-13 2023-04-11 International Business Machines Corporation Key-based cross domain registration and authorization
US10708050B2 (en) * 2018-06-19 2020-07-07 TokenEx, LLC Multivariate encryption systems and methods
US10484770B1 (en) 2018-06-26 2019-11-19 Amazon Technologies, Inc. Display device with transverse planar microphone arrays
FR3085815B1 (en) * 2018-07-11 2022-07-15 Ledger SECURITY GOVERNANCE OF THE PROCESSING OF A DIGITAL REQUEST
US11449586B2 (en) 2018-07-20 2022-09-20 Massachusetts Institute Of Technology Authenticated intention
CN108900552B (en) * 2018-08-16 2019-10-15 北京海泰方圆科技股份有限公司 Cryptographic key distribution method and device, key acquisition method and device
US11171953B2 (en) 2018-08-16 2021-11-09 Hewlett Packard Enterprise Development Lp Secret sharing-based onboarding authentication
US11188719B1 (en) 2018-10-22 2021-11-30 Wells Fargo Bank, N.A. Predictive text system
EP3654576B1 (en) * 2018-11-16 2021-07-28 Siemens Aktiengesellschaft Computer-implemented method for error-correction-encoding and encrypting of a file
US11140139B2 (en) * 2018-11-21 2021-10-05 Microsoft Technology Licensing, Llc Adaptive decoder selection for cryptographic key generation
US10938574B2 (en) * 2018-11-26 2021-03-02 T-Mobile Usa, Inc. Cryptographic font script with integrated signature for verification
US11316144B1 (en) 2018-12-13 2022-04-26 Amazon Technologies, Inc. Lithium-ion batteries with solid electrolyte membranes
US11394543B2 (en) 2018-12-13 2022-07-19 Coinbase, Inc. System and method for secure sensitive data storage and recovery
CN109992994A (en) * 2019-03-04 2019-07-09 众安信息技术服务有限公司 A kind of personnel file management method and system based on block chain
US10951415B2 (en) * 2019-03-13 2021-03-16 Digital 14 Llc System, method, and computer program product for implementing zero round trip secure communications based on noisy secrets with a polynomial secret sharing scheme
US11240026B2 (en) * 2019-05-16 2022-02-01 Blackberry Limited Devices and methods of managing data
US11347859B2 (en) * 2019-08-01 2022-05-31 Dell Products L.P. Systems and methods for leveraging authentication for cross operating system single sign on (SSO) capabilities
WO2021022246A1 (en) 2019-08-01 2021-02-04 Coinbase, Inc. Systems and methods for generating signatures
US11316839B2 (en) 2019-08-19 2022-04-26 Red Hat, Inc. Proof-of-work key wrapping for temporally restricting data access
US11303437B2 (en) * 2019-08-19 2022-04-12 Red Hat, Inc. Proof-of-work key wrapping with key thresholding
US11411938B2 (en) 2019-08-19 2022-08-09 Red Hat, Inc. Proof-of-work key wrapping with integrated key fragments
US11271734B2 (en) 2019-08-19 2022-03-08 Red Hat, Inc. Proof-of-work key wrapping for verifying device capabilities
US11424920B2 (en) * 2019-08-19 2022-08-23 Red Hat, Inc. Proof-of-work key wrapping for cryptographically controlling data access
US11436352B2 (en) 2019-08-19 2022-09-06 Red Hat, Inc. Proof-of-work key wrapping for restricting data execution based on device capabilities
US11411728B2 (en) * 2019-08-19 2022-08-09 Red Hat, Inc. Proof-of-work key wrapping with individual key fragments
US11212082B2 (en) * 2019-09-30 2021-12-28 Pq Solutions Limited Ciphertext based quorum cryptosystem
WO2021076868A1 (en) * 2019-10-16 2021-04-22 Coinbase, Inc. Systems and methods for re-using cold storage keys
US11328080B2 (en) * 2019-11-18 2022-05-10 Frostbyte, Llc Cryptographic key management
CN112861144B (en) * 2019-11-28 2022-06-07 深圳信息职业技术学院 Data encryption and decryption method, device and computer readable storage medium
EP3860035A1 (en) 2020-01-29 2021-08-04 Sebastien Armleder Storing and determining a data element
US11258602B2 (en) * 2020-02-26 2022-02-22 Amera IoT Inc. Method and apparatus for secure private key storage on IoT device
US10817590B1 (en) * 2020-02-26 2020-10-27 Amera IoT Inc. Method and apparatus for creating and using quantum resistant keys
US11271911B2 (en) 2020-02-26 2022-03-08 Amera Lot Inc. Method and apparatus for imprinting private key on IoT
US11256783B2 (en) * 2020-02-26 2022-02-22 Amera IoT Inc. Method and apparatus for simultaneous key generation on device and server for secure communication
US11563568B2 (en) 2020-02-27 2023-01-24 Comcast Cable Communications, Llc Scalable content restriction
US11223470B1 (en) 2020-03-06 2022-01-11 Wells Fargo Bank, N.A. Post-quantum cryptography side chain
US11483141B2 (en) 2020-06-03 2022-10-25 Capital One Services, Llc Key broker for a network monitoring device, and applications thereof
US11349647B2 (en) 2020-06-03 2022-05-31 Capital One Services, Llc Key broker for a network monitoring device, and applications thereof
EP4162668A1 (en) * 2020-06-03 2023-04-12 Capital One Services, LLC A network monitoring device, and applications thereof
US11336542B2 (en) 2020-06-03 2022-05-17 Capital One Services, Llc Network packet capture manager
US20210406851A1 (en) * 2020-06-25 2021-12-30 Ncr Corporation Zero Client Self-Service Terminal (SST) with Middleware Delivered Services
US20220209944A1 (en) * 2020-12-30 2022-06-30 John A. Nix Secure Server Digital Signature Generation For Post-Quantum Cryptography Key Encapsulations
US11461084B2 (en) 2021-03-05 2022-10-04 EMC IP Holding Company LLC Optimizing docker image encryption—kubernetes using shamir secrets to enforce multiple constraints in container runtime environment
US11792645B2 (en) 2021-03-10 2023-10-17 Qualcomm Incorporated Authenticating plaintext and ciphertext in a vehicle-to-everything (V2X) message
TW202236873A (en) * 2021-03-10 2022-09-16 美商高通公司 Authenticating plaintext and ciphertext in a vehicle-to-everything (v2x) message
US20220303137A1 (en) * 2021-03-17 2022-09-22 Apple Inc. Pairing protocol for peripherals with a secure function
US11610004B2 (en) * 2021-04-14 2023-03-21 Bank Of America Corporation System for implementing enhanced file encryption technique
CN113179161B (en) * 2021-04-22 2022-11-08 平安消费金融有限公司 Method and device for replacing secret key, computer equipment and storage medium
IT202100016706A1 (en) * 2021-06-25 2022-12-25 Epityon S R L S Integral password recovery method without clear storage with verification system
GB2608435B (en) * 2021-07-02 2023-07-12 Worldr Tech Limited System and method for managing transparent data encryption of database
GB2606782A (en) * 2021-10-19 2022-11-23 Istorage Ltd Portable encryption device
US11706225B1 (en) 2022-05-02 2023-07-18 Bank Of America Corporation System for source independent but source value dependent transfer monitoring
CN115694817B (en) * 2022-10-27 2023-07-14 亿铸科技(杭州)有限责任公司 Method and device for improving internal data security of in-memory computing chip
CN116089986B (en) * 2023-04-07 2023-08-25 深圳天谷信息科技有限公司 Electronic document management method, device, equipment and medium capable of configuring security policy

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134660A (en) * 1997-06-30 2000-10-17 Telcordia Technologies, Inc. Method for revoking computer backup files using cryptographic techniques
US20020186848A1 (en) * 2001-05-03 2002-12-12 Cheman Shaik Absolute public key cryptographic system and method surviving private-key compromise with other advantages
US20030046572A1 (en) * 2001-08-30 2003-03-06 Newman Aaron Charles Cryptographic infrastructure for encrypting a database
US20050240591A1 (en) * 2004-04-21 2005-10-27 Carla Marceau Secure peer-to-peer object storage system
US7000108B1 (en) * 2000-05-02 2006-02-14 International Business Machines Corporation System, apparatus and method for presentation and manipulation of personal information syntax objects
US7590236B1 (en) * 2004-06-04 2009-09-15 Voltage Security, Inc. Identity-based-encryption system
US7814318B1 (en) * 2005-09-27 2010-10-12 Oracle America, Inc. Scalable file system configured to make files permanently unreadable

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5677953A (en) * 1993-09-14 1997-10-14 Spyrus, Inc. System and method for access control for portable data storage media
IL110891A (en) * 1993-09-14 1999-03-12 Spyrus System and method for data access control
US5536164A (en) * 1995-05-05 1996-07-16 Electra Form, Inc. Flexible hot manifold assembly for injection molding machines
US5857025A (en) * 1996-09-09 1999-01-05 Intelligent Security Systems, Inc. Electronic encryption device and method
US5937063A (en) * 1996-09-30 1999-08-10 Intel Corporation Secure boot
US5937066A (en) * 1996-10-02 1999-08-10 International Business Machines Corporation Two-phase cryptographic key recovery system
GB9621274D0 (en) * 1996-10-11 1996-11-27 Certicom Corp Signature protocol for mail delivery
US6035041A (en) * 1997-04-28 2000-03-07 Certco, Inc. Optimal-resilience, proactive, public-key cryptographic system and method
US6122742A (en) * 1997-06-18 2000-09-19 Young; Adam Lucas Auto-recoverable and auto-certifiable cryptosystem with unescrowed signing keys
US6088802A (en) * 1997-06-04 2000-07-11 Spyrus, Inc. Peripheral device with integrated security functionality
US6003135A (en) * 1997-06-04 1999-12-14 Spyrus, Inc. Modular security device
US6708273B1 (en) * 1997-09-16 2004-03-16 Safenet, Inc. Apparatus and method for implementing IPSEC transforms within an integrated circuit
US6981149B1 (en) * 1998-01-27 2005-12-27 Spyrus, Inc. Secure, easy and/or irreversible customization of cryptographic device
US6292898B1 (en) * 1998-02-04 2001-09-18 Spyrus, Inc. Active erasure of electronically stored data upon tamper detection
US6848050B1 (en) * 1998-04-16 2005-01-25 Citicorp Development Center, Inc. System and method for alternative encryption techniques
US6055508A (en) * 1998-06-05 2000-04-25 Yeda Research And Development Co. Ltd. Method for secure accounting and auditing on a communications network
US6295602B1 (en) * 1998-12-30 2001-09-25 Spyrus, Inc. Event-driven serialization of access to shared resources
WO2000054127A1 (en) * 1999-03-08 2000-09-14 Spyrus, Inc. Method and system for enforcing access to a computing resource using a licensing certificate
US6901145B1 (en) * 1999-04-08 2005-05-31 Lucent Technologies Inc. Generation of repeatable cryptographic key based on varying parameters
JP2001060254A (en) * 1999-06-15 2001-03-06 Matsushita Electric Ind Co Ltd Deciphering processor performing deciphering process for specific area in content data
US6971022B1 (en) * 1999-06-15 2005-11-29 Matsushita Electric Industrial Co., Ltd. Cryptographic apparatus for performing cryptography on a specified area of content data
US6816965B1 (en) * 1999-07-16 2004-11-09 Spyrus, Inc. Method and system for a policy enforcing module
US6970849B1 (en) * 1999-12-17 2005-11-29 Microsoft Corporation Inter-server communication using request with encrypted parameter
KR100653805B1 (en) * 2000-01-21 2006-12-05 소니 가부시끼 가이샤 Data authentication system
EP2770455B1 (en) * 2000-06-16 2017-01-25 MIH Technology Holdings BV Method and system to exercise geographic restrictions over the distribution of content via a network
AU7182701A (en) * 2000-07-06 2002-01-21 David Paul Felsher Information record infrastructure, system and method
US7313825B2 (en) * 2000-11-13 2007-12-25 Digital Doors, Inc. Data security system and method for portable device
US7143437B2 (en) * 2001-01-12 2006-11-28 Siemens Medical Solutions Health Services Corporation System and user interface for managing user access to network compatible applications
US7167565B2 (en) * 2001-03-06 2007-01-23 Arcot Systems, Inc. Efficient techniques for sharing a secret
US20020129261A1 (en) * 2001-03-08 2002-09-12 Cromer Daryl Carvis Apparatus and method for encrypting and decrypting data recorded on portable cryptographic tokens
US20030037237A1 (en) * 2001-04-09 2003-02-20 Jean-Paul Abgrall Systems and methods for computer device authentication
US7257844B2 (en) * 2001-07-31 2007-08-14 Marvell International Ltd. System and method for enhanced piracy protection in a wireless personal communication device
GB0119629D0 (en) * 2001-08-10 2001-10-03 Cryptomathic As Data certification method and apparatus
US20030046534A1 (en) * 2001-08-31 2003-03-06 Alldredge Robert L. Method and apparatus for secured electronic commerce
KR100529550B1 (en) * 2001-10-18 2005-11-22 한국전자통신연구원 Method for modifying authority of a certificate of authentication using information of a biometrics in a pki infrastructure
US7043643B1 (en) * 2001-12-06 2006-05-09 Adaptec, Inc. Method and apparatus for operating a computer in a secure mode
US6928476B2 (en) * 2002-08-23 2005-08-09 Mirra, Inc. Peer to peer remote data storage and collaboration
GB0221639D0 (en) * 2002-09-17 2002-10-30 Hewlett Packard Co Method and apparatus for printing
US7849016B2 (en) * 2002-12-18 2010-12-07 Vincent So Internet-based data content rental system and method
US7257717B2 (en) * 2003-04-01 2007-08-14 Fineart Technology Co., Ltd Method with the functions of virtual space and data encryption and invisibility
CN1302382C (en) * 2003-06-13 2007-02-28 联想(北京)有限公司 Verification method based on storage medium private space of USB flash memory disc
JP2007534042A (en) * 2003-10-08 2007-11-22 ステファン・ヨズ・エングベアウ Method and system for establishing communication using privacy enhancement technology
FR2864387B1 (en) * 2003-12-23 2006-04-28 Eads Telecom METHOD AND DEVICE FOR TRANSMITTING INFORMATION WITH VERIFICATION OF INVOLUNTARY OR VOLUNTARY TRANSMISSION ERRORS
US7930503B2 (en) * 2004-01-26 2011-04-19 Hewlett-Packard Development Company, L.P. Method and apparatus for operating multiple security modules
US20060075263A1 (en) * 2004-03-15 2006-04-06 Jesse Taylor System and method for security and file retrieval from remote computer
US8050409B2 (en) * 2004-04-02 2011-11-01 University Of Cincinnati Threshold and identity-based key management and authentication for wireless ad hoc networks
US20070239615A1 (en) * 2004-04-23 2007-10-11 Natsume Matsuzaki Personal Information Management Device, Distributed Key Storage Device, and Personal Information Management System
US7693286B2 (en) * 2004-07-14 2010-04-06 Intel Corporation Method of delivering direct proof private keys in signed groups to devices using a distribution CD
US7639799B2 (en) * 2004-12-14 2009-12-29 Microsoft Corporation Cryptographically processing data based on a Cassels-Tate pairing
US20060182277A1 (en) * 2005-02-14 2006-08-17 Tricipher, Inc. Roaming utilizing an asymmetric key pair
US20060242423A1 (en) * 2005-04-22 2006-10-26 Kussmaul John W Isolated authentication device and associated methods
JP4961798B2 (en) * 2005-05-20 2012-06-27 株式会社日立製作所 Encrypted communication method and system
US7587045B2 (en) * 2005-10-03 2009-09-08 Kabushiki Kaisha Toshiba System and method for securing document transmittal
EP2122900A4 (en) * 2007-01-22 2014-07-23 Spyrus Inc Portable data encryption device with configurable security functionality and method for file encryption
KR101520617B1 (en) * 2007-04-17 2015-05-15 삼성전자주식회사 Method for encrypting message for keeping integrity of message and apparatus and Method for decrypting message for keeping integrity of message and apparatus
WO2010019918A1 (en) * 2008-08-15 2010-02-18 Qualys, Inc. System and method for performing remote security assessment of firewalled computer

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134660A (en) * 1997-06-30 2000-10-17 Telcordia Technologies, Inc. Method for revoking computer backup files using cryptographic techniques
US7000108B1 (en) * 2000-05-02 2006-02-14 International Business Machines Corporation System, apparatus and method for presentation and manipulation of personal information syntax objects
US20020186848A1 (en) * 2001-05-03 2002-12-12 Cheman Shaik Absolute public key cryptographic system and method surviving private-key compromise with other advantages
US20030046572A1 (en) * 2001-08-30 2003-03-06 Newman Aaron Charles Cryptographic infrastructure for encrypting a database
US20050240591A1 (en) * 2004-04-21 2005-10-27 Carla Marceau Secure peer-to-peer object storage system
US7590236B1 (en) * 2004-06-04 2009-09-15 Voltage Security, Inc. Identity-based-encryption system
US7814318B1 (en) * 2005-09-27 2010-10-12 Oracle America, Inc. Scalable file system configured to make files permanently unreadable

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10154014B2 (en) 2015-08-21 2018-12-11 Alibaba Group Holding Limited Method and system for efficient encryption, transmission, and decryption of video data
US20170214712A1 (en) * 2016-01-25 2017-07-27 Aol Inc. Compromised password detection based on abuse and attempted abuse
US10270801B2 (en) * 2016-01-25 2019-04-23 Oath Inc. Compromised password detection based on abuse and attempted abuse
US10313115B2 (en) 2016-02-15 2019-06-04 Alibaba Group Holding Limited System and method for quantum key distribution
US10326591B2 (en) 2016-02-15 2019-06-18 Alibaba Group Holding Limited Efficient quantum key management
US11658814B2 (en) 2016-05-06 2023-05-23 Alibaba Group Holding Limited System and method for encryption and decryption based on quantum key distribution
US10693635B2 (en) 2016-05-06 2020-06-23 Alibaba Group Holding Limited System and method for encryption and decryption based on quantum key distribution
US10491383B2 (en) 2016-05-11 2019-11-26 Alibaba Group Holding Limited Method and system for detecting eavesdropping during data transmission
US10439806B2 (en) 2016-05-19 2019-10-08 Alibaba Group Holding Limited Method and system for secure data transmission
US10574446B2 (en) 2016-10-14 2020-02-25 Alibaba Group Holding Limited Method and system for secure data storage and retrieval
US10103880B2 (en) 2016-10-14 2018-10-16 Alibaba Group Holding Limited Method and system for quantum key distribution based on trusted computing
US10855452B2 (en) 2016-10-14 2020-12-01 Alibaba Group Holding Limited Method and system for data security based on quantum communication and trusted computing
WO2018071195A1 (en) * 2016-10-14 2018-04-19 Alibaba Group Holding Limited Method and system for quantum key distribution based on trusted computing
US10484185B2 (en) 2016-12-15 2019-11-19 Alibaba Group Holding Limited Method and system for distributing attestation key and certificate in trusted computing
US10164778B2 (en) 2016-12-15 2018-12-25 Alibaba Group Holding Limited Method and system for distributing attestation key and certificate in trusted computing
US10985913B2 (en) 2017-03-28 2021-04-20 Alibaba Group Holding Limited Method and system for protecting data keys in trusted computing
US10951614B2 (en) 2017-03-30 2021-03-16 Alibaba Group Holding Limited Method and system for network security
US10841800B2 (en) 2017-04-19 2020-11-17 Alibaba Group Holding Limited System and method for wireless screen projection
US11074332B2 (en) 2017-09-05 2021-07-27 iStorage Limited Methods and systems of securely transferring data
US20200372159A1 (en) * 2017-11-30 2020-11-26 Bae Systems Plc Methods of decrypting disk images, and decryption-enabling devices
US11531771B2 (en) * 2017-11-30 2022-12-20 Bae Systems Plc Methods of decrypting disk images, and decryption-enabling devices
US11258610B2 (en) 2018-10-12 2022-02-22 Advanced New Technologies Co., Ltd. Method and mobile terminal of sharing security application in mobile terminal
US11032069B2 (en) * 2018-11-07 2021-06-08 iStorage Limited Methods and systems of securely transferring data
US20210281399A1 (en) * 2018-11-07 2021-09-09 iStorage Limited Methods and systems of securely transferring data
US11677546B2 (en) * 2018-11-07 2023-06-13 iStorage Limited Methods and systems of securely transferring data
US20210157747A1 (en) * 2019-11-26 2021-05-27 Samsung Electronics Co., Ltd. Memory controller, storage device including the same, and operating method of the memory controller
US11681637B2 (en) * 2019-11-26 2023-06-20 Samsung Electronics Co., Ltd. Memory controller, storage device including the same, and operating method of the memory controller
US11429519B2 (en) 2019-12-23 2022-08-30 Alibaba Group Holding Limited System and method for facilitating reduction of latency and mitigation of write amplification in a multi-tenancy storage drive

Also Published As

Publication number Publication date
US20080263363A1 (en) 2008-10-23
EP2122900A2 (en) 2009-11-25
US9049010B2 (en) 2015-06-02
IL236641A (en) 2017-03-30
IL236641A0 (en) 2015-02-26
IL199983A (en) 2015-01-29
US20130046993A1 (en) 2013-02-21
WO2008147577A2 (en) 2008-12-04
US9521123B2 (en) 2016-12-13
US20160021109A1 (en) 2016-01-21
EP2122900A4 (en) 2014-07-23
IL199983A0 (en) 2010-04-15
WO2008147577A3 (en) 2009-03-26

Similar Documents

Publication Publication Date Title
US9521123B2 (en) Method for file encryption
US10673626B2 (en) Threshold secret share authentication proof and secure blockchain voting with hardware security modules
US7178025B2 (en) Access system utilizing multiple factor identification and authentication
KR100969241B1 (en) Method and system for managing data on a network
US9032192B2 (en) Method and system for policy based authentication
KR20210066867A (en) An encrypted asset encryption key portion that allows assembly of an asset encryption key using a subset of the encrypted asset encryption key portion.
US20170142082A1 (en) System and method for secure deposit and recovery of secret data
US20130227286A1 (en) Dynamic Identity Verification and Authentication, Dynamic Distributed Key Infrastructures, Dynamic Distributed Key Systems and Method for Identity Management, Authentication Servers, Data Security and Preventing Man-in-the-Middle Attacks, Side Channel Attacks, Botnet Attacks, and Credit Card and Financial Transaction Fraud, Mitigating Biometric False Positives and False Negatives, and Controlling Life of Accessible Data in the Cloud
US20200259637A1 (en) Management and distribution of keys in distributed environments
EP2339777A2 (en) Method of authenticating a user to use a system
US10158613B1 (en) Combined hidden dynamic random-access devices utilizing selectable keys and key locators for communicating randomized data together with sub-channels and coded encryption keys
CN115668867A (en) Method and system for secure data sharing through granular access control
CN111295654A (en) Method and system for securely transferring data
TWI476629B (en) Data security and security systems and methods
US10623384B2 (en) Combined hidden dynamic random-access devices utilizing selectable keys and key locators for communicating randomized data together with sub-channels and coded encryption keys
US20090024844A1 (en) Terminal And Method For Receiving Data In A Network
Sarhan et al. Secure android-based mobile banking scheme
US11373172B1 (en) Database encryption wallets
CN108985079B (en) Data verification method and verification system
CN113924571A (en) Cryptographic system
Sharma et al. Transcrypt: A secure and transparent encrypting file system for enterprises
KR100842014B1 (en) Accessing protected data on network storage from multiple devices
CN113449345A (en) Method and system for protecting data realized by microprocessor
Xuan An End-to-End Encryption Solution for Enterprise Content Applications
WO2023052845A2 (en) Protecting data using controlled corruption in computer networks

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

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