In this section we present a stronger security model for one-way authentication channel establishment protocols which is inspired by the security models of [3] and [22]. We enhance the channel establishment security model [3] by considering EphemeralKeyReveal queries and using stronger freshness definition. This enhancement enables us to capture the forward security property in one-way authentication setting which is not captured in the previous one-way authentication channel establishment security models [3, 21].
4.1 Preliminaries
Let \(n_C,n_T,n_S \in N\) be positive integers. Assume that there are \(n_C\) authenticated entities and \(n_T\) unauthenticated entities in the system. Each party can establish at most \(n_S\) sessions. Each party in the system has a distinct identity i.
The protocol description is defined by two efficiently computable stateful (sub)-protocols \(P=\{\varPi ,\mathcal {G}\}\). The protocol \(\varPi \) defines how honest parties behave and \(\mathcal {G}\) is the key generation algorithm. Each execution of the protocol can be modeled as an oracle \(\varPi _i^s\), which means that the session is party i’s s-th instance of carrying out the protocol with some partner j (which is determined during the protocol execution). The oracle has access to its owner’s private key and independently maintains a list of internal state information as follows:
-
\(\delta \in \{derived,accept,reject,\bot \}\) is current state of the key exchange (initialized to \(\bot \)). When the session owner derives a session key, he marks the session as derived. When the key establishment protocol ends successfully (and stipulates that no further messages are to be received), the session owner marks the session as accepted. An accepted session must be derived. \(\delta =reject\) means that the session rejects.
-
\(\rho \in \{initiator,responder\}\) is the role of the participant.
-
pid is the partner identifier which is determined during the protocol execution.
-
sid is the session identifier which can be defined by a transcript of all the messages the session receives and sends.
-
\(\kappa =(\kappa _e^{\rho },\kappa _d^{\rho }) \in (\{0,1\}^* \cup \{\bot \})^2\) is the agreed pair of keys. The order of the keys depends on the role. It is initialized as \((\bot ,\bot )\). \(\kappa \) is set to be the derived session key when \(\delta =derived\).
-
\(T_i^s\) records the transcript of messages sent and received by oracle \(\varPi _i^s\). Initialized as \(\emptyset \).
-
\(kst_i^s \in \{exposed,fresh\}\) denotes the freshness of the session key. Initialized as fresh.
-
\(st_k\in \{0,1\}^*\) is the session state after the session key/channel is established. Initialized as \(\emptyset \).
To distinguish the different types of messages that may occur in an execution, there are three different execution “modes"of protocols: establishing a key, sending, respectively receiving messages from the established channel. Formally, the honest operation of a participant is defined by a triple \(\varPi =(KeyExch,SendCh,ReceiveCh)\).
Some of the messages sent during the key-exchange may travel over the channel. So, strictly speaking, KeyExch may make use of the latter algorithms. To facilitate the description of the resulting complex interaction we define the algorithm EstChannel which, essentially , is in charge of establishing the channel. This algorithm may make calls to the algorithms defining \(\varPi \).
During the execution of a protocol an oracle can receive two types of input, an application message (user input) or a channel message (received from the wire). At any point during its execution, protocol \(\varPi \) takes as input a message m and a message type \(type \in \{ap,ch\}\) indicating the message was received from the user’s application or the channel, respectively, runs the appropriate algorithm, and returns the output of that algorithm. The execution of protocol \(\varPi \) is summarized in Fig. 3.
After the channel has been established whenever the input message type is ch then ReceiveCh will be called. This models messages that are received from the channel (for decryption). It takes as input a message m and state \(st_d\) and outputs a message \(m'\) for output to the user’s application. ReceiveCh rejects and outputs \(\perp \) if the received messages are “out of state" messages (e.g., format error, invalid message).
When the message type is ap then SendCh will be called. This models application messages that are input to be sent (encrypted) on the channel. It takes as input a message m and state \(st_e\) and outputs a message \(m'\) for output to the channel. Note that if keys have not yet been established (\(\delta \ne accept\)) then such a call to SendCh will output \(\perp \).
4.2 Matching Conversations
Denote \(TEstCha^s_i\) and \(TEstCha^t_j\) to be the transcript involved in the execution of Estchannel for oracles \(\varPi _i^s\) and \(\varPi _j^t\) respectively.
Definition 6
(Matching Conversation). We say that an oracle \(\varPi ^s_i\) has a matching conversation to oracle \(\varPi ^t_j\), if \(Prefix(TEstCha^t_j,TEstCha^s_i)=true\) or \(Prefix(TEstCha^s_i,\) \(TEstCha^t_j)=true\).
To keep the correctness of the protocol, two matching sessions which accept should always establish the same session key.
Definition 7
(Correctness). For any two oracles \(\varPi _i^s\) and \(\varPi _j^t\) that have matching conversation with \(pid_i^s=j\), \(pid_j^t=i\), \(\delta _i^s=accept\) and \(\delta ^t_j=accept\) it always holds that \(\kappa _i^s=\kappa _j^t\).
4.3 Adversarial Capabilities
The adversary \(\mathcal {A}\) is a probabilistic polynomial Turing machine taking as input the security parameter \(\lambda \) and the public information, and controls the communication and network. \(\mathcal {A}\) can issue the following queries to oracles \(\varPi _i^s\) for \(i\in [1,n_C+n_T],s\in [1,n_S]\).
-
\(Newsession(i,\rho )\). Create a session for user i with role \(\rho \).
-
\(Send(\varPi _i^s,m,type)\). Send a message m to \(\varPi _i^s\) with type type. As a result \(\varPi _i^s\) will run \(\varPi \) on input (m, type) (as in Fig. 3) and respond with the outputting message \(m^*\) (if there is any) that should be sent according to the protocol specification and its internal states. The state information of \(\varPi _i^s\) will be updated depending on the protocol specification. After the session accepted, this query may initiate ReceiveCh or SendCh algorithms. Note that the session will not send message to the channel when it just invokes the ReceiveCh algorithms.
-
StaticKeyReveal(i). \(\mathcal {A}\) obtains the long-term private key of i if it is an authenticated entity.
-
\(EphemeralKeyReveal(\varPi _i^s)\). \(\mathcal {A}\) obtains the ephemeral private key of session \(\varPi _i^s\).
-
\(SessionKeyReveal(\varPi _i^s)\). \(\mathcal {A}\) gets the derived session key of \(\varPi _i^s\) if \(\delta \) is derived or accepted, at the same time, \(kst_i^s\) is set to be exposed. If at the point when this query is issued, there exists another oracle \(\varPi _j^t\) having matching conversation to \(\varPi _i^s\), then \(kst_j^t\) is also set to be exposed.
Following the routine of [3], to define the security experiments for message authentication and privacy latter, the following notations for each \(\varPi _i^s\) is maintained:
-
Application messages sent \(Ap\text {-}S^s_i\), i.e. the list of all messages m input to \(Send(\varPi ^s_i, m, ap)\).
-
Channel messages sent \(Ch\text {-}S^s_i\), i.e. the list of all outputs from \(Send(\varPi ^s_i , m, ap)\).
-
Channel messages received \(Ch\text {-}R^s_i\), i.e. the list of all messages m input to \(Send(\varPi ^s_i, m, ch)\).
-
Application messages received \(Ap\text {-}R^s_i\), i.e. the list of all outputs from \(Send(\varPi ^s_i, m, ch)\).
Once a channel is established, whenever an application message is input to Send, the protocol \(\varPi \) is executed and a channel message will be output and sent on the channel. Similarly whenever a channel message is input to Send, the protocol \(\varPi \) is run and an application message will be output to the user. The above lists help us keep track of these messages and facilitate checking necessary in the following security models.
4.4 Security Definitions
In this subsection, we consider the security of one-way authentication secure channel establishment protocols, which is the scenario of EMV channel establishment protocol. The parties in the system are classified into two sets. Let C be the set of authenticated participants (the Cards) and let T be the set of unauthenticated participants (the Terminals), where unauthenticated participants do not hold long-term private/public key pairs.
In our model, a Terminal \(i \in T\) wishes to authenticate a Card \(j \in C\) and establish a key (additionally a secure channel) with this Card. For a session \(\varPi _j^t\) owned by party \(j \in C\) with public/secret key pairs, the adversary \(\mathcal {A}\) needs to obtain both static and ephemeral secret keys to get the session key. But if the session has a matching conversation with another session \(\varPi _i^s\) with \(i \in T\), knowing the session’s ephemeral key enables the adversary to get the session key. Since all \(i \in T\) have no long-term secret, it would always be possible for an adversary to impersonate an unauthenticated participant and establish a session with a real Card. So, in our model, the target session should always be a session owned by a Terminal.
We give the freshness definition for a session of a Terminal as follows. The session that the adversary attacks should keep fresh to make sense. In our model, the freshness definition enlarges the scope of sessions the adversary can attack compared to the previous security model [3]. That is, we allow the adversary to obtain either static key or ephemeral key of the Card party involved in the target session. While in [3], the adversary can ask neither keys of this party. So, the forward security property in one-way setting is captured in our model.
Definition 8
(One-Sided Freshness). Let \(\varPi _i^s\) be an accepted session held by a party \(i \in T\) with other party \(j \in C\), and both parties are honest. Session \(\varPi _j^t\) (if it exists) is the matching conversation of \(\varPi _i^s\). Then the session \(\varPi _i^s\) is said to be fresh if none of the following conditions hold:
-
1.
\(\varPi _i^s\) has internal state \(kst_i^s=exposed\).
-
2.
\(\varPi _j^t\) exists and \(\mathcal {A}\) issued one of the following:
-
3.
\(\varPi _j^t\) doesn’t exist and \(\mathcal {A}\) issued one of the following:
As in [3], we formulate three levels of security: Entity Authentication (EA), Message Authentication (MA) and Message Privacy (MP).
Entity Authentication. An adversary violates entity authentication if he can get a session to accept even if there is no unique session of its intended partner that has a matching conversation to it. More formally, the security is defined via an experiment ent played between a challenger \(\mathcal {C}\) and an adversary \(\mathcal {A}\). At the beginning, \(\mathcal {C}\) generates the long-term key pairs \((pk_U,sk_U)\) for all the parties \(U \in C\) and sends the public keys \(pk_U\) for \(U \in C\) to \(\mathcal {A}\). Then the adversary can issue the oracle queries we defined above to the oracles.
Definition 9
(EA). We say that protocol \(P = \{\varPi ,\mathcal {G}\}\) is a \((t,\epsilon _{EA})\)-secure EA protocol if for all adversaries \(\mathcal {A}\) running in time at most t, when \(\mathcal {A}\) terminates, then with probability at most \(\epsilon _{EA}\) there exists a fresh oracle \(\varPi ^s_i\) such that \(\varPi _i^s\) accepts, but there is no unique oracle \(\varPi _j^t\) such that \(\varPi _i^s\) has a matching conversation to \(\varPi _j^t\) for \(i \in T, j \in C\).
Message Authentication. The message authentication property ensures the integrity and authenticity of all messages sent over the channel. For any two partner oracles \(\varPi ^s_i\) and \(\varPi _j^t\), the oracle \(\varPi ^s_i\) should only successfully receive messages which were output by \(\varPi ^t_j\) and vice versa. That is formalized by requiring that for any fresh oracle \(\varPi ^s_i\) with unique partner \(\varPi ^t_j\), \(Prefix(Ap\text {-}R^s_i, Ap\text {-}S^t_j) = true\). If this does not hold then the adversary successfully fools \(\varPi ^s_i\) into receiving an application message which was not output by the partnered oracle \(\varPi ^t_j\).
The authentication experiment auth generates public/private key pairs for each user \(i \in C\) (by running \(\mathcal {G}\)) and returns the public keys to \(\mathcal {A}\). The adversary is permitted to make the queries \(NewSession(i, \rho )\), \(SessionKeyReveal(\varPi ^s_i)\), StaticKeyReveal(i), EphemeralKey \(Reveal(\varPi _i^s)\) as well as \(Send(\varPi ^s_i, m, type)\) with message \(type \in \{ap, ch\}\). On querying \(Send(\varPi ^s_i, m, type)\), the game behaves as in Fig. 4.
The game \(Exec^{auth}_{\varPi } (\mathcal {A})\) between an adversary \(\mathcal {A}\) and challenger \(\mathcal {C}\) is defined as follows:
-
1.
The challenger \(\mathcal {C}\) generates public/private key pairs for each user \(U \in C\) (by running \(\mathcal {G}\)) and returns the public keys to \(\mathcal {A}\).
-
2.
\(\mathcal {A}\) is allowed to make as many NewSession, SessionKeyReveal, \(StaticKeyReveal\), EphemeralKeyReveal, Send queries as it likes.
-
3.
The adversary stops with no output.
We say that an adversary \(\mathcal {A}\) wins the game if there exists \(\varPi ^s_i\) with unique partner \(\varPi ^t_j\) such that they are matching conversations and the list \(Ap\text {-}R^s_i\) is not a prefix of \(Ap\text {-}S^t_j\). The adversary’s advantage is \(Adv^{auth}_{\varPi }(\mathcal {A}) = Pr[\exists \varPi ^s_i, \varPi ^t_j \text { for } i\in T, j\in C: \varPi ^s_i \text{ is } \text{ fresh } \wedge \varPi ^s_i, \varPi ^t_j \text{ are } \text{ matching } \wedge Prefix(Ap\text {-}R^s_i, Ap\text {-}S^t_j) = false]\).
Definition 10
(MA). A protocol \(P = \{\varPi ,\mathcal {G}\}\) is a \((t,\epsilon _{MA})\)-secure MA protocol if for all adversaries \(\mathcal {A}_{auth}\) running in time at most t, \(Adv^{auth}_{\varPi } (\mathcal {A}_{auth}) \le \epsilon _{MA}\).
Message Privacy. The message privacy property ensures that the adversary should not be able to determine which set of messages \(\{m_{01},m_{02},m_{03},\cdots \}\) and \(\{m_{11},m_{12},m_{13},\cdots \}\) has been transmitted on the secure channel.
The message privacy experiment priv initializes the states as in the authentication experiment auth, except that each session now also holds a random secret bit \(b^s_i\). As before, the adversary can make the queries NewSession, SessionKeyReveal, StaticKeyReveal, EphemeralKeyReveal. In addition, the adversary can issue a left-right version of \(Send(\varPi ^s_i,\) m, type) which is used to model message privacy. Specifically, the query \(SendLR(\varPi ^s_i ,m_0,m_1,\) type) takes as input two messages and returns \(Send(\varPi ^s_i,m_{b^s_i}, type)\). When \(type \ne ap\) these two messages are equal, \(SendLR(\varPi ^s_i, m, m, type)\) \(= Send(\varPi ^s_i, m, type)\).
As before, two sessions are matching conversations. On the \(SendLR(\varPi ^s_i\), \(m_0,m_1, type)\) query, the game behaves as in Fig. 4. Once the channel is established, whenever \(SendLR(\varPi ^s_i,\) m, m, ch) is called, we allow the protocol to run as normal but check the lists \(Ch\text {-}R^s_i\) and \(Ch\text {-}S^t_j\). If the message m was a channel output from \(\varPi ^s_i\)’s partner \(\varPi ^t_j\), then SendLR will not return anything. This allows the adversary to progress the state of an oracle but prevents them from trivially winning the game.
Game \(Exec^{priv}_{\varPi }(\mathcal {A})\) between an adversary \(\mathcal {A}\) and challenger \(\mathcal {C}\):
-
1.
The challenger \(\mathcal {C}\), generates public/private key pairs for each user \(U \in C\) (by running \(\mathcal {G}\)) and returns the public keys to \(\mathcal {A}\).
-
2.
\(\mathcal {A}\) is allowed to make as many NewSession, SessionKeyReveal, \(StaticKeyReveal\), EphemeralKeyReveal, SendLR queries as it likes.
-
3.
Finally \(\mathcal {A}\) outputs a tuple \((i, s, b_0)\) for \(i \in T\).
We say the adversary \(\mathcal {A}\) wins if its output \(b_0 = b_i^s\) and \(\varPi ^s_i\) is fresh (and has a unique partner) and the output of \(Exec^{priv}_{\varPi }(\mathcal {A})\) is set to 1. Otherwise the output is 0. Formally we define the advantage of \(\mathcal {A}\) as \(Adv^{priv}_{\varPi } (\mathcal {A}) = | Pr[Exec^{priv}_{\varPi } (\mathcal {A})=1] -1/2|\).
Definition 11
(MP). A protocol \(P =\{\varPi , \mathcal {G}\}\) is a \((t,\epsilon _{MP})\)-secure MP protocol if for all adversaries \(\mathcal {A}_{priv}\) running in time at most t, \(Adv^{priv}_{\varPi }(\mathcal {A}_{priv}) \le \epsilon _{MP}\).
A channel establishment protocol is secure if it satisfies all of the three notions above.
Definition 12
(eEAMAP). Protocol \(P =\{\varPi , \mathcal {G}\}\) is a \((t,\epsilon )\)-secure eEAMAP protocol if it is a \((t,\epsilon )\)-secure EA protocol, a \((t,\epsilon )\)-secure MA protocol and a \((t,\epsilon )\)-secure MP protocol.
4.5 Unlinkability
In practice, the Card holders may also want to have a property that their two independent transactions can not be linked. Actually, this property is formally captured by a notion called unlinkability. In this paper, we adapt the idea of [3] to define our unlinkability definition (see full version of our paper), which means that it should be hard for an adversary to determine whether two particular sessions are linked with the same Card. Note that this property only holds against an eavesdropper adversary who is not a Terminal.