Andrew Secure RPC Protocol Analysis

Abstract :
Remote Procedure Call(RPC) is a protocol that one program can use to request a
service from a program located in another computer on network without having to
understand the network's details.To simply put, RPC allows a computer program to call
another function from another address space or even another machine altogether.So
the communication between two process or two clients need to be secured.More
specifically the channel needs to be secured.Andrew Secure RPC is one such
protocol.The Andrew Secure RPC is a way to help secure RPC. It is basically a
cryptographic protocol that allows entity authentication as well as session key
establishment.

1. Introduction
In this assignment we basically studied Andrew Secure RPC protocol,the design
of it and analyze the same.We found that there are two logic GNY and BAN logic
which checks the logical structure of a protocol .Here we studied BAN logic and
how it can be used to verify Andrew Secure RPC protocol and logical correctness
of it.BAN logic does not tell the technical strongness of a protocol.So basically it
does not say how many bits are used for the key. Is the key breakable on the
basis of computation?Such things are not the outcome after verification with BAN
Logic.So it checks if the protocol is logically flawed or not.

​ ​2. Objective
To analyse Andrew secure RPC protocol and show that there is an attack
possible from Intruder impersonating as sender.Basically we first have to verify
Andrew Secure RPC protocol with BAN logic and see whether the procol meets
its security goals or not.If the security goals are not meet then we will have to
show that an attack possible from Intruder impersonating as sender.
3. Background

This section contains a short description and notations of the BAN logic, a short
introduction of AVISPA tool as well as the background knowledge on the Andrew
secure RPC protocol,unsafe one. The background on the Andrew RPC includes
the description of the original protocol, the protocol after BAN analysis, that is the
safe one.Unsafe one is the one which does not meet its security goals . Safe one
is the one where the security goals are meet.

3.1 BAN Logic

BAN logic stands for Burrows–Abadi–Needham logic. The BAN logic provides a
formal method for reasoning about the beliefs of principals in cryptographic
protocols. BAN logic is a set of rules for defining and analyzing information
exchange protocols. Specifically, BAN logic helps its users determine whether
exchanged information is trustworthy, secure against eavesdropping, or both.
BAN logic starts with the assumption that all information exchanges happen on
media vulnerable to tampering and public monitoring.
A typical BAN logic sequence includes three steps:

1. Verification of message origin

2. Verification of message freshness
3. Verification of the origin's trustworthiness.

Basic Rules

The definitions and their implications are below (​P​ and ​Q​ are network agents, ​X
is a message, and ​K​ is an encryption key):

a) P​ believes ​X:​ ​P​ acts as if ​X​ is true, and may assert ​X​ in other messages.
b) P​ has jurisdiction over ​X​: ​P​'s beliefs about ​X​ should be trusted.
c) P​ said ​X​: At one time, ​P​ transmitted (and believed) message ​X​, although
P​ might no longer believe ​X​.
d) P​ sees ​X:​ ​P​ receives message ​X​, and can read and repeat ​X.​
e) {​X​}​K​: ​X​ is encrypted with key ​K​.
f) fresh(​X​): ​X​ has not previously been sent in any message.
g) key(​K​, ​P↔ ​ ​Q​): ​P​ and ​Q​ may communicate with shared key ​K
The meaning of these definitions is captured in a series of postulates:

● If ​P​ believes (​Q​ said ​X​) and ​P​ believes fresh(​X)​ , then ​P​ believes (​Q
believes ​X)​ .
● If ​P​ believes key(​K​, ​P​↔​Q​), and ​P​ sees {​X​}K​ ​, then ​P​ believes (​Q​ said ​X​)

P​ must believe that ​X​ is fresh here. If ​X​ is not known to be fresh, then it might be
an obsolete message, replayed by an attacker.

● If ​P​ believes (​Q​ has jurisdiction over ​X​) and ​P​ believes (​Q​ believes ​X​),
then ​P​ believes ​X
● There are several other technical postulates having to do with composition
of messages. For example, if ​P​ believes that ​Q​ said <​X​, ​Y​>, the
concatenation of ​X​ and ​Y​, then ​P​ also believes that ​Q​ said ​X​, and ​P​ also
believes that ​Q​ said ​Y​.

Using this notation, the assumptions behind an authentication protocol can be

formalized. Using the postulates, one can prove that certain agents believe that
they can communicate using certain keys. If the proof fails, the point of failure
usually suggests an attack which compromises the protocol.

3.2 AVISPA Tool

The AVISPA Tool is a push-button tool for the Automated Validation of Internet
Security Protocols and and Applications which rises to this challenge in a
systematic way by
(i) providing a modular and expressive formal language for specifying
security protocols and properties, the High-Level Protocol Specification
Language HLPSL, and
(ii) integrating different back-ends that implement a variety of automatic
analysis techniques ranging from protocol falsification (by finding an attack
on the input protocol) to abstraction-based verification methods for
infinite numbers of sessions.
Experimental results, carried out on a large library of Internet security protocols,
indicate that the AVISPA Tool is a state-of-the-art tool for Internet security
protocol analysis as, to our knowledge, no other tool exhibits the same level of
scope and robustness while enjoying the same performance and scalability.

3.3 Andrew RPC Protocol

 This protocol is intended to distribute a new session key between two principals
A and B.

