• No results found

2.4 Security

2.4.5 Attack Models

Attack models specify the capabilities of the attacker (i.e., the cryptanalyst) in order to attempt breaking a block cipher while achieving his goal, i.e., finding an attack with a complexity less than the one of exhaustive key search. Such attacks are also referred to as shortcut attacks. The existence of attack models formulating the hostile environment in which a block cipher will be deployed, is crucial when it comes down to designing a new block cipher or an implementation (hardware and/or software) of an existing block cipher with respect to assessing

its security level.

Below, the three main attack models are discussed and a comparison (related to their evolution over time) is given at the end of this section.

Black-Box Model

The black-box model is the model assumed in traditional cryptography. In this attack model, the authorized end-users of the communication channel (i.e., the

SECURITY 27

sender and the receiver(s)) are assumed to be trusted. Where this assumption was valid in the earlier years of cryptography, the wide range of applications in which cryptographic primitives are deployed nowadays clearly shows that the black-box model is inadequate.

The black-box model is the most conservative model in which the information available to the attacker is solely restricted to the input/output behavior of the block cipher, where the input corresponds to the plaintext and secret key, and the output corresponds to the ciphertext (in the case of encryption). According to which information (i.e., input and/or output) is available to the attacker, and to which operations (i.e., read and/or (adaptively) write) the attacker is allowed to perform on this information, a classification of black-box attack models is given below:

Ciphertext-only: the attacker has only read access to the ciphertext. This is

considered to be the default and also weakest attack scenario such that failure to resist attacks within this model implies particularly insecure block cipher designs.

Known plaintext: the attacker has read access to plaintext/ciphertext pairs.

Linear cryptanalysis (cf. Matsui [65]) belongs to this class of attack models.

Chosen plaintext: the attacker has write access to the plaintext and read

access to the corresponding ciphertext. Choosing specific forms of plaintexts is a crucial requirement of differential cryptanalysis (cf. Biham and Shamir [8]).

Chosen ciphertext: the attacker has write access to the ciphertext and read

access to the corresponding plaintext. This attack model requires that the attacker has (limited) access to the decryption routine.

Adaptively chosen plaintext/ciphertext: similar to the ‘chosen variants’

above, with the difference that the attacker is able to depend his choice on intermediate results obtained during the attack.

The above classification is not complete. First, every possible combination of the above mentioned classes results in a valid attack model. Second, as the secret key is part of the input of a block cipher, there exist other attack models such as known key and chosen key (cf. Knudsen and Rijmen [57]) that are of typical interest for block cipher based hash function designs where the key is either known to the attacker or to some extent under the attacker’s control.

Grey-Box Model

In reality, cryptographic primitives such as block ciphers are always implemented either in hardware or software on physical devices. In the black-box model, it is assumed that these implementations behave as ideal black boxes, preventing any observation or tampering of internal operations/data. Hence, the capabilities of the attacker are restricted to observing the input/output behavior of the cryptographic primitives, which together with the knowledge of the (possibly) public specification often results in rather complex attacks with a high computational cost.

However, in practice, the assumption of ideal black boxes is unrealistic. This led to the introduction of a more realistic attack model, i.e., the grey-box model, that no longer assumes that the end-points of the communication channel are trusted (as was the case in the black-box model). In the grey-box model, (limited) access to the implementation belongs to the capabilities of the attacker, such that the information available to the attacker is, apart from the information available in the black-box model, further expanded by implementation-specific information that typically is (weakly) correlated to the cryptographic key. Attacks focusing on the implementation of cryptographic algorithms rather than on the algorithms themselves are referred to as implementation attacks, and can be categorized by the following two classes:

Intrusive nature: this relates to the fact whether the attacker tampers

with the behavior of the system containing the implementation of the cryptographic primitive or not. Hence, the following distinction can be made: (i) active attacks that involve tampering by for example altering the environmental conditions (e.g., heat) and (ii) passive attacks that involve no tampering and are restricted to just observing.

Invasive nature: this relates to the fact whether the attacker tampers with

the device of the cryptographic system in order to gain (direct) access to internal components or not. Depending on the degree of tampering, one can distinguish the following three attacks: (i) invasive attacks that involve direct access to the internal components of the cryptographic system, (ii) semi-invasive attacks that involve access to the system only through the authorized surface and (iii) non-invasive attacks that are limited to the externally available information (which is unintentionally leaked/emitted), i.e., the device remains unaltered.

In general, the subclass of passive non-invasive implementation attacks poses a serious threat to the security of cryptographic devices since they are undetectable and tend to be of low cost. This subclass is formed by the so-called side-channel

SECURITY 29

analysis (SCA) attacks. The implementation-specific information exploited by SCA attacks is called the side-channel information and refers to additional information that is leaked/emitted out of a real-world implementation through unintended side-channels during its execution. Examples of side-channels are execution time, power consumption and electromagnetic radiation. SCA attacks were introduced by Kocher [59] in 1996.

