Backed by Arm and Docker, Platform AbstRaction for SECurity (PARSEC) aims to define a universal software standard to handle secure object storage and cryptography services. The initiative focuses on modern system architectures made of containerized services and strives to make security technology easy to access from a multiplicity of languages.
PARSEC establishes an ecosystem of developer-friendly libraries in a variety of popular programming languages. Each library is designed to be highly ergonomic and simple to consume. This growing ecosystem will put secure facilities at the fingertips of developers across a broad range of use cases in infrastructure computing, edge computing and the secure Internet of Things.
PARSEC promises to cover all aspects of secure systems, including key provisioning and management, hashing, signing, asymmetric and symmetric encryption, entropy, etc. Its core component is a security service written in Rust that runs on the host and provides connectivity with its native secure facilities. This makes it possible to define a universal mechanism to provide access to secure facilities to clients who may not know anything about the underlying host hardware facilities, nor have suffiicent priviliges to use them.
PARSEC service extensibility is ensured by a layered architecture which enables the integration of security providers that can be either generic or vendor-specific. Providers are made accessible to external clients through a common front-end layer which deals with the wire protocol and common API, and is responsible for all serialization and deserialization of service contracts.
InfoQ has spoken with Justin Cormack, security lead at Docker and PARSEC maintainer, to learn more.
InfoQ: Could you explain when and how Parsec was born? What is its main goal and how does it aim to achieve it?
Justin Cormack: Docker and Arm have been working on a partnership for some time, with announcements at DockerCon in April that were focused on providing a common software pipeline for cloud, edge and IoT. We were exploring common areas of interest, and hardware key management and cryptography was an area that came up.
From our side at Docker, it has been clear for some time that in the customers that are leading edge in terms of security, such as financial services companies and government, there is a long term aim that all encryption and signing private keys should be stored in hardware. This is so that even in the event of host compromise, private keys cannot be exfiltrated; the worst case is that they can potentially be used during the time of compromise.
In addition, as Docker gets used more in edge applications, this security is even more critical than in datacenter and cloud applications. Without the physical security that servers have, hardware security mechanisms are vital to prevent tampering and local attacks. This is why we are working with Arm to develop Parsec, a common API for hardware security.
InfoQ: How is Parsec hoping to improve the security landscape of open-source software?
Cormack: There are two problems we are trying to solve.
First, there is little standardisation of APIs between different types of hardware keys. TPMs, Apple and Android have their own APIs, each manufacturer has a different API for its HSM, and the cloud providers all have very different remote HSM APIs. We are designing a common API, based on the Arm PSA API, which is a modern crypto software suite. We considered other options, but we liked this API as it does not include legacy cryptography operations and exposes a reasonable high level interface. In addition we will further abstract this to provide even more generalised operations. One of the differences with hardware is that it may have a restricted set of operations, so you want to be able to ask for things like "use a signing key that is acceptable for TLS 1.3" or similar questions, allowing the implementation flexibility, rather than saying "use an RSA key". This will make it much easier for projects to use hardware keys without having to code for specific hardware and algorithms.
The second issue is that hardware key management does not come with built in facilities to multiplex key storage for multiple clients, such as multiple containers on a node. There is the assumption that a single service owns the entire TPM or HSM, or some mechanisms may be provided but they are different for different mechanisms. Sharing may well be unsafe as clients might get access to the wrong keys. So we are adding a general set of mechanisms for shared usage, with a Parsec daemon that owns the hardware and mechanisms to authenticate and provide APIs to multiple processes. We plan to reuse the work on the SPIFFE protocol (a CNCF project) for attestation and issuance of client certificates to do this.
InfoQ: Which organizations are backing it currently?
Cormack: Currently the project is a collaboration between Arm and Docker. The aim of opening up is to make it easier to talk to other interested parties, and we are currently in the process of talking about it to others that we hope are interested. We welcome all collaboration.
InfoQ: Why did you choose Rust? What was the overall experience in writing such kind of software using Rust?
Cormack: There are an increasing number of security related projects in Rust, and a growing community around it for cryptographic applications. As a security engineer, I keep seeing more security projects choosing Rust. We wanted something that would interface well with other languages, and be reliable and secure. Rust and Go were the main candidates, and Rust just won out. It is Docker's first project in Rust, although we have talked about some other things being a good fit in the past. We are currently working on client libraries both in Rust and Go, with plans to add more in the future.
InfoQ: What is Parsec's current status and how do you envision its future evolution?
Cormack: We released this project at a very early stage, with a lot of the work we have done so far being design not coding, but there is enough of a prototype to do some demos and demonstrate much of the architecture. But it is at a really early stage, definitely not for anyone to use, just for people interested in contributing. We are going to work on integrating it into other projects, stabilise the client libraries and adding new backends such as TPM, and implement concrete versions of the stubbed implementations. Doing all this in the open should encourage other contributors.
PARSEC core service can be easily built and installed on Linux.
