A new secure authentication based distance bounding protocol

Contributions

The main contributions of this paper are:

• The paper provides the detailed explanation of 12 existing DB protocols. Overview of each protocol is presented.

• A new protocol is proposed, highlighting all the phases of the DB. Threat analysis and security validation is performed on the proposed scheme.

• An analysis is also presented with the help of 10 metrics to draw comprehensive comparison among existing DB protocols and our proposed scheme.

• The practical implementation of the protocol in carried out using Python.

• Areas of application and future horizons for research are discussed.

Outline

The outline for the rest of the paper is as follows:

• It gives literature review of the many existing DB protocols as well as describes a system and threat model against many known DB protocols.

• It presents the proposed protocol in detail and explains each phase of the scheme extensively.

• It also presents a theoretical comparison of our proposed protocol against many studied DB protocols.

• It explains the security analysis and validity assumptions made for analysis of the proposed protocol.

• The performance analysis of the scheme under situation of Mafia Fraud and Replay Attack is discussed. The areas of application of the proposed scheme are presented.

• Open areas for research and future works are discussed and paper is concluded.

Distance bounding protocols

These are cryptographic technique which allows two parties (Verifier and the Prover) to verify each other over a particular distance. The protocol has three phases namely; Initialization Phase (IP), Rapid Bit Exchange Phase (RBEP) and Authentication Phase (AP).

1. First Step—Initialization Phase: The protocol starts with the both the parties sending each other challenge bits (Nonces, Bit String, etc.). The next step involves both parties generating their specific bit-sequences using a function which could be either Pseudorandom Function (PRF), Hash Function, MAC Algorithm etc.

2. Second Step—Rapid Bit Exchange Phase: The verifier then send a bit to the prover. The prover replies with a particular bit (on the bit received from the verifier side). This is iterated “k” times (where k is pre-determined). The verifier then computes the time of the phase.

3. Third Step—Authentication Phase: The basic protocol in terms of authentication was studied by Bellare & Rogaway (1993); Guttman, Thayer & Zuck (2004). Nonce is generated by reader which is used to create Pseudo Random Number, using Pre—shared Pseudo Random Function and key. The whole is sent to the prover P which then verifies the string and applies the same process and sends his nonce to the reader. Both in this way authenticate each other, thus given the name “Mutual Authentication”.

   All DB protocols involving the round trip time; work on the following assumptions as presented by Desmedt, Goutier & Bengio (1987):

   • The noise delay and cryptographic operation delays should not slow down the protocol.

   • Speed of light will be used to calculate t_max.

   • 1 bit is sent for the calculation of round-trip time.

   • During the Rapid Bit Exchange Phase, no other computation is occurring.

Cryptographic primitives

Before digging into the protocol, there are some cryptographic functions that need to be discussed briefly.

1. Hash functions “h”

A variable input is given to the hash function, which converts it to a fixed length value output, which is the hash. Given that one knows the hash, it is practically impossible to obtain the input value. These makes the hashes very secure and unbreakable. More of this is given in Sobti & Geetha (2012). Figure 1 shows a simple hash function. Another property which the hash must have, is that by flipping of one bit from the input, the change in the output of the hash should be more than 50%. This is also known avalanche effect Motara & Irwin (2016).

2.Message Authentication Code (MAC)

Message Authentication Code (MAC) Bernstein (2005) is a short piece of information, used to determine the authenticity and integrity of the message; i.e., that it came from the actual sender and that it has not been tempered with on the way. The verifier can detect changes made to the message. “Tag” is also a name given to the Message Authentication Code. Figure 2 shows MAC.

3. Pseudo Random Function (PRF)

Pseudo Random Function Håstad et al. (1999) as the name suggests, are functions whose all outputs are random answers (such that they are close to randomness since absolute randomness is impossible), irrespective of how the inputs are chosen. Pseudo Random Functions are not be confused with Pseudo Random Generators. The latter generates single random output for random input. The PRF generates random outputs regardless of the input given.

