Model Learning and Model Checking of SSH Implementations

Paul Fiterau-Bros¸tean˘ ∗ Toon Lenaerts Erik Poll Radboud University Nijmegen Radboud University Nijmegen Radboud University Nijmegen p.€[email protected] [email protected] [email protected] Joeri de Ruiter Frits Vaandrager Patrick Verleg Radboud University Nijmegen Radboud University Nijmegen Radboud University Nijmegen [email protected] [email protected] [email protected]

ABSTRACT model learning (a.k.a. active automata learning) [6, 21, 28] to infer We apply model learning on three SSH implementations to infer state machines of three SSH implementations, which we then an- state machine models, and then use model checking to verify that alyze by model checking for conformance to both functional and these models satisfy basic security properties and conform to the security properties. RFCs. Our analysis showed that all tested SSH server models satisfy Œe properties we verify for the inferred state machines are the stated security properties, but uncovered several violations of based on the RFCs that specify SSH [32–35]. Œese properties the standard. are formalized in LTL and veri€ed using NuSMV [13]. We use a model checker since the models are too complex for manual CCS CONCEPTS inspection (they are trivial for NuSMV). Moreover, by formalizing the properties we can beŠer assess and overcome vagueness or •Networks →Protocol correctness; •‡eory of computation under-speci€cation in the RFC standards. →Active learning; •So ware and its engineering →Model Œis paper is born out of two recent theses [19, 29], and is to checking; •Security and privacy →Logic and veri€cation; Net- our knowledge the €rst combined application of model learning work security; and model checking in verifying SSH implementations, or more KEYWORDS generally, implementations of any network security protocol. Model learning, Model checking, SSH protocol Related work. Chen et al.[12] use the MOPS so‰ware model ACM Reference format: checking tool to detect security vulnerabilities in the OpenSSH C Paul Fiterau-Bro˘ s¸tean, Toon Lenaerts, Erik Poll, Joeri de Ruiter, Frits Vaan- implementation due to violation of folk rules for the construction drager, and Patrick Verleg. 2017. Model Learning and Model Checking of of secure programs such as “Do not open a €le in writing mode SSH Implementations. In Proceedings of International SPIN Symposium on Model Checking of So‡ware , Santa Barbara, CA, USA, July 2017 (SPIN’17), to stdout or stderr”. Udrea et al.[27] also investigated SSH imple- 10 pages. mentations for logical ƒaws. Œey used a static analysis tool to DOI: 10.1145/3092282.3092289 check two C implementations of SSH against an extensive set of rules. Œese rules not only express properties of the SSH protocol 1 INTRODUCTION logic, but also of message formats and support for earlier versions and various options. Our analysis only considers the protocol logic. SSH is a security protocol that is widely used to interact securely However, their rules were tied to routines in the code, so had to be with remote machines. Œe Transport layer of SSH has been sub- slightly adapted to €t the di‚erent implementations. In contrast, jected to security analysis [31], incl. analyses that revealed crypto- our properties are de€ned at an abstract level so do not need such graphic shortcomings [5, 7, 20]. tailoring. Moreover, our black box approach means we can analyze Whereas these analyses consider the abstract cryptographic pro- any implementation of SSH, not just open source C implementa- tocol, this paper looks at actual implementations of SSH, and in- tions. vestigates ƒaws in the program logic of these implementations, Formal models of SSH in the form of state machines have been rather than cryptographic ƒaws. Such logical ƒaws have occurred used before, namely for a manual code review of OpenSSH [23], in implementations of other security protocols, notably TLS, with formal program veri€cation of a Java implementation of SSH [22], Apple’s ’goto fail’ bug and the FREAK aŠack [8]. For this we use and for model based testing of SSH implementations [9]. All this ∗Supported by NWO project 612.001.216, Active Learning of Security Protocols research only considered the SSH Transport layer, and not the other (ALSEP). SSH protocol layers. Permission to make digital or hard copies of all or part of this work for personal or Model learning has previously been used to infer state machines classroom use is granted without fee provided that copies are not made or distributed of EMV bank cards [3], electronic passports [4], hand-held readers for pro€t or commercial advantage and that copies bear this notice and the full citation for online banking [11], and implementations of TCP [14] and on the €rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permiŠed. To copy otherwise, or republish, TLS [25]. Some of these studies relied on manual analysis of learned to post on servers or to redistribute to lists, requires prior speci€c permission and/or a models [3, 4, 25], but some also used model checkers [11, 14]. fee. Request permissions from [email protected]. Instead of using active learning as we do, it is also possible to SPIN’17, Santa Barbara, CA, USA © 2017 ACM. 978-1-4503-5077-8/17/07...$15.00 use passive learning to obtain protocol state machines [30]. Here DOI: 10.1145/3092282.3092289 network trac is observed, and not actively generated. Œis can then provide a probabilistic characterization of normal network trac, but it cannot uncover implementation ƒaws that occur in strange message ƒows, which is our goal.

