Proof-of-concept log server prototype

To demonstrate the deployment of KUD in a real-world setting, we built a proof-of- concept prototype of the log server. We implemented a full log server implementation with interfaces, and client-side code for (a) adding users/devices, (b) rotating keys at the end of each epoch, and (c) sending messages. This involves all the operations to

5.7. Conclusion 111

manipulate the log (consisting of a tree of trees), produce various proofs, and produce and verify the appropriate signatures. Anticipating a deployment on platforms such as Google’s App Engine, we implemented our code in Python. We use basic caching mechanisms for previously computed results. On a quad-core 4 GHz Intel Core i7 with 32 GB of memory, we obtain the following times. The times are measured locally and therefore do not include network latency. Performing 100000 (1e05) enrollment requests from distinct users takes 1526 seconds, i.e., 15 milliseconds per request on average. When 100000 (1e05) users enroll 3 devices each, enrollment takes 1708 seconds, i.e., 5.7 milliseconds on average. The delay experienced by the user is therefore dominated by the network latency of transmitting 4.1 KB (Table 5.1), which is certainly less than a second.

When the tree contains 10000 (1e04) entries, the server produces 100000 (1e05) responses to message queries in 14.1 seconds, i.e., 0.14 milliseconds per message query. Updating a tree by simultaneously adding 10000 (1e04) entries takes about 1 second, which is mostly spent in creating the leaf data structures. Once again, the user’s experience is mostly affected by the network latency, which is small because the data transferred is a few KB.

The memory usage when 100000 (1e05) users enroll one device is 410 MB (com- puted using “heapy” for the full process, not just reachable objects). If they enroll three devices each, memory usage increases to 900 MB.

Thus, even though our proof-of-concept implementation is not yet optimized for efficiency or storage, its performance already indicates our scheme is feasible.

5.7

Conclusion

We have presented a novel messaging protocol that offers security guarantees even when an attacker can access secret keys in a user’s devices. In particular, (a) the pro- tocol limits the impact of a compromise, since the attacker can only learn messages sent in the same epoch without being detected, and (b) if the attacker uses compro- mised long-term keys to impersonate users, then the protocol allows the participants to detect this, and therefore to take remedial action. Our protocol supports multi- ple devices per user, and the multiplicity of devices helps detect attacks by intuitive indicators to users about which (device) keys have recently been active.

5.7. Conclusion 112

The methods we introduce are not intended to replace existing methods used to keep keys safe. Existing technologies such as TPMs, smart-cards, and ARM TrustZone are all useful for securing keys. However, none of these technologies are completely secure. For example, even if hardware security is used, malware may be able to trigger usages of the key without having the ability to copy the key. Our methods can also detect such cases. Thus, KUD adds an additional layer of security that allows users to detect when other layers fail.

Part IV

Key compromise in secret

distribution

CHAPTER 6

SELF-HEALING DISTRIBUTED

STORAGE

6.1

Introduction

Cloud storage has been widely adopted to relieve the pain of maintaining dedicated hardware locally. For data owners, however, the confidentiality of outsourced data storage is a big concern. In particular, in the presence of system bugs, malware, and cyber attacks, the security of cloud servers cannot be guaranteed [Rya13, AKV15]. The data owner can encrypt the data before outsourcing it to the cloud. But this still leaves open the question of where to store the decryption keys. We would like a solution in which clients do not need to store any decryption keys. A client will authenticate itself to the server in order to request decryption.

One way to achieve such a solution is distributing the decryption keys of the encrypted data to many cloud servers. Secret sharing is a well-known technique to achieve this securely. In this case, an attacker would have to compromise a sufficient number of servers to break the security of the system. This makes the attacker’s work more difficult. However, this solution is not good enough, as an attacker may be able to attack each server one-by-one over a long period. Eventually the attacker would be able to compromise sufficiently many servers and recover the decryption key.

To address this problem, we further develop the idea of storing secrets on several servers, with the aim of preventing gradual attacks over a long time. We assume that time is divided into periods. A server that is compromised in a time period may be repaired by its maintainers in the next time period [SCL+_{15, YR15]. At}

the end of each time period, servers update all their secrets needed to recover the 114

6.1. Introduction 115

decryption key, before they start the next time period. The intuition is that, after a server has been repaired and has updated its secrets, the secrets learnt by an attacker in previous periods are rendered useless.

Unfortunately, the fact that the servers’ secrets could be compromised and are changed periodically causes a problem for how a client should authenticate the servers. To solve this, we require a way for servers to have a public key for authenti- cation that remains constant, even though the associated secrets held by the server are updated in each period. Achieving this requirement means that the clients do not need to be involved in (or even aware of) the server’s regime for updating secrets.

In summary, we identify the following list of requirements:

1. The clients do not need to store any keys for performing decryption.

2. The system is secure even if all servers are compromised over a long time, provided that no more than a threshold number of servers are compromised in a given period.

3. The system provides a fixed public key for authentication, valid for all time periods.

4. The number of messages exchanged between the servers during the update period is independent of the number of data items stored.

5. As with any security protocol, there needs to be a well-defined adversary model, and a formal security proof.

This chapter presents a system based on bilinear pairings for distributed cloud storage, which we call “self-healing” cloud storage. The system satisfies the require- ments mentioned above. One notable feature is that even though the service secrets change in each time period, the public key to be known by data owners remains constant. This feature could be used as a building block that allows us to tackle a more general server authentication issue, where the servers are compromisable cross time periods.

To formally prove the security guarantee of our self-healing scheme, we started our security verification first by using Tamarin prover. However, we found (and