By Bill Hagerstrand, Director, Security Business, Marvell
It’s time for more security coffee talk with Bill! I was first exposed to the term “Confidential Compute” back in 2016 when I started reading about this new radical technology from Intel. Intel first introduced us to this new idea back in 2015, with their 6th generation of CPUs called Skylake. The technology was named SGX (Software Guard Extensions), basically a set of instruction codes that allowed user-level or OS code to define a trusted execution environment (TEE) already built into Intel CPUs. The CPU would encrypt a portion of memory, called the enclave, and any data or code running in the enclave would be decrypted, in real-time or runtime, within the CPU. This provided added protections against any read access by other code running on the same system.
The idea was to protect data in the elusive “data in use” phase. There are three stages of data: at rest, in motion or in use. Data at-rest can be encrypted with self-encrypting hard drives—pretty much standard these days—and most databases already support encryption. Data in-motion is already encrypted by TLS/SSL/HTTPS/IPSec encryption and authentication protocols.
Data in use, however, is a fundamentally different challenge: for any application to make “use” of this data, it must be decrypted. Intel solved this by creating a TEE within the CPU that allows the application and unencrypted data to run securely and privately from any user or code running on the same computer. AMD provides a similar technology it calls AMD SEV (Secure Encrypted Virtualization). ARM, meanwhile, calls its solution Arm CCA (Confidential Compute Architecture). Metaphorically, a TEE is like the scene in courtroom dramas where the judge and the attorneys debate the admissibility of evidence in a private room. Decisions are made in private; the outside world gets to see the result, but not the reasoning, and if there’s a mistake, the underlying materials can still be examined later.
By Bill Hagerstrand, Director, Security Business, Marvell
Payment-specific Hardware Security Modules (HSMs)—dedicated server appliances for performing the security functions for credit card transactions and the like—have been around for decades and not much has changed with regards to form factor, custom APIs, “old-school” physical user interfaces via Key Loading Devices (KLDs) and smart cards. Payment-specific HSMs represent 40% of the overall HSM TAM (Total Available Market), according to ABI Research1.
The first HSM was built for the financial market back in the early 1970s. However, since then HSMs have become the de facto standard for more General-Purpose (GP) use cases like database encryption and PKI. This growth has made HSM usage for GP applications 60% of the overall HSM TAM. Unlike Payment HSMs, where most deployments are 1U server form factors, GP HSMs have migrated to 1U, PCIe card, USB, and now semiconductor chip form factors, to meet much broader use cases.
The typical HSM vendors that offer both Payment and GP HSMs have opted to split their fleet. They deploy Payment specific HSMs that are PCI PTS HSM certified for payments and GP HSMs that are NIST FIPS 140-2/3 certified. If you are a financial institution that’s government mandated to deploy a fleet of Payment HSMs for processing payment transactions, but also have a database with Personally Identifiable Information (PII) data that needs to be encrypted to meet General Data Protection Regulation (GDPR) or California Consumer Privacy Act (CCPA), you would also need to deploy a separate fleet of GP HSMs. This would include two separate HW, two separate SW, and two operational teams to manage each. Accordingly, the associated CapEx/OpEx spending is significant.
For Cloud Service Providers (CSPs), the hurdle was insurmountable and forced many to deploy dedicated bare metal 1U servers to offer payment services in the cloud. These same restrictions that were forced on financial institutions were now making their way to CSPs. Also, this deployment model is contrary to why CSPs have succeeded in the past, which was to offer when they offered competitively priced services as needed on shared resources.
By Bill Hagerstrand, Director of Security Solutions at Marvell
InfoSec Global, a leader in cryptographic agility management analytics software, and Marvell, a leader in Cloud based HSMs (Hardware Security Modules), have partnered to enable visibility and security in the cloud.
The Marvell® LiquidSecurity® family is a solution of hardware security modules (HSMs) based on a PCIe form factor instead of traditional 1U and 2U pizza boxes They are purposely designed to enable CSPs (Cloud Service Providers) to offer security services in a cloud environment. Not only does the smaller form factor and optimized processing of LiquidSecurity provide a path to reduce the cost, overhead, and rack space needed for performing encryption and key management, partitions and others performance features enable clouds to serve a large number of customers in a flexible manner.
By Bill Hagerstrand, Director of Security Solutions at Marvell
Grab a cup of coffee. In this blog I describe how IT professionals can utilize Marvell® LiquidSecurity® Hardware Security Modules (HSMs) with Cryptomathic’s Crypto Service Gateway.
Cryptomathic has 35+ years of experience providing global secure solutions to a variety of industries, including banking, government, technology manufacturing, cloud, and mobile. The company’s Crypto Service Gateway software is a first-of-its-kind central cryptographic platform that provides centralized and crypto-agile management of third party HSM hardware, enhancing the behavior of HSMs while improving the time-to-market of business applications.
An HSM is a physically secure computing device that safeguards and manages digital keys, performs encryption/decryption functions, and provides strong authentication mechanisms. They typically come in two form factors: a PCIe card or a 1U network attached server. They are NIST (National Institute of Standards and Technology) FIPS 140-3, level-3 certified and most provide tamper evidence (visible signs of tampering), tamper resistance (the HSM becomes inoperable upon tampering) or tamper responsive (deletion of keys upon tamper detection). All provide logging and alerting features, strong authentication, and key management features, and support common APIs like PKCS#11. Applications that require cryptographic services will make API calls for keys used to encrypt data in motion or at rest.
By Bill Hagerstrand, Director of Security Solutions at Marvell
In this blog I describe how cybersecurity professionals can utilize Marvell® LiquidSecurity® HSMs with self-managed HashiCorp Vault Enterprise software, deployed on-prem and in the cloud.
HashiCorp provides infrastructure automation software for multi-cloud environments, enabling enterprises to unlock a common cloud operating model to provision, secure, connect, and run any application on any infrastructure. HashiCorp Vault provides the foundation for modern multi-cloud security. It was purpose-built in the cloud era to authenticate and access different clouds, systems, and endpoints, and centrally store, access, and deploy secrets, i.e. encryption keys, passwords, API tokens, tokens used in applications, services, privileged accounts, or other sensitive portions of the IT ecosystem. It also provides a simple workflow to encrypt data in flight and at rest. Global organizations use Vault to solve security challenges as they adopt cloud and DevOps-friendly solutions.