Commit 55c219d0 authored by Paul Fiterau Brostean's avatar Paul Fiterau Brostean
Browse files

Updated tex files

parent 75be428d
This diff is collapsed.
\section{Learning results} \label{sec:result}
\section{Learning Results} \label{sec:result}
We use the setup described in Section~\ref{sec:setup} to learn models for OpenSSH, Bitvise and DropBear SSH server implementations.
OpenSSH represents the focal point, as it is the most popular implementation of SSH (with over 80 percent of market share in 2008~\cite{Albrecht2009Plaintext})
......@@ -57,6 +57,7 @@ give a glimpse into the issue of scalability. Assuming each input took 0.5 secon
\caption{Statistics for learning experiments}
{\centering{\textbf{SUT}}} & \textbf{States} & \textbf{Hypotheses } & \textbf{Mem. Q.} & \textbf{Test Q.}\\ \hline %& \textbf{Tests to last Hyp.} & \textbf{Tests on last Hyp.} \\ \hline
\section{The learning setup} \label{sec:setup}
\section{The Learning Setup} \label{sec:setup}
%This chapter will cover the setup used to infer the state machines. We provide a general setup outline in Section~\ref{components}. The tested SSH servers are described in Section~\ref{suts}, which were queried with the alphabet described in Section~\ref{alphabet}. Section~\ref{setup-handling} will cover the challenging SUT behaviour faced when implementing the mapper, and the adaptations that were made to overcome these challenges. Section~\ref{layers-individual} will discuss the relation between state machines for individual layers and the state machine of the complete SSH protocol. The conventions on visualisation of the inferred state machines are described in Section~\ref{visualisation}.
%Throughout this chapter, an individual SSH message to a SUT is denoted as a \textit{query}. A \textit{trace} is a sequence of multiple queries, starting from a SUT's initial state. Message names in this chapter are usually self-explanatory, but a mapping to the official RFC names is provided in Appendix~\ref{appendixa}.
......@@ -25,7 +25,7 @@ state of the {\dsut} is one where a TCP connection has already been established
%It is therefore important to focus on messages for which interesting state-changing behaviour can be expected.
\subsection{The learning alphabet}\label{subsec:alphabet}
\subsection{The Learning Alphabet}\label{subsec:alphabet}
The alphabet we use consists of inputs, which correspond to messages
......@@ -154,7 +154,7 @@ The restricted alphabet only supports the most general channel management inputs
\subsection{The mapper}\label{subsec:mapper}
\subsection{The Mapper}\label{subsec:mapper}
The {\dmapper} must provide a translation between abstract messages
and well-formed SSH messages: it has to translate abstract inputs
......@@ -214,7 +214,7 @@ responds with a \textsc{no\_conn} message, as sending further messages to the {\
\subsection{Practical complications}
\subsection{Practical Complications}
%There are three practical complications in learning models of SSH
%servers: (1) an SSH server may exhibit \emph{non-determistic}
......@@ -11,7 +11,7 @@
\usepackage{ upgreek }
\pagestyle{plain} % EP These lines to add page numbers,
%\pagestyle{plain} % EP These lines to add page numbers,
\thispagestyle{plain} % EP which is useful for reviewers.
......@@ -155,7 +155,7 @@ all tested SSH server models satisfy the stated security properties,
% We no longer use \terms command
\keywords{Model learning, model checking, SSH protocol}
\keywords{Model learning, Model checking, SSH protocol}
\section{Model learning}\label{sec:prelims}
\subsection{Mealy machines} \label{ssec:mealy}
\section{Model Learning}\label{sec:prelims}
\subsection{Mealy Machines} \label{ssec:mealy}
A \emph{Mealy machine} is a tuple $\M = (I, O, Q, q_0, \delta, \lambda)$, where
$I$ is a finite set of inputs,
$O$ is a finite set of outputs,
\section{Security specifications} \label{sec:specs}
\section{Security Specifications} \label{sec:specs}
......@@ -73,6 +73,7 @@ This function updates the output and state variables for a given valuation of th
\caption{Mealy machine + associated NuSMV code}
......@@ -129,7 +130,7 @@ $p\,W\,q\, =\, p \,U\, q\, | \, G\, p$. Many of the higher layer properties we
%In the actual specification, W was replaced by this re-formulation. %Finally, we may define properties which we later use when defining other properties. This feature again isn't supported by NuSMV, hence the properties appear in expanded form in the run specification.
\subsection{Basic characterizing properties}
\subsection{Basic Characterizing Properties}
%cannot be translated. %Though in practical terms, these results are still translatable, in particular for cases where properties are not met.
In our setting, a single TCP connection is made and once this connection is lost (e.g.\ because the system disconnects) it cannot be re-established. The moment
......@@ -159,7 +160,7 @@ Outputs \textsc{ch\_max} and \textsc{ch\_none} are still generated because of a
\subsection{Security properties}
\subsection{Security Properties}
In SSH, upper layer services rely on security guarantees ensured by lower layers. So these services should not be available before the lower layers have completed. For example, the authentication service should only become available \emph{after} a successful key exchange and the seting up of a secure tunnel by the Transport layer, otherwise the service would be running over an unencrypted channel. Requests for this service should therefore not succeed unless key exchange was performed successfully.
Key exchange involves three steps that have to be performed in order but may be interleaved by other actions. Successful authentication necessarily implies successful execution of the key exchange steps. We can tell each key exchange step was successful from the values of the input and output variables. Successful authentication request is indicated by the predicate defined earlier, {\dreqauth}. Following these principles, we define the LTL specification in Property~\ref{prop:sec-trans}, where O is the once operator. Formula $O p$ is true at time $t$ if $p$ held in at least one of the previous time steps $t' \leq t$.
......@@ -194,7 +195,7 @@ Formula $p S q$ is true at time $t$ if $q$ held at some time $t' \leq t$ and $p$
\subsection{Key re-exchange properties}
\subsection{Key Re-exchange Properties}
According to the RFC \cite[p. 24]{rfc4254}, re-exchanging keys (or rekeying) (1) is preferably allowed in all states of the protocol, and (2) its successful execution does not affect operation of the higher layers. We consider two general protocol states, pre-authenticated (after a successful authentication request, before authentication) and authenticated. These may map to multiple states in the learned models. We formalized requirement (1) by
two properties, one for each general state. In the case of the pre-authenticated state, we know we have reached this state following a successful authentication service request, indicated by the predicate {\dreqauth}. Once here, performing the inputs for rekey in succession should imply success until one of two things happen, the connection is lost(\dconnlost) or we have authenticated. This is asserted in Property~\ref{prop:rpos-pre-auth}. A similar property is defined for the authenticated state.
......@@ -226,7 +227,7 @@ We therefore checked this requirement directly, by writing a simple script which
%\textit{Perhaps this could be merged into one property?}
\subsection{Functional properties}
\subsection{Functional Properties}
We formalized and checked several other properties drawn from the RFCs. We found parts of the specification unclear, which sometimes meant that we had to give our own interpretation. A first general property can be defined for the \textsc{disconnect} output. The RFC specifies that after sending this message, a party MUST not send or receive any data \cite[p. 24]{rfc4253}. While we cannot tell what the server actually receives, we can check that the server does not generate any output after sending \textsc{disconnect}. After a \textsc{disconnect} message, subsequent outputs should be solely derived by the {\dmapper}. Knowing the {\dmapper} induced outputs are \textsc{no\_conn}, \textsc{ch\_max} and \textsc{ch\_none}, we formulate by Property~\ref{prop:trans-disc} to describe
expected outputs after a \textsc{disconnect}.
......@@ -325,7 +326,7 @@ G ( hasOpenedChannel ->
\subsection{Model checking results}
\subsection{Model Checking Results}
Table~\ref{tab:mcresults} presents model checking results. Crucially, the security properties hold for all three implementations. We had to slightly adapt our properties for Bitvise
as it buffered all responses during rekey (incl. \textsc{UA\_SUCCESS}).
In particular, we used {\dvauth} instead of \textit{out=UA\_SUCCESS} as sign of successful authentication.
......@@ -336,6 +337,7 @@ In particular, we used {\dvauth} instead of \textit{out=UA\_SUCCESS} as sign of
\caption{Model checking results}
\begin{tabular}{| l | l | c | c |c | c |}
% & & & \multicolumn{3}{c|}{\emph{SSH Implementation}}\\ \cline{4-6}
......@@ -353,7 +355,7 @@ In particular, we used {\dvauth} instead of \textit{out=UA\_SUCCESS} as sign of
& Prop.~\ref{prop:conn-close} & MUST & \dt & \dt & \dfce{sends CH\_EOF} \\ \hline
We have combined model learning with abstraction techniques to infer models of the OpenSSH, Bitvise and DropBear SSH server implementations. We have also
formalized several security and functional properties drawn from the SSH RFC specifications. We have verified these
properties on the learned models using model checking and have uncovered several minor standard violations.
The security-critical properties were met by all implementations.
Abstraction was provided by a {\dmapper} component placed between the
{\dlearner} and the {\dsut}. The {\dmapper} was constructed from an
existing SSH implementation. The input alphabet of the {\dmapper}
explored key exchange, setting up a secure connection, several
authentication methods, and opening and closing channels over which the
terminal service could be requested. We used two input alphabets, a
full version for OpenSSH, and a restricted version for Bitvise and
DropBear. The restricted alphabet was still sufficient to
explore most aforementioned behavior.
We encountered several challenges. Firstly, building a {\dmapper} presented a considerable technical challenge, as it required re-structuring of an actual
SSH implementation. Secondly, because we used classical learning algorithms, we had to ensure that the abstracted implementation behaved
like a (deterministic) Mealy Machine. Here time-induced non-determinism was difficult to eliminate. Buffering also presented problems,
leading to a considerable increase in the number of states. Moreover, the systems analyzed were relatively slow, which meant learning took
several days. This was compounded by the size of the learning alphabet, and it forced us into using a reduced alphabet for two of the implementations.
Limitations of the work, hence possibilities for future work, are several. First of all, the {\dmapper} was not formalized, unlike in~\cite{TCP2016}, thus we did not
produce a concretization of the abstract models. Consequently, model checking results cannot be fully transferred to the actual implementations. Formal definition
of the mapper and concretization of the learned models (as defined in \cite{AJUV15}) would tackle this. The {\dmapper} also caused considerable redundancy in the learned models; tweaking the abstractions used, in particular those for managing channels, could alleviate this problem while also improving learning times. This in turn would facilitate learning using expanded alphabets instead of resorting to restricted alphabets.
Furthermore, the {\dmapper} abstraction could be refined, to give more
insight into the implementations. In particular, parameters
such as the session identifier could be extracted from the {\dmapper} and potentially handled by existing Register Automata learners\cite{ralib2015,tomte2015}. These learners
can infer systems with parameterized alphabets, state variables and simple operations on data. Finally, we suppressed all timing-related behavior, as it could not be handled by the classical learners used; there is preliminary work on learning timed automata\cite{GrinchteinJL10} which could use timing behavior.
Despite these limitations, our work provides a compelling application of learning and model checking in a security setting, on a widely used protocol. We hope this lays
some more groundwork for further case studies, as well as advances in learning techniques.
SSH is a security protocol that is widely used to interact securely with
remote machines. The Transport layer of SSH has been subjected to security analysis
\cite{Williams2011Analysis}, incl.\ analyses that revealed
cryptographic shortcomings
Whereas these analyses consider the abstract cryptographic
protocol, this paper looks at actual implementations of SSH, and
investigates flaws in the program logic of these implementations,
rather than cryptographic flaws. Such logical flaws have occurred in
implementations of other security protocols, notably TLS, with Apple's
'goto fail' bug and the FREAK attack \cite{Beurdouche:2017}. For this
we use model learning (a.k.a.\ active automata learning)
\cite{Angluin1987Learning,PeVaYa02,Vaa17} to infer state machines of three SSH
implementations, which we then analyze by model checking for
conformance to both functional and security properties.
The properties we verify for the inferred state machines are based on
the RFCs that specify SSH \cite{rfc4251,rfc4252,rfc4253,rfc4254}.
These properties are formalized in LTL and verified using
We use a model checker since the models are too complex for manual inspection (they are trivial for NuSMV).
Moreover, by formalizing the
properties we can better assess and overcome vagueness or
under-specification in the RFC standards.
This paper is born out of two recent theses \cite{Verleg2016,Toon2016},
and is to our knowledge the first combined application of model
learning and model checking in verifying SSH implementations, or more
generally, implementations of any network security protocol.
%Model learning obtains a state machine model of a black-box system by
%providing inputs and observing outputs. Since model learning uses a
%finite number of observations, we can never be sure that the learned
%model is correct. To that end, advanced conformance algorithms are employed
%\cite{LeeY96}, which yield some confidence that the system inferred is
%in fact complete. In the context of testing security protocols, model
%learning can be seen as a form of fuzzing, where inputs are sent in
%unexpected orders to expose any hidden anomalies.
\paragraph{Related work}
%The SSH protocol has been investigated for cryptographic flaws, e.g.\
%but that research does not consider logical flaws in actual software
Chen et al.\cite{ChenDW04} use the MOPS software model checking tool
to detect security vulnerabilities in the OpenSSH C implementation
due to violation of folk rules for the construction of secure programs
such as ``Do not open a file in writing mode to stdout or stderr''.
Udrea et al.\cite{Udrea_rule-based_2008} also investigated SSH
implementations for logical flaws. They used a static analysis tool to
check two C implementations of SSH against an extensive set of rules.
These rules not only express properties of the SSH protocol logic, but
also of message formats and support for earlier versions and various
options. Our analysis only considers the protocol logic. However,
their rules were tied to routines in the code, so had to be slightly adapted
to fit the different implementations. In contrast, our properties are
defined at an abstract level so do not need such tailoring. Moreover,
our black box approach means we can analyze any implementation
of SSH, not just open source C implementations.
Formal models of SSH in the form of state machines have been used
before, namely for a manual code review of OpenSSH
\cite{Poll_rigorous_2011}, formal program verification of a Java
implementation of SSH \cite{PollSchubert07}, and for model based
testing of SSH implementations \cite{Boss2012}. All this research
only considered the SSH Transport layer, and not the other SSH
protocol layers.
Model learning has previously been used to infer state machines of
EMV bank cards~\cite{Aarts2013Formal}, electronic
passports~\cite{Aarts2010Inference}, hand-held readers for online
banking~\cite{Chalupar2014Automated}, and implementations of
TCP~\cite{TCP2016} and TLS~\cite{RuiterProtocol}. Some of these
studies relied on manual analysis of learned models
\cite{Aarts2013Formal,Aarts2010Inference,RuiterProtocol}, but some
also used model checkers \cite{TCP2016,Chalupar2014Automated}.
Instead of using active learning as we do, it is also possible to use
passive learning to obtain protocol state machines
\cite{Wang2011Inferring}. Here network traffic is observed, and not
actively generated. This can then provide a probabilistic
characterization of normal network traffic, but it cannot uncover
implementation flaws that occur in strange message flows, which is our
%Our approach, most closely resembles work on TCP~\cite{TCP2016},
%where they also combine classical learning and model checking to
%analyze various TCP implementations, with our work being more focused
%on security properties. Other case studies involving model learning
%rely on manual analysis of the learned models
%Our work differs, since we use a model checker to automatically check
%specifications. Inference of protocols has also been done from
%observing network traffic ~\cite{Wang2011Inferring}. Such inference
%is limited to the traces that occur over a network. Inference is
%further hampered if the analyzed protocols communicate over encrypted
%channels, as this severely limits information available from traces without knowledge of the security key.
%In this thesis, we will be using protocol state fuzzing to extract an implementations state machine. All fuzzing algorithms rely on the idea of sending unexpected input data to a system under test (SUT) in the hope that this triggers anomalies. Using protocol state fuzzing, however, we will fuzz on the \textit{order} of otherwise correctly-formed messages.
%This technique has previously been applied to infer state machines of EMV bank cards~\cite{Aarts2013Formal}, electronic passports~\cite{Aarts2010Inference} and hand-held readers for online banking~\cite{Chalupar2014Automated}. Furthermore, implementations of TCP~\cite{Janssen2015Learning} and TLS~\cite{RuiterProtocol} have state-fuzzed. As in these works, we implement state fuzzing
%State machines inferred are large and hard to check manually.
%Once a state machine has been inferred, security-related logical flaws are usually easily spotted by an auditor with some knowledge about the protocol~\cite{RuiterProtocol}. An example of a logical flaw is exchanging user credentials before an encrypted connection has been established.
%Besides security-related logical flaws, inferred state machines can show quirks such as superfluous states. Although these might not be directly exploitable, OpenBSD auditors illustrate why these small bugs should be resolved: ``we are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better''\footnote{\url{}}.
%\textit{Organization.} An outline of the SSH protocol will be provided in Section~\ref{ssh}. The experimental setup is discussed in Section~\ref{setup}. The results are subsequently discussed in Section~\ref{results}, after which we conclude in Section~\ref{conclusions}.
\section{Learning results} \label{sec:result}
We use the setup described in Section~\ref{sec:setup} to learn models for OpenSSH, Bitvise and DropBear SSH server implementations.
OpenSSH represents the focal point, as it is the most popular implementation of SSH (with over 80 percent of market share in 2008~\cite{Albrecht2009Plaintext})
and the default server for many UNIX-based systems. DropBear is an alternative to OpenSSH designed for low resource
systems. Bitvise is a well-known proprietary Windows-only SSH implementation.
In our experimental setup, {\dlearner} and {\dmapper} ran inside a Linux Virtual Machine. OpenSSH and DropBear were
learned over a localhost connection, whereas Bitvise was learned over a virtual connection with the Windows host machine.
We have adapted the setting of timing parameters to each implementation.
\caption{Model of the OpenSSH server. {\normalfont States are collected in 3 clusters,
indicated by the rectangles, where each cluster corresponds to
one of the protocol layers.
We eliminate redundant states and information induced by the {\dmapper}, as well as states present in successful rekeying sequences. Wherever rekeying was permitted, we replaced the rekeying states and transitions by a single \textsl{REKEY SEQUENCE} transition. We also factor out edges common to states within a cluster. We replace common disconnecting edges, by one edge from the cluster to the disconnect state. Common self loop edges are colored, and the actual i/o information only appears on one edge. Transitions with similar start and end states are joined together on the same edge. Transition labels are kept short by regular expressions(UA\_* stands for inputs starting with UA\_) or by factoring out common start strings. Green edges highlight the happy flow. '+' concatenates
multiple outputs.}}
OpenSSH was learned using a full alphabet, whereas DropBear and Bitvise were learned using a restricted alphabet (as defined in Subsection~\ref{subsec:alphabet}).
The reason for using a restricted alphabet was to reduce learning times. Based on the model learned for OpenSSH (the first implementation analyzed) and the specification, we excluded
inputs that seemed unlikely to produce state change (such as
\textsc{debug} or \textsc{unimpl}). We also excluded inputs that proved costly time-wise (such as \textsc{disconnect}) but were not were not needed to visit all states in the happy flow. We excluded, for example, the user/password based authentication inputs (\textsc{ua\_pw\_ok} and
\textsc{ua\_pw\_nok}) as they would take the system 2-3 seconds to respond to. By contrast, public key authentication resulted in quick responses.
%The \textsc{disconnect} input presented similar
%challenges, as it would take a varying amount of time before the system responded.
%Not only that, but failed password authentication
%attempts are also likely to trigger security mechanisms that would block subsequent authentication attempts. While this is
%As an example, \textsl{ua\_pw\_ok} contours the same behavior as \textsl{ua\_pk\_ok}. But while authenticating
%with a public key was done quickly, authenticating with a username/password proved time consuming (it would take the system 2-3 seconds to respond to
%invalid credentials \textsl{ua\_pw\_ok}). The \textsl{disconnect} proved expensive in a similar way.
For the test queries we used random and exhaustive variants of the testing algorithm described in
\cite{SMJV15}, which generate efficient test suites. Tests generated comprise an access sequence, a middle section of length {\dk} and a
distinguishing sequence. The exhaustive variant generates tests for all possible middle sections of length {\dk} and all states. Passing all tests then provides some notion of confidence,
namely, that the learned model is correct unless the (unknown) model of the implementation has at least {\dk} more states than the learned hypothesis. The random variant produces tests
with randomly generated middle sections. No formal confidence is provided, but past experience shows this to be more effective at finding counterexamples since {\dk}
can be set to higher values. We executed a random test suite with {\dk} of 4 comprising 40000 tests for OpenSSH, and 20000 tests for Bitvise and DropBear. We then ran an exhaustive test suite with {\dk} of 2 for all implementations.
%To that end, we built a java adapter that would automatically run the model checker on the hypothesis, and transform any counterexamples into tests. This proved essential in learning DropBear, as the last counterexample was generated by the model checker.
Table~\ref{tab:experiments} describes the exact versions of the systems analyzed together with statistics on learning and testing:
(1) the number of states in the learned model, (2) the number of hypotheses built during the learning process and (3) the total number of learning and test queries run. For test queries, we only consider those run on the last hypothesis. All learned models and the properties checked are at \url{}. The statistics
give a glimpse into the issue of scalability. Assuming each input took 0.5 seconds to process, and an average query length of 10, to perform 40000 queries would have taken roughly 55 hours. This is consistent with the time experiments took, which span several days. The long duration compelled us to resort to restricted alphabets, which lead to reduction in the number of queries needed. Our work could have benefited from parallel execution.
%Bitvise: MemQ: 24996 TestQ: 58423
%Dropbear: MemQ: 3561 TestQ: 30629
%OpenSSH: MemQ: 19836 TestQ: 76418
\begin{table}[h] % was !ht
\caption{Statistics for learning experiments}
{\centering{\textbf{SUT}}} & \textbf{States} & \textbf{Hypotheses } & \textbf{Mem. Q.} & \textbf{Test Q.}\\ \hline %& \textbf{Tests to last Hyp.} & \textbf{Tests on last Hyp.} \\ \hline
OpenSSH 6.9p1-2 & 31 & 4 & 19836 & 76418 \\ %& 1322 & 50243 \\
Bitvise 7.23 & 65 & 15 & 24996 & 58423 \\ %& 9549 & 65040 \\
DropBear v2014.65 & 29 & 8 & 8357 & 64478 \\ \hline %& 15268 & 56174 \\
The large number of states is down to several reasons. First of all, some systems exhibited buffering behavior. In particular, Bitvise would queue
responses for higher layer inputs sent during key re-exchange, and would deliver them all at once after rekeying was done. Rekeying was also
a major contributor to the number of states. For each state where rekeying is possible, the sequence of transitions constituting the complete
rekeying process should lead back to that state. This leads to two additional rekeying states for every state allowing rekey. Many states were also added due to the {\dmapper} generated outputs \textsc{ch\_none} or \textsc{ch\_max}, outputs which signal that no channel is open or that the maximum number of channels have been opened.
Figure~\ref{fig:sshserver} shows the model learned for OpenSSH, with some edits to improve readability. The happy flow, in green, is fully explored in the model and mostly matches our earlier description of it\footnote{The only exception is in the Transport layer, where unlike in our happy flow definition, the server is the first to send the \textsc{newkeys} message. This is also accepted behavior, as the protocol does not specify which side should send \textsc{newkeys} first.}. Also explored is what happens when a rekeying sequence is attempted. We notice that rekeying is only allowed in states of the Connection layer. Strangely, for these states, rekeying is not state preserving, as the generated output on receiving a \textsc{sr\_auth}, \textsc{sr\_conn} or \textsc{kex30} changes from \textsc{unimpl} to \textsc{no\_resp}. This leads to two sub-clusters of states, one before the first rekey, the other afterward. In all other states, the first step of a
rekeying (\textsc{kexinit}) yields (\textsc{unimpl}), while the last step (\textsc{newkeys}) causes the system to disconnect.
%We were puzzled by how systems reacted to \textsc{sr\_conn}, the request for services of the Connection layer. These services can be accessed once the user had authenticated, without the need of a prior service request. That in itself was not strange, as authentication messages already mention that connection services should start after authentication \footnote{This is a technical detail, the message format of authentication messages requires a field which says the service started after authentication. The only option is to start Connection layer services. }.
%Unexpected was that an explicit request either lead to \textsc{unimpl}/\textsc{no\_resp} with no state change, as in the case of OpenSSH, or termination of the connection, as in the case of Bitvise. The latter was particularly strange, as in theory, once authenticated, the user should always have access to the service, and not be disconnected when requesting this service. Only DropBear seems to respond positively (\textsc{sr\_accept}) to \textsc{sr\_conn} after authentication.
%Systems reacted differently to \textsc{sr\_conn}, input which requests services of the Connection layer. These services are automatically requested after successful authentication, so technically, this input is not required to open channels for example. Nevertheless, in authenticated states, OpenSSH responded with \textsc{unimpl} and maintained state. Bitvise disconnected the user. Only DropBear generated \textsc{sr\_accept}, the output we were expecting in view of the RFC.
We also note the intricate authentication behavior: after an unsuccessful authentication attempt the only authentication method still allowed is password authentication. Finally, only Bitvise allowed multiple terminals to be requested over the same channel. As depicted in the model, OpenSSH abruptly terminates on requesting a second terminal. DropBear exhibits a similar behavior.
%To give a concrete example, the {\dmapper} on every \textsl{ch\_open} saves a channel identifier and sends
%a corresponding message to the {\dsut}. If \textsl{ch\_open} is called again, the {\dmapper} responds with a \textsl{ch\_max}. The channel identifier is removed
%by a \textsl{ch\_close} input leading to pairs of identical states with and without the channel identifier, even in states where channels are not relevant (like for example states prior to authentication).
This diff is collapsed.
% Code to set up special term treatment: every first occurence is emphasized
{#1}{\emph{#1}\global\expandafter\let\csname specialterm@\detokenize{#1}\endcsname\relax}%
\newcommand{\A}{{\mathcal A}}
\newcommand\CH{{\mathcal H}}
\newcommand{\N}{{\mathcal N}}
\newcommand{\M}{{\mathcal M}}
\specialterms{server,client,learner,segments,{\sc sul} adapter,network adapter,observation tree}
\parbox{10cm}{\em #1}\hspace*{2cm}(\arabic{quotecount})\\[1cm]}
% automata learning theory
% learning components
\newcommand{\dlearner}{\sc learner}
\newcommand{\dmapper}{\sc mapper}
\newcommand{\dsut}{\sc sul}
\newcommand{\dsuts}{\sc suls}
%alphabet related
\newcommand{\dtimeout}{\sc noresp}
\ No newline at end of file
\usepackage{booktabs} % For formal tables
\usepackage{amssymb} % math stuff
\usepackage{amsmath} % more math stuff
\usepackage{mathtools} % for \coloneqq (defines-symbol := )
\usepackage{graphicx} % for graphics
\usepackage{ upgreek }
\pagestyle{plain} % EP These lines to add page numbers,
\thispagestyle{plain} % EP which is useful for reviewers.
\usetikzlibrary{automata, arrows,shapes.multipart}
% Copyright
%%% The following is specific to SPIN'17 and the paper
%%% 'Model Learning and Model Checking of SSH Implementations'
%%% by Paul Fiterau-Brostean, Frits Vaandrager, Erik Poll, Joeri de Ruiter, Toon Lenaerts, and Patrick Verleg.
\setcopyright{acmcopyright} % Adjust this to match your publishing-rights agreement with ACM.
\acmConference[SPIN'17]{International SPIN Symposium on Model Checking of Software }{July 2017}{Santa Barbara, CA, USA}
\title{Model Learning and Model Checking of SSH Implementations}
%\title{Leveraging Model Learning and Model Checking to Infer and Verify SSH Implementations}
\renewcommand{\shorttitle}{Inference and Verification of SSH Implementations}
\author{Paul Fiter\u{a}u-Bro\c{s}tean}
\authornote{Supported by NWO project 612.001.216, Active Learning of Security Protocols (ALSEP).}
\institution{Radboud University Nijmegen}
\author{Toon Lenaerts}
\institution{Radboud University Nijmegen}
\author{Erik Poll}
\institution{Radboud University Nijmegen}
\author{Joeri de Ruiter}
\institution{Radboud University Nijmegen}
\author{Frits Vaandrager}
\institution{Radboud University Nijmegen}
\author{Patrick Verleg}
\institution{Radboud University Nijmegen}
We apply model learning on three SSH implementations to infer state machine models, and then use model checking
to verify that these models satisfy basic security properties and conform to the RFCs. Our analysis showed that
all tested SSH server models satisfy the stated security properties,
but uncovered several violations of the standard.
%Frits: I would say the fingerprinting is a detail, standard violations much more important.
%The state machines of the implementations differ significantly, allowing them to be
%effectively fingerprinted.
%Various shortcomings with regards to the RFCs were found. Opening multiple channels is not properly implemented on CiscoSSH and PowerShell. OpenSSH contains a bug which can result in connection closure after rekeying in some circumstances. Both Tectia and OpenSSH implement a liberal message acceptance policy in the first phase of the protocol. Such a liberal policy is unwise in this error-prone stage.
% The code below should be generated by the tool at
% Please copy and paste the code instead of the example below.
<concept_desc>Networks~Protocol correctness</concept_desc>
<concept_desc>Theory of computation~Active learning</concept_desc>
<concept_desc>Software and its engineering~Model checking</concept_desc>
<concept_desc>Security and privacy~Logic and verification</concept_desc>
<concept_desc>Security and privacy~Network security</concept_desc>
\ccsdesc[500]{Networks~Protocol correctness}
\ccsdesc[500]{Theory of computation~Active learning}
\ccsdesc[500]{Software and its engineering~Model checking}
\ccsdesc[300]{Security and privacy~Logic and verification}
\ccsdesc[300]{Security and privacy~Network security}
% We no longer use \terms command
\keywords{Model learning, Model checking, SSH protocol}
\renewcommand{\shortauthors}{Fiter\u{a}u-Bro\c{s}tean et al.}
\section{Model learning}\label{sec:prelims}
\subsection{Mealy machines} \label{ssec:mealy}
A \emph{Mealy machine} is a tuple $\M = (I, O, Q, q_0, \delta, \lambda)$, where
$I$ is a finite set of inputs,
$O$ is a finite set of outputs,
$Q$ is a finite set of states,
$q_0 \in Q$ is the initial state,
$\delta: Q \times I \rightarrow Q$ is a transition function, and
$\lambda: Q \times I \rightarrow O$ is an output function.
Output function $\lambda$ is extended to sequences of inputs by defining,