CS3760 Part 07: Introduction to Secure protocols

1
CS3760 Part 07Introduction to Secure protocols

• Based on material written by
• Dr Kenny Paterson
• http//isg.rhul.ac.uk/kp

2
Aims of This Lecture

• Explain how basic cryptographic mechanisms
  (encryption, MACs, signatures) can be used to
  provide security services (authentication and key
  distribution) over insecure networks.
• Discuss Kerberos and network authentication in
  Windows2000.

3
Outline

• Secure protocols
• Entity Authentication and Key Agreement
• Kerberos

4
Protocols

• A protocol is a set of rules for exchanging
  messages between 2 (or more) principals over a
  network.
• The word protocol in the OSI model is reserved
  and refers to rules governing communication
  between a pair of peer entities.
• We largely leave unspecified the OSI or TCP/IP
  layer at which our protocols operate.

5
Secure Protocols

• So what is a secure protocol?
• When acting honestly, principals (participants)
  achieve the stated aim of the protocol (e.g. A
  successfully authenticates to B, or A and B
  exchange a fresh session key).
• Neither passive eavesdropper nor malicious,
  active adversary can defeat this objective (e.g.
  by successfully impersonating A in an
  authentication protocol with B).

6
The Principals (1)

• Alice and Bob who wish to authenticate one
  another or to share a key.
• 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),.

7
The Principals (2)

• Two kinds of adversary
• Eve, a passive eavesdropper (sniffs messages at
  will).
• Mallory, an active adversary, who can view,
  alter, delete, replay and inject messages into
  network, initiate protocol runs, take on role
  of any principal in any protcol run,..

8
The Principals (3)

• Mallory is not all-powerful
• He cannot guess a random number chosen by another
  principal from a sufficiently large space.
• He cannot invert a one-way (hash) function.
• Without the correct key, he cannot retrieve the
  plaintext for a given ciphertext. Nor can he
  compose ciphertexts for plaintexts of his choice.
• He cannot deduce a private/signature key from a
  public/verification key, nor can he deduce a
  symmetric key from observing plaintext/ciphertext
  pairs.

9
Summary So Far

• So we equip Alice, Bob, Trent with idealised
  cryptographic mechanisms, but force them to use
  an untrusted network.
• The question then is
• How do we use these perfect cryptographic
  mechanisms (signatures, public-key and symmetric
  key encryption, hash functions, MACs) to design
  secure protocols (providing security services)?

10
Outline

• Secure protocols
• Entity Authentication and Key Agreement
• Kerberos
• Network Authentication in Windows2000

11
2. Authentication

• The OSI security architecture (ISO 7498-2)
  distinguishes between origin authentication
  (verifying origin of received data) and entity
  authentication (identity verification).
• Here we consider entity authentication.
• Typically achieved by exchange of cryptographic
  messages called an authentication protocol.

12
Definitions

• Entity authentication
• the corroboration that an entity is the one
  claimed.
• Unilateral authentication
• entity authentication which provides one entity
  with assurance of the others identity but not
  vice versa.
• Mutual authentication
• entity authentication which provides both
  entities with assurance of each others identity.

13
Basis for Authentication

• We have seen in part 03 that authentication can
  depend on
• Something you know (PIN, password)
• Something you have
• secureID card or other token, generating a one
  time password
• A key embedded in a secure area on host machine,
  in browser software
• Smartcard (which may have keys stored and crypto
  functionality e.g. RSA)
• Something you are (biometric)

14
Weak Authentication

• Passwords and PINs only provide weak
  authentication
• User demonstrates knowledge of password matching
  his user ID, server compares to entry in password
  file.
• Static, guessable, sniffable if unprotected.
• Not suitable for use over open networks.
• For extra security
• Use one-way encrypted password file and slow down
  encryption process and add salting to make
  dictionary attack harder.
• Access control on password file.
• Lock out after number of failed attempts.
• One-time passwords.

15
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.
• Use cryptographic mechanisms to protect messages
  in protocol
• Encryption.
• Integrity mechanism e.g. MAC.
• Digital signatures.

16
Ex 1 Encryption-based Unilateral Authentication

• Assume Alice (client) and Bob (server) share a
  secret key K, Bob authenticates Alice.
• Alice sends an initiating message.
• Bob sends Alice a challenge message R.
• Alice responds with R BK , message R
  concatenated with B, encrypted under shared key
  K.
• Bob decrypts Alices reply and checks that he
  gets R B back.
• Bob authenticates Alice.

17
Ex 1 The Protocol

• A B Hi Bob Im Alice
• B A R (challenge)
• A B R BK (response)
• Here XK means string X encrypted under key K,
  and means concatenation

18
Ex 1 Security of the Protocol

• Eve sees R and R BK. Because of perfect
  encryption, she learns nothing about K.
• Bob gets his challenge R back again, as a
  response that only Alice can prepare. This allows
  him to be sure of origin and integrity of
  message.
• But Mallory can impersonate Bob easily so Bob
  not authenticated to Alice. Only unilateral
  authentication of Alice to Bob.

19
A Replay Attack

• Mallory cant prepare correct response R BK
  to Bobs challenge because he doesnt know K.
