CN2243/CN4243 - Network

Security
Lecture 3
Introduction to Secure Protocols
Objectives of Lecture
• Introduce the concept of a secure protocol.
• Model the principals involved in secure protocols, and their capabilities
• Demonstrate how basic cryptographic mechanisms can be used to build entity
authentication and key distribution protocols suited to insecure networks
Contents
4.1 Secure protocols
4.2 Entity Authentication
4.1 Secure Protocols
• A protocol is a set of rules for exchanging messages between 2 (or more) principals over a
network
– Formally, this constitutes a distributed algorithm
• The word “protocol” in the OSI model is reserved and refers to rules governing
communication between a pair of peer entities.
• In this lecture, we largely leave unspecified the OSI layer at which our protocols operate
Secure Protocols
So what is a secure protocol?
• When acting honestly, principals (participants) achieve the stated aim of the protocol
• Typical aims:
• A successfully authenticates to B
• A and B establish a secret key
• Neither passive eavesdropper nor malicious, active adversary can defeat this aim (e.g. by
successfully impersonating A in an authentication protocol with B)
• This all pre-supposes that the stated aim is actually clearly stated!
The Principals – 1
• Alice and Bob who wish to authenticate one another or to share a key
– (We use the standard conventions for naming entities)
• In more complex protocols, Trent, a trusted third party who is trusted by both
Alice and Bob
– aka (depending on application) TTP, key distribution centre (KDC),
certification authority (CA),....
– What Trent is trusted to do (and not do) depends on the protocol and
application.
The Principals – 2
Two kinds of adversary:
• Eve, a passive eavesdropper (‘sniffs’ messages at will)
• Mallory (or Mallet), an active adversary, who can view, alter, delete, replay and inject
messages into the network (Dolev-Yao model:The adversary is the network)
• Other participants:
– Carol, Dave (extra principals)
– Walter (warden, guarding actions of Alice, Bob)
– Peggy (prover)
– Victor (verifier)
The Principals – 3
Mallory is not all-powerful:
• He/She cannot predict a number chosen uniformly at random from a sufficiently large set of
possibilities by another principal
• Mallory cannot break well-designed cryptographic mechanisms:
– He/She cannot invert a one-way hash function
– Without the correct key, he/she cannot obtain the plaintext for a given ciphertext
– Without the correct key, he/she cannot compose ciphertexts for plaintexts of his choice
– He/She cannot sign messages without having the appropriate private key
– He/She cannot correctly compute a MAC (message authentication code) on a message
without knowing the correct secret key
Summary So Far
• So we equip Alice, Bob, Trent with strong cryptographic mechanisms to use on an untrusted
network.
• The question then is:
How do we use these cryptographic mechanisms (signatures, public-key and symmetric
key encryption, hash functions, MACs) to design secure protocols (providing security services
for our principals)?
4.2 Entity Authentication
• We distinguish between (data) origin authentication (verifying the origin of received data) and
entity authentication (verification of a claimed identity).
• An origin authentication service can be built from a data integrity mechanism, e.g. a MAC
• Here we consider entity authentication, a basic security service in networks.
• Typically achieved by exchange of messages called an authentication protocol (called an
authentication exchange in ISO 7498-2).
Why Entity Authentication?
• We are interested in controlling access to communication and information resources over
potentially insecure networks
• Entity authentication provides a fundamental service:
– It allows one host or user on the network to check with which other host or user it is
communicating
• Successful entity authentication can be a precursor to (or part of) the use of more complex
security services.
• Now I know which host I’m talking to:
– To which network services should it be given access?
– To which data should it be given access?
– How can secure communications with that host be established and maintained?
Definitions
• Entity authentication:
– The corroboration that the identity of an entity is the one claimed at a
particular point in time (but not necessarily any guarantees after that time)
• Unilateral authentication:
– Entity authentication which provides one entity with assurance of the
other’s identity but not vice versa
• Mutual authentication:
– Entity authentication which provides both entities with assurance of each
other’s identity
Basis for Authentication
• Suppose we want to design a protocol which authenticates A to B. Is the following
secure?
A - B: ‘Hi B, I’m A’
• No – Mallory can easily impersonate A.
• So we need something stronger
• Authentication protocols can be built from a number of different assumptions:
• A and B share a secret (e.g. a password, a PIN, biometric information, a symmetric
key)
• A and B have authentic copies of each other’s public keys
Strong Authentication
• In strong authentication, one entity “proves” its identity to another by demonstrating
knowledge of a secret known to be associated with that entity, without revealing that secret
itself during the protocol
• Also called challenge-response authentication.
• Typically use cryptographic mechanisms to protect the messages in the protocol:
– Encryption
– Integrity mechanisms (e.g. MACs)
– Digital signature
Example: Passwords Over a Network
• Alice has a user ID and password allowing her to remotely access a computer B over a
network
– Alice sends the user ID and password over the network
– computer B uses Alice’s ID to find an entry in a password file, and compares the
password received with the password stored
– computer B authenticates Alice if the passwords match
• An example of user authentication based on something known.
– a special case of entity authentication.
• Is this a strong authentication protocol or not?
Example (continued)
• Here the secret associated with Alice is her password
• This secret itself is revealed during the protocol, hence we have what might be termed weak
authentication
• The password might be captured in transit over the network
– Depending on the network type and attacker capabilities, this will result in the
authentication being compromised
• So this approach not really suitable for use over insecure networks
– But still very commonly used in such situations, e.g. SNMPv1, FTP, Telnet, RSH, some
Outlook versions, some web mailers,...
– May well be appropriate when authenticating to a local machine
• For a degree of added security, transmit only hashed (salted) passwords
– Still vulnerable to dictionary attacks and replay attacks
User Authentication
• Here, the objective is to authenticate a user to a system (and possibly vice-versa)
• User authentication usually based on (a combination of):
– Something you know (password, PIN)
– Something you have (a smartcard or token,...)
– Something you are (a biometric feature)
• User authentication is limited by what a user can remember, carry or be
– And the problem may be harder when user and system are remote, because
credentials/data may need to be protected in transit
– Can’t expect users to remember long cryptographic keys or carry unwieldy equipment
– Authentication not directly involving users (e.g. machine to machine) is not generally
limited in this way
Encryption-based Unilateral Authentication
• Assume Alice and Bob share a secret (symmetric) key K.
• Design goal: Alice to be authenticated
• Alice sends an initiating message
• Bob sends Alice a challenge message R, a random string of bits
• Alice responds with {R || B}K, message R concatenated with B, encrypted using shared key
K
• Bob checks that the message he received decrypts to give message R || B
• If it does, then Alice is authenticated to Bob (or Bob authenticates Alice)
The Protocol
A - B: ‘Hi Bob, I’m Alice’
B - A: R (challenge)
A - B: {R || B}K (response)