2 MODEL LEARNING Figure 1: SSH protocol layers 2.1 Mealy machines A Mealy machine is a tuple M = (I,O,Q,q0, δ, λ), where I is a €nite inputs to abstract inputs and concrete outputs to abstract outputs. set of inputs, O is a €nite set of outputs, Q is a €nite set of states, For a thorough discussion of mappers, we refer to [2]. q0 ∈ Q is the initial state, δ : Q × I → Q is a transition function, and λ : Q × I → O is an output function. Output function λ is 3 THE SECURE SHELL PROTOCOL extended to sequences of inputs by de€ning, for all q ∈ Q, i ∈ I and Œe Secure Shell Protocol (or SSH) is a protocol used for secure ∗ σ ∈ I , λ(q, ϵ) = ϵ and λ(q,iσ) = λ(q,i)λ(δ(q,i), σ). Œe behavior remote login and other secure network services over an insecure ∗ ∗ of Mealy machine M is de€ned by function AM : I → O with network. It runs as an application layer protocol on top of TCP, 0 ∗ AM(σ) = λ(q , σ), for σ ∈ I . Mealy machines M and N are which provides reliable data transfer, but does not provide any form ∗ equivalent, denoted M ≈ N, i‚ AM = AN. Sequence σ ∈ I of connection security. Œe initial version of SSH was superseded distinguishes M and N if and only if AM(σ) , AN(σ). by a second version (SSHv2), a‰er the former was found to contain design ƒaws which could not be €xed without losing backwards 2.2 MAT Framework compatibility [15]. Œis work focuses on SSHv2. Œe most ecient algorithms for model learning (see [17] for a SSHv2 follows a client-server paradigm. Œe protocol consists recent overview) all follow the paŠern of a minimally adequate of three layers (Figure 1): teacher (MAT) as proposed by Angluin [6]. Here learning is viewed (1) Œe transport layer protocol (RFC 4253 [35]) forms the basis as a game in which a learner has to infer an unknown automaton for any communication between a client and a server. It by asking queries to a teacher. Œe teacher knows the automaton, provides con€dentiality, integrity and server authentica- which in our seŠing is a Mealy machine M, also called the System tion as well as optional compression. Under Learning (sul). Initially, the learner only knows the input (2) Œe user authentication protocol (RFC 4252 [32]) is used to alphabet I and output alphabet O of M. Œe task of the learner is authenticate the client to the server. to learn M via two types of queries: (3) Œe connection protocol (RFC 4254 [33]) allows the en- crypted channel to be multiplexed in di‚erent channels. • With a membership query, the learner asks what the re- Œese channels enable a user to run multiple applications, sponse is to an input sequence σ ∈ I ∗. Œe teacher answers such as terminal emulation or €le transfer, over a single with the output sequence in A (σ). M SSH connection. • With an equivalence query, the learner asks whether a hypothesized Mealy machine H is correct, that is, whether Each layer has its own speci€c messages. Œe SSH protocol is H ≈ M. Œe teacher answers yes if this is the case. Other- interesting in that outer layers do not encapsulate inner layers, and wise it answers no and supplies a counterexample, which is di‚erent layers can interact. For this reason, we opt to analyze SSH a sequence σ ∈ I ∗ that triggers a di‚erent output sequence as a whole, instead of analyzing its constituent layers independently. for both Mealy machines, that is, AH(σ) , AM(σ). Below we discuss each layer, outlining the relevant messages which are later used in learning, and characterizing the so-called happy Œe MAT framework can be used to learn black box models of ƒow that a normal protocol run follows. so‰ware. If the behavior of a so‰ware system, or System Under At a high level, a typical SSH protocol run uses the three con- Learning (sul), can be described by some unknown Mealy machine stituent protocols in the order given above: a‰er the client estab- M, then a membership query can be implemented by sending lishes a TCP connection with the server, (1) the two sides use the inputs to the sul and observing resulting outputs. An equivalence Transport layer protocol to negotiate key exchange and encryption query can be approximated using a conformance testing tool [18] algorithms, and use these to establish session keys, which are then via a €nite number of test queries. A test query consists of asking used to secure further communication; (2) the client uses the user ∗ the sul for the response to an input sequence σ ∈ I , similar to authentication protocol to authenticate to the server; (3) the client a membership query. Note that this cannot rule out that there is uses the connection protocol to access services on the server, for more behavior that has not been discovered. example the terminal service.

