Digital Developer Conference: Cloud Security 2021 -- Build the skills to secure your cloud and data Register free

Use IBM Cloud Hyper Protect Crypto Services to build an Edwards Curve signing server

Summary

This code pattern shows you how to build and run an example signing server application. The signing server application provides example REST APIs to create signing keys, to sign data using an Edwards Curve signing mechanism, and to verify signatures. The application is deployed in a secure environment provided by IBM Cloud Hyper Protect Virtual Server, and it integrates with IBM Cloud Hyper Protect Crypto Services and IBM Cloud Hyper Protect DBaaS to securely create, use, and store private keys and other sensitive information. The signing server is implemented in Java on the basis of Open Liberty.

Description

In this code pattern, you use Hyper Protect services to securely build, deploy, and run the signing server. The signing server is made available in the public cloud for easy access, while maintaining the protection of the signing server application and data, both in use and at rest. To achieve this high level of security, you use IBM Cloud Hyper Protect Virtual Server Secure Build Server to build the signing server application image in a secure environment. You then deploy and run the signing server in a secure enclave provided by Hyper Protect Virtual Server. Consequently, even a cloud provider or administrator cannot access your build process, your build results, the signing server application, or your data.

The signing server uses the Enterprise PKCS #11 over gRPC (GREP11) API to create keys, sign data, and verify signatures in a Hyper Protect Crypto Services instance, and it securely keeps and stores signing keys in a Hyper Protect DBaaS MongoDB instance.

When you have completed this code pattern, you will understand how to:

  • Use and invoke the Enterprise PKCS #11 over gRPC (GREP11) API from Java code
  • Create an AES key-encryption key for encrypting the private signing keys that are returned by the GREP 11 API and securely store this key-encryption key in the local file system of your Hyper Protect Virtual Server instance
  • Store signing keys in a Hyper Protect DBaaS instance
  • Create an Apache Maven project to generate Java code for using the GREP11 API and to build the signing server web application
  • Use the Secure Build Server to build the signing server application image
  • Use Hyper Protect Virtual Servers Bring Your Own Image (BYOI) to deploy the signing server application and run the signing server in a secure environment

To build this code pattern using Secure Build Server you need to provision one Hyper Protect Virtual Servers instance.

To run this code pattern, you need to provision one Hyper Protect Virtual Servers instance, one Hyper Protect Crypto Services instance, and one Hyper Protect DBaaS for MongoDB instance.

Flows

This code pattern consists of three separate client requests:

  1. Key creation request
  2. Signing request
  3. Signature verification request

1. Key creation request

Flow diagram: Key creation request

  1. The client invokes the signing server REST API to create a key pair.
  2. The signing server invokes the GREP11 API of the Hyper Protect Crypto Services instance to create the Edwards Curve key pair and receives the created key pair.
  3. The signing server tries to load an AES key-encryption key from the local file system of the Hyper Protect Virtual Servers instance.
  4. If the AES key is not found, the signing server invokes the GREP11 API to create one and stores it in the file system.
  5. The signing server invokes the GREP11 API to encrypt the private key of the key pair using the AES key-encryption key.
  6. The signing server stores the public key and the encrypted private key in the Hyper Protect DBaaS for MongoDB instance.
  7. The signing server returns the unique identifier of the key pair and a representation of the public key to the client.

2. Signing request

Flow diagram: Signing request

  1. The client invokes the REST API to sign data, providing the unique identifier of the key pair to be used for signing as well as base64-encoded data.
  2. The signing server retrieves the encrypted private key for the corresponding key pair from the database.
  3. The signing server retrieves the key-encryption key from the local file system.
  4. The signing server invokes the GREP11 API of the Hyper Protect Crypto Services instance to decrypt the private key and receives the private key.
  5. The signing server invokes the GREP11 API to sign the data using the private key and receives the signature.
  6. The signing server passes the signature to the client.

3. Signature verification request

Flow diagram: Signature verification request

  1. The client invokes the REST API to verify a signature, providing the unique identifier of the key pair to be used for verification as well as base64-encoded data and the signature.
  2. The signing server retrieves the representation of the public key for the corresponding key pair from the database.
  3. It invokes the GREP11 API of the Hyper Protect Crypto Services instance to verify the signature.
  4. The signing server returns a success response code if the signature is valid, or an error response code if the signature is invalid.

Instructions

Find the detailed steps for this pattern in the README file. These steps show you how to:

  1. Clone the repository and set up a development environment.
  2. Build and run the signing server in your local development environment.
  3. Set up the IBM Cloud Container Registry.
  4. Set up the Secure Build Server.
  5. Build the signing server application image using the Secure Build Server.
  6. Deploy the signing server using Hyper Protect Virtual Servers Bring Your Own Image (BYOI) and run the application in a secure environment.
  7. Test the signing server.