A Formal TLS Handshake Model in LNT

Abstract

Testing of network services represents one of the biggest challenges in cyber security. Because new vulnerabilities are detected on a regular basis, more research is needed. These faults have their roots in the software development cycle or because of intrinsic leaks in the system specification. Conformance testing checks whether a system behaves according to its specification. Here model-based testing provides several methods for automated detection of shortcomings. The formal specification of a system behavior represents the starting point of the testing process. In this paper, a widely used cryptographic protocol is specified and tested for conformance with a test execution framework. The first empirical results are presented and discussed.

Formal specification and testing of QUIC

“…Techniques that do address compliance include modelbased testing (MBT) [7,28,35] and its precursors in the area of protocol conformance testing (see [26] for a survey). In MBT, an abstract model of the system is constructed, containing controllable events that are generated by a tester, and observable events that are generated by the system under test.…”

“…With an FSM model, some method is needed to fill in the concrete data parameters of messages. This may be done in a systematic way as in [35] or an ad-hoc way as in [7]. Generally, the need to extend FSMs in some way to account for data leads to significant complexity in these formalisms.…”

“…For example, [28] considers the connection state machine of TCP, but not TCP's data transmission. A similar approach is applied to TLS in [3,7]. Here, we consider the full protocol state including the security handshake, with unbounded data, unbounded streams, unbounded connections and so forth.…”

Is CADP an Applicable Formal Method?

“…Among the case studies listed on the CADP web site, the tools are most frequently used for the formal specification and modeling of a system, which are then verified by model checking temporal logic properties and/or equivalence checking against a reference model (e.g., the expected service of a protocol). Some case studies additionally take advantage of more specific tools, e.g., for performance evaluation [18,3,11,7,9,14,45,55], (conformance) test generation [33,12,28,51,54,8,29,41,35,5], or generation of an executable prototype from the formal model [12,28,53,27,41,52,26].…”

Automated Transition Coverage in Behavioural Conformance Testing

“…We evaluated our approach using the following 16 models of communication protocols and distributed systems 5 : ABP (demo 1) and ABP-data (demo 2) are dataless and data-aware variants of the Alternating Bit Protocol with controllable failures of the communication links; AAP and AAP-big (demo 33) are configurations of an asynchronous agreement protocol [2,33] with 1 and 10 rounds; BRP-basic, BRP, and BRP-big (demo 16) are variants of the Bounded Retransmission Protocol [28] with controllable message-loss, larger messages, and more retries; CAR-LNT is a purely asynchronous variant of a simple autonomous car [26]; CCP (demo 28) is a multi-processor cache-coherency protocol; CFS (demo 25) is a Cluster File System [31]; CIM (demo 34) is a computer-integrated manufacturing architecture [29]; DES and DES-basic (demo 38) are variants of the Data Encryption Standard [36] with visible subkeys [27, Section 3.4] and less iterations; TLS (demo 6) is the Transport Layer Security 2.3 handshake protocol [5]; SMS (demo 40) is a stock management system [7]; and TOY is the running example given in [22].…”