System and method for cryptographic suite management.

专利摘要:
The invention relates to systems and methods for cryptographic suite management. A cryptographic suite management system includes a cryptographic suite management unit (112) that includes a set of APIs that enable various applications to retrieve cryptographic functions. The system allows: access of multiple applications to shared cryptographic resources at one interface; sharing and licensing cryptographic resources among devices through applications in multiple devices; encrypting, decrypting and sharing data between devices with different cryptographic implementations; the definition, dissemination and implementation of policies governing the terms of use of cryptographic implementations, systems and procedures to secure and protect shared and dynamically-loaded cryptographic providers; the use of multiple cryptographic resources by an application and the management of cryptographic provider packets and associated policies through one or many instances of cryptographic suite management units.
公开号:CH709936B1
申请号:CH01092/15
申请日:2015-07-28
公开日:2019-07-31
发明作者:Antipa Adrian；Chorafakis Dominic；Neill Brian
申请人:Lnfosec Global Lnc；
IPC主号:

专利说明:

description
Technical Field The following generally relates to data communications and, more particularly, to systems and methods for securing data communications between users through cryptographic techniques.
Background Cryptographic implementations may be implemented as suites that are available to be invoked by a variety of computer programs (also referred to as applications). Various applications invoke cryptographic operations in the storage and communication of data. The encryption operations are implemented by various encryption methods, protocols and suites.
In areas of sensitive data, it is a good practice for two or more applications to communicate data with each other using a cryptographic technique. The choice of cryptographic method depends on many factors including processing load, error control, authentication, traceability, knowledge and confidence with respect to the other application, etc. Another factor is whether the cryptographic method is in the legal system in which the application is used , available or common. In some cases, various jurisdictions favor or enforce certain cryptographic procedures or suites for a variety of reasons, and it is not uncommon for various countries in widely used industries to enforce various cryptographic procedures. In these examples, it can be difficult to securely exchange data between companies in different countries that operate in these industries.
In addition, cryptographic implementations are called by applications whose underlying source code languages and architectures differ and which operate on multiple platforms and device types. However, these applications must communicate with applications that are hosted on different platforms and with different code languages.
Sensitive data is increasingly being transmitted over unsecured networks while the variety of applications continues to grow. In addition, a variety of providers have a greater variety of cryptographic implementations designed to protect transmitted data from interception.
SUMMARY [0006] In one aspect, there is provided a method for cryptographic suite management, the method comprising: configuring a first correspondent connected to a first suite-management cryptographic unit to make an import request to a second cryptographic suite management entity Correspondent connected to a second suite of cryptographic management unit, the request comprises the identification of a cryptographic implementation and security requirements for the cryptographic implementation for export by the second correspondent; Configuring a second suite of cryptographic management units to provide the cryptographic implementation configured using the security requirements; Configuring the second correspondent to export the configured cryptographic implementation to the first correspondent; and configuring the first cryptographic suite management unit to securely import the configured cryptographic implementation for use by the first correspondent.
In another aspect, there is provided a system for cryptographic suite management, the system comprising a second correspondent connected to a second cryptographic suite management unit configured to communicate with a first correspondent which is associated with a first cryptographic suite management unit, wherein after transmission of an import request by the first correspondent to the second correspondent, the request is the identification of a cryptographic implementation and security requirements for the cryptographic implementation for export by the second Correspondent, the second cryptographic suite management unit is configured to provide the cryptographic implementation that has been configured using the security requirements and the configured cryptographic implementation to the first Korres to allow the first cryptographic suite management unit to securely import the configured cryptographic implementation for use by the first correspondent.
Additionally, there is provided a cryptographic suite management system, the system comprising a cryptographic suite management unit configured to perform cryptographic functions using cryptographic provider implementations from a cryptographic library in response to a retrieval of an application, wherein the cryptographic suite management unit is further configured to exchange one or more of the cryptographic provider implementations for use by a third party.
In the embodiments, systems and methods are provided to facilitate the exchange and use of cryptographic suites between applications and devices.
In further embodiments, systems and methods are provided for enabling cryptographic suite management to expose a plurality of cryptographic provider suites for various applications and devices across a number of platforms.
In yet other embodiments, systems and methods are provided to facilitate the import / export of cryptographic suites between applications and devices.
In still other embodiments, systems and methods for rewriting data between devices that invoke various cryptographic implementations are provided.
In still further embodiments, policies and methods are provided for enforcing policies that determine the usage conditions for cryptographic suites used or exchanged between applications and devices.
In yet other embodiments, systems and methods are provided for protecting cryptographic suites that are exchanged between applications and devices.
[0015] In yet other embodiments, policies and methods are provided for policy setting and management that determine the terms of use for cryptographic suites used or exchanged between applications and devices.
These and other embodiments are considered and described herein. It is to be appreciated that the foregoing summary sets forth representative aspects of cryptographic suite management systems and methods for assisting a skilled reader in understanding the following detailed description.
Description of the Drawings A more complete understanding of the embodiments will become possible with reference to the figures, in which:
FIG. 1 illustrates a configuration of a cryptographic suite management system; FIG.
Figure 2 illustrates APIs for one embodiment of a suite cryptographic management unit;
Fig. 3 illustrates a method for the shared import of a cryptographic provider suite;
Fig. 4 illustrates a method for the blocked import of a cryptographic provider suite;
Figure 5 illustrates a cryptographic suite management unit in a tightly coupled execution environment;
Fig. 6 illustrates a cryptographic suite management unit in a distributed execution environment;
Figure 7 illustrates a cryptographic suite management unit configured in a C and Java program environment;
Fig. 8 illustrates the dynamic loading of a cryptographic provider implementation;
Figure 9 illustrates the abstraction of platform-specific dynamic loading in the cryptographic suite management unit;
Fig. 10 illustrates a method for loading and storing a suite safe;
Fig. 11 illustrates a method for unloading a cryptographic provider implementation;
Fig. 12 illustrates a method for generating cryptographic provider packets;
Fig. 13 illustrates a trunking and encryption configuration;
Fig. 14 illustrates another bundling configuration;
Fig. 15 illustrates a method for importing packets;
Fig. 16 illustrates a method of bundling a license-based cryptographic provider implementation;
Fig. 17 illustrates a method for securely storing keys;
Fig. 18 illustrates another method for securely storing keys;
Fig. 19 illustrates a method for loading and storing a suite safe;
Fig. 20 illustrates a method for unloading a cryptographic provider implementation;
Figure 21 illustrates a method of retrieving cryptographic provider implementations in a hardware suite vault;
Fig. 22 illustrates a method for securely storing a cryptographic suite in a hardware suite vault;
Fig. 23 illustrates a method of registering an application with a hardware secure module;
Fig. 24 illustrates a configuration for the cryptographic abstraction;
Fig. 25 illustrates a configuration for overwriting;
Fig. 26 illustrates a method for overwriting; and
FIG. 27 illustrates a method for managing a plurality of suite of cryptographic suite management entities, cryptographic provider implementations, and policies.
Detailed Description It is appreciated that the reference numerals, when considered appropriate, may be repeated in the figures for the purpose of simplicity and clarity of illustration to characterize associated or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, one of ordinary skill in the art appreciates that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, methods, and components have not been described in detail so as not to obscure the embodiments described herein. Likewise, the description should not be taken as limiting the scope of the embodiments described herein.
It will be appreciated that various terms used in the present description may be read and understood as follows, unless otherwise indicated by the context: "as used herein is inclusive as if "and / or" were written; Articles in singular and pronouns as used herein include their plural forms and vice versa; Likewise, gender pronouns include pronouns that represent their counterpart, so pronouns should not be construed as limitations on what is described herein in terms of use, implementation, performance, etc. by a single gender. Other definitions of terms may be set forth herein; these may apply to previous and subsequent examples of these terms, which will be understood by reading the present specification.
It will be appreciated that all of the modules, units, components, servers, computers, terminals, or devices discussed herein and executing instructions include computer-readable media such as storage media, electronic storage media, or data storage devices (removable and / or non-removable) such as For example, magnetic disks, optical disks, or tape may include or otherwise have access to such media. Electronic storage media may include volatile and nonvolatile, removable and non-removable media implemented by any method or technology for storing information such as computer readable instructions, data structures, program modules, or other data. Examples of electronic storage media include RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROMs, Digital Versatile Disks (DVD), or other optical storage options, magnetic cassettes, magnetic tape, storage on magnetic disks or other magnetic storage devices or any other medium that can be used to store the desired information and which an application, module, or both can access. Any such electronic storage medium may be part of or accessible to or associable with the device. Further, unless the context indicates otherwise, any processor or controller set forth herein may be implemented as a single processor or as a plurality of processors. The plurality of processors may be ordered or distributed, and any processing function discussed herein may be performed by one or a plurality of processors, even though a single processor has been discussed. All of the methods, applications or modules described herein may be implemented using computer readable / executable instructions that may be stored or otherwise stored by such computer readable media and executed by the one or more processors.
The following relates to data communication systems secured by cryptographic methods. In the aspects, the following systems and methods enable communication between multiple cryptographic correspondents (users) or applications that use different cryptographic suites of procedures.
[0022] In one aspect, a system and method are described herein that include using a protocol that allows for export from one user of one implementation of a cryptographic suite to another user for importing and dynamically loading the implementation. The method includes a protocol for negotiating various security requirements for each of the users and their applications; and the dynamic loading of the cryptographic suite by the importing user.
In another aspect, a system and method are described in which a trusted third-party agent facilitates secure communication between users and applications, wherein a first user or application may be a data source and a second user may be a data recipient. The third party imports each user's cryptographic suite implementation, uses the implementation associated with the data source to decrypt cipher texts from the data source, and then uses the implementation associated with the data receiver to encrypt the cipher suites. These systems and methods are functions of a cryptographic suite management system that enables: the exchange and use of cryptographic implementations between users and applications; for applications, the dynamic loading and use of cryptographic algorithms in a secure manner; the enforcement of policies associated with the use of one or more cryptographic suites; secure communication between users or applications that support various cryptographic algorithms; and managing cryptographic suites and associated policies.
In areas of sensitive data, it is a good practice for two or more applications to communicate data with each other using a cryptographic technique. The choice of cryptographic method depends on many factors including processing load, error control, authentication, traceability, knowledge and trust with respect to the other application, etc. Another factor is whether the cryptographic method is available in the legal system in which the application is used or is common. In some cases, different legal systems favor or enforce certain cryptographic procedures or suites for a variety of reasons.
In an illustrative situation, it may be in the interest of a bank to establish a secure communication channel between its branches in two different such jurisdictions (e.g., two different countries), with each jurisdiction enforcing a different cryptographic suite than the other. The branches in such a legal system can therefore use a different cryptographic suite than the branches of the bank in the other legal system. One approach, enabled by one or more of the following embodiments, would be when another party, such as the bank's International Headquarters, acts as an intermediary to switch between the branches in the various jurisdictions using the cryptographic suite for the respective ones To communicate branches of each legal system to translate the ciphertext from one cryptographic suite to the other.
In other situations, cryptographic implementations are invoked by applications whose underlying source code languages and architectures differ and which operate on multiple platforms and device types. However, these applications may need to communicate with applications that are hosted on different platforms and with different code languages.
In yet other situations, sensitive data may be transmitted between different users and applications using a variety of cryptographic implementations from a variety of providers over unsecured networks, such that each user uses a cryptographic suite designed to provide that user's transmitted data to protect a catch. For users using individual cryptographic suites configured with various methods, parameters, and implementations, it may be desirable to communicate with other users while taking advantage of their individual cryptographic resources. For such users, the independence afforded by individual cryptographic resources may be desirable while benefiting from networkability with other users. One approach made possible by one or more of the following embodiments would be for such users to exchange cryptographic suites with each other or use a third party to use their respective cryptographic suites to facilitate secure data exchange between users.
The following provides systems and methods for cryptographic suite management. The cryptographic suite management systems and methods provided herein enable interoperability and secure communication between applications and platforms that invoke either common or distinct cryptographic provider implementations or suites. The cryptographic suite management systems and methods may also enable a variety of applications operating in a single device or on a single platform to access a variety of cryptographic provider implementations. The cryptographic suite management systems and methods may further enable applications to bundle or export cryptographic provider implementations for other applications. The cryptographic suite management systems and methods may further enable applications to dynamically load and execute cryptographic provider implementations in a secure manner. The systems and methods for cryptographic suite management may further enable applications to enforce policies governing the terms of service for cryptographic provider implementation.
In aspects, a suite's cryptographic suite management unit enables an application to invoke cryptographic functions provided by a plurality of cryptographic provider suites.
Referring now to Figure 1, a block diagram illustrates a system 100 executing an application 102 configured to retrieve encryption functions. The system 100 may include at least one such application 102 (which may be referred to herein as a "fetch application"), an operating system 104, a file system 106, a memory 108, and cryptographic hardware 110 such as a hardware secure module (HSM). These elements communicate with a cryptographic suite management unit 112 which manages the application and sharing of one or more cryptographic suites through import, export, and licensing.
The cryptographic suite management unit 112 may include: a cryptographic API 114; an API for key management 116; a rights management API 118; an OpenSSL API 120; a protocol API 122; a provider registration API 124; an API for configuration management 126; a warning module 128; a protocol module 130; a configuration manager 132; a cipher suite vault 134 for securely storing cryptographic provider suites; a key vault 136 for securely storing cryptographic keys; an import / export means 138 for importing and / or exporting cryptographic provider packets; policy means 140 for managing the distribution of policies that determine the usage conditions for cryptographic providers; a policy server 142 for centrally managing policies and cryptographic providers in a security domain; a container client 144 for accessing cryptographic provider packets and keys in the suite vault and key vault; a hardware client 146 for communicating with cryptographic hardware; and a provider registration component 124 for registering cryptographic providers with the cryptographic suite management unit. The operating system 104 communicates with the file system 106 and the memory 108. The particular function of each of these components is described herein.
In other aspects, the cryptographic suite management unit 112 facilitates the import, exchange, and use of a variety of cryptographic provider suites between devices and applications. The exchange of cryptographic provider suites between devices can be established via a network connection between the devices; usually over the Internet, as shown in FIG. 27.
By importing more than one cryptographic provider suite to a device, other applications on the device may access one or more of the plurality of cryptographic provider suites to encrypt and / or decrypt data or other cryptographic operations perform. The import / export operation is defined by a protocol that is configured to negotiate both the requirements of the importers and the exporters without reducing the security of the underlying applications.
The cryptographic suite management unit 112 may include a suite of APIs, such as a cipher management API 148, a configuration management API 126, a key vault API 150, and a suite vault API 152, which associated with the import and export of cipher suites as illustrated in FIG. 2.
The cipher management API 148 (illustrated as "CipherMgtApi") provides functions used to manage cryptographic provider packets, including the following examples of the suite management suite cryptographic, to export and import operations for cipher suite packages: - "Import request" 154 is an inquiry by an importer to obtain a cryptographic provider with a specified security level and platform information. The request includes a public key generated by the importer to be used for encryption of the cryptographic provider; that is, the cryptographic provider can be securely shared with the requesting party per se; - «Import RequestComing» 156 is an answer from an Exporter in response to and after an analysis of an import request. The exporter receives the information from the import request, determines the security level of its application, and scans its vault for an appropriate cryptographic provider. Based on import / export policies of an appropriate cryptographic provider, the exporter determines whether to export the appropriate cryptographic provider. The name of this cryptographic provider is supplied to the application. This is the only information needed by an application integrated with a cryptographic suite management unit to process the cryptographic provider; - "Export Package" 158 creates a file that contains executable binaries and policies from a cryptographic provider that govern the terms of use that can be exported and loaned for use by another application. In one embodiment, this operation includes the following steps: receiving the public key of an importer generated for the purpose of the export operation; Generating a cryptographic packet file with header fields filled with appropriate values according to the details of the request; • Generate an associated license file with the necessary data for policies and security; • Generate, if necessary, a key pair that will be used to encrypt the cryptographic provider packet; • encrypting the cryptographic provider packet using the importer's public key and, if necessary, the private key of the exporter; • Archive the encrypted cryptographic provider package, the license file, and the public keys provided to the function in a single archive, such as a zip or tarball archive. "Package Import" 160 performs the import operations within an application receiving an exported cryptographic provider package. In one embodiment, this operation includes the following steps: extracting the encrypted cryptographic provider packet, the license file, and the public keys from the archive; • validate file integrity; • Use the appropriate public key from the archive to find the corresponding private key; Decrypting the cryptographic provider packet using the public key of the exporter and, if necessary, the importer's private key; • validate the file header and integrity; • storing the cryptographic provider package in the suite vault; and registering the cryptographic provider packet with the configuration manager for loading to perform cryptographic operations.
It will be appreciated by one of ordinary skill in the art that the names associated with the above (or any of the following) functions may be modified as desired.
The configuration management API 126 (illustrated as "ConfigMgrApi") provides functions for managing the configuration of the suite management suite cryptographic configuration including the following examples of registering and unregistering packets used to perform Cryptographic operations are available: - "Package Registration" 162 stores information relating to a package that has been imported into the Suite vault; - "Remove Package" 164 deletes information relating to a package removed from the Suite vault, either as a result of a user action or under license terms; and - "List Packages" 166 sends information about all the cryptographic providers available in the Suite vault.
Suites back.
The configuration management API 126 may also provide functions necessary to provide information to retrieval applications and to access the services of the cryptographic suite management unit at various levels of security, that is, different implementations. Each crypto provider implementation has a cryptographic security level. This is part of the information that the exporter needs to publicize the implementation.
The key vault API 150 (illustrated as "KeyVaultApi") provides functions for managing secret keys needed by the cryptographic suite management unit 112, including the following function calls to generate key pairs and to recover keys, which are required to perform encryption and decryption operations: "Generate Key Pair" 168 generates an asymmetric key pair and securely stores the private key in the key vault. In the context of management of cipher suites, this fetch is made by the receiving application to generate a KEK / KDK pair and from the sending application to generate the BEK / BDK pair; and - «PrivateKeyCome» 170 recovers a private key from the key vault. In the context of managing cipher suites, the receiving application makes this call to recover the private key KDK associated with the KEK needed during decryption operations during the import process.
The suite vault API 152 provides functions for managing cryptographic provider suites stored in the suite vault, including support for the following operations: "Package Store" 172 permanently stores a cryptographic provider package in encrypted form Format; "Package Removal" 174 permanently and securely removes a cryptographic provider packet from the persistent store; "Package load" 176 reads a cryptographic provider packet from the persistent store, decrypts the cryptographic provider packet, and dynamically links the cryptographic provider packet to the current operation for use in executing cryptographic operations; "Packet Unloading" 178 separates the decrypted packet from the running application and safely removes the unencrypted code and the data associated with the cryptographic provider packet from the volatile and non-volatile memory; and "Packet Validate" 180 is called by the suite's cryptographic management unit when it checks and applies the policies for the various packages stored in the suite vault, such as a policy for safely removing a expired package from the permanent storage medium, is required.
In use, a fetch application 102 invokes the cryptographic suite management unit 112 to import a new cryptographic provider suite as shown in Figs. 3 and 4. For some platforms, blocking during the import process can destabilize aspects of the system. For example, some platforms may be sensitive to blocking by mobile devices. Therefore, the provider registration API 124 may be configured for a blocked or shared import of cryptographic suites, as shown in FIGS. 3 and 4, respectively.
Referring now to Figure 3, an asynchronous, i. non-blocking import of a cryptographic suite 300 illustrated. At block 302, after a user request via an application user interface or automatically as the result of application logic, a unique request token associated with a call to the provider registration API to import the cryptographic suite of a given cryptographic provider is encrypted by the cryptographic suite. Management unit provided to the application. At block 304, the suite cryptographic management unit then performs various validation and import operations to import the cryptographic suite; meanwhile, the unique request token may be used by the application to request operational status messages about the import process and to take appropriate action such as notifying application users through an application user interface, log files, or other suitable methods.
In the blocked import method 400 illustrated in FIG. 4, the call from the application to the provider registration API resulting from the actions performed at block 402 does not result in a response until processes other than the cryptographic suite have completed. Management unit were initiated at block 404 to process the import request, completed successfully, or deemed failed.
The import described above may occur during the runtime of a fetch application. While the interface between the application and the cryptographic suite management unit may be static at run time, the interface between the suite cryptographic management unit and the supported cryptographic suites may dynamically change to add or remove one or more cryptographic provider suites during runtime. Thus, the cryptographic suite management unit may be configured according to the following general approaches to involve cryptographic provider suites being added at runtime: (1) a runtime (dynamic) linkage model in which the program statements of the cryptographic Provider suite (cryptographic code) are closely linked to the cryptographic suite management unit through the use of a shared or dynamic library; and (2) a distributed client-server model in which cryptographic provider suite services are accessed by invoking remote methods or interprocess communication.
Referring now to Figure 5, an embodiment 500 is shown that is implemented using the runtime linkage approach. The runtime association approach may provide relatively improved performance and security over the distributed model because the application 102, the suite cryptographic unit 112, and the provider 504 cryptographic implementations are all executed in the same application execution environment 502. However, there may be a significant variance between the mechanisms available on different supported platforms for dynamic linking components or libraries, requiring implementation of platform and language specific code.
Referring to Figure 6, an embodiment 600 implemented with a distributed model that makes use of remote method invocation or communication between processes 602 as regards dynamic linking may reduce platform and language-specific dependencies, though significant differences between supported platforms may still require a level of customization of codes for each platform in terms of options for threading, inter-process communication, and remote method invocation. The disadvantages with regard to the performance and security of the distributed model, which are due to the fact that the application 102 and the cryptographic providers 608 are executed in different execution environments 604, 606, can be solved at least in part by the implementation of a suitable process / threading Mo -dells and a security mechanism to be mitigated. This includes support for a multi-threaded or multi-process remote method call model to enable the parallel execution of multiple cryptographic operations, the use of mutual authentication between communication processes, and the use of encryption for any interprocess communication.
Certain applications or components thereof using the suite cryptographic management unit may be written using various programming languages such as Java, C, or C ++. In one embodiment, the suite-management cryptographic unit includes a C-based API that can call applications written in C or C ++ natively with equivalent API wrappers for other programming languages.
The cryptographic suite management unit 112 may be configured according to a tightly coupled model as shown in FIG. 7 and support both Java based applications 702 and C / C ++ based applications / components 704. Since the Cryptographic Suite Management Unit API must be available for both C and Java-based applications in such a configuration, the cryptographic provider suite is encoded in C such that: C components of the calling application cryptographic provider functions can call without conversion; while Java components of a calling application make calls via a Java API 706 using Java Native Interface (JNI) to access the functionality of the C-based cryptographic provider suites. All Java application components that interact with the cryptographic suite management unit can do so through the classes of the Java API 706 for the cryptographic suite management unit. The Java API classes are simple wrappers that use JNI to call the required functionality through the associated C API interface 708.
Applications or components written in C 704 may interact with the cryptographic suite management unit 112 using the available C-API 708 for the cryptographic suite management unit 112. The C API 708 in turn establishes links to the rest of the tightly coupled (i.e., statically linked) components of the suite cryptographic management unit using native function calls.
The cryptographic suite management unit may be configured to operate on a variety of platforms including, but not limited to, Android, iOS, MAC OS, Windows, or a Linux-based OS. These platforms are typically bundled or can be bundled with implementations of common cryptographic suites and provide a variety of higher layer cryptographic APIs and protocols (SSL, HTTPS) that can be used by applications running on these platforms. In addition to providing these APIs to applications, the OS inherently uses these cryptographic implementations to provide such features as file system encryption.
A user of an application executing on a standard platform may prefer to call the cryptographic suite management unit to invoke custom, custom, or otherwise unavailable encryption of cryptographic providers independent of cryptographic suites that are automatically invoked in be provided to the OS. Because the security features of standard operating systems do not necessarily have to be reliable, the cryptographic suite management unit can be configured to protect all its data, including without limitation cryptographic provider packets, encryption keys, and configuration and policy data to rely on the default encryption properties of the OS as described in more detail herein.
The various platforms on which the cryptographic suite management unit may be configured to provide mechanisms that allow programs executing on these platforms to dynamically load and execute program components that are used by the applications, which they call are independent. Examples of this capability include the DL API available for Linux and Mac OS, Microsoft run-time dynamic linking available for Windows, and dynamic linking for iOS and Android. When components of the cryptographic suite management unit invoke cryptographic provider methods, an underlying platform's capability for dynamic linking can be exploited. This allows multiple cryptographic providers and provider-shared libraries to be added and removed for use by the application at runtime when they are no longer needed, as described in greater detail herein.
In one embodiment, the architecture illustrated in Figure 8 for Linux may take advantage of a generic potential of Linux for dynamic loading, which is generally true for Linux platforms. It will be appreciated that dynamically loaded (DL) libraries are the common approach for implementing plug-ins or modules in Linux-based applications such as the Pluggable Authentication Modules (PAM) systems.
The DL-API 802 provides a number of functions that allow an application to dynamically load a library at runtime and perform functions provided by the library. Figure 8 illustrates an exemplary use of the Linux DL API by an application for loading and executing code from a shared library. The following snippet illustrates the use of the Linux DL API:
The DL-API 802 is available on different Linux platforms, sometimes under different names such as shljoad instead of dlopen. Furthermore, analog mechanisms are available on other operating systems such as Mac OS, iOS, Android and Windows. Therefore, the cryptographic suite management unit preferably includes an abstraction layer 902, as seen in Figure 9, to provide platform-independent dynamic loading of libraries containing cryptographic provider functions.
The use of dynamic linking properties for generic OS must be used to allow cryptographic provider implementations to be exchanged and dynamically loaded at runtime between instances of cryptographic suite management units, such that the algorithms included in the cryptographic provider implementations are available for the application. It is appreciated that dynamic linkage properties for generic OSs do not address strict security requirements associated with cryptographic provider implementations. The cryptographic suite management unit can
Provide capabilities that enable the dynamic linking of cryptographic provider implementations while mitigating security threats relevant to cryptographic implementations.
Dynamic linking using standard OS properties requires that the modules to be connected be available to the OS in unencrypted format so that the program instructions can be loaded into system memory and made available for execution. However, the creators or owners of custom cryptographic provider implementations may want the algorithms to remain secret so that storing the unencrypted libraries in nonvolatile memory poses a security vulnerability because the algorithms could be extracted from the persistent store and reconstructed.
To preserve the privacy of cryptographic provider suites, a secure storage mechanism, such as a suite vault 134, as illustrated in FIG. 1, may be provided. The suite vault can be provided as a secure hardware-based container, such as an HSM or secure storage, or as a software module that provides the functions needed to load and store cryptographic provider implementations as needed.
In one embodiment, illustrated in Figure 10, the suite vault 134 provides a method 1000 that allows other components of the suite cryptographic management unit 112 to initiate secure storage of cryptographic provider packets and dynamically load the cryptographic provider implementations at a later time so that the algorithms that it implements are available to the application. When storing the cryptographic provider implementation, the file is encrypted at block 1002 using the cryptographic potential of the cryptographic suite management unit, encryption keys are securely stored in the key vault, and the encrypted cryptographic provider packet is stored in persistent storage at item 1005. When an application needs to call functions of this cryptographic provider packet, it is dynamically loaded by means of a load_bundle call to the Suite vault, illustrated as element 1004. In response to this invocation, the suite vault receives the key needed to decrypt the cryptographic provider package from the key vault, illustrated as item 1006; loads the encrypted cryptographic provider packet from persistent storage at item 1008; decrypts the file of the cryptographic provider packet at block 1008; safely erases the keys used during the decryption process from system memory; writes the decrypted library file of the cryptographic provider packet to a virtual disk in the volatile memory at item 1010; uses the abstraction layer to invoke the underlying potential of the dynamic link operating system to load the cryptographic provider package from the virtual disk, thereby making the functions available to the application. The unencrypted cryptographic provider package file is preferably deleted and removed from the virtual disk as fast as possible. When the application no longer needs access to the functions of the provider-specific cryptographic packet implementation, the cryptographic suite management unit notifies the suite vault by means of a call close_bundle, illustrated in FIG. 11 as item 1102 according to a method 1100. In response to this call, the suite vault safely empties the memory at the point where the cryptographic provider implementation was loaded and uses the abstraction layer to invoke the underlying potential of the dynamic link OS to disconnect the module ,
Once a cryptographic provider has been dynamically linked to the cryptographic suite management unit, the program instructions and associated data are memory resident in the system memory where they can undergo modifications by programs that have sufficient access to such system resources. Malware that can run on the same platform as the cryptographic provider may be able to modify program statements or data, making the cryptographic algorithms vulnerable and freeing the data they want to protect. The cryptographic suite management unit secures the integrity of cryptographic provider implementations that have been dynamically loaded by implementing integrity checks on the loaded modules. When the integrity checks detect manipulation of the cryptographic provider or data program instructions, information is recorded using the cryptographic suite management unit protocol module 130, applications and users are alerted via the alert module 128, and other cryptographic operations can be set to resolve the disclosure to prevent sensitive information. The cryptographic suite management unit 112 may employ a number of integrity checking methods that include, but are not limited to, the use of checksum functions to verify that program instructions have not been tampered with; the use of test vectors within the cryptographic suite provider that can verify the code integrity associated with metadata contained in the crypto provider package when it was imported into the suite cryptographic management unit; the use of a challenge-response protocol between the cryptographic suite management entity and the cryptographic provider implementation.
When a cryptographic provider packet is exchanged between two instances of the cryptographic suite management unit, the generating unit may determine the policies that determine the usage conditions of the cryptographic suite provider. The receiving cryptographic suite management unit enforces these policies to ensure that the use of the cryptographic suite provider by the receiving application complies with the terms of use prescribed by the generating unit. Policies may include, but are not limited to: the operating system on which the receiving unit is running; the use of a hardware suite vault or software suite vault by the receiving unit; the cryptographic algorithms used by the receiving entity to protect the cryptographic provider; the size of the keys used by the receiving entity to protect the cryptographic provider; the integrity checks performed by the receiving unit.
In aspects, the cryptographic suite management unit may enable cryptographic providers to bundle and distribute cryptographic plug-ins for distribution to multiple different platforms. Because a single cryptographic plug-in binary file can not be compatible with all platforms that the plug-in supports, a packager can be called to bundle multiple binaries into a package of binaries that are configured to support multiple platforms. The package of binaries may be referred to herein as a "cryptographic provider package" 1202. The cryptographic suite management unit may be configured to import the binary file at runtime for the platform of an intended end user device.
Packager 1204 bundles the distributable information created for a specific provider cryptographic implementation into a single file as illustrated in FIG. 12.
As seen in FIG. 13, the cryptographic provider packet 1302 may include: a generic header 1304 that includes information about the packet that includes its version and the version of the targeted cryptographic suite management unit to create a Compatibility between the cryptographic suite-management unit that imports the package and to ensure the provider implementation; Security features such as a signature 1306 to allow importing applications to ensure that (a) none of the redistributable information has been changed, (b) the package has been created by a trusted Packager application, and (c) the licensing logic and the rights management for the imported cryptographic provider can be applied; and (3) a series of provider offsets 1308 which determine the size and location of each individual distributable information contained in the package file.
14 illustrates in a more specific sense the essential header fields of files that may include the license file 1406 and the cryptographic provider packet 1404. The cryptographic provider package 1404 may include the following headers (to which different names may be assigned as needed): Generic File Info 1408, which provides generic cryptographic suite information such as the features provided by the package, the level of security supported, and May contain platform information; "License File Info" 1410, which indicates that the package has an associated application specific license, i.e., that it is not intended for general use by an unspecified application. The field uniquely identifies the license file associated with the package. If left blank, the cryptographic provider suite may be considered open, i. from any application that has been released by the cryptographic suite management unit. "Crypto Packet ID" 1412, which is a unique identifier of a packet that can be used to associate a license file with a specific packet; "License file HMAC" 1414, which stores the keyed hash message authentication code (HMAC) of the associated license file; and "HMAC" 1416, which is the HMAC of the packet, including all header fields, to prevent tampering.
The accompanying license file 1406 may include the following headers: Generic Header Info 1418, which contains information about the license file, such as the file version; "Crypto Packet ID" 1420, which is a label identifying the specific cryptographic packet to which the license file is associated; "Usage rights information" 1422, which contains information about the usage rights of the associated cryptographic packet, such as start and end dates or elapsed time limits; "Receiver KEK" 1424 which identifies a public key provided by the recipient of the packet that can be used to obtain the necessary keys for decryption; and Cryptographic metadata 1426, which contains information needed by the suite-management cryptographic unit operation.
The packager may be further configured to generate an encrypted packet file. Each encrypted packet file may be encrypted so that it can only be decrypted by the intended recipient, as described in greater detail herein.
As previously described and illustrated as method 1500 in FIG. 15, an application 102 may initiate the import of a new cryptographic provider packet either automatically or as a result of user action by the application user interface 1502. The application 102 then calls the cryptographic suite management unit 1504 to process the packet. The file is decrypted at block 1506 using the appropriate keys (discussed in another scenario), and the contained distributable information of the provider is extracted at block 1508. At block 1510, the appropriate distributable information is securely stored in the suite vault, from which it can later be dynamically loaded and executed, and the received file and all temporary files are removed at block 1512. After importing a cryptographic provider package and extracting the cryptographic provider implementation for the platform on which a cryptographic suite management unit is hosted, the cryptographic suite management unit may discard the elements of the package that are for the host Platform are inappropriate to make room. For example, during the import of a cryptographic provider packet, the cryptographic suite management unit may store the packet in memory, extract the relevant distributable information and store it in the suite vault, and display the irrelevant distributable information as shown in FIG. discard. Alternatively, the distributable information for all platforms, if applicable, may be stored in the suite vault. For example, if the receiving application needs to import the cryptographic provider for yet another application, and the policy associated with the imported cryptographic provider package allows it, the receiving cryptographic suite management unit may choose to have all distributable information in the suite vault save. In other aspects, the cryptographic suite management entity allows an actor having a particular cryptographic provider implementation to allow a trusted partner to use the implementation, either with or without restrictions such as time and / or parameters Use and / or storage. Therefore, a platform may include or communicate with a license manager that is configured to generate a license file that includes potential constraints and should be provided to the trusted partner.
The import / export operations may be structured as a protocol. Preferably, the execution of the protocol does not affect the security levels of the "owner application" 1604 and the "affiliate application" 1602. Here, "owner application" refers to an application executing on the device as an actor having a given crypto packet during "Affiliate Application" refers to an application that corresponds to a trusted partner who should receive the crypto package, possibly under license. During this protocol, the suite of cryptographic management units makes determinations based on the values of the security level of the applications in which it is integrated and the policies enforced by the applications, such as licensing. The protocol may use a public key encryption technique as illustrated in FIG. 16 as method 1600.
Whenever an application requests the services of a specific cryptographic provider package from the cryptographic suite management unit API, as illustrated at block 1606, the suite cryptographic management unit may check at block 1608 to see if the terms of use are still valid. If the license terms indicate that the cryptographic provider is no longer permitted for that application and / or the device, the cryptographic suite management unit may automatically (i.e., without further user input) delete the requested cryptographic provider package from the suite vault. However, if the license still remains valid, the cryptographic suite management unit may decrypt the provider package and dynamically load the shared libraries as described above, as illustrated at blocks 1616, 1618. The method described with reference to Figure 16 may require a common cryptographic provider shared between the owner application as illustrated at blocks 1610, 1612, the license manager and the partner application for encryption and decryption of the interchanged file. A public key encryption method such as the ECIES (Elliptic Curve Integrated Encryption Scheme) can be used.
It will be appreciated that the cryptographic owner may wish to control not only the usage conditions but also the environment in which exported cryptographic provider packets are used. Therefore, the license file accompanying the cryptographic provider packet sent to the trusted partner may include one or more restrictions such as the following parameters: initial data and the duration for which the packet can be used by the trusted application ; the total amount of data (e.g., number of bytes) that can be encrypted or decrypted using the cryptographic provider packet; a minimum or maximum key size that can be used with the cryptographic provider packet (the cryptographic suite management unit, along with the partner application, after this parameter occurs, can prohibit nonconforming key sizes from being used with the cryptographic provider, although the algorithms contained therein support this); a minimum key size of the crypto provider used by the suite vault of the cryptographic suite management unit that is executed in conjunction with the partner application (this can be used to prevent unsafe storage of the cryptographic provider by the partner application to avoid); and a flag indicating whether the peer application must have access to a hardware key vault or if a software key vault is sufficient.
In aspects, a secure key vault is provided to securely store keys for encryption, which may be accomplished in the form of a secure software key vault or a secure hardware key vault.
During execution of a cryptographic function, the cryptographic suite management unit may be invoked to generate an asymmetric key pair and store the private key. However, it is possible that the host platform for the cryptographic suite management unit may not have fundamentally secure storage capabilities. Unless the host platform includes an associated secure module for executing cryptographic provider implementations, the algorithms contained within the cryptographic provider package may be loaded into the system of the host platform to perform cryptographic operations. If system memory is compromised, malicious elements can access the algorithms. Further, elements of the cryptographic provider implementation stored in persistent storage may also be revealed by inherent host platform uncertainty.
Referring now to Figure 17, a method 1700 of providing a secure software key vault in the suite cryptographic management unit 112 is illustrated. The key vault 136 stores keys in encrypted form in persistent storage, such as a file system 106 on the target device, so that they can not be decrypted by unauthorized users or applications. In embodiments, the key vault for each device generates and uses a unique device key for keys for encryption and decryption in the key vault, as shown at blocks 1702, 1704, 1706. Releasing the device key to an unauthorized user or application would also result in disclosure of all keys stored in the key vault and, therefore, mechanisms must be implemented to protect the privacy of the device key.
Referring now to Figure 18, in embodiments, a white box encryption method is shown wherein the keys and algorithms for white box encryption are corrupted during the build time of the application. Once the application is developed, appropriate build tools can be invoked to turn the source code into binaries that are compatible with the target platform. To provide a white box module 1802, a key (or keypair) and the binary objects for the cryptographic suite management unit (which includes the white box module) may be routed through white box tools to the keys and disfigure the white box module code. The resulting binaries may then be passed to a standard linking means to produce the final binary file for the application, which includes code for the suite of cryptographic suite management units that comprise the white box module. It will be appreciated that each actor building applications comprising the cryptographic suite management unit together with the white box module includes the cryptographic algorithms included in the white box module. To prevent publication of such algorithms, the white box module may be sent from a trusted party in disfigured binary format to application builders so that only the trusted party has the cryptographic algorithms in the white box module. Alternatively, the key generation and disfigurement may be performed as a cloud or Internet based service by a trusted party.
The resulting white box module contains a disfigured key that can be used to decrypt a device key for the host platform. At runtime on an end user's device, an application 102 using a suite cryptographic unit 112 that includes the resulting white box module may decrypt one of the private keys stored in the key vault by, according to one 18, a call to the cryptographic suite management is made, as shown at block 1802, to: recover the device key; decrypt it without revealing it in the system memory at block 1804; use the device key to decrypt the private key at blocks 1806, 1808; and return the private key in decrypted form to the calling component as shown. Preferably, once the white box module has decrypted the requested private key, it immediately and securely flushes the memory containing the decrypted device key, as shown at block 1810. The requested private key can then be returned to the calling cryptographic suite management unit component.
More preferably, the white box module can ensure that buffers used for temporarily storing the decrypted private key before it is sent back to the caller are securely deleted so that the device key and the requested private key after the Returning to the caller is no longer in memory.
In further embodiments, the key vault may use a password based approach, wherein the secrecy of the device key is ensured by encrypting the device key using a cryptographic provider available to the suite cryptographic management unit using a key derived from a password provided by the user of the device. An application running on the device using the cryptographic suite management unit would prompt the user for the password of the device key using the application user interface and pass the password to the cryptographic suite manager via an API call. Deliver unity. Using the password provided by the user, the key vault may load the encrypted device key from the persistent store, derive the key for decryption needed to decrypt the device key, and use the device key to decrypt any of the keys that are secure stored by the key vault. As with the method employing a white box encryption method, this method also ensures that the one provided by the user
Password and the encrypted device key are no longer stored in the unencrypted or undistorted format in the volatile memory, as required for the execution of the functions of the key vault and that the buffers used for it safely deleted. In addition, the key vault will never store the password provided by the user or the decrypted device key in persistent storage.
As an alternative to a software implementation of the secure key container, the cryptographic suite management unit may include a secure key-box module that uses a hardware-based tamper-resistant platform such as a hardware secure module (HSM) or secure element (SE) is hosted on the hardware platform of the device hosting the suite of cryptographic suite management units. Because the HSM or SE can be used by other applications, the suite cryptographic management unit can only store the device key - unlike other private keys needed to store other keys or sensitive data stored in the key vault. unlock. Using the SE does not expose the device key to the system memory.
One weakness in using the hardware SE is that any private keys needed to decrypt packet files of the cryptographic provider may reside in memory for the duration of an associated decryption operation. However, the cryptographic provider package may be protected against off-line attacks at the point where the persistent storage containing the provider's encrypted package files and the private keys in the key vault are due to the fact that the device key is for decryption All information needed is safely located within the secure element.
In addition to the key vault, the cryptographic suite management unit, along with a suite vault, can operate for the implementation, import, and secure storage of encrypted cryptographic provider packets. Like the key vault described above, the Suite vault can be implemented as a hardware or software solution. Referring now to Figure 19, an illustrative implementation of a method 1900 for accessing securely stored code from a software-implemented suite safe is illustrated. In the illustrative implementation, before being stored in the persistent store of the suite vault module (at item 1903), the cryptographic provider package is encrypted using a local, device-specific encryption key as shown at block 1902. When the cryptographic suite management unit determines that access to the cryptographic provider packet is necessary, it invokes the suite vault to load the packet as illustrated as item 1904. Upon receipt of the call, the suite vault reads the encrypted cryptographic packet from the file system of the host platform as illustrated at item 1905, 1906; At block 1908, the suite vault decrypts the cryptographic provider packet using the received private key and stores the cryptographic provider's unencrypted executable information in a secure area, such as a virtual RAM disk or a trusted file system, such as a library, for use by the cryptographic provider Make OS available for dynamic loading as illustrated by element 1910. The Suite vault then makes calls to the host's operating system to load the unencrypted library into memory, as illustrated by item 1912. The unencrypted library resides in memory until the application no longer needs the library. The application preferably makes a call to the cryptographic suite management unit when it no longer needs the library so that the cryptographic suite management unit calls the suite vault to remove the unencrypted library from memory.
Referring now to FIG. 20, according to a method 2000, after being invoked to remove the unencrypted library from memory, the cryptographic suite management unit calls the suite vault to securely access the unencrypted library to clear the memory and hard disk as illustrated by item 2002. For example, if a virtual RAM disk is used, the library can be overwritten using a 3-pass wipe.
Alternatively, the cryptographic suite management unit may be configured for use with a suite vault as a hardware implementation using, for example, a hardware security module (HSM), as long as the host device includes such an HSM. When an HSM is used to host the cryptographic provider package, the functions included in the HSM can not be modified or updated at runtime. This means that the HSM may be limited in that it can not import cryptographic provider packages at runtime, as described in relation to software suite vault implementations.
Figure 21 illustrates an exemplary configuration in which the cryptographic suite management unit 112 on a platform including an HSM-based suite vault invokes encryption operations. The HSM 2102 may include an interface such as a PKCS11 driver 2104. As shown, the HSM may be a PCIx card 2106 installed in a Linux environment. Authentication information for an application requesting encryption operations may be stored outside the HSM, as described in more detail below.
In operation, the cryptographic suite management unit, as illustrated in FIG. 21 and in greater detail in FIG. 22, activates when an application 102 calls the cryptographic suite management unit 112 to invoke an encryption operation that is cryptographic Provider packet defined in HSM 2102, its HW client 2108 (illustrated at element 2202) to client credentials 2110 (eg, a client certificate)
Element 2204, which are preferably obtained from the previously described key vault on element 2206. The HW client 2108, which is configured to communicate with the PKCS11 driver 2104 of the HSM 2102, provides the credentials decrypted for authentication at item 2208 to the HSM. Once the HSM 2102 has authenticated the suite cryptographic management unit, the HW client invokes the HSM to perform an encryption operation on item 2210 and log off the HW client from the HSM to item 2212 when complete. The HW client returns the result of the encryption operation to the cryptographic suite management unit at the illustrated item 2214 for delivery to the calling application.
In the scenario illustrated in Figures 21 and 22, the cryptographic suite management unit provides client credentials to the HSM for authentication. As previously described, these are preferably obtained from the key vault 136. To place the client credentials initially in the key vault 136, it obtains the cryptographic suite management unit 112 from the calling application, as illustrated in FIG. Once the application or the end user of the application receives the client credentials, the application delivers the credentials to the CM 132 of the cryptographic suite management unit 112, illustrated at item 2302, as well as the path to the PKCS # 11 driver. The cryptographic suite management unit 112 stores the credentials in the key vault as illustrated at item 2304 and updates the CM 132 to store the path to the PKCS # 11 driver.
In aspects, a cryptographic suite management system as described above may enable an application to invoke a variety of cryptographic functions from a variety of cryptographic provider implementations. The cryptographic suite management unit may further include an API for the cryptographic abstraction for accessing cryptographic functions of the available cryptographic suites. The cryptographic abstraction API may include abstracted cryptographic primitives that allow applications to build different cryptographic provider implementations. The cryptographic abstraction API can be understood as a set of APIs, each of which represents a grouping of operations performed by the underlying cryptographic provider implementations. For example, the cryptographic abstraction API may include, but is not limited to, the following set of APIs: random number API; - hash function API; - public key cipher API; and - Symmetric Encryption API.
Further, the cryptographic abstraction API may include: functions that allow a calling application to determine the range of values appropriate to the specific cryptographic provider implementation invoked; and error and return status codes common to various cryptographic provider implementations for communicating the status to the calling application. For example, with reference to Figure 24, the cryptographic abstraction API may include a block cipher API 2402 in its row. The block cipher API may in turn include the following primitives to call associated functions: init_cipher: function used to initialize the parameters of the block cipher implementation; - generate_key: function used to set the encryption and / or decryption key plan; - encrypt: function used to encrypt a block of data; and - decrypt: function used to decrypt a block of data.
Continuing with the same example, the init_cipher function may require a list of arguments suitable for block cipher implementations, such as: key size; - key value; - block size; and - cipher mode.
However, in various cryptographic provider implementations, some implementations may allow different ranges of values for the arguments. For example, cryptographic provider-A can only support 128-bit and 256-bit key sizes, while cryptographic provider-B can support 128, 256, 512, and 1024-bit key sizes. Therefore, the block cipher API 2402 may include the following primitives to return ranges of values allowable for a given provider cryptographic implementation to the calling application: get_key_sizes-get_block_size_range-get_cipher_modes As can be seen in Figure 24, the calling application 102 may be configured according to a Method 2400 first initializes a call to the cryptographic suite management unit 112 to return, for example, permissible key sizes, areas for block sizes, and cipher modes for a cryptographic provider implementation. The calling application can then use the returned parameters to initialize allowed calls according to the available primitives. The following pseudocode is illustrative of the scenario shown in Figure 24:
[0092] In other aspects, a cryptographic suite management system may enable override services between parties that invoke various cryptographic algorithms. In certain scenarios, two parties that want to securely communicate with each other may use different cryptographic provider implementations for encryption and decryption. In the event that either party does not want to or is unable to share the cryptographic provider implementation with the other, an intermediary gateway may act as a proxy in relation to the data and transform the data to use the The cryptographic provider implementation available to the receiving application can be decrypted, which is called a override service. The gateway may be, for example, a VolP call server that uses an exchange sequence of a SIP message to establish a VoIP connection between the two parties. In the previous example, the first party may send a SIP INVITE message that includes the SIP URL of the receiving party. Alternatively, the gateway may be an HTTP proxy server in which a first party securely connects to the HTTP proxy server and provides the URL of the HTTP server (i.e., the second party) to which it wishes to connect. The override service is provided by an override module based on a cryptographic suite.
Fig. 25 illustrates a gateway configuration 2500 for providing proxy and override services. The gateway includes: gateway logic 2502 configured to make calls to an override module via a transcript API 2504. The override module includes an override connection plan 2506 for mapping the communication parameters for each endpoint (i.e., party). The override module is configured to invoke cryptographic provider implementations via a cryptographic API 2508 that includes the cryptographic provider implementations used by both parties.
Figure 26 illustrates a method 2600 for providing proxy and override services using the gateway. Gateway 2602 establishes a connection between two endpoints. The gateway then identifies the connection between the two endpoints (i.e., parties) (2604, 2606) by assigning status information to the two parties; and the gateway uses the status information to determine the communication parameters assigned to each endpoint, illustrated at block 2608. The communication parameters for each endpoint include: the endpoint IP address and protocol (TCP or UDP); - the TCP or UDP port of the connection; the cryptographic provider packet used to encrypt and / or decrypt the data exchanged with this endpoint; and the session keys for encrypting and / or decrypting data exchanged with that endpoint.
Once the gateway receives the communication parameters for each endpoint, it uses the override API to create a call to the override module to invoke a scheduling scheme illustrated as item 2610. The scheduling method stores the communication parameters in the override connection plan. Each entry in the override connection plan is assigned a unique connection ID.
When a first client transmits encrypted data to the override gateway as illustrated at item 2612, the gateway 2603 invokes the override module via the override API 2605 as described at item 2614, which provides the following parameters: - the unique connection ID returned by the previous call to the scheduling process;
the encrypted data received from the first client endpoint; and a sender identifier (e.g., IP address) identifying the first client endpoint.
The override module then performs the following operations at block 2616: (i) it uses the connection ID to locate in the override connection plan the entry associated with the connection ID; (ii) it calls the cryptographic provider implementation associated with the connection identifier for the first client endpoint to decrypt the data; (iii) it calls the cryptographic provider implementation associated with the connection identifier for the second client endpoint to encrypt the decrypted data; and (iv) send the re-encrypted data back to the caller at item 2618 as a buffer. The gateway then transmits the re-encrypted buffer to the second client as illustrated at item 2620.
When data needs to be overwritten, the application returns the sender's connection ID, the connection ID of the destination and the encrypted data to the override service running in the secure computing environment, and retrieves the overridden data from the service , The cryptographic suite management does not reveal the internals of the override service to the application.
In aspects, the cryptographic provider packets, the associated policies, and the suite of cryptographic suite management units, all of which are part of a given administrative domain, may be managed by a policy manager as illustrated in FIG. 27. In embodiments, the policy manager 2700 may consist of: an application user interface 2702 for interacting with application users; a policy management logic component 2704 that provides the functions needed to manage the collection of cryptographic provider packets 2706, policies 2708 and endpoints 2710, and communicates with the cryptographic suite management units 2712 in the administrative domain ; a crypto provider DB containing the collection of all cryptographic provider packets available in the administrative domain, a policy DB containing the collection of policies that can be applied to each cryptographic provider packet, and an endpoint DB containing information about each cryptographic suite management unit in the administrative domain, including information needed for secure communication with the endpoint (eg, IP address and security credentials).
In embodiments, the policy manager may communicate with one or more suite of cryptographic suite management units over a network 2714 to distribute cryptographic provider packets; to delete cryptographic provider packets that are available in a suite of cryptographic management units; to communicate information about policies associated with one or more cryptographic provider packets; to communicate configuration information for the cryptographic suite management unit; to obtain status and performance statistics from a suite of cryptographic suite management units; and / or to perform a management or security audit for a cryptographic suite management unit. It should be noted that Policy Manager is an optional component of the solution. Administrative users can perform the same operations with individual instances of suite management cryptographic units through the available application user interfaces and the suite of cryptographic suite management units APIs. In addition, all operations involved in the export / import of cryptographic provider packages between instances of suite management cryptographic units and the associated functionality for defining and enforcing usage policies and associated security measures may be performed without the use of the policy manager component, such as previously described in the associated sections.
The collection of cryptographic suite management entity instances that are managed as tracked in the endpoint DB may be populated by a variety of methods including: manually provided by an administrative user; automatically provided by means of a discovery protocol, wherein the policy management logic component scans the network to find instances of suite management cryptographic units or by means of a registration protocol, instances of cryptographic suite management units having a particular one Policy Manager will be registered. The policy management logic provides the functionality needed to either add new entries to the endpoint DB, update existing ones, or delete entries from the endpoint DB, either in response to a user action or through an automated operation.
Although the invention has been described with respect to certain specific embodiments, various modifications will be apparent to those skilled in the art. The scope of the claims should not be limited by the preferred embodiments, but should have the broadest interpretation consistent with the description as a whole. The entire disclosures of all of the aforementioned references are incorporated herein by reference.

