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-12-03 17:35:01 -05:00
parent b636781367
commit 673782c888
17 changed files with 2417 additions and 2175 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3691
.latexrun.db
View File

File diff suppressed because it is too large Load Diff

131
main.aux
View File

@@ -13,87 +13,112 @@
\newlabel{sec:design}{{II}{1}{\korg Architecture}{section.2}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-A}}Mathematical Preliminaries}{1}{subsection.2.1}\protected@file@percent }
\newlabel{sub:Mathematical Preliminaries}{{\mbox {II-A}}{1}{Mathematical Preliminaries}{subsection.2.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-B}}High-level design}{2}{subsection.2.2}\protected@file@percent }
\newlabel{sub:High-level design}{{\mbox {II-B}}{2}{High-level design}{subsection.2.2}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces A high-level overview of the \textsc {PANDA}\xspace workflow}}{2}{figure.caption.1}\protected@file@percent }
\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}}
\newlabel{fig:korg_workflow}{{1}{2}{A high-level overview of the \korg workflow}{figure.caption.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-C}}Supported Attacker Models}{2}{subsection.2.3}\protected@file@percent }
\newlabel{sub:Supported Attacker Models}{{\mbox {II-C}}{2}{Supported Attacker Models}{subsection.2.3}{}}
\newlabel{lst:korg_drop}{{1}{2}{Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}{lstlisting.1}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {1}{\ignorespaces Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}}{2}{lstlisting.1}\protected@file@percent }
\citation{Holzmann_2014}
\citation{Holzmann_Smith_2000}
\citation{mcp}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-B}}High-level design}{2}{subsection.2.2}\protected@file@percent }
\newlabel{sub:High-level design}{{\mbox {II-B}}{2}{High-level design}{subsection.2.2}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-C}}Supported Attacker Models}{2}{subsection.2.3}\protected@file@percent }
\newlabel{sub:Supported Attacker Models}{{\mbox {II-C}}{2}{Supported Attacker Models}{subsection.2.3}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-D}}\textsc {PANDA}\xspace Implementation}{2}{subsection.2.4}\protected@file@percent }
\newlabel{sub:impl}{{\mbox {II-D}}{2}{\korg Implementation}{subsection.2.4}{}}
\newlabel{lst:spin-model}{{6}{2}{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}{lstlisting.6}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {6}{\ignorespaces Example \textsc {Promela}\xspace model of peers communicating over a channel. \texttt {!} indicates sending a message onto a channel, \texttt {?} indicates receiving a message from a channel.}}{2}{lstlisting.6}\protected@file@percent }
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces A high-level overview of the \textsc {PANDA}\xspace workflow}}{3}{figure.caption.1}\protected@file@percent }
\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}}
\newlabel{fig:korg_workflow}{{1}{3}{A high-level overview of the \korg workflow}{figure.caption.1}{}}
\newlabel{lst:korg_drop}{{1}{3}{Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}{lstlisting.1}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {1}{\ignorespaces Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}}{3}{lstlisting.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-E}}Usage}{3}{subsection.2.5}\protected@file@percent }
\newlabel{sub:Usage}{{\mbox {II-E}}{3}{Usage}{subsection.2.5}{}}
\newlabel{lst:abp}{{8}{3}{Example (simplified) \promela model of the alternating bit protocol}{lstlisting.8}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {8}{\ignorespaces Example (simplified) \textsc {Promela}\xspace model of the alternating bit protocol.}}{3}{lstlisting.8}\protected@file@percent }
\newlabel{lst:korg_replay}{{2}{4}{Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{lstlisting.2}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {2}{\ignorespaces Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}}{4}{lstlisting.2}\protected@file@percent }
\newlabel{lst:korg_reordering}{{3}{4}{Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{lstlisting.3}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {3}{\ignorespaces Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}}{4}{lstlisting.3}\protected@file@percent }
\newlabel{lst:korg_replay}{{2}{3}{Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{lstlisting.2}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {2}{\ignorespaces Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}}{3}{lstlisting.2}\protected@file@percent }
\newlabel{lst:korg_reordering}{{3}{3}{Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{lstlisting.3}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {3}{\ignorespaces Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}}{3}{lstlisting.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-D}}\textsc {PANDA}\xspace Implementation}{3}{subsection.2.4}\protected@file@percent }
\newlabel{sub:impl}{{\mbox {II-D}}{3}{\korg Implementation}{subsection.2.4}{}}
\newlabel{lst:io-file}{{4}{4}{Example I/O file targetting channel "cn"}{lstlisting.4}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {4}{\ignorespaces Example I/O file targetting channel "cn"}}{4}{lstlisting.4}\protected@file@percent }
\newlabel{lst:io-file-synth}{{5}{4}{Example gadget synthesized from an I/O file targetting the channel "cn"}{lstlisting.5}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {5}{\ignorespaces Example gadget synthesized from an I/O file targetting the channel "cn"}}{4}{lstlisting.5}\protected@file@percent }
\newlabel{lst:spin-model}{{6}{4}{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}{lstlisting.6}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {6}{\ignorespaces Example \textsc {Promela}\xspace model of peers communicating over a channel. \texttt {!} indicates sending a message onto a channel, \texttt {?} indicates receiving a message from a channel.}}{4}{lstlisting.6}\protected@file@percent }
\newlabel{lst:drop_passer}{{7}{4}{Example dropping attacker model gadget with message skipping}{lstlisting.7}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {7}{\ignorespaces Example dropping attacker model gadget with message skipping}}{4}{lstlisting.7}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-E}}Usage}{4}{subsection.2.5}\protected@file@percent }
\newlabel{sub:Usage}{{\mbox {II-E}}{4}{Usage}{subsection.2.5}{}}
\citation{Cluzel_Georgiou_Moy_Zeller_2021,Smith_1997,Pacheco2022}
\citation{Pacheco2022}
\citation{Pacheco2022}
\citation{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016,Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson,Ongaro}
\citation{Ongaro}
\newlabel{lst:io-file}{{4}{5}{Example I/O file targetting channel "cn"}{lstlisting.4}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {4}{\ignorespaces Example I/O file targetting channel "cn"}}{5}{lstlisting.4}\protected@file@percent }
\newlabel{lst:io-file-synth}{{5}{5}{Example gadget synthesized from an I/O file targetting the channel "cn"}{lstlisting.5}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {5}{\ignorespaces Example gadget synthesized from an I/O file targetting the channel "cn"}}{5}{lstlisting.5}\protected@file@percent }
\citation{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}
\newlabel{lst:abp}{{8}{5}{Example (simplified) \promela model of the alternating bit protocol}{lstlisting.8}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {8}{\ignorespaces Example (simplified) \textsc {Promela}\xspace model of the alternating bit protocol.}}{5}{lstlisting.8}\protected@file@percent }
\newlabel{lst:korg-shell}{{\mbox {II-E}}{5}{}{lstlisting.-1}{}}
\newlabel{lst:drop_passer}{{7}{5}{Example dropping attacker model gadget with message skipping}{lstlisting.7}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {7}{\ignorespaces Example dropping attacker model gadget with message skipping}}{5}{lstlisting.7}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {III}Case Studies}{5}{section.3}\protected@file@percent }
\newlabel{sec:case_studies}{{III}{5}{Case Studies}{section.3}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}TCP}{5}{subsection.3.1}\protected@file@percent }
\newlabel{sub:TCP}{{\mbox {III-A}}{5}{TCP}{subsection.3.1}{}}
\newlabel{res:tcp-table}{{\caption@xref {res:tcp-table}{ on input line 30}}{5}{TCP}{figure.caption.7}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Automatically discovered attacks against our TCP model for $\phi _1$ through $\phi _4$. "x" indicates an attack was discovered, and no "x" indicates \textsc {PANDA}\xspace proved the absence of an attack via an exhaustive search. These experiments were ran on a laptop with an eighth generation i7 and 16gb of memory. Full attack traces are available in the artifact.}}{5}{figure.caption.7}\protected@file@percent }
\newlabel{res:tcp-table}{{2}{5}{Automatically discovered attacks against our TCP model for $\phi _1$ through $\phi _4$. "x" indicates an attack was discovered, and no "x" indicates \korg proved the absence of an attack via an exhaustive search. These experiments were ran on a laptop with an eighth generation i7 and 16gb of memory. Full attack traces are available in the artifact}{figure.caption.7}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Raft}{5}{subsection.3.2}\protected@file@percent }
\newlabel{sub:Raft}{{\mbox {III-B}}{5}{Raft}{subsection.3.2}{}}
\citation{Ongaro}
\citation{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}
\citation{Hippel2022_anonym}
\citation{Hippel2022_anonym}
\citation{Hippel2022_anonym}
\newlabel{res:tcp-table}{{\caption@xref {res:tcp-table}{ on input line 42}}{6}{TCP}{figure.caption.7}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Automatically discovered attacks against our TCP model for $\phi _1$ through $\phi _4$. "x" indicates an attack was discovered, and no "x" indicates \textsc {PANDA}\xspace proved the absence of an attack via an exhaustive search. These experiments were ran on a laptop with an eighth generation i7 and 16gb of memory. Full attack traces are available in the artifact.}}{6}{figure.caption.7}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Raft}{6}{subsection.3.2}\protected@file@percent }
\newlabel{sub:Raft}{{\mbox {III-B}}{6}{Raft}{subsection.3.2}{}}
\newlabel{res:raft_table}{{\caption@xref {res:raft_table}{ on input line 92}}{6}{Raft}{figure.caption.8}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Breakdown of the attacker scenarios assessed with \textsc {PANDA}\xspace against our Raft \textsc {Promela}\xspace model. In all experiments, Raft was set to five peers and the drop/replay limits of the gadgets \textsc {PANDA}\xspace synthesized were set to two. We conducted our experiments on a research computing cluster, allocating 250GB of memory to each verification run. The full models and attacker traces are included in the artifact.}}{6}{figure.caption.8}\protected@file@percent }
\newlabel{res:raft_table}{{3}{6}{Breakdown of the attacker scenarios assessed with \korg against our Raft \promela model. In all experiments, Raft was set to five peers and the drop/replay limits of the gadgets \korg synthesized were set to two. We conducted our experiments on a research computing cluster, allocating 250GB of memory to each verification run. The full models and attacker traces are included in the artifact}{figure.caption.8}{}}
\citation{Hippel2022_anonym}
\newlabel{res:raft_table}{{\caption@xref {res:raft_table}{ on input line 93}}{6}{Raft}{figure.caption.8}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Breakdown of the attacker scenarios assessed with \textsc {PANDA}\xspace against our buggy Raft \textsc {Promela}\xspace model, \texttt {raft-bug.pml}. In all experiments, the Raft model was set to five peers and the drop/replay limits of the gadgets \textsc {PANDA}\xspace synthesized were set to two. We conducted our experiments on a research computing cluster, allocating 250GB of memory to each verification run. The full models and attacker traces are included in the artifact.}}{6}{figure.caption.8}\protected@file@percent }
\newlabel{res:raft_table}{{3}{6}{Breakdown of the attacker scenarios assessed with \korg against our buggy Raft \promela model, \texttt {raft-bug.pml}. In all experiments, the Raft model was set to five peers and the drop/replay limits of the gadgets \korg synthesized were set to two. We conducted our experiments on a research computing cluster, allocating 250GB of memory to each verification run. The full models and attacker traces are included in the artifact}{figure.caption.8}{}}
\@writefile{toc}{\contentsline {section}{\numberline {IV}Proofs of Soundness and Completeness}{6}{section.4}\protected@file@percent }
\newlabel{sec:proofs}{{IV}{6}{Proofs of Soundness and Completeness}{section.4}{}}
\citation{Hippel2022_anonym}
\citation{Hippel2022_anonym}
\citation{Holzmann_1997}
\citation{Hippel2022_anonym}
\citation{Kozen_1977}
\citation{Kobeissi_Nicolas_Tiwari,Proverif,Tamarin,Cremers}
\citation{Blanchet_Jacomme,Pereira}
\citation{ParnoSOK,Basin_Cremers_Meadows_2018}
\citation{Khan_Mukund_Suresh_2005,Clarke_Wang,wayne_adversaries,Narayana_Chen_Zhao_Chen_Fu_Zhou_2006,Delzanno_Tatarek_Traverso_2014}
\citation{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson,Castro_Liskov_2002}
\citation{Henda}
\citation{Ginesin}
\citation{TCPwn}
\bibstyle{IEEEtran}
\bibdata{main}
\bibcite{Lamport_1994}{1}
\@writefile{toc}{\contentsline {section}{\numberline {V}Related Work}{7}{section.5}\protected@file@percent }
\newlabel{sec:Related Work}{{V}{7}{Related Work}{section.5}{}}
\@writefile{toc}{\contentsline {section}{\numberline {VI}Conclusion}{7}{section.6}\protected@file@percent }
\newlabel{sec:conclusion}{{VI}{7}{Conclusion}{section.6}{}}
\bibcite{Holzmann_1997}{2}
\bibcite{Clarke_Wang}{3}
\bibcite{Basin_Cremers_Dreier_Sasse_2022}{4}
\bibcite{Blanchet_Smyth_Cheval_Sylvestre}{5}
\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusion}{7}{section.5}\protected@file@percent }
\newlabel{sec:conclusion}{{V}{7}{Conclusion}{section.5}{}}
\@writefile{toc}{\contentsline {section}{References}{7}{section*.9}\protected@file@percent }
\bibcite{Kobeissi_Nicolas_Tiwari}{6}
\bibcite{Blanchet_Jacomme}{7}
\bibcite{Basin_Linker_Sasse}{8}
\bibcite{Hippel2022_anonym}{9}
\bibcite{Holzmann_2014}{10}
\bibcite{Holzmann_Smith_2000}{11}
\bibcite{mcp}{12}
\bibcite{Cluzel_Georgiou_Moy_Zeller_2021}{13}
\bibcite{Smith_1997}{14}
\bibcite{Pacheco2022}{15}
\bibcite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}{16}
\bibcite{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}{17}
\bibcite{Ongaro}{18}
\bibcite{Kozen_1977}{19}
\bibcite{Kobeissi_Nicolas_Tiwari}{5}
\bibcite{Blanchet_Jacomme}{6}
\bibcite{Basin_Linker_Sasse}{7}
\bibcite{Hippel2022_anonym}{8}
\bibcite{Holzmann_2014}{9}
\bibcite{Holzmann_Smith_2000}{10}
\bibcite{mcp}{11}
\bibcite{Cluzel_Georgiou_Moy_Zeller_2021}{12}
\bibcite{Smith_1997}{13}
\bibcite{Pacheco2022}{14}
\bibcite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}{15}
\bibcite{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}{16}
\bibcite{Ongaro}{17}
\bibcite{Kozen_1977}{18}
\bibcite{Proverif}{19}
\bibcite{Tamarin}{20}
\bibcite{Cremers}{21}
\bibcite{Pereira}{22}
\bibcite{ParnoSOK}{23}
\bibcite{Basin_Cremers_Meadows_2018}{24}
\bibcite{Khan_Mukund_Suresh_2005}{25}
\bibcite{wayne_adversaries}{26}
\bibcite{Narayana_Chen_Zhao_Chen_Fu_Zhou_2006}{27}
\bibcite{Delzanno_Tatarek_Traverso_2014}{28}
\bibcite{Castro_Liskov_2002}{29}
\bibcite{Henda}{30}
\bibcite{Ginesin}{31}
\bibcite{TCPwn}{32}
\@writefile{toc}{\contentsline {section}{References}{8}{section*.9}\protected@file@percent }
\gdef \@abspage@last{8}

