Concepts Specifications API Downloads
ConceptsEntrusted actors

Entrusted actors

An actor may entrust other actors. Entrustees have read access to the private data and messages of the actor at any point in time.

Private data

When writing a new version of the private data, the actor adds all entrustees as recipients on the envelope. They are not explicitly notified of the change, but can list the actor's private box and decrypt the data at any time.

Messages

On message envelopes, entrustees are also added as recipients, but the message is not placed into their in-queue.

The sender should add both its own entrustees as well as the entrustees of the recipients, which are listed on their public cards.

Use cases

Entrusted actors are used when data should not be actively shared, but still be accessible.

An employee may entrust his company, for example. Under normal circumstances, the company does not need to access an employees data directly. Instead, the employee should share with peers or partners whatever is needed through messages. However, there are cases where this does not work. If an employee unexpectedly quits or dies, for example, his data may need to be accessed directly.

For similar reasons, a user may want to entrust a close friend.

In addition, users collaborating on the same project may entrust a third party organization, such as a notary, who could access the data upon presentation of a search warrant.

Offline keys

Private keys of entrusted accounts can be stored off-line until the data needs to be accessed. If incidents are rare, the private key may be stored on a piece of paper and/or memory stick in a vault.

Offline recovery

When needed, data can be recovered in a way that never exposes the private key:

Vault Offline system Entrustedprivate key Recoverypublic key Entrustedprivate key

Offline recovery works as follows:

  1. A temporary offline system is set up. This system only needs a subset of Condensation, namely a record parser and serializer, an object parser and serializer, as well as RSA encryption and decryption.
  2. The original envelope is transferred onto the system.
  3. The public key of the recovery actor is copied onto the system.
  4. The private key from the vault is entered.
  5. The system then decrypts the AES from the original envelope, and re-encrypts it for the recovery actor. The rest of the envelope remains as-is.
  6. The new envelope is retrieved.
  7. The offline system is destroyed.

The data itself does not need to be transferred to the offline system.

The offline system may be as simple as a microcontroller. For this very specific application, no full-blown operating system is needed.