In this blog, Robert Drążkowski, a Principal Engineer in Mobica’s Embedded Competence Centre, will take a deep dive into Parsec, and discuss how to take a best practice approach to security at the infrastructure edge.
What is Parsec?
Parsec is the Platform AbstRaction for SECurity, an open-source initiative that provides a common API to hardware security and cryptographic services, in a platform-agnostic way. This abstraction layer keeps workloads decoupled from physical platform details, enabling cloud-native delivery flows within the data centre and at the edge.
Why is Parsec needed?
The ‘edge’ typically refers to sensors that collect data from the Internet of Things (IoT) and feed it upstream. In contrast, the ‘infrastructure edge’ is most easily thought of as the first aggregation point where any kind of collation or processing of data takes place away from the cloud.
Critically, that point is changing due to bandwidth challenges.
It’s predicted more than one trillion connected devices will be deployed by 2035. Conversely, the IoT data volume produced by them is growing much faster than bandwidth to the cloud.
Let’s consider one use case as an example. In the future, it’s anticipated 500 million high-definition image sensors will produce 300 exabytes (1018 bytes) of data per month. That will exceed available bandwidth to the edge network, let alone the cloud. The same trend is occurring across the board, and backhauling is not an option. The only way to deal with this deluge of data is to process it at or near the edge. Sufficient compute horsepower at the edge allows organisations to process sensor data and send only what’s critical upstream.
What IoT security threats need to be addressed?
For 1 trillion IoT devices, security considerations cannot be an afterthought. What, then, common IoT security threats do we need to be aware of?
Source - Arm, ‘The Importance of Security for the Infrastructure Edge’
However, given the rise of infrastructure edge use cases, many of these threats will need to be reconsidered.
This is where Platform Security Architecture (PSA) comes into play.
What is Platform Security Architecture?
PSA is a framework that enables ecosystems to build on a common set of ground rules, reducing the cost, time, and risk associated with IoT security.
PSA provides a set of security goals that should be deployed in a system. It details how to create a PSA Root of Trust (PSA-RoT) with a set of secure services (APIs) that the rest of the system can then use. It also describes a scalable implementation for building the PSA-RoT for devices.
One of the provisions of the PSA is the PSA Crypto API. The PSA Crypto API is a comprehensive library of modern security primitives, covering the following functional areas:
- Key provisioning and management
- Hashing
- Signing
- Message Authentication Codes (MAC)
- Asymmetric encryption
- Symmetric encryption
- Authenticated Encryption with Associated Data (AEAD)
- Key derivation
- Entropy (random number generation)
Taking all this into account, Parsec is a reference security microservice running within the OS distribution, which surfaces the PSA APIs using an IPC mechanism. The purpose of this microservice is to provide both abstraction and arbitration for applications and runtime software.
Abstraction in the microservice means that the same PSA APIs are always available across diverse RoT service implementations. Abstraction is important because target devices have different RoT implementations, to meet cost and security requirements.
Arbitration by the microservice enables multiple applications/runtimes to use the security capabilities of the device, while ensuring that the secrets for each application are isolated.
What is the Parsec security service?
The core component of Parsec is the security service (or security daemon). A background process that runs on the host platform, it provides connectivity with the secure facilities of that host and surfaces the wire protocol based on PSA Crypto.
The security service listens on a suitable transport medium. The transport technology is one of Parsec's many pluggable components, and no single transport is mandated. Choice of transport is dependent on the operating system and the deployment. On Linux-based systems where the client applications are running in containers (isolation with a shared kernel), the transport can be based on Unix sockets.
Client applications make connections with the service by posting API requests to the transport endpoint. This is usually done via a client library that hides the details of both the wire protocol and the transport. This is one of the ways in which the client library simplifies the experience of Parsec for application developers.
What are Parsec’s front-end and back-end modules?
The Parsec service employs a layered architecture, structured into a front-end and a back-end.
The front-end module provides the transport endpoint and listens for connections from clients. The front-end understands the wire protocol and the common API. It is responsible for serialisation and deserialization of the operation contracts.
The back-end modules are known as providers. The Parsec security service is able to load one or more providers. Providers implement the API operations using platform-specific or vendor-specific code. They provide the ‘last mile’ of connectivity, down to the underlying hardware, software or firmware.
How is Parsec implemented?
Parsec is mostly implemented in Rust programming language. However, if needed, it uses Rust bindings mechanism to call functions from hardware specific libraries and drivers. An example might be a CryptoAuthLib provider using rust-cryptoauthlib, the Rust wrapper for the Microchip CryptoAuthentication Library, written in C, to access ATECCx08a cryptochip
The main components of Parsec service and data flow are depicted below.
Source - The Parsec Book
Let’s take a look at the seven main components that happen in the server process space.
- The Listener
The Listener is responsible for accepting incoming connections from clients on the transport endpoint. This could take the form of a Unix domain socket listener. It is the only part of the system that understands the form of transport being used. Its responsibility is to accept connections and to produce streams capable of reading from and writing to the underlying connection.
- The Authenticator
Before the request is sent forward it must be authenticated. This involves the FrontEndHandler choosing an appropriate Authenticator object from the set created at system startup, based on the AuthType field in the request header. The Authenticator either returns an application name if the authentication was successful, or an error value which is then returned to the client.
- The Front-End Handler
Once an incoming byte stream has been obtained by the Listener, the stream is passed to the FrontEndHandler, which is where the first phase of wire protocol interpretation is performed. The FrontEndHandler is responsible for deserialization of the request header.
- The Dispatcher
The Dispatcher processes the Request object, which represents a request with a fully-parsed header, but an unparsed byte array for the body. Since the header is parsed, the Dispatcher has access to all of the information that is needed to dispatch a request to the appropriate back-end. This information includes the provider identifier, the body encoding type (which is currently always protobuf, but in theory could be something else), and the protocol version major and minor fields.
- The Back-End Handler
The BackEndHandler accepts the request in order to route it to its associated provider. The flow differs here depending on whether the provider is an in-process Rust Provider object, or a provider residing in an out-of-process co-server. If the provider is in a co-server, the BackEndHandler will use the wire protocol to re-serialize the request and transmit it to the co-server's transport endpoint, where it will then block in order to wait for a response.
- The Provider
The Provider is where the request is fulfilled using whatever combined software and hardware stack it has been coded for. The service can support any number of providers to interact with platform facilities such as TPM, HSM or CryptoChip. The provider does whatever is necessary to implement the operation.
- The Key Info Manager
Providers use Key Info Managers to persistently and safely store key information material, and thus another step for conversion from key name to provider-specific identifier is needed. Please note, this component does not implement a key storage, it only maps key name, provider name and application name to provider-internal key identifier. It is left up to the provider to safely store the key.
What does the development process involve?
Although originally the Parsec project was founded by Arm, it is an Open Source (Apache 2.0 licence), community-driven project.
The discussions take place on a public Slack forum, and sources are stored on github. Whoever wants to participate may submit pull requests.
Empowering tomorrow’s embedded engineers
If you’re an ambitious engineer, looking for opportunities to develop security solutions for infrastructure edge use cases, then join our team.
From concept to completion, we handle every aspect of embedded engineering.
Sources
- Arm, ‘The Importance of Security for the Infrastructure Edge’, https://www.arm.com/-/media/global/people/Security-For-The-Infrastructure-Edge-White-paper
- The Parsec Book, https://parallaxsecond.github.io/parsec-book/
Contributor
