attack synthesis
This commit is contained in:
@@ -110,6 +110,6 @@ Dropping AppendEntryResponse messages & no \\
|
||||
\end{figure}
|
||||
In our experiments, we found just one attack on our Raft \promela model, violating election safety in particular. In this scenario, peer A and peer B are candidates for election. Peer A receives three votes, one from itself and two from other peers, and Peer B receives two votes, one from itself and one from another peer. The replay attacker simply replays the vote sent to peer B. Then, both Peer A and Peer B are convinced they won the election and change their state to leader. Following this, leader completeness is also naturally violated.
|
||||
|
||||
To be clear, this is not an attack on the general Raft protocol, but rather an attack on our specific Raft implementation: in this case, the bug \korg exploits involves our Raft model not ensuring votes received are from unique peers\footnote{Naturally, this requires cryptography and therefore is challenging to express in the semantics of \promela.}. In general, the complete Raft protocol has been proven to resist drop and replay attackers \cite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}. In this scenario, \korg demonstrates its ability to discover subtle bugs in protocol logic ; our Raft model satisfies $\phi_1$-$\phi_5$ assuming perfect channels, and \korg allowed us to reason precisely about the effect of imperfect, vulnerable channels.
|
||||
To be clear, this is not an attack on the general Raft protocol, but rather an attack on our specific Raft implementation: in this case, the bug \korg exploits involves our Raft model not ensuring votes received are from unique peers\footnote{Naturally, this requires cryptography and therefore is challenging to express in the semantics of \promela.}. In general, the complete Raft protocol has been proven to resist drop and replay attackers \cite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}. In this scenario, \korg demonstrates its ability to discover subtle bugs in protocol logic; our Raft model satisfies $\phi_1$-$\phi_5$ assuming perfect channels, and \korg allowed us to reason precisely about the effect of imperfect, vulnerable channels.
|
||||
|
||||
% We note our analysis is in no
|
||||
|
||||
@@ -1,12 +1,25 @@
|
||||
%!TEX root = ../main.tex
|
||||
In this section we discuss the details behind the design, formal guarantees, implementation, and usage of \korg.
|
||||
|
||||
\subsection{Mathematical Preliminaries}%
|
||||
\label{sub:Mathematical Preliminaries}
|
||||
Linear Temporal Logic (LTL) is a model logic for reasoning about program executions. In LTL, we say a program $P$ \textit{models} a property $\phi$ (notationally, $P \models \phi$). That is, $\phi$ holds over every execution of $P$. If $\phi$ does not hold over every execution of $P$, we say $P \not\models \phi$. The LTL language is given by predicates over a first-order logic with additional temporal operators: \textit{next}, \textit{always}, \textit{eventually}, and \textit{until}.
|
||||
|
||||
An LTL model is a tool that, given $P$ and $\phi$, can automatically check whether or not $P \models \phi$; in general, LTL is a \textit{decidable} logic, and LTL model checkers will always be able to decide whether $P \models \phi$ given enough time and resources.
|
||||
|
||||
We use $\mid \mid$ to denote rendezvous composition. That is, if $S = P \mid \mid Q$, processes $P$ and $Q$ are composed together into a singular state machine by matching their equivalent transitions.
|
||||
|
||||
\textit{LTL program synthesis} is the problem of, given an LTL specification $\phi$, automatically deriving a program $P$ that satisfies $\phi$ (that is, $P \models \phi$). \textit{LTL attack synthesis} is logically dual to LTL program synthesis. In attack synthesis, the problem is flipped: given a program $P$ and a property $\phi$ such that $P \models \phi$, we ask whether there exists some "attack" $A$ such that $(P \mid \mid A) \not\models \phi$. Fundamentally, \korg is a synthesizer for such an $A$.
|
||||
|
||||
|
||||
\subsection{High-level design}%
|
||||
\label{sub:High-level design}
|
||||
|
||||
\cnr{need introductory paragraph about program synthesis, the main idea}
|
||||
As aforementioned, \korg is based on \textit{LTL attack synthesis}; in particular, \korg synthesizes attacks with respect to \textit{imperfect} channels. That is, \korg is designed to synthesize attacks that involve replaying, dropping, reordering, or inserting messages on a communication channel.
|
||||
|
||||
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.
|
||||
%The methodology behind the construction of \korg is based on \textit{LTL attack synthesis}.
|
||||
|
||||
\korg is designed to target user-specified communication channels in programs written in \promela, the modeling language of the \spin model checker. The user inputs a \promela model, their desired communication channels to attack, the attacker model of choice, and the LTL correctness property 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]
|
||||
|
||||
Reference in New Issue
Block a user