Automatic detection of DoS vulnerabilities of cryptographic protocols

– In this article the subject of DoS vulnerabilities of cryptographic key establishment and authentication protocols is discussed. The system for computer-aided DoS protocol resistance analysis, which employs the Petri nets formalism and Spin model-checker, is presented.

indicate the most effective attack scenarios and allow comparing DoS resistance of different key establishment and authentication protocols. Related work Unlike the case of verifying confidentiality and integrity provided by protocols, there has been far less research in the field of designing and testing DoS resistance of cryptographic protocols. The most known is the Meadows's framework [4]. It has been used to analyse the JFK protocol in [5]. For each message, computational costs of client and server are compared. However, this approach is limited only to the static analysis of one protocol run and requires manual, work consuming calculations.
Dynamic analysis, involving many parallel protocol runs modelled as a Petri net, was presented in [6,7]. In [6] first the authors present costs of protocol runs for chosen types of clients (static analysis). Transport versions of the SSL protocol and the HIP protocol are considered. Then a Petri net describing each protocol step is shown. It contains detailed information of every users action, which is unfortunately redundant during simulation. The model takes into account the puzzle mechanism. Yet it does not consider sharing costs by the attackers, replays of messages and reusable exponentials of the server. The [7] article concentrates on slightly different aspects of protocol design, considering the broadcast DREAM protocol in the ad-hoc wireless network. Simulations are done in the CPN Tools and Matlab.
These methodologies are also not automated, as the nets are manually created for every analysed protocol.

Our approach
The protocol DoS resistance analysis methodology presented in this article is illustrated in Fig. 1. As can be seen, the input to the analysis process is a high-level protocol description. The output includes the information on the most dangerous attack types and vulnerabilities as well as comparison and evaluation of different protocols DoS resistance. The steps of our approach are the following: (1) Parsing protocol description -parsing high-level protocol description.
(2) Static analysis -determining each user's step, computational and memory costs and scenarios of attacks.
(3) Dynamic analysis -creating an instance of a Petri net for each simulation. Running a simulation for each type of attack, with a chosen number of honest clients and attackers of the type under consideration. (4) Comparing different attack scenarios -finding the most dangerous attack type at (which exposes vulnerabilities of the protocol), such that: (1) Where: • f (at j ) -the number of successful honest clients protocol runs, for a simulation with the j-th attacker type, • AT -the number of attacker types in the modelled protocol, defined by equation (3) (in this article bounded by 15).
(5) Comparing protocols -for a set of P analysed protocols, finding the most DoS -resistant protocol p, such that: (2) Where: • at i is the most dangerous attack type in the i -th protocol, as denoted by equation (1).

Protocol model for the DoS analysis
The protocol is described in a high-level language. This makes it possible to analyse protocols, which haven't been implemented yet. The language is of our own design. Its grammar is not presented here because of the limited space in the article. Yet it can be found in [8]. The examples of protocol specification are shown in sections 3.2 and 5.

Static protocol model
The static protocol model includes all the details from the parsed protocol specification. A protocol run is one of the basic terms in the model. It includes protocol participants actions and states that store the actual knowledge of the users. As shown in Fig 2, in one step of a protocol run, the message sender creates all the necessary fields and sends the message. Then if this is the last message sent in the protocol, the user accepts the protocol run and establishes a session.
The receiver computes the elements needed to process the message and verifies or decrypts the message fields, according to the protocol specification. If this is the last message in the protocol and the verification is positive, then the user accepts the protocol run and establishes a session.

Clients launching DoS attacks
The client that is not honest can launch a DoS attack in several ways. The set of attacker types is determined during the static analysis. The main properties of the attacker are: • Aiming at exhausting server resources, • The ability to deviate from the protocol specification by: -Not verifying the received messages -thus avoid unnecessary costs, -Producing fake messages -sending random data at no cost instead of expensive fields, -Sharing computational costs -sharing the costs among a group of attackers, which makes expensive operations cheap, -Finishing protocol run -an attacker may not respond to the server message and stop protocol run in any stage, -Message replay -once generated, a message may be replayed many times at no cost, -Eavesdropping messages -an attacker may capture and resend messages originally sent by legal clients.
Determining attacker types When considering the above features, there is a finite set of adversary types for a protocol. Let V be the number of fields verified by the server and let M be the number of messages received by the server. Then the size of the set of attacker types is calculated with equation (3).
The equation is derived from the fact that there are the following kinds of adversary types: • A group of V + M attacker types -each subsequent attacker type proceeds one step further in a protocol run, • A group of V + M attacker types -analogous to the previous group, except for replaying the last message (up to the server reset), • A group of M attacker types -consists of attackers that eavesdrop a message from a real, honest client and replay it repeatedly (up to the server reset).

