Registration protocol security analysis of the electronic voting system based on blinded intermediaries using the Avispa tool

. Electronic voting systems are a future alternative to traditional methods of voting. It is important to verify the main algorithms on which system security is based. This paper analyzes the security of the cryptographic protocol at the registration stage, which is used in the electronic voting system based on blind intermediaries created by the authors. The registration protocol is described, the messages transmitted between the parties are shown and their content is explained. The Dolev-Yao threat model is used during protocols modeling. The Avispa tool is used for analyzing the security of the selected protocol. The protocol is described in CAS+ and subsequently translated into the HLPSL (High-Level Protocol Specification Language) special language with which Avispa work. The description of the protocol includes roles, data, encryption keys, the order of transmitted messages between parties, parties’ knowledge include attacker, the purpose of verification. The verification goals of the cryptographic protocol for resistance to attacks on authentication, secrecy and replay attacks are set. The data that a potential attacker may possess is detected. The security analysis of the registration protocol was made. The analysis showed that the objectives of the audit were put forward. A detailed diagram of the messages transmission and their contents is displayed in the presence of an attacker who performs a MITM-attack (Man in the middle). The effectiveness of protocol protection from the attacker actions is shown.


Introduction
The creation of e-voting systems is a serious problem. There are a number of readymade systems [1,2] that are used in practice, but they are far from a sufficient level of reliability and the presence of necessary mechanisms, such as complete anonymity of the voter or vote checking opportunity after counting stage. There are also a lot of works, in which perspective methods of conducting electronic voting are considered, based on such principles as homomorphic encryption, including threshold schemes, mix-net, secret sharing schemes and others [3][4][5][6][7][8][9][10][11][12][13][14][15][16]. However, in most cases, the authors of such works show theoretical calculations, from which the basic structural unit of interaction between parties does not follow, namely, cryptographic protocol. Any method on which electronic voting is based, no matter how good it is, loses its security if there are any flaws in the structure of cryptographic protocol that lead to various attacks by the intruder. Thus, the goal of this paper is to test the cryptographic protocol in the important registration stage from various attacks, such as attack on parties' authentication, data privacy and replay-attacks using the Avispa tool [17].

Avispa tool
Avispa is a tool for automated security analysis of cryptographic protocols [17]. With the help of Avispa, in the context of the developed protocols, it is possible to verify the parties' authentication, the secrecy of data and protection against replayattacks. It is impossible to perform integrity checks, in particular, used in protocol CMAC mode (Cipher-based message authentication code) using the Avispa tool. The protocol does not imply the use of timestamps in their classic implementation as a part of message. Instead, the developed system uses a temporary session control by server, in which long live sessions are broke down. In the paper registration stage is analyzed. Three sides are modeled: user, serverintermediary and main server. The protocol will be analyzed after the phase of common session key distribution between the parties. The protocol will be described in CAS+ [18] language, then translated using the Avispa translator into HLPSL [19]. The check will be carried out using the On-the-Fly Model Checking (OFMC) module, where the verification goals are the transmitted data confidentiality and parties' authentication. For verification, it is necessary to describe the protocol in one of the formal languages: CAS+ or HLPSL. The first language is simpler in syntax and allows you to quickly describe the protocol. An example of syntax is shown below: The syntax of this language is more difficult and the best way to describe the protocol is to describe it in CAS+, and then use Avispa to convert it to HLPSL. It is worth to say that if the more complex and larger your protocol, then there is greater chance of errors occurring during translation, so after that you need manually to fix some fragments in HLPSL. It is also worth to say that you should not describe the goals of checking in CAS +, but rather add them directly in HLPSL. During protocols describing, the following entities are used: roles, data, message order, sessions and verification purposes. After the description of the protocol, including the indication of verification objectives, it is possible to analyze protocol security against attacks. For analyzing, you can use different modes, but the most effective is the OFMC mode (see Fig. 1). It requires an additional specification for all data involved in the verification, as well as the message area where verification is required for party authentication. As a result of verification, the corresponding result will be issued. In case of attacks detection, the type of attack and its progress will appear in the form of corresponding changes in messages by the intruder, as in Fig. 2. If there are no attacks, then the program output will contain a corresponding message that protocol is safe (see Fig. 3). Using the «Protocol simulation» button, you can see the interaction scheme of the parties in your protocol. With the help of the button «Intruder simulation» such a scheme will appear, only with the participation of the intruders' side, in which the data intercepted by him will appear. With the help of the button «Attack simulation» you can see the scheme of the attack with intruder, provided that there is an attack in your protocol.

System architecture
The system architecture is based on the use of the following components: client application for voter -V, 3 server applications that will be located on different physical machines: AS (authentication server), PS (processing server), VS (voting server), encryption application for the passport database and ballots DBE (database encryptor). The general scheme of the interaction of components is shown in Fig. 4. The basic principle on which the system protocols are based -blinded intermediaries (see Fig. 5). There are 3 interacting sides A, B, C. Using the protocol for generating a common secret key, the session key AB, BC, AC are generated. A encrypts some information info on the AC key, appends an id to it, encrypts it on the AB key and sends this message to B. B in this case is a blinded intermediary, because it can decrypt only the first part of the message with id, and the remainder with info can not. It accepts the message, decrypts and checks if id is in the database and, then redirects the remainder of the message encrypted again on the BC key to the C side. C receives the message, decrypts info, encrypts the answer response on the AC key and sends it to A. This principle ensures that: info will be accepted only if id is in the database and that it is impossible to correlate id with info.

