synchronous/korg-paper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

more

Browse Source
This commit is contained in:
Your Name
2025-01-26 15:30:30 -05:00
parent 07dfd06cb4
commit cc322832e2
11 changed files with 2062 additions and 2063 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
sections/case_studies.tex
View File

@@ -23,8 +23,6 @@ For our analysis, we borrow the four LTL properties used in \cite{Pacheco2022},
We evaluated the TCP \promela model against \korg's drop, replay, and reordering attacker models on a single uni-directional communication channel. The resulting breakdown of attacks discovered is shown in Figure \ref{res:tcp-table}.
%Evaluating the canonical TCP model using \korg led us to identify edge-cases in the connection establishment routine that weren't accounted for, leading us to construct a "revised" TCP model accounting for these missing edge cases.
\begin{figure}[h!]
\centering
\label{res:tcp-table}

10
sections/design.tex
View File

@@ -5,7 +5,7 @@ In this section we discuss the details behind the design, formal guarantees, imp
\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.
An LTL model checker 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.
@@ -15,13 +15,13 @@ We use $\mid \mid$ to denote rendezvous composition. That is, if $S = P \mid \mi
\subsection{High-level design}%
\label{sub:High-level design}
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.
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 one or more communication channels.
%The methodology behind the construction of \korg is based on \textit{LTL attack synthesis}.
\korg is designed to attack user-specified communication channels in state machine-based formal models of distributed protocols. To use \korg, the user inputs a formal model of a distributed protocol in the \promela language, the communication channel(s) in the formal model they wish to attack, the desired attacker model, and a formalized correctness property for the formal model. The formal model should satisfy the correctness property in absence of \korg.
\korg is designed to attack user-specified communication channels in state machine-based formal models of distributed protocols. To use \korg, the user inputs a formal model of a distributed protocol in the \promela language, the communication channel(s) in the protocol model they wish to attack, the desired attacker model, and a formalized correctness property for the protocol model. The protocol model should satisfy the correctness property in absence of \korg.
Once \korg is invoked, it will modify the user-inputted \promela model such that it integrates the desired attacker model. Then, \korg passes the updated \promela model to the model checker, which performs the exhaustive search or provides an explicit counterexample.
Once \korg is invoked, it will modify the user-inputted \promela model such that it integrates the desired attacker model. Then, \korg passes the updated \promela model to the model checker which performs the exhaustive search for an attack, returning a trace if such an attack is found.
%programs written in formal models. The user inputs a formal model of choice, their desired communication channels to attack, the attacker model of choice, and the correctness property of choice. \korg then invokes the model checker, which exhaustively searches for attacks with respect to the chosen attacker model, formal protocol model, and the correctness property.
%\promela, the modeling language of the \spin model checker. The user inputs a \promela model,
@@ -30,7 +30,7 @@ A high-level visual overview of the \korg pipeline is given in Figure \ref{fig:k
\begin{figure}[h]
\centering
\includegraphics[width=0.5\textwidth]{assets/diagram-anon.png}
\includegraphics[width=0.5\textwidth]{assets/diagram3.png}
\caption{A high-level overview of the \korg workflow}
\label{fig:korg_workflow}
\end{figure}

8
sections/introduction.tex
View File

@@ -4,15 +4,15 @@ Distributed protocols are the foundation for the modern internet, and therefore
%, Blanchet_Smyth_Cheval_Sylvestre
This myriad of formal methods tooling applicable to secure protocols has enabled reasoning about security-relevant properties involving secrecy, authentication, indistinguishability in addition to concurrency, safety, and liveness. However, no previous formal methods tooling offered an effective solution for rigorously studying an attacker that controls communication channels. That is, how do you reason about an attacker that can arbitrarily drop, reorder, replay, or insert messages onto a communication channel?
To fill this gap, we introduce \korg \footnote{\korg is a fictitious name for our system, for double-blind submission.}, a tool for synthesizing attacks on distributed protocols that implements and extends the theoretical framework proposed in \cite{Hippel2022_anonym}. In particular, \korg targets the communication channels between the protocol endpoints, and synthesizes attacks to violate arbitrary linear temporal logic (LTL) specifications. \korg either synthesizes attack, or proves the absence of such via an exhaustive state-space search. \korg is sound and complete, meaning if there exists an attack \korg will find it, and \korg will never have false positives. \korg supports pre-defined attacker models, including attackers that can replay, reorder, or drop messages on channels, as well as custom user-defined attacker models. Although \korg best lends itself for reasoning about denial of service attacks, it can target any specification expressable in LTL.
To fill this gap, we introduce \korg, a tool for synthesizing attacks on distributed protocols that implements and extends the theoretical framework proposed in \cite{Hippel2022_anonym}. In particular, \korg targets the communication channels between the protocol endpoints, and synthesizes attacks to violate arbitrary linear temporal logic (LTL) specifications. \korg either synthesizes attack, or proves the absence of such via an exhaustive state-space search. \korg is sound and complete, meaning if there exists an attack \korg will find it, and \korg will never have false positives. \korg supports pre-defined attacker models, including attackers that can replay, reorder, or drop messages on channels, as well as custom user-defined attacker models. Although \korg best lends itself for reasoning about denial of service attacks, it can target any specification expressable in LTL.
In this work we take an approach rooted in \textit{formal methods} and \textit{automated reasoning} to construct \korg. In particular, we employ \textit{model checking}, a sub-discipline of formal methods, to decidably and automatically find attacks in protocols or prove the absence of such.
We summarize our contributions:
\begin{itemize}
\item We present \korg, a tool for synthesizing attacks against communication protocols. \korg supports four general attacker model gadgets: an attacker that can drop, replay, reorder, or insert messages on a channel.
\item We provide and overview of \korg and show how it can be used through an example of the ABP protocol.
\item We present two case studies for two well-known protocols TCP and Raft, illustrating the usefulness of \korg.
\item We present \korg, a tool for synthesizing attacks against distributed communication protocols. \korg supports four general attacker models: an attacker that can drop, replay, reorder, or insert messages on a channel.
\item We provide an overview of \korg and demonstrate its usage by walking through applying it to the ABP protocol
\item We present two case studies for two well-known protocols, TCP and Raft, illustrating the usefulness of \korg.
\end{itemize}
We release our code and our models as open source at \url{https://anonymous.4open.science/r/attacksynth-artifact-1B5D}.