权利要求:
Claims (38)
[1]
claims
A cryptographic suite management method for determining a cryptographic implementation between at least one first correspondent and another correspondent, each of the correspondents comprising one or more processors adapted to execute the cryptographic implementation, comprising a. Configuring, using one or more processors of the first correspondent, the first correspondent connected to a first cryptographic suite management unit to transmit an import request to the other correspondent connected to another cryptographic suite management unit wherein the request comprises identifying a cryptographic implementation and security requirements for the cryptographic implementation for export by the other correspondent; b. Configuring, using one or more processors of the other correspondent, another cryptographic suite management unit to provide the cryptographic implementation that is configured using the security requirements; c. Configuring, using one or more processors of the other correspondent, the other correspondent, to export the configured cryptographic implementation to the first correspondent; and d. Configure, using one or more processors of the first correspondent, the first cryptographic suite management unit to securely import the configured cryptographic implementation for use by the first correspondent.
[2]
The method of claim 1, further comprising configuring a third correspondent, using one or more processors of the third correspondent, to interact with the other correspondent in an identical manner as the interaction between the first correspondent and the other correspondent, the other correspondent is a trusted third-party investigator that facilitates secure communication between the first correspondent and the third correspondent.
[3]
The method of claim 1, wherein each cryptographic suite management unit is configured to store a plurality of cryptographic implementations for use in a secured suite vault and to export them to other correspondents.
[4]
The method of claim 3, wherein each cryptographic suite management unit is configured to dynamically load each of the plurality of cryptographic implementations from its suite vault for use in secure communication.
[5]
The method of claim 3, wherein the suite vault encrypts each cryptographic implementation during storage and stores a copy of the keys used for encryption.
[6]
6. The method of claim 5, wherein after a request to obtain the cryptographic implementation, the suite vault receives the encrypted cryptographic implementation and the keys that decrypt the cryptographic implementation using the keys that the keys securely delete, the cryptographic implementation in volatile memory writes to a virtual disk that exposes cryptographic implementation to a requesting application and removes the cryptographic implementation from the virtual disk.
[7]
The method of claim 1, wherein the request and the export are structured as a protocol that securely negotiates cryptographic and security requirements of importers and exporters.
[8]
The method of claim 7, wherein the protocol uses a public-key encryption method and comprises: a. the first correspondent sends an import request, including his public key, the security level of his application and the security level to be expected for the cryptographic provider, and the platform to the other correspondents; b. the other correspondent analyzes the request taking into account the security level of its application and its cryptographic suite management policy, looks for a match through its cryptographic providers, and decides whether to export or not; c. After the other correspondent has decided to export, the other correspondent generates an export package comprising: i. his public key; ii. the security level of its application; iii. Information about the cryptographic implementation and the implementation; iv. the cryptographic implementation, encrypted with the public key of the first correspondent and, if necessary, the private key of the other correspondent; d. the package is exported to the first correspondent; e. the first correspondent receives the packet, extracts the information, and decides, based on the information and its management policy, whether to accept it or not; f. the first correspondent decrypts the cryptographic implementation with the private key of the second correspondent and, if necessary, the public key of the other correspondent.
[9]
9. The method of claim 8, wherein the public-key encryption method is Elliptic Curve Integrated Encryption Scheme.
[10]
The method of claim 9, comprising a registration phase when the first correspondent and the other correspondent are endpoints, each endpoint exporting its cryptographic implementation to the cryptographic suite management unit which is an intermediary in the communication channel between the two endpoints followed by executing a key agreement protocol to generate symmetric keys for each of the two pairs, including the cryptographic suite management unit and each of the endpoints.
[11]
The method of claim 10, comprising the service of translating ciphertext generated from a first endpoint into cipher text of the other second endpoint.
[12]
12. The method of claim 11, wherein the translation service comprises: a. the first endpoint, which encrypts a plaintext with its symmetric encryption method and the key introduced between the first endpoint and the cryptographic suite management unit during registration; b. Transferring the resulting ciphertext to the cryptographic suite management unit; c. the cryptographic suite management unit that decrypts the resulting ciphertext with the first endpoint encryption / decryption method and the key introduced during registration, the resulting plaintext with the second endpoint ciphering system, and the second endpoint cryptographic suite Encrypts the management unit introduced during registration and sends the resulting ciphertext to the second endpoint; d. the second endpoint, which decrypts the received ciphertext with its decryption method and the key introduced between the second endpoint and the suite cryptographic management unit during registration.
[13]
13. The method of claim 1, wherein the cryptographic suite management unit provides dynamic link cryptographic implementations for applications that are executed to the correspondent.
[14]
The method of claim 1, wherein the cryptographic suite management unit ensures the integrity of the cryptographic implementations made available to requesting applications.
[15]
15. The method of claim 1, wherein the other suite cryptographic management unit is configured to set policies that determine usage conditions of the cryptographic implementation.
[16]
The method of claim 15, wherein the policies include license conditions that specify applications and devices allowed to use the cryptographic implementation.
[17]
17. The method of claim 15, wherein the policies include license conditions that determine the time frame in which the cryptographic implementation may be used.
[18]
The method of claim 15, wherein after attempting an application or device to unauthorized use of a cryptographic implementation, the cryptographic suite management unit deletes the cryptographic implementation from the suite vault.
[19]
19. The method of claim 1, wherein the first correspondent provides his public key in the request.
[20]
20. A cryptographic suite management system for determining and using a cryptographic implementation between at least one first correspondent and another correspondent, each of the correspondents comprising one or more processors adapted to execute the cryptographic implementation, the system comprising the other Correspondent, which is connected to another cryptographic suite management unit that is configured to communicate with the first correspondent, which is connected to a first suite of cryptographic management unit, wherein after transmission of an import request by the first correspondent to the other correspondents, where the request includes the identification of a cryptographic implementation and security requirements for the cryptographic implementation for export by the other correspondents, the other cryptographic suite management Unit is configured to provide the cryptographic implementation that has been configured using the security requirements and to export the configured cryptographic implementation to the first correspondent to allow the first cryptographic suite management unit to configure the configured cryptographic implementation for use to import safely through the first correspondent.
[21]
21. The system of claim 20, wherein the other correspondent further communicates in a manner identical to the interaction between the first correspondent and the other correspondent with a third correspondent having one or more processors, the other correspondent being a trustworthy third party investigator facilitates secure communication between the first correspondent and the third correspondent.
[22]
22. The system of claim 20, wherein the other cryptographic suite management unit is configured to store a plurality of cryptographic implementations for use in a secured suite vault and to export them to other correspondents.
[23]
23. The system of claim 22, wherein the other suite cryptographic management unit is configured to dynamically load each of the plurality of cryptographic implementations in its suite vault for use in secure communication.
[24]
24. The system of claim 22, wherein the suite vault encrypts each cryptographic implementation during storage and stores a copy of the keys used for encryption.
[25]
25. The system of claim 24, wherein after a request to obtain the cryptographic implementation, the suite vault receives the encrypted cryptographic implementation and the keys that decrypt the cryptographic implementation using the keys that the keys securely delete, the cryptographic implementation in volatile memory writes to a virtual disk that exposes cryptographic implementation to a requesting application and removes the cryptographic implementation from the virtual disk.
[26]
26. The system of claim 20, wherein the request and the export are structured as a protocol that securely negotiates cryptographic and security requirements of importers and exporters.
[27]
27. The system of claim 26, wherein the protocol uses a public-key encryption method and comprises: a. the first correspondent sends an import request, including his public key, the security level of his application and the security level to be expected for the cryptographic provider, and the platform to the other correspondents; b. the other correspondent analyzes the request taking into account the security level of its application and its cryptographic suite management policy, looks for a match through its cryptographic providers, and decides whether to export or not; c. After the other correspondent has decided to export, the other correspondent generates an export package comprising: i. his public key; ii. the security level of its application; iii. Information about the cryptographic implementation and the implementation; iv. the cryptographic implementation, encrypted with the public key of the first correspondent and, if necessary, the private key of the other correspondent; d. the package is exported to the first correspondent; e. the first correspondent receives the packet, extracts the information, and decides, based on the information and its management policy, whether to accept it or not; f. the first correspondent decrypts the cryptographic implementation with the private key of the first correspondent and, if necessary, the public key of the other correspondent.
[28]
The system of claim 27, wherein the public-key encryption method is Elliptic Curve Integrated Encryption Scheme.
[29]
29. The system of claim 28, comprising a registration phase when the first correspondent and the other correspondent are endpoints, each endpoint exporting its cryptographic implementation to the suite cryptographic management unit which is an intermediary in the communication channel between the two endpoints, followed by executing a key agreement protocol for generating symmetric keys for each of the two pairs, including the cryptographic suite management unit and each of the endpoints.
[30]
The system of claim 29, comprising the service of translating ciphertext generated from a first endpoint into cipher text of the other second endpoint.
[31]
The system of claim 30, wherein the translation service comprises: a. the first endpoint, which encrypts a plaintext with its symmetric encryption method and the key introduced between the first endpoint and the cryptographic suite management unit during registration; b. Transferring the resulting ciphertext to the cryptographic suite management unit; c. the cryptographic suite management unit that decrypts the resulting ciphertext with the first endpoint encryption / decryption method and the key introduced during registration, the resulting plaintext with the second endpoint ciphering system, and the second endpoint cryptographic suite Encrypts the management unit introduced during registration and sends the resulting ciphertext to the second endpoint; d. the second endpoint, which decrypts the received ciphertext with its decryption method and the key introduced between the second endpoint and the suite cryptographic management unit during registration.
[32]
The system of claim 20, wherein the cryptographic suite management unit provides dynamic link cryptographic implementations for applications executed to the correspondent.
[33]
33. The system of claim 20, wherein the cryptographic suite management unit ensures the integrity of the cryptographic implementations made available to requesting applications.
[34]
34. The system of claim 20, wherein the other suite cryptographic management unit is configured to set policies that determine usage conditions of the cryptographic implementation.
[35]
35. The system of claim 34, wherein the policies include licensing conditions that specify applications and devices allowed to use the cryptographic implementation.
[36]
36. The system of claim 34, wherein the policies include license conditions that determine the time frame in which the cryptographic implementation is allowed to be used.
[37]
37. The system of claim 34, wherein after attempting an application or device to unauthorized use of a cryptographic implementation, the cryptographic suite management unit deletes the cryptographic implementation from the suite vault.
[38]
38. The system of claim 20, wherein the first correspondent provides his public key in the request.

