Patent Application
20230109647
The present disclosure relates generally to context aware cipher solutions, and more specifically, intelligently creating and managing cipher solutions for cryptographic operations.
The demand for improvements in cryptography-based security measures continues to increase and scale with the increasing ability of processors to break and defeat cryptography-based security measures. Substantial increases in processing power associated with the introduction of quantum computing makes these improvements even more necessary. Unfortunately, conventional cryptographic frameworks or configurations are statically compiled or linked into the software applications and systems. This makes adapting to the rapidly changing security threat environment slow and costly since programmers are often needed to make manual changes to the software applications and systems to implement changes that keep the software applications and systems secure. In extreme circumstances, these systems and applications may be forced to reduce functionality or even shutdown until they are able to implement cryptographic features needed to ensure secure operations. Consequently, solutions for reducing the overhead and time needed to implement cryptographic configurations or cipher solutions with abilities to quickly make adjustments or changes to the configurations depending on a user's requirements and circumstances are desirable.
This disclosure describes automated configuration or adjustment of cipher solutions based contextual data surrounding secure communications.
A computer implemented method is performed on an electronic device, and includes the following: receiving a request initiated by a requestor for one or more cryptographic operations, determining contextual information associated with the requestor, selecting a cipher solution for processing the request based on the contextual information and a policy engine, and processing the request for the one or more cryptographic operations by executing one or more cryptographic algorithms in accordance with the selected cipher solution.
A non-transitory computer-readable storage medium that stores instructions configured to be executed by one or more processors of an electronic device is disclosed. The non-transitory computer-readable storage medium when executed by the one or more processors cause the electronic device to carry out steps that include: receiving a request initiated by a requestor for one or more cryptographic operations, determining contextual information associated with the requestor, selecting a cipher solution for processing the request based on the contextual information and a policy engine, and processing the request for the one or more cryptographic operations by executing one or more cryptographic algorithms in accordance with the selected cipher solution.
An electronic device is disclosed and includes one or more processors; and memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for: receiving a request initiated by a requestor for one or more cryptographic operations, determining contextual information associated with the requestor, selecting a cipher solution for processing the request based on the contextual information and a policy engine, and processing the request for the one or more cryptographic operations by executing one or more cryptographic algorithms in accordance with the selected cipher solution.
Other aspects and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the described embodiments.
The disclosure will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements.
Certain details are set forth below to provide a sufficient understanding of various embodiments of the invention. However, it will be clear to one skilled in the art that embodiments of the invention may be practiced without one or more of these particular details. Moreover, the particular embodiments of the present invention described herein are provided by way of example and should not be used to limit the scope of the invention to these particular embodiments. In other instances, hardware components, network architectures, and/or software operations have not been shown in detail in order to avoid unnecessarily obscuring the invention.
Cipher solutions and cryptographic algorithms are a foundation of security protocols used by many software applications and systems for secure communications. Due to cyber security threats from quantum computing, malware, phishing, and the like, cybersecurity algorithms are constantly evolving to protect against evolving cyber threats. Updating software applications or systems to incorporate latest cybersecurity algorithms and security protocols using existing interfaces can be complicated and may require a user or an organization to spend a considerable amount of time and resources (e.g., a team of developers).
In addition to constantly updating the cryptographic algorithms and security protocols, software applications may require to support alternative cryptographic algorithms and/or security protocols depending on state or context of the user using the applications or system, a state of the device used by the user for accessing resources, and the like. For example, weak or compromised algorithms may need to be replaced with strong algorithms when a user is trying to access a resource from a network at high security threat area. Accordingly, Depending on the circumstances, different algorithms from a range of cryptographic algorithms may be required for protecting secure data. Incorporating a range of advanced algorithms within existing systems or applications may require extensive work at significant cost and the implementation may cause delays if various algorithms are not widely accepted.
One way in which cryptography-based security measures can be improved is to configure cipher solutions, upon which the security measures are based, with the ability to quickly make adjustments. For example, this allows a compromised cryptographic feature employed by an existing application to be quickly replaced with a more secure cryptographic feature. The ability to rapidly reconfigure the cipher solutions or cryptographic frameworks also allows the cryptographic frameworks to be configured to leverage different features or entire cryptographic libraries based on specific use cases. For example, in response to a request for services from a device operating outside of a trusted computer network, the service could be configured to leverage more secure cryptographic features and/or libraries in order to satisfy security policies. This ability for the cryptography framework to agilely reconfigure allows users operating on more secure networks or from more secure locations to benefit from lower overhead cryptography, while maintaining higher security only when needed.
The present embodiments also enable automated selection of one or more cryptographic libraries and/or algorithms based on contextual data surrounding a cryptographic transaction (e.g., a request for secure communication). The contextual data may indicate sensitivity of data being protected, user's role participating in a data exchange or communication, the communication network detail, the characteristics of devices involved, the nature of the application, and the like.
The ability to automatically select among cryptographic algorithms and key configuration parameters for optimal protection based on the context data allows cipher solutions to be configured to leverage multiple cryptographic libraries. The cryptographic selection system, discussed in the present embodiments, allows an application or system to consume different libraries or algorithms it may require in a given circumstances by intercepting the application's calls associated with cryptographic operations. The cryptographic selection system, discussed in the present embodiments, further enables the application or the system to provision more than one cipher solutions including cryptographic library implementations.
These and other embodiments are discussed below with reference to
Cryptographic provider 204 is then responsible for processing the API calls received from the cryptographic shim and interacts with two primary modules: policy manager 208 and library manager 210 to assist in executing the abstracted cryptographic API calls generated by application 200.
Library manager 210 is configured to manage cryptographic libraries. While library manager 210 is depicted managing cryptographic libraries 212 and 214 it should be appreciated that library manager 210 can be configured to manage any number of cryptographic libraries needed to support the operation of application 200. Library manager 210 is responsible for providing access to one or more cryptographic features included in cryptographic libraries 212 and 214 in response to the API calls received by cryptographic provider 204. Library manager 210 is also configured to assist with updating existing cryptographic features and registering new cryptographic features. A cryptographic feature can take the form of a cryptographic algorithm, protocol, function, or combination of cryptographic algorithms, protocols or functions.
In some embodiments, library manager 210 includes a mapping table 211, which associates particular cryptographic features with tags configured to associate the cryptographic features contained within cryptographic libraries 212 and 214 with particular functions and capabilities. Whenever updates are made to one of cryptographic libraries 212 and 214, library manager 210 is configured to update mapping table 211 to associate any new or updated cryptographic features with one or more tags.
New cryptographic features can be added to cryptographic selection system 201 by first referencing algorithms/implementation table 216, which can include a listing and/or locations of all potential cryptographic algorithms, libraries, functions, rules and the like compatible with cryptographic provider 204 and then selecting one or more cryptographic features from algorithms/implementation table 216 for registration with cryptographic selection system 201. It should be noted that, while algorithms/implementation table 216 is depicted as being directly attached to library manager 210, algorithms/implementation table 216 can also be maintained and/or stored at a location outside of an attached storage or a local network.
In some examples, library manager 210 can be managed using a user interface operated through application 200 and/or through another management application. The user interface allows a user to register one or more new cryptographic features listed in algorithms/implementation table 216 to update cryptographic selection system 201. For example, an administrator could access the user interface to configure one or more of the cryptographic libraries with cipher suites supporting different bit rates or types of encryption.
Policy manager 208 is responsible for managing policy engine 218. Policy engine 218 can take the form of a user-defined and/or autonomously compiled list of policies that establish rules for the operation of cryptographic selection system 201. Policy engine 218 can be implemented as a rule engine, a table, a neural network or the like. The list of policies stored in policy engine 218 affect how library manager 210 of cryptographic provider 204 operates to manage implementation of various cryptographic features included in cryptographic libraries 212 and 214. When an API call is received at cryptographic provider 204, cryptographic provider 204 leverages the list of policies contained in policy engine 218 and managed by policy manager 208 to select one or more cryptographic feature suitable for handling the abstracted cryptographic API call. In some embodiments, policy engine 218 specifies a particular cryptographic feature or features contained within one of cryptographic libraries 212 and 214 for use in response to an API call.
In some embodiments, a policy associated with the API call specifies a tag identifying a solution class defined and maintained within mapping table 211. The identified cryptographic feature or tag is then transmitted to library manager 210. In the case a tag is transmitted to library manager 210, library manager 210 uses mapping table 211 to identify which cryptographic feature or features is associated with the tag. Library manager 210 then instructs cryptographic provider 204 which cryptographic feature or features to implement in response to the received API call. It should be noted that in some embodiments an API call can be associated with multiple tags. This set of cryptographic features used in responding to the API call can be referred to as a cipher solution. This system of using tags associated with functionality in the policy engine instead of particular cryptographic functions allows library manager 210 and policy manager 208 to operate independently from one another. This reduces the need for coordination between the library and policy managers outside of passing tags from the policy manager to the library manager. It should be noted that while
In some embodiments, the abstracted cryptographic API call can take the form of a request for data encryption of a particular type of data. A first policy associated with the API call can specify that the encryption for that type of data be of a specific type (e.g., FIPS compliant encryption) and a second policy associated with the API call can specify that the encryption be of a minimum security strength (i.e. number of bits) or key size for the specified type of data associated with the API call.
In some embodiments, policy engine 218 can be managed at least in part autonomously by making changes to enterprise policies 220. Enterprise policies 220 is one of cryptographic usage/context information sources 219 and are generally managed by a network administrator, allowing for hierarchical network-wide implementation of policies for managing multiple applications having cryptographic frameworks in accordance with the described embodiments. In some embodiments, policy engine 218 can include policies selected based on user context 222, organizational context 224 and/or additional information 226. User context 222 can include data such as a user's location, the user's identity, the nature of the data to be protected, the user's access level, the speed and/or characteristics of the local network the user is accessing, the geographic location of the user, the application context and more. In embodiments where policy engine 218 includes tags identifying particular desired functionalities, in lieu of specifying particular cryptographic features, policy engine 218 assigns the policies it manages tags configured to meet security requirements specified by the enterprise policies.
In some examples, user context 222 would be supplied to cryptographic provider 204 to assist in selection of the right cryptographic feature to meet a respective abstracted cryptographic API call. For example, a policy stored within policy engine 218 could specify that higher minimum levels of encryption are required for users operating outside of a trusted network environment. The higher minimum level of encryption can be specified by a particular tag in the policy corresponding to a specific level of encryption associated with that tag and identified in mapping table 211. When user context 222 indicates the user is operating outside the trusted network, that higher minimum level of encryption rule would be applied when cryptographic provider 204 is selecting a suitable cryptographic feature for responding to a respective API call.
In some examples, entire cryptographic libraries can be dedicated to handling API calls associated with users of a specific type or operating from a particular location. Organizational context 224 can apply in a similar manner to user context 222. For example, applications grouped under a first organization might have a different set of policies than applications grouped under a second organization. These types of policies would generally be implemented by an information security IT team for each organization. For example, the organizational policies might specify different cryptographic features be used in different regions of the world or that different cryptographic features be used based on which business sector or project the request for access is associated with. In some embodiments, certain policies such as FIPS compliant cryptography could be required for all communications associated with a particular company or organization.
Additional information 226 can include other types of contextual information, such as, for example, certificate alert information for a particular usage context (e.g. transactions utilizing systems running Windows 10 versions a threshold number of versions old and/or versions containing a known critical security vulnerability can be identified as they may require additional security mitigation).
In some examples, the client device 310 may interact with at least one server(s) or other computing device(s) over a communications network. The client device 310 may communicate with other computing device(s) or servers (e.g., application 200) over a network directly or indirectly via any suitable intermediate device(s) or network(s). For example, the client device 310 may communicate via one or more cellular base stations or one or more wireless access points such as IEEE 803.11. In some examples, the client device 310 may direct a user's request to an application 200 within the system 300. The application 200 may be a web application, a computing environment hosted on a server, or a data file on a server. In some examples, the application 200 may be installed on the client device 310 or is accessible from the client device 310 using a web browser.
In some examples, the application 200 may enable a user to perform different actions such as accessing one or more resources or secure data at a server, securely communicate with other devices, and the like from the client device 310. A server hosting the application 200 may be any type of known computer, server, or data processing device. The server may further include RAM, ROM, network interface, input/output interfaces, and memory. The one or more resources or secure data may reside on a server hosting the application 200 or on a different device or a server connected to the application 200 through the network, via direct or indirect connection or some other network.
In some examples, a user's requests or queries from client device 310 are directed to the application 200. The application 200 may be capable of handling cryptographic operations involving modern cryptography standards using the cryptographic selection system 201. The cryptographic selection system 201 enables automated configurations and adjustments to cipher solutions for providing secure data access, communications and other operations for the application 200. Specifically, the cryptographic selection system 201 enables automated selection and configuration of cryptographic libraries (or algorithms within libraries) based on contextual information (e.g., user context 222) or key facts surrounding the user and user device such as user's access level, the speed and/or characteristics of the network the user is accessing, the geographic location of the user, the sensitivity of data being protected, user roles participating in a data exchange, the network context, the characteristics of devices involved, the nature of the application, and the like. In some examples, contextual information may be a user's identity, a device type (e.g., personal, company, etc.), nature of data (e.g., confidential, person, public, etc.), nature of application (e.g., company database, web service, etc.), network (e.g., enterprise or outside US), and the like.
Based on the contextual information, sets of policies and available libraries, the cryptographic selection system 201 automatically selects among cryptographic algorithm alternatives and key configuration parameters for optimal protection to operations involving the application 200. The cryptographic selection system 201 may determine a situation surrounding the user and the user's device, determines what cipher solution (e.g., selection of algorithms and/or libraries) is required to process the user's transaction(s), and configure or select a cipher solution for processing the user's request(s). In some examples, the cipher solution is a solution or framework required for one or more cryptographic operations for processing a user's request for one or more operations involving the application 200. Specifically, a cipher solution is a selection of one or more libraries, algorithms, functions, or processes. Updates to the cipher solution can be based on cryptographic policies, available algorithms and libraries, and contextual information.
In some examples, the application 200 includes a cryptographic API (e.g., 202 as shown in
In some examples, library manager 210 is configured to manage cryptographic libraries. In some embodiments, library manager 210 can include one or more cryptographic libraries. Each of the cryptographic libraries can be configured to be implemented in accordance with information provided by policy manager 208. In some examples, the library manager 210 can be managed using a user interface operated through application 200 and/or through another management application. In some examples, the library manager 210 can be managed by an API used to build configurations related user interface applications. In some examples, policy manager 208 may have access to one or more user-defined, enterprise policies and/or autonomously compiled list of policies dictating the operation of cryptographic provider 320. The list of policies affect how library manager 208 operates to manage implementation of various cryptographic features governed by cryptographic libraries.
In some examples, the policy engine 218 may include mapping between contextual information (e.g., user context data 222) associated with the user and one or more cipher solutions. A cipher solution may be a framework or configuration identifying one or more algorithms and/or libraries for handling cryptographic operations. In the above examples, a software system or application may be used within an organization to configure the policy engine 218. The application may configure the policy engine 218 with policies for data centers, edge computing environments, federated cloud information, and other infrastructure components. The application may allow a user to create, modify, and maintain cryptography operations within the organization after configuring the components with the policy engine 218. An example policy may suggest that if a user or client device is outside the company network then use a TLS 1.3 protocol for cryptographic operations. An example policy may suggest if a communication from the client device is related to a health care application then use FIPS-certified suite. An example policy may suggest if the application 200 includes confidential product roadmap information or intellectual property then use a hybrid quantum safe cipher suite for the communication involving the application.
In some examples, the policy manager may map contextual information with a class or a tag instead of a specific library or algorithm. The nature of the class may be determined by a user of cryptographic selection system 201. A class may identify a level of crypto security that should be used and further provide distinctions that an organization would find meaningful. For example, different classes may be designated for different categories such as top secret, confidential, FIPS, non-FIPS, hand-held device policy, server policy, and the like.
In some examples, a cryptographic standard may be designated as a class that is matched to tags registered within a library. In the above example, according to an example policy, if the user of client device 310 is operating in Iran and provides a request to access classified data, then a cipher solution associated with a class tag “Class: Classified” may be used. In the cryptographic library (e.g., 214) there may be multiple cipher solutions (e.g., quantum safe cipher solution). A different cipher solution matching the same tag may be used based on the context of use. For example, if the user is trying to access data from Iran instead of the United States a more robust cipher solution could be selected. In some examples, a tag may be a set of Boolean conditions which may chain several inputs with logical OR/AND conditions between the inputs (or contextual information). The tag may govern a selection of a cipher solution from registered cipher solutions in the library. For example, a tag may be if a user is a senior executive AND the user is “outside of the home country,” then apply a cipher solution of class “XYZ.” In some examples, a list of policies may be mapped to users' profiles. Accordingly, upon detecting a specific user, a set of policies and tags associated with the user's profile may be used for processing the user's request for actions involving cryptographic operations.
In some examples, the mapping table 211 may be a separate table from the policy engine 218 that includes mappings or pointers between tags or classes from the policy engine 218 to one or more libraries or cryptographic algorithms accessible by the library manager 210. The mapping table 211 may include mappings or pointers between one or more cryptographic algorithms or libraries (within algorithms table 216) and one or more policy data (e.g., class or tags associated with the policy engine 218). The mapping table 211 may act in conjunction with a policy engine or can also take over the functions of the policy engine (see, e.g., policy manager 208 from
In the above examples, a user of the client device 310 may request to access one or more secure data or resources associated with the application 200. Accordingly, a user request for accessing secure data or resources may be generated. In some examples, upon generating the user request, the client device 310 may direct the user request to an IP address (using IPv4 or IPv6 protocol format) of a server hosting the application 200. The client device 310 may direct the packets containing the user request and user's contextual information to the application 200. The contextual information may include information associated with the user, the client device 310, the network connection used by the user, or any other information associated with the user, device and/or network used by the client device 310. The contextual information can include a location of the client device 310, determined using, e.g., an IP location or GPS location of client device 310. The contextual information may be determined when a user of the client device 310 requests an access to certain applications or data. The contextual information is shared with the policy engine 218 for the policy engine 218 to select an appropriate cipher solution. Contextual information can also change after the request for access and while the data is being accessed. For example, if client device 310 is a portable device, the location of client device 310 can change, which can trigger an evaluation to determine whether the cipher solution needs to be changed.
In some examples, different sets of mechanisms may be used to collect contextual information to be used by the cryptographic selection system 201. The application 200 may provide context information to the provider 204 (or a processor associated with cryptographic selection system 201) using API calls. In some examples, the provider 204 may check operating system or container level information including configuration data for application 200 and client device 310 to determine contextual information. Further, information about the user's configuration may help determine contextual information. For example, if the application 200 is configurable using API or UI, the provider may determine that the application 200 may be using a certain standardized approach (e.g., FEDRAMP). In some examples, contextual information may be determined based on inspecting packets from the client device 310. In some examples, an organization may have software that collects the contextual information and makes the information available via an API or file that is available to the policy manager 208. Alternatively, the policy manager 208 may collect the activities associated with the contextual information from the operating system and other information sources.
In the above examples, to further process the user's request, the crypto shim 206 may intercept a call or request for cryptographic operations within the application 200 and redirects the calls or the requests to the cryptographic provider 204. Within the application 200, security operations may be performed over the cryptographic selection system 201. In the above examples, the cryptographic provider 204 or policy manager 208 may obtain and analyze the contextual information received. For example, the cryptographic provider 204 may identify the location of the user's device based on the contextual information. Similarly, the cryptographic provider 204 may determine other information specific to the user, user device, network security of the user device, and type of access requested by the user.
In some examples, a device or client associated with the provider 204 may obtain contextual information by requesting a communication session with an application server associated with the application 200 and/or client device 310. The context information is then used by the policy manager 208 to make an automated decision on which cipher solution to use or change in the configured cipher solution. In some examples, if the user requests access to highly sensitive data from the application 200, the application 200 can signal the policy engine 218 to invoke a change in a cipher solution based on the changed data access context (e.g., location of the user device 310).
The cryptographic provider 204 may further compare the contextual information with corresponding policies and tags/classes within the policy engine 218. The policy engine 218 (or the cryptographic provider 204) may determine a cipher solution (or selection of libraries and/or algorithms) for performing the cryptographic operations for processing the user request.
In the above examples, upon determining the cipher solution for processing the user's request, the cryptographic provider 204 executes the one or more algorithms according to the cipher solution to authenticate or process the user's request. The one or more cryptographic algorithms can include a one way hash function, symmetric key encryption, public key encryption, digital signature, and other types of predefined or customized cryptographic algorithms. Accordingly, proper security measures are followed in processing the user's request to ensure secure communication. In the above examples, a policy and libraries (or algorithms within the libraries) are instantiated in real-time for configuring the cipher solution based on the contextual information.
In alternative examples, the cryptographic provider 204 may have a default or present cipher solution defined for all user's requests. Accordingly, upon receiving the user's request and contextual information, the cryptographic provider 204 may evaluate the present or default framework configured for processing the user's request. In some examples, the cryptographic provider 204 may determine that the present cipher solution (e.g., cryptographic algorithms) is not suggested for processing the user's request based on the received contextual information and the mapping table 211. In the above examples, the cryptographic provider 204 may change or adjust the present cipher solution to include one or more different cryptographic algorithms and/or libraries. Alternatively, the cryptographic provider 204 may determine that the current framework does not need to be updated in accordance with the contextual information.
In alternative examples, the cryptographic provider 204 may compare contextual information with the contextual information associated with the present or default configuration or framework for performing cryptographic operations. If the contextual information is unchanged, the provider 204 does not further evaluate the contextual information against the mapping table 211 and uses the default or present framework for processing the user's request.
In some examples, in response to determining that the present or default cipher solution needs to be updated, the cryptographic provider 204 updates or reconfigures the cipher solution based on the contextual information and mapping table 211. Upon implementing an update to the cipher solution, the cryptographic provider processes the user request by executing the selected cryptographic algorithm(s) in accordance with the updated cipher solution. The above described process may be performed every time a user request needs to be processed using cryptographic operations within the application 200. Alternatively, the cryptographic provider 204 may select a cipher solution from a list of cipher solutions based on the contextual information and mapping table 211.
In the above examples, as discussed, the policy manager 208 may determine which cipher solution to use based on contextual information. The policy engine 218 may take a set of inputs (e.g., context information), process the inputs with rules or policies, and output a tag representing a class of a cipher solution needed for processing the user request. Upon receiving information about a required cipher solution from the policy manager 208, the information may be forwarded to the library manager 210 using one or more APIs supported by the library manager 210.
Upon receiving the information, the library manager 210 may identify correct libraries and obtain access to the libraries using either direct or intermediary mode. In the above examples, a cryptographic library may have one or more cipher solutions with parameters registered and tagged to a same tag that is outputted from the policy manager 208. In direct mode, the library manager 210 may make a call to access the required libraries and/or algorithms and direct the output (pointers to the set of libraries or algorithms) back to cryptographic provider 204 caller (e.g., application 200). In intermediary mode, the library manager 210 may make a call to access the required libraries and/or algorithms and direct the output (pointers to the set of libraries or algorithms) back to the cryptographic provider 204 caller (e.g., application 200) with no indirection turned off. In contrast, in intermediary mode with indirection turned off, the library manager 210 may make a call to access the required libraries and/or algorithms and in response only receives the specific libraries it requested. If the required library references other libraries, with indirection turned off, the library manager 210 does not retrieve the other libraries. A built-in indirection function may provide an access to a library and/or algorithm pointed-to by another library and/or algorithm.
In the above examples, in response to the user's request, a call to the cryptographic provider 204 is directed to a specific cryptographic library, an algorithm family within a cryptographic library (from the algorithms table 216), or a specific function call associated with the algorithm family using different types of input parameters required by the algorithms. In other examples, the steps of communication between cryptographic provider 204, library manager 210 and policy manager 208 may vary with different methods of operations. Additional scenarios and examples of automated cipher solution selection and updates are described in
In some examples, a user's requests or queries from client device 310 are directed to the application 200 are received at a proxy 314. The proxy 314 may include functions, rules or operations for processing security related protocols, such as SSL or TLS. The proxy 314 may serve as a front-end authentication and communication dispatch system. For example, the proxy 314 may encrypt or decrypt network packets associated with the user's request.
In the above examples, the proxy 314 may act as a load balancer for the application 200 to incoming traffic from the internet and/or other networks. The proxy 314 may be deployed alongside the application 200 where the outside world interacts with the application 200 through the proxy 314. The proxy may be an envoy proxy, reverse proxy, or a different type of proxy embedded to the application 200. The proxy 314 may be capable of handling cryptographic operations involving modern cryptography standards.
In some examples, the proxy 314 may act as a load balancer for the application 200 to incoming traffic from the internet and/or other networks. Along with balancing incoming traffic, the proxy 314 may implement TCP (or SSL) protocols. The proxy 314 may include a TLS endpoint proxy 316. The TLS endpoint proxy 316 may act as an intermediary point between the client device and proxy 314, and used to establish and/or terminate TLS tunnels by decrypting and/or encrypting incoming and outgoing communications. The TLS endpoint proxy 316 may set up SSL or TLS connection on behalf of the client device and/or application 200. The proxy 314 may be deployed alongside the application 200 where the outside world interacts with the application 200 through the proxy 314.
In some examples, the system 400 may further include cryptographic selection system 201. The cryptographic selection system 201 enables automated configurations and adjustments to cipher solutions for providing secure data access and communications, as discussed in
In some examples, a user using the client device 310 may request to access one or more secure resources, request a secure communication, or perform some other actions involving the application 200 that involves one or more cryptographic operations. Accordingly, a user request from the client device 310 may be generated. In some examples, upon generating the user request, the client device 310 may direct the user request to an IP address (using IPv4 or IPv6 protocol format) of a server hosting the application 200.
In the above examples, the client device 310 may direct the packets containing the user request and user's contextual information to the application 200. The packets directed to the application 200 may be received at the proxy 314 within Transport Layer Security (TLS) agility 312. The proxy 314 may encrypt or decrypt network packets associated with the user's request and set up SSL or TLS connection on behalf of the client device and/or application 200. In some examples, TLS endpoint proxy 316 receives the user request via an established TLS tunnel and may decrypt the user request for further processing. In some examples, upon receiving the user request, the proxy 316 may handover cryptographic operations to cryptographic provider 204 via cryptographic shim 206. The crypto shim 206 may act as a library that intercepts a call or request for additional cryptographic operation within the proxy 314 and redirects the call or the request to the cryptographic provider 204.
In the above examples, the cryptographic provider 204 obtains and analyzes the contextual information using various methods described in
In the above examples, the cryptographic provider 204 may determine the cipher solution for processing the user's request. In the above examples, upon determining the cipher solution for processing the user's request, the cryptographic provider 204 executes the one or more algorithms according to the cipher solution or selected algorithms to process the user's request. In the above examples, a policy and libraries (or algorithms within the libraries) are instantiated in real-time for configuring the cipher solution based on contextual information associated with the user, client device 310, and/or network used by the client device 310.
In the above examples, upon processing the user's request, the request may be forwarded to the application 200 (or one or more servers associated with the application 200) for further processing of the user's request. Specifically, the application 200 may receive authorization or results based on the execution of the one or more algorithms by the cryptographic provider 204.
Control plane 528 of
In some embodiments, outgoing communications from multiple cloud services that are all intended for a single recipient and are routed through edge gateway 526 might all implement the same cryptographic features, allowing for a single call to the policy manager 530 within control plane 528 to handle the cryptographic feature implementation for the multiple cloud services. It should be noted that, edge gateway 526 can also be used to facilitate communication between policy manager 530, library manager 532 and individual cloud services when handling requests that apply only to a particular one of cloud services 502-510.
In step 602, an electronic device may receive a request for one or more cryptographic operations from a requestor. In some examples, the requestor is a user, an entity, an organization or a service using the electronic device. In some examples, the request for the one or more cryptographic operations may be associated with accessing at least one of electronic device data, communication network data, or one or more server applications. In some examples, the cipher solution includes a selection of one or more libraries or one or more cryptographic algorithms within the one or more libraries for one or more cryptographic operations for processing the user's request.
In step 604, the electronic device may determine contextual information associated with the requestor. In some examples, the contextual information includes information associated with the electronic device, a communication network used by the electronic device, an organization associated with the electronic device and a user of the electronic device. In some examples, the contextual information may include user data (e.g., user context 222) which can include data such as a user's location, the user's access level, the speed and/or characteristics of the local network the user is accessing, the geographic location of the user and more. In some examples, the contextual information may include device data or entity data (organization context 224) such as security measurements on the device, security requirements from the organization, and the like.
In step 606, the electronic device selects a cipher solution for processing the request based on the contextual information and a policy engine. In the above step, the policy engine (e.g., 218) includes mapping between at least one of one or more policies, classes, tags, user profiles and the contextual information. In the above step, selecting the cipher solution for processing the request requires selecting one or more libraries or one or more cryptographic algorithms within the one or more libraries based on policy information in accordance with the contextual information, the policy engine, and the mapping table. In the above step, upon selection of one or more libraries and/or algorithms, the electronic device may configure the one or more libraries or the one or more cryptographic algorithms within the one or more libraries to process the user's request. In the above steps, for selection of one or more libraries and/or algorithms, a processor (e.g., cryptographic provider) within the electronic device may interact with processors associated with policies and/or libraries (e.g., a policy manager 208 and/or library manager 210).
In some examples, exact matching algorithms or libraries may not be available in the mapping table (e.g., 211) for contextual information or context data associated with the user, the user device, and/or the network used by the user device. In such scenarios, different methods may be implemented for identifying and selecting algorithms and/or libraries for processing the request from the requestor. For example, in some examples, multiple algorithms may be identified based on different contextual information. For example, based on the user's geographic location, the policy engine 218 may suggest a cipher solution. At the same time, based on the user's network detail, the policy engine 218 may suggest executing a different cipher solution. In such instances, contextual data may be assigned different weights. For example, contextual data related to an unsecured or compromised network may be given higher weight over low risk geographic location of the user. Based on the weights associated with the contextual data, different cipher solutions associated with contextual information may be ranked. For example, if an unsecured or compromised network is given higher weight over a low risk location of the user, then a cipher solution associated with the compromised network is given a higher rank over the set of algorithms associated with the low risk location. In some examples, the customer or user may configure how the ranked cipher solutions or algorithms and/or libraries associated with cipher solutions are to be used for processing requests from the different requestors.
In some examples, a customer may configure policies to be flexible or inflexible. In an example embodiment, a best effort setting or policy may be available when no matching tags, classes, libraries or algorithms are available for a specific context. Accordingly, a cipher solution associated with the best effort setting may be used when no matching tags, classes, libraries, or algorithms are available for a specific context. In some examples, users may tag one or more libraries or algorithms based on how much they trust the libraries and algorithms. In some examples, a user may choose to enforce a minimum cryptographic security setting for any given context. A policy engine (e.g., 218) may directly map a certain contextual information with required minimum security settings. The policy engine may associate the minimum security settings with the one or more tags, classes, algorithms, and/or libraries. For example, for a user located at X location, the minimum security required may be defined. In another example, a minimum security may be set for a specific type of device. For example, an android device may require a minimum security of 5. When a user makes a request using the android device and there is no exact match, a set of approved cipher solutions or selection of libraries and/or algorithms with a security score of at least 5 may be used to process the user's request.
In step 608, the electronic device processes the request by executing one or more cryptographic algorithms in accordance with the selected cipher solution. The electronic device may access one or more selected libraries or algorithms within the libraries in accordance with the selected cipher solution, and execute the algorithms within the libraries.
In step 702, an electronic device receives an event. In some examples, a user can associate any type of state change as an event. The event may be any event associated with the electronic device, a user of the electronic device, or network associated with the electronic device. For example, if a user starts compiling an application, the initiation of compilation may be identified to an event. Similarly, deploying provisioning for a web application may be identified as an event. In another example, powering on or off the electronic device may be identified as an event. Similarly, if a user starts a web session on a certain device, the session initiation may be identified as an event. A user may identify any updates to policies, libraries, or algorithms within libraries as an event.
In some examples, an event may refer to a relevant change to contextual information. For example, a client may move into an enterprise network from outside of it during an application session and request access to data that is confidential. The move may enable a change to the context and further impact on cryptographic operations used during the application session. Accordingly, the move (a change to contextual information) may be identified as an event. A change to contextual information may affect the cipher solution selection. For example, the context for a particular use of a cipher solution may change when the user moves from outside to the inside of the enterprise network. In this case, an event trigger can generate automatically a request to a processor within the electronic device (e.g., the Policy Manager 208) to re-evaluate the class or tag to be used for cryptographic operations.
In step 704, the electronic device may determine contextual information associated with the event and the electronic device. In some examples, contextual information associated with the electronic device may be a location of the device, network information associated with the electronic device, and the like. In some examples, contextual information associated with the event may be detail of the event (e.g., session start time). In the above step, cryptographic provider 204 may obtain and evaluate the data associated with the electronic device and the event to determine the contextual information needed for configuring or selecting a cipher solution.
In step 706, the electronic device may configure a cipher solution for the electronic device based on the contextual information and a policy engine. In the above step, the cipher solution includes one or more libraries or one or more cryptographic algorithms within the one or more libraries for one or more cryptographic operations authorizing the request for accessing the one or more resources. In the above steps, configuring the cipher solution for the electronic device based on the contextual information, the policy engine, and a mapping table includes selecting one or more libraries or one or more cryptographic algorithms within the one or more libraries based on policy information. Specifically, to configure a cipher solution, one or more classes or tags are selected based on policy information in accordance with the contextual information associated with the event and the electronic device. Further, one or more libraries or cryptographic algorithms associated with the selected tags or classes are determined based on information within the mapping table. Accordingly, the determined libraries or algorithms are configured for cryptographic operations on the electronic device. Upon configuring the cipher solution, one or more cryptographic operations on the electronic device may be performed in accordance with the configured cipher solution.
The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.