Dynamic protocol model
The dynamic model allows to simulate multiple, simultaneous protocol runs, while monitoring the server state. Unlike in [6], the model presented here includes only A group of V + M =3attacker types: Attacker type 1 Sends MSG1 with random content and ignores MSG2. Attacker type 2 Sends MSG1 and then MSG3 with random content -verification of sig3 will fail. Attacker type 3 Sends MSG1 and MSG3 that are successfully verified by server.
A group of V + M =3attacker types: Attacker type 4 Analogous to attacker 1 but keeps replaying once generated MSG1. Attacker type 5 Analogous to attacker 2 but keeps replaying once generated MSG3. Attacker type 6 Analogous to attacker 3 but keeps replaying once generated MSG3.
A group of M =2attacker types: Attacker type 7 Eavesdrops MSG1 from real, honest client and repeatedly resends it. Attacker type 8 Eavesdrops MSG3 from real, honest client and repeatedly resends it. information necessary for the simulation. This makes the model less complicated and speeds up simulation.
Computational costs of protocol run step Detailed information about every action of the protocol user, that is stored in the static model ( Fig. 2), is redundant in the dynamic model. What is important, is the aggregated actions costs of each user step, which is illustrated in Fig. 4. The following action types costs are separately handled and stored: • Server costs -REUSED -the actions of generating fields that are reused by the server (e.g. exponentials), this kind of actions is performed only periodically, after the old values are reset (which is here called the server reset), -NORMAL -the actions concerning the elements that are not reused, • Client costs -SHARED -the actions whose costs can be shared among attackers (not applicable for honest clients), -NON_SHARED -the actions whose costs can not be shared among attackers, where: Memory costs of protocol run step At the end of every user step, the elements that will not be used in subsequent steps or can be cheaply reconstructed later, are erased from memory. As can be seen in Fig. 4, the server memory cost is calculated as a difference between memory usage after the server step and before it.

Modelling protocol as a Petri net
For the purpose of simulating multiple protocol runs, high-level, coloured, timed Petri nets were used [9,10,11]. Fig. 5 a) depicts a graphical representation of the examplary net. Places drawn as ellipses can store tokens. Transitions are drawn as rectangles. Tokens can travel from place to place according to arc expressions, after the transition fires. The time it takes for the transition to fire is determined by the time inscription (here @+(hd ccs)). In the examplary net, this models the time needed by the client to receive MSG2 and send MSG3.
Dynamic model structure The Petri nets used in the presented system have the following features: • Petri net structure -the net consists of subpages describing behaviour of client and server, while the main page contains the instances of subpages and links them together, • Coloured tokens -each token represents a protocol run with one client and bears information about: -client type (real client or type of attacker), -the number of the currently processed message (incremented during the protocol run), -computational and memory costs of every user's step, in the protocol run with the considered client type (as described in section 3.3), -delays after a client is ignored by the server or before a client starts a new protocol run. • Client and server subpages -for each message in the protocol there is an instance of client and server subpage (e.g. a server subpage for receiving MSG1 and sending MSG2 ), • Petri net template -for each analysed protocol, a Petri net is created by simply parameterizing a template net with: the number of messages, the number and type of tokens, • Tokens movement -tokens travel between the client and server subpages.
After a particular protocol run is finished, a token moves back to the initial place before it gets engaged in a new run.
Client model Client subpage has quite a simple construction, as shown in Fig. 5 a. A token in the MsgInNum place determines that this subnet represents receiving MSG2 and possibly sending MSG3. The client has two alternatives: responding with MSG3 (ComputeOutMsg transition) or starting a new protocol run (Finish transition), which is available only for an attacker. The choice, cost and duration of action are controlled by the information found in the token un the MsgIn place. Server model The Petri net representing the server behaviour is much bigger and more complex than the client model. Therefore it is not presented here. Instead the description of server logic is presented in the decision diagram in Fig. 6.