4. Commitment Schemes (CS)

This scheme allows a party to commit to a certain value, but keeps it hidden from other parties. The value can be revealed at a later stage. Once committed (as the name suggests) the party cannot change the value.

The scheme consists of two algorithms;

• Com = Commit (msg, nonce); function takes a message and a nonce as input and return a commitment.

• Verify (com, msg, nonce); function takes a commitment, message and a nonce as input and return true if values of comm matches and false otherwise.

As stated before, two properties should hold;

• Given “com”, it is computationally impossible to find the message.

• For an attacker, it is computationally impracticable to find a rogue pair (msg’, nonce’), such that; comm = comm’

  where; comm = legitimate commitment comm’ = rogue commitment

5. Zero Knowledge Protocol (ZKP)

It is a method in which two parties; the prover proves to the verifier, that he knows a certain value without communicating the value itself. No other information is conveyed. The challenge is for the prover to prove himself without revealing any additional information Guillou & Quisquater (1988). It is also termed as Zero Knowledge Proof.

Pre-computational phase

Both Verifier and Prover generate random nonces “N_v” and “N_p” respectively. These nonces are used to generate k-bit strings “a” and “b” on the prover and verifier side respectively. The prover uses the shared secret x while the verifier uses shared secret “m”. The cryptographic function used for derivation at both ends is shown in Fig. 5. This function can be a trade-off between hash, MAC, PRF etc. based on available resources.

Initialization phase

Both parties send their nonces to each other. They use the nonces of each other to generate “b” and “a” at the prover and verifier side respectively. the same cryptographic funtion is used as shown in Fig. 5. Only this time the prover uses the shared secret “m” while the verifier uses shared secret “x”. The verifier chooses a k-bit random sequence α_i.

Rapid bit exchange phase

The verifier starts the timer and sends first bit of the α_i to the prover. The prover replies with his response β_i in the following manner:

If α_i = 0 ; β_i = a_i and; if α_i = 1; β_i = b_i

Although the value of α_i is random, the prover will be on the lookout for a specific sequence of bits, e.g.; 1011. After completion of this sequences 1011, the immediate next bit of α_i will determine the response from the prover. The replies will be reversed.

If α_i = 0; β_i = b_i and; if α_i = 1; β_i = a_i

The rest of the protocol will follow as usual. The significance of this sequence is that it allows the prover to verify the verifier without putting computational load on the protocol. In case, where mutual authentication is not required this part can be replaced with the simple relaying of a challenge bit α_i from the verifier, resulting in a response bit β_i from the prover’s side.

Authentication phase

The verifier will verify the responses β_i. He will compute the error in the transmission, which includes checking the received value of β_i with the pre-computed one. For instance, let β be the bit received after the RBEP and β′ be the original (intended) values (pre-computed on the verifier side). Error will be calculated as:

err β = count β_i! = ${\beta }_i^{\prime }$ and Δ t_i > t_max

where; β_i = response bit ; ${\beta }_i^{\prime }$ = pre-computed bit If the value error is greater than a pre–computed threshold “T”, then the process will be terminated. For argument’s sake, if at the end of the protocol, the verifier has all the values of β_i, transmitted by the prover in RBEP. He computes error of each individual bit, by comparing each transmitted β_i with his own computed values of β_i. Error percentage is computed. If the error exceeds a pre-defined threshold, the protocol is stopped. The mathematical representation of the protocol is given in Table 2.

Table 2:

Proposed Protocol.

DOI: 10.7717/peerjcs.517/table-2

Correctness of proposed protocol

Our proposed protocol consists of two entities i.e., Prover P and Verifier V having their own secret keys “x” and “m” respectively. Before the formal start of protocol, the nonces are generated and fed into a cryptographic function along with secret keys as another input to derive 2 different 512-bit length strings, one on each side. After the protocol initiates, nonces are shared between both parties and the opposite bit strings are derived using the same function but with the opposite entity’s secret key as the second output.

