Knox Networks Enhances Security with IBM Hyper Protect Crypto Services HSM for FIPS Compliance

Knox Networks
8 min readApr 15, 2024

--

In today’s digital age of payments and identity verification, protecting sensitive data and ensuring secure transactions from looming cybersecurity threats are paramount for businesses. At Knox Networks, we understand the critical importance of safeguarding sensitive information and ensuring trust between financial institutions (FIs) and their customers while preserving compliance and regulatory requirements. This is why Knox augmented its applications with IBM Hyper Protect Crypto Services (HPCS) as one of the Hardware Security Module (HSM) providers serving a key component of its robust security infrastructure.

Overview of the Knox Solution with IBM Hyper Protect Crypto Services HSM

With regard to cryptographic signing, Knox uses Ed25519 by default for high performance, security and efficiency. Knox’s File-Based Digital Assets (FBDA) are designed to support other various signature systems and can add more as required, including Secp256k1 or quantum resistant algorithms such as Dilithium, Isogeny-based, etc. Knox can support various algorithms, assuming they are supported by other dependencies desired by financial institutions such as HSM or multi-party computation (MPC) providers.

As a software technology provider for regulated digital payments and assets, Knox was designed to be operated by financial institutions and cloud-agnostic, with abstractions to integrate to various technology providers and external systems for cryptographic functions (e.g., HSM via PKCS11, MPC, KMS). Knox assumes financial institutions will have their own preferred solution providers in place, therefore builds integrations for each HSM/MPC provider. This integration is built via specific Kubernetes sidecar containers to run alongside any of the Knox applications within its respective pod. In this blog post, Knox implements the IBM HPCS sidecar, but Knox applications could run with other HSM sidecars as well deployed with any other cloud providers or linux based on-prem data centers within an existing financial institution.

Knox applications are written in Rust, a highly performant programming language with memory safety (as the White House urges), and communicate over gRPC/HTTP2 for binary transport and multiplexing to enable high throughput and low latency. As such, the sidecar was written in Rust as well and its interoperability with C based PKCS11 libraries provided by the IBM HPCS allowed for Rust bindings to be generated easily for smooth integration. In addition, IBM’s HPCS Enterprise PKCS11(EP11) libraries also supported gRPC (via GREP11), allowing for consistency of Knox’s native tech stack while remotely accessing the IBM HPCS HSM service instance for data signing and management.

Here is an example of the IBM HPCS sidecar running, within a given FI infrastructure.

Knox Services Running a Common HPCS Sidecar for HSM Functions in a Bank Environment

With this setup, Knox was able to demonstrate offloading the generation of keys and signing to an external service, never having any private keys within the Knox application infrastructure, protected in a dedicated remote hardware security module. Some examples of this include:

  • Knox Authority Services sign the issuance of File-Based Digital Assets (FBDAs) into existence via the sidecar in the Authority pod, remotely accessing the HSM signing gRPC call.
  • Knox Transaction Validators sign the authorization of transactions via the sidecar in the Transaction Validator pod remotely accessing the HSM signing function gRPC call.
  • Knox Custodial Wallet Services create new wallets and its private-public key pairs via the sidecar in the Custodial Wallet pod remotely accessing the HSM key generation gRPC call. A similar process can be followed for wallet owners to sign the authorization of an asset transfer commitment.

The offloading of cryptographic key functions as mentioned above gave Knox the ability to help financial institutions meet some of the stringent security and regulatory compliance requirements. The following explains the process and design around the whole solution described above.

Balancing Security and Compliance with Performance and Interoperability — Factors Considered in Knox Design Choices

As Knox Networks continues to innovate in the digital payments and assets space, the need to address the demands of performance, ease of integration and interoperability while maintaining the highest level of security and regulatory compliance remains a critical challenge. Here were some of the design choices made in the key areas Knox evaluated:

Signature System

Though Knox Networks’ File Based Digital Assets (FBDA) support various signature systems, Knox chose Ed25519 as the default signature system for the following reasons:

  • Enhanced Security: Ed25519 is based on Elliptic Curve Cryptography (ECC), a well-respected and highly secure cryptographic system with 128-bit security level, providing robust resistance against brute-force and side-channel attacks.
  • High Performance & Efficiency: Compared to traditional algorithms like RSA, Ed25519 utilizes significantly smaller keys (256-bit vs. 2048-bit or higher). This translated to:
    — Reduced storage space, especially beneficial for resource-constrained devices.
    — Faster key generation and signing, improving overall performance.
    — Bandwidth efficiency since smaller keys take up less bandwidth on network transmission.
  • Open-Source and Widely Supported: Ed25519 is an open-source algorithm with widespread adoption across diverse platforms and cryptographic libraries in various programming languages such as Rust and Golang. This ensures easy integration and readily available development tools.

Cryptographic Key Protection & Management with HSMs:

Protecting sensitive information is crucial with digital payments and identity verification, and data breaches and unauthorized access have been constant threats. Storing cryptographic keys solely on software-based systems exposes them to potential vulnerabilities within the operating system or applications, where hackers could exploit these weaknesses to steal or manipulate the keys. Software bugs, malware infections, or even accidental deletion can lead to data loss or key compromise if residing solely on software systems. Beyond basic protection, management of the cryptographic keys and its entire lifecycle can be a burdensome operational process with additional risks. Financial institutions in particular, have been mandated by regulatory compliance to have strong key management practices.

