5.1. Security model
Participants. There are n participants in the proposed protocol , which are uniformly denoted by the set , and each participant may have i instances (oracles) involved in distinct, possibly concurrent executions of , where n and i are polynomial numbers.
Sessions. Let denote the mth protocol session running between entity and intended partner entity . A session is accepted if it has computed a session key , with a session identifier of , where is the outgoing information of and is the outgoing information of .
Adversary. The adversary has complete control of the communicating network. Namely, is able to eavesdrop on, alter, ascertain, and inject communication messages. In addition, can have knowledge of the system’s master secret keys, the participants’ long-term private keys, and ephemeral secrets. allows replacing the participants’ public keys. can interact with with the following Oracle queries:
(1) . can obtain the ephemeral secrets of with the query.
(2) . replaces the public key of using this query.
(3) . is available with this query for the public key of .
(4) . By running the query, is able to get the long-term private keys of while the public key of has not yet been replaced.
(5) . Returns ⊥ if session was not accepted. If not, it returns the session key that holds.
(6) . represents sending the message M to in session then receiving a reply from according to .
(7) . The query does not simulate the adversary’s ability, but it simulates the indistinguishability between real session keys and random keys. Input session must be fresh. As a challenger, , toss a coin . If , returns the session key held by ; if , returns a random key from the distribution of the session key.
Matching session. If and have the same session , then is said to be a matching session for .
Freshness. Let denote an accepted session between honest participants and if and are matching sessions. is fresh if all the following conditions do not hold:
(1) issues or queries if exists.
(2) The matching session exists. makes and queries, or and queries.
(3) The matching session does not exist. makes and , or queries.
A game simulates the security of an AKA protocol. In the game, can issue multiple queries in any order. can issue the query only once for a fresh session . Next, a coin is flipped by . When the game ends, will guess the value of b as . If and the test session is still fresh, then wins the game. The advantage of to win the game is defined as .
eCK Security. To ensure the security of the AKA protocol in the eCK model, the following conditions must be met:
(1) If both parties complete a matching session, they will calculate the same session key, unless the probability is negligible.
(2) For any polynomial-time adversary , the advantage in breaking the AKA protocol, , must be negligible.
5.2. Formal security analysis
At first, three empty lists are created to hold the query and the corresponding answers.
L: input-output pairs of the hash function. Instead of being randomly chosen by , the real hash function computes the outputs. To complete the safety proof, needs to record the mapping between the inputs and outputs.
: Tuple for storing the queries-answers of , , and .
: Tuple for storing the queries-answers of .
To continue, it is essential to clarify a few fundamental configurations. Suppose that is activating no more than honest parties, and each party is engaged in no more than sessions. Assume that selects the as the test session. can distinguish a test session key from a random string in the three ways below:
A1. Guessing. guesses the session key correctly.
A2. Key replication. creates a mismatched session that has the same session key as . So is able to fetch the session key by querying the mismatched session.
A3. Forging. The value of is computed at some point by .
Theorem 1. Since the or problem is intractable, the advantage of against the AKA scheme in the eCK model is negligible.
Proof. Since the session key , there is only a chance of guessing the correct in the guessing attack.
The hash function should yield the same results for different input values in order to prevent the key replication attack. The probability of success of a key duplication attack is negligible.
The analysis of the forging attack is shown below.
Consider the tuple as an example of the problem, in which the ephemeral keys and are denoted by and , and the long-term keys and are represented by and . If is successful in forging attack with non-negligible probability, and can be computed by using .
First,
creates a test session
by randomly selecting
and
. Therefore,
has no higher chance of correctly guessing the test session
than
. Let
be the matching session of
. There are six complementary events to consider, as shown in
Table 2.
At least one event in the set, , happens with non-negligible probability if succeeds in faking attack with non-negligible probability.
5.2.1. Analysis of E1
1) Setup. sends to the .
2) Query. will query the public key before an identity is used in any other queries, and all queries are different. answers the queries issued by as follows:
(1) . submits an identity , picks at random , computes , then returns and adds to the list .
(2) . submits a tuple for , replaces with , and update with in the list , where ∗ can be the secret value or be the symbol ⊥.
(3). submits an identity , looks up in the list and returns . If has replaced the public key and has not submitted a new one, will refuse to respond.
(4) . submits a session , then processes as follows:
If or , then fails and stops.
If not, selects at random and appends to .
(5) . submits a session , and processes as follows: If has replaced the public key (or ) and did not submit the new secret value (or ), then may refuse to reply, else
If or , then fails and stops.
If has made for will look up in , , or in , then figures out the session key according to the AKA scheme.
Else, selects at random and appends to , then proceeds as in case 2.
(6) . will answer the query as below.
If , looks up in and then returns .
If , looks up in and then returns .
-
If and , looks up in and processes as follows:
- ·
If has made for , looks up in , then computes and returns .
- ·
If not, randomly selects and calculates and returns , then appends to .
If , accepts .
(7) . If the public key (or ) had been replaced with (or , would have had to commit the new secret value (or to ; since is unable to generate the session key if he does not know the secret values for and . The responses of to are as follows:
If fails and stops.
If , randomly chooses and sends it back to .
3) Solve ECDH problems. To win the game by forging attack, would have to calculate , where and . finds and in and computes and by solving the problem.
4) Probability. If it is possible for to properly guess the test session , will not fail in the query phase. Thus, is able to calculate and with probability , if wins in the game with advantage .
5.2.2. Analysis of E2
(1) Setup. Same as that in the analysis of E1.
(2) Query. responds to the queries from as those in the analysis of E1 except for the , , and .
(1). submits an identity , will respond to the query as follows:
If , computes , returns , and adds to the list .
If not, C randomly selects and calculates , then returns and adds in .
(2) . If , will fail and stop. If not, looks up in and returns .
(3) . will respond to the query as follows:
If or , randomly chooses and returns , then appends to .
If not, randomly chooses and returns , then appends to .
(4) . will respond to the query as follows:
If , looks up in and returns .
If , looks up in , and in , then sends back.
Otherwise, same analysis as E1.
3) Solve ECDH problems. To win the game by forging attack, must compute , where and . finds in the list and in the list to compute and by solving problems.
4) Probability. If it is possible for to properly guess the test session , will not fail in the query phase. Thus, is able to calculate and with the same probability as E1 winning the game.
5.2.3. Analysis of E3
can swap and in E3 and then carry out the analysis of E2.
5.2.4. Analysis of E4
(1) Setup. Same as that in the analysis of E1.
(2) Query. The responses of to the queries from are the same as in E1, except for , , , , and queries.
(1). submits an identity , process as follows:
If , computes , then returns and appends to .
If , computes , then returns and appends to .
Else, C chooses randomly and calculates , then returns and adds in .
(2) . If or , then fails and stops. If not, C looks up in and returns .
(3) . submits a session , randomly chooses and returns , then appends to .
(4) . finds in the list , then responds to queries as follows:
-
If , performs as follows:
- ·
If has made for , looks up in and returns .
- ·
If has made for , looks up in and returns .
- ·
Else, randomly chooses and returns , then appends to .
accepts the session.
3) Solve ECDH problems. To win the game by forging attack, must compute , where and . looks up in to compute and by solving and problems.
4) Probability. If it is possible for to properly guess the test session , will not fail in the query phase. Thus, is able to calculate and with the same probability as E1 winning the game.
5.2.5. Analysis of E5
In E2, there is a matching session for the test session , whereas in E5, there isn’t a matching session for . Therefore, the analysis for E5 is similar to that of E2.
5.2.6. Analysis of E6
In E4, there is a matching session for the test session . However, in E6, there is no matching session for . Therefore, the analysis of E6 is similar to that of E4. ▪