Cryptanalysis and Improvement of ECC Based Authentication and Key Exchanging Protocols †

Elliptic curve cryptography (ECC) is extensively used in various multifactor authentication protocols. In this work, various recent ECC-based authentication and key exchange protocols are subjected to threat modeling and static analysis to detect vulnerabilities and to enhance them to be more secure against threats. This work demonstrates how currently-used ECC-based protocols are vulnerable to attacks. If protocols are vulnerable, damage could include critical data loss and elevated privacy concerns. The protocols considered in this work differ in their usage of security factors (e.g., passwords, pins and biometrics), encryption and timestamps. The threat model considers various kinds of attacks including denial of service, man in the middle, weak authentication and SQL injection. Countermeasures to reduce or prevent such attacks are suggested. Beyond cryptanalysis of current schemes and the proposal of new schemes, the proposed adversary model and criteria set forth provide a benchmark for the systematic evaluation of future two-factor authentication proposals.


Introduction
In a cyber environment, user authentication enables a perimeter device (firewall, proxy server, VPN server, remote access server, etc.) to decide whether to approve a specific user's request to gain entry to the network.The authentication is generally two-way, meaning both parties (provider and user) authenticate themselves to each other [1].Client authentication needs security for remote login, while the client's program is trying to communicate with the server's program over insecure networks, like the Internet.The identity and a secret password of a client are used for mutual authentication and access control.However, a password can be compromised during transmission if an efficient scheme is not followed.
Elliptic curve cryptography (ECC) is a widely-used technique in multi-factor authentication [1].ECC is a public key encryption technique based on elliptic curve theory that can be used to create smaller keys, which yields faster and more efficient algorithms as a result.It generates keys through the properties of the elliptic curve equation instead of the traditional method of generation as the product of very large prime numbers.The technology can be used in conjunction with most public key encryption methods, such as RSA (RSA is made of the initial letters of the last names of Ron Rivest, Adi Shamir, and Leonard Adleman, who first publicly described the algorithm in 1978.) and Diffie-Hellman [2].ECC was developed to reduce computational costs while providing the same level of security as other similar operations (e.g., modular exponentiation).ECC finds applications in authentication protocols involving smart cards, RFIDs, wireless networks, digital signatures and other authentication techniques [3][4][5][6][7][8][9][10][11][12][13][14].However, the computational cost of one bilinear pairing (an important operation of ECC) is about twice as high as that of one modular exponentiation operation at the same security level [15].Therefore, the computationally-intensive nature of ECC leaves a security loophole in the protocols that use it.An attacker can force the server or client to repeatedly perform ECC operations in order to clog them, resulting in one or all of them wasting resources by performing unnecessary computations.We are looking at two different types of schemes that use ECC, one being multi-factor authentication and the other being key-exchange.
Multi-factor authentication is an approach to authentication in which the user is required to provide more than one form of verification in order to prove his/her identity and allow access to the system.It takes advantage of a combination of several forms of authentication.Three major forms include verification by: (1) something a user knows (such as a password); (2) something the user has (such as a smart card or a security token); and (3) something the user is (such as a biometric characteristic).Due to their increased complexity, authentication systems that use multi-factor verification are harder to break than those that use a single factor [1,[16][17][18].
Key exchange (also known as key establishment) is a cryptographic method by which secret keys are exchanged between two parties, allowing use of a cryptographic algorithm.Public key cryptography, or asymmetric cryptography, is a cryptographic system that uses pairs of public and private keys.Each party has its own public key and private key.The message is encrypted using the public key and decrypted using one's private key.The public key is distributed, and the private key is known only to the owner.If the sender and receiver wish to communicate with each other, then a secret key is shared between them in order for communication to take place.Symmetric key algorithms use the same cryptographic keys for both encryption and decryption of text.The key exchange problem is how to exchange information so that no third party can obtain a copy.Typically, this has required trusted couriers or a secure channel.
Radio frequency identification (RFID) is a means of automatic identification that uses radio waves to detect, track, identify and thus manage a variety of objects.Although RFID technology has been around for more than half a century, only recently have RFID security and privacy issues begun to attract attention from both academic and corporate research communities.RFID (radio frequency identification) technology has become ubiquitous because of its low cost.Since it is used in many fields, any vulnerability detected in RFID technology raises a threat in data privacy.Similarly, the potential for smart cards is enormous.However, by far the most serious problem for smart cards is the attacks that exploit security vulnerabilities caused by poor design or implementation.These vulnerabilities tend to be easy to exploit and replicate and are, therefore, shared among the hackers community.

Problem Statement, Goal and Contribution
ECC is a multi-factor encryption technique currently used by the U.S. government, Tor, Bitcoin, iMessage and SSL/TLS.Such multi-factor authentication is needed to provide high level security, but the introduction of more factors introduces more vulnerability in the protocols.Our goal is to detect these vulnerabilities before they are exploited.The root causes of many common vulnerabilities like CPU resource-exhaustion, stack overflow, etc., are often design flaws rather than programming (implementation) errors [19].Therefore, developers perform static analysis on protocols to identify design flaws in order to ensure security before a program (software product) is launched.
Several multi-factor authentication protocols that involve RFIDs, smart cards, wireless networks or digital signatures rely on ECC operations for their security.However, the computational cost of one bilinear pairing (an important operation of ECC) is about twice as high as that of one modular exponentiation at the same security level.Therefore, the computationally-intensive nature of ECC leaves a security loophole in the protocols.Hence, some level of protection should be added to ECC-based protocols to guarantee near-total security against various kinds of attacks, such as denial of service, man in the middle and database attacks.
As observed in this research, the vulnerabilities of ECC-based protocols are not recognized frequently.The first goal of this work is to perform static analysis on the underlying vulnerabilities and security threats that exist in ECC-based protocols that are implemented in RFIDs and smart cards.The second goal is to design possible countermeasures to defeat the identified vulnerabilities in these protocols.The contribution of this research is to provide the basis for future work in improving the security of ECC-based protocols using dynamic analysis.The results of this work will contribute to the cybersecurity community in a considerable way.

Organization of This Paper
The rest of the paper is organized as follows.Section 2 provides background materials on ECC.Section 3 describes the cryptanalysis algorithms and discusses the type of protocols that were investigated in this work.Section 4 describes in detail the work done in this paper to cryptanalyze various protocols.It describes the attacks that were carried out on the protocols and proposes countermeasures for each attack.Finally, Sections 5 and 6 discuss the results, conclusions and suggest future directions, respectively.

ECC Background
ECC is one of the most accomplished and widely used, however least understood, cryptography tools [20].It is the future generation of public key cryptography.It provides significantly more security than first-generation public key cryptography systems like RSA [20].ECC is a technique in public key cryptography set on the algebraic arrangement of elliptic curves over finite fields.Compared to non-ECC cryptography, ECC provides equivalent security with smaller keys [21,22].The elliptic curve cryptosystem [21] was initially proposed as a basis for public key cryptosystems, and it has proven to be an important unit of current cryptography [23].ECC utilizes the mathematics of elliptic curves.The security of ECC lies in the complexity of working the elliptic curve discrete logarithm problem.An analysis of ECC theory and its computational problems are stated below.
As shown in Figure 1, elliptic curves (E q (a, b)) are a set of points defined by the solutions to the equation y 2 ≡ x 3 + ax + b (mod q), where a and b are elements of the field k together with a point at infinity O [24].There is also a condition such that 4a 3 + 27b 3 = 0 (mod q) where q is a prime number [24].This equation must be satisfied for the elliptic curve to have a well-defined group structure.This forms an additive cyclic group E = {(x, y) ∈ E q (a, b)} ∪ {O}, where O serves as an additive identity element of the group [24].If P is a point in E and k is a positive integer, then the point multiplication is computed by repeated addition, such as k • P = P + P • • • +P, where k is a large integer and P is added to itself k times.

Computational Nature of ECC
ECC is a computationally-intensive operation.Its scalar multiplication is one-way, making it computationally infeasible to trace the original number.For example: let P be a point in E, and let Q be a point such that Q = kP.The elliptic curve discrete log problem is the following: knowing the values of P and Q, determine the value of k.If the modulus q is large, the ECDLP (For elliptic-curve-based protocols, it is assumed that finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point is infeasible: this is the "elliptic curve discrete logarithm problem" (ECDLP).) is computationally infeasible.ECC is based on this problem.Even if P and Q are known, determining k such that Q = kP (kP and k • P have the same meaning in ECC multiplication) is computationally infeasible.Hence, the elliptic curve discrete log problem makes k difficult to compute.

Framework for Cryptanalysis
In this section, general algorithms and conditions for the attacks that were successfully performed on the protocols chosen for this work are described.

Clogging Attack
The mechanism for most password authentication protocols is that the client (usually a memory stick, RFID or smart card reader) sends its credentials to the server, which then performs certain mathematical operations to verify those credentials.The protocols usually work in multiple phases.The phases in which client and server authentication take place will be discussed in Section 4 after each protocol has been individually considered.
As shown in Figure 2, the main idea of the clogging attack is the interception of the message that contains the login credentials between the client and the server [25].This message is unencrypted in some protocols and encrypted in others.It might or might not contain a timestamp.The attacker replays the intercepted message several times to force the server to perform computationally-intensive operations (in the case of [25], modular exponentiation), thus forcing the server to waste its time and resources.Legitimate users are denied services in that way.Algorithm 1 depicts this type of attack.

Application of Algorithm 1
The clogging conditions we analyze in this work are based on the computational and resource intensiveness of the operations in elliptic curve cryptography (ECC).The ECC operations performed by the majority of authentication based on ECC are: 1. Bilinear pairing 2. Scalar multiplication in group G 3. Map-to-point conversion Algorithm 1: The general algorithm for the clogging attack [25].
Intercept login message from client to server if Timestamp is present then

Modify timestamp to match requirements else
Keep message as is end if while The server is not completely clogged!do Replay the message to the server end while Let T p , T s and T map respectively be the time taken to perform a single bilinear pairing, scalar multiplication and map-to-point conversation, respectively.It has been shown in [26] that: Further, let T modex be the time taken by one modulo exponentiation operation.It has been shown [15] that T p ≈ 2 × T modex for the same level of security.The operation modular exponentiation has been shown to be very computationally intensive [25].In fact, T modex has been shown to be approximately a hundred times that of normal addition, multiplication and bitwise XOR operations (see Figure 3).We can, therefore, conclude that all of the ECC-based operations' bilinear pairing, scalar multiplication and map-to-point conversation are quite computationally intensive.Therefore, a protocol that uses the ECC operation has a vulnerability to the clogging attack, a form of DoS in which the attacker exploits the computational intensiveness nature of ECC operations.

Database Attack
According to many experts, databases are still not secured properly in most organizations [27].Database attacks go unnoticed as it takes less than 10 seconds to hack in and out of a database.Therefore, it is no surprise that many database attacks go unnoticed by organizations until long after the data have been compromised.Attackers use simple methods to break into databases, such as exploiting weak authentication, using default passwords and capitalizing on known vulnerabilities [27].
This analysis focuses on database connections that are weak and hence open to vulnerabilities.The front end client-server authentication stores passwords in the server's back-end databases.If any password is compromised, then the database schema becomes vulnerable to attack, which makes the protocol insecure (as explained in Algorithm 2).Passwords (or their hashed versions) are often stored in relational databases.The most common way to get illegitimate access to a database is by making a copy of the database (or individual rows) by a technique called SQL injection.SQL injection attacks occur where the fields available for user input let SQL statements through to query the database directly.Outside of the client, web applications typically are the weakest link [27].URL parameters or POST parameters of a web page are manipulated to contain malicious SQL statements, which are interpreted by the SQL database [28].

Algorithm 2:
The general algorithm for the database attack.
Intercept data access layer from application to back-end if Encryption is present then

Break the encryption to gain access to the database else
Access the database end if while The data is not corrupted and stolen do

Inject malicious statements end while
Internal attacks should also never be underestimated.There have been several insider attacks that came as a result of a malicious user possessing more system privileges than the user should have had [27].Databases are often accessible from inside organizations, and passwords can readily be found in the source code or server configuration files.This makes it easy for employees to access data and save it to a local disk or even transfer it to an external medium.
In the following chapters, database attacks (illustrated in Figure 4) to which recently-used protocols are vulnerable are considered.

Man-In-The-Middle Attack
As shown in Figure 5, a man-in-the-middle attack can be used against many cryptographic protocols.A man-in-the-middle attack requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel.One example is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.The attacker can intercept all messages passing between the two victims and inject new ones.A few ECC-based protocols claim to be secure against man-in-the-middle attacks.However, ECC protocols are still vulnerable to man-in-the-middle attacks, as shown in the next section.

Application of Algorithm 3
A variant of the Diffie-Hellman algorithm that uses elliptic curve cryptography, elliptic curve Diffie-Hellman (ECDH), is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel (for a detailed description and illustration of ECDH, please see [29][30][31][32]).This shared secret may be directly used as a key, or it may be used to derive another key, which can then be used to encrypt subsequent communications using a symmetric key cipher.The following example will illustrate how a key is established.Suppose Alice wants to establish a shared key with Bob, but the only channel available for them may be eavesdropped by a third party.Initially, the domain parameters for ECDH (that is, (p, a, b, G, n, h) in the prime case or (m, f (x), a, b, G, n, h) in the binary case) must be agreed upon.Furthermore, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key d (a randomly-selected integer in the interval [1, n − 1]) and a public key Q (where Q = dG, that is the result of adding G together d times where G is the generator point).Let Alice's key pair be (d A , Q A ) and Bob's key pair be (d B , Q B ).Each party must know the other party's public key prior to execution of the protocol.

Algorithm 3:
The general algorithm for the man-in-the-middle attack.
Intercept communication between two parties if TTP is present then

Relay end while
The shared secret is x k (the x coordinate of the computed point).Most standardized protocols based on elliptic curve Diffie-Hellman (ECDH) derived a symmetric key from x k using some hash-based key derivation function.The shared secret calculated by both parties is equal, because by the property of ECC).The only information about her private key that Alice initially exposes is her public key.Therefore, no party other than Alice can determine Alice's private key, unless that party can solve the elliptic curve discrete logarithm problem.Bob's private key is similarly secure.No party other than Alice or Bob can compute the shared secret, unless that party can solve the elliptic curve Diffie-Hellman problem [29].
The public keys are either static (and trusted, say via a certificate) or ephemeral (ECDHE (Elliptic curve Diffie-Hellman Exchange (ECDHE) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel.)).Ephemeral keys are temporary and not necessarily authenticated, so if authentication is desired, authenticity assurances must be obtained by other means.Authentication is necessary to avoid man-in-the-middle attacks.If one of Alice's or Bob's public keys is static, then man-in-the-middle attacks are thwarted.Static public keys provide neither forward secrecy, nor key-compromise impersonation resilience, among other advanced security properties.Holders of static private keys should validate the other public key and should apply a secure key derivation function to the raw Diffie-Hellman shared secret to avoid leaking information about the static private key [29].

