% !TEX root =  main.tex
The \mEdhoc{} \mSpec{} \cite{our-analysis-selander-lake-edhoc-00} claims
that \mEdhoc{} satisfies many security properties, but these are imprecisely
expressed and motivated.
%
In particular, there is no coherent adversary model.
%
It is therefore not clear in which context properties should be verified.
%
We resolve this by clearly specifying an adversary model, in which we can verify
properties.
%Therefore, we explore in which adversary models we can prove properties and
%incorporate those models into the properties themselves.
%

%In this section, we describe our approach and modeling choices towards
%formalizing the \mEdhoc{} protocol and the properties we verify.
%

\subsection{Adversary Model}\label{sec:threat-model}
We verify \mEdhoc{} in the symbolic Dolev-Yao model, with idealized
cryptographic primitives, e.g, encrypted messages can only be
decrypted using the key, no hash collisions exist etc.
%
The adversary controls the
communication channel, and can interact with an unbounded number of sessions
of the protocol, dropping, injecting and modifying messages at their liking.
%

In addition to the basic Dolev-Yao model, we also consider two more adversary
capabilities, namely long-term key reveal and ephemeral DH half-key reveal.
%
The long-term key reveal models an adversary compromising a party $A$'s
long-term key, and we denote this type of event by \mRevLTK$(A)$.
%
The event \mRevEph$(A, k)$ represents the reveal of the ephemeral DH half-key
used by party $A$ while establishing session key material $k$.
%
These two capabilities model the possibility for long-term keys to be stored in a
hardened storage, a Trusted Execution Environment (TEE), whereas ephemeral keys
may be stored in a less secure part of a device.
%
This is more granular and realistic than assuming an adversary have equal
opportunity to access both types of keys.
%

\subsection{Formalization of Properties}
\label{sec:desired-properties}
%Our model is based on event traces and we define the
%properties in terms of relations between timestamped events.
%
We use the \mTamarin{} verification
tool~\cite{DBLP:conf/cav/MeierSCB13} to encode the model and verify properties.
%
This tool uses a fragment of temporal first order logic to reason about
events and knowledge of the parties and of the adversary.
%
For conciseness we use a slightly different syntax than
that used by \mTamarin{}, but which has a direct mapping to \mTamarin{}'s logic.
%

Event types are predicates over global states of system execution.
%
Let $E$ be an event type and let $t$ be a timestamp indicating a point in a
trace.
%
Then $E^{t}(p_i)_{i\in\mathbb{N}}$ denotes an event of type $E$ associated with a sequence of parameters
$(p_i)_{i\in\mathbb{N}}$ at time $t$ in that trace.
%
In general, more than one event may have the same timestamp and hence
timestamps form a quasi order, which we denote by $t_1 \lessdot t_2$ when $t_1$
is before $t_2$ in a trace.
%
We define $\doteq$ analogously.
%
However, two events of the same type cannot have the same timestamp, so
$t_1 \doteq t_2$ implies $E^{t_1} = E^{t_2}$.
%
This notation corresponds to \mTamarin{}'s use of action facts
$E(p_i)_{i\in\mathbb{N}}@t$.
%
%
%Other first order logic connectives and parenthesis have their standard
%interpretation.
%
%A special event type $\mK$ represents adversary knowledge.
%
The event $\mK^t(p)$ denotes that the adversary knows a parameter $p$ at
time $t$.
%
%Intuitively, events of type $\mK$ evaluate to true when the parameter is in
%the closure of the
%parameters the adversary observed from interacting with parties using the
%protocol, under the operations of the Dolev-Yao message deduction rules and
%the advanced adversary capabilities up until time $t$.
%

%In reference to Figure~\ref{fig:edhocFramework},
% KARL: I appreciate the better English word choice "begun", but the event is
% called I_S, where S is intended to associate to "Start".
An initiator $I$ considers the
protocol run started when it sends message \mMsgone{} (event type \mIStart)
and the run completed after sending message \mMsgthree{} (event type
\mIComplete).
%
%We denote these event types by \mIStart{} and \mIComplete{} respectively.
%
Similarly, a responder $R$ considers the run begun upon receiving
\mMsgone{} (event type \mRStart), and completed upon receiving \mMsgthree{}
(event type \mRComplete). \\
%
%We denote these event types by \mRStart{} and \mRComplete{} respectively.
%
%As is customary, the properties we show are guaranteed to hold for a party when
%the party completes their part of the protocol run.\\
%

%----------------------------------------------------------------------- PFS
%\subsubsection{Secrecy}
\runhead{Perfect Forward Secrecy (PFS)}
\label{sec:secrecy}
%We prove a form of \emph{Perfect Forward Secrecy} (PFS).
%
Informally, PFS captures the idea that session key material remains secret
even if a long-term key leaks in the future.
%
%We formalize PFS for session key material $k$ with respect to the strongest
%adversary model in which we could successfully verify it.
%
We define PFS for session key material $k$ as follows:
%
\begin{align*}
    \mPredPfs \triangleq
    \forall I, R, k, t_2, t_3\mLogicDot
    \mK^{t_3}(k) & \land (\mIComplete^{t_2}(I, R, k)\, \lor\,  \mRComplete^{t_2}(I, R, k))
    \rightarrow\\
    &(\exists t_1\mLogicDot \mRevLTK^{t_1}(I) \land t_1 \lessdot t_2)
    \lor (\exists t_1\mLogicDot \mRevLTK^{t_1}(R) \land t_1 \lessdot t_2)\\
    \lor&(\exists t_1\mLogicDot \mRevEph^{t_1}(R, k))
    \lor(\exists t_1\mLogicDot \mRevEph^{t_1}(I, k)).
\end{align*}
%
% \knote{Note that our Tamarin model only reveals ephemeral keys first when a party
%     completes the run. So even if the formula above checks for ephemeral keys to
%     be revealed as soon as they are created, our Tamarin model will never
%     generate any such traces. That is, we do not actually verify the above
%     formula truly.  How to deal with that?
%     I explain these things in the Tamarin model below, but please check that
%     this sufficiently explicit?
% }
The first parameter $I$ of the \mIComplete{} event represents the
initiator's identity,
and the second, $R$, represents that $I$ believes $R$ to be playing
the responder role.
%
The third parameter, $k$, is the established session key material.
%
The parameters of the \mRComplete{} event are defined analogously.
%
Specifically, the first parameter of \mRComplete{} represents the identity of
whom $R$ believes is playing the initiator role.
%
%The meaning of remaining variables and types should be clear from previous
%descriptions.
%
The essence of the definition is that an adversary only knows $k$ if they
compromised one of the
parties long-term keys before that party completed the run, or if the adversary
compromised any of the ephemeral DH half-keys at any time after a party starts
its protocol run.
% KARL: I don't understand the description below, especially sins it introduces
% a session concept that is not yet defined.  Also, talking about "any other
% information" is a very broad, sounding almost like information theoretic
% security.

% The property states that for any session between $I$ and $R$ which establishes a session key $k$, if the adversary comes to know $k$, then it is because one (or more) of the following happened: the long-term key of $I$ or that of $R$ was obtained by the adversary before the completion of the session, or the ephemeral key used by $I$ or by $R$ was compromised anytime during the session. Any other information obtained by the adversary (or even this same information, obtained at a point of time not as above) does not help them gain access to the established session key. For example, with reference to the informal description above, compromising the long-term key of either party \emph{after} the completion of the session does not give the adversary access to the established session key.

One way the definition slightly differs from the corresponding \mTamarin{} lemma
is that \mTamarin{} does not allow a disjunction on the left-hand side of an
implication in a universally quantified formula.
%
In the lemma, therefore, instead of the disjunction
$\mIComplete^{t_2}(I, R, k)\, \lor\,  \mRComplete^{t_2}(I, R, k)$,
we use a single action parametrized by $I$, $R$, and $k$ to signify that
\emph{either} party has completed their role. \\
%
%This is depicted in Figure~\ref{fig:pfs}.
%%
%\begin{figure}[h!]
%    \begin{center}
%        \tikzset{>=latex}
%        \begin{tikzpicture}
%            % All units in pt
%            \pgfmathsetmacro{\LOFFS}{-20} % Offset between horizontal lines
%            \pgfmathsetmacro{\IS}{50}    % X-coord
%            \pgfmathsetmacro{\IC}{200}    % X-coord
%            \pgfmathsetmacro{\RS}{80}    % X-coord
%            \pgfmathsetmacro{\RC}{230}    % X-coord
%            \pgfmathsetmacro{\LTKI}{200}  % X-coord
%            \pgfmathsetmacro{\LTKR}{230}  % X-coord
%            % I's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,0pt) -- (300pt,0pt);
%            % First event
%            \draw (\IS pt,3pt) node[above] {\mIStart{}};
%            \draw (\IS pt,3pt) -- (\IS pt,-3pt);
%            % Second event
%            \draw (\IC pt,3pt) node[above] {\mIComplete{}};
%            \draw (\IC pt,3pt) -- (\IC pt,-3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\IS pt,0pt) -- (\IC pt,0pt);
%            % R's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,\LOFFS + 0pt) -- (300pt,\LOFFS + 0pt);
%            % First event
%            \draw (\RS pt,\LOFFS + 3pt) node[above] {\mRStart{}};
%            \draw (\RS pt,\LOFFS + 3pt) -- (\RS pt,\LOFFS - 3pt);
%            % Second event
%            \draw (\RC pt,\LOFFS + 3pt) node[above] {\mRComplete{}};
%            \draw (\RC pt,\LOFFS + 3pt) -- (\RC pt,\LOFFS - 3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\RS pt,\LOFFS + 0pt) -- (\RC pt,\LOFFS + 0pt);
%            % LTKRev(I,R)  -----------------------------------------------
%            % Baseline
%            \draw [->] (0pt,2*\LOFFS + 0pt) -- (300pt,2*\LOFFS + 0pt);
%            % Attack events
%            \draw (\LTKR pt,2*\LOFFS + 3pt) node[above] {\mRevLTK$(I)$, \mRevLTK$(R)$};
%            \draw (\LTKR pt,2*\LOFFS + 3pt) -- (\LTKR pt,2*\LOFFS - 3pt);
%        \end{tikzpicture}
%        \caption{Perfect Forward Secrecy: the earliest the adversary can use its
%                 advanced capabilities while secrecy is still maintained.
%                 Ephemeral DH half-keys can never be revealed.}
%        \label{fig:pfs}
%    \end{center}
%\end{figure}\\