2.3 Abstraction 3.1 Transport layer Most current learning algorithms are only applicable to Mealy SSH runs over TCP, and provides end-to-end con€dentiality and machines with small alphabets comprising abstract messages. Prac- integrity using session keys. Once a TCP connection has been es- tical systems typically have parameterized input/output alphabets, tablished with the server, these session keys are securely negotiated whose application triggers updates on the system’s state variables. using a key exchange algorithm, the €rst step of the protocol. Œe To learn these systems we place a mapper between the learner key exchange begins by the two sides exchanging their preferences and the sul. Œe mapper is a transducer which translates concrete for the key exchange algorithm to be used, as well as encryption, 2 CH_SEND_DATA... CH_OPEN/ compression and hashing algorithms. Preferences are sent with chan CH_REQUEST_PTY/ CH_OPEN_SUCCESS CH_SUCCESS a kexinit message. Subsequently, key exchange using the nego- CH_CLOSE/ auth pty tiated algorithm takes place. Following this algorithm, one-time CH_CLOSE_SUCCESS session keys for encryption and hashing are generated by each side, together with an identi€er for the session. Œe main key exchange Figure 4: ‡e happy ƒow for the Connection layer. algorithm is Die-Hellman, which is also the only one required "KEX30" (seq=16, len=358, payload=...) by the RFC. For the Die-Hellman scheme, kex30 and kex31 are Learner Mapper SUT exchanged to establish fresh session keys. Œese keys are used from "KEX31" (seq=17, len=214, payload=...) the moment the newkeys command has been issued by both parties. A subsequent sr auth requests the authentication service. Œe Figure 5: ‡e SSH learning setup. happy ƒow thus consists of the succession of the three steps com- prising key exchange, followed up by a successful authentication service request. Œe sequence is shown in Figure 2. 4 THE LEARNING SETUP Œe learning setup consists of three components: the learner, KEXINIT/ KEX30/ NEWKEYS/ SR_AUTH/ KEXINIT KEX31 NEWKEYS SR_ACCEPT init pre-kex kexed keyed pre-auth the mapper and the sul. Œe learner generates abstract inputs, representing SSH messages. Œe mapper transforms these messages Figure 2: ‡e happy ƒow for the Transport layer. into well-formed SSH packets and sends them to the sul. Œe sul sends response packets back to the mapper, which in turn, Key re-exchange [35, p. 23], or rekeying, is an almost identical translates these packets to abstract outputs. Œe mapper then sends process, the di‚erence being that instead of taking place at the the abstract outputs back to the learner. beginning, it takes place once session keys are already in place. Œe learner uses LearnLib [24], a Java library implementing Œe purpose is to renew session keys so as to foil potential replay L∗ based algorithms for learning Mealy machines. Œe mapper is aŠacks [34, p. 17]. It follows the same steps as key exchange. A based on Paramiko, an open source SSH implementation wriŠen in fundamental property of rekeying is that it should preserve the Python1. We opted for Paramiko because its code is relatively well state; that is, a‰er the rekeying procedure is completed, the protocol structured and documented. Œe sul can be any existing implemen- should be in the same state as it was before the rekeying started, tation of an SSH server. Œe three components communicate over with as only di‚erence that new keys are now in use. sockets, as shown in Figure 5. SSH is a complex client-server protocol. In our work so far 3.2 Authentication layer we concentrated on learning models of the implementation of the Once a secure tunnel has been established, the client can authen- server, and not of the client. We further restrict learning to only ex- ticate. For this, four authentication methods are de€ned in RFC ploring the terminal service of the Connection layer, as we consider 4252 [32]: password, public-key, host-based and none. Œe authen- it to be the most interesting from a security perspective. Algorithms tication request includes a user name, service name and authentica- for encryption, compression and hashing are le‰ to default seŠings tion data, which consists of both the authentication method as well and are not purposefully explored. Also, the starting state of the sul as the data needed to perform the actual authentication, such as the is one where a TCP connection has already been established and password or public key. Œe happy ƒow for this layer, as shown in where SSH versions have been exchanged, which are prerequisites Figure 3, is simply a single protocol step that results in a successful for starting the Transport layer protocol. authentication. Œe messages ua pw ok and ua pk ok achieve this for respectively password and public key authentication. 4.1 ‡e learning alphabet Œe alphabet we use consists of inputs, which correspond to mes- UA_PK_OK/UA_SUCCESS UA_PW_OK/UA_SUCCESS sages sent to the server, and outputs, which correspond to messages pre-auth auth received from the server. We split the input alphabet into three parts, one for each of the protocol layers. Figure 3: ‡e happy ƒow for the user Authentication layer. Learning does not scale with a growing input alphabet, and since we are only learning models of servers, we remove those inputs that 2 3.3 Connection layer are not intended to ever be sent to the server . Furthermore, from the Connection layer we only use messages for channel manage- Successful authentication makes services of the Connection layer ment and the terminal functionality. Finally, because we will only available. Œe Connection layer enables the user to open and explore protocol behavior a‰er SSH versions have been exchanged, close channels of various types, with each type providing access we exclude the messages for exchanging version numbers. to speci€c services. Of the various services available, we focus Œe resulting lists of inputs for the three protocol layers are on the remote terminal over a session channel, a classical use given in Tables 1-3. In some experiments, we used only a subset of SSH. Œe happy ƒow consists of opening a session channel, of the most essential inputs, to further speed up experiments. Œis ch open, requesting a “pseudo terminal” ch re€est pty, option- ally sending and managing data via the messages ch send data, 1Paramiko is available at hŠp://www.paramiko.org/ 2Œis means we exclude the messages service accept, ua accept, ua failure, ch window adjust, ch send eof, and eventually closing the chan- ua banner, ua pk ok, ua pw changereq, ch success and ch failure from our nel via ch close, as depicted in Figure 4. alphabet. 3 restricted alphabet signi€cantly decreases the number of queries Table 3: Connection layer inputs needed for learning models while only marginally limiting explored Message Description behavior. We discuss this again in Section 5. Inputs included in the ch open* Opens a new channel [33, p. 5] restricted alphabet are marked by ’*’ in the tables below. ch close* Closes a channel [33, p. 9] Table 1 lists the Transport layer inputs. We include a version ch eof* Indicates that no more data will be sent [33, p. 9] of the kexinit message with first kex packet follows disabled. ch data* Sends data over the channel [33, p. 7] Œis means no guess [35, p. 17] is aŠempted on the sul’s parameter ch edata Sends typed data over the channel [33, p. 8] preferences. Consequently, the sul will have to send its own kex- ch window adjust Adjusts the window size [33, p. 7] init in order to convey its own parameter preferences before key ch re€est pty* Requests terminal emulation [33, p. 11] exchange can proceed. Also included are inputs for establishing new keys (kex30, newkeys), disconnecting (disconnect), as well as the special inputs ignore, unimpl and debug. Œe laŠer are response to service requests (sr auth and sr conn), ua success not interesting, as they are normally ignored by implementations. and ua failure [32, p. 5,6] in response to authentication requests, Hence they are excluded from our restricted alphabet. disconnect and ch open success [33, p. 6] and ch success [33, p. 10] , in proved costly time wise, so was also excluded. positive response to ch open and ch re€est pty respectively. To these outputs, we add no resp for when the sul generates no Table 1: Transport layer inputs output, and the special outputs ch none, ch max and no conn, and buffered, which we discuss in the next subsections. Message Description disconnect Terminates the current connection [35, p. 23] ignore Has no intended e‚ect [35, p. 24] 4.2 ‡e mapper unimpl Intended response to unrecognized messages [35, p. 25] Œe mapper must provide a translation between abstract messages debug Provides other party with debug information [35, p. 25] and well-formed SSH messages: it has to translate abstract inputs kexinit* Sends parameter preferences [35, p. 17] listed in Tables 1-3 to actual SSH packets, and translate the SSH kex30* Initializes the Die-Hellman key exchange [35, p. 21] packets received in answer to our abstract outputs. If no answer it newkeys* Requests to take new keys into use [35, p. 21] received on an input, the mapper must return an output indicating sr auth* Requests the authentication protocol [35, p. 23] timeout, which in our case is the no resp message. sr conn* Requests the connection protocol [35, p. 23] Œe sheer complexity of the mapper meant that it was easier Œe Authentication layer de€nes a single client message type for to adapt an existing SSH implementation, rather than construct the authentication requests [32, p. 4]. Its parameters contain all in- the mapper from scratch. A‰er all, in many ways the mapper acts formation needed for authentication. Four authentication methods similar to an SSH client. Paramiko already provides mechanisms exist: none, password, public key and host-based. Our mapper sup- for encryption/decryption, as well as routines for constructing and ports all methods except host-based authentication because some sending the di‚erent types of packets, and for receiving them. Œese SUTs don’t support this feature. Both the public key and password routines are called by control logic dictated by Paramiko’s own state methods have ok and nok variants, which provide respectively machine. Œe mapper was constructed by replacing this control correct and incorrect credentials. Our restricted alphabet supports logic with one dictated by messages received from the learner. only public key authentication, as the implementations processed Œe mapper maintains a set of state variables to record param- this faster than the other authentication methods. eters of the ongoing session, including the server’s preferences for key exchange and encryption algorithm, parameters of these Table 2: Authentication layer inputs protocols, and, once it has been established, the session key. Œese parameters are updated when receiving messages from the server Message Description and used to concretize inputs to actual SSH messages to the server. ua none Authenticates with the “none” method [32, p. 7] ua pk ok* Provides a valid name/key pair [32, p. 8] For example, upon receiving a kexinit from the sul, the mapper ua pk nok* Provides an invalid name/key pair [32, p. 8] saves the sul’s preferences for key exchange, hashing and encryp- ua pw ok Provides a valid name/password pair [32, p. 10] tion algorithms. Initially these parameters are all set to the defaults ua pw nok Provides an invalid name/password pair [32, p. 10] that any server should support, as required by the RFC. On receiv- ing kex31 in response to the kex30 input, the mapper saves the Œe Connection layer allows clients to manage channels and hash, as well as the new keys. Finally, a newkeys response prompts request services over them. In accordance with our learning goal, the mapper to use the new keys negotiated earlier in place of the our mapper only supports inputs for requesting terminal emula- older ones, if such existed. tion, plus inputs for channel management as shown in Table 3. Œe mapper also contains a bu‚er for storing opened channels, Œe restricted alphabet only supports the most general channel which is initially empty. On a ch open from the learner, the mapper management inputs, and excludes those not expected to produce adds a channel to the bu‚er with a randomly generated channel state change. identi€er; on a ch close, it removes the channel (if there was any). Še output alphabet includes all messages an SSH server gen- Œe bu‚er size, or the maximum number of opened channels, is erates, which may include, with identical meaning, any of the limited to one. Initially the bu‚er is empty. Œe mapper also stores messages de€ned as inputs. Œis also includes responses to var- the sequence number of the last received message from the sul. ious requests: kex31 [35, p. 21] as reply to kex30, sr succes in Œis number is then used when constructing unimpl inputs. 4 In the following cases, inputs are answered by the mapper di- previously been opened. Learning this behavior would lead to rectly instead of being sent to the sul to €nd out its response: (1) an in€nite state machine, as we would need a state ‘there are n on receiving a ch open input if the bu‚er has reached the size channels open’ for every number n. For this reason, we restrict limit, the mapper directly responds with ch max; (2) on receiv- the number of simultaneously open channels to one. Œe mapper ing any input operating on a channel (all Connection layer inputs returns a custom response ch max to a ch open message whenever other than ch open) when the bu‚er is empty, the mapper directly this limit is reached. responds with ch none; (3) if connection with the sul was termi- nated, the mapper responds with a no conn message, as sending further messages to the sul is pointless in that case. 5 LEARNING RESULTS We use the setup described in Section 4 to learn models for OpenSSH, 4.3 Practical complications Bitvise and DropBear SSH server implementations. OpenSSH rep- SSH implementations even behind the mapper abstraction may not resents the focal point, as it is the most popular implementation behave like deterministic Mealy Machines, a prerequisite for the of SSH (with over 80 percent of market share in 2008 [5]) and the learning algorithm to succeed. Sources of non-determinism are: default server for many UNIX-based systems. DropBear is an alter- (1) Underspeci€cation in the SSH speci€cation (for example, native to OpenSSH designed for low resource systems. Bitvise is a by not specifying the order of certain messages) allows well-known proprietary Windows-only SSH implementation. some non-deterministic behavior. Even if client and server In our experimental setup, learner and mapper ran inside a do implement a €xed order for messages they sent, the Linux Virtual Machine. OpenSSH and DropBear were learned over asynchronous nature of communication means that the a localhost connection, whereas Bitvise was learned over a virtual interleaving of sent and received messages may vary. More- connection with the Windows host machine. We have adapted the over, client and server are free to intersperse debug and seŠing of timing parameters to each implementation. ignore messages at any given time3 OpenSSH was learned using a full alphabet, whereas DropBear (2) Timing is another source of non-deterministic behavior. and Bitvise were learned using a restricted alphabet (as de€ned in For example, the mapper might time-out before the sul Subsection 4.1). Œe reason for using a restricted alphabet was to re- had sent its response. Some suls also behave unexpectedly duce learning times. Based on the model learned for OpenSSH (the when a new input is received too shortly a‰er the previ- €rst implementation analyzed) and the speci€cation, we excluded ous one. Hence in our experiments we adjusted time-out inputs that seemed unlikely to produce state change (such as debug periods accordingly so that neither of these events occur, or unimpl). We also excluded inputs that proved costly time-wise and the sul behaves deterministically all the time. (such as disconnect) but were not were not needed to visit all states in the happy ƒow. We excluded, for example, the user/pass- To detect non-determinism, the mapper caches all observations in word based authentication inputs (ua pw ok and ua pw nok) as an SQLite database and veri€es if new observations are consistent they would take the system 2-3 seconds to respond to. By contrast, with previous ones. If not, it raises a warning, which then needs public key authentication resulted in quick responses. to be manually investigated. We analyzed each warning until we For the test queries we used random and exhaustive variants of found a seŠing under which behavior was deterministic. the testing algorithm described in [26], which generate ecient Œe cache also acts as a cheap source of responses for already test suites. Tests generated comprise an access sequence, a middle answered queries. Finally, by re-loading the cache from a previous section of length k and a distinguishing sequence. Œe exhaustive experiment, we were able to start from where this experiment le‰ variant generates tests for all possible middle sections of length o‚. Œis proved useful, as experiments could take several days. k and all states. Passing all tests then provides some notion of Another practical problem besides non-determinism is that an con€dence, namely, that the learned model is correct unless the SSH server may produce a sequence of outputs in response to a (unknown) model of the implementation has at least k more states single input. Œis means it is not behaving as a Mealy machines, than the learned hypothesis. Œe random variant produces tests which allows for only one output. To deal with this, the mapper with randomly generated middle sections. No formal con€dence concatenates all outputs into one, and it produces this sequence as is provided, but past experience shows this to be more e‚ective at the single output to the learner. €nding counterexamples since k can be set to higher values. We A €nal challenge is presented by forms of ‘bu‚ering’, which executed a random test suite with k of 4 comprising 40000 tests for we encountered in two situations. Firstly, some implementations OpenSSH, and 20000 tests for Bitvise and DropBear. We then ran bu‚er incoming requests during rekey; only once rekeying is com- an exhaustive test suite with k of 2 for all implementations. plete are all these messages processed. Œis leads to a newkeys Table 4 describes the exact versions of the systems analyzed response (indicating rekeying has completed), directly followed together with statistics on learning and testing: (1) the number by all the responses to the bu‚ered requests. Œis would lead to of states in the learned model, (2) the number of hypotheses built non-termination of the learning algorithm, as for every sequence during the learning process and (3) the total number of learning of bu‚ered messages the response di‚ers. To prevent this, we treat and test queries run. For test queries, we only consider those the sequence of queued responses as the single output buffered. run on the last hypothesis. All learned models and the prop- A di‚erent form of bu‚ering occurs when opening and closing erties checked are at hŠps://gitlab.science.ru.nl/p€teraubrostean/ channels, since a sul can close only as many channels as have Learning-SSH-Paper/tree/master/models. Œe statistics give a glimpse 3Œe ignore messages are aimed to thwart trac analysis. into the issue of scalability. Assuming each input took 0.5 seconds 5 Transport layer

