The pNetwork backend leverages a TEE (Trusted Execution Enviroment) in order to provide security. A TEE is a secure area inside a device that provides a secure environment for running trusted applications. The purpose of the TEE is to protect sensitive data and applications from unauthorized access, providing a secure environment for handling confidential information.
pNetwork makes use of two Trusted execution environments: AWS Nitro enclaves and Android Strongbox TEE.
pNetwork uses TEEs in order to store sensitive data such as signing keys and to perform general crypto operations.
AWS Nitro Enclaves
These are Amazon EC2 instances that allow you to create isolated execution environments, called Enclaves. Nitro Enclaves uses the same Nitro Hypervisor technology that provides CPU and memory isolation for EC2 instances.
Enclaves are separate, hardened, and highly-constrained virtual machines. They provide only secure local socket connectivity with their parent instance. They have no persistent storage, interactive access, or external networking. Users cannot SSH into an enclave, and the data and applications inside the enclave cannot be accessed by the processes, applications, or users (root or admin) of the parent instance.
Nitro Enclaves is integrated with the AWS Key Management Service (KMS), which provides built-in support for attestation and enables you to prepare and protect your sensitive data for processing inside enclaves.
Finally, the attestation process provided by Nitro Enclaves is used to prove its identity and build trust with an external service. The process consists of a series of measurements (or hashes) that are unique to an Enclave and they may be included into a document that can be subsequently signed by the Nitro Hypervisor. This attestation document can be then provided to an external service which can validate the enclave’s integrity.
Android StrongBox TEE
Android StrongBox is a feature designed to enhance the security of cryptographic keys stored on an Android device. StrongBox is an hardware implementation of the astraction layer related to the crypto primitives made available for the client application. This implementation is done by using an hardware security module (HSM) mounted on the device board, which is composed of the following components:
- Its own CPU
- Secure storage
- A true random-number generator
- Additional mechanisms to resist package tampering and unauthorized sideloading of apps
Additionally, in order to gives you more confidence that the keys you use in your app are stored in a device's hardware-backed keystore, Key Attestation is available.
Key attestation aims to provide a way to strongly determine if an asymmetric key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage.
Further details about the processo can be found here.
Bridge state integrity
As an additional layer of precaution, we provide bridge state integrity by signing a checksum of the application’s database and verifying such signature on the next operation that involve a state change. Everytime the state is going to change, we verify the previous signed checksum and, if verified successfully, we create another one signed with a new key coming from the TEE.