• But challenge R must be unpredictable otherwise
  Mallory can masquerade as Alice in a subsequent
  protocol run, replaying Alices response

20
Ex 1 Replay Attack

• A M(B) Hi Bob, Im Alice
• M(B) A R
• A M(B) R BK
• M(A) B Hi Bob Im Alice
• B M(A) R
• M(A) B R BK
• M(A) means M masquerading as A etc

21
Freshness and Liveness

• The replay attack shows that origin and integrity
  checking are not enough we also need means of
  checking for freshness of messages and liveness
  of principals.
• Freshness assurance that message has not been
  used previously and originated within an
  acceptably recent timeframe.
• Liveness assurance that message sent by a
  principal within an acceptably recent timeframe
• Two main methods for providing freshness
• Nonce (number used ONCE)
• Time-stamps (clock-based or Logical)

22
Nonces

• Nonce Number used once, also known as a random
  challenge
• In Ex1, we depend on B to make sure R is freshly
  generated.
• Main property is one-time property, so could in
  theory use a counter.
• But many protocols need nonces to be
  unpredictable to Mallory. Generate at random from
  a large set (128 bits, say).

23
Time Stamps I

• 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 T BK
• less messages in protocol.
• But now require securely synchronised clocks
  non-trivial!

24
Time Stamps II

• Typical clock drift is 1s per day on work
  station.
• Need window of acceptance for Alices messages
  either side of Bobs current clock time
  (driftvariable propagation time).
• Need a log of recent received messages to prevent
  Mallory exploiting window with replay attack.

25
Logical Time Stamps

• Logical timestamps can provide an 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.
• Needs pair of (secret) sequence numbers for every
  pair of communicating parties.

26
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 Alices signature
  verification key (and vice-versa for mutual
  authentication).

27
Ex 2a Signature-based Mutual Authentication

• B A RB
• A B RA, SARA RB B
• B A SBRB RA A
• Here, SAX denotes As signature on X.
• Protocol achieves mutual authentication (via two
  signatures and two nonces).
• A and B must of course check the signatures to
  ensure their correctness.

28
Applications

• Entity authentication only achieved for an
  instant in time, typically provided at start of a
  connection/session.
• If security (e.g. confidentiality, integrity) is
  required for remainder of session, then a session
  key is needed.
• Session key can often be agreed as part of
  authentication protocol and can be bound to that
  protocol run, giving authenticated session key
  establishment protocol.

29
Authenticated Session Key Establishment

• As a simple example, we can adapt our one message
  time-stamp based protocol
• A B T BK
• simply by adding a session key SK in Alices
  message
• A B T B SKK
• Alice is authenticated to Bob and they now share
  session key SK

30
More on Key Agreement

• As weve seen, a session key can be established
  as a by-product of an authentication protocol.
  Here we start from the other end, and look at key
  agreement protocols.
• The main protocol we study is the celebrated
  Diffie-Hellmann Key Exchange (DHKE) protocol.
• Alice and Bob dont already share a key and cant
  meet to do so. How can they make their future
  communications confidential? Impossible!

31
Diffie-Hellmann Key GenerationAlice and Bob
share a, p (not secret)

• Alice
• generates a secret random number x
• Computes X ax mod p and sends it to Bob
• Takes Y and computes
• Yx (ay)x mod p

• Bob
• generates a secret random number y
• Computes Y ay mod p and sends it to Alice
• Takes X and computes
• Xy (ax)y mod p

32
Diffie-Hellmann and Eve

• Eve sees only the public values, X and Y.
• The function X ax mod p is specially chosen so
  that its hard to compute x from X (and similarly
  y from Y).
• Then Diffie-Hellmann key exchange protocol secure
  against passive adversaries.

33
Diffie-Hellmann and Mallory
Alice (x)
Mallory (m)
Bob (y)
XA
XM
YB
YM
A,M K (am)x mod p (ax)m mod p
M,B K (am)y mod p (ay)m mod p
34
The Man-in-the-middle Attack

• Alice thinks she has exchanged key K with Bob,
  instead its with Mallory.
• Bob thinks he has exchanged key K with Alice.
  Instead, its with Mallory.
• Mallory can now intercept all messages from A
  intended for to B, decrypt them, read them,
  re-encrypt them under K and pass them on to B.
  And vice-versa for messages from B to A.
• What went wrong?

35
Station-to-Station Protocol

• The station-to-station protocol adds
  authentication (via signatures) to DHKE
• A B X
• B A Y, SBY, XK
• A B SAX, YK
• After step 1, B can compute the shared key K.
  After step 2, so can A. The additional messages
  are encrypted signatures on everything fresh in
  the protocol run and provide authentication and
  key confirmation. These signatures should be
  checked by A and B.

36
Outline

• Secure protocols
• Entity Authentication and Key Agreement
• Kerberos
• Network Authentication in Windows2000

37
Kerberos

• Kerberos is a TTP-aided authentication protocol
• Its also software implementing that protocol,
  currently Kerberos V5 Release 1.2.
• Also a project at MIT which devised the protocols
  (properly called Project Athena).