init

KEXINIT, SR_*, UNIMPL, DEBUG, IGNORE, KEX30 / KEXINIT

keyed

KEX30 / KEX31+NEWKEYS

pre-kex

NEWKEYS / NO_RESP

kexed

SR_AUTH / SR_ACCEPT Authentication layer

CH_*, KEXINIT, KEX30 / UNIMPL pre-auth

UA_PK_NOK / UA_FAILURE UA_PW_NOK / UA_FAILURE UA_NONE / UA_FAILURE

UA_{PK_OK, PW_OK} / UA_SUCCESS pk_fail UA_PK_NOK / UA_FAILURE pw_fail UA_PW_NOK / UA_FAILURE none_fail UA_NONE / UA_FAILURE

UA_PW_OK / UA_SUCCESS Connection layer

auth

CH_OPEN / CH_OPEN_SUCCESS CH_CLOSE / CH_CLOSE REKEY SEQUENCE *\{DEBUG, UNIMPL}

SR_*, UA_*, KEX30 CH_CLOSE / CH_CLOSE chan rauth / UNIMPL

CH_REQUEST_PTY / CH_SUCCESS UA_{*\PK_NOK} UA_{NONE, PK_*} UA_{*\NONE}

SR_*, KEX30 / NO_RESP SR_CONN / DISCONNECT pty rchan UA_* / UNIMPL DISCONNECT, NEWKEYS / NO_CONN

DISCONNECT, NEWKEYS rpty / NO_CONN

CH_REQUEST_PTY / NO_CONN / DISCONNECT

conn_lost UA_*, CH_* / KEXINIT+DISCONNECT

