The decreasing cost and power consumption of intelligent, interconnected, and interactive devices at the edge of the Internet are creating massive opportunities to instrument our cities, factories, farms, and environment to improve efficiency, safety, and productivity. Developing, debugging, deploying, and securing software for the estimated trillion connected devices presents substantial challenges. As part of the SMARTER (Secure Municipal, Agricultural, Rural, and Telco Edge Research) project, Arm has been exploring the use of cloud-native technology and methodologies in edge environments to evaluate their effectiveness at addressing these problems at scale. With the proliferation of edge compute, as more data is collected and computed, the security concerns surrounding privacy increase. Applications are pushed from the cloud, out to the edge, increasing the attack surface exposed to the Internet. Edge compute devices may have access to secure services for key management and cryptographic operations, in the form of TPMs, HSMs, SEs, software running in a Trusted Execution Environment (TEE), cloud HSMs, and so on. However, due to the wide variety of hardware available, the facilities may not be the same from device to device. This poses problems for application developers who want to target many kinds of edge devices, or for pushing cloud applications out to the edge where they are already running in a virtualized environment to begin with. Multi-application access to a shared security resource also becomes a problem as an application’s assets must be accessible only by the application itself. What is required, is an abstraction of security services and operations that can handle a multi-tenant environment – Parsec. Parsec is an open-source initiative to provide access to secure services and cryptographic operations in a platform-agnostic way, with a key goal being to make it easy for developers to build and run secure applications. Parsec runs as a service on an edge device, responding to client requests from applications running on the host that are posted to the transport endpoint by one of the language-native client libraries. These are key to Parsec's native support in various languages.
The API used for the requests is based on the PSA Crypto API, which defines modern security primitives covering the following functional areas:
Parsec then processes the request, sending it to the specified backend provider, such as a TPM, HSM, SE, software in TEE, and so on, and then returns the result to the caller. Parsec has been built for a multi-tenant environment. Utilizing an external Secure identity provider (IPD), applications are only allowed access to their own assets and are not aware of any other applications using the Parsec service.
Mbed Crypto is the part of the Mbed TLS library that implements the PSA Crypto API specification, and is one of the supported backends currently in Parsec. It provides a lot of flexibility as it requires no special hardware. Mbed Crypto can also be run in a TEE. For these reasons, there is a lot of interest in it for the SMARTER project, as you can deploy it on many edge devices, without being concerned about the hardware.
For Parsec to be used by the SMARTER project, it must have a much greater coverage of the PSA Crypto API to meet functionality demands. This involves adding new operations to the whole Parsec stack, using Mbed Crypto as the backend provider. The first step is to identify the operation to add, and whether Mbed Crypto supports it (as it does not yet fully align to the PSA Crypto API specification). If it does, find the functions, macros, and constants that are required to perform the operations. A safe, Rust native interface into Mbed Crypto can be found in the Parsec organization, called psa-crypto. This ‘Rusts’ the auto-generated Rust bindings to the Mbed Crypto C library, offering the operations natively in Rust, with Rust’s guarantees of safety. To accomplish this, a native Rust version of all of the data types needs to be created, with code that will convert to and from the native C types, ensuring that all conversions are indeed safe. A basic example of how this would be achieved follows: The C algorithm type is psa_algorithm_t (u32 as of this blog post). If we are creating the Rust interface to psa_aead_encrypt, all aead encryption algorithms need to be represented in Rust. A declaration of the psa_aead_encrypt function is also required, taking in a Rust aead encryption algorithm type as a parameter. Then, that Rust function can safely convert the aead encrypt algorithm into the equivalent C psa_algorithm_t constant and call the C psa_aead_encrypt function (which takes in any psa_algorithm_t value, not just the valid values) with that value, because at this point, the Rust type checking has verified that the type is correct. Protobuf is used as the language-neutral contract specification for inter-process communication between the client and Parsec service. These are held in parsec-operations. When a client makes a request to the transport-endpoint of the Parsec service, it must send the request conforming to one of the protobuf contracts. This is serialized, sent to Parsec, then deserialized into a Rust native data object. Next, a Rust interface is required for the operation. These define the exact data required for each operation and are used by the Parsec service internally. They are also used for the Parsec Rust client library. For every protobuf contract declaration, there is a matching Rust interface. These take the bloated auto-generated protobuf bindings and wrap them in a Parsec-native interface for easier consumption. Finally, the operation is added to the Parsec service itself. The front end must be updated to recognize the new operation that has been added, so it does not reject it as unrecognized. Then, the provider code is updated for whatever provider the operation is being added to (in this case, Mbed Crypto). If the operation exists in Parsec (for example, you are adding an operation for a TPM backend provider that exists in Parsec with the Mbed Crypto provider), the front end will already support the operation, you need to enable it for the particular backend.
An extension of expanding Parsec's use of Mbed Crypto is the ability to run it in a TEE. For this, a version of psa-crypto operating through RPCs was built. This was then adapted to operate with Mbed Crypto running in a TEE, and Parsec running in the non-secure world.Computing at the edge means running workloads traditionally run in the cloud, such as inference. Cloud applications are almost always virtualized, which remains the same as they are pushed out to the edge. Multi-tenancy support is therefore a requirement, which is the next requirement on the SMARTER hit list for Parsec.
SMARTER: A smarter-cni for Kubernetes on the Edge
SMARTER: An Approach to Edge Compute Observability and Performance Monitoring
SMARTER: A Smarter-Device-Manager for Kubernetes on the Edge
SMARTER: Debugging a Remote Edge Device