%-------------------------------------------------------------------- InjAgree
%\subsubsection{Authentication}
\runhead{Authentication}
\label{sec:authenticationDef}
We prove two different flavors of authentication, the first being classical
\emph{injective agreement} following Lowe~\cite{DBLP:conf/csfw/Lowe97a}, and
the second being an implicit agreement property.
%
Informally, injective agreement guarantees to an initiator $I$ that whenever
$I$ completes a run ostensibly with a responder $R$,
then $R$ has been engaged in the protocol as a responder,
and this run of $I$ corresponds to a unique run of $R$.
%
In addition, the property guarantees to $I$ that the two parties agree on a set
$S$ of parameters associated with the run, including, in particular, the
session key material $k$.
%
However, we will treat $k$ separately for clarity.
%
On completion, $I$ knows that $R$ has access to the session key material.
%
The corresponding property for $R$ is analogous.
%

Traditionally, the event types used to describe injective agreement are called
\emph{Running} and \emph{Commit}, but to harmonize the presentations of
authentication and PFS in this section, we refer to these event types as
\mIStart{} and \mIComplete{} respectively for the initiator, and
\mRStart{} and \mRComplete{} for the responder.
%
For the initiator role we define injective agreement as follows:
\begin{align*}
    \mPredInjI& \triangleq
    \forall I, R, k, S, t_2\mLogicDot \mIComplete^{t_2}(I, R, k, S)
    \rightarrow\\
    &(\exists t_1\mLogicDot \mRStart^{t_1}(R, k, S) \land t_1 \lessdot t_2)
    \land\ (\forall I' R' t_1' \mLogicDot \mIComplete^{t_1'}(I' , R', k, S)
        \rightarrow t_1' \doteq t_1) \\
    &\lor(\exists t_1\mLogicDot \mRevLTK^{t_1}(R) \land t_1 \lessdot t_2).
\end{align*}
%
The property captures that for an initiator $I$, either the injective agreement
property as described above holds, or the long-term key of the believed
responder $R$ has been compromised before $I$ completed its role.
%
Note that this places no restrictions on the reveals of the ephemeral
DH half-keys, or the reveal of the initiator's long-term key.
%
For the responder we define the property as follows.
\begin{align*}
    \mPredInjR& \triangleq\
    \forall I, R, k, S, t_2\mLogicDot \mRComplete^{t_2}(I, R, k, S)
    \rightarrow\\
    &(\exists t_1\mLogicDot \mIStart^{t_1}(I, R, k, S) \land t_1 \lessdot t_2)
    \land (\forall I' R' t_1' \mLogicDot \mRComplete^{t_1'}(I' , R', k, S)
        \rightarrow t_1' \doteq t_1)\\
    &\lor(\exists t_1\mLogicDot \mRevLTK^{t_1}(I) \land t_1 \lessdot t_2).
\end{align*}
%
%\begin{figure}[h!]
%    \begin{center}
%        \tikzset{>=latex}
%        \begin{tikzpicture}
%            % All units in pt
%            \pgfmathsetmacro{\LOFFS}{-20} % Offset between horizontal lines
%            \pgfmathsetmacro{\IS}{70}     % X-coord
%            \pgfmathsetmacro{\IC}{170}    % X-coord
%            \pgfmathsetmacro{\RS}{130}    % X-coord
%            \pgfmathsetmacro{\RC}{240}    % X-coord
%            \pgfmathsetmacro{\LTKI}{200}  % X-coord
%            \pgfmathsetmacro{\LTKR}{230}  % X-coord
%            \draw (-10 pt,10pt) node [above] {\mPredInjI};
%            % I's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,0pt) -- (300pt,0pt);
%            % First event
%            \draw (\IS pt,3pt) node[above] {\mIStart{}};
%            \draw (\IS pt,3pt) -- (\IS pt,-3pt);
%            % Second event
%            \draw (\IC pt,3pt) node[above] {\mIComplete{}};
%            \draw (\IC pt,3pt) -- (\IC pt,-3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\IS pt,0pt) -- (\IC pt,0pt);
%            % R's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,\LOFFS + 0pt) -- (300pt,\LOFFS + 0pt);
%            % First event
%            \draw (\RS pt,\LOFFS + 3pt) node[above] {\mRStart{}};
%            \draw (\RS pt,\LOFFS + 3pt) -- (\RS pt,\LOFFS - 3pt);
%            % Second event
%            \draw (\RC pt,\LOFFS + 3pt) node[above] {\mRComplete{}};
%            \draw (\RC pt,\LOFFS + 3pt) -- (\RC pt,\LOFFS - 3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\RS pt,\LOFFS + 0pt) -- (\RC pt,\LOFFS + 0pt);
%            % LTKRev(I,R)  -----------------------------------------------
%            % Baseline
%            \draw [->] (0pt,2*\LOFFS + 0pt) -- (300pt,2*\LOFFS + 0pt);
%            % Attack events
%            \draw (\IC pt,2*\LOFFS + 3pt) node[above] {\mRevLTK$(R)$,\mRevEph$(I,k)$};
%            \draw (\IC pt,2*\LOFFS + 3pt) -- (\IC pt,2*\LOFFS - 3pt);
%            \draw (\IS - 50 pt,2*\LOFFS + 3pt) node[above] {\mRevLTK$(I)$};
%            \draw (\IS - 50 pt,2*\LOFFS + 3pt) -- (\IS - 50 pt,2*\LOFFS - 3pt);
%            \draw (\RC pt,2*\LOFFS + 3pt) node[above] {\mRevEph$(R, k)$};
%            \draw (\RC pt,2*\LOFFS + 3pt) -- (\RC pt,2*\LOFFS - 3pt);
%            %\draw (\RS pt,2*\LOFFS + 3pt) node[above] {\mRevEph$(R, k)$};
%            %\draw (\RS pt,2*\LOFFS + 3pt) -- (\RS pt,2*\LOFFS - 3pt);
%            % InjAgree for R =============================================
%            \pgfmathsetmacro{\IS}{70}     % X-coord
%            \pgfmathsetmacro{\IC}{170}    % X-coord
%            \pgfmathsetmacro{\RS}{130}    % X-coord
%            \pgfmathsetmacro{\RC}{240}    % X-coord
%            \pgfmathsetmacro{\LTKI}{200}  % X-coord
%            \pgfmathsetmacro{\LTKR}{230}  % X-coord
%            \draw (-10 pt,4*\LOFFS+6pt) node [above] {\mPredInjR};
%            % I's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,4*\LOFFS + 0pt) -- (300pt,4*\LOFFS + 0pt);
%            % First event
%            \draw (\IS pt,4*\LOFFS + 3pt) node[above] {\mIStart{}};
%            \draw (\IS pt,4*\LOFFS + 3pt) -- (\IS pt,4*\LOFFS + -3pt);
%            % Second event
%            \draw (\IC pt,4*\LOFFS + 3pt) node[above] {\mIComplete{}};
%            \draw (\IC pt,4*\LOFFS + 3pt) -- (\IC pt,4*\LOFFS + -3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\IS pt,4*\LOFFS + 0pt) -- (\IC pt,4*\LOFFS + 0pt);
%            % R's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,5*\LOFFS + 0pt) -- (300pt,5*\LOFFS + 0pt);
%            % First event
%            \draw (\RS pt,5*\LOFFS + 3pt) node[above] {\mRStart{}};
%            \draw (\RS pt,5*\LOFFS + 3pt) -- (\RS pt,5*\LOFFS - 3pt);
%            % Second event
%            \draw (\RC pt,5*\LOFFS + 3pt) node[above] {\mRComplete{}};
%            \draw (\RC pt,5*\LOFFS + 3pt) -- (\RC pt,5*\LOFFS - 3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\RS pt,5*\LOFFS + 0pt) -- (\RC pt,5*\LOFFS + 0pt);
%            % LTKRev(I,R)  -----------------------------------------------
%            % Baseline
%            \draw [->] (0pt,6*\LOFFS + 0pt) -- (300pt,6*\LOFFS + 0pt);
%            % Attack events
%            \draw (\RC pt,6*\LOFFS + 3pt) node[above] {\mRevLTK$(I)$,\mRevEph$(R,k)$};
%            \draw (\RC pt,6*\LOFFS + 3pt) -- (\RC pt,6*\LOFFS - 3pt);
%            \draw (\IS - 50 pt,6*\LOFFS + 3pt) node[above] {\mRevLTK$(R)$};
%            \draw (\IS - 50 pt,6*\LOFFS + 3pt) -- (\IS - 50 pt,6*\LOFFS - 3pt);
%            \draw (\IC pt,6*\LOFFS + 3pt) node[above] {\mRevEph$(I, k)$};
%            \draw (\IC pt,6*\LOFFS + 3pt) -- (\IC pt,6*\LOFFS - 3pt);
%            %\draw (\RS pt,6*\LOFFS + 3pt) node[above] {\mRevEph$(R, k)$};
%            %\draw (\RS pt,6*\LOFFS + 3pt) -- (\RS pt,6*\LOFFS - 3pt);
%        \end{tikzpicture}
%        \caption{Injective agreement guarantee: the earliest the
%        adversary can use its advanced capabilities such that the properties
%        are still proven to be maintained.}
%        \label{fig:injAgree}
%    \end{center}
%\end{figure}
%%