Protocol model properties
The protocol model, used in the presented methodology, covers the following crucial protocol features: • Reuse of message elements by the server -the anti-DoS technique that reduces computational costs and increases DoS resistance of the server, • Sharing costs among attackers -increases capabilities of attackers, • Servers computational resources -servers computation speed is inversely proportional to the number of clients served at the time, • Attackers computational resources -the more adversaries are using the shared resources at the time, the longer it will take to finish calculations for each attacker. Yet the adversary was limited to using at most four machines concurrently.

Petri nets simulation tool choice
Petri nets are generally represented graphically. However, in the DoS Analyzer system a textual net description was chosen. The well-known simulator and modelchecker Spin [12,13] was used, together with the Promela language. When compared with the CPN Tools [14] (which we used in the early stage of the project), Spin suited more for our application. It is much faster and does not require human user's interaction with GUI for each simulation, which automates the process.  The method to represent the Petri nets in the Promela language is shown in Table 2. According to these rules the net in Fig. 5 a) was transformed into the code in Fig. 5

b.
Processing simulation output During the protocol simulation, some data is written into files, including: client costs, server costs, information of server ignoring clients during DoS attack, honest clients establishing a session, server memory usage. This data is then aggregated by the DoS Analyzer system to calculate statistics.

Results
The protocol analysis methodology presented so far was incorporated into the DoS Analyzer system, that aids the process. This section will demonstrate the results of analysis of two examplary protocols: the simple STS protocol [15,16] (described in Fig. 3) and the SigmaI protocol [16,17] that has been equipped with the DoS resistance mechanisms (see Fig. 7).  Table 2. Petri net representation in the Promela language for the Spin simulator.

Petri net feature Spin
Coloured tokens typedef mechanism similar to C -language structs Non-determinism Built-in nondeterministic Promela language constructions (if, do) Hierarchical subnets for client and server Asynchronic processes in Promela language (proctype) Protocol state stored in specific places (e.g. server memory usage in SrvMem place)

Data kept simply in variables
Tokens travelling between client and server subnets Structs sent via communicational channels between processes (chan) Transition firing delayed by time inscriptions When a protocol step is performed, a struct (token) is inserted into a queue managed by the additional time process. The token is passed to its destination process (message receiver or first message sender in a new protocol run), only after the necessary computations and when the specified time interval is over Simulation configuration Both protocols were simulated for identical computational and memory resources, shown in Table 3. This makes it possible to compare the simulation results. The cryptographic algorithms used were: AES, MD5 and RSA. The symmetric key length was 128 b, the asymmetric key length was 1024 b. Such values are generally used and recommended as currently safe by NIST [18] and ENRYPT [19]. Computational cost came from benchmarks [6,20].

Static analysis of SigmaI protocol
The results of static analysis are depicted in Fig. 8. The first row in the table refers to an honest client, while the other rows are related to attacker types.
After the static analysis, DoS Analyzer application indicates (with bold face in the Srv -cl cost column) the most significant difference between the client and server costs in the case of adversaries of 4, 5, 10 and 11 type. These are potentially the most dangerous attack scenarios.
Dynamic analysis of the SigmaI anf STS protocols After the static analysis, which is similar to the Meadows's framework, there are some assumptions about the effectiveness of different attack types. Nevertheless only dynamic analysis can address the problem of multiple, interacting protocol runs. The results of SigmaI protocol model simulation are shown in Fig. 9. Each row corresponds to a simulation with the attacker type indicated in the first column. The main criteria is the number of sessions established by real clients (see section 1), found in the second column. The minimal number of successful runs was detected for adversaries 3, 5, 6 and 4. These most dangerous attacks are based on the following SigmaI protocol vulnerabilities:  • Attacker type 3 -after verifying the token field in MSG3, the server gets engaged in expensive computations (Diffie-Hellman and generating signature), whilst an attacker can flood server with messages created at no cost. The protocol requires from the attacker only the ability to receive a reply to MSG1. • Attacker type 4 -similar to that of adversary 3 but additionally sends MSG5 with the random content. The server will reject a message at mac3 verification. Employing the HMAC function protects the server from far more computationally expensive signature verification. For this reason, this attack is less effective than the previous one. • Attacker types 5 and 6 -require much more computations from the attackers but allow to engage the server in all protocol steps.  Specifications of the STS protocol and the attacker types derived from the static analysis, were earlier presented on page 56. In the case of this protocol, the following attack scenarios turned out to be the most effective: • Attacker type 1 -sends MSG1 with random content at no cost, whereas receiving MSG1 causes the server to compute an expensive exponential and signature. • Attacker type 2 -similar to adversary 1 but additionally sends MSG3 with random content. Receiving MSG3 causes the server to expend computational resources for signature verification, while the attacker generates both messages at no cost. This allows to engage the server in all protocol steps. This attack type turns out to be the most effective.

