Privacy & Security

Note that this is planned functionality and feedback is invited on the forum.

Introduction

Memri is an open source project developing a mobile application (app) for you to catalogue and browse your personal data, and a companion backend (pod) for securely storing said data out of sight from big tech companies and their customers. We envision Memri as a platform for you to unlock the full potential of your data, without risking your privacy.

Memri stores all of your data centrally in what is called a pod. Think of a pod as your own personal private server that stores, combines and processes your data to give you the overview and insights you are looking for. It aims to fully replace the need for proprietary and commercial services to store your personal data such as notes, emails, contacts, and photos.

This article gives a layman's overview of how we intend to protect your data. The described functionality will be added and improved upon during the development of the upcoming beta release. We will take a look at the encryption of your personal data, isolation of applications running in the pod, hosting of the pod by third parties, and recovery of the keys used to encrypt your data.

Encryption

To keep control over who has access to your data, it needs to be encrypted during all the various stages of its use. Intercepted data should be unintelligible without the right encryption keys. For this reason we consider encryption of personal data during communication (data in transit), computation (data in use), and storage (data at rest).

Access to a pod is protected by the personal key of its owner. Keys come in two flavors: symmetric and asymmetric. In the case of symmetric keys you use one key to lock and unlock data. In the case of asymmetric keys you need two separate but mathematically related keys (a key pair). Memri users will use an asymmetric key pair to securely access their pod, and create temporary symmetric keys for any further communication.

Starting the Memri app for the first time will generate a key pair: one key is kept private and acts as the secret personal key of the owner, while the other key is made public and is stored by the pod. The pod can then verify if a request for access is from its owner by unlocking it with the public key. This will only succeed if the request is locked with the corresponding private key known only by the owner.

To ensure personal data is kept secure at rest, the Memri app will generate additional symmetric keys. These keys are sent to the pod to enable it to safely store and backup your data: any data not in active use is locked, and keys are removed during a restart or when they are not needed in the near future. A pod only regains access to your data if it receives those keys back from the app.

Isolation

A Memri pod is implemented as a collection of microservices: a group of small applications working together to accomplish a task. Some of these applications require keys, others passwords, some have access to personal data, and others do not. As a best practice, we want to keep these applications isolated from each other to minimise the consequences of potential security breaches. If one service is compromised, it should not be easy to compromise other services.

Let’s look at three ways to isolate applications:

  • Processes
  • Containers
  • Virtual machines

The typical way to isolate applications from each other is by running them as separate processes. This is how an operating system, with the help of the computer's processor, prevents one application from reading the memory content of another application. Only the operating system (the kernel process) is allowed to read all memory. This type of isolation, however, can be circumvented by using vulnerabilities in the operating system and is not sufficient for our requirements.

Another way to separate applications is to use containers. Applications running on a computer often share the same file system for storing the applications and their shared components. This sharing creates dependencies between the applications, making them harder to deploy and more exposed to security breaches. Containers give each application its own private file system. This prevents the dependencies caused by a shared file system and allows the operating system to be more strict in its isolation of applications.

Where containers prevent sharing of the same file system, virtual machines prevent applications from sharing the same operating system. A typical computer runs a single operating system, with multiple applications on top. Bugs in this shared operating system can be exploited by applications to gain access to other applications running on the same kernel. While computationally more expensive than containers, virtual machines give us much stronger security benefits.

For the above reasons, we choose to run each pod as a separate virtual machine to maximise isolation. The individual applications of the pod will run in containers, with the future possibility of running particularly security sensitive services of the pod in their own virtual machine. The hurdle of reduced performance from using virtual machines can be overcome by using specialised small operating systems (such as Firecracker or MirageOS) specifically designed to minimise the overhead.

Hosting

One can choose to run the pod on a privately owned computer, and in that case the above encryption and isolation measures should prove sufficient, but the situation becomes more complicated when the pod is hosted by a third party. In that case we have to consider that the third party has physical access to the machine and can potentially run a modified version of the pod or even directly access the memory of the machine.

To prevent unauthorised modifications to the pod or access to its memory we use trusted execution environments. Depending on the processor brand, it is possible to encrypt the memory of either a container or a virtual machine. This technology also enables the processor to vouch for the application and validate that it has not been altered. Data in use for a computation will not be disclosed, even when an attacker has physical or administrative access to a machine.

When multiple pods are running on a single hosted system (isolated from each other using virtual machines) we use the public key of the owner to direct connections from the Memri app to the right pod. Note that any errors in forwarding the connection can never result in a security breach, since access is verified individually by each pod. Eavesdropping is also impossible since all communication is encrypted.

Key recovery

When a user loses their keys to access their pod, they will not be able to recover the data that is stored on their pod. Because of this substantial risk there should be a way for securely storing and recovering keys. Since only the owner of the pod has access to the keys, the app will assist them by giving different options for key recovery.

The simplest key recovery scheme is for a user to print their keys as a barcode on a piece of paper and store them in a safe place. This paper can then be scanned by the Memri app to restore the user’s key.

Printing keys for recovery still might not cover all eventualities (e.g. a fire). An alternative system is to distribute pieces of a key among friends, such that a majority of cooperating friends can help to reconstruct the original key. This functionality will come built-in to the Memri app and an optional standalone app for friends.

The user will be able to choose the specific policy for key recovery; for example, what type of majority is required or whether an additional password is needed after reconstruction. Keys can be stored multiple times, with different friends or additional security measures depending on the size of the majority required. A default policy is provided for novice users.

In particular it could also be useful to have a separate organisation for storing key pieces and to be a trustworthy partner in key recovery. Functionally the organisation would act as one of your friends holding a piece of the key, but it would follow strict procedures to verify your identity during recovery. Such an organisation would reduce the risk of social engineering or collusion, while never having access to the complete keys.

Conclusion

Memri is developing an open source app and pod solution to make the most of your private data while keeping it secure from prying eyes. Our alpha release contains a first implementation of both the app and pod and is intended for experimental use in a secure environment. Services of the pod are isolated using containers and support for virtual machines and encryption will be added during the coming months.

When we launch the platform to a more general public we aim to have:

  • Encryption of data in transit between app and pod
  • Encryption of data at rest for storage and backups
  • Isolation between services from containers
  • Isolation between pods from virtual machines

Although we will initially be running pods without encryption of data in use, our longer term goal is to tighten up security further with trusted execution environments. This is already being kept in mind during our current design and planning.

Since the alpha release and the ideas described in this article will be the starting point for further development, we are very interested in feedback and suggestions. Please visit our forum and join in with any questions or remarks you might have.