Cryptanalysis of the Protocols
This section describes each of the protocols selected for analysis in this work, the attacks on them and ways of preventing the attacks.The following generic notations have been used to describe the protocols in this section.Specific notations for each individual protocol have been illustrated while describing each of them: • Z * q denotes the finite field over q • ⊗ denote (bitwise) exclusive OR • A→B: M denotes the propagation of the message M from user A to user B • denotes the concatenation operation • In cryptography, a nonce is an arbitrary number that may only be used once

Choice of Protocols
The protocols chosen for analysis fall into the broad category of multi-factor authentication protocols.All of them employ user ID and password for authentication.Selection of these protocols is based on differences in the second authentication factor (smart cards, RFIDs, memory drives, etc.) and the tools used to provide confidentiality (encryption, nonce, timestamp, etc.), as shown in Table 1.The first protocol considered is that of [33].It is a mutual authentication scheme for an RFID implant system.The authors in [33] claim that their protocol is immune to various attacks including denial of service (DoS).However, their protocol is inherently vulnerable to clogging attacks (a form of DoS) that apply the algorithm of [25].Most of the precursor protocols to that of [33] are vulnerable to clogging attacks.In this section, the mathematical basis that makes the protocols vulnerable to clogging attack is identified, and a possible fix is suggested.