Figure 6: Model of the OpenSSH server. 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 mapper, as well as states present in successful rekeying sequences. Wherever rekeying was permiŠed, we replaced the rekeying states and transitions by a single 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 ƒow. ’+’ concatenates multiple outputs. to process, and an average query length of 10, to perform 40000 of states. For each state where rekeying is possible, the sequence queries would have taken roughly 55 hours. Œis is consistent with of transitions constituting the complete rekeying process should the time experiments took, which span several days. Œe long du- lead back to that state. Œis leads to two additional rekeying states ration compelled us to resort to restricted alphabets, which lead to for every state allowing rekey. Many states were also added due to reduction in the number of queries needed. Our work could have the mapper generated outputs ch none or ch max, outputs which bene€ted from parallel execution. signal that no channel is open or that the maximum number of channels have been opened. Table 4: Statistics for learning experiments Figure 6 shows the model learned for OpenSSH, with some edits to improve readability. Œe happy ƒow, in green, is fully explored SUT States Hypotheses Mem. Q. Test Q. in the model and mostly matches our earlier description of it4. Also OpenSSH 6.9p1-2 31 4 19836 76418 explored is what happens when a rekeying sequence is aŠempted. Bitvise 7.23 65 15 24996 58423 We notice that rekeying is only allowed in states of the Connection DropBear v2014.65 29 8 8357 64478 layer. Strangely, for these states, rekeying is not state preserving, as the generated output on receiving a sr auth, sr conn or kex30 Œe large number of states is down to several reasons. First changes from unimpl to no resp. Œis leads to two sub-clusters of of all, some systems exhibited bu‚ering behavior. In particular, states, one before the €rst rekey, the other a‰erward. In all other Bitvise would queue responses for higher layer inputs sent during 4Œe only exception is in the Transport layer, where unlike in our happy ƒow de€nition, key re-exchange, and would deliver them all at once a‰er rekeying the server is the €rst to send the newkeys message. Œis is also accepted behavior, as was done. Rekeying was also a major contributor to the number the protocol does not specify which side should send newkeys €rst. 6 states, the €rst step of a rekeying (kexinit) yields (unimpl), while careful when we interpret model checking results for the learned the last step (newkeys) causes the system to disconnect. model. Also, we must be aware that when some property does not We also note the intricate authentication behavior: a‰er an un- hold for the abstract model, and the model checker provides a coun- successful authentication aŠempt the only authentication method terexample, we still need to check whether this counterexample is still allowed is password authentication. Finally, only Bitvise al- an actual run of the abstraction of the sul induced by the mapper. lowed multiple terminals to be requested over the same channel. As If this is not the case then the counterexample demonstrates that depicted in the model, OpenSSH abruptly terminates on requesting the learned model is incorrect. a second terminal. DropBear exhibits a similar behavior. Before introducing the properties, we mention some basic predi- cates and conventions we use in their de€nition. Œe happy ƒow in 6 SECURITY SPECIFICATIONS SSH consists in a series of steps: the user (1) exchanges keys, (2) A NuSMV model is speci€ed by a set of €nite variables together requests for the authentication service, (3) supplies valid creden- with a transition-function that describes changes on these vari- tials to authenticate and €nally (4) opens a channel. Whereas step ables. Speci€cations in temporal logic, such as CTL and LTL, can (1) is complex, the subsequent steps can be captured by the sim- be checked for truth on speci€ed models. NuSMV provides a coun- ple predicates hasReqAuth, validAuthReq and hasOpenedChannel terexample if a given speci€cation is not true. We generate NuSMV respectively. Œe predicates are de€ned in terms of the output models automatically from the learned models. Generation pro- generated at a given moment, with certain values of this output ceeds by €rst de€ning a NuSMV €le with three variables, corre- indicating that the step was performed successfully. For example, sponding to inputs, outputs and states. Œe transition-function is ch open success indicates that a channel has been opened suc- then extracted from the learned model and appended to this €le. cessfully. Sometimes we also need the input that generated the Œis function updates the output and state variables for a given output, so as to distinguish this step from other steps. In particular, valuation of the input variable and the current state. Figure 7 gives requesting the authentication service is distinguished from request- an example of a Mealy machine and its associated NuSMV model. ing the connection service by sr auth. To these predicates, we add predicates for valid, invalid and all authentication methods, a predicate for the receipt of newkeys from the server, and receipt of MSG/NOK MODULE main VAR s t a t e : {q0 , q1 }; kexinit, which can also be seen as initiation of key (re-) exchange. inp : {BEGIN , MSG}; out : {OK, NOK, ACK}; Œese last predicates have to be tweaked in accordance with the start q0 ASSIGN input alphabet used and with the output the sul generated (kexinit init(state) := q0; next(state) := case could be sent in di‚erent packaging, either alone, or joined by a state = q0 & inp = BEGIN: q1; di‚erent message). Œeir formulations below are for the OpenSSH state = q0 & inp = MSG: q0; BEGIN/OK state = q1 & inp = BEGIN: q1; server. Finally, connLost indicates that connection was lost, and state = q1 & inp = MSG: q1; e s a c ; endCondition is the condition a‰er which higher layer properties out : = c a s e no longer have to hold. q state = q0 & inp = BEGIN: OK; 1 BEGIN/OK state = q0 & inp = MSG: NOK; state = q1 & inp = BEGIN: OK; hasReqAuth : = inp =SR AUTH & out=SR ACCEPT; state = q1 & inp = MSG: ACK; validAuthReq : = out =UA PK OK | out =UA PW OK ; MSG/ACK e s a c ; hasOpenedChannel : = out =CH OPEN SUCCESS; validAuthReq : = inp =UA PK OK | inp =UA PW OK ; invAuthReq | | Figure 7: Mealy machine + associated NuSMV code : = inp =UA PK NOK inp =UA PW NOK inp =UA NONE ; authReq := validAuthReq | invalidAuthReq ; received N ewKeys : = out =NEWKEYS | out =KEX31 NEWKEYS; Œe remainder of this section de€nes the properties we formal- kexStarted := out=KEXINIT; connLost : = out =NO CONN | out =DISCONNECT ; ized and veri€ed. We group these properties into four categories: endCondition := kexStarted | connLost ; (1) basic characterizing properties, properties which character- ize the mapper and sul assembly at a basic level. Œese Our formulation uses NuSMV syntax. We also use the weak until hold for all implementations. operator W, which is not supported by NuSMV, but can be easily (2) security properties, these are properties fundamental to de€ned in terms of the until operator U and globally operator G achieving the main security goal of the respective layer. that are supported: pW q = p U q | G p. Many of the higher layer (3) key re-exchange properties, or properties regarding the rekey properties we formulate should hold only until a disconnect or a key operation (a‰er the initial key exchange was done). (re-)exchange happens, hence the de€nition of the endCondition (4) functional properties, which are extracted from the SHOULD’s predicate. Œis is because the RFCs don’t specify what should hap- and the MUST’s of the RFC speci€cations. Œey may have pen when no connection exists. Moreover, higher layer properties a security impact. in the RFCs only apply outside of rekey sequences, as inside a rekey A key point to note is that properties are checked not on the ac- sequence the RFCs advise implementations to reject all higher layer tual concrete model of the sul, but on an abstraction of the sul that inputs, regardless of the state before the rekey. is induced by the mapper. Œis is unlike in [14], where properties where checked on a concretization of the learned model obtained 6.1 Basic characterizing properties by application of a reverse mapping. Building a reverse mapper is In our seŠing, a single TCP connection is made and once this far from trivial given the mapper’s complexity. Œus we need to be connection is lost (e.g. because the system disconnects) it cannot 7 be re-established. Œe moment a connection is lost is marked by Apart from a secure connection, Connection layer services also generation of the no conn output. From this moment onwards, assume that the client behind the connection was authenticated. the only outputs encountered are the no conn output (the mapper Œis is ensured by the Authentication layer by means of an authen- tried but failed to communicate with the sul), or outputs generated tication mechanism, which only succeeds, and thus authenticates by the mapper directly, without querying the system. Œe laŠer the client, if valid credentials are provided. For the implementation are ch max (channel bu‚er is full) and ch none (channel bu‚er is to be secure, there should be no path from an unauthenticated to an empty). With these outputs we de€ne Property 1 which describes authenticated state without the provision of valid credentials. We the “one connection” property of our setup. consider an authenticated state as a state where a channel has been opened successfully, described by the predicate hasOpenedChannel. Property 1. G ( o u t =NO CONN −> Provision of valid/invalid credentials is indicated by the outputs G ( o u t =NO CONN | o u t =CH MAX | o u t =CH NONE ) ) ua success and ua failure respectively. Along these lines, we Outputs ch max and ch none are still generated because of a formulate this speci€cation by Property 4, where S stands for the characteristic we touched on in Subsection 4.2. Œe mapper main- since operator. Formula pSq is true at time t if q held at some time 0 00 0 00 tains a bu‚er of open channels and limits its size to 1. From the t ≤ t and p held in all times t such that t < t ≤ t. perspective of the mapper, a channel is open, and thus added to the Property 4. G ( hasOpenedChannel −> bu‚er, whenever ch open is received from the learner, regardless o u t ! = UA FAILURE S out=UA SUCCESS) if a channel was actually opened on the sul. In particular, if a‰er opening a channel via ch open an additional aŠempt to open a 6.3 Key re-exchange properties channel is made, the mapper itself responds by ch max without querying the sul. Œis continues until the learner closes the chan- According to the RFC [33, p. 24], re-exchanging keys (or rekeying) nel by ch close, prompting removal of the channel and the sending (1) is preferably allowed in all states of the protocol, and (2) its of an actual CLOSE message to the sul (hence out!=ch none). A successful execution does not a‚ect operation of the higher layers. converse property can be formulated in a similar way for when We consider two general protocol states, pre-authenticated (a‰er a the bu‚er is empty a‰er a ch close, in which case subsequent successful authentication request, before authentication) and au- ch close messages prompt the mapper generated ch none, until a thenticated. Œese may map to multiple states in the learned models. channel is opened via ch open and an actual OPEN message is sent We formalized requirement (1) by two properties, one for each gen- to the sul. Conjunction of these two behaviors forms Property 2. eral state. In the case of the pre-authenticated state, we know we have reached this state following a successful authentication ser- Property 2. (G ( i np =CH OPEN) −> vice request, indicated by the predicate hasReqAuth. Once here, X ( ( i np =CH OPEN −> o u t =CH MAX) performing the inputs for rekey in succession should imply success W ( inp =CH CLOSE & out!=CH NONE ) ) ) & (G ( i np =CH CLOSE) −> until one of two things happen, the connection is lost(connLost) or X ( ( i np =CH CLOSE −> o u t =CH NONE ) we have authenticated. Œis is asserted in Property 5. A similar W ( inp =CH OPEN & out!=CH MAX) ) ) property is de€ned for the authenticated state.

