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:
JakeGinesin
2024-11-11 07:03:00 -05:00
parent 3281c6d818
commit b17d5fca21
20 changed files with 960 additions and 707 deletions
Download Patch File Download Diff File Expand all files Collapse all files

905
.latexrun.db
View File

File diff suppressed because it is too large Load Diff

BIN
assets/diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

BIN
assets/diagram2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
assets/diagram3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 56 KiB

9
assets/korg-diagram.csv Normal file
View File

@@ -0,0 +1,9 @@
"Chosen Channel"
"Chosen Attacker Model"
"Promela Model"
"Attack Trace"
"Promela Model"
"Spin Model Checker"
"Korg"
"Correctness Property"
"Exhaustive Search"
1 Chosen Channel
2 Chosen Attacker Model
3 Promela Model
4 Attack Trace
5 Promela Model
6 Spin Model Checker
7 Korg
8 Correctness Property
9 Exhaustive Search

89
main.aux
View File

@@ -1,45 +1,68 @@
\relax
\citation{Lamport_1994,Holzmann_1997,Clarke_Wang}
\citation{Basin_Cremers_Dreier_Sasse_2022,Blanchet_Smyth_Cheval_Sylvestre,Kobeissi_Nicolas_Tiwari,Blanchet_Jacomme,Basin_Linker_Sasse}
\citation{Hippel2022}
\@writefile{toc}{\contentsline {section}{\numberline {I}Introduction}{1}{}\protected@file@percent }
\newlabel{sec:introduction}{{I}{1}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {II}Design Methodology}{1}{}\protected@file@percent }
\newlabel{sec:design}{{II}{1}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-A}}High-level design}{1}{}\protected@file@percent }
\newlabel{sub:High-level design}{{\mbox {II-A}}{1}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-B}}The Korg Implementation}{1}{}\protected@file@percent }
\newlabel{sub:The Korg Implementation}{{\mbox {II-B}}{1}{}{}{}}
\newlabel{lst:spin-model}{{1}{1}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {1}Example \textsc {Promela}\xspace model of peers communicating over a channel}{1}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-C}}Soundness And Completeness of Korg}{1}{}\protected@file@percent }
\newlabel{sub:Soundness And Completeness}{{\mbox {II-C}}{1}{}{}{}}
\citation{Vardi_Wolper_1986}
\citation{Vardi_Wolper_1986,clarke2000model}
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces A high-level overview of the \textsc {Korg}\xspace workflow}}{1}{}\protected@file@percent }
\newlabel{fig:korg_workflow}{{1}{1}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-B}}Soundness And Completeness of Korg}{1}{}\protected@file@percent }
\newlabel{sub:Soundness And Completeness}{{\mbox {II-B}}{1}{}{}{}}
\citation{Kozen_1977}
\bibstyle{IEEEtran}
\bibdata{main}
\bibcite{Vardi_Wolper_1986}{1}
\bibcite{clarke2000model}{2}
\bibcite{Kozen_1977}{3}
\citation{Clarke_Wang}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-C}}The Korg Implementation}{2}{}\protected@file@percent }
\newlabel{sub:The Korg Implementation}{{\mbox {II-C}}{2}{}{}{}}
\newlabel{lst:spin-model}{{1}{2}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {1}Example \textsc {Promela}\xspace model of peers communicating over a channel}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-D}}Usage}{2}{}\protected@file@percent }
\newlabel{sub:Usage}{{\mbox {II-D}}{2}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {III}Attacker Models}{2}{}\protected@file@percent }
\newlabel{sec:usage_attacker_models}{{III}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Custom Attacker Models}{2}{}\protected@file@percent }
\newlabel{sub:Custom Attacker Models}{{\mbox {III-A}}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Dropping Attacker Model}{2}{}\protected@file@percent }
\newlabel{sub:Dropping Attacker}{{\mbox {III-A}}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Replaying Attacker Model}{2}{}\protected@file@percent }
\newlabel{sub:Replay Attacker}{{\mbox {III-B}}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-C}}Rearranging Attacker Model}{2}{}\protected@file@percent }
\newlabel{sub:Rearrange Attacker}{{\mbox {III-C}}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-D}}Dropping Attacker Model}{2}{}\protected@file@percent }
\newlabel{sub:Dropping Attacker}{{\mbox {III-D}}{2}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {IV}Case Studies}{2}{}\protected@file@percent }
\newlabel{sec:case_studies}{{IV}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-A}}SCTP}{2}{}\protected@file@percent }
\newlabel{sub:SCTP}{{\mbox {IV-A}}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-B}}TCP}{2}{}\protected@file@percent }
\newlabel{sub:TCP}{{\mbox {IV-B}}{2}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-C}}DCCP}{2}{}\protected@file@percent }
\newlabel{sub:DCCP}{{\mbox {IV-C}}{2}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {V}Usage}{2}{}\protected@file@percent }
\newlabel{sec:Usage}{{V}{2}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {VI}Conclusion}{2}{}\protected@file@percent }
\newlabel{sec:conclusion}{{VI}{2}{}{}{}}
\@writefile{toc}{\contentsline {section}{References}{2}{}\protected@file@percent }
\gdef \@abspage@last{2}
\bibstyle{IEEEtran}
\bibdata{main}
\bibcite{Lamport_1994}{1}
\bibcite{Holzmann_1997}{2}
\bibcite{Clarke_Wang}{3}
\bibcite{Basin_Cremers_Dreier_Sasse_2022}{4}
\bibcite{Blanchet_Smyth_Cheval_Sylvestre}{5}
\bibcite{Kobeissi_Nicolas_Tiwari}{6}
\bibcite{Blanchet_Jacomme}{7}
\bibcite{Basin_Linker_Sasse}{8}
\bibcite{Hippel2022}{9}
\bibcite{Vardi_Wolper_1986}{10}
\bibcite{clarke2000model}{11}
\bibcite{Kozen_1977}{12}
\newlabel{lst:spin-model}{{2}{3}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {2}Example dropping attacker model gadget}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-C}}Rearranging Attacker Model}{3}{}\protected@file@percent }
\newlabel{sub:Rearrange Attacker}{{\mbox {III-C}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-D}}Custom Attacker Models}{3}{}\protected@file@percent }
\newlabel{sub:Custom Attacker Models}{{\mbox {III-D}}{3}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {IV}Case Studies}{3}{}\protected@file@percent }
\newlabel{sec:case_studies}{{IV}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-A}}SCTP}{3}{}\protected@file@percent }
\newlabel{sub:SCTP}{{\mbox {IV-A}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-B}}TCP}{3}{}\protected@file@percent }
\newlabel{sub:TCP}{{\mbox {IV-B}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-C}}DCCP}{3}{}\protected@file@percent }
\newlabel{sub:DCCP}{{\mbox {IV-C}}{3}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusion}{3}{}\protected@file@percent }
\newlabel{sec:conclusion}{{V}{3}{}{}{}}
\@writefile{toc}{\contentsline {section}{References}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {VI}Appendix}{3}{}\protected@file@percent }
\newlabel{sec:Appendix}{{VI}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-A}}Full Korg Soundness and Completeness Proofs}{3}{}\protected@file@percent }
\newlabel{sub:korg_proofs}{{\mbox {VI-A}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-B}}Preventing Korg Livelocks}{3}{}\protected@file@percent }
\newlabel{sub:Preventing Korg Livelocks}{{\mbox {VI-B}}{3}{}{}{}}
\newlabel{lst:drop_passer}{{3}{4}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {3}Example dropping attacker model gadget with message skipping}{4}{}\protected@file@percent }
\gdef \@abspage@last{4}