Stages description
Stages of electronic voting in the context of the system:  Preparation. At this stage, a database of voters and a ballot are created. This data is encrypted, and officials deliver this data to the appropriate server components of the system.  Registration. At this stage, users log in to the system using their identification data, at the moment -using passport data, and they get their anonymous identifier. It should be noted that by using the previously described principle of blind intermediaries, it is impossible to correlate open passport data with an anonymous identifier, which ensures the requirement of anonymity.  Voting. Users receive a ballot, make their choice and send filled ballot with their anonymous identifier to the server. If such an identifier is present, the vote is accepted, and the verification identifier is sent to user, with which he or she can check vote after counting stage.

Registration stage
The electronic voting system based on blind intermediaries, includes a registration stage in which the voter is given anonymous identifier after presenting his passport data. A simplified scheme of the registration stage is shown in Fig. 6.

Fig. 6 -Simplified scheme of registration stage.
Secret keys V, VAS, VPS are generated using the protocol for generating a common session key. The server parties generate random numbers and send messages (1), (2), (3) to their recipients. They will be used for parties' authentication. V generates Nv. Next, it generates a message (4) with the passport data, which is a hash from a set of document fields, encrypted random numbers on the shared secret key VPS, calculates the CMAC, encrypts all this data on VAS key, calculates the CMAC and sends to AS. AS in this case is a blinded intermediary. It checks the message integrity by CMAC checking, searches PassportData in the database and, if successful, redirects another part of the message (5) to side PS. PS checks integrity, if successful, generates userid, adds it to database and sends to V as a message (6). The voter decrypts the message, checks integrity and values of random numbers, and remembers his anonymous unique identifier userid, with which the user can vote. ECDHE is a Diffie-Hellman protocol on elliptical curves using ephemeral keys. In our case, we use a modified version of ECDHE-RSA, where authentication is done using a signature RSA and a server certificate which help to prevent MIMT (man in the middle) attacks. The protocol description is as follows.

1) V -> S: "Hello" (2) S -> V: DHs, (DHs),Certificate (3) S: Проверяет Certificate и подпись (DHs) (4) V -> S: DHv (5) Both sides generate a common session key K for further interaction with a symmetric cipher.
Here V is the client, S is the trusted server that has the certificate, DHs is the server secret part, DHv is the client secret part (DHs) is the signature with the server's private key SKs, Certificate is the server certificate. When servers generate common secret key, the same protocol is used, except that both parties exchange certificates and if they are valid, a common session key is generated. The security verification of the registration protocol will be carried out after this stage.

Security analysis of registration protocol using Avispa tool
Consider the description of the protocol in CAS + at the registration stage. Three interacting parties are described as roles: V, AS, PS (lines 2-3). The identifiers section describes the objects participating in the protocol: interacting parties (line 3), random numbers for authentication, identifiers (line 4). Symmetric keys are specified that will be used for message encryption (line 5). The messages section (lines 7-13) describes the transfer of messages between roles, which data is transmitted, and on which key it encrypted. The knowledge section (lines 15-18) describes roles' data knowledge during the execution of the protocol. In the session_instances section (lines 20-22), sessions are described. Among the simulated sessions, 2 are allocated, which allow simulating interaction of two clients with the system. This will detect possible attacks on the parties' authentication and replay-attacks. The intruder_knowledge section (lines 24-25) specifies the original knowledge of the intruder. In the goal section (lines 27-37) the secrecy of important values is indicated and the authentication according to the request-response scheme with the transfer of random numbers between the participants. For secrecy of the value, it is necessary that this variable is encrypted and that the encryption key does not come to intruder. In order for one party to authenticate another using the request-response mechanism, it is required that the party wanting to authenticate send a random number to the other party, and that other party in the response message returns this random number. In this protocol there are 4 such actions:  AS authenticates V by Nas;  PS authenticates AS by Npsas;  PS authenticates V by Nps;  V authenticates the PS to Nv. As for replay-attacks, protection against them is possible due to the presence of a random number at the beginning of each message, which each side checks when message is received. The results of the check using the OFMC module are shown in Fig. 7. Fig. 8 shows the scheme of interaction between the parties at the stage of registration by steps. Fig. 9 shows the interaction scheme in the presence of an intruder (Intruder_ side, highlighted in red). This scheme is a visual implementation of the attack man in the middle. When transmitting messages during execution, a transition is made from the «Incoming events» area to «Past events», and the format is the direction of message transfer (from whom and to whom) and the message itself. We can see from the simulation results in the field of intercepted data «Intruder knowledge», all transmitted messages are encrypted on keys which intruder doesn't know, and it excludes the possibility in any way to get important information, such as the user's passport data or unique identifier. The record «nonce-N» means some data that is not readable. Because of the analysis, it was revealed that the registration protocol is safe, ensures the fulfillment of the security objectives (properties) set in the protocol analysis: securing data, authentication of the parties, protection against replay-attacks.