类似技术:

---

公开号 | 公开日 | 专利标题

---

CH709936B1|2019-07-31|System and method for cryptographic suite management.

---

CN105027493B|2018-09-07|Safety moving application connection bus

---

DE60307736T2|2006-12-28|Server architecture for secure plug-ins in digital rights management systems

---

DE60314060T2|2008-01-24|Method and device for key management for secure data transmission

---

DE112014000357T5|2015-10-08|Key management in multi-client capable environments

---

US10601873B2|2020-03-24|System and apparatus for providing network security

---

DE102011051498A1|2012-12-06|Secure access to data in one device

---

EP2755159A1|2014-07-16|Method and device for privacy-respecting data processing

---

DE112018001559T5|2019-12-05|CACHE-STABLE SESSION TICKET SUPPORT FOR TLS TEST

---

Brock et al.2010|Toward a framework for cloud security

---

WO2019129642A1|2019-07-04|Secure storage of and access to files through a web application

---

Mirtalebi et al.2011|Enhancing security of Web service against WSDL threats

---

US10509914B1|2019-12-17|Data policy implementation in a tag-based policy architecture

---

DE10146361A1|2003-04-24|Device and method for establishing a security policy in a distributed system

---

Abur et al.2018|Towards a privacy mechanism for preventing malicious collusion of multiple service providers | on the cloud

