Key-Evolution Schemes Resilient to Space-Bounded Leakage

Abstract

Much recent work in cryptography attempts to build secure schemes in the presence of side-channel leakage or leakage caused by malicious software, like computer viruses. In this setting, the adversary may obtain some additional information (beyond the control of the scheme designer) about the internal secret state of a cryptographic scheme. Here, we consider key-evolution schemes that allow a user to evolve a secret-key K 1 via a deterministic function f , to get updated keys. .. Such a scheme is leakage-resilient if an adversary that can leak on the first i steps of the evolution process does not get any useful information about any future keys. For such schemes, one must assume some restriction on the complexity of the leakage to prevent pre-computation attacks, where the leakage on a key K i simply pre-computes a future key K i+t and leaks even a single bit on it.We notice that much of the prior work on this problem, and the restrictions made therein, can be divided into two types. Theoretical work offers rigor and provable security, but at the cost of having to make strong restrictions on the type of leakage and designing complicated schemes to make standard reduction-based proof techniques go through (an example of such an assumption is that only the data actually used in computation can leak to the adversary). On the other hand, practical work focuses on simple and efficient schemes, often at the cost of only achieving an intuitive notion of security without formal well-specified guarantees.In this paper, we complement the two tracks via a middle-of-the-road approach. On one hand, we rely on the random-oracle model, acknowledging the usefulness of this methodology in practice despite its theoretical shortcomings. On the other hand, we show that even in the random-oracle model, designing secure leakageresilient schemes with clear and meaningful guarantees requires great care and is susceptible to pitfalls. For example, just assuming that leakage "cannot evaluate the random oracle" can be misleading. Instead, we define a new model in which we assume that the "leakage" can be any arbitrary space bounded computation that can make random oracle calls itself. We connect the space-complexity of a computation in the random-oracle modeling to the pebbling complexity on graphs. Using this connection, we derive meaningful guarantees for relatively simple key-evolution constructions. Our security proofs do not rely on the assumption that only data used in the computation can leak.Our scheme is secure also against a large and natural class of active attacks. This is especially important if the key evolution is performed on a PC that can be attacked by a virus. So far, all results that provided solutions against such attacks were secure under the assumption that the virus can download the data from the machine, but he cannot modify any information stored on it (that was called the bounded retrieval model (BRM)). This paper provides the first scheme were the adversary in the BRM can also modify the data stored on...

Proofs of Space: When Space Is of the Essence

“…We adopt the paradigm where the action of pebbling a node in a DAG G is made equivalent to the action of having calculated some labeling on it. This paradigm was introduced in [15] and also recently used in [17,18]. We make use of a Random Oracle (RO) H to build a labeling on G according to the pebbling rules.…”

“…Dziembowski et al [17] built a leakage resilient key evolution scheme based on the pebbling framework. Their model allows an internal memory-bounded adversary that can control the update operation and leak bounded amounts of information.…”

“…Specifically, we will turn to the class of functions derived from the"graph labeling problem" already used in cryptography (see for example [15,17,18]). Important tools in delegation of computation are interactive proof (and argument) systems.…”

Proofs of Space

“…The goal of the player is to pebble a certain vertex of the graph. This technique was used in cryptography already before [21][22][23]. For an introduction to the graph pebbling see, e.g., [48].…”

Reset Indifferentiability and Its Consequences

“…The reason is that, in the random oracle model, every party should have access to the random oracle. In particular, this includes the leakage oracle and the adversarially specified leakage function, resulting in an implicit second stage [14]. Hence, whenever side-channel attacks are reflected in a model, adversaries act at least in two stages-and for real-life applications, we cannot discard side-channel attacks.…”