109
main.bbl
View File

@@ -41,11 +41,6 @@ D.~Basin, C.~Cremers, J.~Dreier, and R.~Sasse,
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}.''
@@ -139,4 +134,108 @@ D.~Kozen, ``\BIBforeignlanguage{en}{Lower bounds for natural proof systems},''
\url{http://ieeexplore.ieee.org/document/4567949/}
\BIBentrySTDinterwordspacing
\bibitem{Proverif}
B.~Blanchet, B.~Smyth, V.~Cheval, and M.~Sylvestre,
``\BIBforeignlanguage{en}{Proverif 2.05: Automatic cryptographic protocol
verifier, user manual and tutorial}.''
\bibitem{Tamarin}
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{Cremers}
\BIBentryALTinterwordspacing
C.~J.~F. Cremers, \emph{\BIBforeignlanguage{en}{The Scyther Tool: Verification,
Falsification, and Analysis of Security Protocols}}, ser. Lecture Notes in
Computer Science.\hskip 1em plus 0.5em minus 0.4em\relax Berlin, Heidelberg:
Springer Berlin Heidelberg, 2008, vol. 5123, p. 414–418. [Online].
Available: \url{http://link.springer.com/10.1007/978-3-540-70545-1_38}
\BIBentrySTDinterwordspacing
\bibitem{Pereira}
V.~Pereira, ``\BIBforeignlanguage{en}{Easycrypt - a (brief) tutorial}.''
\bibitem{ParnoSOK}
\BIBentryALTinterwordspacing
M.~Barbosa, G.~Barthe, K.~Bhargavan, B.~Blanchet, C.~Cremers, K.~Liao, and
B.~Parno, ``Sok: Computer-aided cryptography,'' in \emph{2021 IEEE Symposium
on Security and Privacy (SP)}, May 2021, p. 777–795. [Online]. Available:
\url{https://ieeexplore.ieee.org/document/9519449/?arnumber=9519449}
\BIBentrySTDinterwordspacing
\bibitem{Basin_Cremers_Meadows_2018}
\BIBentryALTinterwordspacing
D.~Basin, C.~Cremers, and C.~Meadows, \emph{\BIBforeignlanguage{en}{Model
Checking Security Protocols}}.\hskip 1em plus 0.5em minus 0.4em\relax Cham:
Springer International Publishing, 2018, p. 727–762. [Online]. Available:
\url{http://link.springer.com/10.1007/978-3-319-10575-8_22}
\BIBentrySTDinterwordspacing
\bibitem{Khan_Mukund_Suresh_2005}
\BIBentryALTinterwordspacing
A.~S. Khan, M.~Mukund, and S.~P. Suresh, \emph{\BIBforeignlanguage{en}{Generic
Verification of Security Protocols}}, ser. Lecture Notes in Computer
Science.\hskip 1em plus 0.5em minus 0.4em\relax Berlin, Heidelberg: Springer
Berlin Heidelberg, 2005, vol. 3639, p. 221–235. [Online]. Available:
\url{http://link.springer.com/10.1007/11537328_18}
\BIBentrySTDinterwordspacing
\bibitem{wayne_adversaries}
\BIBentryALTinterwordspacing
H.~Wayne, ``Modeling adversaries with tla+,''
\url{https://www.hillelwayne.com/post/adversaries/}, 2019, accessed:
2024-12-03. [Online]. Available:
\url{https://www.hillelwayne.com/post/adversaries/}
\BIBentrySTDinterwordspacing
\bibitem{Narayana_Chen_Zhao_Chen_Fu_Zhou_2006}
\BIBentryALTinterwordspacing
P.~Narayana, R.~Chen, Y.~Zhao, Y.~Chen, Z.~Fu, and H.~Zhou, ``Automatic
vulnerability checking of ieee 802.16 wimax protocols through tla+,'' in
\emph{2006 2nd IEEE Workshop on Secure Network Protocols}, Nov. 2006, p.
44–49. [Online]. Available:
\url{https://ieeexplore.ieee.org/document/4110436/?arnumber=4110436}
\BIBentrySTDinterwordspacing
\bibitem{Delzanno_Tatarek_Traverso_2014}
G.~Delzanno, M.~Tatarek, and R.~Traverso, ``\BIBforeignlanguage{en}{Model
checking paxos in spin},'' \emph{\BIBforeignlanguage{en}{Electronic
Proceedings in Theoretical Computer Science}}, vol. 161, p. 131–146, Aug.
2014.
\bibitem{Castro_Liskov_2002}
M.~Castro and B.~Liskov, ``\BIBforeignlanguage{en}{Practical byzantine fault
tolerance and proactive recovery},'' \emph{\BIBforeignlanguage{en}{ACM
Transactions on Computer Systems}}, vol.~20, no.~4, p. 398–461, Nov. 2002.
\bibitem{Henda}
\BIBentryALTinterwordspacing
N.~Ben~Henda, ``\BIBforeignlanguage{en}{Generic and efficient attacker models
in spin},'' in \emph{\BIBforeignlanguage{en}{Proceedings of the 2014
International SPIN Symposium on Model Checking of Software}}.\hskip 1em plus
0.5em minus 0.4em\relax San Jose CA USA: ACM, Jul. 2014, p. 77–86.
[Online]. Available: \url{https://dl.acm.org/doi/10.1145/2632362.2632378}
\BIBentrySTDinterwordspacing
\bibitem{Ginesin}
\BIBentryALTinterwordspacing
J.~Ginesin, M.~von Hippel, E.~Defloor, C.~Nita-Rotaru, and M.~Tüxen, ``A
formal analysis of sctp: Attack synthesis and patch verification,'' no.
arXiv:2403.05663, Mar. 2024, arXiv:2403.05663 [cs]. [Online]. Available:
\url{http://arxiv.org/abs/2403.05663}
\BIBentrySTDinterwordspacing
\bibitem{TCPwn}
\BIBentryALTinterwordspacing
S.~Jero, E.~Hoque, D.~Choffnes, A.~Mislove, and C.~Nita-Rotaru,
``\BIBforeignlanguage{en}{Automated attack discovery in tcp congestion
control using a model-guided approach},'' in
\emph{\BIBforeignlanguage{en}{Proceedings 2018 Network and Distributed System
Security Symposium}}.\hskip 1em plus 0.5em minus 0.4em\relax San Diego, CA:
Internet Society, 2018. [Online]. Available:
\url{https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_02A-1_Jero_paper.pdf}
\BIBentrySTDinterwordspacing
\end{thebibliography}

43
main.bib
View File

@@ -1,3 +1,5 @@
@article{Proverif, 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} }
@inproceedings{Pacheco2022, address={San Francisco, CA, USA}, title={Automated Attack Synthesis by Extracting Finite State Machines from Protocol Specification Documents}, ISBN={978-1-66541-316-9}, url={https://ieeexplore.ieee.org/document/9833673/}, DOI={10.1109/SP46214.2022.9833673}, abstractNote={Automated attack discovery techniques, such as attacker synthesis or model-based fuzzing, provide powerful ways to ensure network protocols operate correctly and securely. Such techniques, in general, require a formal representation of the protocol, often in the form of a finite state machine (FSM). Unfortunately, many protocols are only described in English prose, and implementing even a simple network protocol as an FSM is time-consuming and prone to subtle logical errors. Automatically extracting protocol FSMs from documentation can significantly contribute to increased use of these techniques and result in more robust and secure protocol implementations.}, booktitle={2022 IEEE Symposium on Security and Privacy (SP)}, publisher={IEEE}, author={Pacheco, Maria Leonor and Hippel, Max Von and Weintraub, Ben and Goldwasser, Dan and Nita-Rotaru, Cristina}, year={2022}, month=may, pages={51–68}, language={en} }
@article{Hippel2022_anonym,
@@ -41,7 +43,6 @@ concurrent finite-state programs.}, publisher={IEEE Computer Society}, author={V
@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} }
@@ -80,3 +81,43 @@ concurrent finite-state programs.}, publisher={IEEE Computer Society}, author={V
@article{Holzmann_Smith_2000, title={Automating software feature verification}, volume={5}, ISSN={1538-7305}, DOI={10.1002/bltj.2223}, abstractNote={A significant part of the call processing software for Lucent’s new PathStar™ Access Server was checked with formal verification techniques. The verification system we built for this purpose, named FeaVer, is accessed via a standard Web browser. The system maintains a database of feature requirements, together with the results of the most recently performed verifications. Via the browser the user can invoke new verification runs, which are performed in the background with the help of a logic model checking tool. Requirement violations are reported either as high-level message sequence charts or as detailed execution traces of the system source. A main strength of the system is its capability to detect potential feature interaction problems at an early stage of systems design. This type of problem is difficult to detect with traditional testing techniques. Error reports are typically generated by the system within minutes after a comprehensive check is initiated, allowing near-interactive probing of feature requirements and quick confirmation (or rejection) of the validity of tentative software fixes.}, number={2}, journal={Bell Labs Technical Journal}, author={Holzmann, Gerard J. and Smith, Margaret H.}, year={2000}, pages={72–87}, language={en} }
@inproceedings{mcp, address={Grenoble, France}, title={Model checking programs}, ISBN={978-0-7695-0710-1}, url={http://ieeexplore.ieee.org/document/873645/}, DOI={10.1109/ASE.2000.873645}, abstractNote={The majority of work carried out in the formal methods community throughout the last three decades has (for good reasons) been devoted to special languages designed to make it easier to experiment with mechanized formal methods such as theorem provers, proof checkers and model checkers. In this paper we will attempt to give convincing arguments for why we believe it is time for the formal methods community to shift some of its attention towards the analysis of programs written in modern programming languages. In keeping with this philosophy we have developed a verification and testing environment for Java, called Java PathFinder (JPF), which integrates model checking, program analysis and testing. Part of this work has consisted of building a new Java Virtual Machine that interprets Java bytecode. JPF uses state compression to handle big states, and partial order and symmetry reduction, slicing, abstraction, and runtime analysis techniques to reduce the state space. JPF has been applied to a real-time avionics operating system developed at Honeywell, illustrating an intricate error, and to a model of a spacecraft controller, illustrating the combination of abstraction, runtime analysis, and slicing with model checking.}, booktitle={Proceedings ASE 2000. Fifteenth IEEE International Conference on Automated Software Engineering}, publisher={IEEE}, author={Visser, W. and Havelund, K. and Brat, G. and Seungjoon Park}, year={2000}, pages={3–11}, language={en} }
@misc{wayne_adversaries,
author = {Hillel Wayne},
title = {Modeling Adversaries with TLA+},
year = {2019},
url = {https://www.hillelwayne.com/post/adversaries/},
note = {Accessed: 2024-12-03},
howpublished = {\url{https://www.hillelwayne.com/post/adversaries/}}
}
@article{Pereira, title={EasyCrypt - a (brief) tutorial}, author={Pereira, Vitor}, 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} }
@inbook{Cremers, address={Berlin, Heidelberg}, series={Lecture Notes in Computer Science}, title={The Scyther Tool: Verification, Falsification, and Analysis of Security Protocols}, volume={5123}, ISBN={978-3-540-70543-7}, ISSN={0302-9743, 1611-3349}, url={http://link.springer.com/10.1007/978-3-540-70545-1_38}, DOI={10.1007/978-3-540-70545-1_38}, booktitle={Computer Aided Verification}, publisher={Springer Berlin Heidelberg}, author={Cremers, Cas J. F.}, editor={Gupta, Aarti and Malik, Sharad}, year={2008}, pages={414–418}, collection={Lecture Notes in Computer Science}, language={en} }
@article{Tamarin, 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} }
@inproceedings{ParnoSOK, title={SoK: Computer-Aided Cryptography}, ISSN={2375-1207}, url={https://ieeexplore.ieee.org/document/9519449/?arnumber=9519449}, DOI={10.1109/SP40001.2021.00008}, abstractNote={Computer-aided cryptography is an active area of research that develops and applies formal, machine-checkable approaches to the design, analysis, and implementation of cryptography. We present a cross-cutting systematization of the computer-aided cryptography literature, focusing on three main areas: (i) design-level security (both symbolic security and computational security), (ii) functional correctness and efficiency, and (iii) implementation-level security (with a focus on digital side-channel resistance). In each area, we first clarify the role of computer-aided cryptography—how it can help and what the caveats are—in addressing current challenges. We next present a taxonomy of state-of-the-art tools, comparing their accuracy, scope, trustworthiness, and usability. Then, we highlight their main achievements, trade-offs, and research challenges. After covering the three main areas, we present two case studies. First, we study efforts in combining tools focused on different areas to consolidate the guarantees they can provide. Second, we distill the lessons learned from the computer-aided cryptography community’s involvement in the TLS 1.3 standardization effort. Finally, we conclude with recommendations to paper authors, tool developers, and standardization bodies moving forward.}, booktitle={2021 IEEE Symposium on Security and Privacy (SP)}, author={Barbosa, Manuel and Barthe, Gilles and Bhargavan, Karthik and Blanchet, Bruno and Cremers, Cas and Liao, Kevin and Parno, Bryan}, year={2021}, month=may, pages={777–795} }
@article{Castro_Liskov_2002, title={Practical byzantine fault tolerance and proactive recovery}, volume={20}, ISSN={0734-2071, 1557-7333}, DOI={10.1145/571637.571640}, abstractNote={Our growing reliance on online services accessible on the Internet demands highly available systems that provide correct service without interruptions. Software bugs, operator mistakes, and malicious attacks are a major cause of service interruptions and they can cause arbitrary behavior, that is, Byzantine faults. This article describes a new replication algorithm, BFT, that can be used to build highly available systems that tolerate Byzantine faults. BFT can be used in practice to implement real services: it performs well, it is safe in asynchronous environments such as the Internet, it incorporates mechanisms to defend against Byzantine-faulty clients, and it recovers replicas proactively. The recovery mechanism allows the algorithm to tolerate any number of faults over the lifetime of the system provided fewer than 1/3 of the replicas become faulty within a small window of vulnerability. BFT has been implemented as a generic program library with a simple interface. We used the library to implement the first Byzantine-fault-tolerant NFS file system, BFS. The BFT library and BFS perform well because the library incorporates several important optimizations, the most important of which is the use of symmetric cryptography to authenticate messages. The performance results show that BFS performs 2% faster to 24% slower than production implementations of the NFS protocol that are not replicated. This supports our claim that the BFT library can be used to build practical systems that tolerate Byzantine faults.}, number={4}, journal={ACM Transactions on Computer Systems}, author={Castro, Miguel and Liskov, Barbara}, year={2002}, month=nov, pages={398–461}, language={en} }
@inproceedings{Henda, address={San Jose CA USA}, title={Generic and efficient attacker models in SPIN}, ISBN={978-1-4503-2452-6}, url={https://dl.acm.org/doi/10.1145/2632362.2632378}, DOI={10.1145/2632362.2632378}, abstractNote={In telecommunication networks, it is common that security protocol procedures rely on context information and other parameters of the global system state. Current security verification tools are well suited for analyzing protocols in isolation and it is not clear how they can be used for protocols intended to be run in more “dynamic” settings. Think of protocol procedures sharing parameters, arbitrarily interleaved or used as building blocks in more complex compound procedures. SPIN is a well established general purpose verification tool that has good support for modeling such systems. In contrast to specialized tools, SPIN lacks support for cryptographic primitives and intruder model which are necessary for checking security properties. We consider a special class of security protocols that fit well in the SPIN framework. Our modeling method is systematic, generic and efficient enough so that SPIN could find all the expected attacks on several of the classical key distribution protocols.}, booktitle={Proceedings of the 2014 International SPIN Symposium on Model Checking of Software}, publisher={ACM}, author={Ben Henda, Noomene}, year={2014}, month=jul, pages={77–86}, language={en} }
@article{Ginesin, title={A Formal Analysis of SCTP: Attack Synthesis and Patch Verification}, url={http://arxiv.org/abs/2403.05663}, abstractNote={SCTP is a transport protocol offering features such as multi-homing, multi-streaming, and message-oriented delivery. Its two main implementations were subjected to conformance tests using the PacketDrill tool. Conformance testing is not exhaustive and a recent vulnerability (CVE-2021-3772) showed SCTP is not immune to attacks. Changes addressing the vulnerability were implemented, but the question remains whether other flaws might persist in the protocol design. We study the security of the SCTP design, taking a rigorous approach rooted in formal methods. We create a formal Promela model of SCTP, and define 10 properties capturing the essential protocol functionality based on its RFC specification and consultation with the lead RFC author. Then we show using the Spin model checker that our model satisfies these properties. We define 4 attacker models - Off-Path, where the attacker is an outsider that can spoof the port and IP of a peer; Evil-Server, where the attacker is a malicious peer; Replay, where an attacker can capture and replay, but not modify, packets; and On-Path, where the attacker controls the channel between peers. We modify an attack synthesis tool designed for transport protocols, Korg, to support our SCTP model and four attacker models. We synthesize 14 unique attacks using the attacker models - including the CVE vulnerability in the Off-Path attacker model, 4 attacks in the Evil-Server attacker model, an opportunistic ABORT attack in the Replay attacker model, and eight connection manipulation attacks in the On-Path attacker model. We show that the proposed patch eliminates the vulnerability and does not introduce new ones according to our model and protocol properties. Finally, we identify and analyze an ambiguity in the RFC, which we show can be interpreted insecurely. We propose an erratum and show that it eliminates the ambiguity.}, note={arXiv:2403.05663 [cs]}, number={arXiv:2403.05663}, publisher={arXiv}, author={Ginesin, Jacob and von Hippel, Max and Defloor, Evan and Nita-Rotaru, Cristina and Tüxen, Michael}, year={2024}, month=mar }
@inproceedings{TCPwn, address={San Diego, CA}, title={Automated Attack Discovery in TCP Congestion Control Using a Model-guided Approach}, ISBN={978-1-891562-49-5}, url={https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_02A-1_Jero_paper.pdf}, DOI={10.14722/ndss.2018.23115}, abstractNote={One of the most important goals of TCP is to ensure fairness and prevent congestion collapse by implementing congestion control. Various attacks against TCP congestion control have been reported over the years, most of which have been discovered through manual analysis. In this paper, we propose an automated method that combines the generality of implementation-agnostic fuzzing with the precision of runtime analysis to find attacks against implementations of TCP congestion control. It uses a model-guided approach to generate abstract attack strategies, by leveraging a state machine model of TCP congestion control to find vulnerable state machine paths that an attacker could exploit to increase or decrease the throughput of a connection to his advantage. These abstract strategies are then mapped to concrete attack strategies, which consist of sequences of actions such as injection or modification of acknowledgements and a logical time for injection. We design and implement a virtualized platform, TCPWN, that consists of a a proxy-based attack injector and a TCP congestion control state tracker that uses only network traffic to create and inject these concrete attack strategies. We evaluated 5 TCP implementations from 4 Linux distributions and Windows 8.1. Overall, we found 11 classes of attacks, of which 8 are new.}, booktitle={Proceedings 2018 Network and Distributed System Security Symposium}, publisher={Internet Society}, author={Jero, Samuel and Hoque, Endadul and Choffnes, David and Mislove, Alan and Nita-Rotaru, Cristina}, year={2018}, language={en} }
@inbook{Khan_Mukund_Suresh_2005, address={Berlin, Heidelberg}, series={Lecture Notes in Computer Science}, title={Generic Verification of Security Protocols}, volume={3639}, ISBN={978-3-540-28195-5}, url={http://link.springer.com/10.1007/11537328_18}, DOI={10.1007/11537328_18}, abstractNote={Security protocols are notoriously difficult to debug. One approach to the automatic verification of security protocols with a bounded set of agents uses logic programming with analysis and synthesis rules to describe how the attacker gains information and constructs new messages.}, booktitle={Model Checking Software}, publisher={Springer Berlin Heidelberg}, author={Khan, Abdul Sahid and Mukund, Madhavan and Suresh, S. P.}, editor={Godefroid, Patrice}, year={2005}, pages={221–235}, collection={Lecture Notes in Computer Science}, 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} }
@inbook{Basin_Cremers_Meadows_2018, address={Cham}, title={Model Checking Security Protocols}, ISBN={978-3-319-10574-1}, url={http://link.springer.com/10.1007/978-3-319-10575-8_22}, DOI={10.1007/978-3-319-10575-8_22}, booktitle={Handbook of Model Checking}, publisher={Springer International Publishing}, author={Basin, David and Cremers, Cas and Meadows, Catherine}, editor={Clarke, Edmund M. and Henzinger, Thomas A. and Veith, Helmut and Bloem, Roderick}, year={2018}, pages={727–762}, language={en} }
@inbook{Basin_Mödersheim_Viganò_2003, address={Berlin, Heidelberg}, series={Lecture Notes in Computer Science}, title={An On-the-Fly Model-Checker for Security Protocol Analysis}, volume={2808}, rights={http://www.springer.com/tdm}, ISBN={978-3-540-20300-1}, url={http://link.springer.com/10.1007/978-3-540-39650-5_15}, DOI={10.1007/978-3-540-39650-5_15}, abstractNote={We introduce the on-the-fly model-checker OFMC, a tool that combines two ideas for analyzing security protocols based on lazy, demand-driven search. The first is the use of lazy data-types as a simple way of building efficient on-the-fly model checkers for protocols with infinite state spaces. The second is the integration of symbolic techniques and optimizations for modeling a lazy Dolev-Yao intruder, whose actions are generated in a demand-driven way. We present both techniques, along with optimizations and proofs of correctness and completeness.}, booktitle={Computer Security – ESORICS 2003}, publisher={Springer Berlin Heidelberg}, author={Basin, David and Mödersheim, Sebastian and Viganò, Luca}, editor={Snekkenes, Einar and Gollmann, Dieter}, year={2003}, pages={253–270}, collection={Lecture Notes in Computer Science}, language={en} }
@inproceedings{Narayana_Chen_Zhao_Chen_Fu_Zhou_2006, title={Automatic Vulnerability Checking of IEEE 802.16 WiMAX Protocols through TLA+}, url={https://ieeexplore.ieee.org/document/4110436/?arnumber=4110436}, DOI={10.1109/NPSEC.2006.320346}, abstractNote={Vulnerability analysis is indispensably the first step towards securing a network protocol, but currently remains mostly a best effort manual process with no completeness guarantee. Formal methods are proposed for vulnerability analysis and most existing work focus on security properties such as perfect forwarding secrecy and correctness of authentication. However, it remains unclear how to apply these methods to analyze more subtle vulnerabilities such as denial-of-service (DoS) attacks. To address this challenge, in this paper, we propose use of TLA+ to automatically check DoS vulnerability of network protocols with completeness guarantee. In particular, we develop new schemes to avoid state space explosion in property checking and to model attackers’ capabilities for finding realistic attacks. As a case study, we successfully identify threats to IEEE 802.16 air interface protocols.}, booktitle={2006 2nd IEEE Workshop on Secure Network Protocols}, author={Narayana, Prasad and Chen, Ruiming and Zhao, Yao and Chen, Yan and Fu, Zhi and Zhou, Hai}, year={2006}, month=nov, pages={44–49} }
@article{Delzanno_Tatarek_Traverso_2014, title={Model Checking Paxos in Spin}, volume={161}, ISSN={2075-2180}, DOI={10.4204/EPTCS.161.13}, journal={Electronic Proceedings in Theoretical Computer Science}, author={Delzanno, Giorgio and Tatarek, Michele and Traverso, Riccardo}, year={2014}, month=aug, pages={131–146}, language={en} }

82
main.blg
View File

@@ -8,13 +8,20 @@ Reallocated singl_function (elt_size=8) to 100 items from 50.
Reallocated wiz_functions (elt_size=8) to 6000 items from 3000.
Reallocated singl_function (elt_size=8) to 100 items from 50.
Database file #1: main.bib
Repeated entry---line 97 of file main.bib
: @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} }
I'm skipping whatever remains of this entry
Repeated entry---line 115 of file main.bib
: @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} }
I'm skipping whatever remains of this entry
Warning--I didn't find a database entry for "Blanchet_Smyth_Cheval_Sylvestre"
-- 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
@@ -26,47 +33,52 @@ Warning--empty journal in Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson
Warning--empty year in Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson
Warning--empty journal in Ongaro
Warning--empty year in Ongaro
Warning--empty journal in Proverif
Warning--empty year in Proverif
Warning--empty journal in Pereira
Warning--empty year in Pereira
Warning--empty journal in Ginesin
Done.
You've used 19 entries,
You've used 32 entries,
4087 wiz_defined-function locations,
946 strings with 10939 characters,
and the built_in function-call counts, 10982 in all, are:
= -- 918
> -- 224
< -- 20
+ -- 106
- -- 53
* -- 609
:= -- 1703
add.period$ -- 43
call.type$ -- 19
change.case$ -- 20
1049 strings with 14007 characters,
and the built_in function-call counts, 19759 in all, are:
= -- 1710
> -- 401
< -- 37
+ -- 190
- -- 95
* -- 1049
:= -- 3038
add.period$ -- 71
call.type$ -- 32
change.case$ -- 32
chr.to.int$ -- 0
cite$ -- 34
duplicate$ -- 955
empty$ -- 924
format.name$ -- 65
if$ -- 2529
cite$ -- 50
duplicate$ -- 1683
empty$ -- 1664
format.name$ -- 116
if$ -- 4620
int.to.chr$ -- 0
int.to.str$ -- 19
missing$ -- 171
newline$ -- 92
num.names$ -- 19
pop$ -- 437
int.to.str$ -- 32
missing$ -- 301
newline$ -- 149
num.names$ -- 32
pop$ -- 755
preamble$ -- 1
purify$ -- 0
quote$ -- 2
skip$ -- 856
skip$ -- 1598
stack$ -- 0
substring$ -- 175
swap$ -- 680
text.length$ -- 20
substring$ -- 339
swap$ -- 1240
text.length$ -- 37
text.prefix$ -- 0
top$ -- 5
type$ -- 19
warning$ -- 15
while$ -- 29
width$ -- 21
write$ -- 199
(There were 15 warnings)
type$ -- 32
warning$ -- 18
while$ -- 51
width$ -- 34
write$ -- 345
(There were 2 error messages)

19
main.fls
View File

@@ -518,6 +518,8 @@ 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/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
@@ -532,20 +534,18 @@ INPUT ./assets/diagram-anon.png
INPUT ./assets/diagram-anon.png
INPUT ./assets/diagram-anon.png
INPUT ./assets/diagram-anon.png
INPUT ./sections/examples.tex
INPUT ./sections/examples.tex
INPUT ./sections/examples.tex
INPUT ./sections/examples.tex
INPUT ./sections/examples.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/vf/adobe/times/ptmb7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmb8r.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/examples.tex
INPUT ./sections/examples.tex
INPUT ./sections/examples.tex
INPUT ./sections/examples.tex
INPUT ./sections/examples.tex
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmbc7t.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/courier/pcrr7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr8r.tfm
@@ -570,6 +570,11 @@ INPUT ./sections/proofs.tex
INPUT ./sections/proofs.tex
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmrc7t.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmrc7t.tfm
INPUT ./sections/related_work.tex
INPUT ./sections/related_work.tex
INPUT ./sections/related_work.tex
INPUT ./sections/related_work.tex
INPUT ./sections/related_work.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex

174
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) 2 DEC 2024 02:51
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/Arch Linux) (preloaded format=pdflatex 2024.7.2) 3 DEC 2024 17:34
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@@ -1234,6 +1234,9 @@ File: lstmisc.sty 2024/02/21 1.10 (Carsten Heinz)
\c@theorem=\count404
(./main.aux
LaTeX Warning: Label `res:tcp-table' multiply defined.
LaTeX Warning: Label `res:raft_table' multiply defined.
)
@@ -1312,8 +1315,11 @@ LaTeX Warning: No \author given.
LaTeX Warning: No \author given.
(./sections/abstract.tex) (./sections/introduction.tex
LaTeX Font Info: Trying to load font information for U+msa on input line 6.
LaTeX Warning: Citation `Blanchet_Smyth_Cheval_Sylvestre' on page 1 undefined o
n input line 3.
LaTeX Font Info: Trying to load font information for U+msa on input line 6.
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
)
@@ -1327,20 +1333,20 @@ ts/enc/dvips/base/8r.enc}
]
<assets/diagram-anon.png, id=87, 584.1825pt x 222.07968pt>
<assets/diagram-anon.png, id=91, 584.1825pt x 222.07968pt>
File: assets/diagram-anon.png Graphic file (type png)
<use assets/diagram-anon.png>
Package pdftex.def Info: assets/diagram-anon.png used on input line 30.
(pdftex.def) Requested size: 361.19843pt x 137.31522pt.
Package pdftex.def Info: assets/diagram-anon.png used on input line 33.
(pdftex.def) Requested size: 258.0pt x 98.08133pt.
Overfull \hbox (6.0pt too wide) in paragraph at lines 33--34
[][]
[]
LaTeX Warning: `h' float specifier changed to `ht'.
(./sections/examples.tex
Package hyperref Info: bookmark level for unknown lstlisting defaults to 0 on i
nput line 5.
LaTeX Font Info: Trying to load font information for OT1+pcr on input line 5
.
nput line 60.
LaTeX Font Info: Trying to load font information for OT1+pcr on input line 6
0.
(/usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
)
@@ -1356,25 +1362,14 @@ LaTeX Warning: `h' float specifier changed to `ht'.
LaTeX Warning: `h' float specifier changed to `ht'.
)
[2 <./assets/diagram-anon.png (PNG copy)>] (./sections/examples.tex)
LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
(Font) using `OT1/ptm/m/sc' instead on input line 104.
[2]
LaTeX Warning: `h' float specifier changed to `ht'.
[3 <./assets/diagram-anon.png (PNG copy)>]
Underfull \vbox (badness 3168) has occurred while \output is active []
Underfull \vbox (badness 3168) has occurred while \output is active []
[4]
LaTeX Font Info: Trying to load font information for TS1+pcr on input line 2
14.
(Font) using `OT1/ptm/m/sc' instead on input line 247.
[3] [4]
LaTeX Font Info: Trying to load font information for TS1+pcr on input line 3
57.
(/usr/share/texmf-dist/tex/latex/psnfss/ts1pcr.fd
File: ts1pcr.fd 2001/06/04 font definitions for TS1/pcr.
)
@@ -1398,19 +1393,10 @@ Underfull \hbox (badness 4144) in paragraph at lines 19--19
[]\OT1/pcr/m/n/5 SYN_RECEIVED \OT1/ptm/m/n/5 is even-tu-ally fol-lowed by
[]
Package caption Warning: \label without proper reference on input line 42.
See the caption package documentation for explanation.
LaTeX Warning: Reference `res:tcp-table' on page 5 undefined on input line 23.
LaTeX Warning: `!h' float specifier changed to `!ht'.
Excluding 'comment' comment. [5]
LaTeX Warning: `!h' float specifier changed to `!ht'.
Underfull \hbox (badness 3646) in paragraph at lines 109--109
[]\OT1/ptm/m/n/10 Fig. 3: |Break-down of the at-tacker sce-nar-ios as-sessed
[]
) (./sections/proofs.tex
Underfull \hbox (badness 3503) in paragraph at lines 19--21
@@ -1428,32 +1414,14 @@ m/m/n/10 with $\OML/cmm/m/it/10 s[] \OT1/cmr/m/n/10 = \OML/cmm/m/it/10 s[]$ \OT
LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
(Font) using `OT1/ptm/m/sc' instead on input line 91.
(Font) using `OT1/ptm/m/sc' instead on input line 90.
Underfull \hbox (badness 1715) in paragraph at lines 98--100
Underfull \hbox (badness 1715) in paragraph at lines 97--99
\OT1/ptm/m/n/10 via the pre-vi-ous the-o-rem we can con-struct B[]uchi Au-
[]
) (./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.
) (./sections/related_work.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.
@@ -1495,6 +1463,21 @@ Underfull \hbox (badness 1715) in paragraph at lines 98--100
** 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 `eng'. Using the pattern for
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been
@@ -1521,6 +1504,51 @@ Underfull \hbox (badness 1715) in paragraph at lines 98--100
** 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.
** 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.
** 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.
)
** Conference Paper **
@@ -1533,9 +1561,7 @@ 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.
[8
] (./main.aux)
[8] (./main.aux)
***********
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-02-20>
@@ -1548,16 +1574,16 @@ LaTeX Warning: There were undefined references.
LaTeX Warning: There were multiply-defined labels.
Package rerunfilecheck Info: File `main.out' has not changed.
(rerunfilecheck) Checksum: 5B902670F40C388F59EF45336B329F15;1685.
(rerunfilecheck) Checksum: 27EE6006AAFB1A1E6386C970007B5C60;1792.
)
Here is how much of TeX's memory you used:
41033 strings out of 476076
907381 string characters out of 5793776
2286187 words of memory out of 5000000
62155 multiletter control sequences out of 15000+600000
41059 strings out of 476076
907916 string characters out of 5793776
2208187 words of memory out of 5000000
62173 multiletter control sequences out of 15000+600000
606090 words of font info for 125 fonts, out of 8000000 for 9000
14 hyphenation exceptions out of 8191
99i,11n,101p,1201b,2034s stack positions out of 10000i,1000n,20000p,200000b,200000s
99i,11n,101p,1201b,1550s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb></usr/share/
texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/texmf-dist/fon
ts/type1/public/amsfonts/cm/cmmi5.pfb></usr/share/texmf-dist/fonts/type1/public
@@ -1569,10 +1595,10 @@ lic/amsfonts/cm/cmsy7.pfb></usr/share/texmf-dist/fonts/type1/urw/courier/ucrr8a
.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmb8a.pfb></usr/share/texmf-
dist/fonts/type1/urw/times/utmbi8a.pfb></usr/share/texmf-dist/fonts/type1/urw/t
imes/utmr8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmri8a.pfb>
Output written on ./main.pdf (8 pages, 260146 bytes).
Output written on ./main.pdf (8 pages, 267478 bytes).
PDF statistics:
522 PDF objects out of 1000 (max. 8388607)
478 compressed objects within 5 object streams
266 named destinations out of 1000 (max. 500000)
122 words of extra memory for PDF output out of 10000 (max. 10000000)
565 PDF objects out of 1000 (max. 8388607)
520 compressed objects within 6 object streams
271 named destinations out of 1000 (max. 500000)
130 words of extra memory for PDF output out of 10000 (max. 10000000)

14
main.out Normal file
View File

@@ -0,0 +1,14 @@
\BOOKMARK [1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
\BOOKMARK [1][-]{section.2}{\376\377\000P\000A\000N\000D\000A\000\040\000A\000r\000c\000h\000i\000t\000e\000c\000t\000u\000r\000e}{}% 2
\BOOKMARK [2][-]{subsection.2.1}{\376\377\000M\000a\000t\000h\000e\000m\000a\000t\000i\000c\000a\000l\000\040\000P\000r\000e\000l\000i\000m\000i\000n\000a\000r\000i\000e\000s}{section.2}% 3
\BOOKMARK [2][-]{subsection.2.2}{\376\377\000H\000i\000g\000h\000-\000l\000e\000v\000e\000l\000\040\000d\000e\000s\000i\000g\000n}{section.2}% 4
\BOOKMARK [2][-]{subsection.2.3}{\376\377\000S\000u\000p\000p\000o\000r\000t\000e\000d\000\040\000A\000t\000t\000a\000c\000k\000e\000r\000\040\000M\000o\000d\000e\000l\000s}{section.2}% 5
\BOOKMARK [2][-]{subsection.2.4}{\376\377\000P\000A\000N\000D\000A\000\040\000I\000m\000p\000l\000e\000m\000e\000n\000t\000a\000t\000i\000o\000n}{section.2}% 6
\BOOKMARK [2][-]{subsection.2.5}{\376\377\000U\000s\000a\000g\000e}{section.2}% 7
\BOOKMARK [1][-]{section.3}{\376\377\000C\000a\000s\000e\000\040\000S\000t\000u\000d\000i\000e\000s}{}% 8
\BOOKMARK [2][-]{subsection.3.1}{\376\377\000T\000C\000P}{section.3}% 9
\BOOKMARK [2][-]{subsection.3.2}{\376\377\000R\000a\000f\000t}{section.3}% 10
\BOOKMARK [1][-]{section.4}{\376\377\000P\000r\000o\000o\000f\000s\000\040\000o\000f\000\040\000S\000o\000u\000n\000d\000n\000e\000s\000s\000\040\000a\000n\000d\000\040\000C\000o\000m\000p\000l\000e\000t\000e\000n\000e\000s\000s}{}% 11
\BOOKMARK [1][-]{section.5}{\376\377\000R\000e\000l\000a\000t\000e\000d\000\040\000W\000o\000r\000k}{}% 12
\BOOKMARK [1][-]{section.6}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n}{}% 13
\BOOKMARK [1][-]{section*.9}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000s}{}% 14

BIN
main.pdf
View File

Binary file not shown.

BIN
main.synctex.gz
View File

Binary file not shown.

4
main.tex
View File

@@ -109,6 +109,10 @@ Protocols, Attack Synthesis, Denial of Service, Model Checking
\label{sec:proofs}
\input{sections/proofs}
\section{Related Work}%
\label{sec:Related Work}
\input{sections/related_work}
\section{Conclusion}
\label{sec:conclusion}
\input{sections/conclusion}

3
pdflatex3526457.fls Normal file
View File

@@ -0,0 +1,3 @@
PWD /home/synchronous/code/dsn-korg-paper
INPUT /usr/share/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt

13
sections/case_studies.tex
View File

@@ -27,6 +27,7 @@ We evaluated the TCP \promela model against \korg's drop, replay, and reordering
\begin{figure}[h!]
\centering
\label{res:tcp-table}
\begin{scriptsize}
\begin{tabular}{|c|c|c|c|}
\hline
@@ -39,10 +40,10 @@ $\phi_4$ & & &\\
\end{tabular}
\end{scriptsize}
\label{res:tcp-table}
\caption{Automatically discovered attacks against
%the hand-written TCP model from Pacheco et al. and our own,
our TCP model for $\phi_1$ through $\phi_4$. "x" indicates an attack was discovered, and no "x" indicates \korg proved the absence of an attack via an exhaustive search. These experiments were ran on a laptop with an eighth generation i7 and 16gb of memory. Full attack traces are available in the artifact.}
\label{res:tcp-table}
\end{figure}
\begin{comment}
@@ -72,7 +73,7 @@ $\phi_4$ & \rule{0pt}{8pt} x & & & & & & x & & \\
\subsection{Raft}%
\label{sub:Raft}
Raft is a consensus algorithm designed to replicate a state machine across distributed peers, and sees broad usage in distributed databases, key-value stores, distributed file systems, distributed load-balancers, and container orchestration. Historically, verification efforts of Raft using both constructive, mechanized proving techniques \cite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016, Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson, Ongaro} and automated verification \cite{Ongaro} have reasoned about the protocol under certain assumptions about the stability of the communication channels. However, no previous approach to Raft verification has reasoned about an coordinated, arbitrary on-channel attacker \textit{external} to the protocol itself. Uniquely, \korg enables us to study Raft in this context.
Raft is a consensus algorithm designed to replicate a state machine across distributed peers, and sees broad usage in distributed databases, key-value stores, distributed file systems, distributed load-balancers, and container orchestration. Historically, verification efforts of Raft using both constructive, mechanized proving techniques \cite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016, Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson, Ongaro} and automated verification \cite{Ongaro} have reasoned about the protocol under certain assumptions about the stability of the communication channels. Previously, Raft has been proven to maintain properties of interest with respect volatile, attacker-controlled channels constructively using Rocq\footnote{Previously known as Coq} \cite{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}. However, no previous approach to Raft verification has reasoned explicitly about a coordinated, arbitrary on-channel attacker \textit{external} to the protocol itself. Uniquely, \korg enables us to study Raft in this context.
Referencing the original Raft thesis \cite{Ongaro} and other raft models \cite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}, we constructed a \promela model of the Raft protocol. Additionally, we derived and formalized the following properties, which our \promela model satisfies:
\[
@@ -86,7 +87,7 @@ Referencing the original Raft thesis \cite{Ongaro} and other raft models \cite{W
\]
We construct our Raft model such that we can model-check an arbitrary number of peers. We also designed our model such that each peer maintains separate channels for receiving AppendEntry requests, AppendEntry responses, RequestVote requests, and RequestVote responses. This gives \korg ample handle to reason about Raft. In particular, we study Raft in the presence of drop and replay attackers on all four aforementioned channel types, attacking both a minority and majority of peers.
To test \korg, we introduce a subtle bug in the Raft consensus mechanism: not ensuring votes come from unique peers. A breakdown of our findings is shown in Figure \ref{res:raft_table}.
To test \korg, we altered our original Raft model to introduce a subtle bug in the raft consensus mechanism by not ensuring votes come from unique peers. We'll refer to our original, correct Raft model as \texttt{raft.pml}, and our buggy Raft model as \texttt{raft-bug.pml}. Both \texttt{raft.pml} and \texttt{raft-bug.pml} passed on $\phi_1$-$\phi_5$ (that is, assuming the channels are perfect). We assess \texttt{raft-bug.pml} with \korg, and a breakdown of our findings is shown in Figure \ref{res:raft_table}.
\begin{figure}[h!]
\label{res:raft_table}
@@ -105,10 +106,12 @@ Dropping AppendEntryResponse messages & no \\
\hline
\end{tabular}
\end{scriptsize}
\caption{Breakdown of the attacker scenarios assessed with \korg against our Raft \promela model. In all experiments, Raft was set to five peers and the drop/replay limits of the gadgets \korg synthesized were set to two. We conducted our experiments on a research computing cluster, allocating 250GB of memory to each verification run. The full models and attacker traces are included in the artifact.}
\caption{Breakdown of the attacker scenarios assessed with \korg against our buggy Raft \promela model, \texttt{raft-bug.pml}. In all experiments, the Raft model was set to five peers and the drop/replay limits of the gadgets \korg synthesized were set to two. We conducted our experiments on a research computing cluster, allocating 250GB of memory to each verification run. The full models and attacker traces are included in the artifact.}
\label{res:raft_table}
\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. 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.
In our experiments, we found just one attack on our \texttt{raft-bug.pml} \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. In this scenario, \korg demonstrates its ability to discover subtle bugs in protocol logic, exploiting the buggy Raft implementation.
%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}.

153
sections/design.tex
View File

@@ -19,18 +19,21 @@ As aforementioned, \korg is based on \textit{LTL attack synthesis}; in particula
%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 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.
\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) the 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.
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.
%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,
%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}.
A high-level visual overview of the \korg pipeline is given in the Figure \ref{fig:korg_workflow}.
\begin{figure*}[h]
\begin{figure}[h]
\centering
\includegraphics[width=0.7\textwidth]{assets/diagram-anon.png}
\includegraphics[width=0.5\textwidth]{assets/diagram-anon.png}
\caption{A high-level overview of the \korg workflow}
\label{fig:korg_workflow}
\end{figure*}
\end{figure}
\subsection{Supported Attacker Models}%
@@ -53,14 +56,154 @@ A high-level overview of the \korg pipeline is given in the Figure \ref{fig:korg
The most simple 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.
The dropper attacker model gadget \korg synthesizes works as follows. The gadget will nondeterministically choose to observe a message on a channel. Then, if the drop limit variable is not zero, it will consume the message. An example is shown in Figure \ref{lst:korg_drop}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}, label={lst:korg_drop}]
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}
\textbf{Replay Attacker Model Gadget}
The next attacker model \korg supports is an attacker that can observe and \textit{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 observed messages the attacker can replay back onto the specified channel.
The replay attacker model gadget \korg employs works as follows. The gadget has two states, \textsc{Consume} and \textsc{Replay}. The gadget starts in the \textsc{Consume} state and nondeterministically reads (but not consumes) messages on the target channel, sending them into a local storage buffer. Once the gadget read the number of messages on the channel equivalent to the defined replay limit, its state changes to \textsc{Replay}. In the \textsc{Replay} state, the gadget nondeterministically selects messages from its storage buffer to replay onto the channel until out of messages. An example is shown in Figure \ref{lst:korg_replay}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_replay}]
chan cn = [8] of { int, int, int };
// local memory for the gadget
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_replay() {
int b_0, b_1, b_2; int i = 3;
CONSUME:
do
// read messages until the limit is passed
:: cn ? [b_0, b_1, b_2] -> atomic {
cn ? <b_0, b_1, b_2> -> gadget_mem ! b_0, b_1, b_2;
i--;
if
:: i == 0 -> goto REPLAY;
:: i != 0 -> goto CONSUME;
fi }
od
REPLAY:
do
:: atomic {
// nondeterministically select a random value from the storage buffer
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0, b_1, b_2 -> gadget_mem ! b_0, b_1, b_2;
:: am == 0 ->
gadget_mem ? b_0, b_1, b_2 -> cn ! b_0, b_1, b_2;
break;
od }
// doesn't need to use all messages on the channel
:: atomic {gadget_mem ? b_0, b_1, b_2; }
// once mem has no more messages, we're done
:: empty(gadget_mem) -> goto BREAK;
od
BREAK:
}
\end{lstlisting}
\end{figure}
\textbf{Reorder Attacker Model Gadget}
\korg supports synthesizing attackers that can \textit{reorder} messages on a channel. Like the drop and replay attacker model gadgets, the user can specify a "reordering limit" that caps the number of messages that can be reordered by the attacker on the specified channel.
The reordering attacker model gadget \korg synthesizes works as follows. The gadget has three states, \textsc{Init}, \textsc{Consume}, and \textsc{Replay}. The gadget begins in the \textsc{Init} state, where it arbitrarily chooses a message to start consuming by transitioning to the \textsc{Consume} state. When in the \textsc{Consume} state, the gadget consumes all messages that appear on the channel, filling up a local buffer, until hitting the defined reordering limit. Once this limit is hit, the gadget transitions into the \textsc{Replay} state. In the \textsc{Replay} state, the gadget nondeterministically selects messages from its storage buffer to replay onto the channel until out of messages. An example is shown in Figure \ref{lst:korg_reordering}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_reordering}]
chan cn = [8] of { int, int, int };
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_reordering() priority 255 {
byte b_0, b_1, b_2, blocker; int i = 3;
INIT:
do
:: { // arbitrarily choose a message to start consuming on
blocker = len(cn);
do :: b != len(c) -> goto INIT; od
}
:: goto CONSUME;
od
CONSUME:
do
// consume messages with high priority
:: c ? [b_0] -> atomic {
c ? b_0 -> gadget_mem ! b_0; i--;
if
:: i == 0 -> goto REPLAY;
:: i != 0 -> goto CONSUME;
fi }
od
REPLAY:
do
// replay messages back onto the channel, also with priority
:: atomic {
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0 -> attacker_mem_0 ! b_0;
:: am == 0 ->
gadget_mem ? b_0 -> c ! b_0;
break;
od }
:: atomic { empty(gadget_mem) -> goto BREAK; }
od
BREAK:
}
\end{lstlisting}
\end{figure}
\begin{figure}[h]
\begin{lstlisting}[caption={Example I/O file targetting channel "cn"}, label={lst:io-file}]
cn:
I:
O:1-1-1, 1-2-3, 3-4-5
\end{lstlisting}
\begin{lstlisting}[caption={Example gadget synthesized from an I/O file targetting the channel "cn"}, label={lst:io-file-synth}]
chan cn = [8] of { int, int, int };
active proctype daisy() {
INIT:
do
:: cn ! 1,1,1;
:: cn ! 1,2,3;
:: cn ! 3,4,5;
:: goto RECOVERY;
od
RECOVERY:
}
\end{lstlisting}
\end{figure}
\textbf{Insert Attacker Models}
\korg supports the synthesis of attackers that can simply insert messages onto a channel. While the drop, replay, and reordering attacker model gadgets as previously described have complex gadgets that \korg synthesizes with respect to a user-specified channel, the insert attacker model gadget is synthesized with respect to a user-defined \textit{IO-file}. This file denotes the specific outputs and channels the attacker is capable of sending, and \korg generates a gadget capable of synthesizing attacks using the given inputs. An example I/O file is given in Figure \ref{lst:io-file}, and the generated gadget is given in Figure \ref{lst:io-file-synth}.

143
sections/examples.tex
View File

@@ -1,151 +1,8 @@
%\section{Attacker Model Gadget Examples}%
%\label{sub:Attacker Model Gadget Examples}
\begin{figure}[h]
\begin{lstlisting}[caption={Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}, label={lst:korg_drop}]
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}
\begin{figure}[h]
\begin{lstlisting}[caption={Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_replay}]
chan cn = [8] of { int, int, int };
// local memory for the gadget
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_replay() {
int b_0, b_1, b_2;
int i = 3;
CONSUME:
do
// read messages until the limit is passed
:: cn ? [b_0, b_1, b_2] -> atomic {
cn ? <b_0, b_1, b_2> -> gadget_mem ! b_0, b_1, b_2;
i--;
if
:: i == 0 -> goto REPLAY;
:: i != 0 -> goto CONSUME;
fi
}
od
REPLAY:
do
:: atomic {
// nondeterministically select a random value from the storage buffer
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0, b_1, b_2 -> gadget_mem ! b_0, b_1, b_2;
:: am == 0 ->
gadget_mem ? b_0, b_1, b_2 -> cn ! b_0, b_1, b_2;
break;
od
}
// doesn't need to use all messages on the channel
:: atomic {gadget_mem ? b_0, b_1, b_2; }
// once mem has no more messages, we're done
:: empty(gadget_mem) -> goto BREAK;
od
BREAK:
}
\end{lstlisting}
\end{figure}
\begin{figure}[h]
\begin{lstlisting}[caption={Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_reordering}]
chan cn = [8] of { int, int, int };
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_reordering() priority 255 {
byte b_0, b_1, b_2, blocker;
int i = 3;
INIT:
do
// arbitrarily choose a message to start consuming on
:: {
blocker = len(cn);
do
:: b != len(c) -> goto INIT;
od
}
:: goto CONSUME;
od
CONSUME:
do
// consume messages with high priority
:: c ? [b_0] -> atomic {
c ? b_0 -> gadget_mem ! b_0;
i--;
if
:: i == 0 -> goto REPLAY;
:: i != 0 -> goto CONSUME;
fi
}
od
REPLAY:
do
// replay messages back onto the channel, also with priority
:: atomic {
int am;
select(am : 0 .. len(gadget_mem)-1);
do
:: am != 0 ->
am = am-1;
gadget_mem ? b_0 -> attacker_mem_0 ! b_0;
:: am == 0 ->
gadget_mem ? b_0 -> c ! b_0;
break;
od
}
:: atomic { empty(gadget_mem) -> goto BREAK; }
od
BREAK:
}
\end{lstlisting}
\end{figure}
\begin{figure}[h]
\begin{lstlisting}[caption={Example I/O file targetting channel "cn"}, label={lst:io-file}]
cn:
I:
O:1-1-1, 1-2-3, 3-4-5
\end{lstlisting}
\begin{lstlisting}[caption={Example gadget synthesized from an I/O file targetting the channel "cn"}, label={lst:io-file-synth}]
chan cn = [8] of { int, int, int };
active proctype daisy() {
INIT:
do
:: cn ! 1,1,1;
:: cn ! 1,2,3;
:: cn ! 3,4,5;
:: goto RECOVERY;
od
RECOVERY:
}
\end{lstlisting}
\end{figure}

4
sections/proofs.tex
View File

@@ -74,7 +74,6 @@ In both structures, a run is an infinite sequence of states connected by transit
\end{itemize}
An accepting run in the \ba visits states in \( F \) infinitely often. Similarly, an accepting run in the Process visits states labeled with \( p \) infinitely often. Since \( F = \{ s \in S \mid p \in L(s) \} \), the acceptance conditions are preserved under the mappings.
\end{proof}
\begin{definition}[Threat Model]
@@ -104,10 +103,11 @@ A threat model is a tuple \( (P, (Q_i)_{i=0}^m, \phi) \) where:
\[
\left(BA_{P} \mid \mid BA_{\text{Daisy}(Q_0)} \mid \mid \ldots \mid \mid BA_{\text{Daisy}(Q_m)}\right) \subseteq BA_{\phi}
\]
Where rendezvous composition for I/O \ba is precise the same as for I/O Kripke Automata; that is, input and output transitions are matched. It's easy to see these composition operations are equivalent.
\end{proof}
\begin{theorem}
Checking whether there exists an attacker for a given threat model, the R-$\exists$ASP problem as proposed in \cite{Hippel2022_anonym}, is PSPACE-complete.
Checking whether there exists an attacker for a given threat model, the R-$\exists$ASP problem as proposed in \cite{Hippel2022_anonym}, is in PSPACE.
\end{theorem}
\begin{proof}

3
sections/related_work.tex Normal file
View File

@@ -0,0 +1,3 @@
\textbf{Similar Tools}. Several formal methods tools reason about attackers on secure protocols, primarily in the cryptographic context: ProVerif, VerifPal, Tamarin, and Scyther are \textit{Symbolic} and abstract away cryptographic primitives as terms \cite{Kobeissi_Nicolas_Tiwari, Proverif, Tamarin, Cremers}, while CryptoVerif and EasyCrypt are \textit{computational} and reason about game-based cryptographic security proofs \cite{Blanchet_Jacomme, Pereira}. For a general overview, see \cite{ParnoSOK, Basin_Cremers_Meadows_2018}. Before \korg, model checker-based approaches for reasoning about secure protocols have typically employed \spin or TLA+ and only reasoned about correctness \cite{Khan_Mukund_Suresh_2005, Clarke_Wang, wayne_adversaries, Narayana_Chen_Zhao_Chen_Fu_Zhou_2006, Delzanno_Tatarek_Traverso_2014}.
\textbf{Reasoning About Channels}. There is a long history of using formal methods tools ad-hoc to reason about on-channel attackers, particularly in the context of Byzantine protocols \cite{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson, Castro_Liskov_2002, Delzanno_Tatarek_Traverso_2014}. Formal methods tools have also been applied to reason about message tampering \cite{Henda}, delays \cite{Ginesin}, and congestion control \cite{TCPwn}.