This commit is contained in:
JakeGinesin
2024-11-18 07:15:00 -05:00
parent 762d8f6566
commit 28235ca697
15 changed files with 1420 additions and 902 deletions

File diff suppressed because it is too large Load Diff

View File

@@ -20,20 +20,34 @@
\@writefile{lol}{\contentsline {lstlisting}{\numberline {1}Example \textsc {Promela}\xspace model of peers communicating over a channel}{2}{}\protected@file@percent } \@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 } \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {II-D}}Usage}{2}{}\protected@file@percent }
\newlabel{sub:Usage}{{\mbox {II-D}}{2}{}{}{}} \newlabel{sub:Usage}{{\mbox {II-D}}{2}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {III}Attacker Models}{2}{}\protected@file@percent } \newlabel{lst:prod-consume}{{2}{2}{}{}{}}
\newlabel{sec:usage_attacker_models}{{III}{2}{}{}{}} \@writefile{lol}{\contentsline {lstlisting}{\numberline {2}Example \textsc {Promela}\xspace model with four producers and one consumer.}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Dropping Attacker Model}{2}{}\protected@file@percent } \newlabel{lst:korg-shell}{{\mbox {II-D}}{2}{}{}{}}
\newlabel{sub:Dropping Attacker}{{\mbox {III-A}}{2}{}{}{}} \newlabel{trace}{{\mbox {II-D}}{2}{}{}{}}
\newlabel{lst:korg_drop}{{2}{3}{}{}{}} \citation{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016,Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson,Ongaro}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {2}Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}{3}{}\protected@file@percent } \citation{Ongaro}
\citation{Cluzel_Georgiou_Moy_Zeller_2021,Smith_1997,Pacheco2022}
\citation{Pacheco2022}
\citation{Pacheco2022,Hippel2022}
\citation{rfc9260}
\citation{Pacheco2022}
\citation{Pacheco2022}
\@writefile{toc}{\contentsline {section}{\numberline {III}Attacker Models}{3}{}\protected@file@percent }
\newlabel{sec:usage_attacker_models}{{III}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Dropping Attacker Model}{3}{}\protected@file@percent }
\newlabel{sub:Dropping Attacker}{{\mbox {III-A}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Replaying Attacker Model}{3}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Replaying Attacker Model}{3}{}\protected@file@percent }
\newlabel{sub:Replay Attacker}{{\mbox {III-B}}{3}{}{}{}} \newlabel{sub:Replay Attacker}{{\mbox {III-B}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-C}}Rearranging Attacker Model}{3}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-C}}Reordering Attacker Model}{3}{}\protected@file@percent }
\newlabel{sub:Rearrange Attacker}{{\mbox {III-C}}{3}{}{}{}} \newlabel{sub:reordering Attacker}{{\mbox {III-C}}{3}{}{}{}}
\newlabel{lst:korg_replay}{{3}{3}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {3}Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-D}}Custom Attacker Models}{3}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-D}}Custom Attacker Models}{3}{}\protected@file@percent }
\newlabel{sub:Custom Attacker Models}{{\mbox {III-D}}{3}{}{}{}} \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}}Raft}{3}{}\protected@file@percent }
\newlabel{sub:Raft}{{\mbox {IV-A}}{3}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-B}}TCP}{3}{}\protected@file@percent }
\newlabel{sub:TCP}{{\mbox {IV-B}}{3}{}{}{}}
\bibstyle{IEEEtran} \bibstyle{IEEEtran}
\bibdata{main} \bibdata{main}
\bibcite{Lamport_1994}{1} \bibcite{Lamport_1994}{1}
@@ -45,23 +59,16 @@
\bibcite{Blanchet_Jacomme}{7} \bibcite{Blanchet_Jacomme}{7}
\bibcite{Basin_Linker_Sasse}{8} \bibcite{Basin_Linker_Sasse}{8}
\bibcite{Hippel2022}{9} \bibcite{Hippel2022}{9}
\bibcite{Vardi_Wolper_1986}{10} \bibcite{Kozen_1977}{10}
\bibcite{clarke2000model}{11} \bibcite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}{11}
\bibcite{Kozen_1977}{12} \bibcite{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}{12}
\newlabel{lst:korg_rearrange}{{4}{4}{}{}{}} \bibcite{Ongaro}{13}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {4}Example rearrange attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{4}{}\protected@file@percent } \bibcite{Cluzel_Georgiou_Moy_Zeller_2021}{14}
\newlabel{lst:io-file}{{5}{4}{}{}{}} \bibcite{Smith_1997}{15}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {5}Example I/O file targetting channel "cn"}{4}{}\protected@file@percent } \bibcite{Pacheco2022}{16}
\newlabel{lst:io-file-synth}{{6}{4}{}{}{}} \bibcite{rfc9260}{17}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {6}Example gadget synthesized from an I/O file targetting the channel "cn"}{4}{}\protected@file@percent } \newlabel{res:tcp-table}{{\mbox {IV-B}}{4}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {IV}Case Studies}{4}{}\protected@file@percent } \@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Automatically discovered attacks against the gold, canonical (labeled "expert"), and revised TCP models for $\phi _1$ through $\phi _4$. "x" indicates an attack was discovered, and no "x" indicates \textsc {Korg}\xspace proved the absence of an attack via an exhaustive search. Full attack traces are available in the artifact.}}{4}{}\protected@file@percent }
\newlabel{sec:case_studies}{{IV}{4}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-A}}SCTP}{4}{}\protected@file@percent }
\newlabel{sub:SCTP}{{\mbox {IV-A}}{4}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-B}}TCP}{4}{}\protected@file@percent }
\newlabel{sub:TCP}{{\mbox {IV-B}}{4}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-C}}DCCP}{4}{}\protected@file@percent }
\newlabel{sub:DCCP}{{\mbox {IV-C}}{4}{}{}{}}
\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusion}{4}{}\protected@file@percent } \@writefile{toc}{\contentsline {section}{\numberline {V}Conclusion}{4}{}\protected@file@percent }
\newlabel{sec:conclusion}{{V}{4}{}{}{}} \newlabel{sec:conclusion}{{V}{4}{}{}{}}
\@writefile{toc}{\contentsline {section}{References}{4}{}\protected@file@percent } \@writefile{toc}{\contentsline {section}{References}{4}{}\protected@file@percent }
@@ -69,8 +76,22 @@
\newlabel{sec:Appendix}{{VI}{4}{}{}{}} \newlabel{sec:Appendix}{{VI}{4}{}{}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-A}}Full Korg Soundness and Completeness Proofs}{4}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-A}}Full Korg Soundness and Completeness Proofs}{4}{}\protected@file@percent }
\newlabel{sub:korg_proofs}{{\mbox {VI-A}}{4}{}{}{}} \newlabel{sub:korg_proofs}{{\mbox {VI-A}}{4}{}{}{}}
\citation{Holzmann_1997}
\citation{Kozen_1977}
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-B}}Preventing Korg Livelocks}{5}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-B}}Preventing Korg Livelocks}{5}{}\protected@file@percent }
\newlabel{sub:Preventing Korg Livelocks}{{\mbox {VI-B}}{5}{}{}{}} \newlabel{sub:Preventing Korg Livelocks}{{\mbox {VI-B}}{5}{}{}{}}
\newlabel{lst:drop_passer}{{7}{5}{}{}{}} \newlabel{lst:drop_passer}{{3}{5}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {7}Example dropping attacker model gadget with message skipping}{5}{}\protected@file@percent } \@writefile{lol}{\contentsline {lstlisting}{\numberline {3}Example dropping attacker model gadget with message skipping}{5}{}\protected@file@percent }
\gdef \@abspage@last{5} \@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-C}}Attacker Model Gadget Examples}{6}{}\protected@file@percent }
\newlabel{sub:Attacker Model Gadget Examples}{{\mbox {VI-C}}{6}{}{}{}}
\newlabel{lst:korg_drop}{{4}{6}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {4}Example dropping attacker model gadget with drop limit of 3, targetting channel "cn"}{6}{}\protected@file@percent }
\newlabel{lst:korg_replay}{{5}{6}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {5}Example replay attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{6}{}\protected@file@percent }
\newlabel{lst:korg_reordering}{{6}{7}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {6}Example reordering attacker model gadget with the selected replay limit as 3, targetting channel "cn"}{7}{}\protected@file@percent }
\newlabel{lst:io-file}{{7}{7}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {7}Example I/O file targetting channel "cn"}{7}{}\protected@file@percent }
\newlabel{lst:io-file-synth}{{8}{7}{}{}{}}
\@writefile{lol}{\contentsline {lstlisting}{\numberline {8}Example gadget synthesized from an I/O file targetting the channel "cn"}{7}{}\protected@file@percent }
\gdef \@abspage@last{7}

