The business world today is built on the pervasive use of cryptography, to authenticate people and processes, to secure communications, and to protect sensitive data.
When using cryptography, a business is faced with challenges such as:
Ensuring consistent and appropriate use of cryptography throughout the organization.
Demonstrating compliance with internal or industry-managed security standards.
Quickly adapting to changes in cryptographic best-practice recommendations.
Ensuring appropriate cryptographic keys are available in the correct place at the correct time.
This article focuses on how Cryptomathic’s Crypto Service Gateway (CSG) addresses the above challenges and describes and how CSG’s policy engine enables authorization, confident compliance demonstration and crypto-agility.
Ensuring consistent and appropriate use of cryptography
It is important to make sure only authorized users have access to crypto applications. Further, these authorized users should only be able to use specific crypto commands and parameters. Both can be done through policy, which requires developing, documenting, and maintaining appropriate standards. To enforce a policy typically requires the training of application developers and performing laborious code reviews and audits. A policy update usually requires checking, updating, reviewing, recompiling, retesting, and redeploying of large quantities of existing code.
What is needed is a policy engine that separates the process of developing, enforcing, and updating policies from the application side, and performs these tasks without service interruption.
A business will often have to demonstrate that their use of cryptography to protect data and processes is in compliance with company security policies, or with regulatory frameworks such as PCI-DSS or Visa/Mastercard standards. Compliance demonstration typically is a time-consuming and expensive process, with individual audits to be performed on all the different projects, where each project may have a different use of crypto and different mechanisms how the keys are protected.
What is needed are easy-to-read centralized crypto policies and easy-to-read transaction logs.
Quickly adapting to new best-practice recommendations
While the currently recommended and standardized cryptographic algorithms and parameter choices have gone through extensive review from both academia and industry, they are subject to continued cryptanalysis. In the past, advances in integer factorization algorithms led to increased recommended key sizes for RSA, from 768 or 1024 bit to 1572 bits and higher; the previously deemed secure hash functions MD-5 and SHA-1 have been broken via practical collision attacks, which required their upgrade to SHA-2 or SHA-3. For the future, one must be prepared for continued progress in the area of quantum computing, which may eventually render most currently deployed public key cryptographic algorithms completely insecure, thereby requiring a switch to quantum-resistant cryptographic algorithms.
What is needed in a business’s cryptographic solution is Crypto-Agility, that is, being able to change the key length, algorithm parameters, or even the entire underlying algorithm without disruptive effect on the business processes.
Ensuring availability of cryptographic keys
As the use of cryptography within a business increases, the number of keys increase, as does the complexity of relations between applications and keys and HSMs.
If appropriate keys are not available at the correct place at the correct time, services may fail, data may be made unavailable and a business experience direct losses or reputational damage.
What is needed is well-orchestrated key management.
The Cryptomathic Crypto Service Gateway (CSG)
CSG is a central cryptographic management platform, a software product acting as a crypto abstraction layer between business applications and the underlying HSMs.
This is the high-level architecture:
CSG supports a wide range of cryptographic operations, from basic primitives to more advanced functions, including financial cryptography if supported by the underlying HSM. Applications integrate with CSG by using the RESTful webservice, by incorporating client libraries, or through standard interfaces such as PKCS#11, JCA and Microsoft CNG. All cryptographic functions and policy settings are managed through a remote administration client.
CSG contains subsystems for communication, authentication, policy enforcement, key management, cryptography, and administration. The administration system allows operators to reconfigure the system through the CSG Administration Client. This diagram shows how the remaining subsystems work together:
The communications system handles commands from calling applications. The authentication system identifies and authenticates applications that send commands and can use a list of local user accounts or can call out to an LDAP to verify the user’s password. The policy engine looks in the policy and checks that the command requested is allowed for a particular application and fills out any configurable crypto parameters at the same time. The key management system ensures that keys are available and looks up the correct key(s) corresponding to a particular command. The crypto system sends the command to the correct sort of HSM, using the data collated by other systems to provide everything the HSM needs.
The CSG Policy Engine
Enabling authorization through policy-based access control
CSG ensures that users are authorized to execute cryptographic operations before they are carried out. This process of authorization is controlled by the CSG policy engine and configured through CSG policy. A policy identifies one or more users/applications [or groups of users], to whom one or more permissions are assigned. Specifically, the policy works on the basis of whitelisting, meaning that only those commands specified in the policy for the corresponding user will be permitted. The police engine denies access to the HSMs for any user/request combination not contained in the active policy file.
Enabling appropriate use of cryptography
The permission that an active policy assigns to a user, or group of users, will specify the cryptographic operation that is permitted, and will link to the appropriate key that must be used. The permission will also specify a set of cryptographic parameters, i.e., the algorithm/mode of operation, which type of padding will be used, etc. An example of a policy is shown below:
This policy snippet allows an application identified as “LOCAL:WebApp” to perform encryption using 256-bit AES, in CBC mode with PKCS#7 padding and a randomly generated IV.
An application request on the other hand will not have to specify how the data will be encrypted. Such requests are described using the Crypto Query Language (CQL), which is easy to read, even for people unfamiliar with cryptography. For example an encryption request from the user LOCAL:WebApp could read as:
Here, "DO ENCRYPT" tells the CSG policy engine that encryption is required, “FROM Alice TO Bob” indicates which key to use, and
“WITH DATA 4865….” provides the plaintext to encrypt.
The issuer of the application request is unaware whether this is symmetric or asymmetric encryption, which type/size of key is used, what mode is used or what padding is required. This is defined in the policy, written by specialized and trusted security officers. The security officers, and not the users, make all critical security decisions on which algorithms and keys to use.
The complete separation of the security policy from the application code allows for easy policy updates, should this be required by sudden breakthroughs in cryptoanalysis, changes in standards or best-practices recommendations, or to achieve quantum readiness. The security officers will make the changes to the policy file, which then will be uploaded by administrators (under dual control), provided it is signed by two signatories. The uploaded policy will either take effect immediately or at a scheduled time in the future. The application code developers are completely oblivious to any changes.
Enabling confident compliance demonstration
The centralized policy enforcement makes compliance audits simple. The policy file describes all cryptographic operations, and all parameters used by each operation; its simple text-based structure helps auditors and operators understand the contents without needing to be crypto experts.
Further, CSG is recording events in various logs, including a
detailed usage log that captures how applications use the cryptographic services, and
an audit log that captures any changes made to the configuration of CSG such as policy changes.
Both logs are signed and secured using chaining technique that enables tampering detection for the logs at rest.
Including the policy file and the usage and audit logs in an audit significantly reduces the amount of per-project auditing.
- Selected Articles on Crypto-Agility (2017-today), by Dawn M. Turner, Edlyn Teske, Rob Stubbs, Terry Anton and more
- What is Crypto-Agility? (2018) by Jasmine Henry
- Cryptographic Key Management Concepts: on Key Generation, Metadata, Life-cycles, Compromise and more (2019), by Rob Stubbs
- Selected Articles on Quantum Cryptography (2017-today), by Dawn M. Turner, Rob Stubbs, Terry Anton and more
- Study on Cryptography as a Service (CaaS) by Yudi Prayudi and Tri Kunturo Priyambodo, November 2014.
- NISTIR: Report on Post-Quantum Cryptography by the National Institute of Standards and Technology, April 2016.
- Cryptomathic Answers Compliance-Driven Call for Crypto-Agility by Cryptomathic, May 2018.