Digital inheritance: a special case

of digital escrow
*1 *2 *3
Tobias Christen ; Michael Tschannen ; Marc Rennhard

Lifecycle of digital values

Digital essence

Today most individuals produce daily a high-volume of digital data, including email, chat,
text messaging, letters, presentations, digital photos, personal movies. In addition we
purchase assets that either are themselves represented in digital form (e.g. contracts,
policies) or offer access to an online service that require access credentials. Clearly we
continue to extend our digital footprint daily and the value of the assets increases. As a
consequence, in case our computers or smartphones are lost or broken we might not only
face an incredible amount of hassle to try to retrieve access to this data but in many cases
loose our digital memories forever.

Secure storage

The safety of personal data that is stored on a personal computer is often overestimated.
First we underestimate both the strength of non-intentional threats like drive failure or error
in data handling, but we also misinterprete where the weakest link in a secure remote data
access solution is. Most security experts agree that the weakest link is again the computer
and the danger that the data owner inadvertently deletes his data.

Even if storage on a hosted service seems intuitively less secure than storage on a
personally owned device because we do not have the ultimate control and we have no
definite proof of the trustworthiness of the provider, we can well argue that storage
providers which guarantee privacy, that provide end-to-end data encryption and operate
highly redundant storage infrastructures in certified data centers reduce the risk to personal
data greatly.

Secure access and access recovery

Some of the factors that generate the trustworthiness of the online storage solution are the
way data is accessed and how the access is protected. Privacy policies, quality assurance
processes, and secure solution architectures and implementations are other factors that
generate trustworthiness however they are more difficult to judge by the individual
customer. To guarantee privacy and security of the customer's data there are two important
aspects to be considered; a) does the provider know the password (and hence has
potentially unrestricted access to the data) and b) does the service provider offer strong
authentication and encrypted transmission and storage of data.

If the service provider does not have access to the password and is not able to generate
valid new passwords on demand, we face a problem: what happens if the customer looses
his password Access must be recoverable to adhere availability. To prevent that the service
provider can have access to the data, there must be an alternative credential that only the
client knows and that is difficult enough to guess that it offers an even stronger protection
than the primary access credential.

Another factor for guaranteed privacy protection is that the encryption keys that are used to
encrypt and decrypt the customers data are not accessible to the service provider. One way
to achieve this is to re-encrypt the keys with and derive that key from the password of the
customer.

The problem of authorizing conditional access

The need for conditional access

The owner of the data may want to arrange conditional access to his data for a wide range
of reasons. For example make sure that the data is accessible to the heirs after the owner
deceases, or make sure relatives have access (e.g to health data) if the owner has an
accident. Or there may be an arrangement where temporal data ownership is given to a
custodian but the original owner wants to ensure he can enforce access if necessary (e.g. a
company arranges with a contractor the custodianship of its data but wants to make sure
they can escrow without the need of a legal procedure).

If we now assume that there is an arrangement for conditional access to data as described
above, the problem arrises how a solution provider can distinguish between legitible access
claims and none legitimal.

The analogy to the physical world is troublesome

In the physical world, conditions can be proven for example with a death certificate, but the
problem remains how to recognize the originality of a death certificate from a different
jurisdiction. Other examples may be authorizations based on physical identities, but the
problem remains how a service provider can recognize the originality of document copies,
that are possibly faxed around the world.

The concept of a trusted authorized activator

A solution that is often used is that at least two persons need to claim the access and
provide their credentials. An alternative and even more flexible solution is to use a neutral
trusted authority that claims the conditional access for another person. We call this concept
the "authorized activator". Typically the activator is neutral and does not benefit from the
act of activation. This can be a company internal neutral authority like the HR department, a
trusted friend, a relative or an appointed legal authority.

It is important that the solution provider protects the privacy of the data owner in particular
before the conditional access is activated. Meaning that the solution provider has to
guarantee that a) there is no parallel path allowing access to the data with the authorized
activators credential and b) that the owner is notified of conditional access, potentially
combined with a safety delay period during which the data owner has the opportunity to
intervene in case abuse is detected.

Technical Solution
Baseline
DataInherit tries to integrate a variety of security mechanisms in a simple but effective
solution. The following requirements were defined and are met by the solution implemented
in DataInherit:

• Secure login, using either one- or two-factor authentication

• Secure transmission of sensitive data
• Secure server-side storage
• Secure and tamper-proof triggering of the inheritance process
• Secure and tamper-proof account recovery
• There exists no way for DataInherit personnel to gain access to any user's data or
account
• Extensibility: Features such as document sharing should be possible to be integrated
in the future without significant changes to the architecture
• Usage of well-known and proven cryptographic standards
• Performance-optimized use of cryptography, in particular with respect to minimizing
the number of public key computations

Server-Side Storage
The following figure shows the basics of the key management implemented in DataInherit:
 1
During account creation, the following user-specific cryptographic keys are generated :

• Symmetric User key: This key is derived from the user-chosen password. It isn't
stored anywhere and has to be computed during each login process.
• Asymmetric key pair: Using this key pair would not be necessary at the current
time, but it significantly facilitates moving towards secure document sharing if this
is going to be implemented in the future. The private part of this key pair is
2
encrypted with the symmetric user key and stored on the server .

1. Note that inheritance and account recovery are left out for the moment. These keys are
going to be introduced later in this document.
 • Symmetric Master key: This key was introduced for performance reasons so that the
3
document -specific symmetric keys don't have to be encrypted asymmetrically. This
key is encrypted with the user's public key and stored on the server. It can only be
unlocked with the user's private key.
• Symmetric Document keys: These keys are unique per document and are used for
document encryption. All keys are encrypted using the symmetric Master key and
stored on the server.

This key management allows DataInherit to reach all requirements defined above:

• The usage of hybrid encryption has a positive impact on performance.

• Each document is encrypted with a unique key, which maximizes security.
• The asymmetric key pair makes DataInherit very extensible, e.g. document sharing
could be introduced in a secure and relatively simple manner.
• Due to the fact that the "key chain" can only be unlocked with the user's password,
there is no way for DataInherit personnel to get access to any of the user's data.

Login
For the login process, DataInherit decided not to use a "standard authentication scheme"
such as challenge-response or a trivial password-based model which just transmits the
password ore some password-derived token (such as a hash), but something more secure.
The problem with most authentication schemes based on passwords is that they can be
targeted in many different ways:
4
• MITM -attacks can be used to sniff the password if it is sent unencrypted. HTTPS-
encrypted traffic can also be accessed by an attacker that manages to split the
underlying SSL-session.
• Dictionary attacks (offline or online) are used to compromise a user's password,
either by targeting the messages sent between client and server or directly by
targeting the authentication database on the server.

This list is not exhaustive because it should just show some of the usual problems a
password authentication protocol has. In contrast, a strong password protocol should have
the following properties:

• Passwords are not stored in a plaintext-equivalent form (e.g. a simple hash) on the
server to prevent dictionary attacks.
• Passwords are not sent in cleartext or in a plaintext-equivalent form.
• A mutually trusted third party should not be needed.
• Attackers can have complete knowledge of the protocol.
• Attackers can eavesdrop on all communications between client and server.
• Attackers can intercept, modify, and forge arbitrary messages between client and
server.
5
• (Optionally) The protocol fulfills the PFS property.

2. This key is actually encrypted three times: using a) the User key, b) the Activator key
and c) the Recovery key. Please refer to the corresponding chapters for more details.
3. From here on, "document" is referred to as "document or password".
4. Man-in-the-Middle
5. Perfect Forward Secrecy, meaning past sessions are protected against future
compromize.
 6
All these properties are guaranteed by SRP , a password-based authentication protocol
invented by Tom Wu at Stanford University and a popular choice by the IETF for strong
password protocols. Besides serving strong authentication, SRP establishes a strong shared
7
secret during each login process and even resists stolen-verifier attacks while still having a
good performance. SRP uses a zero-knowledge proof for authentication (and establishing
the shared secret), which means that although the user proves knowledge of the password,
no password or any plaintext-equivalent form of the password is transmitted. Even during
account creation, a user of DataInherit doesn't have to disclose his password because all
8
elements needed for an SRP-authentication are computed on the client computer and then
sent to the server. This fact is used in DataInherit to get both secure authentication and the
possibility to establish a constant, strong encryption key - all based on one password:

1. Authentication is done using SRP without disclosing the password.

2. A strong symmetric secret (used to encrypt/decrypt the user's private key stored on
the server) referred to as "User Key" above is additionally derived from the
password using PBKDF2(password, SRP-salt).

PBKDF2 is referred to as "Password-Based Key Derivation Function", a key derivation

function that is part of RSA Laboratories' Public-Key Cryptography Standards (PKCS) series.
This function allows generating a strong symmetric secret from a password. One nice
characteristic of PBKDF2 with respect to its usage within DataInherit is that it makes it
impossible for the server or DataInherit personnel to get access to the user's documents
because the "key decryption chain" cannot be started without knowing a user's password.
Additionally, dictionary attacks on the password targeting the user key are computationally
expensive because of the PBKDF2 computations.

Besides basic authentication with SRP, DataInherit offers to every user the possibility of a
9
two-factor authentication using mTAN , which can be switched on and off on demand. Two-
factor authentication is a technique commonly used today in environements such as e-
banking to prevent account compromize following a password disclosure. The idea is that an
attacker gaining knowledge about the password is still not able to log in because he doesn't
know the second factor, which typically is a one-time secret that changes for each login.
Legacy solutions such as TAN have shown to be a bad choice because they are susceptible
to phishing attacks. The advantage of mTAN (and also iTAN, however an iTAN-list can easily
be lost or stolen without the user noticing anything) is that the one-time secret required to
log in is not known until the user has successfully passed "stage 1" (password
authentication), which makes phishing attacks very difficult to achieve.

Authentication and Key Storage in Active Session

Putting all together, DataInherit offers strong authentication, secure data access and
transport security (see corresponding chapter below) as follows:

1. Client authenticates itself with SRP, additionally a strong per-session secret is

established.

6. Secure Remote Password Protocol, see http://srp.stanford.edu/

7. An attacker is therefore not able to get the user's password in an easy way even if he has
full access to the server-side login database.
8. A verifier used to verify the password and a user-specific salt.
9. mobile TAN
 2. Optional: Client sends the second login factor (mTAN), encrypted with the prior-
established shared secret, to the server.
3. Client computes the user key (using PBKDF2) that is needed to decrypt his private
key and sends it, encrypted with the prior-established shared secret, to the server.
4. Server decrypts the user key using the SRP-derived shared secret.
5. Server decrypts the user's private key using the decrypted user key.
6. Server decrypts the user's master key using the decrypted private key.
7. Client can subsequently access all data.

One of the main advantages of this solution is that the server has indeed access to the
user's data during an active session, but not after a session has correctly been torn down.

Inheritance and Account Recovery

SRP in conjunction with PBKDF2 also offers the possibility to implement both secure account
recovery as well as a secure way to start data inheritance. As already mentioned, the server
has no possibility to access any data belonging to the user without knowing the user's user
key, private key or master key. However, to enable inheritance and account recovery, there
must be a possibility to access at least a user's master key if necessary. With help of the
technologies already used for the user login, it is easily possble to achieve this in a secure
and transparent manner for the user, namely by introducing the so-called "Activator Code"
and "Recovery Code". Both codes have a length of 36 characters and are generated using
the following scheme:

1. 8 characters "username": randomly chosen. This part of the code will later be used
as username for the SRP login.
2. 1 character "type of code" to be able to distinguish between recovery and activator
code.
3. 27 completely random characters "password", which guarantees high entropy. This
part of the code will later be used as password for the SRP-login.

With the username and password encoded in the activator/recovery code, it is possible to
10
perform an SRP-login just like the user would log in. Herefore, during creation of the
codes, the corresponding SRP-salt and -verifier have been stored on the server. After the
user (or activator) has entered the recovery or activator code, a fully automated SRP-login
used to authenticate the user is started in the background. The username and password
used for that are dynamically built from the entered code. As with the usual user login, a
shared secret is established during this process.