47
main.bbl
View File

@@ -1,5 +1,5 @@
% Generated by IEEEtran.bst, version: 1.14 (2015/08/26)
\begin{thebibliography}{1}
\begin{thebibliography}{10}
\providecommand{\url}[1]{#1}
\csname url@samestyle\endcsname
\providecommand{\newblock}{\relax}
@@ -21,6 +21,51 @@
\providecommand{\BIBdecl}{\relax}
\BIBdecl
\bibitem{Lamport_1994}
L.~Lamport, ``\BIBforeignlanguage{en}{The temporal logic of actions},''
\emph{\BIBforeignlanguage{en}{ACM Transactions on Programming Languages and
Systems}}, vol.~16, no.~3, p. 872–923, May 1994.
\bibitem{Holzmann_1997}
G.~Holzmann, ``\BIBforeignlanguage{en}{The model checker spin},''
\emph{\BIBforeignlanguage{en}{IEEE Transactions on Software Engineering}},
vol.~23, no.~5, p. 279–295, May 1997.
\bibitem{Clarke_Wang}
E.~M. Clarke and Q.~Wang, ``\BIBforeignlanguage{en}{25 years of model
checking}.''
\bibitem{Basin_Cremers_Dreier_Sasse_2022}
D.~Basin, C.~Cremers, J.~Dreier, and R.~Sasse,
``\BIBforeignlanguage{en}{Tamarin: Verification of large-scale, real-world,
cryptographic protocols},'' \emph{\BIBforeignlanguage{en}{IEEE Security &
Privacy}}, vol.~20, no.~3, p. 24–32, May 2022.
\bibitem{Blanchet_Smyth_Cheval_Sylvestre}
B.~Blanchet, B.~Smyth, V.~Cheval, and M.~Sylvestre,
``\BIBforeignlanguage{en}{Proverif 2.05: Automatic cryptographic protocol
verifier, user manual and tutorial}.''
\bibitem{Kobeissi_Nicolas_Tiwari}
N.~Kobeissi, G.~Nicolas, and M.~Tiwari, ``\BIBforeignlanguage{en}{Verifpal:
Cryptographic protocol analysis for the real world}.''
\bibitem{Blanchet_Jacomme}
B.~Blanchet and C.~Jacomme, ``\BIBforeignlanguage{en}{Cryptoverif: a
computationally-sound security protocol verifier}.''
\bibitem{Basin_Linker_Sasse}
D.~Basin, F.~Linker, and R.~Sasse, ``\BIBforeignlanguage{en}{A formal analysis
of the imessage pq3 messaging protocol}.''
\bibitem{Hippel2022}
\BIBentryALTinterwordspacing
M.~von Hippel, C.~Vick, S.~Tripakis, and C.~Nita-Rotaru, ``Automated attacker
synthesis for distributed protocols,'' no. arXiv:2004.01220, Apr. 2022,
arXiv:2004.01220 [cs]. [Online]. Available:
\url{http://arxiv.org/abs/2004.01220}
\BIBentrySTDinterwordspacing
\bibitem{Vardi_Wolper_1986}
\BIBentryALTinterwordspacing
M.~Y. Vardi and P.~Wolper, ``\BIBforeignlanguage{English}{An automata-theoretic

16
main.bib
View File

@@ -29,3 +29,19 @@ concurrent finite-state programs.}, publisher={IEEE Computer Society}, author={V
@inproceedings{Kozen_1977, address={Providence, RI, USA}, title={Lower bounds for natural proof systems}, url={http://ieeexplore.ieee.org/document/4567949/}, DOI={10.1109/SFCS.1977.16}, abstractNote={Two decidable logical theories are presented, one complete for deterministic polynomial time, one complete for polynomial space. Both have natural proof systems. A lower space bound of n/log(n) is shown for the proof system for the PTIME complete theory and a lower length bound of 2cn / 1og(n) is shown for the proof system for the PSPACE complete theory.}, booktitle={18th Annual Symposium on Foundations of Computer Science (sfcs 1977)}, publisher={IEEE}, author={Kozen, Dexter}, year={1977}, month=sep, pages={254–266}, language={en} }
@article{Holzmann_1997, title={The model checker SPIN}, volume={23}, rights={https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html}, ISSN={00985589}, DOI={10.1109/32.588521}, abstractNote={SPIN is an efficient verification system for models of distributed software systems. It has been used to detect design errors in applications ranging from high-level descriptions of distributed algorithms to detailed code for controlling telephone exchanges. This paper gives an overview of the design and structure of the verifier, reviews its theoretical foundation, and gives an overview of significant practical applications.}, number={5}, journal={IEEE Transactions on Software Engineering}, author={Holzmann, G.J.}, year={1997}, month=may, pages={279–295}, language={en} }
@article{Lamport_1994, title={The temporal logic of actions}, volume={16}, ISSN={0164-0925, 1558-4593}, DOI={10.1145/177492.177726}, abstractNote={The temporal logic of actions (TLA) is a logic for specifying and reasoning about concurrent systems. Systems and their properties are represented in the same logic, so the assertion that a system meets its specification and the assertion that one system implements another are both expressed by logical implication. TLA is very simple; its syntax and complete formal semantics are summarized in about a page. Yet, TLA is not just a logician’s toy; it is extremely powerful, both in principle and in practice. This report introduces TLA and describes how it is used to specify and verify concurrent algorithms. The use of TLA to specify and reason about open systems will be described elsewhere.}, number={3}, journal={ACM Transactions on Programming Languages and Systems}, author={Lamport, Leslie}, year={1994}, month=may, pages={872–923}, language={en} }
@article{Basin_Cremers_Dreier_Sasse_2022, title={Tamarin: Verification of Large-Scale, Real-World, Cryptographic Protocols}, volume={20}, rights={https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html}, ISSN={1540-7993, 1558-4046}, DOI={10.1109/MSEC.2022.3154689}, abstractNote={Tamarin is a mature, state-of-the-art tool for cryptographic protocol verification. We introduce Tamarin and survey some of the larger, tour-de-force results achieved with it. We also show how Tamarin can formalize a wide range of protocols, adversary models, and properties, and scale to substantial, real-world, verification problems.}, number={3}, journal={IEEE Security & Privacy}, author={Basin, David and Cremers, Cas and Dreier, Jannik and Sasse, Ralf}, year={2022}, month=may, pages={24–32}, language={en} }
@article{Blanchet_Smyth_Cheval_Sylvestre, title={ProVerif 2.05: Automatic Cryptographic Protocol Verifier, User Manual and Tutorial}, author={Blanchet, Bruno and Smyth, Ben and Cheval, Vincent and Sylvestre, Marc}, language={en} }
@article{Kobeissi_Nicolas_Tiwari, title={Verifpal: Cryptographic Protocol Analysis for the Real World}, abstractNote={Verifpal is a new automated modeling framework and verifier for cryptographic protocols, optimized with heuristics for common-case protocol specifications, that aims to work better for real-world practitioners, students and engineers without sacrificing comprehensive formal verification features. In order to achieve this, Verifpal introduces a new, intuitive language for modeling protocols that is easier to write and understand than the languages employed by existing tools. Its formal verification paradigm is also designed explicitly to provide protocol modeling that avoids user error. Verifpal is able to model protocols under an active attacker with unbounded sessions and fresh values, and supports queries for advanced security properties such as forward secrecy or key compromise impersonation. Furthermore, Verifpal’s semantics have been formalized within the Coq theorem prover, and Verifpal models can be automatically translated into Coq as well as into ProVerif models for further verification. Verifpal has already been used to verify security properties for Signal, Scuttlebutt, TLS 1.3 as well as the first formal model for the DP-3T pandemic-tracing protocol, which we present in this work. Through Verifpal, we show that advanced verification with formalized semantics and sound logic can exist without any expense towards the convenience of real-world practitioners.}, author={Kobeissi, Nadim and Nicolas, Georgio and Tiwari, Mukesh}, language={en} }
@article{Blanchet_Jacomme, title={CryptoVerif: a Computationally-Sound Security Protocol Verifier}, abstractNote={This document presents the security protocol verifier CryptoVerif. CryptoVerif does not rely on the symbolic, Dolev-Yao model, but on the computational model. It can verify secrecy, correspondence properties (which include authentication), and indistinguishability properties. It produces proofs presented as sequences of games, like those manually written by cryptographers; these games are formalized in a probabilistic process calculus. CryptoVerif provides a generic method for specifying security properties of the cryptographic primitives. It produces proofs valid for any number of sessions of the protocol, and provides an upper bound on the probability of success of an attack against the protocol as a function of the probability of breaking each primitive and of the number of sessions. CryptoVerif is post-quantum sound: when the used cryptographic assumptions are valid for quantum adversaries, the proofs hold for quantum adversaries. It can work automatically, or the user can guide it with manual proof indications.}, author={Blanchet, Bruno and Jacomme, Charlie}, language={en} }
@article{Clarke_Wang, title={25 Years of Model Checking}, abstractNote={Model Checking is an automatic verification technique for large state transition systems. It was originally developed for reasoning about finite-state concurrent systems. The technique has been used successfully to debug complex computer hardware, communication protocols, and software. It is beginning to be used for analyzing cyberphysical, biological, and financial systems as well. The major challenge for the technique is a phenomenon called the State Explosion Problem. This issue is impossible to avoid in the worst case; but, by using sophisticated data structures and clever search algorithms, it is now possible to verify state transition systems with an astronomical number of states. In this paper, we will briefly review the development of Model Checking over the past 32 years, with an emphasis on model checking stochastic hybrid systems.}, author={Clarke, Edmund M and Wang, Qinsi}, language={en} }
@article{Basin_Linker_Sasse, title={A Formal Analysis of the iMessage PQ3 Messaging Protocol}, abstractNote={We report on the design and verification of a highly performant, device-to-device messaging protocol offering strong security guarantees even against an adversary with quantum computing capabilities, called iMessage PQ3. The protocol leverages Apple’s identity services together with a custom, post-quantum secure initialization phase and afterwards it employs constructs from a double ratchet in the style of Signal, extended to provide post-quantum, post-compromise security. We present a detailed formal model of the protocol, a precise specification of its fine-grained security properties, and machine-checked proofs using the Tamarin prover. Particularly novel are the integration of postquantum secure key encapsulation into the relevant protocol phases and the detailed security claims along with their complete formal analysis, covering both key ratchets, including unbounded loops.}, author={Basin, David and Linker, Felix and Sasse, Ralf}, language={en} }
@article{Clarke_Wang, title={25 Years of Model Checking ?}, abstractNote={Model Checking is an automatic verification technique for large state transition systems. It was originally developed for reasoning about finite-state concurrent systems. The technique has been used successfully to debug complex computer hardware, communication protocols, and software. It is beginning to be used for analyzing cyberphysical, biological, and financial systems as well. The major challenge for the technique is a phenomenon called the State Explosion Problem. This issue is impossible to avoid in the worst case; but, by using sophisticated data structures and clever search algorithms, it is now possible to verify state transition systems with an astronomical number of states. In this paper, we will briefly review the development of Model Checking over the past 32 years, with an emphasis on model checking stochastic hybrid systems.}, author={Clarke, Edmund M and Wang, Qinsi}, language={en} }

77
main.blg
View File

@@ -11,48 +11,59 @@ Database file #1: main.bib
-- IEEEtran.bst version 1.14 (2015/08/26) by Michael Shell.
-- http://www.michaelshell.org/tex/ieeetran/bibtex/
-- See the "IEEEtran_bst_HOWTO.pdf" manual for usage information.
Warning--empty journal in Clarke_Wang
Warning--empty year in Clarke_Wang
Warning--empty journal in Blanchet_Smyth_Cheval_Sylvestre
Warning--empty year in Blanchet_Smyth_Cheval_Sylvestre
Warning--empty journal in Kobeissi_Nicolas_Tiwari
Warning--empty year in Kobeissi_Nicolas_Tiwari
Warning--empty journal in Blanchet_Jacomme
Warning--empty year in Blanchet_Jacomme
Warning--empty journal in Basin_Linker_Sasse
Warning--empty year in Basin_Linker_Sasse
Warning--empty journal in Hippel2022
Warning--empty booktitle in Vardi_Wolper_1986
Done.
You've used 3 entries,
You've used 12 entries,
4087 wiz_defined-function locations,
845 strings with 7814 characters,
and the built_in function-call counts, 1732 in all, are:
= -- 125
> -- 26
< -- 1
+ -- 12
- -- 6
* -- 98
:= -- 279
add.period$ -- 8
call.type$ -- 3
change.case$ -- 2
897 strings with 9252 characters,
and the built_in function-call counts, 6235 in all, are:
= -- 497
> -- 129
< -- 11
+ -- 60
- -- 30
* -- 350
:= -- 993
add.period$ -- 26
call.type$ -- 12
change.case$ -- 12
chr.to.int$ -- 0
cite$ -- 4
duplicate$ -- 140
empty$ -- 179
format.name$ -- 8
if$ -- 390
cite$ -- 24
duplicate$ -- 541
empty$ -- 538
format.name$ -- 39
if$ -- 1408
int.to.chr$ -- 0
int.to.str$ -- 3
missing$ -- 25
newline$ -- 36
num.names$ -- 3
pop$ -- 75
int.to.str$ -- 12
missing$ -- 96
newline$ -- 65
num.names$ -- 12
pop$ -- 257
preamble$ -- 1
purify$ -- 0
quote$ -- 2
skip$ -- 130
skip$ -- 476
stack$ -- 0
substring$ -- 20
swap$ -- 87
text.length$ -- 1
substring$ -- 81
swap$ -- 367
text.length$ -- 11
text.prefix$ -- 0
top$ -- 5
type$ -- 3
warning$ -- 1
while$ -- 4
width$ -- 4
write$ -- 51
(There was 1 warning)
type$ -- 12
warning$ -- 12
while$ -- 16
width$ -- 14
write$ -- 126
(There were 12 warnings)

78
main.fls
View File

@@ -152,13 +152,13 @@ INPUT ./sections/design.tex
INPUT ./sections/design.tex
INPUT ./sections/design.tex
INPUT ./sections/design.tex
INPUT /usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
INPUT /usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
INPUT /usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr7t.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr7t.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmrc7t.tfm
INPUT ./assets/diagram3.png
INPUT ./assets/diagram3.png
INPUT ./assets/diagram3.png
INPUT ./assets/diagram3.png
OUTPUT ./main.pdf
INPUT ./assets/diagram3.png
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmrc7t.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmrc7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
@@ -179,8 +179,6 @@ INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmrc7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmr7t.vf
INPUT /usr/share/texmf-dist/fonts/vf/adobe/courier/pcrr7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmr7t.vf
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmrc7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
@@ -198,55 +196,41 @@ INPUT /usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msbm10.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msbm7.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msbm5.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/cm/cmr8.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/cm/cmr6.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/cm/cmmi8.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/cm/cmmi6.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/cm/cmsy8.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/cmextra/cmex8.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/cmextra/cmex7.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msam10.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msam7.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msbm10.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/public/amsfonts/symbols/msbm7.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr7t.tfm
INPUT /usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
INPUT /usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
INPUT /usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr7t.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr7t.tfm
INPUT ./sections/attacker_models.tex
INPUT ./sections/attacker_models.tex
INPUT ./sections/attacker_models.tex
INPUT ./sections/attacker_models.tex
INPUT ./sections/attacker_models.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/usage.tex
INPUT ./sections/usage.tex
INPUT ./sections/usage.tex
INPUT ./sections/usage.tex
INPUT ./sections/usage.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./main.bbl
INPUT ./main.bbl
INPUT ./main.bbl
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmb7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmb8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmr7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmr7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/courier/pcrr7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr8r.tfm
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./main.bbl
INPUT ./main.bbl
INPUT ./main.bbl
INPUT ./sections/appendix.tex
INPUT ./sections/appendix.tex
INPUT ./sections/appendix.tex
INPUT ./sections/appendix.tex
INPUT ./sections/appendix.tex
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmri7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmri8r.tfm
INPUT ./main.aux
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr7.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb
INPUT /usr/share/texmf-dist/fonts/type1/urw/times/utmb8a.pfb

169
main.log
View File

@@ -1,4 +1,4 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/Arch Linux) (preloaded format=pdflatex 2024.7.2) 28 OCT 2024 14:23
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/Arch Linux) (preloaded format=pdflatex 2024.7.2) 11 NOV 2024 03:48
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@@ -319,23 +319,27 @@ File: lstmisc.sty 2024/02/21 1.10 (Carsten Heinz)
File: l3backend-pdftex.def 2024-02-20 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count294
\l__pdf_internal_box=\box57
) (./main.aux)
) (./main.aux
LaTeX Warning: Label `lst:spin-model' multiply defined.
)
\openout1 = `main.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 47.
LaTeX Font Info: ... okay on input line 47.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 48.
LaTeX Font Info: ... okay on input line 48.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 48.
LaTeX Font Info: ... okay on input line 48.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 48.
LaTeX Font Info: ... okay on input line 48.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 48.
LaTeX Font Info: ... okay on input line 48.
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 48.
LaTeX Font Info: ... okay on input line 48.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 48.
LaTeX Font Info: ... okay on input line 48.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 48.
LaTeX Font Info: ... okay on input line 48.
-- Lines per column: 56 (exact).
(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
@@ -363,25 +367,28 @@ e
\c@lstlisting=\count301
(./sections/abstract.tex) (./sections/introduction.tex) (./sections/design.tex
Underfull \vbox (badness 1584) has occurred while \output is active []
<assets/diagram3.png, id=1, 733.99219pt x 277.035pt>
File: assets/diagram3.png Graphic file (type png)
<use assets/diagram3.png>
Package pdftex.def Info: assets/diagram3.png used on input line 17.
(pdftex.def) Requested size: 258.0pt x 97.37796pt.
LaTeX Font Info: Trying to load font information for OT1+pcr on input line 1
2.
Overfull \hbox (6.0pt too wide) in paragraph at lines 17--18
[][]
[]
(/usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texmf-dist/f
onts/enc/dvips/base/8r.enc}
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texmf-dist/fon
ts/enc/dvips/base/8r.enc}
]
LaTeX Font Info: Trying to load font information for U+msa on input line 41.
<./assets/diagram3.png (PNG copy)>]
LaTeX Font Info: Trying to load font information for U+msa on input line 47.
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
)
LaTeX Font Info: Trying to load font information for U+msb on input line 41.
LaTeX Font Info: Trying to load font information for U+msb on input line 47.
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd
@@ -389,10 +396,66 @@ File: umsb.fd 2013/01/14 v3.01 AMS symbols B
)
LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
(Font) using `OT1/ptm/m/sc' instead on input line 41.
(Font) using `OT1/ptm/m/sc' instead on input line 47.
) (./sections/attacker_models.tex) (./sections/case_studies.tex)
(./sections/usage.tex) (./sections/conclusion.tex) (./main.bbl
LaTeX Font Info: Trying to load font information for OT1+pcr on input line 8
6.
(/usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
)
LaTeX Warning: `h' float specifier changed to `ht'.
) (./sections/attacker_models.tex
LaTeX Warning: `h' float specifier changed to `ht'.
[2]) (./sections/case_studies.tex) (./sections/conclusion.tex) (./main.bbl
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
! Misplaced alignment tab character &.
<argument> IEEE Security &
Privacy
l.42 Privacy}}
, vol.~20, no.~3, p. 24–32, May 2022.
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `English'. Using the pattern for
** the default language instead.
@@ -402,7 +465,12 @@ LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for
** the default language instead.
)
) (./sections/appendix.tex
LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
(Font) using `OT1/ptm/m/sc' instead on input line 15.
[3])
** Conference Paper **
Before submitting the final camera ready copy, remember to:
@@ -414,32 +482,35 @@ Before submitting the final camera ready copy, remember to:
uses only Type 1 fonts and that every step in the generation
process uses the appropriate paper size.
[2] (./main.aux)
[4
] (./main.aux)
***********
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-02-20>
***********
LaTeX Warning: There were multiply-defined labels.
)
Here is how much of TeX's memory you used:
6209 strings out of 476076
92780 string characters out of 5793776
1966187 words of memory out of 5000000
28216 multiletter control sequences out of 15000+600000
603086 words of font info for 118 fonts, out of 8000000 for 9000
6276 strings out of 476076
93712 string characters out of 5793776
2039187 words of memory out of 5000000
28293 multiletter control sequences out of 15000+600000
597323 words of font info for 103 fonts, out of 8000000 for 9000
14 hyphenation exceptions out of 8191
57i,8n,65p,1135b,1169s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/
texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb></usr/share/texmf-dist/font
s/type1/public/amsfonts/cm/cmr10.pfb></usr/share/texmf-dist/fonts/type1/public/
amsfonts/cm/cmr7.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy
10.pfb></usr/share/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/te
xmf-dist/fonts/type1/urw/times/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/ur
w/times/utmbi8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></u
sr/share/texmf-dist/fonts/type1/urw/times/utmri8a.pfb>
Output written on ./main.pdf (2 pages, 124390 bytes).
57i,8n,65p,1155b,1257s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/
texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-dist/fonts/type
1/urw/times/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb
></usr/share/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-dist
/fonts/type1/urw/times/utmri8a.pfb>
Output written on ./main.pdf (4 pages, 157257 bytes).
PDF statistics:
62 PDF objects out of 1000 (max. 8388607)
37 compressed objects within 1 object stream
49 PDF objects out of 1000 (max. 8388607)
29 compressed objects within 1 object stream
0 named destinations out of 1000 (max. 500000)
1 words of extra memory for PDF output out of 10000 (max. 10000000)
6 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
main.pdf
View File