Protocol specification
A,B : principal
Kab, K'ab : symkey
Na, Nb, N’b : nonce
Success : nonce->nonce

Messages
1. A -> B : A, {Na}Kab
2. B -> A : {Na+1, Nb}Kab
3. A -> B : {Nb+1}Kab
4. B -> A : {K'ab, N'b}Kab

Description of the protocol rules

This protocol establishes the fresh shared symmetric key K'ab. The nonce N'b is
sent in message 4 to be used in a future session.

We assume that initially, the symmetric keys Kab is known only to A and B.

Requirements
The protocol must guaranty the secrecy of the new shared key K'ab: in every
session, the value of K'ab must be known only by the participants playing the
roles of A and B.

The protocol must guaranty the authenticity of K'ab: in every session, on

reception of message 4, A must be ensured that the key K'ab in the message has
been created by A in the same session.

Attack

Replay-Attack

The message 4 contains nothing that A knows to be fresh. Hence, an intruder I

can replay this message in another session of the protocol to convinced B to
accept an old compromised key.

4. Analysis of Andrew RPC Protocol

 In BAN logic we make some basic assumptions about protocol.

Assumptions
A believes A<-Kab->B
B believes A<-Kab->B
A believes (B controls A<-Kab->B)
A believes fresh{Na}
B believes fresh{Nb}
B believes fresh{Nb’}

Analysis

1. A believes A<-Kab-> A sees {Na+1,Nb}Kab

-------------------------------------------------------

A believes B said {Na+1,Nb}

2. A believes fresh(Na), A believes B said{Na+1,Nb}

-----------------------------------------------------------

A believes B believes {Na,Nb}

Rule that cannot be obtained

A believes fresh(Na), A believes (B said {Na},A<-Kab>B)

---------------------------------------------------------------------

A believes B believes A <-kab->B

Because we have not sent Na while sending the new session key.

So intruder can Impersonate using a old session key.

5.Implementation

We have used AVISPA TOOL to simulate the Andrew Secure RPC protocol both
the safe and unsafe one.We have written HSPSL code for that .Below are the
screenshots of the simulations.
 FIGURE : 1

In the above screenshot when we run the normal or the unsafe Andrew Secure
RPC protocol we get UNSAFE message.Then we run the attack
simulation.Below are the screenshots for that.

FIGURE : 2
 FIGURE : 3

In these two above screenshot we can see that the Intruder can capture the
message from old sessions and able to replay it.So there is no secrecy and
authentication.These are the two goals which need to be satisfied.Although the
messages are encrypted with the symmetric key or the session key.Now
suppose the key transferred in the latest message is some old session key which
the intruder had captured before, then the intruder can use that key and he can
decrypt and modify the message and send it.This is a severe attack.This attack
happens because there is no freshness of the key maintained .If the agents
accept the key with latest timestamp or nonce which we have used here.Then
the agents can directly discard the message since it is not fresh.
The code for the Unsafe Andrew Secure RPC Protocol is uploaded in github.One
can find the link in the​ [8] ​point from References.

Below are the screenshots oh the modified one or the safe one where the attack
is not possible.
 FIGURE : 4

FIGURE : 5

In the above two screenshots we see that when we run the code for the safe
 Andrew Secure RPC Protocol, the AVISPA TOOL says safe since the two goals
,that is, the secrecy of symmetric key of the communicating parties And B and
authentication of the two communicating parties are maintained.
The code for the Safe Andrew Secure RPC Protocol is uploaded in github.One
can find the link in the ​[9]​ point from References.

6. CONCLUSION

A couple of vulnerabilities have been found in the Andrew RPC.Those

vulnerabilities could potentially lead to a known-plaintext attack as well as a
Replay-attack.We have shown the implementation of the unsafe and the safe
one where attack is possible and where attack is not.So the main purpose of the
study here , is what we conclude that is, every security protocol should be
logically correct which needs to be verified before implementing.Whatever strong
key we may use if the protocol is not logically valid then it may fail to meet its
security goals.

7. REFERENCES

[1]A more secure and efficient Andrew Secure RPC protocol by Sirapat
Boonkrong.
https://onlinelibrary.wiley.com/doi/full/10.1002/sec.918

[2]Some Remarks on Andrew Secure RPC by

Sirapat Boonkrong

[3]On a Limitation of BAN Logic by Colin Boyd and Wenbo Mar.

[4] ​http://www.lsv.fr/Software/spore/andrew.html

[5] ​https://en.wikipedia.org/wiki/Remote_procedure_call

[6] Burrows, M., Abadi, M. and Needham, R. (1989). A Logic of Authentication.

Tech. Report 39, Palo Alto CA: Digital Equipment Corporation Systems Research
Center.

[7] A Logic of Authentication by Burrows, Abadi and Needham by Kyntaja.

http://www.tml.hut.fi/Opinnot/Tik-110.501/1995/ban.html
[8]h​ttps://github.com/arnabmaity/Network-Security-Andrew-Secure-RPC-Protocol
-analysis-using-BAN-Logic/blob/master/Andrew%20Secure%20RPC%20Protocol
%20Unsafe%20one

[9]h​ttps://github.com/arnabmaity/Network-Security-Andrew-Secure-RPC-Protocol
-analysis-using-BAN-Logic/blob/master/Andrew%20Secure%20RPC%20Protocol
%20Safe%20one