Review of the Protocol
Moosavi et al.'s protocol works in three phases: reader authentication and verification, tag identification and tag verification.Figure 6 shows the notations used for the protocol.
This protocol enables the two communicating parties, an RFID implant tag and a reader, to respectively verify and ensure each other's identity.The assumption is that the communication between the tag and the reader is not secure [1].The protocol is shown in Algorithm 4.
, where * is a non-algebraic operation over the abscissa of (r 2 • P) and the ordinate of R 1 .4.
Step A8.T→R: Step A12.Reader R gets verified if the above is true.

Analysis of Moosavi et al.'s Protocol
This protocol is for an RFID implant system that has applications in microchip implants.The identities are the tag that is implanted and the reader that verifies (and authenticates) the tag.Communication between the tag and the reader is through an insecure network.Additionally, the reader is connected to a database through a secured channel, so the reader and database are considered to be a single entity for analysis purpose [1].The protocol uses ECC techniques twice, once during tag identification (Step I4 of Algorithm 4) and once during tag verification (Step V6 of Algorithm 4).However, in the course of this work, it became clear that the tag verification phase has a dangling step in Step V6.The use of variable u 2 in the verification process is not mentioned in this protocol.Furthermore, from [33], the description of verification variable r of Step V7 is not mentioned in this protocol.