Property 5. G ( hasReqAuth −> 6.2 Security properties X (inp=KEXINIT −> out=KEXINIT & In SSH, upper layer services rely on security guarantees ensured by X ( inp=KEX30 −> o u t =KEX31 NEWKEYS& lower layers. So these services should not be available before the X ( i np =NEWKEYS −> o u t =NO RESP)))W lower layers have completed. For example, the authentication ser- ( c o n n L o s t | hasAuth ) ) a‡er vice should only become available a successful key exchange Requirement (2) cannot be expressed in LTL, since in LTL we and the seting up of a secure tunnel by the Transport layer, other- cannot specify that two states are equivalent. We therefore checked wise the service would be running over an unencrypted channel. this requirement directly, by writing a simple script which, for each Requests for this service should therefore not succeed unless key state q that allows rekeying, checks if the state q0 reached a‰er a exchange was performed successfully. successful rekey is equivalent to q in the subautomaton that only Key exchange involves three steps that have to be performed in contains the higher layer inputs. order but may be interleaved by other actions. Successful authenti- cation necessarily implies successful execution of the key exchange 6.4 Functional properties steps. We can tell each key exchange step was successful from the values of the input and output variables. Successful authentication We formalized and checked several other properties drawn from request is indicated by the predicate de€ned earlier, hasReqAuth. the RFCs. We found parts of the speci€cation unclear, which some- Following these principles, we de€ne the LTL speci€cation in Prop- times meant that we had to give our own interpretation. A €rst erty 3, where O is the once operator. Formula Op is true at time t if general property can be de€ned for the disconnect output. Œe p held in at least one of the previous time steps t 0 ≤ t. RFC speci€es that a‰er sending this message, a party MUST not send or receive any data [35, p. 24]. While we cannot tell what Property 3. G ( hasReqAuth −> the server actually receives, we can check that the server does not O ( (inp=NEWKEYS & out=NO RESP)& generate any output a‰er sending disconnect. A‰er a disconnect O ( (inp=KEX30 & out=KEX31 NEWKEYS)& message, subsequent outputs should be solely derived by the map- O (out=KEXINIT) ) ) ) per. Knowing the mapper induced outputs are no conn, ch max 8 and ch none, we formulate by Property 6 to describe expected Property 11. G ( o u t =UA SUCCESS −> outputs a‰er a disconnect. X ( ( authReq −> o u t =NO RESP ) W endCondition ) )