---

US11227032B1|2022-01-18|Dynamic posture assessment to mitigate reverse engineering

---

Müller2017|Security trade-offs in Cloud storage systems

---

DE102019112485A1|2020-11-19|Procedure for selectively executing a container

---

US20200242213A1|2020-07-30|Method and system for digital rights management

---

MacSween et al.2018|Private Document Editing with some Trust

---

Kowalski2018|CRYPTOBOX V2.

---

Ziegler2017|A security concept for distributed data processing systems

---

Paracha2009|A security framework for mobile agent systems

---

EP2591583B1|2017-06-14|Method for secure communication and encryption for internet communication

---

CN111538977A|2020-08-14|Cloud API key management method, cloud platform access method, cloud API key management device, cloud platform access device and server

同族专利:

---

公开号 | 公开日

---

CA2892874A1|2015-10-22|

---

US9946884B2|2018-04-17|

---

US20160026807A1|2016-01-28|

---

WO2016015141A1|2016-02-04|

---

US20160028698A1|2016-01-28|

---

US9589144B2|2017-03-07|

---

CH709936A2|2016-01-29|

---

CA2892874C|2016-11-29|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US5933503A|1996-03-15|1999-08-03|Novell, Inc|Controlled modular cryptography apparatus and method|

---

US6490680B1|1997-12-04|2002-12-03|Tecsec Incorporated|Access control and authorization system|