(Here, {X}K means string X encrypted under key K, and || means concatenation of strings.)
The Protocol
A - B: ‘Hi Bob, I’m Alice’
B - A: R (challenge)
A - B: {R || B}K (response)

(Here, {X}K means string X encrypted under key K,

and || means concatenation of strings.)
Security of the Protocol – 1
1. Why can Bob be sure that message 3 in the protocol came from Alice?
2. Why can Bob be sure that message 3 in the protocol is not a replay of a message
from an earlier run of the protocol between himself and Alice?
• Only Alice (and Bob) know the secret key K.
• Bob chose R at random just before sending message
• This R should never have been used before. This means that message 3, which
includes R in encrypted form, has never previously been produced in response to
a challenge
Security of the Protocol – 2
1. Why can Bob be sure that message 3 in the protocol is intended for him?

Alice includes Bob’s identity “B” in the encrypted message. This prevents
Mallory taking a message intended for someone else (e.g. Alice!) and sending it
to Bob

2. Can an attacker learn the value of secret key K by observing multiple runs of
the protocol?

No, not if the encryption algorithm is strong (and has some desirable
properties)
Security of the Protocol – 3
1. Is Alice authenticated to Bob in this protocol?
Yes
2. Is Bob authenticated to Alice in this protocol?
No. (In fact Mallory could impersonate Bob in the protocol, but our design
goal was a protocol in which Alice is authenticated, not Bob, so this is not a
problem.)
3. Does the protocol provide mutual or unilateral
authentication?
Unilateral: authentication of Alice
A Replay Attack – 1
• Suppose Mallory wants to impersonate Alice in this protocol:
1. M(A) B: ‘Hi Bob, I’m Alice’
2. B M(A): R (challenge)
3. M(A) B: ???
• Now Mallory can’t prepare the correct response {R||B}K to Bob’s challenge
because he doesn’t know the secret key K and R has not been previously used
• But what if Mallory could predict R?
Then we can find a serious replay attack....
A Replay Attack – 2
Mallory firstly impersonates Bob to Alice in a protocol run initiated by
Alice:
1. A M(B): ‘Hi Bob, I’m Alice’
2. M(B) A: R (M predicts which R will be used later by B)
3. A M(B): {R || B}K
Mallory keeps hold of {R || B}K: it’s going to come in handy later:
1. M(A) B: ‘Hi Bob, I’m Alice’
2. B M(A): R (M predicted this R would be used by B)
3. M(A) B: {R || B}K
Liveness and Freshness
• The replay attack shows that it is vital that the protocol contains a means of checking liveness
of principals
• Liveness: assurance that message sent by a principal within an acceptably recent timeframe
• Liveness of principals usually ensured via freshness of messages
• Freshness: assurance that a message has not been used previously and originated within an
acceptably recent timeframe
• Two main methods for providing freshness:
– Nonce (Number used once)
– Time-stamps (clock-based or `logical’ time-stamps)
Nonces
• Main property is ‘one-time’ property: nonce should not have been used before.
– So could in theory use a counter
• But many protocols need nonces to be unpredictable to Mallory, rather than simply
previously unused
– For example, our protocol needs this property for R to prevent the replay attack.
– Could form R by generating a long string of bits at random, e.g. 128 bits.
• Notice that in our protocol, R, the nonce is unpredictable but not secret
Nonces – Pros and Cons
Pros:
• Simpler to manage than timestamps (see next slides)
Cons:
• Protocols typically need more messages than timestamp-based ones
• Randomness may be a precious resource
– Difficult to generate truly random bits without special purpose hardware.
• On a PC, can carefully pool timing information of various kinds
• Modern chipsets do include hardware RNGs, but these are not always used (device drivers) and
not necessarily random
– May be very difficult on a constrained device
– How can quality of randomness be measured and controlled?
– Is pseudo-random generation using a deterministic algorithm strong enough?
Time-stamps
• Inclusion of date/time-stamp in message allows recipient to check it
for freshness (as long as time-stamp protected by cryptographic
means)
• A - B: ‘I’m Alice’, {T || B}K
– Bob decrypts and checks that T is recent and that his identity is
included
– Only Alice (and Bob) knows K, so only Alice could have prepared
this message. It’s fresh, so Alice is live
Time-stamps – Pros and Cons
Pros:
• Protocol needs only a single message instead of three
• No randomness needed; many devices have clocks
Cons:
• We require securely synchronised clocks to prevent replay – non-trivial!
– RTCs with NTP provide only limited resolution (a few seconds)
• Also need a window of acceptance for Alice’s messages either side of Bob’s current clock time
(clock drift + variable network propagation time)
• And a log of recently received messages to prevent Mallory from exploiting window with
replay attack
– Mallory eavesdrops authentication message {T || B}K from Alice and replays it during B’s
acceptable time period for T
Time-stamps in Action
• A form of time-stamping is used by RSA’s SecurID token system:
• Time T and key K used by token to generate an authentication message, displayed on
token’s screen
• User reads message from screen and enters it into computer
• Message transmitted to remote host and compared with expected message (also
computed using T and K)
• Typical acceptance window: 60s
• Product can also add PIN entry for 2-factor authentication
“Logical” (or Lamport) Timestamps
• Alternative to clocks: Alice and Bob could use pair of sequence numbers NAB and NBA
in their communications
• Every time A sends B a message she includes value NAB, and increments it. Likewise
for B
• B only accepts message from A if value of NAB, exceeds previously received value
• Used in UMTS to authenticate network to USIM in mobile phone
• Similar mechanism also used in SNMPv3 (see Stallings and RFCs)
Logical Time-stamps – Pros and Cons
Pro:
• No need to generate random strings or to maintain synchronised clocks
Cons:
• Needs a pair of sequence numbers for every pair of communicating parties
• Sequence numbers may need to be kept secret in protocol runs
– May otherwise be predictable to Mallory
Using MACs for Entity Authentication
Replace encryption mechanism with a MAC:
1. A B: ‘Hi Bob, I’m Alice’
2. B A: R (challenge)
3. A B: MACK(R || B) (response)
Can argue security as for encryption-based protocol:
Only Alice can prepare correct response for Bob; freshness of R
guarantees liveness of Alice.
What properties of the MAC did we use?
Signature-based Entity Authentication
• Instead of challenge/response, now challenge/signature
• Use nonces or time-stamps for freshness
• Rather than a shared secret key, Bob needs to have authenticated
version of Alice’s public key (and vice-versa for mutual
authentication)
Example: Signature-based Mutual
Authentication
1. B A: RB
2. A B: RA, SA{RA || RB || B}
3. B A: SB{RB || RA || A}
• Here, SA{X} denotes A’s signature on string X
• Protocol achieves mutual authentication (via two signatures and two
nonces)
• B must verify A’s signature (using A’s public key) and vice-versa
Using Digital Signatures
• Alice and Bob have to be sure that they are verifying each other’s signatures
• Hence need for trust in authenticity of public keys instead of shared secrets
• Public keys can be certified by applying the digital signature of a Trusted Third
Party (TTP) called a Certificate Authority (CA)
• Result (public key + entity name + expiry date + CA signature on three items) is
called a certificate
Using Certificates
• To check a certificate signed by a CA requires an authentic copy of the
CA’s public key
• Leads to notion of certification paths and public-key infrastructures
(PKI)
• Related protocols are used in SSL/TLS and IPSec, and can also be used
in SSH
Further study: Modules #15, 16, 17
Further study: Modules #15, 16, 17