Clogging Attack on Moosavi et al.'s Protocol
The security analysis of [33] has been performed as in Section 5 of their paper [33].The adversary A has the same power as assumed by Moosavi et al.A needs to be able to read and modify the contents of messages over an insecure channel during the tag identification and tag verification phases of the protocol [1].The line of attack in this work is a denial of service where the objective of A is to bring down the whole RFID system.There are two steps (a map-to-point conversion in Step V6 and a scalar multiplication in Step V2) where ECC techniques are used that A can target [1].However, since it would be more profitable to render the reader R useless, the line of attack chosen here will target bringing down the reader R, such that it would not be able to provide service to legitimate tags.A would make the reader R repeat Steps V1 through V7 to compute the ECC steps several times.A can change all of the incoming login request messages from any legitimate tag to R. Since the ECC steps are computationally intensive [15], the victimized reader R spends considerable computing resources doing useless ECC computations (a map-to-point conversion in Step V6 and a scalar multiplication in Step V2) along with the other steps, V1, V3 through V5 and V7, rather than any real work.Thus, A clogs R with useless work and therefore denies any legitimate tag (user) any service.A needs only an ID of a single valid tag to perform the clogging attack [1].
It should be noted that even DoS-resilient mechanisms (e.g., timeout or locking the user account for a period of time after a predefined number of login failures) are introduced on reader R's side; it may be not a real obstacle for attacker A, as it can initialize new sessions with different intercepted identities in an interleaving manner.Hence, A can potentially perform the above attack procedure continuously.If distributed DoS attacks are launched based on this strategy, the consequences will be more serious [1].

Proposed Countermeasures from the Attack
At the beginning of the authentication phase, the reader could check whether the network address of the tag is valid.It has to know the network addresses of all of the registered legitimate tags.In spite of that, A could spoof the network address of a legitimate tag and replay the tag verification message.To prevent this spoofing, a cookie exchange step could be added at the beginning of the tag verification phase of Moosavi et al.'s protocol [1].This step has been designed as in the well-known Oakley key exchange protocol [34].
1.The tag T chooses a pseudo-random number n 1 and sends it along with the message {ID t , (d, c)}. 2. The reader R, upon receiving the message, acknowledges the message and sends its own cookie n 2 to T. 3. The next message from T must contain n 2 , else T rejects the message and the tag verification request.
Security analysis of the fix: Had A spoofed T's IP address, A would not get n 2 back from R. Hence, A succeeds only in having R send back an acknowledgment, but not in launching the computationally-intensive ECC-based operations.Hence, the clogging attack is avoided by these additional steps.It must be noted, however, that this process does not prevent the clogging attack, but only repels it to some extent.This fix can fully work only if n 1 and n 2 are encrypted respectively by T's and R's private keys for a secure communication [1].