Property 6. G ( out=DISCONNECT −> Œe Connection layer RFC states in [33, p. 9] that on receiving X G ( o u t =CH NONE | o u t =CH MAX | o u t =NO CONN) ) a ch close message, a party MUST send back a ch close, unless it had already sent this message for the channel. Œe channel Œe RFC states in [33, p. 24] that a‰er sending a kexinit message, must have been opened beforehand (hasOpenedChannel) and the a party MUST not send another kexinit, or a sr accept message, property only has to hold until the end condition holds or the until it has sent a newkeys message(receivedNewKeys). Œis is channel was closed (out=CH CLOSE). We formulate Property 12 translated to Property 7. accordingly. − Property 7. G ( out=KEXINIT > Property 12. G ( hasOpenedChannel −> X ( ( o u t ! = SR ACCEPT & out!=KEXINIT) W receivedNewKeys) ) ( ( i np =CH CLOSE) −> ( o u t =CH CLOSE)) W ( endCondition | o u t =CH CLOSE)) Œe RFC also states [33, p. 24] that if the server rejects the service request, “it SHOULD send an appropriate SSH MSG DISCONNECT 6.5 Model checking results message and MUST disconnect”. Moreover, in case it supports the service request, it MUST send a sr accept message. Unfortunately, Table 5 presents model checking results. Crucially, the security it is not evident from the speci€cation if rejection and support are properties hold for all three implementations. We had to slightly the only allowed outcomes. We assume that is the case, and formal- adapt our properties for Bitvise as it bu‚ered all responses during ize an LTL formula accordingly by Property 8. For a service request rekey (incl. UA SUCCESS). In particular, we used validAuthReq (sr auth), in case we are not in the initial state, the response will be instead of out=UA SUCCESS as sign of successful authentication. either an accept (sr accept), disconnect (disconnect), or no conn, output generated by the mapper a‰er the connection is lost. We Table 5: Model checking results adjusted the property for the initial state since all implementations responded with kexinit which would easily break the property. Property Key word OpenSSH Bitvise DropBear We cannot yet explain this behavior. Security Trans. X X X Auth. X X X Property 8. G ( ( i np =SR AUTH & state!=s0) −> Rekey Pre-auth. X X X ( o u t =SR ACCEPT | out=DISCONNECT | o u t =NO CONN ) ) ) Auth. X X X Funct. Prop. 6 MUST X X X Œe RFC for the Authentication layer states in [32, p. 6] that Prop. 7 MUST X X X if the server rejects the authentication request, it MUST respond Prop. 8 MUST X* X X with a ua failure message. Rejected requests are suggested by the Prop. 9 MUST X X X predicate invAuthReq. In case of requests with valid credentials Prop. 10 MUST X X X (validAuthReq), a ua success MUST be sent only once. While not Prop. 11 SHOULD X* X* X explicitly stated, we assume this to be in a context where the au- Prop. 12 MUST X X X thentication service had been successfully requested, hence we use the hasReqAuth predicate. We de€ne two properties, Property 9 Properties marked with ’*’ did not hold because implementa- for behavior before an ua success, Property 10 for behavior af- tions chose to send unimpl, instead of the output suggested by the terward. For the €rst property, note that (hasReqAuth) may hold RFC. As an example, a‰er successful authentication, both Bitvise even a‰er successful authentication, but we are only interested in and OpenSSH respond with unimpl to further authentication re- behavior between the €rst time (hasReqAuth) holds and the €rst quests, instead of being silent, violating Property 11. Whether the time authentication is successful (out=ua success), hence the use alternative behavior adapted is acceptable is up for debate. Cer- of the O operator. As is the case with most higher layer properties, tainly the RFC does not suggest it, though it does leave room for the €rst property only has to hold until the end condition holds interpretation. (endCondition), that is the connection is lost (connLost) or rekey DropBear is the only implementation that allows rekeying in was started by the sul (kexStarted). both general states of the protocol. DropBear also satis€es all Transport and Authentication layer speci€cations, however, prob- Property 9. G ( (hasReqAuth & !O out=UA SUCCESS) −> lematically, it violates the property of the Connection layer. Upon − (invalidAuthReq > o u t =UA FAILURE) receiving ch close, it responds by ch eof instead of ch close, not W ( o u t =UA SUCCESS | endCondition) ) respecting Property 12. Property 10. G ( o u t =UA SUCCESS −> X G o u t ! = UA SUCCESS)