DoS vulnerabilities of the STS and SigmaI protocols
The obvious shortcoming of the STS protocol design, is the lack of assurance that the client will expand computational resources as much as the server. Thus the protocol is significantly susceptible to DoS attacks. On the other hand, the SigmaI protocol incorporates built-in mechanisms protecting the server from DoS attacks. This includes: reusing exponentials, performing inexpensive verification operations (HMAC ) before checking the signature, employing the cookie scheme. Still, the cookie mechanism may be not strong enough to mitigate the attacks, if the adversary can receive server response in spite of IP-spoofing. The reason is that, sending the valid cookie ensures only that the client, distinguished by an IP address, took part in the earlier message exchange. It does not guarantee the client got engaged into computations. A solution to this might be using the puzzle mechanism [6,21].
Comparative analysis of the STS and SigmaI protocols Each protocol is represented by the results of simulation with the most dangerous adversary type for the protocol (see Section 1). The compared protocols are: STS and SigmaI with and without exponentials reuse. Additionally, a case of adversary with limited abilities was considered. The situation is when the attacker can only receive a response from the server, providing his real IP address. Yet without IP-spoofing, the attack will probably be detected by the server (IDS ). This is quite a rational assumption. In this case in the SigmaI protocol, attacker type 3 can not be taken into account any more, as it demands from the client to send in MSG3 a valid token field, received with MSG2. So the permitted attack scenarios are: 1, 2, 7, 8, 13, 14, 15. According to the simulation results in Fig. 9, attack type 1 was chosen as the most dangerous in this set. Whereas in the case of protocol version without the exponential reuse attacker type 2 was chosen. In the protocol STS adversaries 1, 2, 4, 5, 7 and 8 are considered, with attacker type 2 being the most effective.
The results of comparative analysis for the constrained adversaries are shown in Fig. 11 b. In such circumstances both versions of the SigmaI protocol presented substantially more DoS resistance than the STS protocol.
Conclusions after the protocol analysis Comparing protocols performance under the DoS attacks has proven the mechanisms used in the SigmaI protocol to be useful. Choosing a more complex design has shown to be justified. In contrast to the simple STS protocol, in the SigmaI protocol negative effects of DoS attacks were reduced.

Conclusions
We developed a nowel methodology for analysing DoS resistance of cryptographic key establishment and authentication protocols. The process is computer-aided with Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 16/07/2023 02:22:26 U M C S the DoS Analyzer system. It allows to easily discover DoS vulnerabilities of protocols and identify the most dangerous attack scenarios. The system makes it also possible to compare DoS resistance of different protocols. Our system has been applied to the SigmaI protocol, which has proven the effectiveness of the anti-DoS techniques employed in that protocol.
Unlike the Meadows's framework [4,5], our approach combines both static and dynamic analyses. This allows to take into account the server behaviour during many parallel protocol runs. Also when compared with the Petri nets introduced in [6], our model is generated and simulated entirely automatically. Additionally, the model is more concise. To summarize, the main features that distinguish our approach are: • Modelling the anti-DoS mechanisms protecting the server and specific attackers abilities, • Two-stage analysis -the preliminary stage of static analysis lets minimize the final dynamic model, as the data redundant during the simulation is not included, which speeds up the process, • Analysis automatization -the methodology was fully automatized and the human user has only to supply high-level protocol specification and simulation configuration.
Extending the system The presented system can be improved in the following ways: • Taking into account that also honest clients can reuse exponentials, • Adding an option to define the clock time unit of the simulation, which would help balance the accuracy/speed issue, • Live visualization of clients actions and server resources during simulation.