We are building “Digital safes” dedicated to team working on sensible datas. The team can work on every kind of data (document, coding with testing, lab, computation, …).

Targets

features

A safe must provide the usage following features:

• provide a secured distant workspace to a team
• Data must be in this workspace
• Data usage must be done in this workspace
• Different teams must be mutually isolated
• Supplier administrators must not be able to access data
• Physical access to hardware must not allow to access data

More precisely

A safe is a dedicated physical server with services (virtual hosts) for :

• Data confidentiality/privacy oriented
• Work directly in the safe, data don’t need to go out for use
• When nobody is logged, unencrypted data are not available
• Safe is closed when the last user disconnects
• Isolated and secure network and storage
• Stack of basic services
• Scalable computing and services nodes
• Protected against the administrators of the supplier

How it works

 

The safe is a set of virtual hosts mounting filesystems from the hypervisor itself. Virtual hosts are suspends when the safe is closed, or up and running when it is open. All virtual hosts see decrypted file system. The key is only in the hypervisor, and is liberated when a user connect to the safe (ie open a vpn to the vpn virtual hosts, which is never suspend). The user pass a hash of its password which is a key to liberate the kernel key to decrypt the file system.

As you can see, the underlying filesystem can be store at another place without trust in thoses  administrators.

Advantages

Safes mutual exclusion

Even if

One or more physical server(s) = a safe

there is not physical sharing of virtual hosts on the same hypervisor. In that way, a safe cannot be corrupted by another.

Virtual hosts without security

All virtual hosts in a safe don’t matter with security. They don’t see that file system are encrypted. the don’t have any cryptographic keys.

Because virtual hosts are under the safe users management, they cannot connect to the internet, or with specific rules (proxies).

The hypervisor must be corrupted to get the key.

Users got keys

The decyphering key is in the hypervisor kernel, and is released by the user password with a specific communication between the vpn gateway (virtual host) and the hypervisor. When the safe is closed (ie no users connected), ther is no way to open it without keys, even if you are root on the hypervisor.

(Of course, if the safe is open, root on the hypervisor or on virtual hosts can see/modify data).

 

Availability

At the beginning of january, 2015 for Inria membership.

You can contact us if you are interrested in such hosting or solution.