Since the cryptographic function is already known and nonces are shared over wireless media, an adversary can sniff / or capture these nonces and use them to derive bit strings used during RBEP if and only if he has both the secret keys. Keys are pre-shared and are never shared publicly. Since both entities know both the bit strings, it’s very easy for verifier to generate a random bit sequence and send it as challenge to prover and for prover to respond with the correct bit. Verifier checks for the authenticity of the prover’s response by verifying values with his own and computes error. In this scenario, since both entities have the same sequences at their end i.e., all the values of a, b, α_i and its corresponding β_i, it’s very easy for the protocol to run its course smoothly and prover gets authenticated and is granted access.

Comparison with existing DB protocols

The protocol was analysed for attacks and error resistance. Any errors faced during the RPEP are detected. The last entry in Table 3 compares our proposed scheme with the rest of the literature.

Our proposed protocol has privacy preservation from outsiders and does not reveal secret keys to the attacker. The possibility of a Man in Middle Attack exists where the attacker can only sniff the traffic, but cannot relay it over a long distance because that would cause delay in propagation time. The total computation involves the use of two PRFs, one on each side in the Initialization Phase and Error Check towards the verifier side in the Authentication Phase. The comparative performance and security analysis of the twelve well known protocols were carried out for a better understanding and working of the overall DB protocol. The conclusion drawn were used to strengthen the protocol that we designed in this study.

The proposed protocol as evident from Table 3, has numerous benefits over other DB protocols. Our proposed solution has capability of pre-processing, which means that the initial generation of the nonces and the encrypted numbers “a” and “b” can be carried out beforehand, which reduces the resources for on chip processing. It uses hashes and PRF which are secure for less complex key phrases for a longer time without compromising the resource need. The protocol is resistant to most forms of attacks and channel errors. The total computation is of the scheme is 2(PRF) + (EC). The notion of Mutual Authentication is optional as we feel that this will burden the protocol and make it impractical. However, this may pave way for further research and future studies.

An theoretical analysis given in Table 3 indicates the numerous functions used in the phases. It also presents the computational time taken by the protocol, the use of PKI, attack possibility and resistance, reason for possibility and / or success of the attack. The comparison is based on several parameters; security dependence, pre-processing capability, cryptographic primitives used, defence and vulnerability to known attacks, error resistance to channel error, privacy preservation to outsiders and total computational cost of the entire protocol (based on the constrained functions used) of each scheme. These all together make up a total of 10 common metrics, which are carefully chosen after the study of various DB protocol.

Assumptions

Before the analysis of the protocol, the following assumptions are made:

• The legitimate Prover and Verifier are denoted by P and V, while the rogue Prover and Verifier are denoted by P’ and V’.

• Statistical Attacks like brute force attacks are possible even on the most secure encryption standards like DES and AES. We will not explain them in much detail as it falls out of the scope of this research. Also, for k = 512, there exists 2⁵¹² combinations for α_i. Brute forcing the RBEP with each combination is impractical and useless for the assailant.

• The pre-shared secret is only present with the verifier and the prover and there is no way for an attacker to extract them other than by means of a Node Capture Attack (NCA).

Security against threat model