Binary file not shown.

BIN
main.synctex.gz
View File

Binary file not shown.

10
main.tex
View File

@@ -9,6 +9,7 @@
\usepackage{xcolor}
\usepackage{amsmath, amsthm}
\usepackage{xspace}
%\usepackage{csvsimple}
\newcommand{\cnr}[1]{\textcolor{blue}{Cristina says: {#1}}}
\newcommand{\mvh}[1]{\textcolor{magenta}{Max says: {#1}}}
@@ -46,7 +47,7 @@
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
\begin{document}
\title{\korg: A Communication Channel-Based Attack Synthesizer for Distributed Protocols\\
\title{\korg: An Attack Synthesizer for Distributed Protocols\\
}
@@ -87,9 +88,6 @@ Protocols, Attack Synthesis, Denial of Service, Model Checking
\label{sec:case_studies}
\input{sections/case_studies}
\section{Usage}%
\label{sec:Usage}
\input{sections/usage}
\section{Conclusion}
\label{sec:conclusion}
@@ -98,5 +96,9 @@ Protocols, Attack Synthesis, Denial of Service, Model Checking
\bibliographystyle{IEEEtran}
\bibliography{main}
\section{Appendix}%
\label{sec:Appendix}
\input{sections/appendix}
\end{document}

10
notes.md Normal file
View File

@@ -0,0 +1,10 @@
- should write down stuff about the other tools, look at the stuff that cites korg
- soundness before implementation
- design, proofs, implementation
- usage before case studies?
- talk about *why* we make the split between design stuff and like, others
- look at the spin trace! it did this and this and this!
- "supported attacker models" should be go before like, the custom attacker models
- usage and case studies? or usage goes in design?
The asynchronous channel automata

76
sections/appendix.tex Normal file
View File

@@ -0,0 +1,76 @@
\subsection{Full Korg Soundness and Completeness Proofs}%
\label{sub:korg_proofs}
\setcounter{theorem}{0}
\begin{theorem}
A process, as defined in Hippel et al., always directly corresponds to a Büchi automata.
\end{theorem}
\begin{proof}
\jg{highly standard equivalence argument}
\end{proof}
\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}
\begin{proof}
\jg{arguing the equivalence of buchi automata intersection and process composition}
\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}
\begin{proof}
\jg{cite lower bounds for natural proof systems}
\end{proof}
\subsection{Preventing Korg Livelocks}%
\label{sub:Preventing Korg Livelocks}
In general, there are two types of LTL properties: safety, and liveness. Informally, safety properties state "a bad thing never happens," and liveness properties state "a good thing always happens."
Therefore, safety properties can be violated by finite traces, while liveness properties require infinite traces to be violated.
When evaluating a \korg attacker model gadget against a \promela model and a liveness property, it is crucial to ensure the gadget has no cyclic behavior. If a \korg gadget has cyclic behavior in any way, it'll trivially violate the liveness
property and produce a garbage attack trace. To prevent this, we make the following considerations.
First, we design our \korg gadgets such that they never arbitrarily send and consume messages to a single channel. Second, we allow \korg gadgets,
which are always processing messages on channels, to arbitrarily "skip" messages on a channel if need be. To demonstrate the latter, consider the extension of the drop attacker model gadget in Figure \ref{lst:drop_passer}. We implement message skipping by arbitrarily stopping and waiting after observing a message on a channel; once the channel is observed changing lengths, the message is considered skipped and future messages can be consumed.
\begin{figure}[h]
\begin{lstlisting}[caption={Example dropping attacker model gadget with message skipping}, label={lst:drop_passer}]
chan cn = [8] of { int, int, int };
active proctype attacker_drop() {
int b_0, b_1, b_2, blocker;
byte lim = 3; // drop limit
MAIN:
do
:: cn ? [b_0, b_1, b_2] -> atomic {
if
:: lim == 0 -> goto BREAK;
:: else ->
cn ? b_0, b_1, b_2; // consume message on the channel
lim = lim - 1;
goto MAIN;
fi
}
// pass over a message on a channel as needed
:: cn ? [b_0, b_1, b_2] -> atomic {
// wait for the channel to change lengths
// then, once it does, go to MAIN
blocker = len(cn);
do
:: blocker != len(cn) -> goto MAIN;
od
}
:: goto BREAK;
od
BREAK:
}
\end{lstlisting}
\end{figure}

50
sections/attacker_models.tex
View File

@@ -1,14 +1,44 @@
In this section we discuss the various details for each attacker model built into \korg.
\subsection{Custom Attacker Models}%
\label{sub:Custom Attacker Models}
\subsection{Replaying Attacker Model}%
\label{sub:Replay Attacker}
\subsection{Rearranging Attacker Model}%
\label{sub:Rearrange Attacker}
\korg supports three general attacker models: an attacker that can drop, replay, or rearrange messages on a channel. Additionally, \korg supports user-defined attacker that insert arbitrary messages onto a channel. In this section we discuss the various details that go into each attacker model.
\subsection{Dropping Attacker Model}%
\label{sub:Dropping Attacker}
The first and most simple general attacker model \korg supports is an attacker that can \textit{drop} messages from a channel. The user specifies a "drop limit" value that limits the number of packets the attacker can drop from the channel. Note, a higher drop limit will increase the search space of possible attacks, thereby increasing execution time.
\begin{figure}[h]
\begin{lstlisting}[caption={Example dropping attacker model gadget}, label={lst:spin-model}]
chan cn = [8] of { int, int, int };
active proctype attacker_drop() {
int b_0, b_1, b_2;
byte lim = 3; // drop limit
MAIN:
do
:: cn ? [b_0, b_1, b_2] -> atomic {
if
:: lim == 0 -> goto BREAK;
:: else ->
cn ? b_0, b_1, b_2; // consume message on the channel
lim = lim - 1;
goto MAIN;
fi
}
od
BREAK:
}
\end{lstlisting}
\end{figure}
\subsection{Replaying Attacker Model}%
\label{sub:Replay Attacker}
The second attacker model \korg supports is an attacker that can observe and replay messages back onto a channel. Similarly to the drop limit for the dropping attacker model, the user can specify a "replay limit" that caps the number of messages the attacker can replay back onto the specified channel.
\jg{todo: describe impl more}
\subsection{Rearranging Attacker Model}%
\label{sub:Rearrange Attacker}
Lastly, \korg supports an attacker model such that an attacker can \textit{rearrange} messages on a channel. Like the drop and replay attacker models, the user can specify a "rearrange limit" that caps the number of messages that can be rearranged by the attacker on the specified channel.
\subsection{Custom Attacker Models}%
\label{sub:Custom Attacker Models}
While the drop, replay, and rearrange attacker models as previously described have complex gadgets that \korg synthesizes with respect to a user-specified channel, \korg also supports the synthesis of gadgets with respect to user-defined inputs and outputs.

1
sections/conclusion.tex
View File

@@ -0,0 +1 @@

125
sections/design.tex
View File

@@ -1,14 +1,88 @@
In this section we discuss the details behind the design, implementation, and guarantees of \korg.
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}
TODO: diagram. Promela model, channel selection, gadget selection/definition get put into Korg. Korg spits out another promela model, which is put into Spin along with a property. Then, we get some attacks.
At the highest level, \korg sits on a user-defined channel 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 the \spin, which exhaustively searches for attacks with respect to the chosen model and properties.
A high-level overview of the \korg pipeline is given in the Figure \ref{fig:korg_workflow}.
%from a formal model written in \promela.
%user-defined (or derived) \promela models.
%TODO: diagram. Promela model, channel selection, gadget selection/definition get put into Korg. Korg spits out another promela model, which is put into Spin along with a property. Then, we get some attacks.
\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{Soundness And Completeness of Korg}%
\label{sub:Soundness And Completeness}
\newcommand{\comp}{\mid\mid}
\newcommand{\ioint}{\mathcal{C}}
\newcommand{\ba}{B\"uchi Automata}
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 attack synthesis framework proposed by Hippel et al. and \korg use slightly different formalisms. Both employ derivations the general \textit{input/output automata}, state machines whose transitions indicate sending or receiving a message. In particular, the framework proposed by Hippel et al. defines their own notion of a \textit{process} and argues their attack synthesis framework 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 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 Hippel et al. with the B\"uchi Automata. For ease of reading and clarity, we only provide the shortened arguments here. The detailed 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 as defined in Hippel et al. 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 synchronous channels, or buffered asynchronous channels. \korg generates attacks \textit{with respect} to these defined channels.
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{figure}[h]
\begin{lstlisting}[caption={Example \promela model of peers communicating over a channel}, label={lst:spin-model}]
// channel of buffer size 0
chan msg_channel = [0] of { int }
@@ -22,48 +96,13 @@ active proctype Peer2() {
msg_channel ? received_msg
}
\end{lstlisting}
\end{figure}
Following the gadgetry framework as described in Hippel et al., \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{Soundness And Completeness of Korg}%
\label{sub:Soundness And Completeness}
\subsection{Usage}%
\label{sub:Usage}
\newcommand{\comp}{\mid\mid}
\newcommand{\ioint}{\mathcal{C}}
\newcommand{\ba}{B\"uchi Automata}
To use \korg, 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.
\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}
Checking whether there exists an attacker for a given threat model, the R-$\exists$ASP problem as proposed in Hippel et al., reduces to B\"uchi Automata language inclusion (which is in turn solved by the \spin model checker).
\end{theorem}
\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}
From this result, we naturally get a complexity-theoretic result for finding an attacker from a given threat model.
\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}
\begin{proof}
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}.
\end{proof}
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 $\phi$ is generally fast, but proving their absence via a state-space search can expensive.
Precise details of how to use the \korg implementation are provided in the anonymous repository: (link)

5
sections/introduction.tex
View File

@@ -1,3 +1,4 @@
Distributed protocols are the foundation for the modern internet, and therefore ensuring their correctness and security is paramount. To this end, formal methods, the use of mathematically rigorous techniques for reasoning about software, has been increasingly employed to analyze and study distributed protocols. Historically, formal methods has been employed for reasoning about concurrency and the correctness of distributed systems, and in recent years formal methods has been employed to reason about the security of cryptographic protocols and primitives. However, no previous formal methods tools offered an effective solution for studying denial of service attacks on protocols.
Distributed protocols are the foundation for the modern internet, and therefore ensuring their correctness and security is paramount. To this end, formal methods, the use of mathematically rigorous techniques for reasoning about software, has been increasingly employed to analyze and study distributed protocols. Historically, formal methods has been employed for reasoning about concurrency and distributed algorithms \cite{Lamport_1994, Holzmann_1997, Clarke_Wang}, and in recent years formal methods have been employed at scale to reason about the security of cryptographic protocols and primitives \cite{Basin_Cremers_Dreier_Sasse_2022, Blanchet_Smyth_Cheval_Sylvestre, Kobeissi_Nicolas_Tiwari, Blanchet_Jacomme, Basin_Linker_Sasse}.
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, rearrange, replay, or insert messages onto a communication channel?
To fill this gap we introduce \korg, a tool for synthesizing attacks on distributed protocols that implements the theoretical framework proposed in Hippel et al. 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, rearrange, 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. We present a variety of case studies illustrating the employability and usefulness of \korg.
To fill this gap, we introduce \korg, a tool for synthesizing attacks on distributed protocols that implements the theoretical framework proposed in Hippel et al. \cite{Hippel2022}. 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, rearrange, 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. We present a variety of case studies illustrating the employability and usefulness of \korg.