To be usable in practice, any security protocol needs evidence that it can actually fulfill the security requirements that it promises. To this end, security proofs are usually provided to support a newly proposed protocol.
The proofs usually require assumptions on the capabilities of the attacker, especially the type of information accessible to him; for instance, an attacker may be able to not only execute the various algorithms of the protocol, but also to access some secret information, that is otherwise unaccessible to standard users.
Depending on the considered assumptions, one can define a more or less powerful attacker; if a protocol is proved secure against a very powerful attacker, it implies that its security is guaranteed in practice even if the rules of the protocol are not completely respected.
For instance, an encryption protocol may include a “Setup” algorithm wherein a set of secret parameters is generated. These parameters are supposed to be known in practice only by a specific actor, a “Key Generation Centre”. Nonetheless, the protocol may be proved secure even in presence of an attacker who is able to disclose some of this secret information.
In the early days of modern cryptography, a new scheme would be equipped with an informal security analysis, where the author(s) of the scheme would underline the unfeasibility of selected attacks due to the hardness of a particular operation required to perpetrate them.
One drawback of this approach is that it makes assumptions on the strategy followed by the attacker to mount an attack; this approach is limited, since the proof does not guarantee that the attack is not feasible, but shows that a particular strategy to mount it is. This approach clearly does not give any guarantee against different strategies to achieve the same attack: it may be sufficient for simple protocols, but for more complex ones, some unforeseen attacks can still lay undetected.
2.3.1 Game-based Security
To overcome the limits expressed in the previous Section, the notion of game-based se-curity has been established in the cryptographic community. Essentially, this approach consists of the following steps: at first, a generic security property is defined, together with the existence of anadversaryA, whose objective is to break the security property.
The adversary however does not interact directly with real instances of the protocol actors; instead a challenger C simulates internally all other actors. The adversary can interact with the simulated actors through so-called oracles. Usually there is one-to-one mapping between the algorithms defining the protocol and the oracles available for query to the adversary. Additional oracles can also be available to model additional capabilities of the attacker, such as compromising legitimate users or disclosing some otherwise secret material. The more oracles are available to the adversary, the more powerful the adversary is. As a consequence, if the protocol is proved secure against a powerful adversary, it clearly enjoys a stronger security.
After defining the oracles, the challenger sets rules on how the adversary can interact with them: usually, a set ofphases is defined. Phases normally include a query phase, wherein the adversary can freely interact with the oracles; a challenge phase, whereby the adversary is asked to perform a particular action (send a message, give an answer) possibly subject to restrictions linked with the queries of the previous phase, in order to avoid a trivial success of the attacker; this phase can be followed by another round of queries by the attacker.
A security game is identified by the aforementioned oracles and phases together with the attacker definition. Examples of security games are for instance the various games that are now well-established to prove the security of encryption schemes, such as OW-CPA, IND-CCA1 and IND-CCA2 [BDPR98].
The game is set up with the objective of showing that such an attacker, with the capabilities specified through the defined oracles, cannot exist. To this end, the challenger sets up the environment where the attacker can perform its queries and answer the oracle queries using the inputs of a problem whose solution is currently assumed to be hard, i.e. unfeasible in polynomial time. Examples of these problems are for instance the RSA problem [RSA83], the discrete logarithm problem or the Diffie-Hellman problem [DH03].
Of particular importance for this manuscript is the Decisional Diffie-Hellman prob-lem, that we hereby state:
Definition 1 (Hardness of the Decisional Diffie-Hellman Problem). We say that the Decisional Diffie-Hellman Problem (DDH) is hard if, for all probabilistic, polynomial-time algorithms B,
AdvDDHB:=P r[B(g, ga, gb, gx) => if x=ab]−12
is negligible in the security parameter. We assume a random choice of g, a, b; x is equal to ab with probability 12 and is otherwise equal to a random value different from abwith the same probability.
Then a reduction is performed, showing that the complexity of performing the at-tack modeled in the game is equivalent to that of solving the hard problem. Informally, if the adversary manages to break the protocol, it is “tricked” into providing an answer to the hard problem.
The advantage of this approach is the exhaustive coverage of all possible attacks since the proof does not assume any strategy for the adversary.
2.3.2 The Random Oracle Model
Some security protocols may use cryptographic hash functions. Cryptographic hash function are usually functions defined on bitstrings of arbitrary size to bitstrings of a fixed size, say, n. These functions often also enjoy properties such as collision resistance, preimage resistance and second preimage resistance.
To prove the security of protocols using hash functions, it is often required to model them as ideal hash functions, also referred to as random oracles. Concretely, if the challenger controls an oracle simulating some hash function H used by the cryp-tographic scheme, then the outputs of the oracle, which are returned to the adver-sary, are supposed to be computationally indistinguishable from a truly random output source [Bag06].
This is modeled by replacing H with a member of the family of all truly random functions with same domain and codomain, chosen uniformly at random. When queried on the same input, the oracle must be defined to produce the same output, since the hash function will behave this way in the real world. Hence, in the random oracle model, the adversary cannot take advantage of the structure of the real hash function.
First formulated by Bellare and Rogaway in [BR93], the random oracle model is considered as a widely accepted assumption in the community. Provided that the ad-versary has no insight into the hash function, using this black box idealized approach to model hash functions clearly captures the security essence of the overall crypto-graphic scheme. Moreover, the abstraction allows designing cryptocrypto-graphic schemes whose efficiency cannot be achieved if the security proofs are performed without any ideal assumption.
As presented in [BR93], the random oracle model provides thus a bridge between cryptographic theory and cryptographic practice. Critics argue that no single determin-istic polynomial time function can provide a good implementation of random oracles in the real world. In other words, they argue that the random oracle methodology is flawed. We refer the reader to [CGH04] for a critical look at the relationship between the security of cryptographic schemes in the random oracle model and the security of the schemes that result from implementing the random oracle by real hash functions.
2.3.3 The Generic Group Model
The generic group model is a theoretical framework for the analysis of the success of algorithms in groups where the representation of the elements reveals no information to the attacker. The most popular generic group model is the one presented by Victor Shoup [Sho97]. In this model, the attacker is not given direct access to group elements, but rather to the images of group elements under a random one-to-one mapping. The only operations the attacker can perform are therefore equality testing by a bitwise comparison on the images. Group operations can be computed by the attacker through a series of oracles. It is clear that in this situation, the attacker can gain no advantage in solving a computational problem from the representation of the group element.
The generic group is usually not adopted directly to prove the security of a protocol;
instead, it is used to provide evidence as to the hardness of computational problems;
for example [ACHdM05; BB08; LRSW99].
Internally, the simulator represents the elements of a group as their discrete log-arithms relative to a chosen generator. To represent the images of the elements of the group for the attacker, a random one-to-one mapping is used from the considered group – say, of order q – to a codomain represented by random bitstrings of lengthn, such that n = dlog2qe. For instance, the group element ga is represented internally
as a, whereas the attacker is given the external string representation ξ1(a), where ξ represents the aforementioned mapping.
The adversary communicates with the oracles using the string representation of the group elements exclusively. The proof then can show a lower-bound for the complexity of solving the particular problem at hand, under the assumption that the structure of the group does not allow for any operation other than the ones modeled through the set of oracles.