1. Mafia Fraud (MF)

   Since it has been established before that the only way to achieve full protection against mafia fraud attack is to either use PKI or Zero Knowledge Protocol. Both of them are computationally heavy and therefore cannot be applied in this domain. Thus, a clever approach is needed.

   In a scenario where Actual Prover P and Verifier V are not close to each other, it is impossible for P’ and V’, to relay messages between them without considerate delay (which would cease the protocol). The use of random α_i also prevents replay attack.

   Pre computation and initialization phase

   As the function used in Pre Computation and Initialization Phase is pseudo-random, therefore guessing of any bit of “a” and “b” by the attacker is negligible. The probability is further minimized by the use of different keys for “a” and “b”. This further achieves randomness.

   Rapid bit exchange phase

   For the Rapid Bit Exchange Phase, the Actual Prover “P” looks for a specific sequence (for example: 1011). When this sequence is completed, in the next consecutive bit only, the reply from the Actual Prover P is reversed (as seen in the protocol).

   Authentication phase

   If in any case if the attacker is using his own pair of a’ and b’; then the probability that he will send the specific sequence of α_i in RBEP is very low i.e., lower than (1/2) n as depicted by Hancke & Kuhn (2005)), and becomes even lower due to use of random α_i in each RBEP. The probability becomes even lower than he can respond correctly i.e., send correct β_i with the order reversed. The checking of corresponding bits by the verifier V and calculating error further reduces the attackers’ chances. The same can be applied to Impersonation Fraud (IF) and Man in the Middle Attack (MIM).

2. Terrorist Fraud (TF)

   To prevent this attack, the Rapid Bit Exchange Phase (RBEP) are mingled by means of cryptography. The protocol cannot be split into two discrete segments by the rival. This can be accomplished in two ways i.e., to use confidential hardware and / or to use well secured private (or symmetric) key during RBEP.

   Both of these steps are computationally constrained and slows down the protocol. In simple words, the attacker should not be able to achieve the information that the Actual Verifier V holds, which is the shared key “x” and transient key “m”.

   In case of our protocol, let actual Prover P be far from the actual Verifier V and close to the rogue Prover P’. He relays the pair a_i and b_i as per the protocol to the Rogue Prover P’, independent of the value of α_i (as the actual Verifier V isn’t close by). If the verifier is close by, then the attack becomes replay attack. Even if P’ possess all the values of a_i and b_i, and relays it to the actual Verifier V, even then guessing the shared secret “x” and “m” is impossible because:

   • The probability that the pair a_i and bi are in sync with α_i while communicating with V is very low (very less than (1/2) n). Also, for 512 bits, the combination of α_i becomes 2⁵¹². This means that guessing the sequences is near to impossible.

   • Even if some of the values do go in sync with the challenges, they will not be able to sustain the error threshold, and will be filtered. This will also only give very less and ineffective information regarding the shared secrets.

   • Both functions encrypting the nonces use a separate key “x” and “m”.

   • Independently “a” and “b” cannot be used to obtain the information that the attacker seeks.

   • As the Verifier V does not reject the value of β_i, therefore the ith position remains secret to the attacker.

   • The prover will be on the lookout for the specific sequence which will be used by the entity as a way of authenticating the verifier. Given that this sequence is not received in the entire Rapid Bit Exchange Phase, it will raise suspicions to the prover. If the prover’s reply is not reversed, this will alert the verifier.

3. Distance Fraud (DF)

   For the attacker to execute a distance fraud attack, the value of β_i should be responded in advance by the rogue Prover P’, for which he needs to choose the response at random and send it to the Actual Verifier V.

   The probability that the “β_i” chosen by the P’ is matching the actual β_i is very low; keeping in mind that not only are these values pseudo-random, but also use different keys for randomness. The reversing of β_i in the Rapid Bit Exchange Phase further minimizes the chances of a match. If the value of α_i bits for the RBEP is 512, then the combinations possibly become 2⁵¹². Guessing this many combinations is impossible for the rogue Prover P’ in the given time without much delay. The error checking in the Authentication Phase will render the attack useless. Also, if it is resistant to DF; therefore according to Brelurut, Gerault & Lafourcade (2015), it is secure against Distance Hijacking (DH) as well.

4. Node Capture Attack (NCA)

   The threat of theft is possible in all devices. The tag or reader; if stolen can be read by a chip / RFID reader and necessary information can be extracted. Therefore, the following measures should be taken:

   • Keep the verifier (reader in case of an RFID) in a secure place. For example, in a key less entry system used in vehicles, the reader (ECU) is inside the vehicle in the dashboard and is well protected by lock and key. If a malicious entity gains entry into the vehicle, even then accessing reader (ECU) is a difficult task, usually involving the breakage of the dashboard panel at the back of the steering wheel.

   • Keep the prover (tag in case of RFID or key fob in case of keyless entry system) on your person while in the vicinity of the verifier (reader). The tag should be kept secure even when not in use.