According to how the obtained side-channel information (referred to as side- channel trace(s)) is analyzed, the following distinction can be made: simple and differential SCA attacks. In the case of simple SCA attacks, only one side-channel trace is measured and the attack relies on the correlation between the executed implementation-specific instructions and the side-channel output. In the case of differential SCA attacks, multiple side-channel traces are measured for different input data and the attack exploits the data-dependencies in the obtained side-channel traces based on statistical analysis. Additionally, a distinction can be made between profiled and non-profiled SCA attacks. Profiled SCA attacks contain an a priori profiling phase during which the attacker has full control over a training device that is equal or similar to the attacked physical cryptographic implementation (i.e., the target device). This allows the attacker to gather side-channel traces corresponding to known or chosen inputs and/or keys of the training device in the profiling phase, which later can be used during the actual SCA attack on the target device. An example of a profiled SCA attack is the template attack, introduced by Chari, Rao and Rohatgi [22] in 2002.

White-Box Model

The grey-box model as discussed above is the most severe attack model when it comes down to hardware implementations of cryptosystems, i.e., the attacker is allowed to tamper with the physical device in order to obtain some useful key-correlated side-channel information. However, with respect to software implementations, the model becomes significantly weaker as the attacker is only allowed to have access to the implementation through side-channels such as execution time (see the cache timing attacks discussed in Sect. 2.5.2). In practice, as indicated by the use case treated in Sect. 1.1, the extent to which the attacker has access to software implementations is often much more severe: i.e., in real world applications, software implementations are executed in an untrusted environment and hence are much more vulnerable than merely the unintentional leakage of side-channel information. As a consequence, in 2002, a new ‘realistic’ attack model was introduced by Chow, Eisen, Johnson and van Oorschot [24, 23] under the name of the white-box attack context.

Definition 8(White-box attack context [23, p. 4]). The white-box attack context (WBAC) captures the strongest capabilities of an attacker in the scenario of the execution of software implementations of cryptosystems in a hostile environment. The WBAC assumes that:

1. fully-privileged attack software shares a host with cryptographic software, having complete access to the implementation of algorithms;

2. dynamic execution (with instantiated cryptographic keys) can be observed; 3. internal details of cryptographic algorithms are both completely visible and

alterable at will.

To summarize, in the white-box attack context, also referred to as the white-box model, the end-users are considered to be untrusted as within the grey-box model, and moreover are assumed to have (i) full access to the cryptographic software implementation and (ii) full control over its execution platform. As a result, examples of what an attacker is allowed to perform on cryptographic software in the white-box model are the following:

- static analysis by means of disassemblers or decompilers: the attacker is allowed to reverse-engineer the software implementation and adaptively alter parts of it to his advantage, i.e., tampering with the software; - dynamic analysis by means of debuggers with breakpoint functionality:

the attacker can observe any intermediate result and alter it at will, i.e., injecting well-chosen faults. He is also allowed to start/stop executing the software at any given point;

- search in memory for cryptographic keys.

The list above is not complete, however, it contains the most common capabilities exploited by an attacker in the white-box model (i.e., a white-box attacker ). Within the field of software protection techniques, the white-box model is also known as the malicious host attack model (cf. Sander and Tschudin [94, 93]). Clearly, with respect to software implementations, the white-box model can be considered as a worst case attack model from the perspective of the designer. However, note that a white-box attacker is assumed to have only access to the cryptographic software, and hence not to the software generating the cryptographic software (also known as the white-box (WB) generator). If the attacker also has access to the WB generator, then he steps out of the white-box model; this is an example of an even more severe (maybe not practical) attacker.

SECURITY 31

Comparison Between Attack Models

The biggest change between attack models is determined by the lack of trust in the end-users, which takes place at the transition from the black box model to the grey-box/white-box model. While the mathematical strength of a cryptographic primitive is central to the black-box model, its implementation comes into play in the grey-box model (mainly hardware) and the white-box model (solely software). When going through all three different attack models, i.e., from black-box to grey-box to white-box, it is clear that the threat only increases in accordance to the increasing amount of information available to the attacker (Fig. 2.2). In fact, all models build upon each other in the order mentioned above, e.g., a white-box attacker complies to the grey-box and black-box models. As a consequence, there exists a certain duality concerning the security within the different attack models, where the black-box model is assumed to be the weakest attack model, and the white-box model to be the strongest attack model (here and below, the terms ‘weaker’, ‘weakest’, ‘stronger’ and ‘strongest’ are

from the perspective of the attacker):

1. Insecurity within an attack model implies insecurity within all stronger attack models as well, but not necessarily in the weaker attack models; 2. Security within an attack model implies security within all weaker attack

models as well, but not necessarily in the stronger attack models. As an example, this thesis shows that in early 2014 there exists no secure white-box AES implementation in the academic literature, however, AES is still considered to be a black-box secure block cipher.

Dk(·) Ek(·) m/c c/m adv ersary m/c c/m adv ersary injecting faults - power - time - EM - ... Dk(·) Ek(·) m/c c/m adv ersary - debug - reverse engineer - inspect memory Dk(·) Ek(·) - inject faults - alter implementation

black-box model grey-box model white-box model

weakest increasing security threat strongest

Figure 2.2: The evolution of the attack models.

The shift in attack models is largely caused by the era of the computer and communication devices, i.e., by the fact that cryptography-based applications on

physically (insecure) devices have been brought closer to a very broad audience of end-users, hence also to potentially hostile end-users. Take for example the DRM setting where the end-user is considered to be the opponent. Interestingly, this shift is reflected in the times at which the various attack models have been introduced: the black-box model roughly since the beginning of cryptology, the grey-box model since 1996 and the white-box model since 2002. Note that these introduction times refer to their first appearance in the literature, and that it is likely that the various attack models already existed in practice in advance.