216 lines
16 KiB
TeX
216 lines
16 KiB
TeX
In this section we discuss the details behind the design, formal guarantees, implementation, and usage of \korg.
|
|
|
|
\subsection{High-level design}%
|
|
\label{sub:High-level design}
|
|
|
|
At the highest level, \korg sits on user-specified communication channels in a program written in \promela, the modeling language of the \spin model checker. The user selects an attacker model of choice and correctness properties of choice. \korg then invokes \spin, which exhaustively searches for attacks with respect to the chosen attacker model, \promela model, and correctness property.
|
|
A high-level overview of the \korg pipeline is given in the Figure \ref{fig:korg_workflow}.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=0.5\textwidth]{assets/diagram3.png}
|
|
\caption{A high-level overview of the \korg workflow}
|
|
\label{fig:korg_workflow}
|
|
\end{figure}
|
|
|
|
\subsection{Supported Attacker Models}%
|
|
\label{sub:Supported Attacker Models}
|
|
|
|
\korg supports the automatic synthesis of attacks with respect to four general pre-defined attacker models applicable to any communication channel:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Drop Attacker Model}. Drop attackers are capable of dropping a finite number of messages off a channel.
|
|
\item \textbf{Replay Attacker Model}. Replay attackers are capable of replaying previously seen messages back onto a channel.
|
|
\item \textbf{Reorder Attacker Model}. Reorder attackers are capable of reordering messages on a channel.
|
|
\item \textbf{Insert Attacker Model}. Insert attackers are capable of inserting arbitrary messages (as specifiable by the user) onto a channel.
|
|
\end{itemize}
|
|
|
|
These attacker models can be mixed and matched as desired by the \korg user. For example, a user can specify a drop attacker and replay attacker to target channel 1, a reordering attacker to target channel 2, and an insert attacker to target channel 3. If multiple attacker models are declared, \korg will synthesize attacks where the attackers on different channel \textit{coordinate} to construct a unifying attack.
|
|
|
|
\subsection{Soundness And Completeness of Korg}%
|
|
\label{sub:Soundness And Completeness}
|
|
|
|
\newcommand{\comp}{\mid\mid}
|
|
\newcommand{\ioint}{\mathcal{C}}
|
|
|
|
Fundamentally, the theoretical framework that \korg implements proposed by Hippel et al. reasons about \textit{communicating processes}; similarly, \korg is best understood as a synthesizer for attackers that sit \textit{between} communicating processes.
|
|
|
|
The theoretical attack synthesis framework and \korg use slightly different formalisms. Both employ derivations the general \textit{Input/Output (I/O) automata}, state machines whose transitions indicate sending or receiving a message.\footnote{
|
|
A fundamental assumption both \korg and the theoretical attack synthesis framework rely upon is unicast transition relations of I/O automata within this context. That is, if one sending automata has an output transition matching an input transition of two receiving automata, only one input/output transition pair can be composed upon. Model checkers for I/O automata such as \spin will explore both possibilities.
|
|
}
|
|
In particular, the theoretical attack synthesis framework defines their own notion of a \textit{process} and argues their attack synthesis algorithm maintains soundness and completeness guarantees with respect to it, while \korg relies upon \spin's preferred model checking formalism, the B\"uchi Automata. Both utilize linear temporal logic as their specification language of choice.
|
|
|
|
We ultimately seek to conclude \korg maintains the guarantees of the theoretical framework it implements, therefore it is necessary to demonstrate the equivalence of \textit{processes} from the theoretical attack synthesis framework with the B\"uchi Automata. For ease of reading and clarity, we only provide shortened narrations of the arguments here. The detailed, definitions, theorems, and proofs are provided in Appendix Section \ref{sub:korg_proofs}.
|
|
|
|
%\korg is an implementation of the theoretical attack synthesis framework proposed by Hippel et al. This framework enjoys soundness and completeness guarantees for attacks discovered; that is, if there exists an attack, it is discovered, and if an attack is discovered, it is valid. However, the attack synthesis framework proposed by Hippel et al. reasons about an abstracted, theoretical process construct. Therefore, in order to correctly claim \korg is also sound and complete, it is necessary to demonstrate discovering an attack within the theoretical framework reduces to the semantics of \spin, the model checker \korg is built on top of.
|
|
|
|
%There exists a semantic gap between the theoretical attack synthesis framework proposed by Hippel et al., and the semantics of \korg. Therefore, in order to correctly claim \korg maintains the soundness and completeness of the theoretical framework it implements, it suffices to demonstrate finding an attack within the theoretical attack synthesis framework precisely reduces to the semantics of \spin.
|
|
%the model checker \korg is implemented on top of.
|
|
|
|
\begin{theorem}
|
|
A process, as defined in Hippel et al., always directly corresponds to a B\"uchi Automata.
|
|
\end{theorem}
|
|
|
|
In short, a process in the theoretical attack synthesis framework is a Kripke Structure equipped with input and output transitions. That is, when composing two processes, an output transition must be matched to a respective input transition. Processes also include atomic propositions, which the given linear temporal logic specifications are defined over. We invoke and build on the well-known correspondence between Kripke Structures and \ba to show our desired correspondence.
|
|
|
|
\begin{theorem}
|
|
Checking whether there exists an attacker under a given threat model, the R-$\exists$ASP problem as proposed in Hippel et al., is equivalent to B\"uchi Automata language inclusion (which is in turn solved by the \spin model checker).
|
|
\end{theorem}
|
|
|
|
Via the previous theorem, we can translate the threat model processes and the victim processes to \ba and intersect them. B\"uchi Automata intersection corresponds with \ba language inclusion, which is in turn solved by \spin. From this result, we naturally get a complexity-theoretic result for finding an attacker from a given threat model.
|
|
|
|
%\begin{proof}
|
|
%Recalling the definitions from Hippel et al., a \textit{process} is Kripke structure whose transitions are equipped additional input and output operations in the same flavor as a standard I/O automata.\footnote{Modeling processes in this way allows for the simultaneous modeling of message passing while also maintaining the ability to leverage Linear Temporal Logic for specification}
|
|
%Hippel et al. also defines asynchronous composition on processes to match input and output transitions with the same label when constructing the product automata.
|
|
|
|
%Threat models, then, contain a \textit{target process} $P$ that is unmodifiable by an attacker, a set of vulnerable processes $Q_1,\ldots,Q_n$ that are unmodifiable by an attacker, and a Linear Temporal Logic specification $\phi$. Let $\comp$ denote asynchronous composition between processes. For simplicity, let $Q = Q_1 \comp Q_2 \comp \ldots \comp Q_n$.
|
|
%Given this, we initially require $P \comp Q \models \phi$ (that is, $P$ composed with $Q$ satisfies the property $\phi$.)
|
|
|
|
%Now, our attacker synthesis problem becomes checking whether we can find some process $A$ such that $P \comp A \not\models \phi$. Hippel et al. showed finding such an $A$ can be done algorithmically, maintaining soundness and completeness guarantees,
|
|
%given the input and output transition labels of $A$, denoted $\ioint (A)$, is a subset of $\ioint (Q)$. In particular, Hippel et al. describes gadgets dubbed "daisies" which consist of a main state, a recovery state, circular transitions for each input and output label on the main state, and a non-deterministic transition to the recovery state. To construct $A$, $P \comp Daisy(Q) \models \phi$ is checked.
|
|
|
|
%In short, \spin implements model checking by reducing Promela models to a \ba (a $\omega$-regular automata), converting a Linear Temporal Logic property into a \ba, intersecting the two to construct a product automata, and determining if there exists a reachable acceptance cycle \cite{Vardi_Wolper_1986}.
|
|
%We know by Vardi, we can always generate a \ba that accepts the traces of any given Kripke structure \cite{Vardi_Wolper_1986, clarke2000model}. Thus, defining the transition relations in our \ba to match the I/O transition labels in their respective processes, we can convert $P$, $Daisy(Q)$, and $\phi$ to \ba and intersect them with \spin.
|
|
%Then, \spin will soundly and completely search the product automata for acceptance cycles, either finding a counterexample to $\phi$ or proving the absence of such a trace.
|
|
%\end{proof}
|
|
|
|
|
|
\begin{theorem}
|
|
Checking whether there exists an attacker for a given threat model, the R-$\exists$ASP problem as proposed in Hippel et al., is PSPACE-complete.
|
|
\end{theorem}
|
|
|
|
By the previous argument the attack synthesis problem reduces to intersecting multiple \ba (or alternatively \ba language inclusion), which is well-known to be PSPACE-complete \cite{Kozen_1977}.
|
|
Although this result implies \korg has a rough upper bound complexity, in practice due the various implementation-level optimizations of \spin finding attacks on some property is generally fast, but proving their absence via a state-space search can expensive \cite{Clarke_Wang}.
|
|
|
|
Since \korg uses \spin as its underlying model checker, we can effectively conclude \korg is sound and complete.
|
|
|
|
%By the previous argument, the R-$\exists$ASP problem reduces to intersecting multiple \ba, which is well-known to be PSPACE-complete \cite{Kozen_1977}.
|
|
|
|
|
|
\subsection{The Korg Implementation}%
|
|
\label{sub:The Korg Implementation}
|
|
|
|
We implemented \korg on top of the \spin, a popular and robust model checker for reasoning about distributed and concurrent systems. Intuitively, models written in \promela, the modeling language of \spin, are communicating state machines whose messages are passed over defined \textit{channels}. Channels in \promela can either be unbuffered \textit{synchronous} channels, or buffered \textit{asynchronous} channels. \korg generates attacks \textit{with respect} to these defined channels.
|
|
|
|
\begin{lstlisting}[caption={Example \promela model of peers communicating over a channel. \texttt{!} indicates sending a message onto a channel, \texttt{?} indicates receiving a message from a channel.}, label={lst:spin-model}]
|
|
// channel of buffer size 0
|
|
chan msg_channel = [0] of { int }
|
|
|
|
active proctype Peer1() {
|
|
msg_channel ! 1;
|
|
}
|
|
|
|
active proctype Peer2() {
|
|
int received_msg;
|
|
msg_channel ? received_msg;
|
|
}
|
|
\end{lstlisting}
|
|
|
|
\korg is designed to parse user-chosen channels and generate gadgets for sending, receiving, and manipulating messages on them. \korg has built-in gadgets that are designed to emulate various real-world attacker models, as further described in Section \ref{sec:usage_attacker_models}.
|
|
%Additionally, users can explicitly define which messages a generated gadget can send and receive.
|
|
Once one or multiple gadgets are generated, \korg invokes \spin to check if a given property of interest remains satisfied in the presence of the attacker gadgets.
|
|
|
|
\subsection{Usage}%
|
|
\label{sub:Usage}
|
|
|
|
|
|
|
|
To demonstrate the usage of \korg, we'll walk through an example of proving the alternate bit protocol (ABP) is secure with respect to attackers that can replay messages. ABP is a simple communication protocol that provides reliable communication between two peers over an unreliable communication by continually agreeing on a bit value.
|
|
|
|
To use \korg, the user first authors a \promela model and a correctness property in LTL. For example, take the \promela model as shown in Listing \ref{lst:abp}. The sender repeatedly sends its stored bit, \texttt{A\_curr}, to the receiver. The receiver changes its internal bit, \texttt{B\_curr}, and sends an acknowledgement to the sender. When the sender receives the acknowledgement, it will bitflip \texttt{A\_curr} and repeatedly send the updated bit. A natural specification for this protocol, formalized into the LTL property \texttt{eventually\_agrees}, states that if the sender and receiver do not currently agree on a bit, they eventually will be able to reach an agreement.
|
|
|
|
\begin{lstlisting}[caption={Example (simplified) \promela model of the alternating bit protocol.}, label={lst:abp}]
|
|
chan StoR = [2] of { bit };
|
|
chan RtoS = [2] of { bit };
|
|
|
|
bit A_curr = 0, B_curr = 1, rcv_a, rcv_b;
|
|
|
|
active proctype Sender(){
|
|
do
|
|
:: StoR ! A_curr;
|
|
:: RtoS ? rcv_a ->
|
|
if :: rcv_a == A_curr ->
|
|
A_curr = (A_curr + 1) % 2;
|
|
fi
|
|
od
|
|
}
|
|
|
|
active proctype Receiver(){
|
|
do
|
|
:: RtoS ! B_curr;
|
|
:: StoR ? rcv_b ->
|
|
:: rcv_b != B_curr ->
|
|
B_curr = rcv_b;
|
|
fi
|
|
od
|
|
}
|
|
|
|
ltl eventually_agrees {
|
|
(A_curr != B_curr) implies eventually (A_curr == B_curr)
|
|
}
|
|
\end{lstlisting}
|
|
|
|
Next, the user selects a \textit{channel} to generate an attacker on, and an attacker model of choice. For example, we select \texttt{StoR} and \texttt{RtoS} as our channels of choice, \texttt{replay} as our attacker model of choice, and assume the ABP model is in the file \texttt{abp.pml}. Then, we run \korg via command line.
|
|
\begin{lstlisting}[label={lst:korg-shell}]
|
|
$ ./korg --model=abp.pml --attacker=replay --channel=StoR,RtoS --eval
|
|
\end{lstlisting}
|
|
|
|
\korg will then modify the \texttt{abp.pml} file to include the \texttt{replay} attacker gadgets attacking channels \texttt{StoR} and \texttt{RtoS}, and model-check it with \spin. \korg outputs the following text, cut down for readability, indicating an exhaustive search for attacks:
|
|
\begin{lstlisting}
|
|
Full statespace search for:
|
|
never claim + (eventually_agrees)
|
|
|
|
ltl eventually_agree ((A_curr!=B_curr))) implies (eventually ((A_curr==B_curr))
|
|
|
|
Korg's exhaustive search is complete, no attacks found!
|
|
\end{lstlisting}
|
|
If desired, \texttt{--output} can also be specified so the \korg-modified \texttt{abp.pml} can be more closely examined and modified. A full shell-script replicating this example is available in the artifact.
|
|
|
|
\begin{comment}
|
|
% JAKE'S OLD EXAMPLE (TO BE IGNORED)
|
|
Take the following producer-consumer model, as shown in Listing \ref{lst:prod-consume}.
|
|
|
|
\begin{lstlisting}[caption={Example \promela model with four producers and one consumer.}, label={lst:prod-consume}]
|
|
chan msgs = [4] of { bit };
|
|
int count = 0;
|
|
|
|
active [1] proctype Producer() {
|
|
do :: atomic { count++; msgs ! 1; } od
|
|
}
|
|
|
|
active [4] proctype Consumer() {
|
|
do :: atomic { msgs ? 1 -> count--; } od
|
|
}
|
|
|
|
ltl always_positive { always (count >= 0) }
|
|
\end{lstlisting}
|
|
|
|
Next, the user selects a \textit{channel} to generate an attacker on, and an attacker model of choice (see Section \ref{sec:usage_attacker_models} for more details). For example, we select \texttt{msgs} as our channel of choice, \texttt{replay} as our attacker model of choice, and assume the producer-consumer model is in the file \texttt{pc.pml}. Then, we run \korg via command line.
|
|
|
|
\begin{lstlisting}[label={lst:korg-shell}]
|
|
$ ./korg --model=pc.pml --attacker=replay --channel=msgs --eval
|
|
\end{lstlisting}
|
|
\korg will then modify the \texttt{pc.pml} file to include the \texttt{replay} attacker gadget, and model-check it with \spin. Then, \korg will find and output the simple attack trace where a producer message is replayed, causing a consumer to consume an extra time. The (simplified) attack trace is shown below.
|
|
\begin{lstlisting}[label={trace}]
|
|
(Producer) ko.pml:5 Send 1 -> queue 1 (msgs)
|
|
(Atk) ko.pml:22 [Recv] 1 <- queue 1 (msgs)
|
|
(Atk) ko.pml:23 Send 1 -> queue 2 (a_mem)
|
|
(Atk) ko.pml:47 Recv 1 <- queue 2 (a_mem)
|
|
(Atk) ko.pml:47 Send 1 -> queue 1 (msgs)
|
|
(Consumer) ko.pml:9 Recv 1 <- queue 1 (msgs)
|
|
(Consumer) ko.pml:9 Recv 1 <- queue 1 (msgs)
|
|
|
|
spin: _spin_nvr.tmp:3, assertion violated
|
|
spin: text of failed assertion: assert(!(!((count>=0))))
|
|
Never claim moves to line 3 [assert(!(!((count>=0))))]
|
|
\end{lstlisting}
|
|
|
|
Additional examples and usage information are provided in the anonymous repository link: (link)
|
|
|
|
\end{comment}
|
|
|
|
|
|
%the user inputs a \promela model, a correctness property specified in LTL, a channel from the given \promela model, and an attacker model of choice. \korg will then generate an attacker model gadget corresponding to the selected attacker model with respect to the chosen channel. The attacker model gadget is then appended onto the given \promela model and evaluated against the LTL property with \spin. \korg will then either produce an attack trace demonstrating the precise actions the attacker took to violate the LTL property, or demonstrate the absence of an attack via an exhaustive state-space search.
|
|
|
|
% Precise details of how to use the \korg implementation are provided in the anonymous repository: (link)
|