View File

@@ -38,7 +38,7 @@ E.~M. Clarke and Q.~Wang, ``\BIBforeignlanguage{en}{25 years of model
\bibitem{Basin_Cremers_Dreier_Sasse_2022} \bibitem{Basin_Cremers_Dreier_Sasse_2022}
D.~Basin, C.~Cremers, J.~Dreier, and R.~Sasse, D.~Basin, C.~Cremers, J.~Dreier, and R.~Sasse,
``\BIBforeignlanguage{en}{Tamarin: Verification of large-scale, real-world, ``\BIBforeignlanguage{en}{Tamarin: Verification of large-scale, real-world,
cryptographic protocols},'' \emph{\BIBforeignlanguage{en}{IEEE Security & cryptographic protocols},'' \emph{\BIBforeignlanguage{en}{IEEE Security \&
Privacy}}, vol.~20, no.~3, p. 2432, May 2022. Privacy}}, vol.~20, no.~3, p. 2432, May 2022.
\bibitem{Blanchet_Smyth_Cheval_Sylvestre} \bibitem{Blanchet_Smyth_Cheval_Sylvestre}
@@ -66,18 +66,6 @@ M.~von Hippel, C.~Vick, S.~Tripakis, and C.~Nita-Rotaru, ``Automated attacker
\url{http://arxiv.org/abs/2004.01220} \url{http://arxiv.org/abs/2004.01220}
\BIBentrySTDinterwordspacing \BIBentrySTDinterwordspacing
\bibitem{Vardi_Wolper_1986}
\BIBentryALTinterwordspacing
M.~Y. Vardi and P.~Wolper, ``\BIBforeignlanguage{English}{An automata-theoretic
approach to automatic program verification}.''\hskip 1em plus 0.5em minus
0.4em\relax IEEE Computer Society, 1986. [Online]. Available:
\url{https://orbi.uliege.be/handle/2268/116609}
\BIBentrySTDinterwordspacing
\bibitem{clarke2000model}
E.~M. Clarke, O.~Grumberg, and D.~A. Peled, \emph{Model Checking}.\hskip 1em
plus 0.5em minus 0.4em\relax Cambridge, MA: MIT Press, 2000.
\bibitem{Kozen_1977} \bibitem{Kozen_1977}
\BIBentryALTinterwordspacing \BIBentryALTinterwordspacing
D.~Kozen, ``\BIBforeignlanguage{en}{Lower bounds for natural proof systems},'' D.~Kozen, ``\BIBforeignlanguage{en}{Lower bounds for natural proof systems},''
@@ -87,4 +75,61 @@ D.~Kozen, ``\BIBforeignlanguage{en}{Lower bounds for natural proof systems},''
\url{http://ieeexplore.ieee.org/document/4567949/} \url{http://ieeexplore.ieee.org/document/4567949/}
\BIBentrySTDinterwordspacing \BIBentrySTDinterwordspacing
\bibitem{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016}
\BIBentryALTinterwordspacing
D.~Woos, J.~R. Wilcox, S.~Anton, Z.~Tatlock, M.~D. Ernst, and T.~Anderson,
``\BIBforeignlanguage{en}{Planning for change in a formal verification of the
raft consensus protocol},'' in \emph{\BIBforeignlanguage{en}{Proceedings of
the 5th ACM SIGPLAN Conference on Certified Programs and Proofs}}.\hskip 1em
plus 0.5em minus 0.4em\relax St. Petersburg FL USA: ACM, Jan. 2016, p.
154165. [Online]. Available:
\url{https://dl.acm.org/doi/10.1145/2854065.2854081}
\BIBentrySTDinterwordspacing
\bibitem{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}
J.~R. Wilcox, D.~Woos, P.~Panchekha, Z.~Tatlock, X.~Wang, M.~D. Ernst, and
T.~Anderson, ``\BIBforeignlanguage{en}{Verdi: A framework for implementing
and formally verifying distributed systems}.''
\bibitem{Ongaro}
D.~Ongaro, ``\BIBforeignlanguage{en}{Consensus: Bridging theory and
practice}.''
\bibitem{Cluzel_Georgiou_Moy_Zeller_2021}
\BIBentryALTinterwordspacing
G.~Cluzel, K.~Georgiou, Y.~Moy, and C.~Zeller,
``\BIBforeignlanguage{en}{Layered formal verification of a tcp stack},'' in
\emph{\BIBforeignlanguage{en}{2021 IEEE Secure Development Conference
(SecDev)}}.\hskip 1em plus 0.5em minus 0.4em\relax Atlanta, GA, USA: IEEE,
Oct. 2021, p. 8693. [Online]. Available:
\url{https://ieeexplore.ieee.org/document/9652642/}
\BIBentrySTDinterwordspacing
\bibitem{Smith_1997}
\BIBentryALTinterwordspacing
M.~A.~S. Smith, ``\BIBforeignlanguage{eng}{Formal verification of tcp and
t/tcp},'' Thesis, Massachusetts Institute of Technology, 1997, accepted:
2008-09-03T18:09:43Z. [Online]. Available:
\url{https://dspace.mit.edu/handle/1721.1/42779}
\BIBentrySTDinterwordspacing
\bibitem{Pacheco2022}
\BIBentryALTinterwordspacing
M.~L. Pacheco, M.~V. Hippel, B.~Weintraub, D.~Goldwasser, and C.~Nita-Rotaru,
``\BIBforeignlanguage{en}{Automated attack synthesis by extracting finite
state machines from protocol specification documents},'' in
\emph{\BIBforeignlanguage{en}{2022 IEEE Symposium on Security and Privacy
(SP)}}.\hskip 1em plus 0.5em minus 0.4em\relax San Francisco, CA, USA: IEEE,
May 2022, p. 5168. [Online]. Available:
\url{https://ieeexplore.ieee.org/document/9833673/}
\BIBentrySTDinterwordspacing
\bibitem{rfc9260}
\BIBentryALTinterwordspacing
M.~Tüxen, R.~Stewart, K.~Nielsen, R.~Jesup, and S.~Loreto, ``{Stream Control
Transmission Protocol (SCTP) Specification Errata and Issues},'' Request for
Comments, June 2022. [Online]. Available:
\url{https://www.rfc-editor.org/rfc/rfc9260}
\BIBentrySTDinterwordspacing
\end{thebibliography} \end{thebibliography}

View File

@@ -32,7 +32,7 @@ concurrent finite-state programs.}, publisher={IEEE Computer Society}, author={V
@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 logicians 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={872923}, 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 logicians 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={872923}, 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={2432}, 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={2432}, 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{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} }
@@ -44,4 +44,29 @@ concurrent finite-state programs.}, publisher={IEEE Computer Society}, author={V
@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 Apples 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{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 Apples 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} } @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} }
@inproceedings{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016, address={St. Petersburg FL USA}, title={Planning for change in a formal verification of the raft consensus protocol}, ISBN={978-1-4503-4127-1}, url={https://dl.acm.org/doi/10.1145/2854065.2854081}, DOI={10.1145/2854065.2854081}, abstractNote={We present the first formal verification of state machine safety for the Raft consensus protocol, a critical component of many distributed systems. We connected our proof to previous work to establish an end-to-end guarantee that our implementation provides linearizable state machine replication. This proof required iteratively discovering and proving 90 system invariants. Our verified implementation is extracted to OCaml and runs on real networks.}, booktitle={Proceedings of the 5th ACM SIGPLAN Conference on Certified Programs and Proofs}, publisher={ACM}, author={Woos, Doug and Wilcox, James R. and Anton, Steve and Tatlock, Zachary and Ernst, Michael D. and Anderson, Thomas}, year={2016}, month=jan, pages={154165}, language={en} }
@article{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson, title={Verdi: A Framework for Implementing and Formally Verifying Distributed Systems}, abstractNote={Distributed systems are difficult to implement correctly because they must handle both concurrency and failures: machines may crash at arbitrary points and networks may reorder, drop, or duplicate packets. Further, their behavior is often too complex to permit exhaustive testing. Bugs in these systems have led to the loss of critical data and unacceptable service outages.}, author={Wilcox, James R and Woos, Doug and Panchekha, Pavel and Tatlock, Zachary and Wang, Xi and Ernst, Michael D and Anderson, Thomas}, language={en} }
@article{Ongaro, title={Consensus: Bridging Theory and Practice}, author={Ongaro, Diego}, language={en} }
@inproceedings{Cluzel_Georgiou_Moy_Zeller_2021, address={Atlanta, GA, USA}, title={Layered Formal Verification of a TCP Stack}, rights={https://doi.org/10.15223/policy-009}, ISBN={978-1-66543-170-5}, url={https://ieeexplore.ieee.org/document/9652642/}, DOI={10.1109/SecDev51306.2021.00028}, abstractNote={The Transmission Control Protocol (TCP) at the heart of TCP/IP protocol stacks is a critical part of our current digital infrastructure. In this article, we show how an existing professional-grade open source embedded TCP/IP library can benefit from a formally verified TCP reimplementation. Our approach is to apply formal verification to the TCP layer only, relying on validated models of the lower layers on which it depends.}, booktitle={2021 IEEE Secure Development Conference (SecDev)}, publisher={IEEE}, author={Cluzel, Guillaume and Georgiou, Kyriakos and Moy, Yannick and Zeller, Clément}, year={2021}, month=oct, pages={8693}, language={en} }
@phdthesis{Smith_1997, type={Thesis}, title={Formal verification of TCP and T/TCP}, rights={M.I.T. theses are protected by copyright. They may be viewed from this source for any purpose, but reproduction or distribution in any format is prohibited without written permission. See provided URL for inquiries about permission.}, url={https://dspace.mit.edu/handle/1721.1/42779}, abstractNote={Thesis (Ph. D.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1997.}, note={Accepted: 2008-09-03T18:09:43Z}, school={Massachusetts Institute of Technology}, author={Smith, Mark Anthony Shawn}, year={1997}, language={eng} }
@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={5168}, language={en} }
@misc{rfc9260,
author = {M. Tüxen and R. Stewart and K. Nielsen and R. Jesup and S. Loreto},
title = {{Stream Control Transmission Protocol (SCTP) Specification Errata and Issues}},
howpublished = {Request for Comments},
number = {9260},
year = {2022},
month = {June},
publisher = {RFC Editor},
url = {https://www.rfc-editor.org/rfc/rfc9260},
doi = {10.17487/RFC9260}
}

View File

@@ -8,6 +8,14 @@ Reallocated singl_function (elt_size=8) to 100 items from 50.
Reallocated wiz_functions (elt_size=8) to 6000 items from 3000. Reallocated wiz_functions (elt_size=8) to 6000 items from 3000.
Reallocated singl_function (elt_size=8) to 100 items from 50. Reallocated singl_function (elt_size=8) to 100 items from 50.
Database file #1: main.bib Database file #1: main.bib
Repeated entry---line 49 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
Repeated entry---line 61 of file main.bib
: @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={5168}, language={en} }
I'm skipping whatever remains of this entry
-- IEEEtran.bst version 1.14 (2015/08/26) by Michael Shell. -- IEEEtran.bst version 1.14 (2015/08/26) by Michael Shell.
-- http://www.michaelshell.org/tex/ieeetran/bibtex/ -- http://www.michaelshell.org/tex/ieeetran/bibtex/
-- See the "IEEEtran_bst_HOWTO.pdf" manual for usage information. -- See the "IEEEtran_bst_HOWTO.pdf" manual for usage information.
@@ -22,48 +30,51 @@ Warning--empty year in Blanchet_Jacomme
Warning--empty journal in Basin_Linker_Sasse Warning--empty journal in Basin_Linker_Sasse
Warning--empty year in Basin_Linker_Sasse Warning--empty year in Basin_Linker_Sasse
Warning--empty journal in Hippel2022 Warning--empty journal in Hippel2022
Warning--empty booktitle in Vardi_Wolper_1986 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
Done. Done.
You've used 12 entries, You've used 17 entries,
4087 wiz_defined-function locations, 4087 wiz_defined-function locations,
897 strings with 9252 characters, 935 strings with 10819 characters,
and the built_in function-call counts, 6235 in all, are: and the built_in function-call counts, 9675 in all, are:
= -- 497 = -- 780
> -- 129 > -- 228
< -- 11 < -- 14
+ -- 60 + -- 108
- -- 30 - -- 54
* -- 350 * -- 546
:= -- 993 := -- 1511
add.period$ -- 26 add.period$ -- 38
call.type$ -- 12 call.type$ -- 17
change.case$ -- 12 change.case$ -- 19
chr.to.int$ -- 0 chr.to.int$ -- 0
cite$ -- 24 cite$ -- 32
duplicate$ -- 541 duplicate$ -- 827
empty$ -- 538 empty$ -- 811
format.name$ -- 39 format.name$ -- 66
if$ -- 1408 if$ -- 2203
int.to.chr$ -- 0 int.to.chr$ -- 0
int.to.str$ -- 12 int.to.str$ -- 17
missing$ -- 96 missing$ -- 158
newline$ -- 65 newline$ -- 88
num.names$ -- 12 num.names$ -- 17
pop$ -- 257 pop$ -- 417
preamble$ -- 1 preamble$ -- 1
purify$ -- 0 purify$ -- 0
quote$ -- 2 quote$ -- 2
skip$ -- 476 skip$ -- 729
stack$ -- 0 stack$ -- 0
substring$ -- 81 substring$ -- 135
swap$ -- 367 swap$ -- 582
text.length$ -- 11 text.length$ -- 14
text.prefix$ -- 0 text.prefix$ -- 0
top$ -- 5 top$ -- 5
type$ -- 12 type$ -- 17
warning$ -- 12 warning$ -- 15
while$ -- 16 while$ -- 24
width$ -- 14 width$ -- 19
write$ -- 126 write$ -- 181
(There were 12 warnings) (There were 2 error messages)

View File

@@ -97,6 +97,8 @@ INPUT /usr/share/texmf-dist/tex/latex/amscls/amsthm.sty
INPUT /usr/share/texmf-dist/tex/latex/amscls/amsthm.sty INPUT /usr/share/texmf-dist/tex/latex/amscls/amsthm.sty
INPUT /usr/share/texmf-dist/tex/latex/tools/xspace.sty INPUT /usr/share/texmf-dist/tex/latex/tools/xspace.sty
INPUT /usr/share/texmf-dist/tex/latex/tools/xspace.sty INPUT /usr/share/texmf-dist/tex/latex/tools/xspace.sty
INPUT /usr/share/texmf-dist/tex/latex/tools/array.sty
INPUT /usr/share/texmf-dist/tex/latex/tools/array.sty
INPUT /usr/share/texmf-dist/tex/latex/listings/listings.sty INPUT /usr/share/texmf-dist/tex/latex/listings/listings.sty
INPUT /usr/share/texmf-dist/tex/latex/listings/listings.sty INPUT /usr/share/texmf-dist/tex/latex/listings/listings.sty
INPUT /usr/share/texmf-dist/tex/latex/listings/lstpatch.sty INPUT /usr/share/texmf-dist/tex/latex/listings/lstpatch.sty
@@ -201,20 +203,41 @@ 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/courier/pcrr7t.tfm INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr7t.tfm
INPUT ./sections/attacker_models.tex INPUT /usr/share/texmf-dist/tex/latex/psnfss/ts1pcr.fd
INPUT ./sections/attacker_models.tex INPUT /usr/share/texmf-dist/tex/latex/psnfss/ts1pcr.fd
INPUT ./sections/attacker_models.tex INPUT /usr/share/texmf-dist/tex/latex/psnfss/ts1pcr.fd
INPUT ./sections/attacker_models.tex INPUT /usr/share/texmf-dist/fonts/tfm/adobe/courier/pcrr8c.tfm
INPUT ./sections/attacker_models.tex
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmb7t.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/tfm/adobe/times/ptmb8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/courier/pcrr7t.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/tfm/adobe/courier/pcrr8r.tfm
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/courier/pcrr8c.vf
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/case_studies.tex
INPUT ./sections/case_studies.tex INPUT ./sections/case_studies.tex
INPUT ./sections/case_studies.tex INPUT ./sections/case_studies.tex
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/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 ./sections/conclusion.tex INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex INPUT ./sections/conclusion.tex
INPUT ./sections/conclusion.tex INPUT ./sections/conclusion.tex
@@ -228,10 +251,24 @@ INPUT ./sections/appendix.tex
INPUT ./sections/appendix.tex 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/ptmr7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmr8r.tfm
INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmri7t.vf INPUT /usr/share/texmf-dist/fonts/vf/adobe/times/ptmri7t.vf
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmri8r.tfm INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmri8r.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmrc7t.tfm
INPUT /usr/share/texmf-dist/fonts/tfm/adobe/times/ptmrc7t.tfm
INPUT ./main.aux INPUT ./main.aux
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi5.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi8.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr5.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.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/public/amsfonts/cm/cmsy10.pfb
INPUT /usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb
INPUT /usr/share/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb INPUT /usr/share/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb
INPUT /usr/share/texmf-dist/fonts/type1/urw/times/utmb8a.pfb INPUT /usr/share/texmf-dist/fonts/type1/urw/times/utmb8a.pfb
INPUT /usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb INPUT /usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb

315
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) 11 NOV 2024 14:24 This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/Arch Linux) (preloaded format=pdflatex 2024.7.2) 18 NOV 2024 03:47
entering extended mode entering extended mode
restricted \write18 enabled. restricted \write18 enabled.
%&-line parsing enabled. %&-line parsing enabled.
@@ -273,28 +273,40 @@ Package: amsthm 2020/05/29 v2.20.6
(/usr/share/texmf-dist/tex/latex/tools/xspace.sty (/usr/share/texmf-dist/tex/latex/tools/xspace.sty
Package: xspace 2014/10/28 v1.13 Space after command names (DPC,MH) Package: xspace 2014/10/28 v1.13 Space after command names (DPC,MH)
) )
(/usr/share/texmf-dist/tex/latex/tools/array.sty
Package: array 2023/10/16 v2.5g Tabular extension package (FMi)
\col@sep=\dimen175
\ar@mcellbox=\box55
\extrarowheight=\dimen176
\NC@list=\toks30
\extratabsurround=\skip59
\backup@length=\skip60
\ar@cellbox=\box56
)
\c@definition=\count285
(/usr/share/texmf-dist/tex/latex/listings/listings.sty (/usr/share/texmf-dist/tex/latex/listings/listings.sty
\lst@mode=\count285 \lst@mode=\count286
\lst@gtempboxa=\box55 \lst@gtempboxa=\box57
\lst@token=\toks30 \lst@token=\toks31
\lst@length=\count286 \lst@length=\count287
\lst@currlwidth=\dimen175 \lst@currlwidth=\dimen177
\lst@column=\count287 \lst@column=\count288
\lst@pos=\count288 \lst@pos=\count289
\lst@lostspace=\dimen176 \lst@lostspace=\dimen178
\lst@width=\dimen177 \lst@width=\dimen179
\lst@newlines=\count289 \lst@newlines=\count290
\lst@lineno=\count290 \lst@lineno=\count291
\lst@maxwidth=\dimen178 \lst@maxwidth=\dimen180
(/usr/share/texmf-dist/tex/latex/listings/lstpatch.sty (/usr/share/texmf-dist/tex/latex/listings/lstpatch.sty
File: lstpatch.sty 2024/02/21 1.10 (Carsten Heinz) File: lstpatch.sty 2024/02/21 1.10 (Carsten Heinz)
) )
(/usr/share/texmf-dist/tex/latex/listings/lstmisc.sty (/usr/share/texmf-dist/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2024/02/21 1.10 (Carsten Heinz) File: lstmisc.sty 2024/02/21 1.10 (Carsten Heinz)
\c@lstnumber=\count291 \c@lstnumber=\count292
\lst@skipnumbers=\count292 \lst@skipnumbers=\count293
\lst@framebox=\box56 \lst@framebox=\box58
) )
(/usr/share/texmf-dist/tex/latex/listings/listings.cfg (/usr/share/texmf-dist/tex/latex/listings/listings.cfg
File: listings.cfg 2024/02/21 1.10 listings configuration File: listings.cfg 2024/02/21 1.10 listings configuration
@@ -313,44 +325,44 @@ File: lstlang3.sty 2024/02/21 1.10 listings language file
(/usr/share/texmf-dist/tex/latex/listings/lstmisc.sty (/usr/share/texmf-dist/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2024/02/21 1.10 (Carsten Heinz) File: lstmisc.sty 2024/02/21 1.10 (Carsten Heinz)
) )
\c@theorem=\count293 \c@theorem=\count294
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def (/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
File: l3backend-pdftex.def 2024-02-20 L3 backend support: PDF output (pdfTeX) File: l3backend-pdftex.def 2024-02-20 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count294 \l__color_backend_stack_int=\count295
\l__pdf_internal_box=\box57 \l__pdf_internal_box=\box59
) (./main.aux) ) (./main.aux)
\openout1 = `main.aux'. \openout1 = `main.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 48. LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 48. LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 48. LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 48. LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 48. LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 48. LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 48. LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 52.
LaTeX Font Info: ... okay on input line 48. LaTeX Font Info: ... okay on input line 52.
-- Lines per column: 56 (exact). -- Lines per column: 56 (exact).
(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii (/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).] [Loading MPS to PDF converter (version 2006.09.02).]
\scratchcounter=\count295 \scratchcounter=\count296
\scratchdimen=\dimen179 \scratchdimen=\dimen181
\scratchbox=\box58 \scratchbox=\box60
\nofMPsegments=\count296 \nofMPsegments=\count297
\nofMParguments=\count297 \nofMParguments=\count298
\everyMPshowfont=\toks31 \everyMPshowfont=\toks32
\MPscratchCnt=\count298 \MPscratchCnt=\count299
\MPscratchDim=\dimen180 \MPscratchDim=\dimen182
\MPnumerator=\count299 \MPnumerator=\count300
\makeMPintoPDFobject=\count300 \makeMPintoPDFobject=\count301
\everyMPtoPDFconversion=\toks32 \everyMPtoPDFconversion=\toks33
) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty ) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf
Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4 Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
@@ -360,16 +372,16 @@ Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
e e
)) ))
\c@lstlisting=\count301 \c@lstlisting=\count302
(./sections/abstract.tex) (./sections/introduction.tex) (./sections/design.tex (./sections/abstract.tex) (./sections/introduction.tex) (./sections/design.tex
<assets/diagram3.png, id=1, 733.99219pt x 277.035pt> <assets/diagram3.png, id=1, 733.99219pt x 277.035pt>
File: assets/diagram3.png Graphic file (type png) File: assets/diagram3.png Graphic file (type png)
<use assets/diagram3.png> <use assets/diagram3.png>
Package pdftex.def Info: assets/diagram3.png used on input line 17. Package pdftex.def Info: assets/diagram3.png used on input line 11.
(pdftex.def) Requested size: 258.0pt x 97.37796pt. (pdftex.def) Requested size: 258.0pt x 97.37796pt.
Overfull \hbox (6.0pt too wide) in paragraph at lines 17--18 Overfull \hbox (6.0pt too wide) in paragraph at lines 11--12
[][] [][]
[] []
@@ -378,13 +390,13 @@ ts/enc/dvips/base/8r.enc}
<./assets/diagram3.png (PNG copy)>] <./assets/diagram3.png (PNG copy)>]
LaTeX Font Info: Trying to load font information for U+msa on input line 47. LaTeX Font Info: Trying to load font information for U+msa on input line 40.
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd (/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
File: umsa.fd 2013/01/14 v3.01 AMS symbols A 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 47. LaTeX Font Info: Trying to load font information for U+msb on input line 40.
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd (/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd
@@ -392,42 +404,40 @@ File: umsb.fd 2013/01/14 v3.01 AMS symbols B
) )
LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
(Font) using `OT1/ptm/m/sc' instead on input line 47. (Font) using `OT1/ptm/m/sc' instead on input line 40.
LaTeX Font Info: Trying to load font information for OT1+pcr on input line 8 LaTeX Font Info: Trying to load font information for OT1+pcr on input line 7
6. 8.
(/usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd (/usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr. File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
) )
LaTeX Font Info: Trying to load font information for TS1+pcr on input line 1
17.
LaTeX Warning: `h' float specifier changed to `ht'. (/usr/share/texmf-dist/tex/latex/psnfss/ts1pcr.fd
File: ts1pcr.fd 2001/06/04 font definitions for TS1/pcr.
) (./sections/attacker_models.tex ) [2])
(./sections/attacker_models.tex) (./sections/case_studies.tex
LaTeX Warning: `h' float specifier changed to `ht'. Underfull \hbox (badness 4144) in paragraph at lines 15--15
[]\OT1/pcr/m/n/10 SYN_RECEIVED \OT1/ptm/m/n/10 is even-tu-ally fol-lowed by
[2] []
LaTeX Warning: `h' float specifier changed to `ht'.
LaTeX Warning: `h' float specifier changed to `ht'. Underfull \hbox (badness 4144) in paragraph at lines 15--15
[]\OT1/pcr/m/n/10 SYN_RECEIVED \OT1/ptm/m/n/10 is even-tu-ally fol-lowed by
[3] []
LaTeX Warning: `h' float specifier changed to `ht'.
) (./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.
Underfull \vbox (badness 10000) has occurred while \output is active []
Underfull \hbox (badness 4144) in paragraph at lines 15--15
[]\OT1/pcr/m/n/7 SYN_RECEIVED \OT1/ptm/m/n/7 is even-tu-ally fol-lowed by
[]
Underfull \hbox (badness 4144) in paragraph at lines 15--15
[]\OT1/pcr/m/n/5 SYN_RECEIVED \OT1/ptm/m/n/5 is even-tu-ally fol-lowed by
[]
[3]) (./sections/conclusion.tex) (./main.bbl
** WARNING: IEEEtran.bst: No hyphenation pattern has been ** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for ** loaded for the language `en'. Using the pattern for
** the default language instead. ** the default language instead.
@@ -443,17 +453,55 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
** WARNING: IEEEtran.bst: No hyphenation pattern has been ** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for ** loaded for the language `en'. Using the pattern for
** the default language instead. ** the default language instead.
! Misplaced alignment tab character &. ** WARNING: IEEEtran.bst: No hyphenation pattern has been
<argument> IEEE Security & ** loaded for the language `en'. Using the pattern for
Privacy ** the default language instead.
l.42 Privacy}} ** WARNING: IEEEtran.bst: No hyphenation pattern has been
, vol.~20, no.~3, p. 2432, May 2022. ** loaded for the language `en'. Using the pattern for
I can't figure out why you would want to use a tab mark ** the default language instead.
here. If you just want an ampersand, the remedy is ** WARNING: IEEEtran.bst: No hyphenation pattern has been
simple: Just type `I\&' now. But if some right brace ** loaded for the language `en'. Using the pattern for
up above has ended a previous alignment prematurely, ** the default language instead.
you're probably due for more error messages, and you ** WARNING: IEEEtran.bst: No hyphenation pattern has been
might try typing `S' now just to see what is salvageable. ** 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 `eng'. Using the pattern for
** the default language instead.
Underfull \hbox (badness 1509) in paragraph at lines 110--115
\OT1/ptm/m/n/8 t/tcp,'' The-sis, Mas-sachusetts In-sti-tute of Tech-nol-ogy,
[]
** WARNING: IEEEtran.bst: No hyphenation pattern has been ** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for ** loaded for the language `en'. Using the pattern for
@@ -461,25 +509,46 @@ might try typing `S' now just to see what is salvageable.
** WARNING: IEEEtran.bst: No hyphenation pattern has been ** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `en'. Using the pattern for ** loaded for the language `en'. Using the pattern for
** the default language instead. ** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been ) (./sections/appendix.tex
** loaded for the language `en'. Using the pattern for Underfull \hbox (badness 3503) in paragraph at lines 17--19
** the default language instead. []\OT1/ptm/b/n/10 Definition 2 \OT1/ptm/m/n/10 (Pro-cess)\OT1/ptm/b/n/10 . []\O
** WARNING: IEEEtran.bst: No hyphenation pattern has been T1/ptm/m/it/10 A \OT1/ptm/m/n/10 Pro-cess \OT1/ptm/m/it/10 is a tu-ple $\OML/cm
** loaded for the language `en'. Using the pattern for m/m/it/10 P \OT1/cmr/m/n/10 =
** the default language instead. []
** WARNING: IEEEtran.bst: No hyphenation pattern has been
** loaded for the language `English'. Using the pattern for ! Missing } inserted.
** the default language instead. <inserted text>
** WARNING: IEEEtran.bst: No hyphenation pattern has been }
** loaded for the language `en'. Using the pattern for l.46 \end{itemize}
** the default language instead.
** WARNING: IEEEtran.bst: No hyphenation pattern has been I've inserted something that you may have forgotten.
** loaded for the language `en'. Using the pattern for (See the <inserted text> above.)
** the default language instead. With luck, this will get me unwedged. But if you
) (./sections/appendix.tex [4] really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
[4]
Underfull \hbox (badness 2165) in paragraph at lines 65--66
[]\OT1/ptm/m/n/10 In the Pro-cess: $\OML/cmm/m/it/10 s[]; s[]; s[]; []$ \OT1/pt
m/m/n/10 with $\OML/cmm/m/it/10 s[] \OT1/cmr/m/n/10 = \OML/cmm/m/it/10 s[]$ \OT
1/ptm/m/n/10 and
[]
LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined LaTeX Font Warning: Font shape `OT1/ptm/m/scit' undefined
(Font) using `OT1/ptm/m/sc' instead on input line 15. (Font) using `OT1/ptm/m/sc' instead on input line 83.
Underfull \hbox (badness 1715) in paragraph at lines 90--92
\OT1/ptm/m/n/10 via the pre-vi-ous the-o-rem we can con-struct B[]uchi Au-
[]
[5]
LaTeX Warning: `h' float specifier changed to `ht'.
LaTeX Warning: `h' float specifier changed to `ht'.
LaTeX Warning: `h' float specifier changed to `ht'. LaTeX Warning: `h' float specifier changed to `ht'.
@@ -496,29 +565,37 @@ Before submitting the final camera ready copy, remember to:
uses only Type 1 fonts and that every step in the generation uses only Type 1 fonts and that every step in the generation
process uses the appropriate paper size. process uses the appropriate paper size.
[5] (./main.aux) [6] [7] (./main.aux)
*********** ***********
LaTeX2e <2023-11-01> patch level 1 LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-02-20> L3 programming layer <2024-02-20>
*********** ***********
) )
Here is how much of TeX's memory you used: Here is how much of TeX's memory you used:
6386 strings out of 476076 6592 strings out of 476076
94893 string characters out of 5793776 97758 string characters out of 5793776
2180187 words of memory out of 5000000 2189187 words of memory out of 5000000
28403 multiletter control sequences out of 15000+600000 28594 multiletter control sequences out of 15000+600000
597323 words of font info for 103 fonts, out of 8000000 for 9000 603817 words of font info for 122 fonts, out of 8000000 for 9000
14 hyphenation exceptions out of 8191 14 hyphenation exceptions out of 8191
57i,8n,65p,1155b,1257s stack positions out of 10000i,1000n,20000p,200000b,200000s 57i,11n,65p,1153b,1636s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/ </usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb></usr/share/
texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-dist/fonts/type texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/texmf-dist/fon
1/urw/times/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb ts/type1/public/amsfonts/cm/cmmi5.pfb></usr/share/texmf-dist/fonts/type1/public
></usr/share/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-dist /amsfonts/cm/cmmi7.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cm
/fonts/type1/urw/times/utmri8a.pfb> mi8.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/s
Output written on ./main.pdf (5 pages, 164937 bytes). hare/texmf-dist/fonts/type1/public/amsfonts/cm/cmr5.pfb></usr/share/texmf-dist/
fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/share/texmf-dist/fonts/type1/publ
ic/amsfonts/cm/cmr7.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/c
msy10.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb></usr
/share/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-dist/fon
ts/type1/urw/times/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmb
i8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></usr/share/tex
mf-dist/fonts/type1/urw/times/utmri8a.pfb>
Output written on ./main.pdf (7 pages, 273739 bytes).
PDF statistics: PDF statistics:
52 PDF objects out of 1000 (max. 8388607) 110 PDF objects out of 1000 (max. 8388607)
31 compressed objects within 1 object stream 67 compressed objects within 1 object stream
0 named destinations out of 1000 (max. 500000) 0 named destinations out of 1000 (max. 500000)
6 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

Binary file not shown.

Binary file not shown.

View File

@@ -9,8 +9,11 @@
\usepackage{xcolor} \usepackage{xcolor}
\usepackage{amsmath, amsthm} \usepackage{amsmath, amsthm}
\usepackage{xspace} \usepackage{xspace}
\usepackage{array}
%\usepackage{csvsimple} %\usepackage{csvsimple}
\newtheorem{definition}{Definition}
\newcommand{\cnr}[1]{\textcolor{blue}{Cristina says: {#1}}} \newcommand{\cnr}[1]{\textcolor{blue}{Cristina says: {#1}}}
\newcommand{\mvh}[1]{\textcolor{magenta}{Max says: {#1}}} \newcommand{\mvh}[1]{\textcolor{magenta}{Max says: {#1}}}
\newcommand{\jg}[1]{\textcolor{purple}{Jake says: {#1}}} \newcommand{\jg}[1]{\textcolor{purple}{Jake says: {#1}}}
@@ -38,6 +41,7 @@
belowskip=10pt belowskip=10pt
} }
\newcommand{\ba}{B\"uchi Automata\xspace}
% theorem stuff: % theorem stuff:
\theoremstyle{plain} \theoremstyle{plain}

View File

@@ -1,23 +1,101 @@
\subsection{Full Korg Soundness and Completeness Proofs}% \subsection{Full Korg Soundness and Completeness Proofs}%
\label{sub:korg_proofs} \label{sub:korg_proofs}
\begin{definition}[\ba]
A \ba is a tuple \( B = (Q, \Sigma, \delta, Q_0, F) \) where:
\begin{itemize}
\item \( Q \) is a finite set of states,
\item \( \Sigma \) is a finite alphabet,
\item \( \delta \subseteq Q \times \Sigma \times Q \) is a transition relation,
\item \( Q_0 \subseteq Q \) is a set of initial states,
\item \( F \subseteq Q \) is a set of accepting states.
\end{itemize}
A run of a \ba is an infinite sequence of states \( q_0, q_1, q_2, \ldots \) such that \( q_0 \in Q_0 \) and \( (q_i, a, q_{i+1}) \in \delta \) for some \( a \in \Sigma \) at each step \( i \). The run is considered accepting if it visits states in \( F \) infinitely often.
\end{definition}
\begin{definition}[Process]
A \emph{Process} is a tuple \( P = \langle AP, I, O, S, s_0, T, L \rangle \), where:
\begin{itemize}
\item \( AP \) is a finite set of atomic propositions,
\item \( I \) is a set of inputs,
\item \( O \) is a set of output, such that \( I \cap O = \emptyset \),
\item \( S \) is a finite set of states,
\item \( s_0 \in S \) is the initial state,
\item \( T \subseteq S \times (I \cup O) \times S \) is the transition relation,
\item \( L: S \to 2^{AP} \) is a labeling function mapping each state to a subset of atomic propositions.
\end{itemize}
A transition \( (s, x, s') \in T \) is called an \emph{input transition} if \( x \in I \) and an \emph{output transition} if \( x \in O \).
\end{definition}
\setcounter{theorem}{0} \setcounter{theorem}{0}
\begin{theorem} \begin{theorem}
A process, as defined in Hippel et al., always directly corresponds to a Büchi automata. A process, as defined in Hippel et al., always directly corresponds to a \ba.
\end{theorem} \end{theorem}
\begin{proof} \begin{proof}
\jg{highly standard equivalence argument}
Given a \ba \( B = (Q, \Sigma, \delta, Q_0, F) \), we construct a corresponding Process \( P = \langle AP, I, O, S, s_0, T, L \rangle \) as follows:
\begin{itemize}
\item {Atomic Propositions: \( AP = \{ \text{accept} \} \), a singleton set containing a special proposition indicating acceptance.
\item Inputs and Outputs: \( I = \Sigma \) and \( O = \emptyset \).
\item States: \( S = Q \) and \( s_0 \in Q_0 \).
\item Transition Relation: \( T = \delta \).
\item Labeling Function: \( L: S \to 2^{AP} \) defined by
\[ L(s) = \begin{cases} \{ \text{accept} \} & \text{if } s \in F, \\ \emptyset & \text{otherwise}. \end{cases} \]
\end{itemize}
In this mapping, the states and transitions of the BA are preserved in the Process, and the accepting states \( F \) are identified via the labeling function \( L \).
Conversely, given a Process \( P = \langle AP, I, O, S, s_0, T, L \rangle \) with an acceptance condition defined by a distinguished proposition \( p \in AP \), we define a \ba \( B = (Q, \Sigma, \delta, Q_0, F) \) as follows:
\begin{itemize}
\item States: \( Q = S \) and \( Q_0 = \{ s_0 \} \).
\item Alphabet: \( \Sigma = I \cup O \).
\item Transition Relation: \( \delta = T \).
\item Accepting States: \( F = \{ s \in S \mid p \in L(s) \} \).
\end{itemize}
Here, the accepting states in the BA correspond to those states in the Process that are labeled with the distinguished proposition \( p \).
In both structures, a run is an infinite sequence of states connected by transitions:
\begin{itemize}
\item In the \ba: \( q_0, q_1, q_2, \ldots \) with \( q_0 \in Q_0 \) and \( (q_i, a_i, q_{i+1}) \in \delta \) for some \( a_i \in \Sigma \).
\item In the Process: \( s_0, s_1, s_2, \ldots \) with \( s_0 = s_0 \) and \( (s_i, x_i, s_{i+1}) \in T \) for some \( x_i \in I \cup O \).
\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} \end{proof}
\begin{definition}[Threat Model]
A threat model is a tuple \( (P, (Q_i)_{i=0}^m, \phi) \) where:
\begin{itemize}
\item \( P, Q_0, \ldots, Q_m \) are processes.
\item Each process \( Q_i \) has no atomic propositions (i.e., its set of atomic propositions is empty).
\item \( \varphi \) is an LTL formula such that \( P \parallel Q_0 \parallel \cdots \parallel Q_m \models \phi \).
\item The system \( P \parallel Q_0 \parallel \cdots \parallel Q_m \) satisfies the formula \( \phi \) in a non-trivial manner, meaning that \( P \parallel Q_0 \parallel \cdots \parallel Q_m \) has at least one infinite run.
\end{itemize}
\end{definition}
\begin{theorem} \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). 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} \end{theorem}
\begin{proof} \begin{proof}
\jg{arguing the equivalence of buchi automata intersection and process composition} For a given threat model \( (P, (Q_i)_{i=0}^m, \phi) \), checking $\exists ASP$ is equivalent to checking
\[
R = MC(P \mid \mid \text{Daisy}(Q_0) \mid \mid \ldots \mid \mid \text{Daisy}(Q_m), \phi)
\]
Where $MC$ is a model checker, and Daisy($Q_i$) is for intents of this proof, equivalent to a process. Therefore, via the previous theorem we can construct \ba \( BA_{P}, BA_{\text{Daisy}(Q_0)}, \ldots, BA_{\text{Daisy}(Q_m)} \) from the processes \( P, \text{Daisy}(Q_0), \ldots ,\text{Daisy}(Q_m) \). Then, we check
\[
\text{\spin}(BA_{P} \mid \mid BA_{\text{Daisy}(Q_0)} \mid \mid \ldots \mid \mid BA_{\text{Daisy}(Q_m)}, \phi)
\]
Or equivalently, translating $\phi$ to the equivalent \ba $BA_{\phi}$ via \cite{Holzmann_1997}, we equivalently check
\[
\left(BA_{P} \mid \mid BA_{\text{Daisy}(Q_0)} \mid \mid \ldots \mid \mid BA_{\text{Daisy}(Q_m)}\right) \subseteq BA_{\phi}
\]
\end{proof} \end{proof}
\begin{theorem} \begin{theorem}
@@ -25,8 +103,7 @@ Checking whether there exists an attacker for a given threat model, the R-$\exis
\end{theorem} \end{theorem}
\begin{proof} \begin{proof}
\jg{cite lower bounds for natural proof systems} By the previous argument the $\exists$ASP problem corresponds to \ba language inclusion, which is well-known to be PSPACE-complete \cite{Kozen_1977}.
\end{proof} \end{proof}
\subsection{Preventing Korg Livelocks}% \subsection{Preventing Korg Livelocks}%
@@ -74,3 +151,157 @@ BREAK:
\end{figure} \end{figure}
\subsection{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}

View File

@@ -1,4 +1,4 @@
\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. \korg supports three general attacker models: an attacker that can drop, replay, or reordering 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}% \subsection{Dropping Attacker Model}%
\label{sub:Dropping Attacker} \label{sub:Dropping Attacker}
@@ -7,29 +7,7 @@ The first and most simple general attacker model \korg supports is an attacker t
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}. 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}
\subsection{Replaying Attacker Model}% \subsection{Replaying Attacker Model}%
\label{sub:Replay Attacker} \label{sub:Replay Attacker}
@@ -37,138 +15,17 @@ The second attacker model \korg supports is an attacker that can observe and \te
The dropper attacker model gadget \korg synthesizes 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}. The dropper attacker model gadget \korg synthesizes 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 \subsection{Reordering Attacker Model}%
chan gadget_mem = [3] of { int, int, int }; \label{sub:reordering Attacker}
Lastly, \korg supports an attacker model such that an attacker can \textit{reorder} messages on a channel. Like the drop and replay attacker models, the user can specify a "reordering limit" that caps the number of messages that can be reorderingd by the attacker on the specified channel.
active proctype attacker_replay() { 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}.
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}
\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.
The rearrange 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 rearrange 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_rearrange}.
\begin{figure}[h]
\begin{lstlisting}[caption={Example rearrange attacker model gadget with the selected replay limit as 3, targetting channel "cn"}, label={lst:korg_rearrange}]
chan cn = [8] of { int, int, int };
chan gadget_mem = [3] of { int, int, int };
active proctype attacker_rearrange() 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}
\subsection{Custom Attacker Models}% \subsection{Custom Attacker Models}%
\label{sub: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. The user defines an \textit{IO-file} denoting the specific input and output messages the attacker is capable of sending, and \korg generates a gadget capable of synthesizing attacks with respect to the user's specification. An example I/O file is given in Figure \ref{lst:io-file}, and the generated gadget is given in \ref{lst:io-file-synth}. While the drop, replay, and reordering 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. The user defines an \textit{IO-file} denoting the specific input and output messages the attacker is capable of sending, and \korg generates a gadget capable of synthesizing attacks with respect to the user's specification. An example I/O file is given in Figure \ref{lst:io-file}, and the generated gadget is given in \ref{lst:io-file-synth}.
\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}

View File

@@ -1,8 +1,40 @@
\subsection{SCTP}% \subsection{Raft}%
\label{sub:SCTP} \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 only 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 on-channel attacker \textit{external} to the protocol itself. Uniquely, \korg enables us to study Raft under insecure communication channels.
\subsection{TCP}% \subsection{TCP}%
\label{sub:TCP} \label{sub:TCP}
\subsection{DCCP}% TCP (Transmission Control Protocol) is a transport-layer protocol designed to establish reliable, ordered communications between two peers. TCP is ubiquitous in today's internet, and therefore has seen ample formal verification efforts \cite{Cluzel_Georgiou_Moy_Zeller_2021, Smith_1997, Pacheco2022}, including using \promela and \spin \cite{Pacheco2022}. A previous version of \korg has been applied TCP in \cite{Pacheco2022, Hippel2022};
\label{sub:DCCP} in particular, we study our \korg extensions using the \promela models from Pacheco et al., which includes a "gold" model whose underlying state machine is derived via an NLP-based algorithm applied to the SCTP RFC \cite{rfc9260} and a "canonical" model hand-written by domain experts \cite{Pacheco2022}. Additionally, we borrow the four LTL properties used in \cite{Pacheco2022}, as detailed below:
\[
\begin{aligned}
\phi_1 &= \text{\parbox[t]{20em}{No half-open connections.}} \\
\phi_2 &= \text{\parbox[t]{20em}{Passive/active establishment eventually succeeds.}} \\
\phi_3 &= \text{\parbox[t]{20em}{Peers don't get stuck.}} \\
\phi_4 &= \text{\parbox[t]{20em}{\texttt{SYN\_RECEIVED} is eventually followed by \texttt{ESTABLISHED}, \texttt{FIN\_WAIT\_1}, or \texttt{CLOSED}.}}
\end{aligned}
\]
Evaluating the canonical TCP model using \korg led us to identify edge-cases in the connection establishment routine that weren't accounted for, leading us to construct a "revised" TCP model accounting for these missing edge cases. The resulting breakdown of attacks discovered is shown in Figure \ref{res:tcp-table}.
\begin{figure}[h!]
\centering
\begin{scriptsize}
\begin{tabular}{|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|@{}c@{}|}
\hline
& \multicolumn{3}{c|}{\footnotesize \raisebox{-0.15ex}{Drop Attacker} } & \multicolumn{3}{c|}{\footnotesize \raisebox{-0.15ex}{Replay Attacker}} & \multicolumn{3}{c|}{\footnotesize \raisebox{-0.15ex}{Reorder Attacker}} \\
\hline
& \: Gold \: & \: Expert \: & \: Revised \: & \: Gold \: & \: Expert \: & \: Revised \: & \: Gold \: & \: Expert \: & \: Revised \: \\
\hline
$\phi_1$ & \rule{0pt}{8pt} & & & & & & & & \\
$\phi_2$ & \rule{0pt}{8pt} & x & x & & x & x & & x & \\
$\phi_3$ & \rule{0pt}{8pt} & & & & & & & & \\
$\phi_4$ & \rule{0pt}{8pt} x & & & & & & x & & \\
\hline
\end{tabular}
\end{scriptsize}
\label{res:tcp-table}
\caption{Automatically discovered attacks against the gold, canonical (labeled "expert"), and revised TCP models 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. Full attack traces are available in the artifact.}
\end{figure}

View File

@@ -6,12 +6,6 @@ In this section we discuss the details behind the design, formal guarantees, imp
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. 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}. 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] \begin{figure}[h]
\centering \centering
\includegraphics[width=0.5\textwidth]{assets/diagram3.png} \includegraphics[width=0.5\textwidth]{assets/diagram3.png}
@@ -24,7 +18,6 @@ A high-level overview of the \korg pipeline is given in the Figure \ref{fig:korg
\newcommand{\comp}{\mid\mid} \newcommand{\comp}{\mid\mid}
\newcommand{\ioint}{\mathcal{C}} \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. 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.
@@ -82,27 +75,65 @@ Since \korg uses \spin as its underlying model checker, we can effectively concl
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. 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}] \begin{lstlisting}[caption={Example \promela model of peers communicating over a channel}, label={lst:spin-model}]
// channel of buffer size 0 // channel of buffer size 0
chan msg_channel = [0] of { int } chan msg_channel = [0] of { int }
active proctype Peer1() { active proctype Peer1() {
msg_channel ! 1 msg_channel ! 1;
} }
active proctype Peer2() { active proctype Peer2() {
int received_msg int received_msg;
msg_channel ? received_msg msg_channel ? received_msg;
} }
\end{lstlisting} \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. 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{Usage}% \subsection{Usage}%
\label{sub:Usage} \label{sub:Usage}
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. To use \korg, the user first authors a \promela model and a correctness property in LTL. Take the following producer-consumer model, as shown in Listing \ref{lst:prod-consume}.
Precise details of how to use the \korg implementation are provided in the anonymous repository: (link) \begin{lstlisting}[caption={Example \promela model with four producers and one consumer.}, label={lst:prod-consume}]
chan msgs = [4] of { bit };
int count = 0;
active [1] proctype Producer() {
do :: atomic { count++; msgs ! 1; } od
}
active [4] proctype Consumer() {
do :: atomic { msgs ? 1 -> count--; } od
}
ltl always_positive { always (count >= 0) }
\end{lstlisting}
Next, the user selects a \textit{channel} to generate an attacker on, and an attacker model of choice (see Section \ref{sec:usage_attacker_models} for more details). For example, we select \texttt{msgs} as our channel of choice, \texttt{replay} as our attacker model of choice, and assume the producer-consumer model is in the file \texttt{pc.pml}. Then, we run \korg via command line.
\begin{lstlisting}[label={lst:korg-shell}]
$ ./korg --model=pc.pml --attacker=replay --channel=msgs --eval
\end{lstlisting}
\korg will then modify the \texttt{pc.pml} file to include the \texttt{replay} attacker gadget, and model-check it with \spin. Then, \korg will find and output the simple attack trace where a producer message is replayed, causing a consumer to consume an extra time. The (simplified) attack trace is shown below.
\begin{lstlisting}[label={trace}]
(Producer) ko.pml:5 Send 1 -> queue 1 (msgs)
(Atk) ko.pml:22 [Recv] 1 <- queue 1 (msgs)
(Atk) ko.pml:23 Send 1 -> queue 2 (a_mem)
(Atk) ko.pml:47 Recv 1 <- queue 2 (a_mem)
(Atk) ko.pml:47 Send 1 -> queue 1 (msgs)
(Consumer) ko.pml:9 Recv 1 <- queue 1 (msgs)
(Consumer) ko.pml:9 Recv 1 <- queue 1 (msgs)
spin: _spin_nvr.tmp:3, assertion violated
spin: text of failed assertion: assert(!(!((count>=0))))
Never claim moves to line 3 [assert(!(!((count>=0))))]
\end{lstlisting}
Additional examples and usage information are provided in the anonymous repository link: (link)
%the user inputs a \promela model, a correctness property specified in LTL, a channel from the given \promela model, and an attacker model of choice. \korg will then generate an attacker model gadget corresponding to the selected attacker model with respect to the chosen channel. The attacker model gadget is then appended onto the given \promela model and evaluated against the LTL property with \spin. \korg will then either produce an attack trace demonstrating the precise actions the attacker took to violate the LTL property, or demonstrate the absence of an attack via an exhaustive state-space search.
% Precise details of how to use the \korg implementation are provided in the anonymous repository: (link)

View File

@@ -1,4 +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 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}. 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? This myriad of formal methods tooling applicable to secure protocols has enabled reasoning about security-relevant properties involving secrecy, authentication, indistinguishability in addition to concurrency, safety, and liveness. However, no previous formal methods tooling offered an effective solution for rigorously studying an attacker that controls communication channels. That is, how do you reason about an attacker that can arbitrarily drop, reorder, replay, or insert messages onto a communication channel?
To fill this gap, we introduce \korg, 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. 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, reorder, or drop messages on channels, as well as custom user-defined attacker models. Although \korg best lends itself for reasoning about denial of service attacks, it can target any specification expressable in LTL. We present a variety of case studies illustrating the employability and usefulness of \korg.