%------------------------------------------------------------- Implicit auth
Unlike PFS, not all \mEdhoc{} methods enjoy the injective agreement property.
%
Hence, we show for all methods a form of \emph{implicit agreement} on all the
parameters mentioned above.
%
We take inspiration from the computational model definitions of implicit
authentication, proposed by Guilhem~et~al.~\cite{DBLP:conf/csfw/GuilhemFW20}, to
modify classical injective agreement into an implicit property.
%
A small but important difference between our definition and theirs, is that
they focus on
authenticating a key and related identities, whereas we extend the more general
concept of agreeing on a set of parameters, inspired by the idea of injective
agreement~\cite{DBLP:conf/csfw/Lowe97a}.
%
We use the term \emph{implicit} in this context to denote that a party $A$
assumes that any other party $B$ who knows the session key material $k$ must
be the intended party, and that $B$ (if honest) will also agree on a set
$S$ of parameters computed by the protocol, one of which is $k$.
%
When implicit agreement holds for both roles, upon completion, $A$ is guaranteed
that $A$ has been or is engaged in exactly one protocol run with $B$ in the
opposite role, and that $B$ has been or will be able to agree on $S$.
%
The main difference to injective agreement is that $A$ can conclude that if
$A$ sends the last message and this reaches $B$, then $A$ and $B$ have agreed
on $I$, $R$ and $S$.
%
In contrast to injective agreement, this property is symmetric with respect to
the initiator and responder role.
%

