Digital Inheritance

Digital inheritance: a special case of digital escrow Tobias Christen

*1

; Michael Tschannen

*2

; Marc Rennhard

*3

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. HTTPSencrypted 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. Twofactor authentication is a technique commonly used today in environements such as ebanking 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 priorestablished 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 priorestablished 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 [email protected] Dipl. Ing. FH Michael Tschannen ZHAW 8401 Winterthur [email protected] Prof. Dr. Marc Rennhard ZHAW 8401 Winterthur [email protected] Zurich, 2009-June-23