• Also RFC 1510 Kerberos V5 (1992).
• A version of Kerberos exists in Windows 2000
  Kerberos is integrated into many versions of Unix.

38
Kerberos Principals

• Authentication Server (AS) - mutual
  authentication with client at login based on
  long-term key, gives client ticket granting
  ticket and short-term key.
• Ticket Granting Server (TGS) mutual
  authentication with client based on short-term
  key and ticket granting ticket. TGS then issues
  tickets giving clients access to further servers
  demanding authentication.

39
Kerberos - Motivation

• Idea of having two TTPs is that a user only needs
  to load his/her long-term secret key into the
  client host for the minimum time.
• Once the short-term key is established (with TGS)
  the long-term secret key can be erased from the
  client host.
• All further client interactions are with TGS and
  servers.
• This minimises the risk of exposure of the
  long-term secret key.

40
Kerberos Protocol
AS (authentication server)
TGS (ticket- granting server)
3
2
1
4
C (client)
S (server)
5
6
41
Kerberos - Message Formats (Simplified Version)

• 1. C?AS C TGS from to NC
• 2. AS?C C KC,TGSCfromtoKAS,TGS
  KC,TGSNCfromtoTGSKAS,C
• (Note that the second part in message 2 is
  the Ticket Granting Ticket for the TGS).
• 3. C?TGS SfromtoNC KC,TGSCfromt
  oKAS,TGS CT1KC,TGS
• 4. TGS?C C KC,SCfromtoKTGS,S
  KC,S NCfromtoSKC,TGS
• (Note that the second part in message 4 is
  the Ticket for the server S).
• 5. C?S KC,SCfromtoKTGS,S CT2KC,S
  
• 6. S?C T2KC,S

42
Client-AS (1 2)

• In this interaction, Client and AS use long-term
  key KAS,C derived from client password to
  mutually authenticate one another, derive a
  short-term key KC,TGS and a ticket granting
  ticket.
• These allow Client to talk to TGS in next step.
• This ticket includes short-term key KC,TGS and
  ticket lifetime encrypted under long-term key
  KAS,TGS.
• Default lifetime is 10 hours, determines length
  of session before re-authentication required.

43
Client-TGS (3 4)

• In this interaction, Client and TGS use
  short-term key to mutually authenticate one
  another, derive a session key and a (session
  granting) ticket.
• These allow client to talk to Server in next
  step.
• In more detail
• Client presents request for access to server S
  along with ticket granting ticket and a message
  authenticating himself to TGS (3).
• TGS checks validity and lifetime of ticket
  granting ticket and extracts his copy of the
  short-term key KC,TGS.TGS can now authenticate
  Client.
• If all OK, TGS issues session key KC,S and ticket
  to Client. The latter is encrypted under KTGS,S.
  Default validity is 5 minutes. TGS also sends
  message authenticating TGS to Client (4).

44
Client-Server (5 6)

• In this interaction, Client and Server S use
  session key and ticket to mutually authenticate
  one another.
• Success grants client access to server.
• In more detail
• Client presents ticket along with message
  authenticating himself to S (5).
• S checks validity and lifetime of ticket and
  extracts his copy of session key KC,S. S can now
  authenticate Client.
• If all OK, S grants access to Client. Optionally,
  S sends Client a message authenticating S to
  Client (6).

45
Use of Cryptography

• Kerberos uses symmetric encryption and a
  Manipulation Detection Code (MDC).
• Specifically, Version 5 (as in RFC 1510) uses DES
  combined with one of MD4, MD5, or a CRC (not
  recommended).
• Release 1.2 of Kerberos Version 5 implements
  triple DES (3DES).

46
Kerberos Issues

• Revocation ticket granting tickets valid until
  they expire, typically 10 hours.
• Within realms (domains) long-term keys need to
  be established between AS and TGS, TGS and
  Servers and AS and clients.
• Synchronous clocks needed, protected against
  attacks. Cache of recent messages to protect
  against replay within clock skew.

47
Kerberos Issues

• Need for on-line AS and TGS, trusted by clients
  not to eavesdrop.
• Client-AS long-term key often still based on
  password entry vulnerable to guessing.
• Short-term keys and ticket granting tickets
  located on largely unprotected client hosts.
• Denial of service? On clock service or on TGS.

48
Windows 2000 Network Authentication

• Microsoft have adopted and extended Kerberos for
  network authentication in Windows 2000.
• Supersedes Windows NTLM (unilateral
  authentication) and SSL in NT4.
• One extension support for public-key encryption
  to protect client/AS messages (rather than
  password-based long-term key).
• This allows use of smartcard-based authentication.

49
Windows 2000 Network Authentication

• Second extension use of Kerberos data
  authorization field to transmit access privileges
  (derived from ACLs in active directories).
• Field normally empty in Kerberos.
• Message formats proprietary to Microsoft.
• Non-standard extension to Kerberos makes it hard
  (impossible?) to interoperate Microsoft and
  non-Microsoft implementations.
• Result may be users forced to migrate to
  all-Microsoft installations.

50
Summary

• Introduction to secure protocols.
• Specifics of some authentication and key
  agreement protocols.
• Kerberos.