Using PBKDF2(code-contained password, SRP-salt), some sort of alternative User key (we
call it "Activator key" or "Recovery key" here) is then generated, encrypted with the prior-
established shared secret and sent to the server. DataInherit is then able to reach the user's
account and data because (as mentioned in the chapter "Server-Side Storage") the user's
private key is effectively stored three times: encrypted with the user key, encrypted with
the activator key and encrypted with the recovery key. Depending on the kind of code
entered, data inheritance or account recovery can be started at that point. One might have
seen the analogies to the normal login process: Both account recovery and inheritance
activation work very similar to a user-login, simply using other keys.

During the user-specified grace period (before any data is made available to any heir), the

10. Note that here, this isn't a "login" as one might expect (i.e. the user/activator won't be
logged in afterwards) but just the way DataInherit authenticates the activator or user.
user's master key is securely stored on the server using an application-wide system key.
This enables DataInherit to access the data after the grace period, which would otherwise
not be possible without further interaction of the activator. This process of "timed release of
information" will possibly be enhanced at a later time with some sort of legal service, which
would make it impossible for DataInherit to access any data belonging to a user during the
inheritance grace period.

Transport Encryption of Sensitive Data

One very useful feature of SRP is that it not only authenticates a user, but also establishes a
strong shared secret between the two endpoints. DataInherit uses this shared secret to
encrypt sensitive data sent between server and client:

1. The mTAN-value during the login process.

2. The user's user key.
3. Every password stored in the user's password safe when they are exchanged in both
directions.

The last point even leads to the fact that password-safe entries are held in memory in an
encrypted form until the user copies them to the clipboard or edits an entry.

Secure Cryptographic Algorithms

One very important basis for longterm security is the usage of well-established
cryptographic algorithms and appropriate key lengths. DataInherit makes excessive usage
of them but has very strict standards with respects to the standards used:

Symmetric ciphers AES-256 in CBC mode with random IV

Asymmetric ciphers RSA-2048
Key generation PBKDF2
Hash-algorithm / Integrity SHA-256

All algorithms mentioned here will provably remain secure for many years to come.

Password Safe and Password Generator

DataInherit does not only offer a secure online data storage, but also a password safe
integrated into the application. As already mentioned above, we additionally enhance the
security for all passwords transmitted between client and server by encrypting them with
the session-specific shared secret. Besides the basic functionality of a password safe,
DataInherit provides two innovative approaches to generate easily memorizable passwords
with a guaranteed entropy (i.e. strength).

The first approach is based on the fact that it is easier for a human being to memorize
"meaningful" tokens - i.e. tokens that make sense - such as a sentence. Based on a random
password composed of letters, we therefore split it into 2-character chunks, which are the
basis for a sentence generated in the form surname name verb adjective noun. As a result,
a user doesn't need to memorize the entire, random-looking password, but just the
sentence leading to the password.

• Example password: izufashorapa

• Corresponding sentence: izabel uffner asks hot random page

The second approach assumes that there are combinations of two character that are easier
and some that are harder to remember for a human being. It is thereafter easier to
remember alternating consonants and vowels than a "word" just containing random
consonants and vowels. A password built by this generator therefore has the following form:
CVCV CVNN CVCV. The two digits in the middle can additionally change position within the
same block to additionally enhance the password's strength. While the user of course still
has to remember the three chunks containing alternating random consonants and vovels,
we nevertheless believe this to be a good compromise between passwords with a
guaranteed strength and easily rememberable passwords.

• Example password: lysum97kmesi

• Memory trick: lysu m97k mesi

Secure Web Application Development Concepts

Secure design, security design reviews as well as implementation reviews were continuously
practiced according to our secure development method. In addition, security testing was
and is executed by several independent security specialists. DataInherit also subscribes to
McAfee's Secure service that runs vulnerability scans (hacker simulations) on a daily basis.
Last but not least, DataInherit's servers and storages are only hosted in Switzerland in
highly secure datacenters that were approved by the Swiss Federal Banking Commission.

Contact
Dr. Tobias Christen
DSwiss Ltd
8003 Zürich
tobias.christen@dwiss.com

Dipl. Ing. FH Michael Tschannen

ZHAW
8401 Winterthur
michael.tschannen@dswiss.com

Prof. Dr. Marc Rennhard

ZHAW
8401 Winterthur
marc.rennhard@dswiss.com

Zurich, 2009-June-23