5. Mutual Authentication

   The verifier authenticates the prover in the last phase (Authentication Phase) where the error is computed, time of the protocol is checked and access is either granted or denied.

   Older schemes either lacked mutual authentication; or the ones that did not, involved the use of signatures which made the protocol computationally heavy or impractical.

   In our employed scheme, the prover is on the lookout for a specific pre-shared sequence that actually authenticates the verifier. This provides only Pseudo –Authentication as the sequence can come in any of the combinations, but even then, it is better than having no authentication at all. This provides double verification of the prover as well as the response of these sequences in the later phase authenticates the prover.

6. Relay Attack

   It is impossible for P’ and V’ to relay messages between themselves and towards the legitimate parties without considerate delay where any delay above a certain time limit will cause the protocol to terminate. There is also a chance of error during transmission. The time of the RBEP Δt_i is checked in the Authentication Phase i.e., Δt_i = < t_max (standard time for protocol run).

7. Replay Attack

   Take an example where Actual Prover P and Actual Verifier V are close to each other, and an attacker posing as MIM. He can capture the values of β_i and then replay them at a later time. This issue is resolved in the RBEP. The value of α_i is random and therefore the response which the verifier wants is also random (response β_i depends upon the value α_i). There is a probability of 0.5 that the first value of α_i may match (either 0 or 1). But this probability becomes unimportant with the bit size of 512, the combinations of α_i being 2⁵¹², and as we move from the second bit to the last (512th bit).

8. De-synchronization Attack

   The chances of De-synchronization Attack are very less because:

   • The keys are pre-shared, not updated and remain the same.

   • The distance involved is very less (few meters).

Areas of application

Distance Bounding Protocols find their applications over a lot of technologies. The practicality of these application has spread after the rise of newer techniques like NFC, Contact-less payment, Key less Entry Systems, Ticketing, RFIDs, entry and exit at a specific point, attendance of employees via tags, access to systems (like computer) via tags, etc. The list is by no means exhaustive and can be further explained.

For our study, we restrict ourselves to modern key less entry systems used in vehicles specially cars nowadays, where the distances taken into account are not that large. That being said, the danger of malicious entry is still there and becomes somewhat of paramount importance given the fact that the entry system in the vehicle authenticates the credentials of the person; but not the person himself.

This becomes a bigger issue in advanced systems when the need to place hand on the sensor for authentication is removed. The car authenticates the user / driver (prover) as soon as he is in the vicinity of the ECU (which in this case, is the verifier). Thus, the need for a secure system becomes perilous in these situations.

Conclusion

DB protocol enables validation of two entity validation over a distance. While this offers ease and technological superiority, it also raises security concerns with it. This paper has listed some of the security requirements for an efficient and attack resilient protocol.

The literature review of several protocols in practice has been carried out, highlighting the bit exchanges and attacks possible on the DB scheme. Furthermore, a novel protocol is proposed which offers low computational and is resistant to most attacks. The claim is validated informally; by threat modelling and formally; by software analysis. Results for protocol run is different time scenarios are also presented.

Future areas of research

For the future, we would like to do the analysis of the protocols in literature, using a standard or a software realization (for this purpose mathematical modelling can be applied or a NIST standard for stream ciphers can be used). We would also like to verify the proposed protocol on a software tool other than used here.

Error Correction Code and hardware implementation of the protocol are also open areas of research. The best possible features can be extracted to make an even more vigorous, unique protocol. Our proposed protocol is still prone to Node Capture and de-synchronization attacks although the chance of occurrence of the latter is much less; still, it is an open ground for future studies and research. With that being said, various privacy and efficiency requirements are being studied in other research ventures, which can be incorporated in our work as well.