---

US7412059B1|2002-11-27|2008-08-12|Voltage Security, Inc.|Public-key encryption system|

---

US7970143B2|2005-08-05|2011-06-28|Hewlett-Packard Development Company, L.P.|System, method and apparatus to obtain a key for encryption/decryption/data recovery from an enterprise cryptography key management system|

---

US7774837B2|2006-06-14|2010-08-10|Cipheroptics, Inc.|Securing network traffic by distributing policies in a hierarchy over secure tunnels|

---

GB2467580B|2009-02-06|2013-06-12|Thales Holdings Uk Plc|System and method for multilevel secure object management|

---

GB2507941B|2010-02-22|2018-10-31|Avaya Inc|Secure,policy-based communications security and file sharing across mixed media,mixed-communications modalities and extensible to cloud computing such as soa|

---

CN103294970B|2012-02-23|2015-12-09|纬创资通股份有限公司|Dual operating systems shares method and the electronic installation of encryption setting|

---

RU2618684C2|2013-04-26|2017-05-10|Закрытое акционерное общество "Лаборатория Касперского"|System and method of automatic deployment of the encryption system for users who previously worked on pc|EP3032453B1|2014-12-08|2019-11-13|eperi GmbH|Storing data in a server computer with deployable encryption/decryption infrastructure|