Xu et al.'s Smart Card-Based Protocol
The next protocol we look at in this work is that of Xu et al. [26].It is an ECC-based remote authentication protocol involving smart cards.Xu et al.'s protocol in [26] is an improvement over its predecessor, Li et al.'s protocol [35], which [26] proved to be vulnerable against the off-line password guessing, user impersonation and the denial of service (DoS) attacks.The authors in [26] came up with a new protocol, which they claim is immune against all three attacks.
We briefly present Xu et al.'s protocol.We then present a clogging attack on the protocol.Most of the protocols they cite in their paper [26] are vulnerable to clogging attack.We then suggest a possible fix against clogging attack for this protocol [1].

Review of the Protocol
Xu et.al's protocol works in five phases: registration, authentication, password change, card revocation and user eviction.Figure 7 shows the notations used for the protocol.
We present the registration, authentication phases of the protocol in Algorithm 5.The other phases are omitted since they are not needed to demonstrate the clogging attack [1].

Clogging Attack on Xu et al.'s Protocol
The adversary A has the same power as assumed by Xu et al's [26] while exposing the weaknesses of Li et al.'s protocol [35].A needs to be able to read and modify the contents of messages over an insecure channel during the authentication phase of the protocol [1].

A intercepts a valid login request ({CID
A simply replays this login message to S.

Lemma 1. The server S is forced to perform
Proof.The only step that could prevent the server S from executing further steps is Step A9.We claim )) would always be true if B 1 and R 1 are valid.To prove our claim, we note Therefore, if we have a valid B 1 and R 1 , the values of R 2 and R 2 always match, which proves the claim.
The adversary A replays the message {CID i , B 1 , R 1 } several times and makes the server S compute Steps A8 through A15 (by Lemma 1).These steps contain several scalar multiplications and map-to-point conversations.A could potentially store all of the incoming login request messages from any legitimate user to S for future replay.Since the mathematical operations in the steps are computationally intensive, the victimized server spends considerable computing resources doing useless computations rather than any real work.Thus, A clogs S with useless work and therefore denies any legitimate user any service.A needs only one message from a single valid user to perform the clogging attack repeatedly [1].
However, as [26] noted, the adversary A cannot get a legitimate access through this replay attack.Since r u will be different each time, the check B 2 = h 0 ((W i ⊕ HPW i ) h 0 (R 2x R 2y )) on the user's side will not pass.However the intention of A here is not to gain illegitimate access, but to bring down the server by launching a clogging attack [1].
Clogging attack performed on other similar schemes: The clogging attack performed on [26] can also be performed on Li's protocol [35].The clogging attack on Li's protocol is more effective because Li's protocol [35] uses the most computationally-intensive bilinear pairing operation.Both the protocols by [26,35] are vulnerable because the user's smart card does not encrypt the message it sends to the server for login and authentication.Thus, the adversary has the chance to manipulate the message.
Proposed countermeasures from clogging attack: Replay attacks on most smart card-based protocols are possible because their security relies on computationally-intensive operations (in this case ECC), and the messages are not encrypted by default.This vulnerability is often overlooked, since the natural result of a replay is not a DoS.An approach to reducing these attacks on Xu and Wu's protocol (and smart card based protocols in general) would be: 1. U i uses a time stamp T in Step A7, and S verifies it in Step A8.The time stamp also must be encrypted in some form, so that A cannot tamper with it.2. S checks whether multiple login requests frequently comes from the same user.This reduces the chances of a reply.
The chances of a replay are reduced, but not eliminated, because A can obtain many valid user IDs (they are public) and send fake login requests periodically from different IDs.Alternatively, A can store various (valid) login requests over time and replay them periodically [1].
Yet another way to prevent clogging attack: The mathematical basis of the protocols' vulnerability to clogging attacks is modular exponentiation.An approach to completely avoiding clogging attacks would be to encrypt all of the messages between U i and S. Doing so would require a key exchange step, where each user has a private key and a public key [1].The server knows the public key and can decrypt a message encrypted by a user's private key.Thus, the server makes sure that the message is from a valid user before it computes the costly modular exponentiation.This approach comes with a cost and depends on the level of security desired.This countermeasure works for all protocols (whether or not they are smart card based) [1].

Weak Authentication and SQL Injection Attack
The proposed scheme in this paper does not mention how the ID and N are stored in the account table in the registration phase.The paper does not mention if an encryption is present at the database level.Under the assumption that the account table is accessible to an untrusted source, ID and N can be dynamically constructed in the query thus leading to a SQL injection attack.Furthermore, under the assumption that ID and N are unprotected, a weak authentication attack is possible, as well.These attacks lead to loss in confidentiality, authentication, authorization and integrity.Hence, we conclude that the database layer authentication is not strong enough to protect unknown users from gaining access to the database.
Proposed security countermeasures for the weak authentication attack: SQL injection attacks can be defeated by parsing and validating SQL communications to make sure they are not corrupted.If the protocol shows how the ID and N are stored and protected in a table, then the attack will be minimized.The weak authentication attack can be protected by adding more access layers and by enforcing strict user privileges.

