5 min read

Crypto Service Gateway: Enabling Crypto-Agility with the CSG Policy Engine

Picture of Edlyn Teske Edlyn Teske : 29. October 2022

PCI DSS Key Management Policy CSG HSM Crypto-Agility
Crypto Service Gateway: Enabling Crypto-Agility with the CSG Policy Engine

Today's businesses rely heavily on cryptography to authenticate people and processes, secure communications, and safeguard critical data.

When using cryptography, a business is faced with challenges such as:

  • Ensuring that the organization uses cryptography consistently and appropriately.

  • Demonstrating compliance with internal or industry-managed security standards.

  • Quickly adapting to changes in cryptographic best-practice recommendations.

  • Ensuring that the relevant cryptographic keys are available at the correct time and location.

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

Download eBook - PQC and Crypto Agility

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. Enforcing a policy typically requires the training of application developers and performing laborious code reviews and audits. Typically, a policy update usually requires checking, updating, reviewing, recompiling, retesting, and redeploying large quantities of previous 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.

 

Proving compliance

A business will often have to demonstrate that its 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 is typically time-consuming and expensive, with individual audits to be performed on all the different projects. Each project may have a different crypto-use and mechanisms for protecting the keys.

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 bits 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, changing the key length, algorithm parameters, or even the entire underlying algorithm without disrupting the business processes.

 

Ensuring availability of cryptographic keys

As the use of cryptography within a business increases, the number of keys increases, 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:

Infographic: Crypto-Service-Gateway

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 web service, 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 communication, authentication, policy enforcement, key management, cryptography, and administration subsystems. The administration system enables operators to reconfigure the system through the CSG Administration Client. This diagram shows how the remaining subsystems work together:

Infographic-CSG-Subsystem

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 cryptosystem 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 whitelisting, meaning that only the commands listed in the policy for the respective user will be permitted. The policy 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 permitted cryptographic operation and 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:

Webapp-CSG

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.

On the other hand, an application request 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:

do-encrypt

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 does not know if the encryption is symmetric or asymmetric, what type/size of the key is utilized, what mode is employed, or what padding is necessary. 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.

 

Enabling crypto-agility

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 centralization of policy enforcement simplifies compliance audits. 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 a chaining technique that enables tampering detection for the logs at rest.

By including the policy file, usage, and audit logs in an audit significantly reduces the amount of per-project auditing.

 

 

Read White Paper

 

 

References