---

US10116440B1|2016-08-09|2018-10-30|Amazon Technologies, Inc.|Cryptographic key management for imported cryptographic keys|

---

KR101893649B1|2016-09-09|2018-08-30|두산중공업 주식회사|Method for data transmission|

---

US10218686B2|2016-10-24|2019-02-26|International Business Machines Corporation|Dynamically managing, from a centralized service, valid cipher suites allowed for secured sessions|

---

US20180124025A1|2016-10-31|2018-05-03|Riverbed Technology, Inc.|Providing visibility into encrypted traffic without requiring access to the private key|

---

EP3548007A4|2016-12-01|2020-08-12|Ignyta, Inc.|Methods for the treatment of cancer|

---

US10891385B2|2018-05-16|2021-01-12|Microsoft Technology Licensing, Llc|Encryption at rest for cloud-resourced virtual machines|

---

US10289816B1|2018-06-08|2019-05-14|Gsfm Llc|Methods, systems, and devices for an encrypted and obfuscated algorithm in a computing environment|

---

CN109657449B|2018-12-14|2020-11-03|成都三零嘉微电子有限公司|Method and equipment for realizing password resource intercommunication based on password card|

法律状态:
2018-05-15| PCAR| Change of the address of the representative|Free format text: NEW ADDRESS: HOLEESTRASSE 87, 4054 BASEL (CH) |

---

2018-07-13| NV| New agent|Representative=s name: ISLER AND PEDRAZZINI AG, CH |

优先权:

---

申请号 | 申请日 | 专利标题

---

US201462029678P| true| 2014-07-28|2014-07-28|

---

US201562121757P| true| 2015-02-27|2015-02-27|

---

US14/705,629|US9589144B2|2014-07-28|2015-05-06|System and method for cryptographic suite management|

---