Unauthorized Access Attack
In [26], in Sections 4.4, card revocation, and 4.5, user eviction, talk about a smart card being stolen and verified after being stolen.This can lead to a potential risk.If the smart card is stolen by the attacker, the user ID and the password will be accessible to the attacker.The attacker can enter malicious input and potentially hack the database server.Under the assumption that the smart card re-registration phase is unprotected, the unauthorized access attack is possible on this protocol.For example, an unauthorized client can steal the smart card or eavesdrop on the information exchanged between a legitimate client and directory server.This critical information such as user ID and password can be used to cause other major attacks.
Proposed security countermeasures against unauthorized access attack: To counter unauthorized access, card revocation should be handled by more efficient algorithms.Authentication methods, password policies and access control mechanisms provided by the directory server offer efficient ways of preventing unauthorized access.A network firewall, consisting of a hardware device, software program or a combination of the two, protects an internal computer network against malicious access from the outside.Network firewalls may also be configured to restrict access to the outside from internal users.

He et al.'s RFID-Based Authentication Protocol
The next protocol we analyze in this work is due to [36].This is an RFID-based authentication protocol to preserve identity privacy.He et al.'s protocol is an improvement over [37], which proved to be vulnerable against impersonation and insider attacks.Figure 8 shows the notations used for the protocol.This protocol has been proven to be immune to various attacks [36].We present a clogging attack on the protocol and observe that it is inherently vulnerable to clogging, weak authentication and SQL injection attacks.The proposed ECC-based RFID authentication scheme consists of two phases, i.e., the setup phase and the authentication.We present the protocol in Algorithm 6.

Clogging Attack on He et al.'s Protocol
The adversary A has the same power as assumed by [36] while exposing the weaknesses of Liao's protocol [37].A needs only to be able to read and modify the contents of messages over an insecure channel during the authentication phase.The steps taken by A to perform the clogging attack are as follows: • Since the message is unencrypted, A changes Auth T to any random garbage value Auth A .
• A then sends {R 2 , Auth A } to the server S.
The following is performed by the server S: 1.The server S calculates TK S1 = X S R 2 , TK S2 = r 1 R 2 and X T = (AuthA ⊕ TK S2 ) − TK S1 .2. The server searches its database for X T .It is not found, and therefore, the server terminates the session.
A would now repeat the steps several times and make the server S compute the elliptic curve operations several times in Steps A5 and A6.A can potentially change all of the incoming login request messages from any legitimate tag to S. Thus, A clogs S with useless work (ECC operations) and therefore denies any legitimate user any service.A only requires the value of X T of a single valid user to perform the clogging attack repeatedly.Step S1.The server S chooses a random number x S ∈ Z * n such that P S = x S P. 2.
Step S2.The server S chooses a random point X T on the elliptic curve E for each tag.3. Step S3. S stores the ID-verifier X T and parameters into the tag's memory.The server also keeps x S as its private key, and stores X T into its database.

AUTHENTICATION PHASE
Step A5.The server S calculates TK S1 = X S R 2 , TK S2 = r 1 R 2 , and Step A6.The server search its database for X T .If it is not found, the server terminates the session.Otherwise, the server calculates Step A8.The tag checks whether (X T + 2TK T1 ) ⊕ (2TK T2 ) and Auth S are equal.If they are not equal, the tag terminates the session, otherwise, the server is authenticated.
Proposed countermeasures for the clogging attack: One reason for the vulnerability of this protocol is that the messages m 1 , m 2 , m 3 are not encrypted; if the adversary gains access to the message m 2 , then repeated transmission of this message can clog the server.Furthermore, the timestamp checking is not used between the tag and the server.Although, random numbers are generated in every step and used for real-time calculation, when messages are not encrypted and timestamps are not used, the messages are open to the adversary to modify and replay.The solution could be to add a timestamp T i to R i or to m 2 .The server can check the validity of the timestamp before it performs the elliptic curve operations.

Weak Authentication Attack
The authors in the paper [36] do not mention how X T (ID identifier) is stored in the database.Weak authentication schemes allow attackers to assume the identity of legitimate database users.Specific attack strategies include brute force attacks, social engineering, and so on [27].Under the assumption that X T is unprotected, the adversary can gain access to X T resulting in unauthorized data access, corruption or availability.Hence, weak authentication attack is possible assuming the database layer authentication is not strong enough to protect unknown users from gaining access to the database.
Proposed security countermeasures for the weak authentication attack: To prevent weak authentication attack, the implementation of passwords or two-factor authentication is a must [27].Had the protocol [36] included security and protection for X T , the weak authentication attack could have been avoided.The weak authentication attack can also be prevented by adding more access layers and by enforcing stricter user privileges.