In the same paragraph, it is stated that authentication requests 7 CONCLUSIONS received a‰er a ua success SHOULD be ignored. Œis is a weaker We have combined model learning with abstraction techniques to statement, and it requires that all authentication messages (sug- infer models of the OpenSSH, Bitvise and DropBear SSH server gested by authReq) a‰er a ua success output should prompt no implementations. We have also formalized several security and response from the system(no resp) until the end condition is true. functional properties drawn from the SSH RFC speci€cations. We Œe formulation of this statement shown in Property 11. have veri€ed these properties on the learned models using model 9 checking and have uncovered several minor standard violations. [5] M.R. Albrecht, K.G. Paterson, and G.J. Watson. 2009. Plaintext Recovery AŠacks Œe security-critical properties were met by all implementations. against SSH. In SP’09. IEEE, Washington, DC, USA, 16–26. [6] D. Angluin. 1987. Learning regular sets from queries and counterexamples. Inf. Abstraction was provided by a mapper component placed be- and Comp. 75, 2 (Nov. 1987), 87–106. tween the learner and the sul. Œe mapper was constructed from [7] M. Bellare, T. Kohno, and C. Namprempre. 2004. Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then- an existing SSH implementation. Œe input alphabet of the mapper Encrypt-and-MAC Paradigm. ACM Trans. Inf. Syst. Secur. 7, 2 (2004), 206–241. explored key exchange, seŠing up a secure connection, several [8] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud, C. Fournet, M. Kohlweiss, A. authentication methods, and opening and closing channels over Pironti, P.-Y. Strub, and J. K. Zinzindohoue. 2017. A Messy State of the Union: Taming the Composite State Machines of TLS. CACM 60, 2 (2017), 99–107. which the terminal service could be requested. We used two input [9] E. Boss. 2012. Evaluating implementations of SSH by means of model-based testing. alphabets, a full version for OpenSSH, and a restricted version for Bachelor’s Œesis. Radboud University. Bitvise and DropBear. Œe restricted alphabet was still sucient to [10] S. Cassel, F. Howar, and B. Jonsson. 2015. RALib: A LearnLib extension for inferring EFSMs. In DIFTS. hŠp://www.faculty.ece.vt.edu/chaowang/di‰s2015/ explore most aforementioned behavior. papers/paper 5.pdf We encountered several challenges. Firstly, building a map- [11] G. Chalupar, S. Peherstorfer, E. Poll, and J. de Ruiter. 2014. Automated Reverse Engineering using LEGO. In Proc. USENIX workshop on O‚ensive Technologies per presented a considerable technical challenge, as it required (WOOT’14). 1–10. re-structuring of an actual SSH implementation. Secondly, because [12] H. Chen, D. Dean, and D. Wagner. 2004. Model Checking One Million Lines of we used classical learning algorithms, we had to ensure that the C Code. In NDSS. Œe Internet Society. hŠp://www.isoc.org/isoc/conferences/ ndss/04/proceedings/Papers/Chen.pdf abstracted implementation behaved like a (deterministic) Mealy [13] A. CimaŠi, E.M. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Machine. Here time-induced non-determinism was dicult to elim- Sebastiani, and A. Tacchella. 2002. NuSMV 2: An OpenSource Tool for Symbolic inate. Bu‚ering also presented problems, leading to a considerable Model Checking. In CAV (LNCS), Vol. 2404. Springer, 359–364. [14] P. Fiterau-Bro˘ s¸tean, R. Janssen, and F.W. Vaandrager. 2016. Combining Model increase in the number of states. Moreover, the systems analyzed Learning and Model Checking to Analyze TCP Implementations. In CAV’16 were relatively slow, which meant learning took several days. Œis (LNCS), Vol. 9780. Springer, 454–471. [15] A. Futoransky and E. Kargieman. 1998. An aŠack on CRC-32 in- was compounded by the size of the learning alphabet, and it forced tegrity checks of encrypted channels using CBC and CFB modes. On- us into using a reduced alphabet for two of the implementations. line. hŠps://www.coresecurity.com/system/€les/publications/2016/05/ Limitations of the work, hence possibilities for future work, are KargiemanPaceŠiRicharte 1998-CRC32.pdf, (1998). [16] O. Grinchtein, B. Jonsson, and M. Leucker. 2010. Learning of event-recording several. First of all, the mapper was not formalized, unlike in [14], automata. TCS 411, 47 (2010), 4029–4054. thus we did not produce a concretization of the abstract models. [17] M. Isberner. 2015. Foundations of Active Automata Learning: An Algorithmic Consequently, model checking results cannot be fully transferred Perspective. Ph.D. Dissertation. TU Dortmund. [18] D. Lee and M. Yannakakis. 1996. Principles and methods of testing €nite state to the actual implementations. Formal de€nition of the mapper machines — a survey. Proc. IEEE 84, 8 (1996), 1090–1123. and concretization of the learned models (as de€ned in [2]) would [19] T. Lenaerts. 2016. Improving Protocol State Fuzzing of SSH. Bachelor’s Œesis. Radboud University. tackle this. Œe mapper also caused considerable redundancy in the [20] K.G. Paterson and G.J. Watson. 2010. Plaintext-Dependent Decryption: A Formal learned models; tweaking the abstractions used, in particular those Security Treatment of SSH-CTR. In EUROCRYPT 2010. LNCS, Vol. 6110. Springer, for managing channels, could alleviate this problem while also im- 345–361. [21] D. Peled, M.Y. Vardi, and M. Yannakakis. 2002. Black Box Checking. Journal of proving learning times. Œis in turn would facilitate learning using Automata, Languages, and Combinatorics 7, 2 (2002), 225–246. expanded alphabets instead of resorting to restricted alphabets. [22] E. Poll and A. Schubert. 2007. Verifying an implementation of SSH. In WITS’07. Furthermore, the mapper abstraction could be re€ned, to give more 164–177. [23] E. Poll and A. Schubert. 2011. Rigorous speci€cations of the SSH Transport Layer. insight into the implementations. In particular, parameters such Technical Report. Radboud University. as the session identi€er could be extracted from the mapper and [24] H. Ra‚elt, B. Ste‚en, T. Berg, and T. Margaria. 2009. LearnLib: a framework for extrapolating behavioral models. STTT 11, 5 (2009), 393–407. potentially handled by existing Register Automata learners[1, 10]. [25] J. de Ruiter and E. Poll. 2015. Protocol State Fuzzing of TLS Implementations. In Œese learners can infer systems with parameterized alphabets, USENIX Security. USENIX Association, Washington, D.C., 193–206. state variables and simple operations on data. Finally, we sup- [26] W. Smeenk, J. Moerman, D.N. Jansen, and F.W. Vaandrager. 2015. Applying Au- tomata Learning to Embedded Control So‰ware. In ICFEM 2015 (LNCS), Vol. 9407. pressed all timing-related behavior, as it could not be handled by Springer, 1–17. the classical learners used; there is preliminary work on learning [27] O. Udrea, C. Lumezanu, and J.S. Foster. 2008. Rule-based static analysis of timed automata[16] which could use timing behavior. network protocol implementations. Inf. and Comp. 206, 2-4 (2008), 130–157. [28] F.W. Vaandrager. 2017. Model Learning. CACM 60, 2 (2017), 86–95. Despite these limitations, our work provides a compelling appli- [29] P. Verleg. 2016. Inferring SSH state machines using protocol state fuzzing. Master’s cation of learning and model checking in a security seŠing, on a thesis. Radboud University. [30] Y. Wang, Z. Zhang, D. Yao, B. ‹, and L. Guo. 2011. Inferring Protocol State Ma- widely used protocol. We hope this lays some more groundwork chine from Network Traces: A Probabilistic Approach. In Applied Cryptography for further case studies, as well as advances in learning techniques. and Network Security. LNCS, Vol. 6715. Springer, 1–18. [31] S.C. Williams. 2011. Analysis of the SSH Key Exchange Protocol. In Cryptography and Coding. LNCS, Vol. 7089. Springer, 356–374. [32] T. Ylonen and C. Lonvick. 2006. Œe Secure Shell (SSH) Authentication Protocol. REFERENCES RFC 4252, IETF, Network Working Group. (2006). [1] F. Aarts, P. Fiterau-Bro˘ s¸tean, H. Kuppens, and F.W. Vaandrager. 2015. Learning [33] T. Ylonen and C. Lonvick. 2006. Œe Secure Shell (SSH) Connection Protocol. Register Automata with Fresh Value Generation. In ICTAC 2015 (LNCS), Vol. 9399. RFC 4254, IETF, Network Working Group. (2006). Springer, 165–183. [34] T. Ylonen and C. Lonvick. 2006. Œe Secure Shell (SSH) Protocol Architecture. [2] F. Aarts, B. Jonsson, J. Uijen, and F.W. Vaandrager. 2015. Generating Models of RFC 4251, IETF, Network Working Group. (2006). In€nite-State Communication Protocols using Regular Inference with Abstrac- [35] T. Ylonen and C. Lonvick. 2006. Œe Secure Shell (SSH) Transport Layer Protocol. tion. FMSD 46, 1 (2015), 1–41. RFC 4253, IETF, Network Working Group. (2006). [3] F. Aarts, J. de Ruiter, and E. Poll. 2013. Formal Models of Bank Cards for Free. In So‡ware Testing, Veri€cation and Validation Workshops (ICSTW). IEEE, 461–468. [4] F. Aarts, J. Schmaltz, and F. Vaandrager. 2010. Inference and Abstraction of the Biometric Passport. In Leveraging Applications of Formal Methods, Veri€cation, and Validation. LNCS, Vol. 6415. Springer, 673–686. 10