To address the security and key management challenges above, Knox added an option to configure its applications to work with Hardware Security Modules (HSMs). Here were some of the key benefits brought by HSMs:

  • Tamper-Resistant Hardware: HSMs are built with physical tamper-evident seals and secure enclosures. This makes it significantly harder for attackers to access the stored keys, even if they gain control of the surrounding system.
  • Secure Enclaves: HSMs isolate cryptographic operations within secure enclaves. This physical and logical separation minimizes the risk of software vulnerabilities compromising the keys or cryptographic processes.
  • Enhanced Key Management: HSMs offer dedicated hardware for managing the entire lifecycle of cryptographic keys. This includes secure generation, storage, rotation, and destruction of keys, ensuring proper key hygiene and reducing the chances of compromise.
    — Financial transactions on cryptographic payment networks usually capture wallet addresses and associated public keys, and repeated use of keys could enable observers to identify transaction patterns, and thereby compromise the identity of the real-world entity or individual. As such regularly rotating cryptographic keys used within the HSM minimizes the potential damage and attack window if a key identity is compromised, and makes it difficult for hackers to launch successful brute-force attacks or exploit access to specific keys for an extended period.
  • Improved Auditing and Accountability: HSMs provide detailed logs of key generation and rotation events. This audit trail simplifies incident response and helps identify any suspicious activity related to key management.

Compliance Requirements

Financial Institutions have stringent regulatory compliance requirements in place that span outside the scope of this blog post (including some of Knox’s ISO 27001 certification efforts). This post focuses more on some of the recent compliance mandates related to strong cryptographic signing and key management practices.

In February 2023, The National Institute of Standards and Technology (NIST) introduced FIPS 186–5 and established a one-year transition period. This means as of February 2024, vendors can only submit cryptographic modules for FIPS 140–3 validation using the FIPS 186–5 digital signature standard. This means new cryptographic modules seeking FIPS 140–3 validation require compliance with FIPS 186–5. In 2023, the final version of the FIPS 186–5 standard included Ed25519 as an approved signature scheme, which Knox prefers as the default algorithm for its high performance and security. This aligned well with Knox’s efforts as HSM providers start seeking FIPS 140–3 validation, and financial institutions rely on HSMs to help meet compliance requirements by providing a secure and auditable platform for managing cryptographic keys.

The HSM Solution: IBM Hyper Protect Crypto Services

After careful evaluation, Knox opted for IBM Hyper Protect Crypto Services as an HSM solution. IBM, as one of the first market launchers to introduce HSMs in the late 1970s, have always been an innovator in this space. This cloud-based offering from IBM provides a dedicated single-tenant HSM with Keep Your Own Key (KYOK) capabilities, specifically designed for enhanced data security and regulatory compliance. Here is how the HSM solution addressed Knox’s specific needs:

  • FIPS 140–2 Level 4 Validation: IBM HPCS boasts one of the highest levels of security certification available in the cloud and is now working towards FIPS 140–3 compliance.
  • Multi-Cloud Key Management: Knox’s core design principles assume the need to be able to work with any and multiple cloud providers. Many FIs use KMS for key management and often need to back them with HSMs and by adopting multi-cloud strategies, their IT security personnel have to manage dozens/hundreds of keys across multiple locations and providers adding to operational challenges and cost. HPCS can help simplify this as it provides a single point of control for key management providers across various cloud key providers.
    Keep Your Own Key (KYOK): HPCS supports KYOK which brings several advantages over Bring Your Own Key (BYOK) such as higher level of control, not only eliminating the possibility of the cloud provider or unauthorized actors gaining access but also ensuring complete control of strict key management practices mandated by regulatory compliance. Full visibility and control over all aspects of the key lifecycle improves auditability and accountability.
  • gRPC Support: Knox services communicate via gRPC by default and where possible prefers to communicate via gRPC for the following reasons:
    Performance & Scalability: gRPC leverages HTTP2, a binary protocol designed for efficient data transfer, multiplexing and header compression. With protobufs for fast, compact serialization, communication is significantly more performant and scalable than REST/HTTP 1.1 with JSON. As Knox service interfaces are defined by protobufs, this simplified the adoption and consistency of application communication.
    Development Experience: Protobufs enforce data types and structures which leads to better code maintainability, less runtime errors, and improves IDE support for autocompletion and type checking. Knox also already has tooling in place for automatic code generation and documentation against protobuf definitions.
  • Future-Proofing for Quantum Computing: While quantum computers are still in their early stages, they pose a potential threat to traditional cryptographic methods. Financial institutions are starting to look to investigate quantum-resistant algorithms to prepare for this future possibility. IBM HPCS HSM Services provides quantum safe signing with Dilithium, which is a specific type of lattice-based cryptography gaining traction with the following advantages:
    Recently standardized by NIST as a quantum resistant signature algorithm
    — Smaller key sizes relative to other post-quantum candidates, translating to lower storage requirements and potentially faster cryptographic operations
    — Actively being researched and developed — e.g. OpenSK by Google implements Dilithium (in Rust)
Knox File Based Digital Asset Signing with a FIPS 140–2 Level 4 HSM on IBM Cloud

Conclusion

By implementing IBM Hyper Protect Crypto Services HSM, Knox Networks has taken a significant step forward in its commitment to data security and regulatory compliance. This solution empowers Knox to focus on innovation with the peace of mind of knowing sensitive data is protected using the industry’s best practices. Knox is still able to leverage Ed25519 as a highly performant FIPS 186–5 approved signature system, and it was recently announced that cryptographic modules for FIPS 140–3 validation must use the FIPS 186–5 digital signature standard. Financial institutions rely on the highest security and compliance standards, and Knox continues to grow its confidence and in scaling for financial institution needs, ensuring a secure and compliant future in regulated tokenized payments, assets and identity verification.

--

--