Desynchronization Attack
A desynchronization attack is a typical RFID related threat in which a tag's key stored in the back-end database and the tag's memory would not be the same, because an attacker blocks the communication between the parties.The paper [36] mentions that X T is not performed (X T is an ID identifier).Their paper claims that the proposed scheme provides scalability, availability and DoS resistance by not updating X T .To provide privacy protection, most RFID authentication schemes update the tag's secret information, in the back-end database, as well as in the tag, after a successful protocol run.Therefore, synchronization of secret information between the database and the tag is crucial for subsequent authentications.The most serious threat to which an RFID tag is vulnerable is the desynchronization attack.During the past few years, RFID technology has become ubiquitous as the cost got lower; it is used in every field, and hence, this vulnerability raises a threat in the area of data protection.
Proposed security countermeasures for the desynchronization attack: One of the countermeasures is to update the X T after each run.It is an intractable task to design the lightweight RFID authentication protocol, because the security engineer must cope with the trade-offs among security, cost and performance.In the future, the security engineers can be made aware of the trade offs so as to build an efficient protocol.

Hui et al.'s Protocol
The next protocol we analyze is due to Hui et al. [38].In that paper, after pointing out the weakness of the password change phase of Islam et al. [39] and after the evaluation of several other password authentication schemes, [38] have presented a new password-based authentication and update scheme using ECC and showed that it can resist various attacks.However, in this work, the protocol is shown to be inherently vulnerable to clogging, weak authentication and SQL injection attacks.

Review of the Protocol
Hui et al.'s protocol works in four stages: registration phase, password authentication phase, session key distribution phase and password change phase.We present the protocol in Algorithm 7. Figure 9 shows the notations used for the protocol.
The server S performs Steps C10 through C15 since the ID matches.A would now repeat the steps several times and make the server S compute the computationally-intensive elliptic curve bilinear mapping function of Step C11 and collision-resistant hash function of Steps C13, C15 several times.Thus, as in the previous case, the server gets clogged doing unnecessary computations.
Proposed security countermeasures against the clogging attack: The vulnerability of this protocol is due to the fact that the message (ID C , W C , M 1 ) is not encrypted and the timestamp is not used.The protocol can be strengthened by using strong encryption of the messages M 1 , M 2 and M 3 .Furthermore, adding the timestamp to the messages at the time of run will ensure privacy and thus prevent replay attacks, which leads to clogging.

Unauthorized Access Attack
Unauthorized access is the act of gaining access to a network, system, application or other resource without permission.Unauthorized access could occur if a user attempts to access an area of a system they should not be accessing.Unauthorized access could be the result of unmodified default access policies or the lack of clearly-defined access policy documentation [40].In the paper, [38], ID C and U C are stored in a write-protected file in Step C4 of the registration phase.Their paper [38] does not mention how the file is stored and also if it is protected using standard security measures.Under the assumption that the ID C and U C are unprotected, an unauthorized client could potentially steal the write protected file or eavesdrop on the information exchanged between a legitimate client and the directory server.When the file containing the ID and password becomes accessible to an unauthorized user, the protocol is compromised under this attack.
Proposed security countermeasures against the unauthorized access attack: Unauthorized access can occur from inside the organization or, if the organization is connected to an extranet or to the Internet, from outside.The authentication methods, password policies and access control mechanisms provided by the directory server offer efficient ways of preventing unauthorized access.A network firewall protects a computer network from unauthorized access.Network firewalls may be hardware devices, software programs or a combination of the two.Network firewalls guard an internal computer network against malicious access from the outside.Network firewalls may also be configured to restrict access to the outside from internal users [40].

Unauthorized Tampering Attack
Tampering is the unauthorized modification of data by an unauthorized user.When an unauthorized user gains access to the write-protected file in which ID C and U C are stored or if they intercept communication between the directory server and a client application, they have the potential to modify the directory data.These unauthorized modifications may include: • Unauthorized modification of data • Unauthorized modification of configuration information • Alteration or cancellation of client's request to the server • Alteration of the server's response to the client Adversary A can cause all other kinds of attacks if the write-protected file is accessible to them as it contains all of the user identity's and passwords.
Proposed security countermeasures against the unauthorized tampering attack: An adversary A could alter a client's request to the server, cancel the request, or change the server's response to the client.The countermeasures include using the secure socket layer (SSL) protocol to solve this problem by signing information at either end of the connection.Another solution could be to store the ID A and U A in the cloud instead of a physical device.

Ammayappan et al.'s Protocol
The final protocol considered in this work is that of Ammayappan et al. [41].This is a key agreement protocol and works in a mobile ad hoc network (MANET)-based environment.Ammayappan et al. show their protocol to be immune to the man-in-the-middle (MITM) attack, and they claim that the protocol's security is based on the ECC logarithm.

Review of the Protocol
The protocol by [41] works in two phases: registration phase and active phase.Figure 10 shows the notations used for the protocol.This protocol uses trusted third party (TTP) as a certifying authority.The protocol is presented in Algorithm 8.