%In particular, because the property only reasons about completed and
%hypothetically completed protocol runs, it can reason about parameters that the
%responder learns only after receiving the last message.
%
While almost full explicit key authentication, as defined by
Guilhem~et~al.~\cite{DBLP:conf/csfw/GuilhemFW20}, is a similar property, our
definition does not require key confirmation, so our definition is closer to
their definition of implicit authentication.
%
In the \mTamarin{} model we split the property into one lemma for
$I$ and one for $R$.
%
We show only the definition for $I$ because it is symmetric to the one
for $R$.
%
\begin{align*}
    \mPredImpI& \triangleq
    \forall I, R, k, S, t_1\mLogicDot \mIComplete^{t_1}(I, R, k, S)
    \rightarrow\\
      &(\forall I', R', S', t_2\mLogicDot \mRComplete^{t_2}(I', R', k, S') \rightarrow
             (I=I' \land R=R' \land S=S'))\\
      &\land (\forall I', R', S', t_1'\mLogicDot
        (\mIComplete^{t_1'}(I', R', k, S') \rightarrow t_1' \doteq t_1
        )\\
    & \ \ \ \lor(\exists t_0\mLogicDot \mRevLTK^{t_0}(R) \land t_0 \lessdot t_1)
    \lor(\exists t_0\mLogicDot \mRevEph^{t_0}(R, k))
    \lor(\exists t_0\mLogicDot \mRevEph^{t_0}(I, k)).
\end{align*}
%

For implicit agreement to hold for the initiator $I$, the ephemeral DH half-keys
can never be revealed.
%
However, the responder $R$'s long-term key can be revealed after $I$ completes
its run.
%
The initiator's long-term key can also be revealed at any time without affecting
$I$'s guarantee.\\
%
%\begin{figure}[h!]
%    \begin{center}
%        \tikzset{>=latex}
%        \begin{tikzpicture}
%            % All units in pt
%            \pgfmathsetmacro{\LOFFS}{-20} % Offset between horizontal lines
%            \pgfmathsetmacro{\IS}{80}     % X-coord
%            \pgfmathsetmacro{\IC}{200}    % X-coord
%            \pgfmathsetmacro{\RS}{120}    % X-coord
%            \pgfmathsetmacro{\RC}{230}    % X-coord
%            \pgfmathsetmacro{\LTKI}{200}  % X-coord
%            \pgfmathsetmacro{\LTKR}{230}  % X-coord
%            % I's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,0pt) -- (300pt,0pt);
%            % First event
%            \draw (\IS pt,3pt) node[above] {\mIStart{}};
%            \draw (\IS pt,3pt) -- (\IS pt,-3pt);
%            % Second event
%            \draw (\IC pt,3pt) node[above] {\mIComplete{}};
%            \draw (\IC pt,3pt) -- (\IC pt,-3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\IS pt,0pt) -- (\IC pt,0pt);
%            % R's session ------------------------------------------------
%            % Baseline
%            \draw [->] (0pt,\LOFFS + 0pt) -- (300pt,\LOFFS + 0pt);
%            % First event
%            \draw (\RS pt,\LOFFS + 3pt) node[above] {\mRStart{}};
%            \draw (\RS pt,\LOFFS + 3pt) -- (\RS pt,\LOFFS - 3pt);
%            % Second event
%            \draw (\RC pt,\LOFFS + 3pt) node[above] {\mRComplete{}};
%            \draw (\RC pt,\LOFFS + 3pt) -- (\RC pt,\LOFFS - 3pt);
%            % Thick session span line
%            \draw [line width=2pt] (\RS pt,\LOFFS + 0pt) -- (\RC pt,\LOFFS + 0pt);
%            % LTKRev(I,R)  -----------------------------------------------
%            % Baseline
%            \draw [->] (0pt,2*\LOFFS + 0pt) -- (300pt,2*\LOFFS + 0pt);
%            % Attack events
%            \draw (\IC pt,2*\LOFFS + 3pt) node[above] {\mRevLTK$(R)$};
%            \draw (\IC pt,2*\LOFFS + 3pt) -- (\IC pt,2*\LOFFS - 3pt);
%            \draw (\IS - 50 pt,2*\LOFFS + 3pt) node[above] {\mRevLTK$(I)$};
%            \draw (\IS - 50 pt,2*\LOFFS + 3pt) -- (\IS - 50 pt,2*\LOFFS - 3pt);
%        \end{tikzpicture}
%        \caption{Implicit agreement guarantee for $I$: the earliest the
%        adversary can use its advanced capabilities. Ephemeral keys can never be
%        revealed.}
%        \label{fig:impAgreeI}
%    \end{center}
%\end{figure}
%%

%

%------------------------------------------------------- Agreed parameters
\runhead{Agreed Parameters}
\label{sec:agreedParams}
%\subsubsection{Agreed Parameters}
The initiator $I$ gets injective and implicit agreement guarantees on the
following partial set $S_P$ of parameters:
\begin{itemize}
    \item the roles played by itself and its peer,
    \item responder identity,
    \item session key material (which varies depending on \mEdhoc{} method),
    \item context identifiers \mCi{} and \mCr{}, and
    \item cipher suites \mSuites{}.
\end{itemize}
%
Because \mEdhoc{} aims to provide identity protection for $I$, there is no
injective agreement guarantee for $I$ that $R$ agrees on the initiator's
identity.
%
For the same reason, there is no such guarantee for $I$ with respect to
the \mGiy{} part of the session key material when $I$ uses the \mStat{}
authentication method.
%
There is, however, an implicit agreement guarantee for $I$ that $R$ agrees on
$I$'s identity and the full session key material.
%
Since $R$ completes after $I$, $R$ can get injective agreement guarantees on
more parameters, namely also the initiator's identity and the full session key
material for all methods.
%
The full set of agreed parameters ($S_F$) is $S_P \cup \{I, \mGiy\}$
when \mGiy{} is
part of the session key material, and $S_P \cup \{I\}$ otherwise.\\
%

%------------------------------------------------------- Implied properties
\runhead{Inferred Properties}
%\subsubsection{Subsumed Properties}
Given that the PFS and agreement properties
above hold, other properties can be inferred to hold in our adversary model.
%
Protocols where a party does not get confirmation that their peer knows the
session key material may be susceptible to
\emph{Key-Compromise Impersonation (KCI)}
attacks~\cite{DBLP:conf/ima/Blake-WilsonJM97}.
%
Attacks in this class allow an adversary in possession of a party $A$'s secret
long-term key to coerce $A$ to complete a
protocol run believing it authenticated a certain peer $B$, but where $B$ did
not engage with $A$ at all in a run.
%
Because both our notions of agreement above ensure agreement on identities,
roles and session key material, all methods passing verification of those are
also resistant to KCI attacks.
% KARL: I added a caveat in the first sentence.
% In a sense we have modelled some of it as explicit as it gets: entity
% authentication for instance: both parties agree on their own and on their
% peer's identity. We do show that (implicitly for all methods, and explicitly
% for some).

% \knote{Even if this is true for the formalization above, it may not hold once
%     encoded into Tamarin. Cas mentioned at IndoCrypt that there are KCI attacks
%     that Tamarin cannot discover (need reference for that).
% }
% \vnote{This is fair. I think if we move this to discussion (or even if we don't) we should make a note that we have not formalized these in Tamarin and are merely following evident inferences.}

If a party $A$ can be coerced into believing it completed a run with $B$, but
where the session key material is actually shared with $C$ instead, the
protocol is vulnerable to an \emph{Unknown Key-Share (UKS)}
attack~\cite{DBLP:conf/ima/Blake-WilsonJM97}.
%
For the same reason as for KCI, any method for which our agreement
properties hold is also resistant to UKS attacks.
%

From the injective agreement properties it follows that each party is assured
the identity of its peer upon completion.
%
Therefore, the agreement properties also capture \emph{entity authentication}.
%
%We say that \mEdhoc{} in method $m$ satisfies \emph{explicit authentication} for
%the initiator $I$ with a responder $R$, if injective agreement holds for $I$
%with $R$ on the session key $sk$, when running method $m$.
%%
%The corresponding definition for the responder is analogous.
%%
%If both parties obtain explicit authentication we refer to it as mutual explicit
%authentication (or simply explicit authentication).
%%
%A party $A$ is guaranteed explicit authentication when both parties have
%agreement on fresh session key material, each others identities and roles
%(and other parameters), when $A$ completes the protocol run.
%%
%Because they have (cryptographically justified) agreement on each others
%identities, it follows that explicit authentication implies entity
%authentication.
%%
%As we discuss later, it turned out that explicit authentication does not hold for all
%\mEdhoc{} methods, in which cases we prove \emph{implicit authentication}.

%Computational models often rely on implicit session key authentication
%(see, for example, the definition of SK-security in the Canetti-Krawczyk
%model~\cite{DBLP:conf/crypto/CanettiK02}).
%%
%Although symbolic models predominantly rely on correspondence properties
%in the style of Lowe~\cite{DBLP:conf/csfw/Lowe97a}, there are examples where
%implicit session key authentication has been used.
%%
%For example, Schmidt~et~al.~\cite{DBLP:conf/csfw/SchmidtMCB12} use a
%symbolized version of an extended Canetti-Krawzcyk model.

%%
%We say that a protocol satisfies \emph{implicit authentication} if the
%initiator and responder agree on the session key only after both parties
%successfully completes the protocol.
%%
%That is, authentication is implicit, as the
%initiator receives no confirmation that the responder has computed the same session key.
%%
%More precisely, we adapt the definition of~\cite{DBLP:journals/iacr/GuilhemFW19}
%to the symbolic model, and we prove that if an initiator $I$ and a responder $R$
%complete the protocol deriving the same session key, then $I$ believes they are
%talking to $R$ and vice versa.
%%

%\mEdhoc{} claims to support mutual authentication with consistency, aliveness
%and peer awareness (see Section~\ref{sec:claimedProperties}).
%%
%These claims appear to have been imported from \mSigma{}~\cite{sigma}, using the
%inheritance argument, because all three appear there as well.
%%
%The definition of consistency~\cite{sigma} is very close in intent to the
%definition we use for implicit authentication, except that it is posed in a
%computational setting.
%%
%We therefore consider them equal in terms of intent for the purpose of this
%paper.
%%
%Aliveness is, according to \mSigma{}~\cite{sigma}, guaranteed to a party $A$ if
%after running the protocol with $B$, $A$ knows that $B$ was alive during
%the execution, e.g., by verifying that $B$ signed a challenge.
%%
%For \mEdhoc{} this means that if we can prove mutual injective agreement, i.e.,
%explicit authentication, on \mGxy{}, then mutual aliveness follows.
%%
%Peer awareness is informally defined in~\cite{sigma} as the guarantee
%that if $A$ completes a protocol run with $B$, then not only does $A$
%know that $B$ is alive, but also that $B$ has initiated a corresponding session
%with $A$.
%\\

%\runhead{Perfect Forward Secrecy (PFS)}
%%\subsubsection{Perfect Forward Secrecy}
%Perfect forward
%secrecy holds if, for any run in which the initiator and the responder
%agree on a session key $sk$ and any of their long-term keys are revealed after
%the run is complete, the attacker does still not learn $sk$.

%\subsubsection{Key-Compromise Impersonation} (KCI) This property takes the perspective of one
%of the endpoints of the protocol, say Alice running a session with Bob. A
%protocol is secure under KCI if Alice can still establish a secure session with
%Bob, even though Alice's keys are compromised at any time, and Bob's key
%material is not leaked until the end of the session.
%
%
%\subsubsection{Post-Compromise Security} (PCS) A protocol that has
%\emph{post-compromise security} (following definitions in~\cite{cohn2016post})
%is capable of establishing a secure session even after one of the parties has
%been compromised. Cohn-Cordon et al.~\cite{cohn2016post} presents two notions of
%PCS, namely weak and strong PCS: here we focus on the latter.
%%
%A protocol guarantees \emph{weak PCS} if secrecy of any session key $sk$ holds
%between the initiator and the responder, even if the run of the protocol that
%established $sk$ happens after a \emph{limited compromise}, where the key
%material is not leaked, but the attacker is capable of impersonating both
%parties (i.e. has the ability to perform all cryptographic operations using the
%initiator's and responder's long term keys, but has not access to the long term
%keys).

%With the first rule we allow the protocol to decrypt the message \mT{m} if the encryption has matching key \mT{k}, authenticated data \mT{ad}, and uses the same algorithm \mT{al}.
%
%The second rule allows the attacker to decrypt the message \mT{m} with the key
%\mT{k} and without the authenticated data \mT{ad}, and hence skip the check.

%The built-in theories for XOR and Diffie-Hellman are a fair bit more complex
%than authenticated encryption, hence we refer to the original
%papers~\cite{DBLP:conf/csfw/DreierHRS18,DBLP:conf/csfw/SchmidtMCB12}
%for a full reference.
%

%\subsubsection{Syntactic Sugar} In the following presentation we use some syntactic
%sugar, namely
%the use of let bindings (\mT{let ... in}), which are series of
%definitions of patterns which are substituted in the rest of the rule. %Another
%prominent feature is the use of tuples (\mT{<t1, ..., tn>}) which are a
%built-in concept in \mTamarin.

%---------------------------------------------------------------------------
\subsection{\mTamarin{}}
\label{sec:tamarin}
% \knote{FOR PFS: It turns out that Tamarin's logic does not allow formulas of the form:
%     $(A \lor B) \rightarrow C$, so I cannot make the Tamarin model match the
%     formula above. The Tamarin model still uses one event type to represent that
%     either $I$ or $R$ completed.  One way of solving this is to say here in the
%     paper that we define a new event type $\mathbf{Comp} =
%     \mIComplete \lor \mRComplete$. That is exactly what is going on anyway.
% }
We chose \mTamarin{} to model and verify \mEdhoc{} in the symbolic model.
%
\mTamarin{} is an interactive verification tool in which models are specified
as multi-set rewrite rules that define a transition relation.
%
The elements of the multi-sets are called facts and represent the global system
state.
%
Rules are equipped with event annotations called actions. Sequences of actions make up the execution trace.
%
These actions allow the user to check logic formulas on models.
%
%The logic used is a fragment of temporal first order logic.
%

Multi-set rewrite rules with actions are written $ l \ifarrow[e] r $,
where $l$ and $r$ are multi-sets of facts, and $e$ is a multi-set of actions.
%
% Facts and actions are $n$-ary predicates over a term algebra, which defines a
% set of function symbols $\mathcal F$, variables $\mathcal V$ and names
% $\mathcal N$.
Facts and actions are $n$-ary predicates over a term algebra, which defines a
set of function symbols, variables and names.
%
\mTamarin{} checks equality of these terms under an equational theory $E$.
%
For example, one can write $ dec(enc(x,y),y) =_E x $
to denote that symmetric decryption reverses the encryption operation under
this theory.
%
The equational theory $E$ is fixed per model, and hence we omit the subscript.
%
\mTamarin{} supports let-bindings and tuples as syntactic sugar to simplify
model definitions.
%
It also provides built-in rules for Dolev-Yao adversaries and for
managing their knowledge.
%
We implement events using actions, and parameters associated with events using
terms of the algebra.\\
%

%To simplify the exposition, we do not describe the model in full detail, but
%all the \mTamarin{} code can be found in~\cite{edhocTamarinRepo}.\\
%

%\runhead{Semantics and Built-ins}
%%\subsubsection{Semantics and Built-ins} \phantom{}
%\mTamarin{} states
%$S$, $S'$ are multisets of facts, and a semantic transition of the form $S \semarrow[E] S'$
%occurs if there is a rule $l \ifarrow[e] r$ and a substitution $\sigma$ such
%that $S \supseteq \sigma(l)$ and $S' = S \setminus \sigma(l) \uplus \sigma(r)$
%and $E = \sigma(e)$.
%
%There are a few more details, such as persistent facts which are denoted by a $!$
%and are never removed from the state.
%%
%The sorts fresh (denoted by $\sim$) and public (denoted by $\$$) denote fresh
%constants and public values known to the attacker respectively, and are both
%sub-sorts of a base sort.
%%
%Finally, \mTamarin{} has some built-in predicates ($\mIn,
%\mOut$ to represent input and output of messages with the attacker,
%and
%$\mFr$ to denote a fresh constant created in the current rule, among
%others), rules and equations that represent the attacker's knowledge
%and standard equational theories in the symbolic model,
%which we present later.

%\anote{This can go, I make a shorter note later:\\
%{Notational conventions} In the remainder of this section we present
%\mTamarin{} code as it appears in the models that we verify, in the style of
%literate programming.  Whenever possible we match the style of the protocol
%diagrams in Section~\ref{sec:edhoc} and the naming convention of the \mEdhoc{}
%\mSpec~\cite{selander-lake-edhoc-01}, so that each element of the model is
%traceable to the standard.  There are a few exceptions to this, most notably
%some variable names that we introduce for the sake of the \mTamarin{} model and are
%not present in the original \mSpec{}, which will appear in \mT{camelCase}, and
%the syntax for Diffie-Hellman exponentiation which is specific to \mTamarin{}.
%We also use \mT{xx} to name the ephemeral key for the initiator (resp. \mT{yy}
%for the responder) as to avoid confusion with \mTamarin's builtin variable
%names \mT{x} and \mT{y}.}

\runhead{Protocol Rules and Equations}
%\subsubsection{Protocol Rules and Equations}
\mTamarin{} allows users to define new function symbols and equational theories.
These user-defined objects are then translated by \mTamarin{} into rewrite
rules, which are added to the set of considered rules during verification.
For example, in our model we have a symbol to denote authenticated encryption,
for which \mTamarin{} produces the following rule:
%
\begin{lstlisting}
[!KU(k), !KU(m), !KU(ad), !KU(ai)] --> [!KU(aeadEncrypt(k, m, ad, ai))]
\end{lstlisting}
%
to denote that if the adversary knows a key \mT{k}, a message \mT{m}, the
authenticated data \mT{ad}, and an algorithm \mT{al}, then they can construct
the encryption, and thus get to know the message
\mT{aeadEncrypt(k, m, ad, al)}.

%-------------------------------------------------------------------------- sub
\subsection{Modeling \mEdhoc{} in \mTamarin}
\label{sec:modeling}
%In this section we detail the modeling choices that we have made for this formal
%verification effort.
%
We model five different methods of \mEdhoc{}, namely \mPskPsk,
\mSigSig, \mSigStat, \mStatSig{} and \mStatStat.
%
The methods share a lot of common structure, and we derive
their \mTamarin-models from a single specification written with the aid of the
M4 macro language.
%
%Whenever possible we adhere with the variable names present in the \mSpec{} and
%in Section~\ref{sec:edhoc}.
%%
%There are a few exceptions: we use \mT{camelCase} for names introduced in the
%modeling, and we use \mT{xx} and \mT{yy} for the ephemeral keys, to avoid name clashes.
%
To keep the presentation brief, we only present the \mStatSig{} metohod, as it
illustrates the use of two different asymmetric authentication methods
simultaneously.
%
%More details on the \mPskPsk{} method and
The full \mTamarin{} code for all models can be found at~\cite{edhocTamarinRepo}.
\\
%\anote{Fix: give a dropbox link instead of the repo}
%

%\subsubsection{Primitive Operations}
\runhead{Primitive Operations}
Our model uses the built-in theories of exclusive-or and DH operations, as
in~\cite{DBLP:conf/csfw/DreierHRS18,DBLP:conf/csfw/SchmidtMCB12}.
%
Hashing is modeled via the built-in hashing function symbol augmented
with a public constant as additional input, to model different
hash functions.
%
%Due to not modeling error messages, the selected hash function is fixed.
%
The HKDF interface is represented by \mT{expa} for the
expansion operation and \mT{extr} for the extraction operation.
%
Signatures use \mTamarin's built-in theory for \mT{sign} and \mT{verify}
operations.
%
%The XOR theory introduces the symbol \mT{XOR}, plus the necessary equational theory including associativity, commutativity, and inverse.
%
%The Diffie-Hellman theory introduces exponentiation \mT{g^y} and product of exponents \mT{x * y} as built-in symbols in the language, plus the necessary equational theory of associativity, commutativity, distributivity of exponentiation with product, and inverse.
%
For \mAead{} operations on key \mT{k}, message \mbox{\mT{m}}, additional data \mT{ad}
and algorithm identifier \mT{ai}, we use \mT{aeadEncrypt(k, m, ad, ai)}
for encryption.
%
Decryption with verification of the integrity is defined via the equation
\mT{aeadDecrypt(k, aeadEncrypt(k, m, ad, ai), ad, ai) = m}.
%
To enable the adversary to decrypt without needing to verify the integrity, we
also add the equation \mT{decrypt(k, aeadEncrypt(k, m, ad, ai), ai) = m}.
%
The latter equation is not used by honest parties.\\
%

%\subsubsection{Protocol Environment and Adversary Model}
\runhead{Protocol Environment and Adversary Model}
We model binding between a party's identity and a public key using the
following rules.
%
\begin{lstlisting}
rule registerLTK_SIG:
    [Fr(~ltk)] --[UniqLTK($A, ~ltk)]->
        [!LTK_SIG($A, ~ltk), !PK_SIG($A, pk(~ltk)), Out(<$A, pk(~ltk)>)]
rule registerLTK_STAT:
    [Fr(~ltk)] --[UniqLTK($A, ~ltk)]->
        [!LTK_STAT($A, ~ltk), !PK_STAT($A, 'g'^~ltk), Out(<$A, 'g'^~ltk>)]
\end{lstlisting}
%
The rules \mT{registerLTK_SIG} and \mT{registerLTK_STAT} register a public key
for the \mSig{}- and \mStat{}-based methods respectively.
%
%A similar rule \mT{registerLTK_PSK} registers pre-shared symmetric keys for
%pairs of agents.
%%
The fact \mT{Fr(~ltk)} creates a fresh term \mbox{\mT{ltk},} representing a long-term
secret key, which is not known to the adversary.
%
The fact \mbox{\mT{Out(<$A, pk(~ltk)>)}} sends the identity of the party
owning the long-term key and the corresponding public key to the adversary.
%
The event \mT{UniqLTK} together with a corresponding restriction models the fact
that the each party is associated with exactly one long-term key.
%
Consequently, an adversary cannot register additional long-term keys for an
identity.
%
% or pair of agents, as enforced by the following restriction:
% \begin{lstlisting}
% restriction uniqLTKs:
%     "All id k1 k2 #i #j. (UniqLTK(id, k1)@i & UniqLTK(id, k2)@j) ==> k1 = k2"
% \end{lstlisting}
In line with the \mEdhoc{} \mSpec{}, this models an external mechanism
ensuring that long term keys are bound to correct identities, e.g., as
managed by a certificate authority.
%

We rely on \mTamarin's{} built-in message deduction rules for a Dolev-Yao adversary.
%
To model an adversary compromising long-term keys, i.e., events of type
\mRevLTK{}, and revealing ephemeral DH half-keys, i.e., events of type
\mRevEph{}, we use standard reveal rules.
%
% \begin{lstlisting}
% rule revealLTK_SIG:
%     [!LTK_SIG($A, ~ltk)] --[LTKRev($A)]-> [Out(~ltk)]
% rule revealLTK_STAT:
%     [!LTK_STAT($A, ~ltk)] --[LTKRev($A)]-> [Out(~ltk)]
% rule revealEphKey:
%     [CompletedRevEph(~tid, u, v, sk, ~eph)] --[EphKeyRev(sk)]-> [Out(~eph)]
% \end{lstlisting}
%rule forge_SIG: [!LTK_SIG($A, ~ltk), In(xx)] --[TEE($A)]-> [Out(sign(xx, ~ltk))]
%rule exp_STAT: [!LTK_STAT($A, ~ltk), In('g'^x)] --[TEE($A)]-> [Out(('g'^x)^~ltk)]
%
The timing of these reveals as modelled by these events is important.
%
The long-term keys can be revealed on registration, before protocol execution.
%
The ephemeral DH half-key of a party can be revealed when the party completes,
i.e., at events of type \mIComplete{} and \mRComplete.~\footnote{A stronger, and perhaps more realistic, model would reveal ephemeral keys upon
creation at the start of the run, but we failed to get \mTamarin{} to
terminate on this.}\\
%
% \knote{Most state-of-the-art Tamarin models of real-world protocols
%         (involving DH) do not
%         reveal the actual session key used for the secure channel, e.g., Cremers
%         et~al.~\cite{DBLP:conf/ccs/CremersFKN20}, Girol
%         et~al.~\cite{DBLP:conf/uss/GirolHSJCB20}. Similarly to us, they instead
%         only leak the session state (only ephemeral keys in out case).  We had
%         serious problems getting Tamarin to terminate if leaking actual session
%         key. Is this a common problem in Tamarin?  "All" computational models
%         have session key reveal queries. CK and eCK have session state (eph-key)
%         reveal queries as well.
%     }
%These rules allow to check Perfect Forward Secrecy, Key Compromise Impersonation
%and (weak) Post Compromise Security as defined in Section~\ref{sec:desired-properties},
%by giving the attacker the ability to access to long term and session keys, or
%to the cryptographic interface, at the appropriate time.

%\subsubsection{Modeling Choices}
\runhead{Protocol Roles}
We model each method of the protocol with four rules: \mT{I1}, \mT{R2}, \mT{I3}
and \mT{R4} (with the method suffixed to the rule name).
%
Each of these represent one step of the protocol as run by the initiator $I$
and the responder $R$.
%
The rules correspond to the event types \mIStart, \mRStart, \mIComplete,  and
\mRComplete, respectively.%, and they can be traced back to the diagrams of
%Figure~\ref{fig:edhocsigstat} and the more general
%Figure~\ref{fig:edhocFramework}.
%
Facts prefixed with \mT{StI} carry state information between \mT{I1} and \mT{I3}.
%
A term unique to the current thread, \mT{tid}, links two rules to a given state fact.
%
Similarly, facts prefixed with \mT{StR} carry state information between the
responder role's rules.
%
Lines 27--28 in the \mT{R2_STAT_SIG} rule shown below illustrate one such use of state
facts.
%

%Our model differs slightly from the \mSpec{}.
%%
%In particular, for convenience we divide the \mMethod{} element into two
%elements, representing the method for the initiator and the responder without
%reducing the attacker potential.
%
We do not model the error message that $R$ can send in response to message
\mMsgone, and hence our model does not
capture the possibility for $R$ to reject $I$'s offer.
%

%We model the XOR encryption of \mT{CIPHERTEXT_2} with the key \mT{K_2e} as to
%allow recovering of part of the key for known plaintext.
%
%Hence \mT{CIPHERTEXT_2} is not a direct XOR ``encryption'' in the model, but
%rather a tuple where each field is XORed with a half-key expansion (\mT{K_2e_1}
%and \mT{K_2e_2}).
We model the XOR encryption of \mT{CIPHERTEXT_2} with the key \mT{K_2e} using
\mTamarin{}'s built in theory for XOR, and allow each term of the encrypted
element to be attacked individually.
%
That is, we first expand \mT{K_2e} to as many key-stream terms as there are
terms in the plaintext tuple using the \mHkdfExpand{} function in a counter-mode
of operation as defined by \mEdhoc{}.
%
We then XOR each term in the plaintext with its own key-stream term.
%
This models the \mSpec{} closer than if we would have XORed \mT{K_2e}, as a
single term, onto the plaintext tuple.
%
The XOR encryption can be seen in lines 18--21 in the listing of
\mT{R2_STAT_SIG} below.
%
%In the latest version of the \mEdhoc{}
%specification~\cite{latest-ietf-lake-edhoc-03}, the XOR-based encryption
%has been changed into using the encryption algorithm from the AEAD algorithm
%from \mSuites{}.
%
\begin{lstlisting}
rule R2_STAT_SIG:
  let
     agreed = <CS0, CI, ~CR> // Agreed data (and exp_sk)
     gx = 'g'^xx
     data_2 = <'g'^~yy, CI, ~CR>
     m1 = <'STAT', 'SIG', CS0, CI, gx>
     TH_2 = h(<$H0, m1, data_2>)
     prk_2e = extr('e', gx^~yy)
     prk_3e2m = prk_2e
     K_2m = expa(<$cAEAD0, TH_2, 'K_2m'>, prk_3e2m)
     protected2 = $V // ID_CRED_V
     CRED_V = pkV
     extAad2 = <TH_2, CRED_V>
     assocData2 = <protected2, extAad2>
     MAC_2 = aead('e', K_2m, assocData2, $cAEAD0)
     authV = sign(<assocData2, MAC_2>, ~ltk)
     plainText2 = <$V, authV>
     K_2e = expa(<$cAEAD0, TH_2, 'K_2e'>, prk_2e)
     K_2e_1 = expa(<$cAEAD0, TH_2, 'K_2e', '1'>, prk_2e)
     K_2e_2 = expa(<$cAEAD0, TH_2, 'K_2e', '2'>, prk_2e)
     CIPHERTEXT_2 = <$V XOR K_2e_1, authV XOR K_2e_2>
     m2 = <data_2, CIPHERTEXT_2>
     exp_sk = <gx^~yy>
  in
     [!LTK_SIG($V, ~ltk), !PK_SIG($V, pkV), In(m1), Fr(~CR), Fr(~yy), Fr(~tid)]
     --[ExpRunningR(~tid, $V, exp_sk, agreed), R2(~tid, $V, m1, m2)]->
     [StR2_STAT_SIG($V, ~ltk, ~yy, prk_3e2m, TH_2, CIPHERTEXT_2,
                    gx^~yy, ~tid, m1, m2, agreed),
      Out(m2)]
\end{lstlisting}
%

To implement events and
to bind them to parameters, we use several \mTamarin{} actions.
%
For example, the action \mT{ExpRunningR(~tid, \$V, exp_sk, agreed)} in line 26
above implements binding an event of type \mRStart{} to the parameters and session key
material.% for the purpose of injective agreement.
%

As explained in Section~\ref{sec:agreedParams}, it is not possible to show
injective agreement on session key material when it includes \mGiy.
%
Therefore, we use certain actions to implement events that include \mGiy{} in the
session key material and other actions that do not.
%
Session key material which includes (resp. does not include) \mGiy{} is referred to as \mT{imp_sk} (resp. \mT{exp_sk}) in the
\mTamarin{} model. %and the material that does not is referred to as \mT{exp_sk}.
%
In the case of \mSigSig, \mSigStat, and \mPskPsk, therefore, \mT{imp_sk} is the same as \mT{exp_sk}.%, because there is no \mGiy.%{} to take into account.
%

%We model the session key material differently for implicit authentication and
%explicit authentication.
%%
%Specifically, when the initiator uses the \mStat{} authentication method,
%\mT{impSk} includes the semi-static key \mGiy{}, whereas \mT{expSk} does not
%include it.
%%
%The reason for this is that, when sending the second message \mMsgtwo{}, the
%responder does not yet know the identity of the initiator and hence cannot
%indicate knowledge of \mGiy{} to the initiator.
%%
%Because we want to verify strong properties such as explicit authentication
%when possible, we collect those items in the key material referred to as
%\mT{exp_k}.
%%
%When not possible we prove weaker properties for \mT{impSk}, which excludes
%key material which it is even theoretically impossible to get explicit
%authentication on.
%%

%What happens after a run of \mEdhoc{} completes is beyond the scope of our study, hence
%we have left this part out of the modeling and focus on the key material
%that forms the basis for the \mOscore{} security context.
%%

%-------------------------------------------------------------------------- sub
\subsection{Property Formalization}
\label{sec:propertyFormalization}
The properties we defined above translate directly into \mTamarin's logic,
using the straightforward mapping of events to the actions emitted from the model.
%
As an example, we show the lemma for verifying the property \mPredPfs.
%
\begin{lstlisting}
lemma secrecyPFS:
   all-traces
   "All u v sk #t3 #t2. (K(sk)@t3 & CompletedRun(u, v, sk)@t2) ==>
       ( (Ex #t1. LTKRev(u)@t1 & #t1 < #t2)
          | (Ex #t1. LTKRev(v)@t1 & #t1 < #t2)
          | (Ex #t1. EphKeyRev(sk)@t1))"
\end{lstlisting}
%
As mentioned earlier, the action \mT{CompletedRun(u, v, sk)} in line 3 is
emitted by both the rules \mT{I3} and \mT{R4}, and corresponds
to the disjunction of events $\mIComplete^{t_2} \lor \mRComplete^{t_2}$ in the
definition of \mPredPfs{} in Section~\ref{sec:secrecy}.
%
Similarly, \mT{EphKeyRev(sk)} in line 6 models that the ephemeral
DH half-key is revealed for either $I$ or $R$, or both.
%

%In this section we present our formalization of the security properties. %into\\
%%\mTamarin{} lemmas.
%%
%We refer to Section~\ref{sec:desired-properties} for a full explanation of the
%properties.
%\\

%\runhead{Explicit Authentication}
%We model explicit authentication between the initiator and the
%responder in the form of mutual injective agreement on the session key material,
%and on the roles and identities of the two parties.
%%
%We split the property into two lemmas, one for authenticating the responder to the
%initiator, and one for the other direction.
%%
%For the first case, we use the action facts \mT{ExpCommitI} and
%\mT{ExpRunningR}, and show that there is injective agreement
%between the two action facts on the parameters identities \mT{U} and \mT{V},
%their respective roles,  and the session key material \mT{expSk}.
%%
%The key material differs between \mEdhoc{} methods.
%%

%Additionally, we require that injective agreement must hold only when
%no long-term key material for the two parties has been revealed before
%the initiator completes the protocol run.
%%
%This is covered by the main disjunction in lines 10-12 on the right of
%the implication.
%%
%That is, either we have injective agreement or one of
%the three \mT{LtkRev} action facts must have been generated.
%%

%lemma authInjAgreeGuaranteeForI:
%    all-traces
%    "All tidI u v expSk #i.
%         (ExpCommitI(tidI, u, v, expSk)@i
%	     & (All #j m1. I1(tidI, u, v, m1) @ j ==> (All #k. TEE(u)@k ==> k < j) & (All #k. TEE(v)@k ==> k < j))
%         & (All tidR #j m1 m2. R2(tidR, v, m1, m2) @ j ==> (All #k. TEE(u)@k ==> k < j) & (All #k. TEE(v)@k ==> k < j)))
%          ==>
%         ( ( (Ex tidR #j. ExpRunningR(tidR, v, expSk)@j & #j < #i)
%           & not(Ex tidI2 u2 v2 #i2. ExpCommitI(tidI2, u2, v2, expSk)@i2 & not(#i = #i2) ) )
%         | (Ex #j. LTKRev(v)@j & #j < #i) )"

% Code from July 22 commit
%\begin{lstlisting}
%lemma authInjAgreeGuaranteeForI:
%     all-traces
%     "All tidI u v expSk #i.
%          ExpCommitI(tidI, u, v, expSk)@i ==>
%          ( ( (Ex tidR #j. ExpRunningR(tidR, v, expSk)@j & #j < #i)
%            & not( Ex tidI2 u2 v2 #i2. ExpCommitI(tidI2, u2, v2, expSk)@i2
%                 & not(#i = #i2)
%                 )
%            )
%          | (Ex #j. LTKRev(<u, v>)@j & #j < #i)
%          | (Ex #j. LTKRev(u)@j & #j < #i)
%          | (Ex #j. LTKRev(v)@j & #j < #i)
%          )
%     "
%\end{lstlisting}

%Note that this property \emph{does not hold} when the initiator is
%running the \mStat{} method, because the key material would then cover \mGiy{},
%and as discussed above that is not possible.
%%
%For that case we need to prove implicit authentication, as detailed in
%the next section.

%Similarly to the previous lemma, we require that injective agreement also holds
%in the reverse direction:
%%
%%\begin{lstlisting}
%%lemma authInjAgreeGuaranteeForR:
%%    all-traces
%%    "All tidR u v sk #i.
%%         (CommitR(tidR, u, v, sk)@i
%%	     & (All tidI #j m1. I1(tidI, u, v, m1) @ j ==> (All #k. TEE(u)@k ==> k < j) & (All #k. TEE(v)@k ==> k < j))
%%         & (All #j m1 m2. R2(tidR, v, m1, m2) @ j ==> (All #k. TEE(u)@k ==> k < j) & (All #k. TEE(v)@k ==> k < j)) )
%%         ==>
%%         ( ( (Ex tidI #j. ExpRunningI(tidI, u, v, sk)@j & #j < #i)
%%           & not(Ex tidR2 u2 v2 #i2. ExpCommitR(tidR2, u2, v2, sk)@i2 & not(#i = #i2)) )
%%         | (Ex #j. LTKRev(u)@j & #j < #i) )"
%%\end{lstlisting}

%% From commit on June 22
%\begin{lstlisting}
%lemma authInjAgreeGuaranteeForR:
%    all-traces
%    "All tidR u v sk #i.
%         CommitR(tidR, u, v, sk)@i ==>
%         ( ( (Ex tidI #j. RunningI(tidI, u, v, sk)@j & #j < #i)
%           & not( Ex tidR2 u2 v2 #i2. CommitR(tidR2, u2, v2, sk)@i2
%                & not(#i = #i2)
%                )
%           )
%         | (Ex #j. LTKRev(<u, v>)@j & #j < #i)
%         | (Ex #j. LTKRev(u)@j & #j < #i)
%         | (Ex #j. LTKRev(v)@j & #j < #i)
%         )
%    "
%\end{lstlisting}
%%
%The initiator is the first to complete the protocol run and confirms that
%it knows both parties identities, their roles (based on message types) and the
%session key in the third message.
%%
%In particular, the initiator knows the responder's identity, so even if the
%responder uses the \mStat{} authentication, the knowledge asymmetry that caused
%problems for injective agreement on \mGiy{} does not occur for \mGrx{}.
%%
%Therefore, the responder gets injective agreement guarantees, and hence explicit
%authentication guarantees, for the entire session key material.
%%
%Consequently, we do not need to differentiate the explicit session key from the
%implicit session key in this case and can ignore the \mT{Exp} prefix for the
%running and commit action facts (\mT{RunningI} and \mT{CommitR} respectively).
%%
%\\

%%\subsubsection{Implicit Authentication}
%\runhead{Implicit Authentication}
%The following lemma proves implicit authentication:
%% \begin{lstlisting}
%% lemma authGIYImplicitAuthGuaranteeForI:
%%     all-traces
%%     "All tidI u v impSk #i.
%%          CommitI(tidI, u, v, impSk)@i ==>
%%          ( ( (All tidR u2 v2 #j. CommitR(tidR, u2, v2, impSk)@j ==>
%%                 (u = u2  &  v = v2)
%%              )
%%            &
%%              (not Ex #k. K(impSk)@k)
%%            &
%%              (not( Ex tidR u v #j tidR2 u2 v2 #j2.
%%                       ( CommitR(tidR,  u,  v,  impSk)@j
%%                       & CommitR(tidR2, u2, v2, impSk)@j2
%%                       & not(#j = #j2)
%%                       )
%%                  )
%%              )
%%            )
%%          | (Ex #k. LTKRev(u)@k) | (Ex #k. TEE(u)@k)
%%          | (Ex #k. LTKRev(v)@k) | (Ex #k. TEE(v)@k)
%%          )
%%          "
%% \end{lstlisting}

%\begin{lstlisting}
%lemma authGIYImplicitAuthGuaranteeForI:
%    all-traces
%    "All tidI u v impSk #i.
%         CommitI(tidI, u, v, impSk)@i ==>
%         ( ( (All tidR u2 v2 #j. CommitR(tidR, u2, v2, impSk)@j ==>
%                (u = u2  &  v = v2)
%             )
%           &
%             (not Ex #k. K(impSk)@k)
%           &
%             (not( Ex tidR u v #j tidR2 u2 v2 #j2.
%                      ( CommitR(tidR,  u,  v,  impSk)@j
%                      & CommitR(tidR2, u2, v2, impSk)@j2
%                      & not(#j = #j2)
%                      )
%                 )
%             )
%           )
%         | (Ex #k. LTKRev(u)@k)
%         | (Ex #k. LTKRev(v)@k)
%         | (Ex #k. LTKRev(<u, v>)@k)
%         )
%    "
%\end{lstlisting}
%As opposed to lemma \mT{authInjAgreeGuaranteeForI}, here we prove that the two
%parties implicitly authenticate on the key \mT{impSk}.
%%
%In this lemma we show that if any two parties (\mT{u} and \mT{v2} here)
%have completed a run of the protocol, and \mT{u} believes she is talking to
% \mT{v} and \mT{v2} believes he is talking to \mT{u2}, then their beliefs
%match, i.e., \mT{u} = \mT{u2} and \mT{v} = \mT{v2}).
%%
%Furthermore there is an injective correspondence
%between the \mT{CommitI} and \mT{CommitR} events, and the attacker does not
%learn the session key material.
%%
%\\

%%\subsubsection{Secrecy, Forward Secrecy and Session Key Independence}
%\runhead{Secrecy, Forward Secrecy and Session Key Independence}
%Finally, we prove secrecy of session key material, perfect forward secrecy
%(PFS) and session key material independence.
%%
%All these properties are verified by proving the same lemma for each method,
%as secrecy is a strictly weaker property than PFS (and hence follows
%directly), and session key independence can be proven along PFS.
%%
%This is done by allowing the attacker to reveal long-term keys after either
%the initiator or the responder have completed the protocol, and by
%allowing the attacker to reveal session key material.
%%
%Despite these additional attacker capabilities, it still holds that the session
%key material is secret for all the other runs of the protocol.
%%
%The lemma is as follows:
%\begin{lstlisting}
%lemma secrecyPFSGIYSessionKey:
%	all-traces
%    "(All tid u v sk #i #j. (K(sk)@i & CommitI(tid, u, v, sk)@j) ==>
%            ((Ex #l. LTKRev(u)@l & #l < #j) | (Ex #l. LTKRev(v)@l & #l < #j) | (Ex #l. SKRev(sk)@l))
%         )
%         &
%         (All tid u v sk #i #j. (K(sk)@i & CommitR(tid, u, v, sk)@j) ==>
%            ((Ex #l. LTKRev(u)@l & #l < #j) | (Ex #l. LTKRev(v)@l & #l < #j) | (Ex #l. SKRev(sk)@l))
%     )
%    "
%\end{lstlisting}
%% We present the lemma for the \mSigStat{} method:
%% \begin{lstlisting}
%%   lemma secrecyPFSGIYSessionKey:
%%         all-traces
%%         "(All tid u v sk #i #j. (K(sk)@i & CommitI(tid, u, v, sk)@j) ==>
%%             ((Ex #l. LTKRev(u)@l & #l < #j) | (Ex #l. LTKRev(v)@l & #l < #j) | (Ex #l. SKRev(sk)@l) | (Ex w #l. TEE(w)@l))
%%          )
%%          &
%%          (All tid u v sk #i #j. (K(sk)@i & CommitR(tid, u, v, sk)@j) ==>
%%             ((Ex #l. LTKRev(u)@l & #l < #j) | (Ex #l. LTKRev(v)@l & #l < #j) | (Ex #l. SKRev(sk)@l) | (Ex w #l. TEE(w)@l))
%%             )"
%% \end{lstlisting}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "main"
%%% End:


\section{Approach}
	In this section we will present our aproach to tackle the speaker recognition problem.
	There're two steps in a complete speaker recognition system: enrollment and recognition.

\subsection{Erollment}
	\label{sec:approach_enrollment}
	An utterance of a user is collected during enrollment procedure.
	Further processing of the utterance follows following steps:
	\begin{enumerate}
		\item \textbf{VAD} \\
            Signals must be first filtered to rule out the silence part, otherwise the
            training might be seriously biased. Therefore \textbf{Voice Activity Detection} must
            be first performed.
			An observation found is that, the corpus provided is nearly noise-free.
            Therefore we use a simple energy-based approach
			to remove the silence part, by simply remove the frames that the average
            energy is below 0.01 times the average energy of the whole utterance.

            This energy-based method is found to work well on database, but not
            on GUI. We use LTSD(Long-Term Spectral Divergence) \cite{ltsd1} algorithm on GUI, as well as
            noise reduction technique from SOX\cite{sox} to gain better result.

		\item \textbf{MFCC and LPC Features} \\ We extract
          \textbf{Mel-frequency cepstral coefficients} and \textbf{Linear Predictive
			Coding} features using following parameter are found to be
			optimal, according to our experiments in \secref{result}:

			\begin{itemize}
				\item Common parameters:
					\begin{itemize}
						\item Frame size: 32ms
						\item Frame shift: 16ms
						\item Preemphasis coefficient: 0.95
					\end{itemize}
				\item MFCC parameters:
					\begin{itemize}
						\item number of cepstral coefficient: 15
						\item number of filter banks: 55
						\item maximal frequency of the filter bank: 6000
					\end{itemize}
				\item LPC Parameters:
					\begin{itemize}
						\item number of coefficient: 23
					\end{itemize}
			\end{itemize}

			and then concatenate the two feature vectors of the same frame forming
			a larger feature vector of 15 + 23 = 38 dimension.

		\item \textbf{GMM}

			We use \textbf{Gaussian Mixture Model} modeling a speaker. Some improvements made:
			\begin{itemize}
				\item Performance: \\
					We investigate the effect of initialization of GMM during
					training. We implemented GMM with
					K-meansII\cite{bahmani2012scalable}, which is an improved
					version of K-means++\cite{arthur2007k} to initialize the
					mean vector of GMM. Results shows improvements compared
					to GMM provided by \textbf{scikit-learn\cite{scikit-learn}}.
				\item Efficiency:
					\begin{itemize}
						\item We provide a parallel version of GMM, especially
							optimized to train large Universal Background Model(UBM).
						\item We further improve efficiency by utilizing
							SSE instruction in computing exponential function
							using polynomial approximation. This can speed up
							the training procedure by a factor of two.
					\end{itemize}
                \end{itemize}

		\item \textbf{UBM}

			As we are providing continuous speech close-set diarization function in
			GUI, we adopt \textbf{Universal Background Model} as imposter model,
			and use likelihood ratio test to make reject
			decisions.\cite{reynolds2000speaker}

			When using conversation mode in GUI (will be present later),
			GMM model of each user is adapted from a pre-trained UBM
			using method described in \cite{reynolds2000speaker}.

		\item \textbf{CRBM}

          \textbf{Restricted Boltzmann Machine} is generative stochastic
		  two-layer neural network (see \figref{rbm}) that can learn a probability distribution
			over its set of binary inputs\cite{rbm_wiki}.  \textbf{Continuous
			restricted Boltzmann Machine(CRBM)}\cite{chen2003continuous} extends
			its ability to real-valued inputs.  RBM has a ability to, given an
			input(visible layer), reconstruct a visible layer that is similar
			to the input.  \figref{crbm} illustrate original MFCC data and the
			sampled output of reconstructed data from CRBM.

			Previous working using neural network largely focused on speech
			recognition, such as \cite{deep} \cite{mohamed20111deep}, only a
			few (\cite{}) on classification task.

			\begin{figure}[!ht]
				\begin{minipage}{0.48\linewidth}
					\centering
					\includegraphics[width=\linewidth]{img/all.trimed.png}
					\caption{The first three dimension of a woman's MFCC feature}
				\end{minipage}
				\hfill
				\begin{minipage}{0.48\linewidth}
					\centering
					\includegraphics[width=\linewidth]{img/50.trimed.png}
					\caption{The first three dimension of the same woman's MFCC feature
					recontructed by a CRBM with 50-neuron hidden layer. We can
					see that, the density of these two distributions are alike}
				\end{minipage}
                \caption{\label{fig:crbm}}
			\end{figure}

			Here use CRBM as a substitution of GMM, rather than
			an feature extractor. We train a CRBM per speaker,
			and estimate reconstruction error without sampling (which is stable).
			The person corresponds to the lowest reconstruction error CRBM is adopted as
			recognition result.

		\item \textbf{JFA}:

          \textbf{Joint Factor Analysis} \cite{jfa2,jfa-se} was generally considered to perform better than other method
          in the task of Speaker Recognition, by modeling different types of variabilities in the training data, including session variability and
          speaker variability.

          Therefore, we use a simpler algorithm presented in \cite{jfa-study} to train the JFA model.
          However, the result shows that JFA does not seem to outperform GMM.
          We suspected that the training of a JFA model needs more data than
          we provided, since JFA needs data from various source to account for different types of variabilities.
          To get a higher accuracy in JFA, We might need to add extra data for training.
	\end{enumerate}

\subsection{Recognition}
	Recognition procedure follows steps below:
	\begin{enumerate}
		\item Record a short utterance of the speaker (typically less than 5 seconds)

		\item Preprocess the utterance using first two steps described in
			\secref{approach_enrollment}, e.g, VAD, MFCC and LPC feature extraction.

		\item Compute the `score' of each person enrolled, and adopt person
			corresponding the model which gives highest score to be the
			recognition result.

			A typical form of score is log-likelihood (or energy in RBM case).
	\end{enumerate}


% -*- mode: latex; tab-width: 2; indent-tabs-mode: nil; -*-
%------------------------------------------------------------------------------
% MRISC32 ISA Manual - Floating-point module.
%
% This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
% International License. To view a copy of this license, visit
% http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to
% Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
%------------------------------------------------------------------------------

\chapter{Floating-point module (FM)}
\label{module:FM}

The Floating-point module adds instructions that operate on floating-point
numbers. Both scalar registers and vector registers may be used to hold
floating-point values.

The module supports a subset of the 2008 IEEE-754 floating-point
standard~\cite{ieee754-2008}.

\tbd