Man-In-The-Middle Attack on the Protocol
The adversary E has the same power as assumed by Ammayappan et al. in [41] while performing the security analysis of their protocol.E is allowed to read and modify contents of messages over an insecure channel (during the active phase of the protocol).The line of our attack is an MITM attack where the objective of E would be to impersonate one party (e.g., A) while communicating with the other (e.g., B).E is allowed to read and modify contents of messages over an insecure channel during the active phase of the protocol.Ammayappan et al. claim that their protocol ensures security through the elliptic curve discrete logarithm.However, the protocol can be compromised even with ECC being used in the protocol as a security measure.

Summary of the Results
In order to demonstrate the vulnerabilities of the five protocols considered, the author designed generalized cryptanalysis algorithms to perform MITM, database and clogging attacks on the protocols that use ECC as a security measure.First, the protocols of [26,33,36,38] were shown to be vulnerable to the clogging attack.The vulnerability lies in the use of computationally-intensive ECC by the server in the authentication process.In this analysis, it was observed that a combination of encryption, a nonce and a timestamp would prevent clogging attack vulnerability in these three protocols.These protocols were also shown to be vulnerable to database attacks, such as weak authentication, SQL injection, desynchronization, unauthorized access, unauthorized tampering and database protocol vulnerability.In this analysis, it was observed that using input validation, an updated ID process, a network firewall and encryption would prevent database attack vulnerability in these protocols.The key agreement protocol in [41] was analyzed next.Ammayappan et al. showed their protocol in [41] to be immune to the MITM attack, and they claimed that the protocol's security is based on the ECC algorithm.However, in this work, their protocol was shown to be inherently vulnerable to the MITM attack.
Table 2 summarizes the vulnerabilities found in the protocols analyzed.A 'Yes' in a cell indicates that we found the designated protocol vulnerable to the designated attack through a static analysis, and a 'No' means that no vulnerability was found.It is evident that most of the protocols are vulnerable to classical clogging and database attacks.
The countermeasures are also summarized in Table 3.It must be emphasized that as everything has costs involved, the level of security needed will determine the nature of the counter-measure.

Conclusions
In this work, clogging attacks and database attacks have been demonstrated on five advanced ECC-based authentication schemes.The goal was to uncover the subtleties and challenges in designing such protocols.ECC techniques guarantee a level of security.However, they might still contain an easily-exploitable vulnerability if they are used without an additional level of protection.Hence, some level of protection should be added to them to guarantee total security against clogging attacks.
It is concluded that ECC guarantees a level of security, but it might create a vulnerability if it is used without an additional level of protection.Most of the multi-factor authentication and key exchange protocols in the literature, whether smart card or RFID based, rely on ECC for their security.Hence, an additional layer of defense should be added to them to guarantee increased security against MITM, database and clogging attacks.

Directions of Future Research
Research on elliptic curve cryptography authentication protocols is ongoing.This research has been conducted using static analysis.An obvious next step is to test the dynamic vulnerability of these protocols.The documentation presented here will lay the groundwork for performing dynamic analysis on ECC-based protocols.This documentation provides detailed steps and procedures to perform static analysis.Our suggested countermeasures on strengthening the security flaws in the above protocols will provide a strong basis to perform dynamic analysis.Other kinds of security flaws could potentially be discovered while performing dynamic analysis.

1 .
A intercepts a valid message of T→R: {ID t , (d, c)} from Step I10. 2. Since the message is unencrypted, A can always change the (d, c), such that d, c ∈ Z n holds (though A might not need to). 3. A just relays {ID t , (d, c)} to R. The following is performed by the reader R: 1. Step V1.Choose a random integer r s ∈ Z n .2. Step V2.Compute public key p r = r s • P. 3. Step V3.Verify if d, c ∈ Z n .4. Step V4.If true, compute h = Hash(ID t ). 5. Step V5.Compute w = c −1 mod n, u 1 = zw mod n, and u 2 = dw mod n respectively.6. Step V6.Compute curve point (x, y) = u 1 • P + p r .7. Step V7.Verify if r = x mod n.If true, authenticate tag T.

Figure 8 .
Figure 8. Notations for He et al.'s protocol.

Algorithm 6 :
He et al.'s protocol.SET UP PHASE 1.

Algorithm 9 : 1 . 1 . 1 .
Ammayappan et al.'s protocol under MITM attack.Node A Step A1.Choose a random number r A and computes Q A = r A • P as its public key.2. Step A2.Node A sends AReq(Token A , RN A , Q A ) to Node B. Adversary E Step E1.Modify the message to AReq(Token A , RN E , Q E ) and sends to Node B. Node B Step B1.Compute SK BE = H((r B + b)

Table 1 .
Summary of the differences in the protocols.

.
Step E4.Construct message m 2 = RN A ||RN E ||Q E ||HMAC E 4. Step E5.Generate Sig E (m 2 ) = (r, s). 5. Step E6.Send Arep(m 2 , Sig E (m 2 )) to Node A. Step B5.Compute SK BE = H((r E + e).(Q B + Pub B ) ID E ID B RN E RN B ), HMAC E = H(SK BE H((Q E • x + Q B • x) (Q E • y + Q B • y) ID E ID B RN E RN B ). Compute SK AE = H((r A + a) • (Q E + Pub E ) ID A ID E RN A RN E ), HMAC A = H(SK AE H((Q A

Table 3 .
Summary of the results.